19 July 2024, 11:58 | #1 |
Registered User
Join Date: Apr 2019
Location: UK
Posts: 277
|
Disassembling/executing instructions with unused bits
How does the 68000 decode instructions with unused bits? Is this well-defined or undefined behaviour?
For example ORI.B $#ff,D1assembles to two words: 0001 00FF. The upper byte in the second word is not required to define the byte-sized instruction. What should happen if the CPU/disassembler/emulator encounters non-zero bits in there? For example: 0001 FFFF. Will the $ff00 bits in the second word simply be ignored (by the spec), or will the decoder class this as an illegal instruction. Sorry if this is in the manual - I couldn't find any information on it. Last edited by hop; 19 July 2024 at 11:59. Reason: Clarity |
19 July 2024, 13:54 | #2 |
Registered User
Join Date: Feb 2017
Location: Denmark
Posts: 1,281
|
The unused bits are just ignored (by all M68K versions), same with 000/010 and the previously unused bits in the extension word (scale/full extension word bit). The latter is at least documented (68000PRM 2.4).
An emulator should obviously behave the same way or it will fail on actual code. A good disassembler will reproduce the original instruction, i.e. preserve the unused bits. Otherwise you can't reassemble the same binary. Maybe via a dc.w sequence if the original instruction can't be accurately re-used in context (e.g. for the extension word thing) |
19 July 2024, 14:48 | #3 |
Registered User
Join Date: Apr 2021
Location: Sydney
Posts: 8
|
You'd have to tell a disassembler which cpu the code was intended for, else it won't know the right thing to do with bits that are undefined on 68000 and used for something new on the 68020 or later.
|
19 July 2024, 20:42 | #4 |
Registered User
Join Date: Apr 2019
Location: UK
Posts: 277
|
Thanks for the great advice. The reassembly is just what caught me out.
|
20 July 2024, 08:51 | #5 |
Registered User
Join Date: Apr 2019
Location: UK
Posts: 277
|
A solution might be to ensure that the disassembler disassembles
0001 1234to ORI.B #$1234,D1and the assembler assembles this back to 0001 1234. This avoids DCdirectives which obfuscate how the CPU would decode the machine code. |
20 July 2024, 12:03 | #6 |
Zone Friend
Join Date: May 2006
Location: France
Posts: 1,885
|
Is this instructions or data’s that the disassembler set as instructions ? Sometimes its not code and should be set as dc.x
|
20 July 2024, 13:25 | #7 | ||
Natteravn
Join Date: Nov 2009
Location: Herford / Germany
Posts: 2,568
|
Quote:
But currently -compat=iwould output ORI.B #$34,D1and masks out the upper byte (because otherwise assemblers may complain). Quote:
Code:
--- ira.c 30 Jun 2024 15:45:14 -0000 1.84 +++ ira.c 20 Jul 2024 11:28:03 -0000 @@ -2173,7 +2173,7 @@ else { adrcat("$"); - adrcat(itohex(buf & 0x00FF, 2)); + adrcat(itohex(buf & 0xFFFF, 2)); } } } Code:
--- cpus/m68k/cpu.c 24 Jun 2024 22:18:20 -0000 1.314 +++ cpus/m68k/cpu.c 20 Jul 2024 11:29:16 -0000 @@ -4879,10 +4879,15 @@ if (op->flags & FL_ExtVal0) { roffs++; rsize = 8; - *d++ = 0; - d = write_extval(0,1,db,d,op,rtype); - if (typechk && (op->extval[0]<-0x80 || op->extval[0]>0xff)) - cpu_error(36); /* immediate operand out of range */ + if (op->extval[0]<-0x80 || op->extval[0]>0xff) { + if (typechk) + cpu_error(36); /* immediate operand out of range */ + d = write_extval(0,2,db,d,op,rtype); + } + else { + *d++ = 0; + d = write_extval(0,1,db,d,op,rtype); + } } else cpu_error(37); /* immediate operand has illegal type */ -no-typechkor -rangewarningswith vasm to avoid error messages due to range-checking. Last edited by phx; 20 July 2024 at 13:31. |
||
20 July 2024, 20:21 | #8 | |
Registered User
Join Date: Feb 2017
Location: Denmark
Posts: 1,281
|
Quote:
dc.w ... ; ori.b #$34,d1might be "ideal" again depending on circumstances, but I would not waste much time on such corner cases) I seem to recall there was at least one assembler could for e.g move.b #-1,d0would output 103c ffff, but maybe I'm misremembering. Otherwise it doesn't pop up too often except in cases like kamelito mentions where data is being interpreted as code. |
|
21 July 2024, 10:25 | #9 | |
Registered User
Join Date: Apr 2019
Location: UK
Posts: 277
|
Quote:
COMPAT=BIwithout thinking about what it was doing. |
|
30 July 2024, 12:09 | #10 |
Natteravn
Join Date: Nov 2009
Location: Herford / Germany
Posts: 2,568
|
Are these modifications to IRA and vasm still needed? Or does somebody else think this is a good idea?
They are still sitting on my disk as local changes and I have to decide whether I commit or revert them. |
30 July 2024, 14:38 | #11 | |
Registered User
Join Date: Apr 2019
Location: UK
Posts: 277
|
Quote:
EDIT: The proposed change to ira doesn't seem to produce the results I was expecting. UnusedBits.cfg Code:
MACHINE 68000 ENTRY $00000000 OFFSET $00000000 CODE $00000000 - $00000004 END Code:
dc.w $0000,$0000 -Fbin, and disassembled with ira -a -config UnusedBitsproduces UnusedBits.asm Code:
ORG $0 SECSTRT_0: ORI.B #$00,D0 ;0: 00000000 END Code:
dc.w $0000,$0100 Code:
ORG $0 SECSTRT_0: DC.W $0000 ;0 BTST D0,D0 ;2: 0100 END Code:
ORG $0 SECSTRT_0: ORI.B #$0100,D0 ;0: 00000100 END Code:
dc.w $0000,$ff00 Code:
ORG $0 SECSTRT_0: DC.W $0000 ;0 DC.W $ff00 ;2 END I was expecting Code:
ORG $0 SECSTRT_0: ORI.B #$ff00,D0 ;0: 0000ff00 END Last edited by hop; 30 July 2024 at 16:33. |
|
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Bug? Black Unused Display | Zilog | support.WinUAE | 4 | 28 October 2020 21:11 |
HDD: Wipe (Zero) unused Blocks | bladecgn | support.Apps | 7 | 01 November 2018 16:01 |
Error when executing PGA Europe | 1time | project.WHDLoad | 1 | 25 March 2010 18:57 |
Selling some unused parts | McVenco | MarketPlace | 3 | 18 October 2008 15:16 |
Unused Connectors/Ports | BippyM | support.Hardware | 16 | 26 July 2006 13:56 |
|
|