[Libre-soc-dev] Fwd: Why My 66000 is and is not RISC

[Luke Kenneth Casson Leighton]

the same analysis applies to alignment of any-width at at-double-width.
this discussion is on comp.arch.
https://groups.google.com/g/comp.arch/c/UvprSM9xJfM

l.

---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68


---------- Forwarded message ---------
From: BGB <cr88192 at gmail.com>
Date: Tue, Jul 5, 2022 at 12:14 AM
Subject: Re: Why My 66000 is and is not RISC
To:


On 7/4/2022 1:24 PM, Stefan Monnier wrote:
>> Was, IIRC:
>>    60% / 40%  (70% vs Fixed-32b)
>
> I assume this is with 32bit instructions that can be 16bit aligned, right?
>

Yes, in BJX2 all of the instructions (and bundles) have 16-bit
alignment, and 32-bit instructions are defined in terms of pairs of
16-bit words.

In my notation, F0nm_ZeoZ, the words are effectively transposed, so if
seen directly as a little endian DWORD, would be:
   ZeoZF0nm

Or, in bytes: nm_F0_oZ_Ze

There is also a funky bit-ordering effect, because bit-order is
effectively big endian in terms of the instruction words, but little
endian within the instruction words.



> If you impose 32bit alignment on 32bit instructions, how much worse does
> it get?
>

Significantly.

Crude estimate is that, for the 40% of 32-bit instructions, roughly half
would require converting the adjacent instruction to 32-bit, turning it
from 60/40 to around 40/60.

For speed-optimized code, it would nearly entirely knock 16-bit
encodings out of the picture.


This is assuming a fairly ad-hoc mix of 16 and 32-bit encodings.


There would be less impact if things were clustered into separate
instruction blocks (more like how Thumb worked on the ARM7T or similar);
or how it "would have worked" on the SH-5 (which would have been
basically "Sort of like MIPS but with 64 registers", *1).

*1: Not sure if SH-5 was effectively also another casualty of the
Itanic, either way, I think at the time Hitachi folded its CPU design
part out to Renesas, who were apparently much more invested in keeping
the SH2 and SH4 going.


I didn't really want to go this direction though.


I had at one point considered fixed-length 64 bit bundles, say:
   1x 60-bit (large instruction)
   2x 30-bit (medium instruction)
   3x 20-bit (small instruction)


But, as noted, didn't go this direction either:
When I later partially rebooted my BJX1 project into BJX2, I stayed with
a 16/32 instruction format (so, similar category as Thumb2 or RVC).

I did somewhat reorganize the encodings in an attempt to make things
more consistent (as by the end, the original BJX1 instruction encodings
had turned into an awful mess).

As can be noted, a fair chunk of the original parts were carried over
from one project to another.


> Also, if you impose 32bit alignment on 32bit instructions, you can look
> at it not as 16bit instructions but as 32bit "instruction pairs".
> At that point you might look at what kinds of pairs you're using, what
> kinds of pairs you're *not* using and what kind of additional pairs might
> be worth having instead.
> E.g. maybe it is better to make your pairs asymmetric (14bit + 18bit),
> e.g. to allow slightly larger offsets in short load instructions
> (assuming the size of the offset is a common reason for loads to be
> forced to use the long form rather than the short form).
>

Having 32-bit instruction words which could be split into a logical pair
of 16-bit instructions is effectively what ISA's like Qualcomm Hexagon
and similar did.