assemblers accepting faulty code

[meynaf]

Look at this :

 beq.b .truc-1
.truc

Not nice, i agree.
While Devpac3 rightfully (?) rejects this, AsmOne (1.48), PhxAss (4.44) and VAsm (1.7e) all accept it without a warning and assemble to wrong opcode $67FF !
So yes in some way this will work on 68000 : conditional crash with address error (i.e. some kind of 68000-compatible trapcc). But for 68020+ - which is what i've setup these asms for - you're up for a very bad surprise...

Makes me wonder what the 'right' reaction of an asm facing that should be. Probably not emitting single $67ff even in 020+ modes. But turning -1 to +1 would lead to $6701 and this could eventually be valid.

I'm telling, because some asms (at least VAsm) are currently maintained. Oh, and sorry if that's already fixed.

[a/b]

It should be rejected. For that kind of "trickery" there is DC[.B|.W].

[ross]

Confirmed in vasm 1.8k
phx will fix this in no time (at least with a warning, but better an error).

I second a/b, this trickery is for dc stuff.

[jotd]

branching to a label + an offset is very bad practice BTW

[phx]

I decided to report it as an error for 68020+ CPUs. Otherwise it goes without a warning, like other odd branches.

Patch will be available with tomorrow's source snapshot.

--- cpus/m68k/cpu.c     27 Apr 2021 14:45:24 -0000      1.253
+++ cpus/m68k/cpu.c     5 May 2021 15:27:29 -0000
@@ -4353,7 +4353,8 @@
     switch (ext) {
       case 'b':
       case 's':
-        if (diff>=-0x80 && diff<=0x7f && diff!=0)
+        if (diff>=-0x80 && diff<=0x7f && diff!=0 && (diff!=-1 ||
+            !(cpu_type & (m68020up|cpu32|mcfb|mcfc|m68881|m68882|m68851))))
           *(d-1) = diff & 0xff;
         else
           cpu_error(28);  /* branch destination out of range */

[ross]

Ok, for the interested I've uploaded to The Zone! a fresh vasm compile:
vasmm68k_mot v1.8k daily snapshot 06-May-2021, x86_64-posix-seh-gcc-11.1.0

vasm 1.8k (c) in 2002-2021 Volker Barthelmann
vasm M68k/CPU32/ColdFire cpu backend 2.3o (c) 2002-2021 Frank Wille
vasm motorola syntax module 3.15a (c) 2002-2021 Frank Wille

Thanks phx!

[kamelito]

cheers

[DevpacDude]

I remember a long time ago Devpac assembled one of the EOR opcodes wrongly. However, I didn't notice for a long time because it disassembled just fine. Of course I misread the docs the same way for both GenAm and MonAm, so put the same bug in both products.
After a long time someone actually noticed and I fixed it in both places.

This was of course decades before test cases were a thing. To test GenAm I used it to assemble itself and compare the binary with the version assembled with the previous version.

[phx]

Indeed, it's always good to have the source of some complex applications, which you can assemble and compare. But that's never enough.

What I'm doing additionally, to test the m68k backend of vasm before a release, is to reassemble various programs (like Kickstart 1.3, AmigaBASIC, games, demos, drivers, etc.). Then assemble the reassembler's output with vasmm68k and reassemble the generated binary again. The output of both reassembler runs have to match. This can be automated easily.