Re: Split instruction and immediate stream

On 2025-03-09 4:44 a.m., BGB wrote:

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

>

 

One thought I had a while ago using a similar technique to glyph's was to place constants at the beginning or the end of a cache line. Then the immediate base register is not needed. The relative offsets would be in terms of the current cache line. It has a couple of drawbacks though, one being the need to branch around the constant data; could be done by carefully maintaining the next fetch address. Another drawback is the code is repositionable only at cache-line boundaries. Might make assembling / linking code interesting.