A formal write-up of the means by which processors may switch to RISC-V (and back, from POWER), to be proposed to the OpenPOWER Foundation at a later date.
alain this is a while back but is basically done.
correction, i thought this was bug #214.
*this* one is done because after careful analysis we decided not
to do an ISA-switch.
Marking this resolved, since all the work which we are going to do in the scope of NLNet.2019.10.046.Standards is completed.
providing additional details:
we decided not to do an ISA switch in hardware because, technically,
the RISC-V ISA turns out to be so fundamentally damaged for high-performance
compute that it would be harmful to consider implementing it. we had no idea
about this fact at the time that the task was raised: very few people did.
this post, predating the proposal by over eight months and found only
last year, gives the best technical explanation:
it explains why the Alibaba Group added a whopping 50% more instructions
(as rogue, custom instructions) to the RISC-V ISA, to compensate for the
design flaws of RISC-V, without which it is anaemic at best:
a much better option would be to perform JIT binary-translation and to
use the opportunity to perform "peephole optimisation" (similar to hardware
macro-op fusion), looking for common patterns and replacing them with
alternative, faster equivalents in Power ISA.
another reason is that RISC-V's patent protection is inadequate. again,
we did not know this at the time. whilst there exist patent licensing
agreements in between RISC-V Members, the novelty of RISC-V means that
those patents are often pre-dated and by third parties *not* RISC-V Members,
not bound by any agreements not to sue or cross-license. we have heard that
RISC-V patent infringement lawsuits have already begun.
put simply: if we implement a RISC-V ISA front-end we risk running into patent
infringment. whereas: software-defined JIT binary-translation, by virtue of
being entirely in general-purpose software, cannot infringe patents.
overall then it was not that the task is not technically feasible: we could
indeed complete it as defined. it was the ancillary research - which took
considerable time over a prolonged period - as to whether there would be any
*benefit* to doing the task. the conclusion from that considered research was
"no", that JIT binary-translation (entirely in software) would be a much
better option, one that, as the JIT binary-translator would be a
general-purpose program (e.g. qemu) there was no *need* for a hardware-level