Hacker News Reader

Comment by pencilguin | Hacker News Reader

RV 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.

View on HN

> 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".

https://danluu.com/risc-definition/

Number of instructions isn't what is "Reduced" in RISC, but rather the complexity of instructions: Single-width opcodes with very few addressing modes, such that pipelining is easy and taking exceptions is not as painful as it is when your opcodes have lots of ALU state, like with indirect addressing and opcodes that mix addressing modes with their own ALU operations.

RISC is also somewhat nebulous, with some ISAs being "more RISC" (RISCier?) than others, and some RISC ideas (architectural delay slots, integer multiplication and divide opcodes requiring their own registers) eventually getting dropped entirely as chip technology moves on.

> 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 that a good ISA needs to be optimized for undergraduate courses to be used in them: MIPS is famously used in H&P and it has quite a following to this day, just not on the desktop or in servers. Was RISC-V optimized for use as a "model organism" like that?

Let us not forget SPARC's register windows.

I don't know if you could say RISC-V was optimized, as such, for undergraduate courses, but historically that was its design target. That said, there was a lot more attention to extensibility via regularized instruction set extensions than the undergraduate target demanded.

RISC-V's permanently-zero register is akin to other RISCs' special multiplication registers.

The number of instructions is already becoming quite large if you consider the V and P extensions. Here's the vector instructions: https://github.com/riscv/riscv-v-spec/blob/master/inst-table...

The set of RISC-V features that each CPU supports is going to be so widely varied that you will need dozens of compiler switches to make full use any processor, and since most software will be compiled for the lowest-common-denominator, some capabilities will go largely unused. This is already the case with x86 with AVX-512, the full capabilities are only leveraged in specific workloads.

Either that or developers are going to rethink the way they distribute software. No longer as compiled binaries, but as an IR which is then compiled on each processor, since the best way to learn what features are supported by any CPU is to query them on it.

That is how mainframes and micro-computers have been doing since forever.

I guess it is time for another great idea for VCs, I know, let's create a WASM runtime for RISC-V.

Or OS authors are going to have to rethink how they handle illegal instruction exceptions, by patching the calling program to call into an emulated version when running on hardware that lacks support; this would allow program authors to choose whether to favor the least common denominator (and give up performance on more capable processors) or to target best possible performance (but take a hit on more limited machines). An ABI that reserves a few registers for this sort of emulation, or a couple or reserved architectural registers, could help a lot.

Nobody is going to be patching calling programs like this. There may be OS emulation in machine mode (saving and restoring the register file) to pretend to be a "generic" RISC-V.

I don't think he is suggesting patching individual programs PPC for example simply faults and traps to the OS for any number of illegal instruction or invalid alignment situations (which may vary based on core implementation). Then the kernel looks at the faulting instruction, emulates it, and resumes the program. Its absolutely terrible for perf because all the internal state has to be serialized to the architecturally visible state in order to update it, and resumes.

Nope, I was very much suggesting the former.

The PPC approach works, but it has significant performance costs over and above instruction emulation. I've shipped PPC software that you may have used that uses both approaches, as appropriate.

Eek, at that point you might just as well try and ship an IR with a JIT/AOT type pass during install, first run, etc.

Its possible we know each other IRL... lol

> Nobody is going to be patching calling programs like this.

Oh the things I've shipped...

Or you know, you mandate most of the stuff in the core arch document with the assumption that on tiny cores that lack.. say multiply instructions its handed by.. wait for it... microcode.

Which actually given the toy CPU's i've implemented is pretty easy to do even if your talking something that fits on a small/medium sized FPGA.

Illegal instruction traps are a lot worse/harder to get right than just cracking an unsupported opcode into a string of microops, particularly if the arch has simple addressing modes that themselves won't ever need to be part of multiple micro ops. AKA you won't have to deal with fault handling in the middle of a sequence. And even worse, the optimal sequence is likely diffrent for every tiny micro arch change, or even change in memory subsystem characteristics. So it needs to be tied to the core and associated memory subsystem, which on a popular arch implemented across the scale of platforms you find x86/arm is going to be unachievable without lots of unoptimal code being used.

Microcode is an option here, but (having also implemented small microcoded cores on an FPGA) it's easy to be misled about ASIC costs here. ROM on an FPGA is very cheap proportional to logic, because it's implemented in various high-density (compared to the LUTs) memory blocks. A very small RISC-V ASIC implementation can easily be smaller than the ROM that would be necessary to microcode a complex ISA extension, ignoring the cost of the sequencer, while the same design in an FPGA might have zero change in area for the ROM.

