TR3200 : Enforce align of 8 byte instructions (long literal instructions)

[Zardoz89]

Catageek suggested that long instructions, that uses 8 bytes (ie, instructions with long literals), must be enforced to be aligned to 8 byte boundary so pipe-lining could be more easy implemented. Also, could make more easy to implement a JIT cpu core with this change.

The side effects are :

• Assemblers should detect when a long instruction is not aligned, and insert a NOP before it to align it. This could arise clever tricks to gain a few cpu clocks changing the order that some instructions are in the assembly code.

• What do when a unaligned instruction is found. Actually we have this suggestions :

  • Ignore it, like a NOP and try to interpret the next dword as a instruction (ie the literal value).
  • Only detect long literal instructions if is a aligned instruction, so the big literal of a not aligned instruction will be interpreted like a instruction instead of a literal value.
  • Increase the CPU clock cost of not aligned instructions by 1 or 2. This sound nice, but keep the problem intact on the implementation side.
  • Issue a exception/trap interrupt (like the 680XX cpus). Were we can :
  • Reuse the interrupt 0x00000000 (step-mode) with a new flag on flag register for this case
  • Reserve 0xXXXX0000 interrupts for traps/exceptions, were 0x00000000 is for step mode, and 0x00010000 is align error.

  In both cases, we need a flag to active/deactive this exception. If is deactivate, we can ignore the instruction or "Only detect long literal instructions if is a aligned instruction, so the big literal of a not aligned instruction will be interpreted like a instruction instead of a literal value."

Additionally, we can add a penalty (+1 cycle) when a code try to read/write a word or dword not aligned to 4 byte boundary.

[milesrout]

We have two options, as I see it. We have the 'nice' option where we detect and add a slowdown cycle or something, and the same with unaligned loads and stores in general.

We also have the 'ruthless' option, where we just raise an illegal instruction exception - or some sort of 'illegal unaligned load or store' exception that we also use for normal unaligned loads and stores, e.g. LOAD %r0, 1.

[milesrout]

For the record, I totally support the 'ruthless' option where 8-byte instructions that are not 8-byte-aligned are always illegal, and unaligned loads and stores (LOAD %r0, 1) are also illegal.

[milesrout]

@catageek @Meisaka @Zardoz89 thoughts?

[catageek]

I agree about the unaligned code that should be illegal, but I don't understand why we should make illegal unaligned load. Is this justified by a possible limitation of a CPU ?

[milesrout]

The CPU just might not have the silicon to do unaligned loads and stores. The Alpha didn't, for example. The Alpha was a pretty weird architecture all things considered.

[Zardoz89]

unaligned load/store on real silicon with a 32 bit data bus, means that the CPU would need do two access to RAM to read/write stuff.

Also, depends on the size of the data to be load/stored :

• Byte -> No problem, on any address an byte never will need to do a double read/write
• Word -> No problem on 0 or 1 offset read/write, but a 3 offset read/write, would cross the boundary of 4 byte and would need an additional read/write
• DWord -> If it's not aligned to 4 boundary, it will need an additional read/write.

[Meisaka]

IMO, the entire 8 byte/64 bit alignment of instructions does not really seem to make sense in the context of 32 bit CPU, which would supposedly be accessing memory at most 32 bits a time. That seems like it would be more trouble to program around than just leaving it as is. I also think we should keep the unaligned load/store, that keeps the CPU simpler to use.

If either does get enforced, unaligned things should end up sending a CPU trap.

[Zardoz89]

I agree with Meisaka, that seems like it would be more trouble to program around than just leaving it as is. Also, it will introduce more "if"s to the cpu interpreter, and make a bit more harder to program at low level.