191–200 of 467 posts
Earlier quoted context omitted.
We shall see :) When my iPhone or laptop is no longer running aarch64, i'll happily admit i had been wrong
History is much easier than prediction. I'm with Jim Keller when he says that in time the fastest CPUs will be RISC-V ones.
It turns out that the cost of waiting years for an ISA change is more costly than fixing whatever problems it has.
Earlier quoted context omitted.
They actually did do that. C was split into ZcfZcdZca, so you can choose a non-overlapping subset. It doesn't affect an RV32 non-F core anyway.
I… you can’t be serious.
* The profile used by "Big SoCs" already explicitly depends on F + D + C, implying ZcdZcf, so the newer Zce won't be implemented.
* The compressed float load/store opcodes repurposed for Zce are often unimplemented on embedded processors.
* The ELF file has an attribute section telling you the exact ISA string. If you're debugging an embedded system you probably depend on the ELF file anyway for DWARF info as you likely don't have frame pointers.
If you disagree then that's ok, I'm happy to be disagreed with, but please explain.
I can definitely see his argument, although I still do believe RISC-V did a lot of things better than x86... I really do hope that the arch is eventually able to fix this. Better that there be an open ISA than them all be closed IMO.
Such as? I can't think of anything it does better for high performance cores.
RISC-V is... fine. It satisfies my two requirements for an ISA as a hobby CPU designer, which are: 1. Supported in mainline LLVM and GCC. 2. I can implement it without lawyers sending me a love letter. Everything else, I can fix in post. There are enough good ideas spread across the extensions that I can assemble a reasonably put-together, curated embedded ISA with competitive performance and code density that admits…
You can’t fix the mutually incompatible overlapping encodings in post.
You thought RISC-V chips were compatible with each other beyond the basics? They're not. RISC-V is only a starting point for designing the ISA your chip will actually implement. Don't get me wrong - it's still beneficial that simple code works on many chips.
Earlier quoted context omitted.
I… you can’t be serious.
Yes, I'm serious. I think the overlap is an aesthetic problem rather than a practical one, given that: * The profile used by "Big SoCs" already explicitly depends on F + D + C, implying ZcdZcf, so the newer Zce won't be implemented. * The compressed float load/store opcodes repurposed for Zce are often unimplemented on embedded processors. * The ELF file has an attribute section telling you the exact ISA string. If y…
Sure, this is messy. But, critically, on x86, these are all modes, and any CPU that supports them makes them detectable and supports them in the same way. If you run long mode code outside long mode, some opcodes will be interpreted as the wrong instruction. But you will not find multiple different CPUs that decode valid instructions differently. If I run your weird old x86 code, either it will run correctly or it will fault.
Oh, and all these modes are older than RISC-V. To the extent that there are lessons to be learned, RISC-V should have learned them.
The fact that you can apparently find two RISC-V CPUs that decode some ordinary user mode instructions based on published standards as entirely different operations is bizarre, to say the least. The fact that the relevant CPU features can’t even be enumerated in user mode just makes it worse.
(There are edge cases in x86. Some invalid opcodes have different lengths on different vendors’ CPUs. This is not a problem in practice because, one way or another, they fault. There was also a little glitch in the 64-bit design where some really really old x87 FPU code that uses exceptions cannot be corrected handled by a kernel on a modern CPU.)
the significance and allure of risc-v, the reason china is investing heavily in it right now, has little to do with the technical details of how it works under the hood, it's the fact that it is an open standard not encumbered by intellectual property law. even if it isn't technically the best general-purpose processor architecture, it sets an important precedent by proving that it is possible to develop an open publ…
Earlier quoted context omitted.
Whom do you expect to work for free to design you a state-of-the-art core?
The same kind of people that 'worked for free' to develop Linux.
Earlier quoted context omitted.
The same kind of people that 'worked for free' to develop Linux.
Linux is decent for its core use cases, but it is far from a solid pro-grade OS in a lot of areas... and in the areas it did get there, it took a long time to get there.
Insane take given all the things that run on Linux...
Earlier quoted context omitted.
History is much easier than prediction. I'm with Jim Keller when he says that in time the fastest CPUs will be RISC-V ones.
If China leapfrogs EUV, this could happen.