Liste des Groupes | Revenir à c arch |
On 9/17/2024 3:11 PM, MitchAlsup1 wrote:My 66000 does not have modes (at least yet) it even comes our of>>
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.
Still limited to 32-bit displacement from IP.>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.
I could almost interpret X0 as PC, except that on a "standard" RISC-VAUPIC is (and remains) a crutch (like LUI from MIPS)
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
Les messages affichés proviennent d'usenet.