Disassembling/executing instructions with unused bits

[hop]

How does the 68000 decode instructions with unused bits? Is this well-defined or undefined behaviour?

For example

ORI.B $#ff,D1

assembles 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.

[paraj]

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)

[jimshaw]

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.

[hop]

Thanks for the great advice. The reassembly is just what caught me out.

[hop]

A solution might be to ensure that the disassembler disassembles

0001 1234

to

ORI.B #$1234,D1

and the assembler assembles this back to

0001 1234

. This avoids

DC

directives which obfuscate how the CPU would decode the machine code.

[kamelito]

Is this instructions or data’s that the disassembler set as instructions ? Sometimes its not code and should be set as dc.x

[phx]

Originally Posted by paraj

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)

Yes, that's what IRA is doing by default.
But currently

-compat=i

would output

ORI.B #$34,D1

and masks out the upper byte (because otherwise assemblers may complain).

Originally Posted by hop

A solution might be to ensure that the disassembler disassembles

0001 1234

to

ORI.B #$1234,D1

and the assembler assembles this back to

0001 1234

. This avoids

DC

directives which obfuscate how the CPU would decode the machine code.

You may try the following patch for IRA:

--- 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));
                         }
                      }
                }

And the following patch for vasm:

--- 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 */

And try if it works for all situations. You will need

-no-typechk

or

-rangewarnings

with vasm to avoid error messages due to range-checking.