Hacker News Reader

Comment by wren6991 | Hacker News Reader

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 a simple implementation.

I think Dmitry's points are largely on-target, though I have filed my usual statutory complaint that every rant that includes a bitfield diagram for the RISC-V J format should accompany it with a similar diagram for the Arm T32 BL encoding.

View on HN

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 force behind RISC-V is and has always been fixing the legal flaws instead.

There is indeed plenty of value to be had from a standardized (if poorly) PlayStation-1-era instruction set you can safely implement in silicon with no risk of a zombie company husk coming after you, especially in the ASIC space where (as Dmitry himself recognized) anything is better than an 8051 core you need a copy of Keil C51 and a lot of patience to write code for. Even if you end up having to add custom extensions, it still is a much better starting point than coming up with your own bespoke ISA, building a toolchain around it and convincing potential customers that your proprietary architecture is worth the effort to deal with over another vendor's licensed Cortex-M cores with full GCC and LLVM support.

Has it been proven that no patent troll holds a patent covering RISC-V?

Of course not because that's impossible to prove.

You might find this relevant: RISC-V Genealogy (2016) https://riscv.org/wp-content/uploads/2025/02/EECS-2016-6.pdf

Or in poster form: https://riscv.org/wp-content/uploads/2025/02/RISC-V-Instruct...

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.

