Re: Computer architects leaving Intel...

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
TBD if the differently aligned register fields significantly effects things regarding superscalar analysis.
When I initially came up with the XG3 encoding, wasn't considering Co-Execute.
The ISA's would also differ in that XG3 will view the space as a unified 64-register space rather than two 32 register spaces.
...