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

91–100 of 114 posts

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

#91

Post by trumped »

yipbub wrote: post #24
trumped wrote: post #12

Earlier quoted context omitted.

so far, the opposite is happening in the "cellphone"/pocket pc space... it is getting hard to get a phone that you can root without having to resort to "holes" that can get patched at any time...

Can you elaborate please?

Well, most people aren't going to make their own chips any time soon... so you have to buy what is available and cellphones are getting more restricted/locked down everyday in the name of security (they are getting closer to what they used to be before Android came out)... not sure if that answers your question though.

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

#92

Post by akuma73 »

aappleby wrote: post #89
akuma73 wrote: post #74

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…

An Arduino has none of the missing parts you mention (except interrupts), yet it's quite a useful device even in non-toy applications.

The cortex m0/m3 CPUs most certainly do have breakpoints, svc (trap), interrupts and an optional memory protection unit.

The Atmel CPU is more constrained but still has hardware breakpoints, IO instructions, watchdog timers and interrupt support. It also has far more complex addressing modes (more CISC-y) to save on instruction counts and a variable length instruction set encoding where memory space to store code is a first order concern.

I’m also sure there is a memory controller to control the SRAM.

So, even if you were to build a simple micro controller, you’d need a lot more features and most likely higher performance (and power efficiency) than you would get from a trivial 2-stage pipeline. Not to mention there are no instruction or data caches in this RISC-V machine.

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

#93

Post by nickik »

gchadwick wrote: post #79
nickik wrote: post #77

Earlier quoted context omitted.

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

Honestly the believe that those things don't actually improve performance that much. ARM has much of this for historic reasons not because the market demand it. I think ARM has more problems because of the incredibly weak memory architecture. RISC-V quite deliberately and explicitly avoided to have overly complex semantics and went a memory model somewhere between x86 and ARM.

x86 has TSO and still is the fastest, so I think overall you are doing much better for yourself if you avoid massive complexity in your memory model because that is gone cost you in application complexity that you could be using for optimizations.

RISC-V has privilege architecture and a vector architecture as well, and they of course do add complexity, but are still simpler then corresponding functionality in ARM/x86 while doing many things better.

RISC-V was specifically design as it was because the ISA does really not impact performance that much and having something simple and understandable was not going to be a huge performance hit.

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

#94

Post by leibwiht »

_chris_ wrote: post #21
leibwiht wrote: post #20

Earlier quoted context omitted.

My understanding of sandsifter is that it works by executing an instruction next to a page boundary, which gives either a page fault error (the instruction executed correctly and then execution passed over to the next page which is presumably non-executable) or an error indicating the instruction was malformed. So, for it to work on RISC-V you need paging, and also interrupt vectors to work. The MMU was only recently…

Sandsifter is dealing with the problem of "how do I find valid instructions in any 1-15 byte sequence, which yields 2^120 combinations?" In RISC-V there are currently only 2 byte and 4 byte instructions, which you can brute force your way through. The specification does technically allow for longer sequences, in which case sandsifter will work just fine. [And the RISC-v privileged specification has existed for years]…

>And the RISC-v privileged specification has existed for years

It is a draft which has not been finalized and contains a disclaimer that it might be modified in a non-backwards compatible way prior to final release.

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

#95

Post by samsoniuk »

akuma73 wrote: post #74

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…

I fully agree with you about the missing features! However, as long my objective is replace some legacy 680x0/683xx/coldfire processors running small toy programs, I see no need for that complex features. Please keep in mind that although 25% of RV32I instruction set is missing in my implementation, there is no side effect, since that instructions are not relevant for this specific environment (fencex, exxx and csrxxx), since the gcc generates by default exactly the implemented subset and nothing more. I think this is a very important advantage in the RISCV architecture when compared with others and I dont think the gcc will have the same benevolent behaviour in the case of ARM or x86. Maybe for MIPS is possible, but I am not sure about it. Anyway, why not use RISC-V? :)

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

#97

Post by samsoniuk »

akuma73 wrote: post #92
aappleby wrote: post #89

Earlier quoted context omitted.

An Arduino has none of the missing parts you mention (except interrupts), yet it's quite a useful device even in non-toy applications.

The cortex m0/m3 CPUs most certainly do have breakpoints, svc (trap), interrupts and an optional memory protection unit. The Atmel CPU is more constrained but still has hardware breakpoints, IO instructions, watchdog timers and interrupt support. It also has far more complex addressing modes (more CISC-y) to save on instruction counts and a variable length instruction set encoding where memory space to store code is…

Good point, but unfortunately the focus of the project is only the RISC-V core running in a FPGA. Everything else is already widely available in the internet and can be easily integrated.

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

#98

Post by AboutTheWhisles »

akuma73 wrote: post #74

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…

You have pretty high expectations for one night of work

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

#99

Post by samsoniuk »

earenndil wrote: post #2

This is good news for risc-v! The fact that it can be implemented so easily by hobbyists furthers the cause of trusted hardware. Sure, it won't be implementable by hobbyists at the speeds necessary for modern desktop computing, but a trusted security core (something like a yubikey) could be implemented on completely from-scratch hardware, but then still use existing trusted/vetted software (openssl), just a cross-com…

I think the best feature of the RISC-V instruction set is that is very clear and very simple. The RV32I instruction set is composed by ~40 different instructions and, depending of the environment and the implementation, you don't even need implement all them, as long the compiler will never generate some instructions. A simpler core means faster clock rates, less logic and more cores per chip, which much more performance. By this way, although the performance in the FPGA is not so good as in a ASIC, the results are not so bad:

https://www.hotchips.org/wp-content/uploads/hc_archives/hc29...

With 1680 RISC-V cores running in parallel at 250MHz, the result is impressive, even working in a FPGA!

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

#100

Post by samsoniuk »

bem94 wrote: post #23

Whoa. This is very impressive! It does seem to hilight an increasing unease I have with riscv. Implementations are many and cheap, but reusable verification is rare and people don't use what is out there. They have maybe the riscv-tests set working. But that's not enough to call your new CPU usable for anything other than a hobby project. Fwiw, the riscv-formal package from Clifford wolf is the closest thing to a tur…

hmmm... I promise investigate this topic in the future!
Post reply on HN