Inadvertent touching is fixable, ARM for example did it with the S bit (though on AArch64 it's slightly more complicated).

I regard it as a mistake of RISC-V. The flag register was invented for good reasons, and dropping it is a trade-off I personally do not think is worth the downside.

I don't agree with the argument.

By the time you have an out-of-order core, there is already so much shared state you have to synchronise, and you have a bunch of complex mechanisms for dealing with it. Adding a flags register doesn't really add any more complexity, it's just a small bit of extra state attached to it.

And we already have the solution, it's register renaming. We are already renaming all the GPRs and FPRs, and we are probably also renaming part of fscr (because turns out, RISC-V does have flags for floating point operations), maybe a few other bits of state. So we just use the existing renaming mechanism to rename a bank of flags registers; That single logical shared flags register is actually backed with a bank of non-shared physical flags registers, neatly solving all concerns.

Sure, the renamed flags do take up a bit of die space. But IMO they don't add any extra design complexity, and shouldn't have any performance impact on maximum clock speed.

RISC-V isn't quite as disadvantaged by the lack of flags as some might suggest (and I wouldn’t say the lack of flags is RISC-V’s worst aspect), but there are a few sequences (add-with-carry, some conditional-moves, detecting overflow) where RISC-V is forced to burn an extra instruction or two to deal with the lack of flags, and IMO eliminating that would be worth the cost of slightly more die space.

Also, avoiding the need for dedicated compare-and-branch instructions would free up encoding space for other things (including larger range on branches)

  By the time you have an out-of-order core

You're thinking too high level and high performance/high power use -- think about minimal embedded controllers, no need to add the complexity of O3 exe, but there's still the possibility of getting to optimize the hazards and execution without the shared state.

Doing the deliberate choice of leaving flags out of the core and then using them in the fp ops ext will nudge designers towards "this is probably the point you should think about out-of-order execution"

If the spec was only arguing that avoiding flags allowed for simpler implementation of minimal in-order pipelines... I might actually agree with it.

But the argument in the spec explicitly uses the "added complexity to out-of-order microarchitectures" as a part of the justification for not having conditional move (and flags). It's the most commonly parroted part of the argument (see above) and the part of the argument I'm responding to.

I actually agree with much of the spec's argument. The cost of not having flags is pretty low, the MIPS approach does work pretty well, and it does simply things.

I'm just not sure it was the right trade off, and I strongly disagree with its attempt to use OoO cores as part of the justification.

Without knowing it, you're thinking at neither high nor low level. You've accepted at face value claims made by RISC-V architects about how to design an ISA for low level embedded controllers, but they weren't actual experts in that field. Instead, they were largely academics.

When you read their stuff, they're constantly overestimating the value of ultra-minimalist CPU designs in the modern context. In fact, they often show little understanding of the real impact of ISA design decisions on implementation complexity, so some of their decisions don't even make sense as minimalist decisions.

To expand on the low value of minimalism: even in trailing edge process nodes, if you're designing something on the scale of a simple single-issue in-order 32-bit RISC core targeting no particular frequency, gates are essentially free. The RISC-V guys are badly out of touch. If minimum gate count mattered as much as they think it does, there would still be a thriving market for 8-bit microcontrollers. Instead, they're steadily losing market share to 32-bitters, even in applications where an 8-bit µC would be more than enough. It's not the 1980s, you don't have to struggle to fit a featureful 32-bit core into a single die anymore, but they're hellbent on relitigating that era's debates.

> Adding a flags register doesn't really add any more complexity, it's just a small bit of extra state attached to it.

I agree in general, we do however see that the cost of flags isn't free by the fact that most modern Arm processors only support ADCS on half of the ALUs supporting ADD. If it was free/negligible, you would see ADCS support on all ALUs.

Yeah... I more mean that it shouldn't add much design and verification complexity. You are mostly just reusing mechanisms you already need. Nor should it negatively impact FMAX. And I suspect the area cost is reasonably low (but not zero)

The lack of flags on those ALUs probably tells us more about the lengths CPU designers will go for reasonably small savings than it tells us about how much flags actually costs. And it's probably more of a "our metrics never gave us enough justification to even consider adding flags to the extra three ALUs" than "we considered it, but the cost was too high".

> Of course not because that's impossible to prove.

Why?

It's supposed to be impossible to prove a negative. But it might still happen some day. We just don't know.

"it's impossible to prove a negative" is a simplification. A negation is just the oppositive of an affirmation. If the affirmation is "there is an element E of an infinite set S that satisfies property P", the negation would be "there is no E in S that satisfy P", which would make proving by enumeration require checking every element of an infinite set, which is impossible. But other forms of proof might be possible.

The set of US patents, however, are not infinite and, IIRC, is also public. That said, IP laws are a mess.

It was a joke I think.

Someone might also file a new parent, then apply it against RISC-V. You'd think that wouldn't be allowed to happen, and maybe it isn't, but only an expensive lawsuit will prove it

Given the nature of the US legal system as based on common law, that applies beyond patents, and may affect ARM and x86 as well. In the end, the real, effective law is the one understood by judges, adjucated in court cases, built on precedents.

That being said, I don't expect someone filing a new patent after a RISC-V extension being published to last much longer beyond discovery in most cases, which should keep costs in lower end. Specially so in cases of bad faith.

Well played

Patents only last 20 years.

If you build your architecture on ideas that are documented to be older than twenty years, it greatly reduces the risk that a patent holder comes from nowhere: even if they did have the patent, it would have expired.

How quickly does the industry move? Would there be any value in a 2006-era instruction set? How would you even start making sure you didn’t infringe on any patents that came after 2006?

The first version of RISC-V was released in 2010. It was based on work done at Berkeley in the 1980s (RISC versions one to four).

One reason that RISC-V has so many optional extensions is that you can trust the core is very likely to be patent-free (because everything in it is documented to be older than 20 years) and just evaluate the extensions you need.

If you iterate trough every concept RISC-V has, you might be able to prove it.

The RISC/MIPS concepts date back over 40 years. The base instruction set is intentionally designed with unencumbered, expired, or public-domain architectural concepts.

RICV-V microarchitectures and implementations are at much high risk of violating patents. Especially anything that is even slightly high performance. SiFive, Andes , and Alibaba’s T-Head are filing thousands of patents on microarchitectural optimizations and extensions. China's RISC-V patent-sharing alliances and other industry groups are building defensive patent cross-license around their RISC-V-related patents.

> 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 moat. I can just see the VCs salivating.

Coming up with any ISA and coming up with a good or better ISA are two very different things.

If that's really all it takes, then it is not much of a moat.

In the set of all possible working implementations, there are one or more that are novel enough to become a moat legally or otherwise. If everyone has the same power (number of tokens) then capability (experience and understanding) becomes the differentiator to “find” that moat first.

If everyone has equal ability to build a moat, it's not a moat.

If every one has a hammer and a saw and identical wood planks, everyone can build a frame that holds up 100 years?

Think it through. This is the HN comment section after all.

Yes. That's the point of AI. Anyone can make anything just as easily and well as anyone else.

That’s just not how things work. Some one with experience and knowledge will be measurably more productive and build a better whatever no matter how much spicy autocomplete they have at their disposal.

Even if you eventually figure out all the right questions to prompt, the experienced person is long done

I think you mean "if everyone has the ability (and resources) to build a boat, then it's not a (good) moat".

If everyone can build a moat, there's just a lot of moats.

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, debugger (at least a port for gdb server), dynamic linker and standard C library, possibly some parts of the standard libraries for other programming languages.

Previously this could have taken years and it is the only reason that has always justified the choice of RISC-V for minimum cost, despite how bad the ISA is.

If today the porting of all these software support applications to a new ISA could be accelerated with AI assistance from a couple of years to a couple of months, that would certainly enable the design and use of custom ISAs, and RISC-V would lose its appeal.

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.

> 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

No links? You may have dreamt about it instead.

It was vibed-level stuff definitely not worth sharing.

The main difficulty in support isn't actually making the changes (which is going to be largely defining various tables and other boilerplate, unless your ISA is really weird and does something unusual), it's in doing all of the politics necessary to get those changes committed upstream.

Maintining this type of long time fork is the kind of mind numbing, tedious thing LLMs are actually exceptionally good at. I did some backend work on Lean4 compiler and then they switched out parts of the codegen, it took Codex less than an hour to recover the feature set I had implemented but on the new backend.

> Designing a good 64-bit ISA [...] is easy [...] could design such an ISA in a couple of weeks

Let me know when you've got it all worked out and published. Should be easy, right?

It is the easy part. Four weeks is plenty of time.

That's why it's so bizarre that the RISC-V design is so awful.

The hard part is the software support side (though, as comments elsewhere in the thread point out, AI is pretty helpful there) and then those lovely pieces like specifying the precise behavior of interrupts.

If it had a snowball's chance in hell of going in to any kind of production anywhere, I'd have no problem spending the next month laying out an ISA. But, again, as this thread makes very, very clear: ISA really just doesn't matter.

> That's why it's so bizarre that the RISC-V design is so awful.

Not bizarre.

The design is a direct result of the biases of its initial designers, and its original intended use-case. And TBH, if you assess it by its original design criteria, it's actually pretty good.

It's just by the time RISC-V had escaped containment and was starting to become a general purpose open ISA, it was a little too late to start from the beginning and consider what the correct design criteria should even be.

Very true... but I can't help but note that basically every person I've ever met with significant experience with multiple architectures at this level, and not connected in some way to RISC-V, utterly hates the thing.

That feels like a "don't release yet" flag to me!

But I hear you.

It looks an awful lot like something that was designed by a sizeable committee made up mostly of academics, most of whom won't have written ten lines of code in as many years. I don't actually know in this case, but I've had to sit and watch standards created in this manner, and Dmitry's description of the RISC-V mess matches their output fairly closely, a chaotic mess that includes every idea everyone on the standards committee has ever had, all made optional so no-one will vote against it when it comes to balloting.

How many people are working on this in your couple years example? Is that just one guy or a team of 20 or something else? Whats the average salary for the team *n this scenario?

I said "me" and "four weeks" because laying out an ISA is a pretty straightforward job for one person in one month.

The deliverable would be a (theoretically) complete specification PDF like RISC-V's.

I have little doubt that I or Adrian could do it, or plenty of others. It might not reach the quality of something like AArch64 with that level of resources, but it's not hard to beat RISC-V.

I am trying to figure out if i can afford to make it happen or not lol. Would the labour coat of getting to something good with the support infra be a fewmillion or tens of millions?

Are you trying to get to a working simulator, a working core in HDL/FPGA, a thoroughly debugged and validated core in HDL, a fast core in HDL, a validated fast core in HDL, or functioning silicon in hand?

I'd guess low six figures for the beginning of that list and mid eight figures for the end. Real silicon also needs all the uncore stuff, which is easy if you don't care how it performs and very very hard if you do.

That's why I've never understood the point of RISC-V. Anyone can design a (reasonably OK) ISA. It's everything else that's the hard part. It's like announcing a new house, it's going to be pained Benjamin Moore Yellow Oxide and everything else is someone else's problem to sort out. Success! We've got a new house!

The only argument I've ever seen for RISC-V that's vaguely logical is that there's no licensing to Arm involved, but since I can get M0/M3 devices for a dollar or so with infinite tool and library support that's something that's totally irrelevant for most users. And if I don't mind going with Chinese suppliers there's no licensing to Arm being paid anyway.

Apart from being able to thumb your nose at Arm, I just can't see what the point of RISC-V is. Is that really all there is going for it?

> The only argument I've ever seen for RISC-V that's vaguely logical is that there's no licensing to Arm involved, but since I can get M0/M3 devices for a dollar or so with infinite tool and library support that's something that's totally irrelevant for most users.

How expensive is it to license the instruction set so you can expand it?

Surely those expanding the instruction set do not fall into "most users"?

Everyone is paying for the license. Expanding was poorly phrased but the per-unit licensing cost might not be irrelevant. It might even make smaller batches cost-efficient for smaller manufacturers if they use an instruction set that doesn’t require a license.

Dunno, I'm still saving up for the billion-dollar fab I'll need before I can think about licensing an instruction set.

As an aside, Espressif (or Xtensa if you want to split hairs) have been quietly doing a lot of what RISC-V is supposed to do for years now. I know they've also been fiddling with RV32's but all the real work is LX6/LX7. They're best-known for their use in ESP32s but they also crop up in an awful lot of industrial/commercial gear.

All the newest ESP32 variants for a bit now have been RISC-V. The last new LX7 was the ESP32-S3 (in fact, the S2 is the only other LX7), and LX6 is basically a legacy product that only lives on in the [non-variant] ESP32. The P4, the entire C and H series, and the new S31, are all RISC-V cores. Not to mention that RISC-V has even taken over for Espressif's classic ULP cores in all the same places (and even lives alongside it in the two LX7-based chips). They're well beyond "fiddling" with it.

My point is that if an ARM chip costs 1$ then how much is licensing? 0.1$? 0.5$? That’s money that doesn’t need to go to ARM if everyone is using unlicensed instruction sets.

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!

it still is a much better starting point than coming up with your own bespoke ISA, building a toolchain around it and convincing potential customers that your proprietary architecture is worth the effort to deal

There are lots of somewhat successful yet little-known Chinese companies with their own proprietary architectures and the toolchains to match, so I don't think it's that clear-cut. (That said, most if not all of them are somewhat MIPS/RISC-V-ish anyway...)

I do think 8051 is better when you don't need 32 or even 16 bits. Even 4-bit MCUs are still around in ultra-low-cost ultra-high-volume products, which is to say RISC-V is, as you said, just a different flavour of MIPS with very similar tradeoffs.

Google search turns up LoongArch (RISC), Shenwei (CUDA-like, HPC), UniCore (RISC). ESP32 is using Tensilica LX6/LX7 RISC base (RISC designed for custom hardware extensions).

C-Sky and Andes NDS32 were popular enough to be supported by both GCC and the Linux kernel, both switched to RISC-V. ESP32 switched to RISC_V for all new chips.

Interestingly Synopsys's ARC's latest version ARC-V is RISC-V.

I think all major FPGA vendors now offer fully supported RISC-V soft cores either alongside their older proprietary ISAs or as the latest upgrade. Several (e.g. Microchip and Gowin) have included real RISC-V cores inside FPGAs.

China is different - the state probably has impact on cpu/mcu vendor selection.

All states regulate, subsidize, or otherwise exert influence on companies acting in their territories. China is not unique or different in that regard. They have been forced to try somewhat harder, but that was really due to the actions of the US trying to restrict their access to free trade. Chine restrictions on buying western tech didn't come until far after NATO countries had placed similar restrictions on Chinese tech.

> 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. :-)

