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

On Tue, 8 Oct 2024 19:06:34 +0000, BGB wrote:

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

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

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).

Yes, one would expect voids in tables would cause the compiler to
break the switch table into more dense chunks.

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.

If the void is greater than the overhead to break the table, then
the table should be broken.

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.

Think of it as a LD IP,[address]