From: cr88192@gmail.com
On 12/19/2025 5:36 PM, MitchAlsup wrote:
>
> BGB posted:
>
>> On 12/18/2025 4:25 PM, Anton Ertl wrote:
>>> John Savard writes:
>>>> Given the great popularity of the RISC architecture, I assumed that one of
>>>> its characteristics, instructions that are all 32 bits in length, produced
>>>> a great increase in efficiency over variable-length instructions.
>>>
>>> Some RISCs have that, some RISCs have two instruction lengths: 16 bits
>>> and 32 bits: IIRC one variant of the IBM 801 (inherited by the ROMP,
>>> but then eliminated in Power), one variant of Berkeley RISC, ARM T32,
>>> RISC-V with the C extension, and probably others.
>>>
>>
>> I have come to realize that 32/64 is probably better than 16/32 here,
>> primarily in terms of performance, but also helps with code-density (a
>> pure 32/64 encoding scheme can beat 16/32 in terms of code-density
>> despite only having larger instructions available).
>
> My 66000 does not even bother with 16-bit instructions--and still ends
> up requiring fewer instruction count than RISC-V. {32, 64, 96, 128, 160}
> are the instruction sizes; with no instructions ever requiring constants
> to be assembled.
>
This is one area where my JX thing saves:
Greatly reduces cases that need constants to be assembled.
Doesn't eliminate it, partly because of an issue where JX runs out of
encoding bits before being able to encode a 64-bit constant, and the
space for constants (falling just short of 64 bits) is far less useful
(because there is a big gulf of very few constants between 33 and 62 bits).
XG3 does allow full 64-bit constants though.
Have come up with a possible encoding scheme to add 64-bit constants to
RISC-V using 96-bit encodings (using a different encoding scheme from my
original JX design).
Have started floating ideas for how to go further within the context of
the RISC-V encoding space:
96-bit encodings to add Imm64 forms;
And some Disp64/Abs64 encodings.
My CPU core wouldn't necessarily actually support Disp64, but Abs64
could have some use-cases.
I could have reason to consider adding an Abs64 special case in both
RV64G+JX and XG3. Most likely, the Disp64 encoding would be decoded, but
would likely just misbehave if the displacement is larger than +/- 4GB
(unless the optional feature to allow Disp48 addressing is enabled).
The bigger incentive ATM would be to allow for Abs64 branches, as this
could encode direct calls and branches between RV64GC+JX mode and XG3.
Granted, would still not address the deficiencies in standard RV64G and
RV64GC.
>> One could argue "But MOV is less space efficient", can note that it also
>> makes sense to try to design the compiler to minimize the number of
>> unnecessary MOV instructions and similar (and when using the minimal
>> number of register moves, the lack of a small MOV encoding has less
>> effect on code density).
>
> Most of the MOV instructions in My 66000 are found::
> a) before a call--moving values to argument positions,
> b) after a call--moving results to post-call positions,
> c) around loops --moving values for next loop iteration.
>
Kinda similar.
Some of these can be reduced in the register allocator, but some amount
are unavoidable.
Either way, when 2R MOV stops being one of the most common instructions,
the incentive for reducing its size goes down; as does the clock cycles
spent moving values from one register to another.
>> 16/32/64 is also sensible, but the existence of 16-bit ops negatively
>> effects encoding space (it is more of a strain to have both 16-bit ops
>> and 6-bit register fields; but at least some code can benefit from
>> having 64 GPRs).
>
> I agree than RISC-V HAS too many 16-bit instructions, and that it gains
> too little in the code density department by having them.
>
Pretty much.
When used, XG1's 16-bit encoding can see a higher percentage of 16-bit
ops than RISC-V's, and is less dog chewed.
Technically, its listing is bigger than RV-C, but this is partly because
the 16-bit ops in what I now call XG1, were the original form of this
ISA (it started out 16-bit, then became 16/32, and then started to
evolve away from the use of 16-bit encodings).
Well, part of this was because earlier on in the ISA's development, I
ended up with the 16-bit ISA, which then grew a bunch of 32-bit
encodings. I ended up doing a test comparing 16-bit only, 16/32, and
32-bit only variants.
Result was, basically:
16/32: Best code density, good performance;
32 Only: Worse code density, best performance;
16 Only: Medium code density, worst performance.
16/32 won this round, but 16-bit only basically died. There was no
reason to have an ISA variant that was only meh for code density and
sucked for performance. This model was programmed in basically the same
way as its SuperH ancestors, but the benefit of having instructions that
were half the size was reduced when (on average) one needs around 60-70%
more of them to do the same amount of work.
I realized that if a fixed-length subset were used, a 32-bit-only subset
was a much better bet. At the time, it still only had 32 registers, but
a 32-bit only subset could much more aggressively use these registers
(whereas, 16/32 needed to use R16..R31 sparingly; and 16-bit only mostly
only had the first 16 registers).
But, that said, something more like the 16-bit instructions from SuperH
would still (on average) beat the crap out of the RISC-V 'C' encodings.
A lot could be left out though. One of the major drawbacks of RV-C isn't
so much what instructions it has or doesn't have, so much as that it is
effectively crippled by most of what instructions it does have, use
3-bit register fields. And, Reg3 is lacking in callee-saved registers,
meaning many of the instructions are effectively only really usable in
leaf functions or similar.
Well, and then from there, later felt a need to expand the register space:
I considered two ideas at first:
The first idea, initially rejected, was to drop the 16-bit encodings and
expand everything to 64 GPRs;
Second idea was to mirror part of the the 32-bit encoding space but
expanded to 64 GPRs (keeping the original ISA as is).
The first idea was later revived under the name of XG2, and then the
original form was later renamed to XG1 (ironically, as a backronym from
XG2, which originally meant XGPR2, or the second design attempt at
expanding the ISA to 64 GPRs).
Though, annoyingly, XG2 didn't fully replace XG1, much as XG3 hasn't
fully replaced either XG1 or XG2.
Well, and now I am left with a situation:
[continued in next message]
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
