Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

RISC-V: They Should Have Known Better

dmitry.gr

Post reply on HN
Print view View original

241–250 of 467 posts

Re: RISC-V: They Should Have Known Better

#241

Post by adrian_b »

aengelke wrote: post #219
amluto wrote: post #196

Earlier quoted context omitted.

In x86 land, there are, as a practical matter, four ISAs: real/v8086 mode, 16-bit protected mode, 32-bit protected mode, and 64-bit “long” mode. Machine code targeting one of these will be executed correctly by the CPU as long as the CPU is in the right mode. (Really it’s messier — there are the CS.D, CS.L, and SS.B bits plus the control bits for v8086, protected and long mode, but this barely matters.) Sure, this is…

> 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, that's not completely true. Intel 64 and AMD64 are not identical and they certainly have encodings that behave differently. As an example: f3 41 90 is pause on Intel, but xchg r8d, eax on AMD (granted, this is not a canonical instruction encod…

For those less familiar with x86, the example instruction encodings that are interpreted differently on Intel and AMD are not base encodings, but instruction encodings modified with prefixes.

The x86 ISA includes a great number of bytes that are used as instruction prefixes, many of which are obsolete. The problem is that the effect of prefixes upon instructions has never been completely defined in any Intel or AMD documentation. The prefix effects have been documented for some instructions, but they were left unspecified for most other instructions.

This has lead to divergent implementations in the unspecified cases. Well-behaved compilers should not generate such undocumented combinations of instruction prefixes with base encodings.

Re: RISC-V: They Should Have Known Better

#242

Post by achierius »

dreamcompiler wrote: post #138
spicyjpeg wrote: post #67

Earlier quoted context omitted.

RISC-V is in many aspects just legally-distinct-MIPS, from the base instruction set all the way up to how certain extensions introduce kludges that are very reminiscent of later MIPS additions. While I do somewhat agree on the fact it was a huge missed opportunity to improve upon MIPS's technical flaws in order to realistically compete against the likes of ARMv8, we still have to keep in mind that the primary driving…

> it still is a much better starting point than coming up with your own bespoke ISA 5 years ago I would have agreed with this but now I'm not so sure. We live in an era where you can tell a robot "Here's some C code. Design a 64-bit ISA, write the Verilog to implement it in an FPGA, write a C compiler for it, and use it to compile the C code I showed you earlier." And now your ISA and your compiler are part of your m…

How is that a moat, if anyone else can do the same thing?

And how would you get this all into Clang? Nobody wants to use your custom compiler. It's certainly not going to be as fast as Clang!

Re: RISC-V: They Should Have Known Better

#243

Post by ChuckMcM »

wren6991 wrote: post #43

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…

> RISC-V is .. fine.

Yeah, so was 8051 and it sucked too :-). I appreciated having this rant all in one place. Ranting against bad architecture is always cathartic and absolutely useless since the people who built and now champion the bad architecture are invested so one's rant simply irritates them. And like the parent comment here, I too find RISC-V "useful" in that it has sufficient tooling to make most everything foundational 'out of the box' rather than me having to build it.

Perhaps the most interesting thing is that RISC-V shows just how ISA agnostic people are, as long as you have cross compilation with the gcc suite and an open source way to program and debug things. Before RISC-V, working on a bespoke ISA and computer architecture was never going to "go" anywhere except perhaps into a paper or conference talk. Now there is evidence of a non-zero chance of it going mainstream. :-)

Re: RISC-V: They Should Have Known Better

#244

Post by therealcamino »

aappleby wrote: post #223

Having written a few RISC-V cores, worked on a chip design project that used RISC-V cores, and generally being OK with the architecture in real-world use cases: What the heck is this guy's problem? Just about every thing he mentioned as a problem is not a problem in practice. Too many options? Who cares, you're not trying to write code that runs on every possible configuration. Either you're writing embedded firmware…

Thanks for this. RISC-V brings out the armchair critics for some reason.

Re: RISC-V: They Should Have Known Better

