68020 to 68000 code convertion using Ira and PhxAss

[gulliver]

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

[matthey]

Hi Gulliver,

Originally Posted by gulliver

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.

Originally Posted by gulliver

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.

[StingRay]

Originally Posted by gulliver

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?

[Mrs Beanbag]

Originally Posted by StingRay

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.

[StingRay]

Originally Posted by Mrs Beanbag

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.

Originally Posted by Mrs Beanbag

So you might get away with not worrying about that.

For 68020 to 68000 conversions this does have to be taken into account!

[Thorham]

Originally Posted by Mrs Beanbag

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:

    move.l  (a0),d0
    addq.l  #3,a0

[gulliver]

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

[amigoun]

It would be great to convert Dungeon Master 2 executable from 020+ to 000, to be able to run on Minimig..
Only just dreaming..

[Mrs Beanbag]

Originally Posted by StingRay

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.

Originally Posted by Thorham

What about reading 24bit pixels? If you want whole 24bit pixels in registers, then you do something like this:

    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:

    move.l (A0),D0
    addq.l #2,A0
    lsr.l #8,D0
    move.l (A0)+,D1

Originally Posted by gulliver

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?

[Thorham]

Originally Posted by Mrs Beanbag

but I'd bend over backwards to avoid odd addressing anyway.

Why?

Originally Posted by Mrs Beanbag

Read pixels in pairs:

    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.

[StingRay]

Originally Posted by Mrs Beanbag

Well for a general solution you need to take that into account

And that's what gulliver asked for, a general, automatic solution.

Originally Posted by Mrs Beanbag

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.

Originally Posted by Mrs Beanbag

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.

[matthey]

Originally Posted by Thorham

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.

[daxb]

Originally Posted by Mrs Beanbag

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.

[Thorham]

Originally Posted by matthey

On which 68k CPU?

68030 (Blizzard 1230 IV, 60ns RAM).

Originally Posted by matthey

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.

[Wepl]

Originally Posted by matthey

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

[matthey]

Originally Posted by Wepl

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:

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 .

[Wepl]

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)

[Mrs Beanbag]

Originally Posted by Thorham

Why?

I dunno, odd accesses just seem inconsiderate.

Read four pixels:

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

[Thorham]

Originally Posted by Mrs Beanbag

I dunno, odd accesses just seem inconsiderate.

What do you mean by inconsiderate?

Originally Posted by Mrs Beanbag

Read four pixels:

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