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

Open source RISC-V implemented from scratch in one night

github.com

Post reply on HN
Print view View original

71–80 of 114 posts

Re: Open source RISC-V implemented from scratch in one night

#71

Post by rayiner »

shawnz wrote: post #49
AnIdiotOnTheNet wrote: post #46

Earlier quoted context omitted.

It isn't the telemetry that's slowing us down, but layers upon layers of (mostly needless) abstraction and buffer bloat. Windows 95 had most of the things we use in a GUI environment today and it ran on a 486 with 8MB of ram. When packaged in Electron with a javascript x86 emulator it is still smaller than many modern text editors. Plenty of GUIs ran on significantly less. Since the modern web is basically one of the…

What layers of abstraction are we stacking? Sure, there's electron/v8, but that's just one layer. You said yourself that notepad in an electron-based x86 VM is still pretty small, so clearly electron itself isnt the problem. Maybe people just demand more from their software these days, and all these little conveniences just add up more than you'd realize? That would also explain why the system is not "doomed in the e…

What conveniences? Most web apps (e.g. Google Docs) have less functionality than their Win95 counterparts, notwithstanding the stupendous amounts of added bloat.

Re: Open source RISC-V implemented from scratch in one night

#72

Post by bogomipz »

opencl wrote: post #58
bogomipz wrote: post #50

Earlier quoted context omitted.

I am curious if you how how this compares to The Great Suspender? I also don't understand why Chrome and Firefox don't buil tab managers directly into the browser.

Firefox used to have Tab Groups, it got removed but the webextension API got some new features specifically to support similar functionality in an extension. i.e. https://addons.mozilla.org/en-US/firefox/addon/basic-panoram... In reality I think it's just not a priority for browser devs because the overwhelming majority of users do not use huge numbers of tabs.

Thanks. Yeah I suspect tab junkies are probably a minority. Do you know is the latest Firefox on par with Chrome in terms of tab usage and memory footprint?

Re: Open source RISC-V implemented from scratch in one night

#73

Post by moftz »

amelius wrote: post #55

> works up to 75MHz How much would this increase if it used an ASIC instead of FPGA? And how much would it cost for different batch-sizes?

Microsemi can use a 111MHz clock for their RISC-V implementation but they recommend a 70MHz limit on the milspec FPGAs. If you scroll down in the readme, they list some other max clock rates for other chips. Also, you can usually mess around a bit with the timing by either changing the seed that the synthesizer is using to place and route or by manually placing and routing signals if you have a high LUT utilization and the tool is struggling with automatic placement.

Re: Open source RISC-V implemented from scratch in one night

#74

Post by akuma73 »

Sorry to burst any bubbles here, but this is s very incomplete implementation.

You couldn’t run anything but small toy programs on this machine. This is more like what a student would build in an undergraduate course in computer architecture.

For example, there is no MMU, no debug support, no traps, no interrupts, no exception handling, no OS privledge levels, no FP, no memory controller etc.

Of course, one wouldn’t implement all of these in a few hours.

The fact that this is RISCV is somewhat of a red herring as you could do a similar thing with a restricted subset of MIPS or ARM or even x86 as they do in UT Austin’s comp arch class.

Re: Open source RISC-V implemented from scratch in one night

#75

Post by gchadwick »

exikyut wrote: post #17

I wonder how easy it would be to port https://github.com/xoreaxeaxeax/sandsifter to the RISC-V instruction set. Would probably be a decent step in the right direction for validating/verifying the future of trusted computing. Although... this gives rise to a 2nd thought. If it was _this easy_ to build a RISC-V implementation, is it all that special, technically speaking? I ask as someone naive about processor design.…

It's not too hard to build a basic processor that can execute enough of an ISA to do something 'real' such as boot Linux, especially if you can craft the kernel build to keep it as simple as possible.

First the complexity comes in fully implementing the whole ISA. Yes RISC-V has an advantage over ARM/x86 in that it will have less cruft, but the complexity in ARM/x86 doesn't exist for no reason. It's driven by real software requirements so RISC-V will need similar complexity if it wants to seriously challenge either architecture (with the advantage they can learn from the previous mistakes made and thus implement things more cleanly).

Second it comes in verifying your design, especially around the fun corner cases. There are plenty of bugs that occur when a series of rare things happens at once (maybe involving some obscure areas of the ISA) which can be very hard to track down. Unless you can successfully hunt down and fix these you'll end up with a phone or a computer that occasionally crashes for no good reason.

Third is making it hit your power and performance targets. It's one thing to say you have a 256-bit data path and can issue 4 instructions per cycle with out of order execution. It's quite another to build such a design so it can actually sustain decent throughput on real software whilst hitting a decent clock frequency and remaining within power budget, especially when you have all of the various complex bits of ISA to deal with.

Re: Open source RISC-V implemented from scratch in one night

#76

Post by nickik »

deeesa1 wrote: post #29

Impressive, I like this! I'm curious more in general how widely risc-v is being used in the industry today already (they mentioned a steep adoption from academia to industry). Looking at the foundation members, there are quite a big number; given they range for risc-v is from small devices to super computers, are there any examples where it's used today and showed benefits over other archs?

Go to the risc-v website, they have constant news and updates about people using it.

Re: Open source RISC-V implemented from scratch in one night

#77

Post by nickik »

gchadwick wrote: post #75
exikyut wrote: post #17

I wonder how easy it would be to port https://github.com/xoreaxeaxeax/sandsifter to the RISC-V instruction set. Would probably be a decent step in the right direction for validating/verifying the future of trusted computing. Although... this gives rise to a 2nd thought. If it was _this easy_ to build a RISC-V implementation, is it all that special, technically speaking? I ask as someone naive about processor design.…

