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 05:01:42 -0500
Organization: A noiseless patient Spider
Lines: 101
Message-ID: <vqjp0g$m0su$1@dont-email.me>
References: <vqhjpv$65am$1@dont-email.me>
 <c89e07f625546e34b17cbeb9fe3d7a0c@www.novabbs.org>
 <e0b069afe64f990a88fa574a2e9c87e8@www.novabbs.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sun, 09 Mar 2025 11:02:57 +0100 (CET)
Injection-Info: dont-email.me; posting-host="3e2dcc3f4de19925a2c8a9285e1c9832";
	logging-data="721822"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/yRKBl4rLsCoiC4roD+Y9++clawo1Vwk4="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:rCqMU8E+XQNeVA5hCypzKl/F4uk=
In-Reply-To: <e0b069afe64f990a88fa574a2e9c87e8@www.novabbs.org>
Content-Language: en-US
Bytes: 4261

On 3/8/2025 5:56 PM, MitchAlsup1 wrote:
> On Sat, 8 Mar 2025 17:53:34 +0000, MitchAlsup1 wrote:
> 
>> On Sat, 8 Mar 2025 14:21:51 +0000, 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 knew a guy with that name at AMD--he did microcode--and did it well.
>>
>>> 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.
>>
>> I took a quick look, and it seems that
>> a) too few registers
>> b) too many OpCode bits
>> although it does look easy to parse.
> 
> The length decode is wasteful of bits. There are 4 sizes of instructions
> 16, 32, 54, 128 denoted by the first halfword having (respectively)
> 00, 01, 10,  11. But successive halfwords contain 2-bits that simply
> waste entropy and could have been used for "other good stuff".
> 

This is why my "if doing something similar" idea, would to use 1 bit per 
16-bit word. Similar effect, less waste.


> 16-bit instructions get a 5-bit opcode, and the entire 32 instruction
> space is already fully populated.
> 

Yeah.

As can be noted, the design seemed poorly balanced IMO.


> 32-bit instructions get a 10-bit OpCode space. At this point I should
> note that my entire OpCode instruction space has only 62 instructions.
> 

10 bits seems reasonable at least.

Can note that if one were to have all of RISC-V as 3R ops, there would 
have been 15 bits of opcode...

Slightly less with 12-bit immediate values, but roughly break-even (in 
terms of entropy cost) with 10 bit immediate values with 6 bit registers.



Though, they managed to burn through most of it already.

IMHO, RISC-V was not particularly efficient with their use of encoding 
space. Not so much the core ISA, but more the extensions.



> 64-bit instructions get a 20-bit OpCode space. Nobody is going to need
> 1M individual instructions.
> 

Nobody is going to need 12-bit register fields either...


> So, a bit of rearrangement would provide for a healthy OpCode space
> and more bits for registers, and possibly a 96-bit instruction in-
> stead of a 128-bit instruction.
> 

32/64/96 works well.


Can note for 16-bit ops, that unless most of the ops are 16-bit, the 
savings are actually fairly modest.

If 40% of the ops become 16 bit, you save 20%; 60% of the ops saves 40%.

The question then becomes how much coverage can one get.

Or, if one saves maybe 10-20% on the size of ".text", if downsides are 
worth it.


> So, we are still missing::
> a) a memory order model
> b) a translation model
> c) atomic instructions
> d) external linkage {code and data}
> e) thread support using his {ip, bp) construct
> f) system call model
> g) debug model
> h) timers and counters
> i) floating point
> ..

Yeah...