> Perhaps the most interesting thing is that RISC-V shows just how ISA agnostic people are

To the extent that Raspberry Pi shipped a microcontroller that can literally be either RISC-V or ARM (indeed, one of each at the same time I think?)

RISC-V, it seems to me, lives in that cognitive space occupied by things like: open source, open weights, C, HTML, ethernet, Greggs sausage rolls and VHS.

Far from optimal, obviously flawed, and could change human society for the better. Ubiquity is inevitable.

Not sure why you had to take a pop at Greggs there. Nothing wrong with a hot sausage roll at all. Assuming you can find a hot one.

you should review the data on processed meat. It's one of the least healthy things you can eat.

Do Greggs sausage rolls even contain meat?

There is a meat option

Is there a named meat option?

What processing do they do to the sausage?

What’s far from optimal about open source? Open source seems like a window into another universe, which is just lightly better than ours: people just working on problems and sharing solutions, because humans are basically good social creatures that enjoy solving problems. To the extent to which there are issues like the difficulty of funding open source projects: our society is wrong, not open source.

> Perhaps the most interesting thing is that RISC-V shows just how ISA agnostic people are

Of course! Most people in the computing world work way higher up the ladder of abstraction. I suspect a small minority of working software engineers know what an ISA even is.

I did some contract work in web development for a time. It is staggering how few people understand how the javascript they write gets executed on the machine. People don't understand pointers, or virtual machines, or in many cases how JS bundlers work, despite using them daily.

