Re: Byte Addressability And Beyond

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

Thomas Koenig <tkoenig@netcologne.de> writes:

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

d) all modern major architectures have instructions for bitfield
manipulation (insert, extract) obviating any need for general bit-level addressing.

>
RISC-V: Seems like it's an extension, for which only a draft is
available, so it is debatable if it has it or not.
>
POWER: Certainly, the rlwinm instruction.
>
AMD64: Sure, pdep and friends.
>
ARM: You certainly know by heart, I don't need to look.
>
Loongarch: Looking at the docs, it also has it (BSTRINS etc).
>
So, with the possible exception of RISC-V, I cannot see anything
to contradict you :-)

 I would, personally, categorize RISC-V as a niche architecture
at this time.   Give it time to reach "major" status, where
the extensions become less optional.

Yeah.
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).
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.
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).
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;
The comparably large number of CSRs;
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").
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).
Conversely, the code when built for RV64G omits 128-bit types entirely, as GCC doesn't seem to support "__int128" on RV64G.
Mostly effects whether "printf()" and similar supports "%I128d" and "%LLd" modifiers.
Say:
   "%d": Assume 32-bit or less.
   "%ld": Assume 64-bit (matches sizeof(long))
   "%lld": Assume 64-bit (explicit)
   "%I64d": Assume 64-bit (this notation used by MSVCRT)
   "%Ld": Assume 128-bit
   "%LLd": Also Assume 128-bit
   "%I128d": Assume 128-bit (also MSVC notation)
     But, MSVC lacks 128-bit types on x86-64.
   "%jd": Also 128-bit (intmax_t)
Where 'I' may also be used for locale, but the distinction is made based on whether 'I' is followed by a digit.
Similarly:
   "%f": Binary64
   "%Lf": long double / Binary128 (also absent in RV64G build)
Though, apparently, it seems GCC decays "long double" to "double" on RV64G, in apparent conflict with the ABI spec which specifies Binary128.
When building for RV64G, at present the support for 128-bit "printf()"/"scanf()" modifiers is disabled.
For BJX2, these don't depend on ALUX being enabled, rather ALUX effects whether native 128-bit instructions should be used, or whether to use runtime calls (which may fake them using 64-bit operations), or (in some cases) to decompose into a pair of 64-bit operations.
But, at present, the main places it is used are mostly in "printf()" and for supporting Binary128 operations (where, as can be noted, 128-bit ALU instructions are a lot cheaper than supporting extended-precision FPU in hardware, and can make the Binary128 emulation faster).
...