Bug 240 - POWER-RISCV ISA switch formal standard writeup needed
Summary: POWER-RISCV ISA switch formal standard writeup needed
Alias: None
Product: Libre-SOC's first SoC
Classification: Unclassified
Component: Specification (show other bugs)
Version: unspecified
Hardware: PC Linux
: --- enhancement
Assignee: Alain D D Williams
Depends on:
Blocks: 174
  Show dependency treegraph
Reported: 2020-03-13 12:56 GMT by Luke Kenneth Casson Leighton
Modified: 2022-08-28 18:07 BST (History)
2 users (show)

See Also:
NLnet milestone: NLNet.2019.10.046.Standards
total budget (EUR) for completion of task and all subtasks: 3000
budget (EUR) for this task, excluding subtasks' budget: 3000
parent task for budget allocation: 174
child tasks for budget allocation:
The table of payments (in EUR) for this task; TOML format:
addw = {amount=1000, submitted=2022-08-18, paid=2022-08-25} lkcl = { amount = 1000, submitted = 2022-06-25, paid = 2022-07-21 } [jacob] amount = 1000 submitted = 2022-07-06 paid = 2022-07-21


Note You need to log in before you can comment on or make changes to this bug.
Description Luke Kenneth Casson Leighton 2020-03-13 12:56:08 GMT
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.
Comment 1 Luke Kenneth Casson Leighton 2022-06-25 10:09:12 BST
alain this is a while back but is basically done.
Comment 2 Luke Kenneth Casson Leighton 2022-06-25 10:21:32 BST
correction, i thought this was bug #214.

*this* one is done because after careful analysis we decided not
to do an ISA-switch.
Comment 3 Jacob Lifshay 2022-07-05 02:03:33 BST
Marking this resolved, since all the work which we are going to do in the scope of NLNet.2019.10.046.Standards is completed.
Comment 4 Luke Kenneth Casson Leighton 2022-08-19 12:27:12 BST
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
ISA switch.