English Amiga Board


Go Back   English Amiga Board > Coders > Coders. Asm / Hardware

 
 
Thread Tools
Old 10 April 2014, 06:57   #1
gulliver
BoingBagged

gulliver's Avatar
 
Join Date: Aug 2007
Location: The South of nowhere
Age: 43
Posts: 2,249
68020 to 68000 code convertion using Ira and PhxAss

Hi, I am complete rookie on assembly programming, so please forgive my ignorance:

I was wondering how to dissassemble and convert to 68000 an executable/library that was originaly designed for the 68020.

I am using ira and PhxAss (both latest versions). What I am doing with no success is the following:

ira -m68000 foo
phxass foo.asm m=0 opt 0

The end result is a buggy executable/library that fails to run properly on a 68000.

So, is there a more or less automatic way of doing what I want to achieve with these programs?

I would apreciate any input
gulliver is offline  
Old 10 April 2014, 08:41   #2
matthey
Banned
 
Join Date: Jan 2010
Location: Kansas
Posts: 1,284
Hi Gulliver,

Quote:
Originally Posted by gulliver View Post
I was wondering how to dissassemble and convert to 68000 an executable/library that was originally designed for the 68020.

I am using ira and PhxAss (both latest versions). What I am doing with no success is the following:

ira -m68000 foo
phxass foo.asm m=0 opt 0

The end result is a buggy executable/library that fails to run properly on a 68000.
I believe -m68000 for ira tells it to only recognize 68000 code. Specifying a target with less instructions and addressing modes can sometimes help identify code vs data. Since you are translating from 68020 code you would probably want to use -m68020. At least that's how it works with ADis which you might try:

http://www.heywheel.com/matthey/Amiga/ADis.lha

For a library, you would type:

ADis -m6 -l foo.library

ADis works better for disassembling and reassembling IMO. It's very convenient to turn off branches with -d2 and let vasm re-optimize them all after making changes. I usually use vasm in normal mode with esc sequences turned off when recompiling. PhxAss usually does ok but vasm is safer and optimizes more including branches in both directions.

There is no easy way to convert from 68020 to 68000 that I'm aware of. It's usually quite a pain actually. Sometimes extra registers are needed and none are free like this:

add.l d2,(8,a0,d0.l*4)

The 68000 doesn't have *4 so something like this is needed:

move.l d0,d1
lsl.l #2,d1
add.l d2,(8,a0,d1.l)

If you can't determine that you have a free data register then you have to save one to the stack and restore it after using. Also, do you know that the alignment is not odd? It's difficult to tell and even more of a pain. There are some easier cases like if you find:

extb.l d0

You can change to:

ext.w d0
ext.l d0

You picked a quite high degree of difficulty to start. It's much easier to go the other way with 68000 to 68020.

Quote:
Originally Posted by gulliver View Post
So, is there a more or less automatic way of doing what I want to achieve with these programs?
Not that I know of. Even if there was an automatic process there would be some danger in disassembling and reassembling without reviewing the disassembly for errors. With that said, ADis will give a flawless disassembly of libraries ready to assemble most of the time.
matthey is offline  
Old 10 April 2014, 09:51   #3
StingRay
move.l #$c0ff33,throat

StingRay's Avatar
 
Join Date: Dec 2005
Location: Berlin/Joymoney
Posts: 6,603
Quote:
Originally Posted by gulliver View Post
So, is there a more or less automatic way of doing what I want to achieve with these programs?
Not really because not only the instructions have to be changed for 68000 compatibility, the code has to be adapted as well since the 68000 doesn't allow word/long access to odd addresses whereas 68020+ does. This can cause some very hard to track down bugs on the 68000.

What exactly is it you want to do?
StingRay is offline  
Old 10 April 2014, 10:57   #4
Mrs Beanbag
Glastonbridge Software
Mrs Beanbag's Avatar
 
Join Date: Jan 2012
Location: Edinburgh/Scotland
Posts: 2,202
Quote:
Originally Posted by StingRay View Post
Not really because not only the instructions have to be changed for 68000 compatibility, the code has to be adapted as well since the 68000 doesn't allow word/long access to odd addresses whereas 68020+ does.
Although anyone who has a habit of doing that is a maniac IMHO!

I haven't personally found it very useful anyway. So you might get away with not worrying about that. Then again I don't even use any of the 68020's fancy new addressing modes apart from scaled index.

Important additions to instruction set are: bitfield instructions, longword multiplies and divides, and EXTB (very useful).

There is also the mysterious CALLM/RTM which was introduced in 68020 and then dropped again in 68030, what the thinking was behind that I can but wonder.
Mrs Beanbag is offline  
Old 10 April 2014, 11:10   #5
StingRay
move.l #$c0ff33,throat

