# How did the Motorola 68000 handle instructions on 32-bit data?

The Motorola 68k, despite its 16-bit external bus, had 32-bit data and address registers, with support for .L-width instructions over four bytes -- which is 32 bits in this case.

I figure that this would be done in the space of two cycles, but I'd like to know some details about how this is executed; specifically, things like:

• Whether externally-loaded data is staged in some intermediate storage before the instruction that requested it is executed

• Whether there's even a general execution model for 32-bit data on the 68k, or whether the execution model differs between instructions

• Get datasheet. Read datasheet. Bus cycles will be shown and everything will make sense. Take a look at the discussions on move byte, move word, and move long. Seriously. It's all in the datasheet. You may note that there is also a 68008 with an 8 bit bus, too. – jonk Nov 3 '17 at 20:55
• I wonder whether the ISA put rules or guarantees on those at all. – user3528438 Nov 3 '17 at 21:00
• You might want to consider moving this to retrocomputing.stackexchange.com if you don't get anything good here. I think it would be on topic there as well. – pipe Nov 3 '17 at 21:09
• @pipe thanks for the suggestion, I hadn't considered that SE. I'll leave it up here for another hour or so before asking a mod to move it, if that's fine with the EE.SE community. – Jules Nov 3 '17 at 21:11

The 68000 processor has a rather orthogonal and powerful instruction set with core instructions supporting different addressing modes (direct to/from register, indirect with address register with and without index etc.) and working on either 8, 16 or 32 bit of data. Address calculations of the addressing modes are always 32 bit.

The data bus of 16 bit is only relevant when external memory is read or written. The data sheet contains a lot of information about how many reads and writes occur given an instruction and its address mode.

A simplified view is:

• 16 bit reads and writes are easy as they directly match the data bus width.
• 32 bit reads and writes require two reads / two writes on the bus. The data sheet doesn't say in which order they occur.
• For 8 bit reads and writes, the processor indicates on a pin if the upper or lower byte should be read.

When multiple reads are required, the instruction is not executed until all the reads have completed. So from a programmer's view, you don't ever see that the bus is only 16 bit (or 8 bit for the 68008). The programming model is simple and consistent. The same goes for writes and 8 bit operations.

Only a partial answer because I don't have all of them.

First a comment on this statement: "I figure that this would be done in the space of two cycles".

Actually, every single bus access consists of 8 "states", each state being either the positive or negative part of the main clock. Thus, a single bus cycle is always 4 clock cycles. (This annoys me more than it should, but that's another story.) You probably know this if you're asking these questions but it doesn't hurt stating it.

Each data type is stored in memory as shown in Figure 2-6. The numbers indicate the order of accessing the data from the processor.

...or is it? Now, that figure is a little confusing to me, but as far as I can interpret it, integers are always read from memory beginning at the lower address.

### Intermediate Storage

I could not find any documentation about this, but I will take my chances and make a guess: I don't think so.

Take for example the arguably simplest instruction, AND.W (A0),D0 vs. AND.L (A0),D0. The 16-bit version takes 4 cycles for reading the single instruction word, and 4 cycles more for the (A0) effective address, which is simply another 16-bit read, for a total of 8 cycles.

The 32-bit version specifies 6 cycles: 4 to read the instruction, 2 extra "unknown" cycles, and 4 cycles to read the 16-bit data, a total of 10 cycles.

I don't know why but to me this indicates that the ALU is processing the 16 bits of data one after the other, with some extra time necessary to shuffle everything. This invisible shuffling would not be necessary if it had a buffer. Maybe this does not make sense when I read it again.

### Execution Model

The execution model does not seem to be documented. For word-sized operands, execution is "hidden" in the operand read cycle. The only hint I can find in the documentation is section 5.1.3 Read-Modify-Write Cycle. The state information shows:

STATES 8-11
The bus signals are unaltered during S8-S11, during which the arithmetic logic unit makes appropriate modifications to the data.

Four states equals 2 clock cycles.