| Summary: | POWER-RISCV ISA switch formal standard writeup needed | ||
|---|---|---|---|
| Product: | Libre-SOC's first SoC | Reporter: | Luke Kenneth Casson Leighton <lkcl> |
| Component: | Specification | Assignee: | Alain D D Williams <addw> |
| Status: | RESOLVED FIXED | ||
| Severity: | enhancement | CC: | libre-soc-bugs, programmerjake |
| Priority: | --- | ||
| Version: | unspecified | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| 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
|
|
| Bug Depends on: | |||
| Bug Blocks: | 174 | ||
|
Description
Luke Kenneth Casson Leighton
2020-03-13 12:56:08 GMT
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.
|