Re: Split instruction and immediate stream

On 3/8/2025 5:07 PM, Robert Finch wrote:

On 2025-03-08 9:21 a.m., Thomas Koenig wrote:

There was a recent post to the gcc mailing list which showed
interesting concept of dealing with large constants in an ISA:
Splitting a the instruction and constant stream.  It can be found
at https://github.com/michaeljclark/glyph/ , and is named "glyph".
>
I think the problem the author is trying to solve is better addressed by
My 66000 (and I would absolutely _hate_ to write an assembler for it).
Still, I thought it worth mentioning.

 Found that post interesting.
 As outlined, the immediate base register requires a double-wide link register. This may be okay for code with 32b addresses running in a 64- bit machine. But otherwise would probably need to go through another GPR to manage the immediate base register. It is potentially more instructions in the function prolog / epilog code. And more instructions at function call.
 I think splitting the code and constant into separate streams requires another port(s) on the I$. The port may already be present if jump- through-table, JTT, is supported.
 

I found a few of the ideas questionable at best...
Possibly an IB like use-case could be handled instead by just using it as a dedicated base register for constant loads. But, this would have similar latency to a traditional constant pool (which also sucks).
But, if it is directly loaded inline, this could add extra complexity and delay to the pipeline.
It almost seems like a case of "what if we took a constant pool, and made it worse...".
Or, if a constant pool does have a strong enough use-case (say, one wants fixed-length 16-bit ops), maybe treat it like a constant pool but have a few special case helper ops.
Say, 16-bit ops:
   MOV.L @IB+, Rn   //load and advance 4 bytes
   MOV.Q @IB+, Rn   //load and advance 8 bytes
   MOV.L (IB, Disp4n*4), Rn
   MOV.Q (IB, Disp4n*4), Rn
Where, the displacement is negative to allow repeating a recently seen prior value.
With the usual caveats of supporting auto-increment.

I guess that the constant tables for a subroutine would be placed either before or after a subroutine. I would not use the constant tables for all constants. Small constants are better encoded directly in the instruction. That means using bits to select between small constants or relative addresses.
 I think it is better to use a constant prefix / postfix instruction to encode larger constants in the instruction stream. Or use a wider instruction format. In Q+ constant postfixes can be used to override a register spec, allowing immediate constants to be used with many more instructions.
 

Agree...
If one is already going to have a variable length encoding, why not make it have decent inline immediate fields?...