[libre-riscv-dev] Why The Dual ISA

[Luke Kenneth Casson Leighton]

On Sun, Jan 19, 2020 at 3:50 AM Immanuel, Yehowshua U <yimmanuel3 at gatech.edu>
wrote:

> So just throwing it out there?
>

ya man :)


> Why are we using the Dual ISA?
>

because as i said in the update, we have committments to users and to
sponsors.


> What are the advantages and disadvantages?
>
> 1. Would the plan be to go to market as POWER compliant?
>

given that the consequences of not being properly compliant are, "IBM would
have the right to assert all and any of its patents against us not being
compliant" and "IBM and other OpenPower Members would also get upset" and
"the OpenPOWER Foundation would assert its right to insist that we, under
no circumstances, are permitted to mention "POWER ISA" in relation to the
product"...

/me sucks in a deep breath and stops turning blue

yes.


>
> 2. Would we mention that RV is still in there somewhere?
>

if it was up to me, it only as a side-note.  the less "endorsement" of RV
the better.


> 3. Would we switch ISA by flipping a bit inside the hardware?
>

basically, yes.  this would be activated via an instruction (for example
setting a CSR - Control Status Register).  what that bit would do is very
simple:

it would be treated as a hidden "33rd" opcode bit.

do you get the significance of that?


> 4. Also, Pipelining is difficult -


not really.  that's what the 6600 Dependency Matrices take care of,
ensuring that you can mix and match variable-length pipelines *and*
multi-clock blocking FSMs *and* multiple mixtures of both or either with
completely arbitrary completion times on *all* of those, with absolutely no
difficulties whatsoever.

now, if we were doing a Tomasulo Algorithm or a standard in-order
processor, *then* we would be in difficulties as far as pipelining is
concerned.  *real* difficulties.  for the Tomasulo algorithm we'd be out of
the running as far as power efficiency is concerned, and if we were doing a
standard in-order design the complexity of the SIMD allocation would
absolutely kill the design even if we were doing a single ISA, let alone
dual.

the 6600 Dependency Matrix System is pretty stunningly effective, efficient
and elegant.  all that it effectively needs to know is: when a pipeline (or
FSM) has produced a result.  that's it.  once that result is known, it can
"release" the result register (and memory location if it's a LD) and from
there, any *other* rows in the Matrix which were waiting for that result,
and for which a suitable ALU is available, may now be "picked" (allowed to
proceed).  i've simplified greatly.

i will send you Mitch Alsup's book chapters, please respect his wishes
regarding Copyright, namely that if you use the information in them, please
ensure that you credit him as the source of that knowledge.


> just HOW compatible are the RV and POWER ISAs?
>

not at all.  however they are both RISC, and they will both fit cleanly
onto an underlying micro-coded internally-mapped ISA.

that internally-mapped ISA will be *very* basic (and also quite long by ISA
standards), and will contain a lot of "state information" which gets passed
from pipeline-stage to pipeline-stage, dropping unnecessary parts of that
as the instruction (during decode / routing) gets passed to specialist ALUs.

this "state" for example would include, at one part of the decode phase,
the "Vector Length".  after the hardware-loop phase, that Vector Length no
longer is included.

the "state" would also include the *value* of predication bits, rather than
the *register* in which that predication is stored.

so it is a continuous process of transformation, and which ISA things came
from is not actually particularly relevant, other than when it comes to
*outputting* state information such as FP flags and INT carry flags etc.
etc.

l.