In some ways, this is a sign that our abstraction layers have been a great success! People can program for the virtual javascript machine, without needing to understand how the actual machine works, or how it emulates javascript. Is this the future we wanted? I'm not sure. But it's here.

What's next? Programming Javascript without understanding Javascript??

That's not next...it's now. Through at least LLMs and languages that compile to JS.

Definitely. I’m a weird software guy that got a hardware degree in college so that I could understand all the low level stuff. I remember there was a joint project with the hardware (ECE) and software (CS) students to build a simple computer with bit slice and microcode and program it to do something (I forget what). I remember the software students being bewildered that there was no division instruction in these systems (because who needs that when you have shifts and add/subtract). Nowadays, with so much stuff running in browsers, the average software engineer has no clue what the hardware is doing.

Nobody wants to cross compile a full linux OS though just for their project. I assume most are using debian multiarch (as they do for arm), and that does mandate a common RISC-V ISA subset. So presumably this will drive further standardization

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 Watchpoint Traces - but maybe there is an extension for that already?

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.

> RISC-V is... fine

Exactly.

> It satisfies my two requirements for an ISA as a hobby CPU designer...

You probably have some unstated requirements as well, such as available toolchains and "vetted well enough to actually be able to run code."

Risc-V now occupies the Schelling point for people who, for whatever reason (rent-seeking and security top the list) want to leave the x86 and Arm ecosystems.

