Hacker News Reader

> Array accesses take an extra instruction? Either you're in a tight loop walking a tiny array and you don't do the full offset calculation per step, or you're walking over an array in RAM and you're bottlenecked by the memory bus.

I'm not a hardware person, but whenever I look at compiler output I find computed index accesses all over the place in the assembly. This would suggest to me that at least compiler developers believe these addressing modes to be important.

> Yes, that is totally fine. Either you know your target CPU, or you don't - and then you ask your OS for details.

So then my code has to choose between being hardware-dependent or OS-dependent? That doesn't seem ideal.

> "For example, if you are writing a kernel and want it to support all RISC-V cores" - NOBODY IS DOING THAT.

I'd hate to live in a future where linux distros need to ship a separate kernel binary for every random combination of RISC-V features. That said maybe the run-time feature-detection extension will be so widely supported in practice that this wouldn't come up?

     Either you're writing embedded firmware and know exactly what core you're using, or you're writing an application that runs in an operating system and that system has a minimum ABI like RVA20 or whatever.

It's very common for embedded teams these days to support a diverse set of cores with a shared codebase, depending on the specific requirements of different products/systems. SoC vendors will often change cores between versions or product lines, and I might need performance in this one system vs specific interfaces in another. So even if I know what core I'm using today, I don't know what core I'll be using in a year or five. I may also be writing a library or other reusable component and have no idea what core will run things today.

    Array accesses take an extra instruction? Either you're in a tight loop walking a tiny array and you don't do the full offset calculation per step, or you're walking over an array in RAM and you're bottlenecked by the memory bus.

Let's take the bitfield instructions the author complains about for similar reasons. If bfi/bfx takes multiple instructions, optimal structure packing isn't necessarily a win for performance or memory usage. The programmer needs to trade off how often the structure is instantiated vs accessed. Even they can make the right decision today, it might not be the right decision tomorrow. And if they get it wrong, that might not be apparent until later (when it will be somewhat obscured in superficial memory usage analysis). Or the ISA can get it right the first time and also make things easier for compilers/humans in the process.

    "Who can predict how their binary will act when a floating point store silently becomes a double-register move or a jump instruction, or vice-versa?" - THIS DOES NOT HAPPEN IN PRACTICE.

I can easily imagine this happening. When you change embedded platforms, the typical approach is to take the existing system and compile it for the new platform without carefully revisiting every decision made in the old system. If one of your vendor blobs was specified for the old system and the new system is "similar", you'll just link it in and see what happens. The metadata in the blob will hopefully catch the issue at link time, but it was an avoidable error.

> If one of your vendor blobs was specified for the old system and the new system is "similar", you'll just link it in and see what happens.

And what if that blob has instructions your new core just doesn't implement? This problem has nothing to do with overlap.

Then it crashes in a nice, obvious way as soon as you execute one of them? Illegal instructions aren't usually that hard to debug unless they're related to memory safety issues.

Then you take an illegal instruction exception, and you have a choice to request a rebuild, patch it, or emulate it. (Yeah, sometimes the vendors just don't cooperate.)

Incidentally, emulating opcodes is quite often practical (unless the performance must not be affected), and is greatly helped by having the plainest, cleanest instruction encoding possible, and a well designed system register & exception architecture.

Yeah the OP post read to me like someone throwing the baby out with three drops of bath water. If this was presented more like “minor gripes with risc V” I’m guessing I wouldn’t feel that way

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

The encoding being oddball does have some effects on linkers/loaders though I imagine?

Not that linking/loading is a super hot path people generally worry about.

It has an effect only in terms of how big an offset you can encode in a relative jump, the _arrangement_ of those bits in the instruction is irrelevant (and already abstracted away in the compiler/linker framework).

> NOBODY IS DOING THAT.

RePalm kernel is literally that.