Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

VRoom A high end RISC-V implementation

moonbaseotago.github.io

Post reply on HN
Print view View original

101–110 of 135 posts

Re: VRoom A high end RISC-V implementation

#101

Post by indolering »

webmaven wrote: post #94
Taniwha wrote: post #71

Earlier quoted context omitted.

One other comment about why GPLing something is important for some like me - publishing my 'secrets' are a great way to turn them into "prior art" - you read it here first, you can't patent it now - I can protect my ideas from becoming part of someone else's protected IP by publishing it. I spent a few years working on an x86 clone, I had maybe 10 (now expired) patents on how to get around stupidly obvious things tha…

> One other comment about why GPLing something is important for some like me - publishing my 'secrets' are a great way to turn them into "prior art" - you read it here first, you can't patent it now - I can protect my ideas from becoming part of someone else's protected IP by publishing it. This is a great strategy! > I spent a few years working on an x86 clone, I had maybe 10 (now expired) patents on how to get arou…

> It might be worthwhile to GPL implementations of those expired patents if they are at all likely to be useful.

Probably not. It's always something stupid that can be easily worked around.

The real problem is convincing a jury: no one wants to risk hundreds of millions of dollars based on what 12 random people think. nVidia caved to Intel after building a Transmeta style VLIW chip that could run x86 assembly because a decade long patent battle would have been costly and invalidated patents on both sides.

Re: VRoom A high end RISC-V implementation

#102

Post by Taniwha »

mastax wrote: post #93
Taniwha wrote: post #35

Earlier quoted context omitted.

These days there are few caches that need to be flushed at context switch time - RISCV's ASIDs mean that you don't need to flush the TLBs (mostly) when you contect switch. VRoom! largely has physically tagged caches so they don't need to be flushed, the BTC is virtually tagged, but split into kernel and user caches, you need to flush the user one on on a context switch (or both on a VM switch) - also the trace cache…

Since this was a bit hard to google: ASID = Address Space Identifier. It's a tag that uniquely identifies each processes' entries in the TLB. This ensures that your TLB lookups can be limited to the valid entries for the process, so you don't need to flush the TLB on context switch.

I think the way to think of ASIDs is as each being a separate address space - in effect if you have 15 bits of ASID you have 2^15 - 32k address spaces.

One thing I've done in VRoom! which is an extension on to the RISCV spec is that if we have an N hart SMP CPU (for example a 2 cpu SMT system) we use log2(N) bits of the ASID to select which hart/cpu a TLB entry belongs to - from a programmer's point of view the ASID just looks smaller.

However there's a VRoom! specific config bit (by default off) that you can set if you know that the ASIDs you are going to use for all your CPU's effectively see the same address space - if you set that bit then the per-cpu portion of the ASID tags (in the TLB) become available (ie to the programmer the ASID looks bigger) - it's a great hack because it doesn't get into any critical paths anywhere

Re: VRoom A high end RISC-V implementation

#103

Post by indolering »

ncmncm wrote: post #65
blacklion wrote: post #37

Earlier quoted context omitted.

As far as I understand, RISC-V proponents want to have "recommended" command sequences for compilers, to avoid situation when different RISC-V CPUs will need different compilations. If different RISC-V implementations have different "fuseable" command sequences, we will be in dreadful situation when you will need exact "-mcpu" for decent performance and binary packages will be very unoptimal. And such "conventions" a…

It is always frustrating when you have put in the work to optimize code, and turn out to have pessimized it for the next chip over. The extremum for this is getting a 10x performance boost by using, e.g., POPCNT, and suffering instead a 10-100x pessimization because POPCNT is trapped and emulated.

Isn't the point of the RISC-V extension mechanism is to eliminate instruction emulation?

Re: VRoom A high end RISC-V implementation

#105

Post by throwaway81523 »

HanyouHottie wrote: post #89
codedokode wrote: post #27

The presentation was interesting; but I would like to write an idea that is tangentially related to this CPU. I noticed that modern CPUs are optimized for legacy monolith OS kernels like Linux or Windows. But having a large, multimegabyte kernel is a bad idea from a security standpoint. A single mistake or intentional error in some rarely used component (like a temperature sensor driver) can get attacker full access…

Another approach is to never context switch by running all programs in kernel mode and vetting them with an interpreter/JIT compiler: https://www.destroyallsoftware.com/talks/the-birth-and-death... (only half joking)

That is how the Singularity research OS works, except it's done by static verification in a compiler.

Re: VRoom A high end RISC-V implementation

#106

Post by throwaway81523 »

Taniwha wrote: post #99
panick21_ wrote: post #95

Earlier quoted context omitted.

Is this a hobby? Is there a way to support the project? What your view on that kind of design for a laptop/phone/tablet processor?

It's a personal project, but an expensive one (with very large AWS bills some months), needs a commercial sponsor to end up as a real chip you could put in real platforms and a real chip design team to build it

Maybe there's a way to hit up AMD/Xilinx for an donated or loaned FPGA box so you don't have to use AWS?

Re: VRoom A high end RISC-V implementation

#107

Post by throwaway81523 »

Taniwha wrote: post #16

Author here (Paul Campbell) - AMA

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 condition codes, since the compiler can emit checks for it at the end of a function or basic block, giving the hardware some time to catch up.

Re: VRoom A high end RISC-V implementation

#108

Post by tux3 »

throwaway81523 wrote: post #106
Taniwha wrote: post #99

Earlier quoted context omitted.

It's a personal project, but an expensive one (with very large AWS bills some months), needs a commercial sponsor to end up as a real chip you could put in real platforms and a real chip design team to build it

Maybe there's a way to hit up AMD/Xilinx for an donated or loaned FPGA box so you don't have to use AWS?

You could probably find a riscv intl member company willing to donate small fpga boards, but if this design barely fits on an AWS f1 instance, I think realistically that'd have to be a 5 digit price board

For reference, Digikey unit price for a VU440 floats around the $40-60k range

Re: VRoom A high end RISC-V implementation

#109

Post by timschmidt »

foobiekr wrote: post #82
kinghajj wrote: post #39

Earlier quoted context omitted.

You should look into the Mill CPU architecture.[0] Its design should make microkernels much more viable. * Single 64-bit address space. Caches use virtual addresses. * Because of that, the TLB is moved after the last level cache, so it's not on the critical path. * There's instead a PLB (protection lookaside buffer), which can be searched in parallel with cache lookup. (Technically, there's three: two instruction PLB…

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 still see echos of the Datapoint 2200 in a modern machine.

I'd also like to see further work related to this: https://core.ac.uk/reader/161119546

There's been a lot of recapitulation and growth in the language space recently as well, showing up in languages like Zig and Rust, paving the way for better utilization across heterogeneous and many core architectures. I feel like Rust's memory semantics don't hurt the mill either, and may help a lot.

Re: VRoom A high end RISC-V implementation

#110

Post by Taniwha »

tux3 wrote: post #108
throwaway81523 wrote: post #106

Earlier quoted context omitted.

Maybe there's a way to hit up AMD/Xilinx for an donated or loaned FPGA box so you don't have to use AWS?

You could probably find a riscv intl member company willing to donate small fpga boards, but if this design barely fits on an AWS f1 instance, I think realistically that'd have to be a 5 digit price board For reference, Digikey unit price for a VU440 floats around the $40-60k range

Next step up is probably a VU13P based board, there were a few on EBay a year ago ~$5k, almost bought one, but then bitcoin went up again ..... I'm hoping for a crypto crash ....
Post reply on HN