StingRay's Avatar
 
Join Date: Dec 2005
Location: Berlin/Joymoney
Posts: 6,603
Quote:
Originally Posted by Mrs Beanbag View Post
I haven't personally found it very useful anyway.
Neither have I but this is not relevant here as it doesn't help the OP with his question.

Quote:
Originally Posted by Mrs Beanbag View Post
So you might get away with not worrying about that.
For 68020 to 68000 conversions this does have to be taken into account!
StingRay is offline  
Old 10 April 2014, 12:50   #6
Thorham
Computer Nerd

Thorham's Avatar
 
Join Date: Sep 2007
Location: Rotterdam/Netherlands
Age: 44
Posts: 3,216
Quote:
Originally Posted by Mrs Beanbag View Post
Although anyone who has a habit of doing that is a maniac IMHO!
What about reading 24bit pixels? If you want whole 24bit pixels in registers, then you do something like this:
Code:
    move.l  (a0),d0
    addq.l  #3,a0
Thorham is offline  
Old 10 April 2014, 14:12   #7
gulliver
BoingBagged

gulliver's Avatar
 
Join Date: Aug 2007
Location: The South of nowhere
Age: 43
Posts: 2,249
Thank you all for your comments and suggestions.

My goal was to downconvert to 68000 the following files:

workbench.library 45.132
Iprefs 45.13
picture.datatype 45.17

This would have proven useful for running an improved workbench experience under 68000.

I was extremely naive to think it would be so easy, as there is so much more involved as you have shown me

Thanks again
gulliver is offline  
Old 10 April 2014, 17:05   #8
amigoun
Registered User
amigoun's Avatar
 
Join Date: May 2010
Location: Czech Rep
Posts: 564
It would be great to convert Dungeon Master 2 executable from 020+ to 000, to be able to run on Minimig..
Only just dreaming..
amigoun is offline  
Old 10 April 2014, 23:03   #9
Mrs Beanbag
Glastonbridge Software
Mrs Beanbag's Avatar
 
Join Date: Jan 2012
Location: Edinburgh/Scotland
Posts: 2,202
Quote:
Originally Posted by StingRay View Post
For 68020 to 68000 conversions this does have to be taken into account!
Well for a general solution you need to take that into account, but if you know a specific program doesn't use odd memory accesses then it doesn't matter does it? You'd find out if that was the case anyway because it generates a specific exception.

Quote:
Originally Posted by Thorham View Post
What about reading 24bit pixels? If you want whole 24bit pixels in registers, then you do something like this:
Code:
    move.l  (a0),d0
    addq.l  #3,a0
Ah, well you could do. Not something I've ever had to deal with personally but I'd bend over backwards to avoid odd addressing anyway. Read pixels in pairs:
Code:
    move.l (A0),D0
    addq.l #2,A0
    lsr.l #8,D0
    move.l (A0)+,D1
Quote:
Originally Posted by gulliver View Post
My goal was to downconvert to 68000 the following files:

workbench.library 45.132
Iprefs 45.13
picture.datatype 45.17
I'm actually surprised these are not 68000 compatible anyway, Workbench 3.x will run on ECS Amigas won't it?

Last edited by Mrs Beanbag; 10 April 2014 at 23:08.
Mrs Beanbag is offline  
Old 11 April 2014, 05:49   #10
Thorham
Computer Nerd

Thorham's Avatar
 
Join Date: Sep 2007
Location: Rotterdam/Netherlands
Age: 44
Posts: 3,216
Quote:
Originally Posted by Mrs Beanbag View Post
but I'd bend over backwards to avoid odd addressing anyway.
Why?

Quote:
Originally Posted by Mrs Beanbag View Post
Read pixels in pairs:

Code:
    move.l (A0),D0
    addq.l #2,A0
    lsr.l #8,D0
    move.l (A0)+,D1
That's around 1.4 cycles slower per pixel, and it's a little bit less simple. Also, while you're not using odd addresses here, one of the move.l instructions will still read from a non 32 bit aligned address. Why the problem with odd-non aligned and not with even-non aligned?

Edit:

For 688030.

Last edited by Thorham; 11 April 2014 at 14:47.
Thorham is offline  
Old 11 April 2014, 06:43   #11
StingRay
move.l #$c0ff33,throat

StingRay's Avatar
 
Join Date: Dec 2005
Location: Berlin/Joymoney
Posts: 6,603
Quote:
Originally Posted by Mrs Beanbag View Post
Well for a general solution you need to take that into account
And that's what gulliver asked for, a general, automatic solution.

Quote:
Originally Posted by Mrs Beanbag View Post
Not something I've ever had to deal with personally but I'd bend over backwards to avoid odd addressing anyway.
I don't really like it either but I don't avoid it completely, I have used it for size-optimising in some of my 4k intros for example and Thorham's example is good real world use of it too.

