Re: Split instruction and immediate stream

Den 2025-03-23 kl. 04:06, skrev Robert Finch:

On 2025-03-22 11:04 a.m., Thomas Koenig wrote:

Marcus <m.delete@this.bitsnbites.eu> schrieb:
>

Then we have the page-crossing issue. Is it better to force the
compiler/assembler to align such instructions so that they never cross
page boundaries?

>
Power 10 chose to do so; actually, larger instructions cannot
cross a (likely) Cache line size there.  According to the Power
ISA Version 3.1, section 1.6:
>
"Prefixed instructions do not cross 64-byte instruction address
boundaries. When a prefixed instruction crosses a 64-byte boundary,
the system alignment error handler is invoked."

 In the latest test project, the LB650 similar to a PowerPC, large constants are encoded at the end of the cache line. So, there is a similar issue of code running into the constant area.
 I have the assembler moving the code that overlaps to the next cache line.
 It is confusing to look at listing files, as there are constants output inline with the code. Makes it look like the code should not work. How does it know where to go for the next instruction? Is the question that comes to mind.
 For now, the hardware decoder takes the cheezy approach of marking instructions fetched in the constant area as invalid. The constant area gets fetched and loaded into the pipeline, but as NOPs.
 It is quite a trick getting the assembler to place constants at the end of the cache line and generate references to the constants. It is interesting because I have *constants* being relocated by the assembler / linker. Normally there would not be a relocation associated with a constant. A relocation reference to the constant is spit out by the assembler, and the linker updates the index to the constant in the code.
 It does not quite work yet. Constants are placed and code is moved, but the linked program does not have the correct references yet.
 Experimental, but looking like things will work.
 

Although I have not tried any of these techniques, here are my thoughts.
Why not always place the constant next to (right after) the instruction
that references it, instead of at an offset within the cache line?
The effect should be very similar, but now you have a simpler offset
(it's always zero) and you eliminate the problem with having to keep
track of where the constants are in order to prevent the PC/IP from
running into the constant area.