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

421–430 of 467 posts

Re: RISC-V: They Should Have Known Better

#421

Post by rsyring »

corndoge wrote: post #400
josephg wrote: post #298

Earlier quoted context omitted.

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

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.

Re: RISC-V: They Should Have Known Better

#422

Post by peterfirefly »

hajile wrote: post #314
walrus01 wrote: post #26

Earlier quoted context omitted.

> The market can sort it out for themselves Because nobody will write software for 300 unique hardware variations of a platform that have inconsistent capabilities. Consistency is one of the reasons why x86-64 with extensions like like SSE, AVX2 etc is popular.

How can you use consistency and SSE/AVX in the same sentence? SSE has inconsistencies like SSE4.x vs SSE4a. AVX is an even more mixed bag. There are some 19 AVX-512 extensions and ZERO chips support all of them. The situation is so bad that AMD and Intel got together to make AVX10 to unify everything. That seemed great, but Intel now has AVX 10.1 and 10.2 in addition to the base set, so there we go again... x86 is a…

> but Intel now has AVX 10.1 and 10.2 in addition to the base set

Intel committed to not slicing and dicing the AVX instruction set going forward. AVX 10.(n+1) will not remove instructions that were in AVX 10.n. Feature testing is also easier: a single feature bit and a single version number.

I bet Intel's management will find some new counterproductive way of segmenting the market but AVX-10 (and therefore AVX-512) should be safe now.

Re: RISC-V: They Should Have Known Better

#424

Post by drob518 »

josephg wrote: post #298
ChuckMcM wrote: post #243

Earlier quoted context omitted.

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

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

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.

Re: RISC-V: They Should Have Known Better

#425

Post by adastra22 »

wren6991 wrote: post #361
adastra22 wrote: post #311

Earlier quoted context omitted.

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…

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

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.

Re: RISC-V: They Should Have Known Better

#426

Post by api »

dismalaf wrote: post #316
pocksuppet wrote: post #305

Earlier quoted context omitted.

It's server-grade. Not desktop-grade.

Tell that to Valve or the millions who use it as a desktop. Also, have you used Windows recently?

I keep saying Linux can win on desktop by just sitting still while Windows sucks more and more.

Re: RISC-V: They Should Have Known Better

#427

Post by zephen »

adrian_b wrote: post #246
brucehoult wrote: post #152

Earlier quoted context omitted.

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

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

Nope. Again, the primary advantage that RISC-V has over Aarch64 is that it is the agreed-upon open specification.

Re: RISC-V: They Should Have Known Better

#428

Post by zephen »

NooneAtAll3 wrote: post #328
adrian_b wrote: post #248

Earlier quoted context omitted.

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, becaus…

I keep seeing comments here saying that a)compressed instruction are awful for pipeline decode, so they aren't used in any ISA on fast speed and b)risc-v loses in code size if you compare against compressed instructions I don't understand how the two viewpoints fit together

> I don't understand how the two viewpoints fit together

Well, they don't and they do. Linux runs on everything from an $8 generic IP camera to the world's fastest supercomputers.

RISC-V is attempting to achieve the same feat in hardware, so there will be many implementations at many price points.

As with any of the T-shirts that list 3 things and say "Pick two" it's always difficult to reduce cost, increase speed, and decrease code size.

But...

You can pick two.

So if you don't mind spending the money for things like fancy micro-op caches, you don't care about the compressed decode, and you can still make it run like a bat out of hell with compressed instructions.

Or if you don't mind lower performance, you don't worry about fusing operations, and the pipeline implications aren't so bad, so you can still make something cheap that works with compressed instructions.

It's only when you're trying to pick all 3 (compressed instructions, high instruction throughput, and low cost) that the difficulty of decompressing the instructions becomes problematic.

Or look at it this way. x86 decode is infinitely more complicated than RISC-V decode, and still occupies maybe 2% of the die area.

Re: RISC-V: They Should Have Known Better

#429

Post by drob518 »

amluto wrote: post #196
wren6991 wrote: post #193

Earlier quoted context omitted.

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

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

Re: RISC-V: They Should Have Known Better

#430

Post by peterfirefly »

p_l wrote: post #8
80x86 wrote: post #4

100% agree with dmitrygr. I was excited when I heard about the project just after it started. However, past experiences taught me to wait before getting excited about the new 'shiny thing'. I did it differently with RISCV. I waited. I am glad I did. It took a long time for actual silicon to appear. Also, the silicon today has all the facepalming special cases mentioned in the article. Its almost like those old soviet…

I'd say RISC won, when you consider how "RISCy" x86 is[1] compared to the ur-CISCs (68k, VAX ) that RISC projects were in opposition to. [1] Not because of often-called "risc like" microcode engine, but because the most complex addressing mode on x86 usually decodes two microinstructions, and decodes in single cycle. In comparison VAX needed separate pipeline for instruction decoding.

> In comparison VAX needed separate pipeline for instruction decoding.

That's how the VAX 9000 and NVAX did it. It's not the only way. It is absolutely possible to decode a number of normal VAX instructions in parallel using a pipelined decoder similar to x86 decoders. It is also possible to use a µop cache similar to many x86 and ARM implementations.

Fallbacks are only needed for the weirder addressing modes and for instructions that positively beg to microcoded (system calls/protection level transitions, some bit vector stuff, COBOL decimal stuff, block copy/scan/fill/compare, probably POLY) and startup and interrupt/exception handling.

DEC never did this but they absolutely could have.

Post reply on HN