On RISC-V it doesn't have to be true microcode. You could trap and emulate in M mode, transparently to the running OS.

This won't work, because the emulation will be too slow to provide usable fallback.

This kind of approach has been used in the past, but the problem is that the overhead of trapping invalid instructions is massive compared to almost anything you do in an instruction, to the point that if you actually use such instructions, your program will be completely unusable on platforms that don't provide them.

The suggestion isn't to implement, say, Vector Add in an illegal instruction handler; instead, it's to use the illegal instruction handler to replace the Vector Add instruction with a jump to a user-space emulation routine. The emulation routine may /also/ be too slow to be usable, but the trap overhead is a once-through cost, not a per-execution cost.

Doable, but you end up having to generate a unique sequence for every single instruction in the program because for something like 'mul r1,r2,r3' your going to have to move the information about which registers are being multiplied somewhere else, as well as encode the return address, and as you mentioned the register spill/etc is going to be costly or you have to reserve a couple registers for it.

There are a lot of problems doing it that way too, particularly if your on a small microcontroller with limited ram.

It is a good way to turn optimizations into gross pessimizations.

> Or OS authors are going to have to rethink how they handle illegal instruction exceptions, by patching the calling program to call into an emulated version when running on hardware that lacks support; […]

It can be done at the OS kernel level, but it does not have to. The usual place to do it in is libc – by virtue of weak symbols in dynamic libraries.

At the linking time, the ld links the executable against a generic function, e.g. __mul512_xyz, and __mul512_xyz is a weak symbol that points to a generic fallback implementation of the 512-bit wide operation in libc.so. Now, at the process startup time, the libc initialisation code looks up the CPU revision, attempts to locate a CPU revision specific, optimised version of, e.g. __cpu_family_abc_123_mul512_xyz, and links the optimised version of the function in. I have made names up but, fundamentally, the idea is that.

> […] this would allow program authors to choose whether to favor the least common denominator

… and this is where I perceive a problem with RISC-V – based on my current knowledge of the ISA in question. Being an open source and a free ISA, RISC-V places no obligation on two (or three, or more) distinct CPU vendors to implement the same set of ISA extensions (other than the foundational one). Therefore, effectively we are talking about every possible permutation of all current and future, extra, ISA extensions that would have to be supported in libc, and it will make it the dynamic re-linking at the runtime either difficult or not possible (not easily, anyway), and the RISC-V specific optimisation effort(s) will go out of the window.

The foundation releases profiles.

For example, the RVA22S64 means it's a 64-bit application processor with supervisor mode complying with the 2022 recommendations. It has a bunch of specific requirements about RAM layout, cache instructions, being little-endian, and so on all specified so code is portable. Likewise M (mul/div), A (atomics) F (32-bit float), D (64-bit float), C (16-bit instructions), and some misc bit manipulation and other instructions MUST be implemented.

At the same time, it specifies optional extensions like V (vector), Zfh (16-bit floats), scalar crypto, H (hypervisor), and some optional supervisor stuff.

If you want to claim to be a RISC-V chip, you MUST implement the specs exactly (else be infringing on their trademark).

If you want to enter the desktop ecosystem that is being started, you'd better support the extensions they specify in RVA22S64 (or newer standards) otherwise people aren't going to buy your chip. You can implement proprietary stuff provided it doesn't conflict with the standard, but normal software isn't going to use those features, so you are probably just wasting transistors.

All the work on unifying stuff like UEFI is because the companies involved are serious about a compatible standard moving forward. It's in all the biggest player's best interests to stick to the spec which is all that matters for end users as it guarantees a consistent experience.

https://github.com/riscv/riscv-profiles/blob/main/profiles.a...

> At the same time, it specifies optional extensions like V (vector), Zfh (16-bit floats), scalar crypto, H (hypervisor), and some optional supervisor stuff.

It is the optional extensions that concern me the most, not the foundational ones. Cryptographic functions, for example, can be optimised using a vector instruction set, a crypto accelarating instruction set, or via a combination of both. If something better comes along (hypothetically), it will become another, new, instruction extension in the future. The libc runtime now has to do significant guess work to support a permutation of all available instruction extensions (or fall back to a generic, unoptimised, version when none are available), not to mention the libc blowing out quite substantially for RISC-V – in size and in complexity.

