10 ms·
RISC-V: The Last ISA?
- cgeier 4y agoI was visiting a space technology fair quite recently, and I was quite surprised to see how many companies are betting on RISC-V in that space (pun intended). On another note: does anyone have experience with a RISC-V board you can actually order right now?
- netr0ute 4y agoI have a LicheePi and a VisionFive 1. The LicheePi is really tiny and really cute, and it's no more than $30. However, it's essentially a Raspberry Pi Zero and so is super slow. The VF1 is like the LicheePi but hugely upgraded, as it's got a whopping TWO cores and a full 8GB of RAM. Both of these boards lack GPUs and so are painful to use as desktops because the CPU is doing all the rendering. Overall, they work shockingly well if you want a working RISC-V device.
- NewJazz 4y agoRecently announced are the BL808, which is supposed to be under $10, and the VisionFive 2, which is 4 cores and up to 8 GB RAM. Unfortunately neither features the vector extension. https://wiki.pine64.org/wiki/Ox64 https://wiki.pine64.org/wiki/Ox64 https://liliputing.com/visionfive-2-risc-v-single-board-computer-is-up-for-pre-order-for-56-and-up/ https://liliputing.com/visionfive-2-risc-v-single-board-comp...
- Vt71fcAqt7 4y agoVisionFive 2 has a GPU IIRC
- rjsw 4y agoI have been waiting for the PINE64 Star64 [1] to be released, planned to be next month. [1] https://wiki.pine64.org/wiki/STAR64 https://wiki.pine64.org/wiki/STAR64
- nanomonkey 4y agoClockwork's uConsole R-01 [0] can be ordered now, and ships in a few months. It looks like a fun option at $139. [0]https://www.clockworkpi.com/product-page/uconsole-kit-r-01 https://www.clockworkpi.com/product-page/uconsole-kit-r-01
- BirAdam 4y agoI have a Clockwork Pi DevTerm R-01 which uses the Allwinner D1. It's fun to mess around with.
- genpfault 4y agoOnly if they port Windows 10 to it!
- pencilguin 4y agoRV is an open-ended collection of ISAs. Do not doubt that the number of instructions will grow as large as is found in x86 and ARM, making a mockery of the "R". I am ready for the successor, Risc-6, already. It can retain most details of RISC-V while fixing its more glaring deficiencies. It is not a mistake to optimize an ISA for use in undergraduate courses, but probably is one to use identically the same ISA industrially. I don't know if the worst deficiency is the need to fuse up to 5 consecutive instructions to get useful operations per clock cycle to a competitive level. While fixing serious problems, numerous smaller incidentals could be patched, such as having chosen the architectural representation of "true" to be 1 instead of -1.
- Vt71fcAqt7 4y ago>Do not doubt that the number of instructions will grow as large as is found in x86 and ARM x86 has at least ~1,000 instructions,[0][1] maybe more depending on how you count. I can't believe RISC-V will approach that number. I couldn't easily find how many instructions arm64 has. But you may be right about RISC-6, only I think any "RISC-6" will just be RISC-V with less useful instructions depreciated [0]https://www.unomaha.edu/college-of-information-science-and-technology/research-labs/_files/enumerating-x86-64-instructions.pdf https://www.unomaha.edu/college-of-information-science-and-t... [1]https://fgiesen.wordpress.com/2016/08/25/how-many-x86-instructions-are-there/ https://fgiesen.wordpress.com/2016/08/25/how-many-x86-instru...
- cwzwarich 4y agoNumber of distinct mnemonics doesn't really determine ISA complexity. As an extreme example, how many AArch64/RISC-V instructions are there corresponding to an x86 MOV?
- deleted 4y ago[deleted]
- sparkie 4y agoIf you exclude AVX-512, the number is probably less than half that. And since Intel locked AVX-512 out of alder-lake processors, if you want a consume grade processor which supports it you would buy a Zen4 from AMD.
- Vt71fcAqt7 4y ago>First it’s likely to be a sign that CPU ISAs are, to some extent, done. I think this is not only correct but in a way almost obvious. Now that RISC has decidedly won out over CISC, well, what does RISC imply? To reduce the number of instructions to the minimum (or more accuratly to min/max the number). What we are left with are ISAs with few total instructions. This basically limits how much room there is for improvement, and the core instructions do not really change across modern RISC ISAs. In result, the best feature of RISC-V is not any technical feature but it's licensing features. If it gains mass adoption, nobody will ever switch to anything else because the ISA isn't the bottle neck of CPU performance anymore. A potential new ISA would have to have a different market such as GPU or ML to succeed.
- pencilguin 4y agoJudging from the number of instructions in all its necessary extensions, RISC-V is RISC in name only. ARM ("Acorn RISC Machine") instructions are as absurdly many as x86's, which does not even pretend to be RISC. So it is silly to say RISC has won.
- Veliladon 4y agoWhen you see RISC replace it in your head with "load/store architecture". Like when you look at the SIMD implementations on x86 "CISC" machines they're all load/store based instead of register/memory based like on the scalar and x87 implementations. This is what people mean when they say RISC has won.
- notacoward 4y agoThe practical definition that came through from reading Computer Architecture: A Quantitative Approach by the two people who did most to make RISC happen (Hennessy at Stanford and Patterson at Berkeley) had to do with this formula. work/second = work/instruction * instructions/cycle * cycles/second The "reduction" in RISC was in work (and complexity) per instruction, enabling even greater gains in the other two factors. I'm well aware that this isn't the official definition, but IMO it's the perspective that has held up best through all the intervening years. Load/store is certainly part of that. So are orthogonal instruction and register sets, exposed pipelines, software TLBs, etc. We've gotten away from some of those things nowadays, but in the early days they were necessary to drive performance despite lower work per instruction.
- Joel_Mckay 4y agoThe primary issue is the subsets of possible extensions to the core. Can it replace ARM? maybe in some roles that only require core features. Will it become the popular standard? probably not, as the groups failed to learn what ARM did wrong. Most popular ARM cores have many advanced features disabled in the compilers for a few reasons: 1. Some ARM ASIC advanced features would err on some chips, or were simply unavailable on some silicon revisions. 2. Deploying chip specific compilers is unsustainable commercially when your competitor can port in billions of dollars of work with gcc (as bad as it is) 3. a complete RISC-V implementation with floating point and DSP extensions should have been the minimum core. Without these features, it dropped the whole generation 1 chip hardware into the low-end mcu domain. A saturated market, that has already fragmented. Is there possible solutions? Complete a fully open 64bit core with mmu, fpu, and DSP. Then give the design to companies that have had a proprietary hardware issue for decades like microchip. Allowing companies to make proprietary design variants was a mistake. Happy computing =)
- deleted 4y ago[deleted]
- TheMagicHorsey 4y ago> 2. Deploying chip specific compilers is unsustainable commercially when your competitor can port in billions of dollars of work with gcc (as bad as it is) Is it really that prohibitive to have your own custom compiler with LLVM (and CLANG)?
- Joel_Mckay 4y agoThere are very good reasons llvm are not used in Real-Time systems. When running in multitasking environments it doesn't really matter. =)
- daworl 4y agoNot coming from a Real-Time background, I'm quite curious as to why? Do you have some sources to point me to?
- pohl 4y agoEven if Mill Computing can't get off the ground, eventually the patents will expire and someone will pick up on the ideas.
- sparkie 4y agoI'm pretty sure Mill computing will never get off the ground. If they were intent on producing something they would've started by now. The only thing they've worked on from the beginning is patents. And since now the focus is on RISC-V due to its openness, Mill will likely not see success unless they go the same route, because people don't want a locked down processor.
- zozbot234 4y agoMill is not an alternative to RISC-V; their insn set is a lot closer to hardware-specific microcode (much like VLIW architectures in general) than a truly general-purpose ISA. RISC-V admits of extensions, but aside from that it's fully general and most use of RISC-V will target standard ISA configs.
- dogma1138 4y agoEven if you intend to have a completely open project patents aren’t necessarily a bad thing. Patents prevent others form parenting it, even if prior art exists someone can still get a patent and the legal battle to revoke it can be costly if you don’t have large corporate backing. So getting patents and offering them under an open FRAND license is a good option, some of the most common standards we have work this way. Ofc if the only reason you get patents is to commercialize them later it’s going to be quite hard to get people to adopt your stuff.
- GLGirty 4y agoIt's a shame they haven't got anything to market. It's such a clever re-think of how instructions operate. If anything, they are probably too far ahead of their time. Reminds me a bit of Transmeta. "Code morphing" sounds very much like the instruction reordering that's standard now.
- deleted 4y ago[deleted]
- zasdffaa 4y agoMy (inexpert) view is that it might be the last ISA because a general purpose ISA will become less important. I see the cpu core as being more like a glue that connects together specialist hardware, so you have a wide SIMD number cruncher (like AVX) but probably off-core, likewise off-core compression (perhaps), encryption, graphics (already there really), prob matrix mult, all the fancy hardware for AI that's coming out now, possibly embedded prolog/logical deduction device etc. So the main ISA will be little more than a distribution device for allocating tasks to subunits, and no-one will care how it's put together. But I'm no expert.
- sparkie 4y agoThe primary issue here is that it is expensive to move data between processing units, and having them share memory has all the common problems with race conditions and cache invalidation. So while we can continue to squeeze more onto a smaller die, providing more capabilities on the same processor looks like it will win out for some time yet.
- zasdffaa 4y ago> The primary issue here is that it is expensive to move data between processing units I'm thinking of them all on a chip (or even same core) with external DRAM shared, and cpu cache shared. > and having them share memory has all the common problems with race conditions and cache invalidation That's pretty well a solved problem, or modern OS's wouldn't work. > providing more capabilities on the same processor looks like it will win out for some time yet I agree, for now, tomorrow's cpu will look like today's. But further out, I expect my view might perhaps start coming to pass.
- hajile 4y agoYou are arguing both sides here. You argue that moving data between discrete processors is bad then argue that sharing memory with processors is also bad. One of the two certainly MUST happen. GPUs seem to on the right path here as the trend toward a thread manager sending data to various CPU/ALU/SIMD/matrix/whatever units.
- thriftwy 4y agoI suggest that eventually it would make sense to move from octet-based ISAs to 64-bit word based ISAs. One such sizeof(int, long, float, double, char) is 1.
- sparkie 4y agoRISC-V is a variable-length instruction ISA, where instructions are a multiple of 16-bits.
- colejohnson66 4y agoWhat would be the benefit? Modern processors handle (what appear as) octet-based memory (despite having 64-bit words) all the time with no issues. In fact, your processor may only work on, say, 128-bit (16 byte cache line) memory accesses at a time. But if you insist, TI has some DSPs where CHAR_BITS is 16. They're supposedly a massive pain to use because you have to mask off the upper octet every so often.
- scottlamb 4y agoYou mean sizeof({int, long, float, double, char}) == 8, right? [edit: no, I guess not. sizeof returns char-sized units, not bytes. TIL.] But why? I don't anticipate we'll ever stop caring about using RAM efficiently, so I assert we need a way to operate on smaller types. The compiler could provide the traditional API I want this by masking/shifting without instructions specifically for smaller types, but (a) then there's a lot of extra masking and such to do anything, and (b) it would be bad for thread safety. IIUC Alpha was a bit like this in that read-write operations done from different threads on adjacent bytes within a word might clobber each other. Not great... And as colejohnson66 said, there are DSPs like this, but they are explicitly not designed for general-purpose programs.
- thriftwy 4y agoIf you're searching for a way to snap your data to power-of-two byte grid, you're already not using RAM efficiently.
- 4y ago