Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: Robert Finch <robfi680@gmail.com>
Newsgroups: comp.arch
Subject: Re: Split instruction and immediate stream
Date: Sun, 9 Mar 2025 08:03:22 -0400
Organization: A noiseless patient Spider
Lines: 86
Message-ID: <vqk02b$n4o8$1@dont-email.me>
References: <vqhjpv$65am$1@dont-email.me> <vqiikd$c35o$1@dont-email.me>
 <vqjkg0$l64n$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sun, 09 Mar 2025 13:03:23 +0100 (CET)
Injection-Info: dont-email.me; posting-host="b2e2a670c6c37b7ac6bf664132202f6b";
	logging-data="758536"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19TGSnICS5Y51XATHFCjI+KMuY1q6P7okI="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:iYoHEM2eElnj33XIAiFoGOCcAck=
In-Reply-To: <vqjkg0$l64n$1@dont-email.me>
Content-Language: en-US
Bytes: 4708

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.