#245

Post by wk_end »

_0ffh wrote: post #212
phire wrote: post #114

Earlier quoted context omitted.

Yeah, very much legally distinct MIPS, at least as a starting point. The biggest tell is the mnemonics. While RISC-V takes a bunch of ideas from other places, and cleans things up, it copies a lot of mnemonics straight from MIPS. But it also copies a lot of other ideas from MIPS, like the absolute distain for flag registers.

>absolute distain for flag registers It's worst aspect maybe.

The RISC-V specs insist that this is important for simplifying high performance designs, because a flag register is a single piece of shared state that instructions are constantly (and often inadvertently!) touching. This necessarily introduces hazards and serialization.

I don’t know enough about high performance microarchitecture design to evaluate that argument confidently, but it seems to make sense to me.

Re: RISC-V: They Should Have Known Better

#246

Post by adrian_b »

brucehoult wrote: post #152
wren6991 wrote: post #80

Earlier quoted context omitted.

The RISC-V fusion arguments from back in ~2018 didn't really pan out. A lot of those fusion opportunities are just instructions now. slli + add? Zba (sh*add). slli + srli? Zbb (zext.*). slli + srai? Believe it or not, also Zbb (sext.*). Look at that pair of RVC instructions you used instead of a single 32-bit opcode. They are: * Taking up valuable compressed instruction space; each compressed codepoint has an opportu…

And all modern high performance Arm and x86 cores do more fusion than RISC-V cores that are currently on the market. Intel has being fusing `CMP` and `Bcc` since Core 2 and AMD since Zen 1. This is - already one instruction in RISC-V - an *extremely* common pattern, often occurring once every 5 or 6 instructions.

The combined comparison-branch instructions of RISC-V are its only good feature in terms of instruction encoding design.

This allows a significant code size reduction in comparison with ARM Aarch64, but unfortunately for RISC-V this advantage is frequently not enough to compensate its other defects, especially when reliable code is desired, i.e. where overflow detection is necessary.

Despite that from this point of view ARM Aarch64 is weaker, that is not an intrinsic problem. Aarch64 has an unused block of encodings inside the block used for branch instructions. I have verified that in the currently unused block it is possible to encode not only compare-and-branch instructions covering all the conditions that exist in the RISC-V ISA, but also additional conditions that are missing in RISC-V, where their absence is a problem, like testing for overflow.

I do not know why nobody at Arm had thought to make this extension yet, but it would be very easy to eliminate the only advantage that RISC-V has over Aarch64.

Re: RISC-V: They Should Have Known Better

#247

Post by aengelke »

adrian_b wrote: post #241
aengelke wrote: post #219

Earlier quoted context omitted.

> 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, that's not completely true. Intel 64 and AMD64 are not identical and they certainly have encodings that behave differently. As an example: f3 41 90 is pause on Intel, but xchg r8d, eax on AMD (granted, this is not a canonical instruction encod…

For those less familiar with x86, the example instruction encodings that are interpreted differently on Intel and AMD are not base encodings, but instruction encodings modified with prefixes. The x86 ISA includes a great number of bytes that are used as instruction prefixes, many of which are obsolete. The problem is that the effect of prefixes upon instructions has never been completely defined in any Intel or AMD d…

> The problem is that the effect of prefixes upon instructions has never been completely defined in any Intel or AMD documentation.

In case of the jump example, the effects are documented by Intel and AMD and they still differ. Point of the GP was that all CPUs don't decode valid instructions differently, which is not fully accurate as shown by the examples; and some of these differences are also explicitly documented.

It's also not accurate that most prefixes are obsolete when most see regular use today (66 size override for 16-bit operations, f2/f3 for string operations, 66/f2/f3 mandatory prefix for many (e.g. SSE) instructions, 64/65 fs/gs override for thread-local storage access and per-thread kernel storage, f0 lock for atomic operations, 3e (again) for branch-taken hint, 4x REX prefix for r8-r15 and 64-bit operand size; one can argue that the 67 address-size override is useless, and only the 26, 2e, and 36 are ignored; I don't count VEX/EVEX/REX2 as prefixes but more as opcode escapes).

