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: https://news.ycombinator.com/item?id=24459314 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: https://ftp.libre-soc.org/466100a052.pdf 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 ISA switch.