Path: ...!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: Computer architects leaving Intel...
Date: Tue, 17 Sep 2024 23:00:43 -0500
Organization: A noiseless patient Spider
Lines: 179
Message-ID: <vcdjbn$3u259$1@dont-email.me>
References: <vaqgtl$3526$1@dont-email.me> <86r09ulqyp.fsf@linuxsc.com>
 <2024Sep8.173639@mips.complang.tuwien.ac.at>
 <p1cvdjpqjg65e6e3rtt4ua6hgm79cdfm2n@4ax.com>
 <2024Sep10.101932@mips.complang.tuwien.ac.at> <ygn8qvztf16.fsf@y.z>
 <2024Sep11.123824@mips.complang.tuwien.ac.at> <vbsoro$3ol1a$1@dont-email.me>
 <867cbhgozo.fsf@linuxsc.com> <20240912142948.00002757@yahoo.com>
 <vbuu5n$9tue$1@dont-email.me> <20240915001153.000029bf@yahoo.com>
 <vc6jbk$5v9f$1@paganini.bofh.team> <20240915154038.0000016e@yahoo.com>
 <2024Sep15.194612@mips.complang.tuwien.ac.at> <vc8m5k$2nf2l$1@dont-email.me>
 <vc8tlj$2od19$3@dont-email.me> <vca209$319ci$1@dont-email.me>
 <vcbiov$3ecji$3@dont-email.me> <vccmm3$3m42h$1@dont-email.me>
 <e060fe2e0ee375efff2a9ab1223652f5@www.novabbs.org>
 <vccv3r$3nfqv$1@dont-email.me>
 <45fb24ca46af5c388b0a44af2f72ddf6@www.novabbs.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Wed, 18 Sep 2024 06:02:00 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="f294aec13410514d4030784d3213085a";
	logging-data="4130985"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+GkgFwninJh1HBFSoRa7EQktzGxnLDOe4="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:dUiyfzdjSwz37MK4OkwDa5SL2N8=
In-Reply-To: <45fb24ca46af5c388b0a44af2f72ddf6@www.novabbs.org>
Content-Language: en-US
Bytes: 7743

On 9/17/2024 6:04 PM, MitchAlsup1 wrote:
> On Tue, 17 Sep 2024 22:15:12 +0000, BGB wrote:
> 
>> On 9/17/2024 3:11 PM, MitchAlsup1 wrote:
>>>
>>> Modes make testing significantly harder. Each mode adds 1 to the
>>> exponent
>>> how many test cases it takes to adequately test a part.
>>
>> Possibly.
>>
>> But, modes are kinda unavoidable here:
>>    CPU only runs RV64GC or similar:
>>      Doomed to relative slowness;
>>    CPU only does CoEx:
>>      Closes off the ability to run binaries that assume RV64GC.
>>    CPU only does new ISA:
>>      Well, then it can't run RISC-V code, making all this kinda moot.
> 
> My 66000 does not have modes (at least yet) it even comes our of
> RESET with the MMUs turned on.

Yes, but My66000 probably isn't intended to be able to run RISC-V 
machine code...


Dealing with multiple ISA encoding schemes requires, modes...


> -----------
>>>> This is assuming an implementation that would want to be able to 
>>>> support
>>>> both this ISA and also RV64GC.
>>>>
>>>> One possibility could be (in native RV notation):
>>>> RV64 (Branches if supported, NOP if not):
>>>>    LBU X0, Xs, Disp12s  //Dest=RV64GC
>>>>    LWU X0, Xs, Disp12s  //Dest=CoEx
>>>>    LHU X0, Xs, Disp12s  //Dest=Native
>>>> New ISA:
>>>>    LBU X0, Xs, Disp10s  //Dest=RV64GC
>>>>    LWU X0, Xs, Disp10s  //Dest=CoEx
>>>>    LHU X0, Xs, Disp10s  //Dest=Native
>>>
>>> This only gives 36-bits (top) or 30-bits (bottom) or range. What you are
>>> going to want is 64-bits of range -- especially when switching modes--
>>> you PROBABLY want to use an entirely different sub-tree of the
>>> translation
>>> table trees.
>>
>> Idea here is that 'Xs' will give the base address for the target.
>>
>> On the RISC-V side, this would mean, say:
>>    AUIPC X7, disp
>>    LWU X0, X7, disp
>> Similar to a normal JALR.
> 
> Still limited to 32-bit displacement from IP.
> 
> How would you perform the following call::
> current IP = 0x0000000000001234
> target  IP = 0x7FFFFFFF00001234
> 
> This is a single (2-word) instruction in my ISA, assuming GOT is
> 32-bit displaceable and 64-bit entries.
> 

