Re: Byte Addressability And Beyond

On 5/5/2024 5:21 PM, MitchAlsup1 wrote:

BGB wrote:
 

On 5/5/2024 10:31 AM, Scott Lurndal wrote:

Thomas Koenig <tkoenig@netcologne.de> writes:

Scott Lurndal <scott@slp53.sl.home> schrieb:
>

 

Not as of yet in my case, but bitfield extract might happen eventually.
Issue is finding a way to pull it off that is useful and cheaper than shift+mask (and probably adding some mechanism to pattern-match it from the AST or similar).

 But, but but but:: it IS shift and Mask !!
 

Annoyingly, a good general case instruction could not be encoded in a 32-bit instruction form at this point (could either add a few special cases as 32-bit ops, or use a 64-bit encoding; or do it as a 2RI op rather than 3RI but this is lame...).

 

Then again, say:
   BITEXTR  Imm10, Rn  //Rn=(Rn>>(Imm&63))&((1<<((Imm>>6)&15))-1)
Could potentially still be useful.

      SL    Rd,Rc,<width:offset>
 Is a bit field extract instruction, it is also a smash instruction (smashing a 64-bit value into a 8-bit or 12-bit or 47 bit for whatever
purpose is needed)
      SR    Rd,Rc,<width:offset>
 Positions the value in a register (Rc) such that it fits the alignment of
a field.
      INS   Rd,Rc,Rf,<width:offset>
 Inserts the field from Rf into its position <w:o> in Rc, inserts the field and delivers the new container to Rd.
 

I would need a 64-bit encoding,

Also, some things don't seem well balanced in terms of cost, so while it would be fairly cheap for a microcontroller, by the time one implements enough extensions to make it more useful for general purpose computing, it will no longer be cheap (while at the same time shooting itself in the foot in terms of performance for imposing some design constraints that *only* make sense for small microcontrollers).

 We can put 64 GBOoO CPUs on a single die and you worry about the shifter
having a masker ?!?
 

I was thinking mostly of stuff RISC-V already has and doesn't have...
Say, RISC-V:
   Says yes to DIV and MOD;
   Says yes to 4-register floating-point multiple-accumulate;
   Say no to register-indexed Load/Store.
Me: This is not a good balance...
But, shift+mask could be added, more an issue of encoding it when the 3RI Imm9 forms were both not big enough and are already used up.
And, likewise, using a bunch of 3R spots to piecemeal the problem would be, inelegant.
Annoyingly, this leaves 2RI or 64-bit encodings as the main option.

One big offender here, as I see it, is a few features in the Privileged ISA spec, such as:
Separate register sets for each protection level/mode;

 Wile My 66000 has separate register files for every thread; each file
is memory resident when not running. {At least conceptually}
 

The comparably large number of CSRs;

 I have a 64-bit control register space and all CSRs are mapped into this
space (along with all device control registers,... {This space is entirely
separate from the space where DRAM occupies}.
 

Allowing operations on CSRs beyond just moving them to/from a GPR or similar;
....

 

Things like the 'V' extension are also cause for concern.

 

The 'M' extension isn't ideal, but I made it work in a way that "isn't too horribly expensive" (namely using a Shift-and-Add unit).

  

Also the cost-scaling of the Shift-Add unit is such that it could potentially be extended to allow 128-bit integer multiply and divide, but debatable (there are only a few edge cases where this would likely be faster than "just do it in software").

 You are being mislead as to what architecture is compared to what you can
implement in your FPGA and this is coloring your view of it.
 

Possibly.
So you think the relative cost-differences would be somewhat different for an ASIC?...
Or, say, would a 128-bit Shift-and-ADD unit be too expensive or too high of latency for an ASIC implementation?...
Then again, trying to work out drawing logic gates and similar for "if I actually do the printable semiconductor thing", seems tradeoffs are a bit different.
I am needing different amounts of space to draw out the logic gates:
   NAND and NOR are smallest;
   AND and OR are a bit bigger;
   Not yet come up with a compact design for an XOR or XNOR gate;
   ...
I suspect memory cells are going to be, comparably, significantly more expensive.
I had hoped that many of the logic-gates and LUTs could be relatively similar sized and all have the interface pads in the same spot, but this is unlikely unless some gates are padded out and others have the logic crammed much closer together.
Well, or use variable size logic and then try to prioritize NAND and NOR over other types of logic gate.

Well, and my ALUX extension can make for faster 128-bit ALU operations, but is debatable as the cost-delta mostly disappears in the noise (mostly because 128-bit ALU ops are rare).

 In My 66000's case, the CARRY instruction modifier provides access to
multiprecision arithmetic--including exact FP arithmetics which even
gets the inexact bit set (clear actually) correctly.
 

Conversely, the code when built for RV64G omits 128-bit types entirely,

 What, exactly, did you expect from an Academic quality ISA ?????

Dunno.
Both GCC and Clang have "__int128" on various other 64-bit targets (though, annoyingly, MSVC did not, as they seemingly did not bother again with "__int128" after the death of the Itanium).