Re: Split instruction and immediate stream

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