Assembler that generates all M68k opcodes

[TheDarkCoder]

Hello, for curiosity and for the sake of explanation of the relationship between assembly language and machine code, I would like to know if there are Amiga assemblers that allow to generate all m68k opcodes.

It seems to me that ASM-One (at least v 1.4x) does not generate some of them, for instance ADD #im, Dx (ASM-One "optimize" it with ADDI #im, Dx).

What about PhxAss, Devpac, vasm?

[StingRay]

Originally Posted by TheDarkCoder

It seems to me that ASM-One (at least v 1.4x) does not generate some of them, for instance ADD #im, Dx (ASM-One "optimize" it with ADDI #im, Dx).

It's the other way 'round, ASM-One allows you to write the less strict add #im,x instruction (which does not exist) and automatically translates it to the correct addi instruction. It is not any kind of optimisation, it actually is just support for lazy coders!

[Leffmann]

Originally Posted by TheDarkCoder

Hello, for curiosity and for the sake of explanation of the relationship between assembly language and machine code, I would like to know if there are Amiga assemblers that allow to generate all m68k opcodes.

It seems to me that ASM-One (at least v 1.4x) does not generate some of them, for instance ADD #im, Dx (ASM-One "optimize" it with ADDI #im, Dx).

What about PhxAss, Devpac, vasm?

I don't know if vasm honors all instructions like this, but it does encode both ADD #Im,Dx and ADDI #Im,Dx correctly, so it's worth taking a look.

[StingRay]

Originally Posted by Leffmann

but it does encode both ADD #Im,Dx and ADDI #Im,Dx correctly

ADD #IM,DX = ADDI #IM,DX

Strictly speaking, ADD #IM,DX is not a valid instruction (i.e. does not exist) but most assemblers handle it automatically since it is clear that an immediate value should be added.

[thor]

Originally Posted by StingRay

Strictly speaking, ADD #IM,DX is not a valid instruction (i.e. does not exist) but most assemblers handle it automatically since it is clear that an immediate value should be added.

ADD.W #$1234,D0 -> D07C 1234
ADDI.W #$1234,D0 -> 0640 1234

If destination is a data register then there is ADD #IM,Dx AFAIK

[StingRay]

You are correct, add.x #IM,Dx is indeed allowed, I checked the reference manual. It's somewhat ambiguous though IMHO.

[TheDarkCoder]

Originally Posted by StingRay

You are correct, add.x #IM,Dx is indeed allowed, I checked the reference manual. It's somewhat ambiguous though IMHO.

yeah, before digging into this issue (just for the sake of explaining ASM, not becose I needed) I also believed that the very dense m68k instruction encoding did not have redundand opcodes.
Indeed, the only redundancies I have discovered up to now, are all related to the xxxI variants using a data register as destination operand:
ADD # , Dx / ADDI # , Dx
SUB # , Dx / SUBI # , Dx
CMP # , Dx / CMPI # , Dx.
AND# , Dx / ANDI # , Dx.
OR # , Dx / ORI # , Dx.

In contrast, there are no redundancied between ADD/ADDA, SUB/SUBA, etc.

Well, another one is that you can use MOVEM to copy just 1 register, but I regard this as anavoidable.

Please, let me know if you know others.

[TheDarkCoder]

Originally Posted by Leffmann

I don't know if vasm honors all instructions like this, but it does encode both ADD #Im,Dx and ADDI #Im,Dx correctly, so it's worth taking a look.

Let's see if Frank Wille is willing to give a qualified answer!

[phx]

Originally Posted by Leffmann

I don't know if vasm honors all instructions like this, but it does encode both ADD #Im,Dx and ADDI #Im,Dx correctly, so it's worth taking a look.

I can only guarantee that I tried my best to support all of them. When I missed something, tell me, and I fix it in a few minutes. It was important to me to differentiate between ADD and ADDI, because I wanted to make sure vasm works well with reassemblers and generates identical code.

Vasm's 68k backend supports all known 68000-68060, 68851, 6888x, CPU32 and ColdFire V2-V4e instructions.

I remember just one ambiguous instruction: PFLUSHA. It exists for 68030, 68851, 68040 and 68060. The 68040/060 version has a different opcode, so the resulting code depends on the current cpu options.

[matthey]

Originally Posted by TheDarkCoder

In contrast, there are no redundancies between ADD/ADDA, SUB/SUBA, etc. Well, another one is that you can use MOVEM to copy just 1 register, but I regard this as unavoidable. Please, let me know if you know others.

Another "redundancy" is ASL and LSL. It would have been easy enough to have the assembler use an alias for ASL that encodes an LSL.

Originally Posted by phx

I can only guarantee that I tried my best to support all of them. When I missed something, tell me, and I fix it in a few minutes. It was important to me to differentiate between ADD and ADDI, because I wanted to make sure vasm works well with reassemblers and generates identical code.

Vasm works great for reassembling code and I wouldn't change a thing. However, the M68000PRM has a note after the ADD instruction that says:

ADDA is used when the destination is an address register. ADDI and ADDQ are used when the source is immediate data. Most assemblers automatically make this distinction.

It doesn't say that assemblers "should" make the distinction so I guess vasm is ok . It does sound like Motorola intended assemblers to convert ADD #,Dn to ADDI #,Dn though. ADD #,Dn is supported by all 68k processors and was generated by some 68k assemblers so it can't be removed now. I think it's safe enough to use it in vasm with the advantage of more accurate reassembled code.

Originally Posted by phx

I remember just one ambiguous instruction: PFLUSHA. It exists for 68030, 68851, 68040 and 68060. The 68040/060 version has a different opcode, so the resulting code depends on the current cpu options.

I hadn't noticed. Good to know.

[TheDarkCoder]

Originally Posted by matthey

Another "redundancy" is ASL and LSL. It would have been easy enough to have the assembler use an alias for ASL that encodes an LSL.

As you probably know, (but let's state it for the beginners ) ASL and LSL are different in the way they affect the V flag.
I agree that it's almost useless to have both, but what I mean with the term "redundant" instruction is two different opcodes that have exactly the same semantics, for whatever values of the operands.

I agree on your comment

Originally Posted by phx

I can only guarantee that I tried my best to support all of them. When I missed something, tell me, and I fix it in a few minutes. It was important to me to differentiate between ADD and ADDI, because I wanted to make sure vasm works well with reassemblers and generates identical code.

Vasm's 68k backend supports all known 68000-68060, 68851, 6888x, CPU32 and ColdFire V2-V4e instructions.

I remember just one ambiguous instruction: PFLUSHA. It exists for 68030, 68851, 68040 and 68060. The 68040/060 version has a different opcode, so the resulting code depends on the current cpu options.

thanks phx, that's what I wanted to know, I really like the choice of supporting all instructions.
Has PhxAss the same behavior, if you remember?

[phx]

Originally Posted by TheDarkCoder

I really like the choice of supporting all instructions.

BTW, although vasm differentiates between ADD and ADDI it will still translate ADD silently into ADDI, but only then when the addressing mode doesn't exist for ADD.

Originally Posted by TheDarkCoder

Has PhxAss the same behavior, if you remember?

It's a long time ago. But from looking at the source it seems so.
It was probably also required because of reassembling. I worked closely together with Tim Rühsen in the mid-90s, who based his IRA reassembler on PhxAss.

[TheDarkCoder]

Originally Posted by phx

BTW, although vasm differentiates between ADD and ADDI it will still translate ADD silently into ADDI, but only then when the addressing mode doesn't exist for ADD.

ok, that's fine.
Thanks again for the info!