3 ms·
Well, open-ness wasn't what RISC-V was looking at in ISA models. Is Power clean? Myself, I've never liked its special purpose Condition, Link and Count registe
by CalChris 7y ago
Well, open-ness wasn't what RISC-V was looking at in ISA models.
Is Power clean? Myself, I've never liked its special purpose Condition, Link and Count registers. I don't see the need for a Branch Processing Unit being an architectural division. The last time I checked, pushing a register value across that boundary was slow. It wasn't handled by a renamer.
- ncmncm 7y agoClean-er. Not suggesting it as a substitute for RV, just wondering why they saw nothing in it to learn from. It's not defunct like PA-RISC, Alpha, and (forgive me) SPARC, and quite some research has gone into it.
- CalChris 7y agoI have to admit that leaving Power out of the analysis is a bit odd; the Berkeley crew can be rather parochial. I wrote PowerPC assembly back when the Mac used that ISA and liked it. Alpha lives on, to a degree, in the Sunway Chinese supercomputers. Intel should have gone with Alpha rather than Itanium. https://en.wikipedia.org/wiki/Sunway_(processor) https://en.wikipedia.org/wiki/Sunway_(processor) Is there an architectural feature in Power you think should have been considered by RISC-V for inclusion or omission? My 2030 prediction is that Intel will have a simpler x86 where they discard a shit ton of legacy.
- ncmncm 7y agoDon't know it well enough to suggest any. That is what inclusion in the survey would have been useful for. It is conventional to complain about condition codes, but I don't see what would be debilitating about just appending a set of condition codes to each register, so that renaming a register carries them along. Going from storing 64 bits to 70 bits each would't break the bank.
- CalChris 7y agoThat is a really good idea. Sadly, RISC-V is an ultra ultra conservative design bereft, nay avoiding anything resembling an idea. I believe that an element of your idea is done in modern x86 microarchitectures. I was having an argument on LLVMdev about a peephole optimization and partial register update stalls. Eventually one of the Intel compiler people popped in on the thread and settled the argument, saying: Regarding the partial EFLAGS write, modern OOO processors independently rename the carry flag, et al, so this is no longer a problem.