Assembler that generates all M68k opcodes
 

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?

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! :)

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.

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.

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

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.

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

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.

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. 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: 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. I hadn't noticed. Good to know.

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


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?

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.

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.

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