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.

[paraj]

Originally Posted by phx

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

Should have perhaps written that a good disassembler has an option to do so Of course it really depends on what you're trying to do with the disassembly, and while reassembly should be possible, it's probably not the most common use case. If I'm using it for whdload stuff, "-A" and having the "logical instruction" is probably what I want. (

dc.w ... ; ori.b #$34,d1

might 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,d0

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

[hop]

Originally Posted by phx

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


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.

Thanks very much. I'll try these out. I've been blindly using

COMPAT=BI

without thinking about what it was doing.