4 ms·
I think that's actually a bit of a contentious question; I think there's a lot of people that'd argue that it's definitely part of the future of open computing,
by remexre 6y ago
I think that's actually a bit of a contentious question; I think there's a lot of people that'd argue that it's definitely part of the future of open computing, and I think it's extremely likely that it stays a part of computing for low-cost embedded devices.
On the other hand, there's a strong argument to be made that it's more difficult to make a RISC-V processor with comparable performance to a desktop-grade amd64 processor than to make an ARMv8 processor that with the same. (Personally, I'm a big fan of AArch64 being a fixed-width encoding, and both programming by hand in it and find writing assemblers and disassemblers is super-easy as a result.)
- nynx 6y agoRiscv is also fixed-width, at least to the same level as aarc64.
- remexre 6y agoMy understanding was that the RISC-V encoding used lengths as decoded in e.g. [0], whereas AArch64 is uniformly 32 bits per instruction; is this incorrect? [0]: https://www.embarcados.com.br/wp-content/uploads/2017/05/RISCV_length.jpg https://www.embarcados.com.br/wp-content/uploads/2017/05/RIS...
- FullyFunctional 6y agoThat's correct, the compressed extension (part of the desktop spec over my loud and persistent protest) is part of the desktop platform. This adds 16-bit instructions to the 32-bit instruction set. There are many reasons why this was a huge and very shortsighted mistake, but the most painful part of this is that you can now have an instruction spanning two cache lines. This has many awful implication and precludes many tricks that would make implementations faster. But it was important for Andrew Waterman to get his thesis work be mandatory part of the Unix platform, so here we are. ADDENDUM: It's near trivial for a linker to pad such that instructions don't span cache lines and that would have made this a lot less painful, but RISC-V refuses to specify the line size (it's implementation dependent), so now we suffer this nightmare.
- farseer 6y agoSo what would the RISC-V foundation do about this problem?
- fwsgonzo 6y agoIt really is the worst and most awful decision that RISC-V absolutely must retract, the sooner the better. We cannot have performance and compressed at the same time. There are other things about the C extension that make it extremely bad for emulators too. The good news is that we can ignore rv64gc completely and just build everything rv64g, if you control everything yourself. Personally for my RISC-V use I actully do control everything and because of this I can pretend the C-extension doesn't exist.
- FullyFunctional 6y agoYou would have to build and maintain your own Linux distribution, that is the problem.
- remexre 6y agoOr just use Gentoo (or presumably Nix), or another distro with support for custom build flags for packages, right?
- FullyFunctional 6y agoI don't know if any of these have RISC-V support, but I would be interested in hearing about it. I would actually love a good distro for RV32G which is arguably a better match for FPGA softcores (and dev boards with > 4 GiB of external memory are rare)
- remexre 6y agoLooks like Gentoo's is experimental [0, 1], and [2] looks relevant for NixOS. [0]: https://wiki.gentoo.org/wiki/Project:RISC-V https://wiki.gentoo.org/wiki/Project:RISC-V [1]: https://dev.gentoo.org/~dilfridge/stages/ https://dev.gentoo.org/~dilfridge/stages/ [2]: https://nitter.net/shlevy/status/965019194759761920?lang=en https://nitter.net/shlevy/status/965019194759761920?lang=en