Quote:
Originally Posted by Mrs Beanbag View Post
I'm actually surprised these are not 68000 compatible anyway, Workbench 3.x will run on ECS Amigas won't it?
So am I actually. WB 3.x works on ECS Amigas as you can use Kickstart 3.1 in non-AGA machines without problems. There might be different WB3.x versions for 68000 and 680x0 machines though.
StingRay is offline  
Old 11 April 2014, 07:21   #12
matthey
Banned
 
Join Date: Jan 2010
Location: Kansas
Posts: 1,284
Quote:
Originally Posted by Thorham View Post
That's around 1.4 cycles slower per pixel, and it's a little bit less simple. Also, while you're not using odd addresses here, one of the move.l instructions will still read from a non 32 bit aligned address. Why the problem with odd-non aligned and not with even-non aligned?
On which 68k CPU? Any even address is aligned for a 32 bit memory access with the original 68000 and it's 16 bit data bus. An odd address 32 bit memory access generally has a bigger penalty than an even unaligned 32 bit memory access on the 32 bit 68020+. Also, unaligned reads are cheaper than writes and the 68040 and 68060 have less penalty than the 68020/68030 from what I recall. Even if unaligned accesses are handled efficiently, it's still possible to cause 2 cache lines to be accessed on the 68030+. Reading a stream (post-increment or pre-decrement addressing modes) will usually only trigger 1 cache line access at a time like in this example. If taking the penalty is faster, then the unaligned access will probably be used. The penalty calculation can vary from one 68k CPU to the next, the memory caching type, the memory speed, whether the access is a read or write and how unaligned the access is. I guess that's reason enough to try and keep as good of alignment as is reasonable.
matthey is offline  
Old 11 April 2014, 16:05   #13
daxb
Registered User
 
Join Date: Oct 2009
Location: Germany
Posts: 2,788
Quote:
Originally Posted by Mrs Beanbag View Post
I'm actually surprised these are not 68000 compatible anyway, Workbench 3.x will run on ECS Amigas won't it?
The mentioned software (V45) are part of OS3.9. So they need 68020+. The OS3.1 software (V40) parts are 68000 compatible (I guess).

gulliver wants something like this example but easier: The 68000 icon.library from PeterK. Disassembled V45 (68020+) rewritten/optimized and later made 68000 compatible.
daxb is offline  
Old 11 April 2014, 16:24   #14
Thorham
Computer Nerd

Thorham's Avatar
 
Join Date: Sep 2007
Location: Rotterdam/Netherlands
Age: 44
Posts: 3,216
Quote:
Originally Posted by matthey View Post
On which 68k CPU?
68030 (Blizzard 1230 IV, 60ns RAM).

Quote:
Originally Posted by matthey View Post
I guess that's reason enough to try and keep as good of alignment as is reasonable.
For 68020+ the only good reason to use alignment is speed. If it's not faster, then don't bother. That said, doing things aligned is probably faster in most cases. I also doubt somehow that there are many situations where you want three bytes a time in a tight loop. For unaligned data in file headers and similar things, don't bother and write simple, easy to read code.

In the case of the code blocks above, I've tested both, and odd addressing is faster. Didn't even know that until I tried it.
Thorham is offline  
Old 11 April 2014, 16:28   #15
Wepl
Moderator
Wepl's Avatar
 
Join Date: Nov 2001
Location: Germany
Posts: 760
Quote:
Originally Posted by matthey View Post
On which 68k CPU? Any even address is aligned for a 32 bit memory access with the original 68000 and it's 16 bit data bus. An odd address 32 bit memory access generally has a bigger penalty than an even unaligned 32 bit memory access on the 32 bit 68020+. Also, unaligned reads are cheaper than writes and the 68040 and 68060 have less penalty than the 68020/68030 from what I recall. Even if unaligned accesses are handled efficiently, it's still possible to cause 2 cache lines to be accessed on the 68030+. Reading a stream (post-increment or pre-decrement addressing modes) will usually only trigger 1 cache line access at a time like in this example. If taking the penalty is faster, then the unaligned access will probably be used. The penalty calculation can vary from one 68k CPU to the next, the memory caching type, the memory speed, whether the access is a read or write and how unaligned the access is. I guess that's reason enough to try and keep as good of alignment as is reasonable.
a 'move.l ($...1),dn' and a 'move.l ($...2),dn' with 32-bit memory should have the same speed on 68020-60, requires two memory accesses in both cases
Wepl is offline  
Old 11 April 2014, 20:27   #16
matthey
Banned
 
