Berkeley’s RISC-V Wants to Be Free
eejournal.com
eejournal.com
I scan-read the paper, but did not encounter any number of registers. Does anybody know, how many registers this architecture has/supports ... is there any implementation yet?
Hope, there will be an implementation soon, and maybe a smartphone or tablet computer based on it... (or a new Raspberry?)
Edit: Now I see, should be 32 registers, based on the 32bit opcode-format (5 bits to address any register).
It's quite possible: http://www.lowrisc.org/
More from the page, enough to get me interested:
On performance: "As a rough guide we would expect ~500-1GHz at 40nm and ~1.0-1.5GHz at 28nm."
Is volume fabrication feasible?
Yes. There are a number of routes open to us. Early production runs are likely to be done in batches of ~25 wafers. This would yield around 100-200K good chips per batch. We expect to produce packaged chips for less than $10 each.
Looking at this slide show: https://speakerdeck.com/asb/lowrisc-a-first-look I see they're doing some very interesting things. Besides a lot of usual stuff, 2 cores each with I+D L1 and a shared L2 cache, they've added tags!
2 bits of tags, and they're thinking general purposes (e.g. GC) as well as security. That's big, something we haven't seen in hardware since Lisp Machines, to my knowledge.
Also I/O "minions", non-coherent RISC-V cores, like the CDC 6600 etc.
I'm now quite interested in the project.
Read and write barrier instructions could be very nice for GC, but those can be done at the page level, I think (I would look at the Azul's Pauseless collector for one state of the art custom hardware approach, and their C4 for doing without on x86_64).
But I'm more interested in tags for dynamically typed languages like Lisp. You don't need many bits, Symbolics used only 4 "hard" ones in the 36 bit 3600 line, which allowed for immediate 32 bit integer and floating numbers, then another 4, leaving 28 bits for word based addressing.
In modern byte addressed CPUs, you can use the least significant bits that are 0 in a pointer for tagging, so the 2 "hard" bits you propose are enough to work with. Basically, as long as we don't have to box floats!
Although it would be nice if we could set things up so that e.g. floating point operations could proceed at full speed, generating a fault if the tag bits on the operands aren't correct ... although superscalar CPUs can do both in parallel without "hard" tags. Are your two main cores going to be superscalar?
And I guess to finish my wishlist, a potential for a lot of ECC DRAM would be nice, at least 16 GiB.
ADDED: flip side is don't let the Second System Syndrome sink this effort (the Raspberry Pi being the first; just going to your own new architecture SoC is a really big step!).
"We did not include special instruction set support for overflow checks on integer arithmetic operations. Most popular programming languages do not support checks for integer overflow, partly because most architectures impose a significant runtime penalty to check for overflow on integer arithmetic and partly because modulo arithmetic is sometimes the desired behavior."
!!!
Or, RISC-V is a Worse is Better (https://en.wikipedia.org/wiki/Worse_is_better), New Jersey style processor, following the same exact model of the primacy of implementation simplicity.
Well, especially since we aren't going to get people to use "safe" languages prior to e.g. software errors killing 4-6 figures of people, I guess it's a really good thing you're adding tag bits that can be used to improve security in unsafe languages.
On the other hand, as a CPU for The Right Way operating systems and languages like Lisp, RISC-V would seem to be ... subpar, especially since who knows what other corners have or will be cut. (Yeah, I know you can check, and for Lisps, it would be fairly cheap to have fixnums be 32 to 29 bits (subtracting LSB bits for more tagging) and then promote them to bignums, but....)
While I think you're doing a very good thing for the world as it is, my personal interest has dropped ... but that's OK, I've got a couple of years to muse about this as you develop your design and get it into production.
I find this argument VERY weak: you need many of these 'very rarely taken branch' overflow checking instructions and they pollute the instruction cache..
The IBM AS/400 or whatever it is called this week uses tags too for security. (A bit is flipped if a pointer is written too thereby preventing changing pointers.) The PowerPC chip has optional support for tags because of this.
Source: http://www.amazon.com/Inside-AS-400-Second-Edition/dp/188241...
[by the way, the PDF at http://riscv.org/download.html#tab_isaspec is clear reading]
I am wondering, what the advantage of a zero register is? I thought about supporting direct operations, but adding zero does not make to much sense, same with minus, multiply, division .... OR/AND/XOR does also make not much sense. Storing data into this register also does not make to much sense ... or as garbage tray??? ;) (the hardware implemented garbage tray was once the April fool joke in an IT magazine).
For example, the original MIPS instruction set has these pseudoinstructions:
- li $d, imm (load immediate) is replaced with ori $d, $0, imm (or immediate with the zero register)
- not $d, $s (bitwise complement) is replaced with nor $d, $0, $s (bitwise NOR with the zero register)
... and some others as well.
It's useful for several things. One is as a no-op instruction; as you point out, AND, OR, XOR, etc. with zero are no-ops, and no-ops are sometimes useful for achieving certain alignment in code, or leaving space for instructions to be patched out with other code (which is common for debugging, tracing, and hot-patching of code).
It can also be used for copying from one register to another, without another instruction. "ADD rd, rs1, 0" is a way to write "MOVE rd, rs", so you don't need to waste an extra instruction on that.
0 is also one of the most common values that you want to compare against (many loops can be turned into decrementing a value until it becomes zero, or you're just walking along a data structure or string until you encounter a null value), and so their branch instructions work by comparing two registers and branching to a particular offset. Having a dedicated 0 register means you can always do a compare against 0 and branch in a single instruction, without having to have separate instructions for comparisons against immediates versus comparison of two registers.
[1]: http://www.eecs.berkeley.edu/Pubs/TechRpts/2011/EECS-2011-63...
The other examples are also valid, but rather special to RISC architectures ... but of course it does the trick.
The uncomfortable reality here though is that this is just another project from the ultimately failed MIPS/SPARC view of the world. ARM has little to zero academic credibility as it is really just a jumped up 6502. This lack of any sort of theoretical purity is really their big strength.
I think that statement is taking a few more shortcuts than are warranted.
I'd argue that's part of why it's been so successful, especially in competition with the other big ISA - x86. Complex instructions are good because they do a lot in a small size, and a small size is good because it conserves cache usage and memory bandwidth; decoding is rarely the bottleneck now. That's why ARM has Thumb, and their latest cores are similar to x86's uop-decoding and decoupled decoder/execution units.
The whole "it can be done faster in software" idea of RISC was mainly based on some early CISC microarchitectures that weren't implemented as efficiently as they could be, which doesn't imply that they couldn't be. Look at all the instructions added by the various SSE extensions, for example; the performance/speed improvements they provide are real, and the cost of the hardware is basically negligible in comparison.
Here's an interesting comparison where ARM and x86 are quite close in power efficiency, while MIPS is relatively far behind: http://www.extremetech.com/extreme/188396-the-final-isa-show...
These have changed throughout history, e.g. when I was reading the Wikipedia CDC 6600 page, it pointed out magnetic core memory of the time could be much faster than germanium transistor CPUs (we're talking about the days when transistors had serial numbers!), and the silicon ones it were built with were fast enough that, with clever architecture (a 60 bit floating point multiply or divide still took many more cycles than a fast memory cycle) and compilers, a theoretical 3 MFLOPs resulted in an achievable 0.5 MFLOPS in FORTRAN. My first job in 1980 was supporting applied mathematicians who ran their FORTRAN on CDC and CRAY hardware at NCAR a couple of thousand miles away. One thing they were always concerned with was to write their array manipulations in a way that the compiler recognized to use the vector hardware.
Back then there was a huge premium on getting a serious CPU on a single die, and I think the speed mismatch with DRAM wasn't hardly as severe.
Also on this topic: if the original MIPS was indeed very simple, recent versions added thumb-like code compression, SIMD extensions, DSP extensions... As everyone else does really. And you can get similar CPU benchmarks level as other architectures. Then the very same instruction architecture can have pretty wide power efficiency differences depending on implementations. Just look at Atom vs. Core, A8 vs. 15... Even the same model shows big differences based on implementation choices (optimize for speed vs. area/cost for example).
As someone working on SoC, I believe the key difference in MIPS vs. ARM vs. Intel is not so much the instruction set, but the work effort spent on optimizing the implementations close to the processes. It's pretty obvious for Intel, but ARM spends a lot of time with the big foundries (TSMC, GlobalFoundries, Samsung) to make sure their implementation are well tuned. And they pass on the know-how to their customers through what they call "POPs" (Process Optimization Packages). This is important for ARM, but also for the foundries as ARM is the de facto standard in mobile. A lot of work go in this, and it shows at the high end. MIPS/Imagination recently propose something similar for MIP, but they're far from having the same amount of resources. That's the main difference between MIPS and ARM at the high-end IMHO.
Unix came from Bell Labs in the East Coast. Californian Unix is just a non-elegant derivative, in my opinion (e.g. BSD sockets don't follow the "Unix philosophy", and one explanation could be the LSD, I agree with that).
So for embedded use if performance is not important, I would seriously consider it.
CPU design is all about the tradeoff between size, complexity, speed and power consumption.
New RISC architectures tend to start on the low-end of the scale (clean architecture, short pipeline, small die), and if they are successful, move toward the x86/ugly/big/complex/fast spot.
We don't have a production-quality SoC out, so "practical use" is still a ways away.
Rocket on the other hand is a full-fledged in-order core with hardware mutliplier, single-precision and double-precision floating-point units, and MMU. Therefore, it can do things like boot a full Linux kernel, which the ZPU cannot. Rocket also has the RoCC co-processor interface, which allows you to define your own ISA extensions in Chisel.
First, I'd just go with a MIPS core. This is effectively the original RISC core, after all. Most patents have expired, and the Chinese have an implementation.
If I didn't do that, I'd probably go with a DEC Alpha core. A shrunk, voltage optimized Alpha core was what drove the StrongARM series, and people raved about it. The Alpha architecture up through EV5 is quite clean.
Given that most data suggests that ecosystem and optimization is more important than basic architecture, reinventing the wheel is not a good thing here.
Sparc is open back at the T1 T2 era pre oracle takeover. That's not a bad place to go, but MIPS is not really ideal due to a lot of factors that make the Chinese clones less than appealing.