What I find most funny about ARM moving to allow custom ISA extensions is that in last year's "risc-v basics" smear campaign one of their main arguments against RISC-V was that it'd be unfathomably bad that RISC-V allows custom ISA extensions bc that would lead to fragmentation.
-
-
Roughly half is moderately serious, half is pointless pedantry about things that don't matter or complaints about good choices.
-
Atomics being optional is absolutely wrong. Non-SMP core can implement lr/sc trivially and should be required to. Likewise for mul but not quite as serious since it *can* be emulated in sw.
- 12 more replies
New conversation -
-
-
As a general statement, the common theme of most of these complaints is the minimalist core they standardized and froze for all time does not contain many desirable instructions. But many of these complaints have been resolved by instructions added in draft versions of the ISA
-
In that regard, I'd say it can be likened to the "batteries included std" debate. To get to the point of a permanently frozen core ISA, they pursued a minimum viable product, perhaps to a fault, but that isn't intended to be the steady state.
- 1 more reply
New conversation -
-
-
A lot of this matches my own thoughts as well (wrt DIV, lack of Reg+Reg*Sc, ...). In an ISA: I have found I prefer a True/False status flag (like in SuperH), which also allows predicated ops to be encoded cheaper (2b vs 4b). Also nifty: sticking the FPU in GPR space; ...
Thanks. Twitter will use this to make your timeline better. UndoUndo
-
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.