> If you want to claim to be a RISC-V chip, you MUST implement the specs exactly (else be infringing on their trademark).

I admire your sense of optimism, but I can nearly guarantee you that a less diligent Chinese RISC-V vendor will not give a flying fig about the trademark and will even cut those extensions out that form the foundational set – if it makes the chip cheaper to design and manufacture. Which has happened in the past with some ARMv7 (or ARMv8?) designs, and which we are nearly guaranteed to see in IoT devices (at the very least). I will not be surprised if a CPU vendor chooses to toss the D extension out and stick with the F extension only for niche case solutions, and it will not be possible to enforce it.

> I admire your sense of optimism, but I can nearly guarantee you that a less diligent Chinese RISC-V vendor will not give a flying fig about the trademark and will even cut those extensions out that form the foundational set – if it makes the chip cheaper to design and manufacture

Who cares. Is HP going to buy a cheap Chinese chip that causes user software to randomly crash?

If that company is going to compete, maybe they want a 5nm chip. They design the chip and get past sanctions, but now have to pay a half-billion to get everything ready for fabrication and then another 2B for that 100k wafer discount.

Now they have huge quantities of chips that are too expensive for the Chinese market and too broken/incompatible for the American/European market. Sticking to the spec -- even if it's just microcoded -- is way better than the alternative.

> It is the optional extensions that concern me the most, not the foundational ones.

Crypto is optional because they believe scalar crypto probably isn't the way forward. They are working on vector crypto, but it's not finalized. Likewise, the vector extension was released too close to the 2022 deadline to force compliance. Look at web standards. Where backward compatibility matters, it's WAY better to be conservative than to mess up forever.

RISC-V chips with decent performance likely won't be out until 2024. By that time, these extensions will be well-established. Companies will have had time to implement them and they will become required.

> I will not be surprised if a CPU vendor chooses to toss the D extension out and stick with the F extension only for niche case solutions, and it will not be possible to enforce it.

This is a particularly unlikely outcome because JS support requires double-precision. Even tiny ARM cores in phones over a decade ago had support for 64-bit floats. If you want to save area, cutting cache or wider SIMD gets you way more bang for your buck.

There are only 2 major versions of RISC-V for desktop processors (64-bit with privileged mode) with a third likely coming in 2023 or 2024. That's definitely better than the competition.

x86 has about 35 new extensions in the last 20 years excluding AVX-512 which adds another 20 or so.

It's also no different from ARM where you have (currently in widespread production) ARMv6, ARMv7, ARMv8 32-bit, ARMv8.0, 8.1, 8.2, 8.3, 8.4, 8.5, 8.6, 8.7, 8.8, ARMv9.0, 9.1, 9.2, 9.3, and some ISA extensions that don't fit neatly into ANY of those. Then ARM also announced (no doubt due to pressure from RISC-V) that custom instructions are also allowed.

This is effectively a solved problem for ARM and x86. It will be even less of an issue for RISC-V.

There's far more than 2.

Even just taking RV32I, you have M, A, F, D standard extensions which are all optional. A CPU could include any combination of these, so you have 3! possible instruction sets off the start line. But let's assume we're working with G (which means all of IMAFD)

Many PC grade processors will support some or all of extensions B (bitmanip), T (transactional memory), P (packed SIMD), V (Vectors), C (compressed instructions), RV64I, RV128I, Q (quad floats), and not to mention all the non-standard extensions.

See: https://groups.google.com/a/groups.riscv.org/g/isa-dev/searc... for non-standard extensions.

You also have vendor specific extensions such as those from Huawei: https://github.com/riscv/riscv-code-size-reduction/tree/main...

As an application developer, finding the right set of features for your users will mean having to distribute many different binaries unless you stick to plain old RV32G, which has the capabilities of a ~20 year old x86 processor.

If you assume all standard extensions, it only takes a processor to lack 1 of them for the program to not work.

You can test for feature sets before running any of these instructions, but this is more commonly done at compile time via the preprocessor. This is what I mean about developers changing their perspective. It will be necessary to move all of those #ifdef __FEATURE__ to runtime, unless you recompile on each processor.

>As an application developer, finding the right set of features for your users will mean having to distribute many different binaries unless you stick to plain old RV32G, which has the capabilities of a ~20 year old x86 processor.