They did explicitly specify:

> 1. Supported in mainline LLVM and GCC.

Which pretty well encapsulates the ecosystem requirements.

Luke is too modest. Something in the region of 5 million chips containing his hobby CPU have shipped since launch on August 8, 2024.

Could you share a link or more details? What is this hobby CPU project?

Luke Wren works at Raspberry Pi and designed the Hazard3 CPU core that is in the RP2350 chip.

I think the GP is talking about the Hazard3 [1] core. This is one of the CPU cores besides the ARM M33 instantiated on the RP2350 µC [2]. See this article from Luke Wren (Wren6991) back when the RP2350 came out [3].

[1] https://github.com/Wren6991/Hazard3

[2] https://www.raspberrypi.com/products/rp2350/

[3] https://www.raspberrypi.com/news/risc-v-on-raspberry-pi-pico...

Thank you!

What I find interesting is that RP2350 is designed as "one or the other", no way to use ARM and RISC-V concurrently, and has fuses that can kill ARM M33 cores outright.

Makes me wonder if an "ARM cores fused off, RISC-V only, no ARM fees" SKU is possible.

Several of the peripherals in the RP2350 are also ARM IP.

You can choose Arm in one pair and RISC-V in the other pair if you want.

Are we talking about rp2350 ? Because the rp2350 can be config as pure arm soc.

