05 May 2021, 09:39 | #1 |
son of 68k
Join Date: Nov 2007
Location: Lyon / France
Age: 51
Posts: 5,323
|
assemblers accepting faulty code
Look at this :
Code:
beq.b .truc-1 .truc 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. |
05 May 2021, 10:50 | #2 |
Registered User
Join Date: Jun 2016
Location: europe
Posts: 1,039
|
It should be rejected. For that kind of "trickery" there is DC[.B|.W].
|
05 May 2021, 11:05 | #3 |
Defendit numerus
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 53
Posts: 4,468
|
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. |
05 May 2021, 13:13 | #4 |
This cat is no more
Join Date: Dec 2004
Location: FRANCE
Age: 52
Posts: 8,162
|
branching to a label + an offset is very bad practice BTW
|
05 May 2021, 17:37 | #5 |
Natteravn
Join Date: Nov 2009
Location: Herford / Germany
Posts: 2,496
|
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. Code:
--- 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 */ |
06 May 2021, 13:23 | #6 |
Defendit numerus
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 53
Posts: 4,468
|
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! |
06 May 2021, 19:22 | #7 |
Zone Friend
Join Date: May 2006
Location: France
Posts: 1,801
|
cheers
|
21 August 2021, 16:15 | #8 |
Registered User
Join Date: Aug 2021
Location: Kirkland, WA, USA
Posts: 3
|
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. |
21 August 2021, 21:43 | #9 |
Natteravn
Join Date: Nov 2009
Location: Herford / Germany
Posts: 2,496
|
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. |
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Include file path priorities for assemblers | phx | Coders. General | 20 | 07 July 2020 16:30 |
assemblers LOAD & ORG directives | jotd | Coders. Asm / Hardware | 4 | 26 January 2020 16:00 |
Hi and thanks for accepting my membership | somacast | Member Introductions | 24 | 08 December 2019 08:23 |
Macro68k compatible cross assemblers | kamelito | Coders. Asm / Hardware | 3 | 28 October 2015 10:38 |
DCE accepting Accelerators for repair? | majsta | Amiga scene | 2 | 21 September 2012 21:32 |
|
|