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

On 10/5/2024 6:10 PM, MitchAlsup1 wrote:

On Thu, 3 Oct 2024 8:20:46 +0000, BGB wrote:
 

On 10/1/2024 5:00 AM, Robert Finch wrote:

On 2024-09-29 10:19 p.m., BGB wrote:

The ADD is not necessary if min == 0
>
The JTT instruction compared Rt with 0 on the low side and max
on the high side. If Ri is out of bounds, default is selected.
>
The table displacements come in {B,H,W,D} selected in the JTT
(jump through table) instruction. Rt indexes the table, its
signed value is <<2 and added to address which happens to be
address of JTT instruction + #(max+1)<<entry. {{The table is
fetched through the ICache with execute permission}}
>
Thus, the table is PIC; and generally 1/4 the size of typical
switch tables.

 

How well does JTT work with large tables? What if there are several
hundred table entries?

 Tables can have 2^16-1 (65534) case entries.
 

There is no hard-limit in my case, but BGBCC had generally broken up tables larger than 256.
IIRC, this was because larger tables were more likely to have "voids" which could lead to a large number of branches to default, while still being over a 75% density threshold, splitting the table apart was more likely to expose these voids (and make the binary smaller).
I guess a possible tweak could be, say, if the density is over 93% or so, it will allow a table-jump regardless of size.
Though, for the most part the programs I am testing with tend not to really have too many large switch blocks, and in the case of "switch" with a byte (most common case in these cases), a limit of 256 works.
Meanwhile, for some other cases, like a switch full of TWOCC and FOURCC values, one really does not want to use a jump table (but, this is avoided as these cases tend to have a very low density).

For Q+ indirect jump the values loaded from the table replace the low
order bits of the PC instead of being a displacement. Only {W,T,O} are
supported. (W=wyde,T=tetra,O=octa). Should add an option for
displacements. Borrowed the memory indirect jump from the 68k.

 My 66000 Loads the table entry directly into IP in 1 cycle less
than LD latency.
 

I guess, specialized Load+Branch could potentially have less latency than separate load+branch, or the current strategy of double-branching.
Though, double-branch doesn't require anything special from the HW, and both BJX2 and RV can do it, though it is a little more wonky on RV.
Using a table of displacements (16 or 32 bit) could work, but would require a special type of reloc, basically: *DestWord = (TgtLbl-RefLbl).
IOW:
A sort of "what now?" scenario has come up.
Gluing Jumbo prefixes and similar onto RV64 does seem to help with performance, but still fails to match BJX2 here (but, BJX2 also has a more complicated instruction decoder vs RISC-V). It is a question at the moment if the cost of the BJX2 instruction decoder is enough to be significant.
May need to get around to trying to implement the word-transposed decoder thing and see if this can reduce LUT cost.
I still have doubts anyone in RV land is likely to take the jumbo-prefix strategy seriously. Though (apparently), one of the higher up people did mention having considered a similar sounding approach.
Albeit seemingly with the prefixes being handled as separately decoded instructions with hidden internal state in a register; which is less desirable as I see it, as the cost of the EX side logic to deal with this being exposed as a CSR is likely to be higher than the cost of always decoding it as a larger conjoined instruction (which requires that the prefix always directly precede the instruction that it modifies).
There is also a temptation to add "sign extend 16-bit short" and "sign-extend byte" ops, which as-is still require a pair of shift operations (though, at least the jumbo prefixes allow encoding "sign extend unsigned short" as "AND Rn, Rm, 0xFFFF"...).
Likewise, "ADD.UW Rd, Rs, Rt" exists as part of Zba, and I had defined jumbo rules to allow faking an "ADD.UW Rn, Rm, Imm" case...
TBD if I come up with some encoding scheme for how to map my existing SIMD system over to RV64, or converter helper ops.
What I would want would be a bit different from the V extension though.
Current thinking:
   The scalar Single-precision ops will work on 2x Binary32
     (as in my current implementation);
   Add scalar half-precision ops within RV64's existing scheme:
     But, these will work on 4x Binary16;
   Will likely use jumbo-prefixed encodings for most other stuff.
     Likely, most of my SIMD ops would exist in the F registers.
The actual 'V' extension would require a whole new chunk of register space, which I don't want to deal with.
So, say:
   FADD.S Fd, Fs, Ft  //Secretly a SIMD op
   FADD.H Fd, Fs, Ft  //Also secretly a SIMD op
   Can use FLD/FSD etc as before.
Would likely use mostly ops encoded via prefixes, specifics TBD, may define short-hands in the User2 / User3 blocks (7'h5B / 7'h7B).
Most likely this would be more relevant for common-ish Packed 4x Int16 ops (like PADD.W, though may rename PIADD.H or similar for more consistency with RV naming conventions).
...

>