[deleted]
VRoom A high end RISC-V implementation
121–130 of 135 posts
Re: VRoom A high end RISC-V implementation
#122Earlier quoted context omitted.
Do you think it is feasible to add some kind of sticky overflow detection bit for integer arithmetic, the way IEEE 754 specifies for FP? The hope is to be able to efficiently implement checked arithmetic as required by e.g. Ada. It came as a real disappointment that RiscV seems to have made that harder rather than easier, compared to the x86 and its ilk. The sticky bit is hopefully more efficient than traditional con…
RISCV doesn't have condition codes, which makes building systems like this with lots of ALUs a lot easier, everything happens in the registerfile and the renaming system. It does have 'sticky' state bits for FP and I can see how I'll implement them - the big problem is not setting them (because they can be accumulated in any order as instructions hit the commit stages), it's how you test them that effectively becomes…
Right, the idea of the sticky bits is that you can execute a number of instructions before hitting a sync point, as compared with traditional condition flags or exceptions which have to potentially sync on every instruction. The hope is for that have less effect on performance. I don't know if it causes issues with modern FPU's. Are imprecise exceptions (like on some old machines) still a thing? I wonder if there is a way to record the exception info so its origin can be reported even if it is not noticed til later.
Re: VRoom A high end RISC-V implementation
#123Earlier quoted context omitted.
RISCV doesn't have condition codes, which makes building systems like this with lots of ALUs a lot easier, everything happens in the registerfile and the renaming system. It does have 'sticky' state bits for FP and I can see how I'll implement them - the big problem is not setting them (because they can be accumulated in any order as instructions hit the commit stages), it's how you test them that effectively becomes…
Right, the idea of the sticky bits is that you can execute a number of instructions before hitting a sync point, as compared with traditional condition flags or exceptions which have to potentially sync on every instruction. The hope is for that have less effect on performance. I don't know if it causes issues with modern FPU's. Are imprecise exceptions (like on some old machines) still a thing? I wonder if there is…
If you don't synchronise it's not an issue :-) but if you have 100+ instructions in motion at any one time creating a bottleneck at the end of every basic block would likely have a big effect on how things run.
Normally we retire up to 8 instructions per clock - merging 8 bits of sticky state is some simple logic (some or gates, it doesn't matter what order they get processed in), merging 8 saved PCs (which one do you save?) is harder, it probably means a priority encoder (order probably does matter) and a 63 bit mux (still doable in a clock though)
Re: VRoom A high end RISC-V implementation
#124What does GPL mean for a chip design? I understand how it applies to the HDL, but I doubt that it obligates you have to open your code to users of physical chips.
IANAL, but as far as I know it's very important it's GPLv3 which means the antitivoization clause, which means that hardware that uses this firmware must provide full source code and a way to let you use your own firmware. If somehow this code is not in a firmware... No idea.
(this is a light derail but related)
some of this design IS firmware - the lowest level bootstrap is encoded into an internal ROM - currently it's a very dumb bootstrap, a real implementation would boot from a number of possible sources. The sources are there on github.
All the ARM systems you can buy today have a similar embedded boot loader - almost all of them do not release that source, because it's the root of their secure boot chain.
IMHO this code should be public (but not the keys)
Re: VRoom A high end RISC-V implementation
#125Earlier quoted context omitted.
Right, the idea of the sticky bits is that you can execute a number of instructions before hitting a sync point, as compared with traditional condition flags or exceptions which have to potentially sync on every instruction. The hope is for that have less effect on performance. I don't know if it causes issues with modern FPU's. Are imprecise exceptions (like on some old machines) still a thing? I wonder if there is…
If you don't synchronise it's not an issue :-) but if you have 100+ instructions in motion at any one time creating a bottleneck at the end of every basic block would likely have a big effect on how things run. Normally we retire up to 8 instructions per clock - merging 8 bits of sticky state is some simple logic (some or gates, it doesn't matter what order they get processed in), merging 8 saved PCs (which one do yo…
Ah, well, you're better equipped than I am to figure this out. Anyway the FPU will have to deal with it. Maybe if the big float computations are mostly vector ops, though, that will help.
Re: VRoom A high end RISC-V implementation
#126Earlier quoted context omitted.
SASOSes are interesting, sometimes extending a 64-bit address space to cover a whole cluster, but they aren't compatible with anything that calls fork(). The various variants of L4 have pretty good context-switch latency even on traditional CPUs, and seL4 in particular is formally proven correct on a few platforms. Spectre+Meltdown mitigation was painful for them, but they're still pretty good. Lots of microcontrolle…
What I would like to have is a context switch latency comparable to a function call. For example, if in a microkernel system bus driver, network card driver, firewall, TCP stack, socket service are all separate userspace processes, then every time a packet arrives there would be a context-switching festival. As I understand, in microkernel OSes most system calls are simply IPCs - for example, network card driver pass…
At the core of any protection boundary crossing is likely going to be a pipe flush (throwing away of tens or maybe 100+ instructions) - post spectre/meltdown we all understand that speculating past such a point into a differently privileged environment is very fraught.
I think this means we won't be seeing 'call gate' equivalents that perform close to subroutine calls on high end systems any time soon if at all
Re: VRoom A high end RISC-V implementation
#127Earlier quoted context omitted.
I was also going to mention the Mill, but it's become a bit of a Flying Dutchman that people tell tales of but which probably doesn't exist.
Fundamental rethinks take time. The ideas expressed by the mill folks have value independent of any specific implementation or absence thereof. Yosys is incredible and the dropping cost and increasing availability of capable FPGA dev boards equally so. I wouldn't put it past a sharp CS major to whip up a toy mill cpu in FPGA these days just based on what's been shared publicly. It's a bit strange to me that I can sti…
They won't commercialize their design. Your best bet would be to reverse engineer their designs and build your own.
Re: VRoom A high end RISC-V implementation
#128Earlier quoted context omitted.
What I would like to have is a context switch latency comparable to a function call. For example, if in a microkernel system bus driver, network card driver, firewall, TCP stack, socket service are all separate userspace processes, then every time a packet arrives there would be a context-switching festival. As I understand, in microkernel OSes most system calls are simply IPCs - for example, network card driver pass…
At the core of any protection boundary crossing is likely going to be a pipe flush (throwing away of tens or maybe 100+ instructions) - post spectre/meltdown we all understand that speculating past such a point into a differently privileged environment is very fraught. I think this means we won't be seeing 'call gate' equivalents that perform close to subroutine calls on high end systems any time soon if at all
Though you certainly know more than I do about the subject, my understanding is that differently privileged environments can enqueue messages to each other without pipeline flushes, and general forms of that mechanism have performed better than subroutine calls on high-end systems since the early 01990s: Thinking Machines, MasPar, Tera, even RCU on modern amd64.
And specialized versions of this principle predate computers: a walkie-talkie has the privilege to listen to sounds in its environment, a privilege it only exercises when its talk button is pressed and which it does not delegate to other walkie-talkies, and the communication latency between two such walkie-talkies may be tens of nanoseconds, though audio communication doesn't really benefit from such short latencies. The latency across a SATA link is subnanosecond, which is useful, and neither end trusts the other.
Re: VRoom A high end RISC-V implementation
#129Earlier quoted context omitted.
At the core of any protection boundary crossing is likely going to be a pipe flush (throwing away of tens or maybe 100+ instructions) - post spectre/meltdown we all understand that speculating past such a point into a differently privileged environment is very fraught. I think this means we won't be seeing 'call gate' equivalents that perform close to subroutine calls on high end systems any time soon if at all
Though you certainly know more than I do about the subject, my understanding is that differently privileged environments can enqueue messages to each other without pipeline flushes, and general forms of that mechanism have performed better than subroutine calls on high-end systems since the early 01990s: Thinking Machines, MasPar, Tera, even RCU on modern amd64. And specialized versions of this principle predate comp…
oh totally, but then you aren't "making a procedure call" you're doing something different.
In this case your data is likely traversing the memory hierarchy far enough so that the message data gets shared (more likely the sending data goes into the sending CPU's data cache and the receiving one will use the cache coherency protocol to pull it from there) - that's likely to take of the order of a pipe flush to happen.
You could also have bespoke pipe-like hardware - that's going to be a fixed resource that will require management/flow control/etc if it's going to be a general facility
Re: VRoom A high end RISC-V implementation
#130Earlier quoted context omitted.
Though you certainly know more than I do about the subject, my understanding is that differently privileged environments can enqueue messages to each other without pipeline flushes, and general forms of that mechanism have performed better than subroutine calls on high-end systems since the early 01990s: Thinking Machines, MasPar, Tera, even RCU on modern amd64. And specialized versions of this principle predate comp…
oh totally, but then you aren't "making a procedure call" you're doing something different. In this case your data is likely traversing the memory hierarchy far enough so that the message data gets shared (more likely the sending data goes into the sending CPU's data cache and the receiving one will use the cache coherency protocol to pull it from there) - that's likely to take of the order of a pipe flush to happen.…
Agreed, but even in the cache-line-stealing case, those are latency costs, while a pipeline flush is also a throughput cost, no? Unless one of the CPUs has to wait for the cache line ownership to be transferred.