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

271–280 of 467 posts

Re: RISC-V: They Should Have Known Better

#271

Post by skydhash »

trollbridge wrote: post #250
adrian_b wrote: post #238

Earlier quoted context omitted.

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

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

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

Re: RISC-V: They Should Have Known Better

#272

Post by g8oz »

When writing a spec, every single thing you make optional, you split the possible implementations into two incompatible groups. Do this enough times and you end up with your spec being meaningless.

I felt that.

Re: RISC-V: They Should Have Known Better

#273

Post by mosura »

TheAceOfHearts wrote: post #156
api wrote: post #53

Earlier quoted context omitted.

X86 is the best argument that you can build a fast efficient RISC-V chip... because the X86 instruction set is a much bigger mess. It just blows my mind sometimes when designers don't learn insanely obvious lessons from the past, basic stuff like "complexity is evil" and "make the fast path overlap with the most common use cases" and "a standard with N optional extensions is actually N! (N factorial) standards." That…

There is a general pattern I've noticed, where people from past generations fail to share the lessons they have learned somewhere that is accessible for the next generations, so they are stuck repeating the lesson. In particular, the next generation might recognize some aspects that seem bad and be confused over how to prioritize correctly because they don't know any better.

But they do share it.

It is just that it is some combination of behind closed doors, for competitive advantage, and/or the new generations don’t want to hear it.

Previous generations had learned long ago that sharing everything in public, or even in patents, was a bad idea for long term survival, a lesson that has now taken on a more extreme form.

Re: RISC-V: They Should Have Known Better

#274

Post by Neywiny »

wren6991 wrote: post #232
Neywiny wrote: post #133

I think I get it. I've tried microblaze-v for a while now. And just look at their interrupt handler. https://github.com/Xilinx/embeddedsw/blob/master/lib/bsp/sta... . With the FPU enabled at compile time, that's > 128 memory ops per interrupt. That's insane, especially without an NVIC and chaining and all that. My latency was astronomical, and my maximum interrupt frequency was pitiful. Ended up doing the work (sw an…

Yeah, this is a bug. They should only be saving the FP state if it's dirty. Also this is one of the reasons I think Zfinx is a better option for embedded (i.e., the standard FP instructions operate on x registers instead of f registers): 31 registers is plenty to hold a mixture of integer and floating-point values, and you avoid the worst-case context save penalty.

Not a bug, just not optimized. Because I think there's a csr to read it the fpu is dirty but... That requires csr extension. It would also increase jitter, which in some cases is more important. At best it should be still there as an option, but also optionally improved

Re: RISC-V: They Should Have Known Better

#275

Post by Neywiny »

mycall wrote: post #260
Neywiny wrote: post #133

I think I get it. I've tried microblaze-v for a while now. And just look at their interrupt handler. https://github.com/Xilinx/embeddedsw/blob/master/lib/bsp/sta... . With the FPU enabled at compile time, that's > 128 memory ops per interrupt. That's insane, especially without an NVIC and chaining and all that. My latency was astronomical, and my maximum interrupt frequency was pitiful. Ended up doing the work (sw an…

You can bypass AMD's heavy BSP abstractions according to gpt.

Is that what you think that is here?

Re: RISC-V: They Should Have Known Better

#276

Post by wren6991 »

Neywiny wrote: post #274
wren6991 wrote: post #232

Earlier quoted context omitted.

Yeah, this is a bug. They should only be saving the FP state if it's dirty. Also this is one of the reasons I think Zfinx is a better option for embedded (i.e., the standard FP instructions operate on x registers instead of f registers): 31 registers is plenty to hold a mixture of integer and floating-point values, and you avoid the worst-case context save penalty.

Not a bug, just not optimized. Because I think there's a csr to read it the fpu is dirty but... That requires csr extension. It would also increase jitter, which in some cases is more important. At best it should be still there as an option, but also optionally improved

Fair enough. It's a performance issue but not a functional correctness issue.

> Because I think there's a csr to read it the fpu is dirty but... That requires csr extension

Yes, and they already unconditionally read that CSR :-)

The "CSR extension" is an almost 100% theoretical concern. It was the spec authors being defensive in case the privileged ISA was so flawed they had to throw it out in future, while keeping the base ISA. I don't see that happening at this point.

The only exception is deeply embedded cores that drop even basic IRQ and exception support. These are always going to exist and I think they're a sufficiently separate class of processor that they don't really factor into the compatibility equation, because such processors usually only run one program in their entire lives.

Re: RISC-V: They Should Have Known Better

#277

Post by dmitrygr »

aappleby wrote: post #223

Having written a few RISC-V cores, worked on a chip design project that used RISC-V cores, and generally being OK with the architecture in real-world use cases: What the heck is this guy's problem? Just about every thing he mentioned as a problem is not a problem in practice. Too many options? Who cares, you're not trying to write code that runs on every possible configuration. Either you're writing embedded firmware…

> NOBODY IS DOING THAT.

RePalm kernel is literally that.

Re: RISC-V: They Should Have Known Better

#278

Post by amluto »

aengelke wrote: post #219
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…

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

Fair point.

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

Post reply on HN