In fact, if we are talking about successfull riscv soc, RISC-V esp32 may have better chance

>2. I can implement it without lawyers sending me a love letter.

What's stopping them? They can trivially claim it infringes any number of patents...

This is a good point, and of course this is why IP lawyers are so important: they protect you from other IP lawyers.

You can’t fix the mutually incompatible overlapping encodings in post.

Practically you don't simultaneously want those overlapping encodings.

They actually did do that. C was split into ZcfZcdZca, so you can choose a non-overlapping subset. It doesn't affect an RV32 non-F core anyway.

I… you can’t be serious.

Yes, I'm serious. I think the overlap is an aesthetic problem rather than a practical one, given that:

* The profile used by "Big SoCs" already explicitly depends on F + D + C, implying ZcdZcf, so the newer Zce won't be implemented.

* The compressed float load/store opcodes repurposed for Zce are often unimplemented on embedded processors.

* The ELF file has an attribute section telling you the exact ISA string. If you're debugging an embedded system you probably depend on the ELF file anyway for DWARF info as you likely don't have frame pointers.

If you disagree then that's ok, I'm happy to be disagreed with, but please explain.

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 messy. But, critically, on x86, these are all modes, and any CPU that supports them makes them detectable and supports them in the same way. If you run long mode code outside long mode, some opcodes will be interpreted as the wrong instruction. 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, and all these modes are older than RISC-V. To the extent that there are lessons to be learned, RISC-V should have learned them.

The fact that you can apparently find two RISC-V CPUs that decode some ordinary user mode instructions based on published standards as entirely different operations is bizarre, to say the least. The fact that the relevant CPU features can’t even be enumerated in user mode just makes it worse.

(There are edge cases in x86. Some invalid opcodes have different lengths on different vendors’ CPUs. This is not a problem in practice because, one way or another, they fault. There was also a little glitch in the 64-bit design where some really really old x87 FPU code that uses exceptions cannot be corrected handled by a kernel on a modern CPU.)

> The fact that the relevant CPU features can’t even be enumerated in user mode just makes it worse.

User-mode feature detection is usually used to select paths for acceleration instructions, like SIMD or crypto. The overlapping RISC-V instructions don't fit in that category: they're compressed versions of basic functions, mostly used in epilogs/prologs, which would be unconditionally compiled in.

There are no overlapping encodings in the 32-bit encoding space and I'm really hoping it stays that way.

> To the extent that there are lessons to be learned, RISC-V should have learned them.

Yeah, I think I agree with this. Also I wish I had been there when Andrew Waterman was writing his master's thesis so I could ask him not to include Whetstone in his size benchmarks, so that we might have left that encoding space free and avoided this conversation :-)

At least with user-mode feature detection there could be an assertion that the correct feature set is present.

Doesn't the ELF loader do that?

A lot of these embedded systems won’t use ELF.

> 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 encoding). 66 e9 xx xx yy yy is a unconditional jump to a 32-bit relative offset on Intel, but on AMD, the offset is 16-bit only (yy yy are the start of the next instruction). x86-64 is typically used to refer to the very large common subset, but this doesn't mean the implementations behave identically.

There are also some weird corner cases where CPUs aren't 100% backwards compatible, just backwards compatible enough for the software that matters.

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.

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

Fair point.

66 E9 is not a practical compatibility problem, though: it’s not a useful encoding of a useful instruction on any CPU :)

Pretty sure 3DNow's instruction space has been repurposed too. There are a few like that, or worse extremely similar but ever so slightly different between vendors or even generations of the same vendor. I won't claim to be an expert, this is all in IIRC territory for me.

No, the 0f 0f opcode (most of 3DNow was encoding-wise a single RMI-encoded opcode where the immediate specified the operation) and the 0f 0e opcode (FEMMS) were not repurposed by either Intel or AMD.