Re: RISC-V: They Should Have Known Better

#248

Post by adrian_b »

brucehoult wrote: post #151
mhh__ wrote: post #65

Earlier quoted context omitted.

The ISA not mattering I think isn't as true when you account cost e.g. in a huge OOO cpu all the fusions and so on are afaict fairly doable but if you are on a cheaper / worse CPU all those extra bytes in the instruction stream do add up.

Performance is subject to debate and quality of implementation and whether such implementations will ever be financed and made ... But *code size* is a demonstrable fact. RISC-V has by far the most compact code of any popular 64 bit ISA, and that was true even of RV64GC. The gap has only widened with RVA23. Just load up your favourite OS (e.g. Ubuntu 26.04) for various ISAs in Docker and compare the `text` size of va…

That is false.

All the claims of the RISC-V fans that I have seen in the past compared the compressed variant of RISC-V with the uncompressed variants of the other ISAs.

Most other ISAs, like ARM, POWER and MIPS, also have compressed variants and if RISC-V were compared with those, it would lose.

Moreover, if you use safe compilation options with RISC-V, the code size explodes in comparison with any other ISA, because I am not aware of any other ISA introduced after 1974 that lacks hardware overflow detection, which multiplies by 3 or more the number of arithmetic instructions required for any computation.

This is a new claim that I see now, that RISC-V can be more compact than Cortex-M33 (i.e. where both use a compressed encoding), which I find unbelievable, because if I assembly by hand almost any function that is not too simple I can make it shorter on Cortex-M33 than on RISC-V and I doubt that the current compilers are so bad that they generate much worse code.

RISC-V is shorter on any code that has a lot of branches and negligible computations, but for anything more complex, with many computations and complex data structures, it loses.

Re: RISC-V: They Should Have Known Better

#249

Post by jacksons5f »

minetest2048 wrote: post #175
jacksons5f wrote: post #168

Earlier quoted context omitted.

100% agree. Is it ideal? Nah. Can you launch successful products with it with only a moderate amount of headache? Yep! Heart of our system that powers a household name devices is a RISC-V multi-hart SoC. It does quite a bit - a little bit of compute, a little bit of DSP. Definitely not the best fit, but cheap and works well enough. The buggest gap for us was the lack of the decent debugging featurea like ARM's Data W…

I'm guessing you're using one of RISC-V ESP32 variant (ESP32-C3?)

Nope, that is a custom SoC that had SiFive RISC-V cores from the times when they still did embedded stuff.

Re: RISC-V: They Should Have Known Better

#250

Post by trollbridge »

adrian_b wrote: post #238
dreamcompiler wrote: post #138

Earlier quoted context omitted.

> it still is a much better starting point than coming up with your own bespoke ISA 5 years ago I would have agreed with this but now I'm not so sure. We live in an era where you can tell a robot "Here's some C code. Design a 64-bit ISA, write the Verilog to implement it in an FPGA, write a C compiler for it, and use it to compile the C code I showed you earlier." And now your ISA and your compiler are part of your m…

Designing a good 64-bit ISA, much better than RISC-V, is easy. There are thousands of people who could design such an ISA in a couple of weeks, without any AI assistance. The hard part, which has always been the moat of RISC-V, is writing all the required support software for a new ISA, i.e. all the utilities from binutils (assembler, static linker, ELF/DWARF utilities), compiler backends at least for gcc and llvm, d…

The effort to support architectures is now minimal with AI assistance. I made a hobby architecture (based on Intel, but with some changes; I was making an "alternate history" as if a few decisions in the past had been different) and it was pretty much trivial to spit out support not just in gcc and llvm, but I also, for fun, made WATCOM backends and a few other things.

With that said, RISC-V is a nice baseline for designing another architecture. Start with RISC-V, and go from there.

Post reply on HN