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

451–460 of 467 posts

Re: RISC-V: They Should Have Known Better

#451

Post by inigyou »

Neywiny wrote: post #443
inigyou wrote: post #439

Earlier quoted context omitted.

Are all registers caller-saved in RISC-V, or are you blaming the ISA for a specific inefficient implementation and ABI?

The delta is that no, not all registers are caller saved. However, that's how it does interrupts. So they're different. In cortex-m, they're not The hardware/ISA matches the ABI. I'm struggling to find the RV doc that describes it on mobile, but I am confident about it. So in RV, there's no pushing required at all which can save time. Interestingly, it looks like GCC (didn't check others) can compile compilation unit…

It isn't the CPU that's saving all registers here, it's the interrupt handler code, which, if the author wanted to reduce latency, he wasn't forced to save all registers.

Re: RISC-V: They Should Have Known Better

#452

Post by Symmetry »

_chris_ wrote: post #257
201984 wrote: post #194

Earlier quoted context omitted.

>I still do believe RISC-V did a lot of things better than x86... Such as? I can't think of anything it does better for high performance cores.

1B through 15B variable length instruction mess, for one. Which still yields a worse than average 4-5B per instruction average.

More to the point x86 instruction streams aren't self-synchronizing. There are cases where you can read one valid stream of x86 instructions starting at byte X, but another completely different one starting at byte X+1. Apart from the security implications this makes wide decode on x86 notably harder than it has to be, though in practice you can make it work by just starting a decode your fetch window at every byte boundary the fist time you're executing something and throwing away the unused decodes, and then mark the invalid positions in the instruction cache so you don't waste that power again.

Re: RISC-V: They Should Have Known Better

#453

Post by RetroTechie »

drob518 wrote: post #429
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…

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. Th…

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

Re: RISC-V: They Should Have Known Better

#454

Post by Neywiny »

inigyou wrote: post #451
Neywiny wrote: post #443

Earlier quoted context omitted.

The delta is that no, not all registers are caller saved. However, that's how it does interrupts. So they're different. In cortex-m, they're not The hardware/ISA matches the ABI. I'm struggling to find the RV doc that describes it on mobile, but I am confident about it. So in RV, there's no pushing required at all which can save time. Interestingly, it looks like GCC (didn't check others) can compile compilation unit…

It isn't the CPU that's saving all registers here, it's the interrupt handler code, which, if the author wanted to reduce latency, he wasn't forced to save all registers.

It depends. On cortex-m, it is the CPU. On RV, it's the code. However, if your IRQs are within the ABI, you are forced to save some registers. I believe Xilinx is overly aggressive with their saving but you still need to save at least some without hardware assistance.

Re: RISC-V: They Should Have Known Better

#455

Post by RetroTechie »

inigyou wrote: post #451
Neywiny wrote: post #443

Earlier quoted context omitted.

The delta is that no, not all registers are caller saved. However, that's how it does interrupts. So they're different. In cortex-m, they're not The hardware/ISA matches the ABI. I'm struggling to find the RV doc that describes it on mobile, but I am confident about it. So in RV, there's no pushing required at all which can save time. Interestingly, it looks like GCC (didn't check others) can compile compilation unit…

It isn't the CPU that's saving all registers here, it's the interrupt handler code, which, if the author wanted to reduce latency, he wasn't forced to save all registers.

> if the author wanted to reduce latency, he wasn't forced to save all registers

Yup.. If author's working with a RISC-V softcore, there are several options to reduce interrupt latency:

  # If softcore saves many registers as a hardware feature: adapt it to not do so
  # Save (and use) only a few registers in interrupt handler
  # Reserve some registers to be nuked by the interrupt handler, and don't use those in application code
  # Use another softcore with faster interrupt response
  # Move to a part with cpu as hard silicon (with sane interrupt handling)
Just to name a few (or some combo thereof).

Re: RISC-V: They Should Have Known Better

#456

Post by leeter »

aengelke wrote: post #449
leeter wrote: post #442

Earlier quoted context omitted.

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

Re: RISC-V: They Should Have Known Better

#457

Post by drob518 »

RetroTechie wrote: post #453
drob518 wrote: post #429

Earlier quoted context omitted.

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. Th…

> 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 v…

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.

Re: RISC-V: They Should Have Known Better

#459

Post by just6979 »

pseudohadamard wrote: post #383
jurgenburgen wrote: post #346

Earlier quoted context omitted.

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

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…

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.

Re: RISC-V: They Should Have Known Better

#460

Post by just6979 »

inigyou wrote: post #310
pyvpx wrote: post #237

Earlier quoted context omitted.

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.

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.

Post reply on HN