Good to know, thank you

> There are edge cases in x86

Some early 386 CPUs had XBTS/IBTS instructions (extract/insert bit string). They used 0F A6 and 0F A7 encodings.

Some early 486 CPUs had CMPXCHG encodings that reused the XBTS/IBTS encodings. That apparently screwed up some programs that tried to execute XBTS/IBTS to see if they were running on early (buggy) 386s so Intel moved CMPXCHG to different encodings (0F B0 and 0F B1).

0F A6 and 0F A7 are still left unused by Intel and AMD in their modern chips.

There's also the delightfully petty story about SYSENTER/SYSEXIT and SYSCALL/SYSRET for fast system calls. Intel came up with the first pair, AMD with the second. AMD of course had to support both and operating systems generally only supported Intel's pair.

Then AMD extended the x86 to 64 bits and of course required SYSCALL/SYSRET for 64-bit system calls (and did not support SYSENTER/SYSEXIT in 64-bit mode). Intel had to support AMD's instructions in 64-bit mode but decided to also support SYSENTER/SYSEXIT there (which I don't think any operating system has ever bothered to support).

To summarize: AMD supports both methods outside of 64-bit mode and only their own in 64-bit mode. Intel supports both methods in 64-bit mode and only their own in 32-bit mode. Or at least that's how it used to be. Maybe they've mellowed out by now.

Oh I remember SYSENTER/SYSEXIT, I think. I worked on CTOS, widely released by Burroughs/Unisys back then. CTOS used all the clever instructions. They performed badly. Later I learned from an Intel customer consultant on porting code, that we were the only ones who ever embraced fancy things like task gates etc. Everybody else just continued using regular push/pop and simple traps. Because they ran faster.

Yes, but x86 had a goal of running every old piece of code on the new thing. That’s not true with RISC-V. Whereas x86 accreted more and more features, RISC-V solves this with profiles that are not guaranteed to be compatible with each other. RISC-V doesn’t even support running 32-bit code on 64-bit processors without a recompile. In a sense, 32-bit RISC-V is a vaguely similar but incompatible ISA to 64-bit RISC-V. That would be a train wreck if there weren’t profiles to specify a group of features that must be there (and some others that might be optional, with a register to flag whether they are or not). The expectation is that profiles act a lot more like the x86 ISA, accreting features while preserving backward compatibility. It took me a while to realize this, too, and I remember several WTF episodes while reading through the specs. And of course profiles go beyond the ISA and specify system level arch as well (like the “PC architecture” did for Windows and Linux). You can certainly argue that it should have been done differently, but it’s not completely crazy given that there is not legacy RISC-V code needing to be run on newer systems for the most part. That won’t be true forever, and so profiles help manage that.

> RISC-V doesn’t even support running 32-bit code on 64-bit processors without a recompile. In a sense, 32-bit RISC-V is a vaguely similar but incompatible ISA to 64-bit RISC-V

RV32 and RV64 are considered distinct ISAs. But designed to divert as little as practical.