Join Date: Jan 2010
Location: Kansas
Posts: 1,284
Quote:
Originally Posted by Wepl View Post
a 'move.l ($...1),dn' and a 'move.l ($...2),dn' with 32-bit memory should have the same speed on 68020-60, requires two memory accesses in both cases
I believe this is true for copyback cached memory but not necessarily true for writethrough or non-cacheable memory. Even the 68040 and 68060 list this chart in the MC68040UM and MC68060UM:

Table 7-3. Memory Alignment Influence on
Noncachable and Writethrough Bus Cycles

Transfer Size | Number of Bus Cycles
-------------| $0* $1* $2* $3*
-------------------------
Instruction 1 N/A N/A N/A
Byte Operand 1 1 1 1
Word Operand 1 2 1 2
Long-Word Operand 1 3 2 3

*Where the byte offset (A1 and A0) equals this encoding.

It appears that an odd address from a longword access can generate 3 bus cycles while an unaligned even address would only generate 2. The 68020 has no data cache so perhaps it feels this pain more? The 68060 appears to use the store buffer to help with some writethrough and non-cacheable (imprecise?) misaligned accesses. The MC68060UM later states the penalty for writethrough as the same as copyback:

Quote:
Originally Posted by MC68060UM
All data accesses are assumed to be aligned on the same byte boundary as the operand size:

o 16-bit operands aligned on 0-modulo-2 addresses
o 32-bit operands aligned on 0-modulo-4 addresses
o 64-bit operands aligned on 0-modulo-8 addresses
o 96-bit operands aligned on 0-modulo-4 addresses

If the operand alignment fails these suggested guidelines, the reference is termed a misaligned access. The processor is required to make multiple accesses to obtain any misaligned operand. For copyback or writethrough pages, one processor clock cycle must be added to the instruction execution time for a misaligned read reference. Two clock cycles must be added for a misaligned write or read-modify-write.
It's as clear as mud to me. I'm not a hardware guy. I do try my best to keep my data and memory accesses aligned, especially on writes, but I don't hesitate to do an unaligned access where it's faster either. I would love to hear a hardware expert explain all this .
matthey is offline  
Old 11 April 2014, 21:31   #17
Wepl
Moderator
Wepl's Avatar
 
Join Date: Nov 2001
Location: Germany
Posts: 760
I wanted to emphasis on that 'move.l ($...2),dn' is also a misaligned transfer.
Yes, for writes to non copyback memory a 'move.l dn,($...1)' will need 3 transfers.
All the above examples were reads. As long you have a data cache (30-60) and the memory is cacheable the both misaligned accesses in my example should take the same amount of cycles I think.
I agree totally that alignment should be considered (especially when writing to chip mem)
Wepl is offline  
Old 11 April 2014, 22:44   #18
Mrs Beanbag
Glastonbridge Software
Mrs Beanbag's Avatar
 
Join Date: Jan 2012
Location: Edinburgh/Scotland
Posts: 2,202
Quote:
Originally Posted by Thorham View Post
Why?
I dunno, odd accesses just seem inconsiderate.

Read four pixels:
Code:
movem.l (A0)+,D0-D2
move.l D2,D3
move.w D1,D2
move.b D0,D1
lsr.l #8,D0
rol.l #8,D2
swap D1
Mrs Beanbag is offline  
Old 12 April 2014, 01:09   #19
Thorham
Computer Nerd

Thorham's Avatar
 
Join Date: Sep 2007
Location: Rotterdam/Netherlands
Age: 44
Posts: 3,216
Quote:
Originally Posted by Mrs Beanbag View Post
I dunno, odd accesses just seem inconsiderate.
What do you mean by inconsiderate?

Quote:
Originally Posted by Mrs Beanbag View Post
Read four pixels:
Code:
movem.l (A0)+,D0-D2
move.l D2,D3
move.w D1,D2
move.b D0,D1
lsr.l #8,D0
rol.l #8,D2
swap D1
That's still not faster on a 68030 (probably 68020 too), and movem.l is slower than three times move.l. With the movem.l replaced, it's still around 1.25 cycles slower than just reading unaligned.

With this alignment crap you really have to run some speed tests. I must admit that I didn't do that before this thread
Thorham is offline  
 


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
68000 code optimisations pmc Coders. Asm / Hardware 198 12 December 2020 18:03
68000 & 68020 comparaison ? (for GhostsNGhosts temporary freeze) CFOU! Coders. Asm / Hardware 7 20 February 2013 11:35
68000 boot code billt Coders. General 15 05 May 2012 20:13
"16-32BIT Microprocessors: 68000/68010/68020" RedskullDC Coders. General 5 21 June 2008 23:59
PhxAss 4.42 AmiGer Coders. General 1 15 October 2004 08:07

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 04:54.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2021, vBulletin Solutions Inc.
Page generated in 0.09655 seconds with 13 queries