Re: Misc: BGBCC targeting RV64G, initial results...

On 10/16/2024 1:07 PM, Stephen Fuld wrote:

On 10/16/2024 8:59 AM, Paul A. Clayton wrote:
 snip
 

I do not know of any enumeration of conditions that would be
commonly useful. Less than, equal to, greater than might be
somewhat useful for a three-way branch.

 That was the function of the arithmetic if statement in original Fortran.  If it were more useful, it wouldn't have been taken out of the language long ago.
 

Yeah...
Ironically, one of the main arguable use-cases for old Fortran style IF statements is implementing the binary dispatch logic in a binary subdivided "switch()", but not enough to justify having a dedicated instruction for it.
Say:
   MOV  Imm, Rt  //pivot case
   BLT  Rt, Rx, .lbl_lo
   BGT  Rt, Rx, .lbl_hi
   BRA  .lbl_case
But, absent having multiple labels per branch, not really a good way to save much over this...
Otherwise, had recently been still working on BGBCC+RV stuff:
Trying to getting stuff working correctly in my Verilog implementation.
   There are still some bugs here.
Writing a spec for a "low-cost" FPU SIMD extension:
   https://pastebin.com/9UeAP9Yk
Which basically just takes the arguably cheaper route of "extend the F, D, and Zfh extensions to support basic FPU-SIMD in the existing FPRs" rather than "define a whole new complicated mess of stuff" that is the V extension.
Some details are still in-flux, and I have not yet decided whether or not to map over the FP8 converter ops and similar. Arguably FP8 and A-Law converter ops are a bit niche though.
As well as looking some at the P spec, which (ignoring the needlessly complicated parts) isn't too far from what BJX2 does SIMD wise (albeit lacks obvious direct equivalents of the RGB555 helper instructions; but possibly using SIMD to work with RGB555 pixel data is a bit niche).
It is possible if I add some of this, I may do it as jumbo-prefix-only ops. One is unlikely to see RGB555 or FP8 converters used in any significant density (except maybe if doing highly-unrolled NN code using FP8 or similar; but unclear if it would try to make sense to map this over to RV anyways; and existing people trying to do stuff in this area appear to be mostly focused on the V extension).
For normal graphical or audio processing, having these sorts of niche converters as 64-bit encodings would probably be fine.
As-is, it could do a 4x32 shuffle in 2 instructions, but would need either a 4-op sequence (no jumbo), or a jumbo-encoded op, to perform a 4x16 shuffle (it is either this or define a dedicated "FPSHUF.H" instruction or similar). Can probably assume, if it matters, will probably also have a jumbo prefix.
May still need to decide on some other things, like whether to map over a jumbo-encoded 4xFP8 to 4xFP16 constant-load. Or, whether to come up with an encoding to load an arbitrary 64-bit value into an FPR (currently N/E in RV64 mode).
As-is:
   J22+J22+LUI  : LI Xn, Imm64
   J22+J22+AUIPC: Unused
   J22+J22+JAL  : Unused, Possible "JAL Rn, Abs64"
For FPR's, in may make sense to have:
   Load Binary16, expanding to Binary64  (already in Jumbo spec)
   Load Imm33s into low-order bits (Jumbo spec, J12O+LUI)
   Load Imm32 into high-order bits
     Possible, not yet defined, already exists in BJX2 (1).
   Load Imm32 as 2xFP16 expanding to 2xFP32
     Possible, not yet defined, already exists in BJX2 (1).
   Load Imm32 as 4xFP8 expanding to 4xFP16
     Possible, not yet defined, already exists in BJX2 (1).
*1: Probably could define it as J12O+LUI, using the Wm and Wo register-extension bits to encode which type of constant to load (basically about the same as how I did it in BJX2; just it had used a J_OP and "MOV Imm16u, Rn" instruction instead, but similar basic idea here).
   Probably, say:
     00: Load Imm33s to low 32-bits, sign-extend as usual
     01: Load Imm32 to high 32-bits (sign bit used for LSB fill, *2)
     10: 2xFP16 -> 2xFP32
     11: 4xFP8 -> 4xFP16
*2: Though in BJX2, this case was encoded as J_IMM+"LDIHI Imm10, Rn"
Could maybe be tempted to reclaim "J22+J22+AUIPC" as:
   LI  Fn, Imm64
Arguing that, if one needs PC-rel, +/- 4GB is sufficient; and one is far more likely to want to be able to load constants like M_PI and similar into an FPU register (in a single clock-cycle).
Though, if one has this, the other constant cases (2xFP16 or 4xFP8) would be merely space-saving (mostly relevant to FP-SIMD vector literals), but may be lower priority mostly as they are infrequently used (and thus the space savings are less significant).
Relative cost-difference is small, if one assumes an implementation where the constant-load cases use the same converters as used for the normal vector conversion path, which would be (presumably) already present.
Most of this would be largely irrelevant to Doom performance, but would be relevant if I want to try to make GLQuake work at some semblance of usable in RV Mode.
Less immediate relevance to SW Quake, which uses mostly scalar FPU (and mostly naively represents vectors as in-memory pointers).
In this stuff, I have also started running into annoyance of noting differences and additions/removals/changed between different versions of the BitManip spec / B extension. A few useful ops were removed in newer versions, ...
My Jumbo prefix encoding would have conflicted with an earlier version of BitManip, but does not conflict with the current form of the B extension (it exists in the shadow of previously-removed instructions).
Felt curious and looked, it looks like the person mostly responsible for the B extension has largely "gone quiet" for the past year or so (no recent social media posts, has seemingly taken down all of their past YouTube and Twitch contents; minimal activity on GitHub). Not entirely sure what is going on there.
...
Otherwise, did see a video talking some about performance of Doom and Quake and similar on older systems:
   Doom apparently required something like a 486 DX2-66 to perform well.
   Quake apparently required a faster Pentium system to be playable.
     Apparently, likewise for Hexen, ...
   Apparently Wolf3D needed a higher-end 386 to perform well.
     Even if it could technically run on a 286.
   ...
I guess this differs from my prior understanding that Doom would have been mostly playable on a 25 MHz 386 or similar. Apparently, not really.
So, I guess I can feel not quite as bad about the lackluster framerates from Quake and Hexen on a 50MHz core. Seemingly, it is in-fact still outperforming vintage (early 90s) PCs.
Well, and Quake3 is pretty slow, but IIRC, PCs of that era were generally pushing 1GHz, so...
...