Granted, but in plain RISC-V, there is no real better option.

If one wants to generate 64-bit displacement, and doesn't want to load a 
constant from memory:
   LUI X6, Disp20Hi       //20 bits
   ADDI X6, X6, Disp12Hi  //12 bits
   AUIPC X7, Disp20Lo
   ADD X7, Disp12Lo
   SLLI X6, X6, 32
   ADD X7, X7, X6

Which is sort of the whole reason I am considering hacking around it 
with an alternate encoding scheme.

New encoding scheme can in theory do:
   LEA X7, PC, Disp64
In a single 96-bit instruction.


>> I could almost interpret X0 as PC, except that on a "standard" RISC-V
>> CPU, the non-supported case would be, likely: "program crashes trying to
>> access a NULL pointer", which is less useful.
>>
>>
>> Branches in the new ISA would likely be encoded using jumbo prefixes.
>>
>> Well, partly because the new ISA lacks AUIPC, but the new ISA can encode
>> it more directly as, essentially:
>>    LWU X0, PC, Disp33s
> 
> AUPIC is (and remains) a crutch (like LUI from MIPS)
> a) it consumes an instruction (space and time)
> b) it consumes a register unnecessarily
> c) it consumes power that direct delivery of the constant would not

Yeah, pretty much.
   LUI + AUIPC + JAL, eat nearly 27 bits of encoding space.

I didn't bother carrying over these instructions...


But, they will still exist when the CPU is running RISC-V code, or in a 
Co-Execute Mode (via the existing 32-bit RISC-V encoding space).
Similarly, the mechanism to leave RISC-V Mode, needs to be able to be 
encoded in RISC-V Mode.


Say:
   ...xxx00: New ISA (XG3?)
   ...xxx01: Jumbo Prefix
   ...xxx10: Reserved for now
   ...xxx11: RISC-V Op (32-bit)

Vs in RV64GC Mode:
   ...xxx00: RISC-V 'C' OPs (16-bit)
   ...xxx01: RISC-V 'C' OPs (16-bit)
   ...xxx10: RISC-V 'C' OPs (16-bit)
   ...xxx11: RISC-V Op (32-bit)


But, I didn't design RISC-V, I am just left needing to face it:
   Because, unlike my ISA, it is actually popular;
   One could, in theory, get Linux running on it
     Provided the HW interfaces were also supported.

But, to have much hope of running mainline software on it, it needs to 
be able to run RV64GC.

No other practical alternative in this case, other than having modes.

As-is, assigned encoding space in the new ISA was divided into 4x 28-bit 
blocks (YY):
   00: 3R, ~ 12% used (~ 120/1024 spots)
   01: Reserved
   10: 3RI Imm10, ~ 50% used, (32/64 spots)
   11: Ld/St / Branch / Imm16, Mostly Full
     36/48 Imm10 spots (75%)
     7/12 Imm16 spots (58%)
     2/2 Disp23 (BRA and BSR, 100%)


XG3 hasn't yet added any SIMD instructions though.
A lot of the basic instructions follow similar patterns to RV instructions.


Encoding (XG3):
* ZZoo-oooo-ZZmm-mmmm-ZZnn-nnnn-ZZZZ-YYPP  (3R)
* ZZZZ-ZZZZ-ZZmm-mmmm-ZZnn-nnnn-ZZZZ-YYPP  (2R)
* iiii-iiii-iimm-mmmm-ZZnn-nnnn-ZZZZ-YYPP  (3RI Imm10)
* iiii-iiii-iiZZ-ZZZZ-ZZnn-nnnn-ZZZZ-YYPP  (2RI Imm10)
* iiii-iiii-iiii-iiii-ZZnn-nnnn-ZZZZ-YYPP  (2RI Imm16)
* iiii-iiii-iiii-iiii-Zjjj-jjjj-ZZZZ-YYPP  (Imm23)
* iiii-iiii-iiii-iiii-Zjjj-jjjj-kkkk-YYPP  (Imm27, Jumbo-Only)

RV:
* ZZZZ-ZZZt-tttt-mmmm-mZZZ-nnnn-nZZZ-ZZ11  (3R)
* iiii-iiii-iiii-mmmm-mZZZ-nnnn-nZZZ-ZZ11  (3RI-A, Imm12)
* iiii-iiit-tttt-mmmm-mZZZ-iiii-iZZZ-ZZ11  (3RI-B, Imm12)
* iiii-iiii-iiii-iiii-iiii-nnnn-nZZZ-ZZ11  LUI/AUIPC/JAL
========== REMAINDER OF ARTICLE TRUNCATED ==========