Live data from Hacker News

RISC-V: They Should Have Known Better

dmitry.gr

81–90 of 467 posts

Re: RISC-V: They Should Have Known Better

#81

Earlier quoted context omitted.

You don't need to probe what hardware you're running on because you know being the manufacturer. The code is bespoke for your solution and nothing more. No foreign code is going to run on it. Different problems require different solutions. An electric blanket doesn't need a barrel shifter for multiplication or even floating point hardware. The ISA can change depending on what's needed to solve a particular problem, n…

I'm not an embedded programmer myself, but from what I've heard... it's actually a pretty big assumption that the software people know what model hardware they're running on. Especially consider the possibility that a product manager decides to swap out the core for a different core to save 5¢ on the BOM. Does the product manager know to ask if the two cores follow the same RISC-V profile? Do the software programmers…

If the product manager isn't an engineer he shouldn't be making these kinds of decisions.

Re: RISC-V: They Should Have Known Better

#82
post #68

Earlier quoted context omitted.

Has it been proven that no patent troll holds a patent covering RISC-V? Of course not because that's impossible to prove.

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

Re: RISC-V: They Should Have Known Better

#83
post #33

Earlier quoted context omitted.

I don't think I've read a more "doesn't actually know anything about how software is produced, but with absolute confidence knows everything about it" post in a very long time.

So you write software for a platform you know nothing about?

> So you write software for a platform you know nothing about?

That's how a sizeable chunk of software is written and shipped.

Runtime detection of CPU features is very much a thing, and is in fact used extensively in software you use or interact with every single day.

Just as a quick example, OpenSSL's approach for x86_64 is OPENSSL_ia32cap

https://docs.openssl.org/master/man3/OPENSSL_ia32cap/

This ensures (in theory, at least) that even if you're using your linux distribution's openssl library which is more generically targeted, you will get optimal/native runtime performance for your actual CPU.

Re: RISC-V: They Should Have Known Better

#84
post #74

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…

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

Practically you don't simultaneously want those overlapping encodings.

Re: RISC-V: They Should Have Known Better

#85
post #74

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…

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

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.

Re: RISC-V: They Should Have Known Better

#86
post #28

Earlier quoted context omitted.

I think MIPS is a great example, and even there I don't think there's the bizarre bifurcation of ISA options RISC-V brings to the table. As a fellow olderster, I can't help but think that after almost 50 years of "ISA X is sooooo much better than x86 it's obvious ISA X is the future and x86 will be dead Real Soon Now (for whatever todays version of x86 is)" I can only shake my head ruefully and say "ping me when that…

x86 chips don't truly exist anymore. They only use it as a compressed ISA for a more capable internal representation that can be freely updated at any time.

Sort of.

They always had a much cleaner instruction set internally, going back to the 8086.

Re: RISC-V: They Should Have Known Better

#87
post #48

I think a lot of this criticism is completely true. However it's also overblown. I do think the ISA matters, but little mistakes like these definitely don't matter enough to preclude making M-series class chips. The reason it hasn't happened yet is simply time. It takes a really really long time to build up to that level of performance. They've definitely gone overboard on the optionality stuff though. I don't think…

ALL chip designs are an exercise of minmaxing these 3 variables: 1) power 2) performance 3) die area SOME chip designs also care about a 4th: 4) die area. NO design has the best of all...it is impossible since you have to trade 1 for another. The reason x86 has been dominate for so long is that is strikes a good balance across all areas, especially #4. A good balance is what you need for a good chip. EDIT: oh and you…

You forgot the variable that RISC-V chose to maximize:

5) Weird principles that are completely detached from anyone's actual needs and that are carried to a length similar to religious convictions.

My biggest personal pet peeve about the architecture is the JAL instruction.

That is, PC-relative jump and link immediate, which jumps to an PC + sign extended immediate value and stores the address of the next instruction in a register. This is your most basic function call instruction. It only has an immediate range of 21 bits. Even a few bits scavenged from somewhere would really help it, ±megabyte of range is in the vicinity of what you need for internal calls but not generally enough.

It's a 32-bit instruction, so why can it only support 21 bits of immediate? Because the people who made RISC-V decided that implicit register arguments are works of the devil, and that you need to use any register as argument for any instruction. Therefore the RISC-V JAL instruction contains a 6-bit field for destination register, which is where they store the next instruction address. Never mind that there is not and will never be a compiler that emits anything but the ABI compliant return address register "ra" to that field, we decided we won't have implicit arguments so by god we are going to pointlessly sacrifice 5 bits⁰ of space in every single fucking branch, often forcing the user to construct the address in a register and use more instructions instead, which is much worse than it sounds, because branch prediction is easier for immediate branches.

This is not the biggest actual problem with the architecture. They added an instruction that adds upper immediate bits to PC, which the any core that implements instruction fusion fuses with jalr. But that sacrifices the low-end, that doesn't fuse anything, and uses two instructions for an extremely common pattern that everyone else manages in one. The reason I hate this one so much because there is no actual reason to make this mistake. A five minute conversation between two engineers should have killed this one in the crib, literally everyone knows not to do this. Apparently other than the RISC-V folks.

0: I give them one bit, because the opcode is short and they use the zero register to suppress the link and turn it into a normal jump.

Re: RISC-V: They Should Have Known Better

#88
post #45

Earlier quoted context omitted.

So you write software for a platform you know nothing about?

[flagged]

Both of your post are actual ad hominem towards OP. In the first, you just said they didn't know how software is developed, without elaborating. With this in mind, their reply is less of an ad hominem and more of an inquiry. In the next, you accuse them of having a fragile ego and being a kid. Not very insightful.

Re: RISC-V: They Should Have Known Better

#89
post #42

Earlier quoted context omitted.

He explains, at length: there is no sane way to determine what the hardware you are running on actually supports, and so there is no sane way to ship compiled code that is both compatible and performant. We already had the mystery meat CPU wars several decades ago. We know how to make sane ISAs now and should be past that.

I'm not sure this is a real problem - for embedded you know a priori - for arbitrary desktop/SBC machines, misa will be available in kernel mode and /proc/cpuinfo will be available in user mode.

Well, misa won't be in most cases since you'll be running ins mode rather than m mode for most kernels on an application core (and misa won't tell you about the X* and Z* extensions).

But you'll practically be passed a device tree from SBI that will tell you.

Re: RISC-V: They Should Have Known Better

#90
post #35

Earlier quoted context omitted.

Noone uses an 8051 because it's elegant. Billions are still still sold every year because no matter if you learned it in the 70s or last week and no matter who made it, the basics are exactly alike. Software matters; ISAs don't.

>You learned it in the 70s [emphasis mine] I really don't know anything about this space, but you just said that 8051 is dominant because it has one dominant architecture since the 70s. It has hundreds of manufacturers making identical parts. As you say, software matters. If the Software can't run because of hundreds of extensions that can't be checked for, then you're going to pick a target that works, no? So in fac…

I really don't know anything about this space

And yet you couldn't help yourself...

but you just said that 8051 is dominant

I said absolutely no such thing.

If the Software can't run because of hundreds of extensions

The software in the x86 world runs because there aren't hundreds of mutually incompatible extensions. I think the last time there was a major completely incompatible x86 ISA divergence was AMD "3DNow" vs other SIMD extensions. AFAIK the rest were "processor X got feature Y later than competitor Z".

Which ISA means my software runs on the most devices?

Easiest question evah: x86.

Post reply on HN