It's not too hard to build a basic processor that can execute enough of an ISA to do something 'real' such as boot Linux, especially if you can craft the kernel build to keep it as simple as possible. First the complexity comes in fully implementing the whole ISA. Yes RISC-V has an advantage over ARM/x86 in that it will have less cruft, but the complexity in ARM/x86 doesn't exist for no reason. It's driven by real so…

> but the complexity in ARM/x86 doesn't exist for no reason. It's driven by real software requirements so RISC-V will need similar complexity if it wants to seriously challenge either architecture

Like what? Are you talking about extensions that don't exist for RISC-V, like Transnational Memory?

I would say most reason for complexity is legacy and there is little actual software requirements in that regard if your doing a new architecture.

Re: Open source RISC-V implemented from scratch in one night

#78

Post by acct1771 »

dtx1 wrote: post #68
kilburn wrote: post #43

Earlier quoted context omitted.

I don't know what "prohibitvely expensive" is in your case, but there's a possibility today: Grab one HiFive Unleashed for $999 [1]: - 4 cores up to 1.5Ghz - 8Gb DDR4 ECC Ram - 1Gbps ethernet Then grab one HiFive Unleashed Expansion Board for $1,999 [2]: - SSD M.2 Connector - SATA3 Connector - x16 PCIE Connector (4 lanes of pcie2) - A bunch of other cool stuff you wouldn't probably use (SPI, FPGA, etc.) Finally grab…

While the hifive is an awesome proof of concept 3,5 k$ for essentially something performing roughly as well as a raspberry pi seems prohibitively expensive for now.

Seems worth it.

My issue would be paying all that, and then strapping closed source hardware to it.

Re: Open source RISC-V implemented from scratch in one night

#79

Post by gchadwick »

nickik wrote: post #77
gchadwick wrote: post #75

Earlier quoted context omitted.

It's not too hard to build a basic processor that can execute enough of an ISA to do something 'real' such as boot Linux, especially if you can craft the kernel build to keep it as simple as possible. First the complexity comes in fully implementing the whole ISA. Yes RISC-V has an advantage over ARM/x86 in that it will have less cruft, but the complexity in ARM/x86 doesn't exist for no reason. It's driven by real so…

> but the complexity in ARM/x86 doesn't exist for no reason. It's driven by real software requirements so RISC-V will need similar complexity if it wants to seriously challenge either architecture Like what? Are you talking about extensions that don't exist for RISC-V, like Transnational Memory? I would say most reason for complexity is legacy and there is little actual software requirements in that regard if your do…

I'm more talking about common things. Take the humble load, give a memory address, get some data into a register, what could be simpler?

Well for one thing your load may come in multiple sizes, can target different kinds of memory (e.g. device memory, non-cacheable memory, fully-cached memory, ARM architecture actually allows you to get quite specific about differing levels or shareability and cacheability too), can be unaligned with respect to the access size (but you still need full performance with them). There are ordering requirements with respect to other loads and stores in the system (even within the same CPU avoiding read-after-read ordering issues may not be simple) and various different kinds of barriers that can effect loads. You get exclusive loads or atomics (some variations can return the data seen so are performing a load on top the atomic op). It may be a vector load that needs to quickly feed the vector register file as opposed to the 'standard' register file. In a multi-processor system you can have various different types of snoop operation coming in that could effect the load. You also need to work out if you're actually allowed to do that load, modern page tables are pretty complex affairs. The page table itself could be changing as the load is executing. A decent chunk of the complexity is for virtualisation support but even without that there's various fiddly bits.

You also have speculative execution attacks to worry about. Certain loads may need to be very sure they should execute before doing anything, others may be free to speculate away and forward data into further speculative execution.

You can certainly build a perfectly functional ISA that avoids a lot of this (and avoid other things by keeping to a simple in-order microarchitecture) but that will loose you a lot of performance.

Re: Open source RISC-V implemented from scratch in one night

#80

Post by brandmeyer »

waterhouse wrote: post #48
Annatar wrote: post #39

Earlier quoted context omitted.

Again: have you looked at the assembler code? Are you able to compare MC68000 assembler and RISC-V assembler? Are you able to compare SPARC assembler and RISC-V assembler? Without being able to do that, it's going to be exceptionally difficult for me to contribute any more to the discussion, especially typing on a mobile telephone. That's my contribution for now, I'm pointing out what to compare with. That point was…

I carefully studied the 2.1 and 2.2 versions of the spec. I wrote, in Racket, a miniature interpreter for lists of RISC-V instructions (just symbolic lists, not the byte strings they assemble into), then wrote programs to compute triangular numbers and Fibonacci, and verified they worked. I've built the RISC-V toolchain and compiled a few test C programs and run them in "spike". I don't think I took more than a glanc…

There are a few instructions that nearly every modern processor ended up adopting, but RISC-V still lacks. Off the top of my head, (with the RV ISA developers response in parenthesis):

- bitwise rotate (let them eat macro-op fusion)

- byte and bit swapping (strictly missing from RV, although proposals exist)

- leading zero count, trailing zero count, and popcount (strictly missing from RV, proposals exist)

- efficient multiword arithmetic (let them eat macro-op fusion, or long dependency chains)

- base + [scaled] index addressing modes (you don't really need those)

- multi-register save/restore instructions (ARMv8 doesn't have them / RVC is equivalent in density to ARMv8, nanoMIPS is irrelevant, let them eat millicode)

So yeah, there are deficiencies. None of them are crippling, but I wouldn't say that RV is super-wham-o-dyne, either.

Post reply on HN