Apart from the register size, differences are small enough to be (almost!) irrelevant. If you know RV32I assembly, then you know RV64I assembly & vice versa. Moving code between those is at worst a re-assemble away. Also it should be easy to support execution of RV32 binaries in userspace on a RV64 cpu (if some implementations supporting that don't exist already).

AIUI, profiles were meant to provide a common target for eg. Linux distributions. Cases where you want 1 "generic" binary to support a variety of hardware like phone/tablet/SBC/desktop. Since these target the common case, yes profiles can be expected to grow & accumulate legacy cruft over time just like other ISAs. But for embedded or high-performance computing (HPC), this doesn't matter as code will be compiled for the specific hardware anyway. RISC-V's modular ISA is a great asset there.

In the meanwhile: loootts of legacy cruft dumped (esp. compared to the insane x86 world). That's always welcome. Nothing's fixed in stone (not even silicon, imho), and tech should learn from past mistakes, improve things & move forward.

You’re basically proving my point. As I said, it’s similar but incompatible, requiring a recompile or reassemble. The point being that the 32-bit instructions are not a distinct subset of all the instructions with the 64-bit instructions added on. Some of the instruction encodings from rv32 are redefined in rv64 to operate on the larger register sizes. Rv64, for instance redefines the encoding for rv32 add to work on 64-bit registers and creates a new instruction to operate on 32-bit registers. Why didn’t they just extend rv32 to add a new “add 64-bit” instruction. If rv32 was a proper subset of rv64 then it would be easier. So, can you create a cpu that runs both? Sure, but you’ll need a mode and duplicate decoders, in whole or in part. Again not the end of the world (decoders are small these days) but it still makes you go wtf? Maybe there’s something I’m missing that offsets this complexity in some other way, but it’s not obvious what that is. It would have been better, imo, if rv64 (and rv128) was a set of newly added instructions with a cpuid or capabilities bit somewhere to let software know about the hardware capabilities, similar to SIMD instructions in x86. And yes, I realize that this is still less complex than x86, but that’s a low bar.

There is a lot to unpack, hence my reaction. Instead of a straight compressed instruction format supported (or not supported) everywhere, we get an alphabet soup of options. C -> "ZcfZcdZca" just by itself is insanity. But the actual technical change is a problem too. Now I can't make vendor-independent RISC-V code, since apparently they all support different compressed instruction sets.

I represented my company as a founding member of the RISC-V foundation. I now shake my head at what it has become and hope I never have to write code for a RISC-V system again. Every time I check in it seems like some new insanity has manifest itself.

> C -> "ZcfZcdZca" just by itself is insanity

Separating the float load/stores from the rest of the compressed ISA is insanity? Why?

> Now I can't make vendor-independent RISC-V code

I think this is what RVA23 is for. Any system running shrinkwrapped binaries is going to have vanilla RVC.

I agree there is some insane stuff going on in RISC-V. Like when the double-trap spec was in public review I popped my head in to say "hi, this seems to break all existing code that uses nested interrupts because the condition is overly broad" and the spec maintainer said words to the effect of "yes, it's supposed to do that."

This is not that weird, though? Float load/store should never really have been included in the C extension, but we can't revise the C extension. So, define an extension for "C: the good parts", aka Zca, and separate extensions for float load/store (two of them because F and D are separate). Ideally we wouldn't have made the mistake in the first place, but what would have been a better way to redact it?

Not redacting it would have been better. Either live with it, or you explicitly create a new incompatible ISA. What happened is the worst of both options.

Sure can. Just change the encodings.

You thought RISC-V chips were compatible with each other beyond the basics? They're not. RISC-V is only a starting point for designing the ISA your chip will actually implement. Don't get me wrong - it's still beneficial that simple code works on many chips.

HP wrote a JIT to migrate old applications to their new hardware. So did Apple, twice. I don't know if IBM were the first but they've done it a few times as well for their mainframe hardware.

In HP's case, they tried running their JIT to translate from architecture B to architecture B and ended up with better performance than running it directly.

HP or HP née Compaq née Digital Equipment Corporation?

HP proper. It was a PA-RISC they were targeting.

https://cseweb.ucsd.edu/classes/sp00/cse231/dynamopldi.pdf

HP also used a binary translator to migrate from HP3000 to PA-RISC in the 80s.

> diagram for the Arm T32 BL encoding

is that... bit xor?

did they attempt signed immediate, but gave up 3 bits into a 32 bit immediate?

wtf

It originally had a range of 4 MiB, and they extended it to 16 MiB in a later ISA revision. The bits with the XORs were originally constant-1 and they wanted to keep backward compatibility, so bits J1 and J2 are interpreted as "if this bit is clear, toggle this position in the leading sign bits".

There is very cool history as to why. In armv5 the BL was two separate instructions. You could take an interrupt in between. And it was documented what each did. Veeery cool. Then they wanted more range. And now that they redefined the two halves as one instruction that could not be in halves, they also redefined a few bits that were always 1 before, to allow the second half of the instruction to be recognized right without a “previous instruction was first half of BL” flag somewhere that would need to be context switched and all that.

Reply on news.ycombinator.com