Path: ...!feeds.phibee-telecom.net!3.eu.feeder.erje.net!feeder.erje.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: BGB <cr88192@gmail.com>
Newsgroups: comp.arch
Subject: Re: Misc: BGBCC targeting RV64G, initial results...
Date: Wed, 16 Oct 2024 19:03:26 -0500
Organization: A noiseless patient Spider
Lines: 64
Message-ID: <vepk8h$2f0m6$1@dont-email.me>
References: <vd5uvd$mdgn$1@dont-email.me>
 <b17e4a241a5bc300250aab8c1c5b9348@www.novabbs.org>
 <vdcbe5$1s6so$1@dont-email.me>
 <852a1995ec32b2e03628885f9b5da124@www.novabbs.org>
 <veonu1$2ae17$1@dont-email.me> <veovcc$2b1fi$1@dont-email.me>
 <vep7be$2cs59$1@dont-email.me>
 <802b8c55ab0ba69a7fc324618f2c63df@www.novabbs.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 17 Oct 2024 02:03:30 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="4621c53e62a3eebf5ae75bff72135c11";
	logging-data="2589382"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18WecHl3VCFQPvTm4/e5BDYWZTpj1XMtS0="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:dsHa4byDS4DIQDrcgSAtqHtLw6c=
Content-Language: en-US
In-Reply-To: <802b8c55ab0ba69a7fc324618f2c63df@www.novabbs.org>
Bytes: 3523

On 10/16/2024 5:16 PM, MitchAlsup1 wrote:
> On Wed, 16 Oct 2024 20:23:08 +0000, BGB wrote:
> 
>>
>> 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
> 
> With a 64-bitinstruction one could do::
> 
>      B3W   .lbl_lo,.lbl_zero,.lbl_hi
> 
> rather straightforwardly.....

Possibly, but the harder part would be to deal with decoding and feeding 
the instruction through the pipeline.

Granted, I guess it could be decoded as if it were a normal 3RI op or 
similar, but then split up the immediate into multiple parts in EX1.


Say:
Decode as a 3RI Imm33s;
Then split the immediate into 3x 11-bits, calculate 3 offsets relative 
to PC, and apply the one which matches the result of the comparison 
(likely needing to route the S and Z flags from the subtract logic to 
EX1 or similar; vs the current logic routing the CMP T/F flag).

Could deal with the Branch PC as, say:
   Calculate PC[47:16]+1, and PC[47:16]-1.
   Calculate the low 16 bits of each branch direction;
   Select direction based on branch result;
   Select high bits of PC based on selected branch direction (-1, 0, 1).

But, worth the cost?...
This could mostly benefit programs that spend a significant part of 
their running time dispatching in sparse switch blocks, but probably not 
a lot else.


Disp11 couldn't deal with particularly large switch blocks, one might 
need a 96 bit encoding, possibly using 18 bits each, but this would be 
more expensive to deal with.


Or, 2-way with fall-through:
   Rn>Rm: Branch High
   Rn<Rm: Branch Low
   Rm==Rn: Fall Through / No Branch
The fall-through case having a branch to the case label. This would 
allow 16 (2-way) and 20/23 bit displacements (for a plain JAL/BRA), so 
could deal with much bigger "switch()" blocks.


Would still need to think on this...