Do you mean RV64G? Linux doesn't really support 32 bit anymore. Even then the VisionFive 2 supports rv64gc And the whole board sells for ~50 USD. The d1 supports RV64GCV (admittedly v. 0.7) and sells for even less. I don't think any Linux CPUs will skimp on C and most will have V and B in my opinion.

The set of RISC-V processors is going to be far more diverse than you are expecting. There's already dozens of open cores, both 32-bit and 64-bit, with varying support of standard extensions.

Assume RVG64GBCV, do we skip P, T, Q? What about J (extensions for dynamic language runtimes)? Do we just ignore those capabilities and leave applications to not get the best out of the machine?

If we stick to current status quo, of having #ifdef __FEATURE__ scattered through our code, we would want a source based distribution like Gentoo to make sure we get the most out of our machines, so we can check which features are present and set all the required compiler flags.

Otherwise, we could have runtime checks for features, but this will require changing the way applications are commonly written, because we don't want to be checking for the presence of features everywhere in code. We only want to check once on application startup.

It seems like you didn't even bother to read the linked spec. The result is a bad faith argument on your part where you are choosing to ignore the clearly stated facts. You also ignore the reality of x86 and ARM extension fragmentation.

If you want people to use your chip in an interchangeable way (how ALL desktop processors want to work), then you'll implement RVA22S64 which automatically requires you to support a bunch of extensions.

If you want proprietary or cutting-edge extensions in your chip, feel free, but software developers will be using the spec and your extras will just be ignored and drive up your cost for no real value.

If you violate the specs you claim to support, you are liable for trademark infringement as use of the trademark requires adherence to any standards you claim to be supporting. At most you could claim "RISC-V compatible", but that will just become code for "doesn't work with normal software" and nobody will buy your chips and you'll have wasted a huge sum of R&D money.

This is better than x86 or ARM which you conveniently ignore. x86 for example has some 55 extensions released in the last 20 years. Some like SGX or FMA4 only have support of a small subset of chips. Some have disappeared. Many aren't supported by older chips still commonly in use. ARMv8 has TEN different version PLUS more optional extensions PLUS the ability to add custom instructions. There's also FOUR versions of ARMv9 too (leaving aside the still very popular ARMv6 and v7).

If fragmentation were such a huge problem, then certainly nobody would be using these ISAs. Of course, people use them everywhere which completely disproves your argument.

>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-t... [1]https://fgiesen.wordpress.com/2016/08/25/how-many-x86-instru...

Number 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?

If 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.

>If you exclude AVX-512, the number is probably less than half that.

This paper seems to say there are thousands, am I reading it wrong?

>There are two primary barriers to producing a formal specification of x86-64. First, the instruction set is huge: x86-64 contains 981 unique mnemonics and a total of 3,684 instruction variants.[0]

[0]https://dl.acm.org/doi/10.1145/29809

AVX-512 is huge. See https://www.intel.com/content/www/us/en/docs/intrinsics-guid...

That's 1k instructions ONLY in their most RISC-like form. It also generally excludes stuff like MOV effectively translating into countless instructions when you start looking at all it's variants based on source/destination type, data types, concatenated instructions tacked on, etc (MOV alone is technically Turing complete[0]).

All that stuff is spelled out in the instruction and while it may have the same mnemonic, the actual binary output is different. In these terms, the actual number of instructions is likely in at least the tens of thousands.

In comparison, RISC-V splits off loads and stores into separate instructions. It further splits off each size of load/store into even more instructions. Start clumping all of this stuff together and RISC-V instruction count would also plummet.

[0] https://stackoverflow.com/questions/61048788/why-is-mov-turi...

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.

What issues does that cause? Finding it difficult to web search for…

The only one I recall of the top of my head is that it makes `first & bool | second & ~bool` faster, since you don't need a `dec r0` instruction to turn {0,1} into a bitmask. Anyone else have a better guess?

"that & bool", yielding either zero or "that", is common enough, by itself, to matter.

Huh, good point, actually; I'd overlooked that, eg in `sum += filter[i] & elem[i]`.

I always pronounce RISC-V in my head as "RISC VEE". Even "RISC OR" is easier for me. If they call the successor RISC-VI then I'll probably mentally autocorrect it to "RISC-VIM" anyway, it's a lost cause.

I pronounce it "riskive", myself. Had there been a RISC-IV it would have been pronounced the same, so it is lucky there wasn't one.

Reply on news.ycombinator.com