Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: BGB <cr88192@gmail.com>
Newsgroups: comp.arch
Subject: Re: Split instruction and immediate stream
Date: Sun, 9 Mar 2025 03:44:38 -0500
Organization: A noiseless patient Spider
Lines: 75
Message-ID: <vqjkg0$l64n$1@dont-email.me>
References: <vqhjpv$65am$1@dont-email.me> <vqiikd$c35o$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 09:45:54 +0100 (CET)
Injection-Info: dont-email.me; posting-host="3e2dcc3f4de19925a2c8a9285e1c9832";
	logging-data="694423"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/QulhHbZduCcauOJPYNNccE2/5nLkE9QA="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:OCXTA/GEjLgP6gyXkfUuuSmGdqc=
In-Reply-To: <vqiikd$c35o$1@dont-email.me>
Content-Language: en-US
Bytes: 3963

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


>