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

On Tue, 1 Oct 2024 10:00:49 +0000, Robert Finch wrote:

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

On 9/29/2024 2:11 PM, MitchAlsup1 wrote:

Compared to::
//      ADD        Rt,Rswitch,#-min
        JTT        Rt,#max
        .jttable   min, ... , max, default
adder:
>
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?

Max table size is +2^16 entries. The instruction specifies the entry
size {B,H,W,D} and scales the index accordingly. If the index is
negative or > MAX then max+1 entry is fetched (default) {Known to
be in the table}. The fetched entry is scaled by <<2 for word
displacement of IP, and then added for the new IP location.
Fetch proceeds.
{{The assembler checks (and adjusts) the size after resolving
the labels of the switch().}}
Most of the time the fetch entry is already in the instruction
buffer and can be simply muxed out (1 cycle) instead of ICache
read latency.

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.

I have memory indirect CALL instructions.