4 ms·
The main thing is they are interoperable. They all run the same basic software.
by brucehoult 4y ago
The main thing is they are interoperable. They all run the same basic software.
- colejohnson66 4y agoThat's no different from ARM, though.
- brucehoult 4y agoWell ... no. ARM has a ton of mutually-incompatible ISAs. You can't take assembly language or binary code between them AT ALL. Forget extensions -- just the basic instructions are incompatible. ARM are still today selling cores that run the original 1980s A32 instruction set plus 16 bit Thumb. You can find them, for example, in the Raspberry Pi A, A+, B, B+, Zero, Zero W, and Compute Module 1. Then there are cores that run only the 16 bit Thumb ISA plus a handful of extra instructions (because Thumb was not originally designed to be the only ISA on a CPU): Cortex-M0+ as in Pi Pico Then there are cores that only run Thumb2: Cortex-M3/M4/M7 Then there are cores that only run A64: Cortex A34, A65, A510, A715, everything from Apple since the iPhone 8, Cavium, probably Nuvia. RISC-V has only two variants: 32 bit and 64 bit. And actually almost all the instruction mnemonics and binary opcodes are the same between them. The only difference is the size of the registers. With a little care you can run 32 bit RISC-V code on a 64 bit CPU, not in a special mode but just sticking to the top and/or bottom 2 GB of address space. You can easily write assembly language code that runs on both 32 bit and 64 bit. It is easy to use the same compiler for both.
- deleted 4y ago[deleted]
- jml7c5 4y agoIs interoperability a requirement for all RISC-V implementations? I thought one of the draws for RISC-V was that adding custom instructions doesn't require an architecture license.
- brucehoult 4y agoIf your chip doesn't run standard RISC-V instructions then you can't use the trademarked "RISC-V" name. Standard operating system, standard binary-distributed software packages, your own programs compiled with standard compilers with default options, will always run on all RISC-V implementations, forever. Of course if you go out of your way to use your current vendor's custom instructions (if any) then you're trading short term gain (possibly) for long term pain if you ever want to move on. Always make sure you also have a generic version of that code that runs on standard chips (if not other ISAs too).
- goodpoint 4y agoFirst, people often imply that everything around RISC-V is open source, which is not the case (unfortunately). Second, no they are not always interoperable - custom extensions to the ISA are allowed.
- Brian_K_White 4y agoI can take a copy of linux and modify it to produce a kernel that can't run anyone else's binaries. This is irrelevant to the essentially infinite value created by linux being open in the first place. You still have access to the same linux I started with to make my custom one. I didn't need anyone's permission to modify it for my purpose, and you don't need anyone's permission to take my same starting point and 99.99% of the engineering in my product. This is just from the basic availability like MIT/BSD where I don't have to give back, not even counting the extra boost that gpl or cc-sa creates. I don't think immediate interoperability is a very important part of this. It's already good enough that the open nature makes interoperability possible if anyone happens to need it and aren't getting it from a vendor. Same goes for things like extended support or adding or removing features. If a manufacturer stops selling a chip you want, or triples the price, or adds hostile features, or any of the other ways manufacturers use to control consuption, anyone else is able to start supplying the same thing. It still costs resources to do it, but there is no artificial block because of patents.
- goodpoint 4y ago> I can take a copy of linux... We all know this already, thanks... > anyone else is able to start supplying the same thing Not if there's a custom extension. Additionally, "supplying the same thing" is equivalent of asking someone to write a perfect drop-in replacement for the Linux kernel, to connect to your example. It's not that simple, by far. > It still costs resources to do it, but there is no artificial block because of patents. Actually, no. CPU IP can be patented and no, RISC-V does not prohibit it. You are asking for someone to design a new CPU, while also supporting whatever custom extension already exists, while also navigating the huge patent minefield.
- 4y ago