
Design of the RISC-V Instruction Set Architecture [pdf] - ingve
http://www.eecs.berkeley.edu/~waterman/papers/phd-thesis.pdf
======
ndesaulniers
This should be a good read. I aspired to do stuff like this in my undergrad:
[https://github.com/nickdesaulniers/Omicron/blob/master/Proje...](https://github.com/nickdesaulniers/Omicron/blob/master/ProjectReport.pdf)

People like the author, Andrew Waterman, and others like Bunnie Huang who work
towards making more of computing open are inspiring. I feel like the last
piece of the puzzle is open FPGAs. I'm quite sure FPGAs are critical to the
open hardware movement.

I should quit Google and solve this...

~~~
ndesaulniers
Also, some choice quotes I've pulled while reading chpt2 ("Why Develop a New
Instruction Set?"):

* MIPS: ...MIPS remains a trademark of Imagination Technologies; MIPS compatibility cannot be claimed without their permission.

* SPARC: SPARC Intl. continues to grant licenses for v8 and v9...for $99...[but] continued development of Oracle SPARC is proprietary.

* Alpha: The Alpha also highlights an important risk of using commercial ISAs: they can die.

* ARMv7: Between ARM[v7] and THUMB, there are over 600 instructions...NEON adds hundreds more.

* ARMv8: The compact THUMB instruction set has not been brought along to the 64-bit address space...as we show in cpht5, it cannot compete in code size with a variable length ISA.

* 80x86: Intel [has done all these great things]...the design quality of the ISA is not one of them.

~~~
nickpsecurity
Good list. Let me add to it.

SPARC: Don't forget the only production-ready, GPL'd CPU from Gaisler & its
proprietary improvements. Also, Fujitsu and Russia have SPARC processors. Not
just Oracle. Fujitsu's are badass.

[http://www.gaisler.com/index.php/products/processors/leon3](http://www.gaisler.com/index.php/products/processors/leon3)

[http://www.gaisler.com/index.php/products/processors/leon4?t...](http://www.gaisler.com/index.php/products/processors/leon4?task=view&id=338)

Alpha: Yes, it died. However, my digging found that Intel and Samsung spun it
off into a dedicated company licensing Alpha to anyone interested. Only found
one vendor that bought it for machines. Nobody major wanted it to exist enough
to buy a license. So, the market killed it.

ARM: Similar issues to MIPS in that ARM will sue your ass any chance they get.
There's a reason the clone went with ARMv2 and said it was not for profit. ;)

Intel did a great one in the past. Still available but crippled. Look here:

[https://en.wikipedia.org/wiki/Intel_i960](https://en.wikipedia.org/wiki/Intel_i960)

POWER and PPC stayed head to head with Intel for years with many PPC cores and
boards in embedded. Even in FPGA's. They also accelerated decimal ops nice for
business apps.

[https://en.wikipedia.org/wiki/PowerPC](https://en.wikipedia.org/wiki/PowerPC)

Dreamcast had a Super-H. Those are still around with their own cost-benefit
analysis:

[https://en.wikipedia.org/wiki/SuperH](https://en.wikipedia.org/wiki/SuperH)

~~~
smcl
Just to add a little bit more - there's been a handful of developments around
the SuperH as patents start to lapse. The Open Processor Foundation have a
couple of SuperH implementations you can use on an FPGA (note: I haven't tried
this) they've got a bit of information up at their website:
[http://0pf.org/](http://0pf.org/)

However this article is a better introduction IMO:
[https://lwn.net/Articles/647636/](https://lwn.net/Articles/647636/)

~~~
nickpsecurity
Yep. Neat that it's getting a revival.

------
zhemao
Haha, so Andrew's thesis is on here, too. If you like this, you might also be
interested in the tech report we published just recently on RocketChip, our
open-source RISC-V SoC generator.

[https://www.eecs.berkeley.edu/Pubs/TechRpts/2016/EECS-2016-1...](https://www.eecs.berkeley.edu/Pubs/TechRpts/2016/EECS-2016-17.html)

I'm a grad student at the UC Berkeley architecture lab and worked with Andrew
before he graduated. I'll also be interning at his new company, SiFive, over
the summer. Happy to answer any questions you might have on RISC-V or
RocketChip.

------
rwmj
The best part of this paper is the thorough analysis of why existing ISAs suck
(chapter 2).

~~~
wmu
It's interesting why the ISAs suck or getting rotten over time (for example
x86). I mean, designing an ISA is not a job for interns, it have to be
developed by experienced engineers. So, are all these guys have no idea what
they're doing? Or, maybe some non-visible factors force certain decisions?

~~~
jabl
Like is said in the abstract, the designers of risc-v have the advantage of 3
decades of hindsight. So they could avoid stuff that was considered good back
in the day but history showed was more a disadvantage, like delay slots ot
register windows.

The cynic in me likes to think that existing proprietary isa's keep adding new
instructions partly to keep customers on the upgrade treadmill. If you design
an open ISA from a clean slate, you can make a nice orthogonal one from the
get go.

------
clarry
Lovely paper.

How about the silicon? By now we've seen quite few more-or-less open
microarchitecture designs (with various ISAs), and it sure must be nice to
dream up a new, lean ISA on paper, even simulate it in software.. but I would
like to run Doom on it. And Quack. And not just in a simulation.

What are the chances that I can actually get to play with this design as I can
with an AVR microcontroller on a breadboard or some ARM chip in one of these
cheap evaluation boards? In, say, the following 5 or 10 years? Is it just a
dream?

Will it be like the CPUs in the Lemote computers? Way underpowered, even
compared to a high end smartphone chip, and power hungry enough to require a
noisy fan?

~~~
ac29
lowRISC [0] is designing a RISC-V chip and intending to finish tape out this
year.

[0] [http://www.lowrisc.org/](http://www.lowrisc.org/)

------
bluetomcat
I have often wondered, do we really need any general-purpose registers to be
visible in the ISA? Aren't they an implementation detail, just like caching?

IMHO, a memory-to-memory architecture would make for a much simpler ISA and
allow much easier code generation (no register allocation needed).

~~~
ndesaulniers
I don't understand this comment, maybe because I can't picture what a "memory-
to-memory architecture" would look like.

You MUST worry about registers due to the exponential increase in latencies
between registers and larger memory communicating with the ALU. Also, limited
are the amount of execution units.

If all memory accesses cost the same in terms of latency, then yes, registers
would be an implementation detail.

~~~
bluetomcat
Eliminating GP registers from the ISA doesn't preclude any optimizations which
could be done dynamically in the microarchitecture. The CPU would still be
able to deal with registers and caches internally, it's just that they won't
be visible to the programmer.

Think of how x86-64's 16 architectural registers are dynamically renamed to
more than 120 physical registers.

~~~
ndesaulniers
That certainly is an interesting idea to think about.

I would think it's hard to beat the compiler though (when it knows how many GP
registers there are). Consider register pressure. If the compiler assumes
there are infinite GP registers (because they're hidden now, no longer an
implementation detail), it can generate code that spends more time spilling
and reloading registers than computing.

The compiler has seen the code before; it knows how many variables it will
need to work with an how to schedule available resources. The processor
(relatively) simply is executing a stream of instructions. It would have to
look pretty far ahead (VLIW) or have sufficient execution units (superscalar)
to have high throughput and not get bogged down spilling.

But, if the finite amount of resources, like number of processing units or
GPRs become very high relative to the amount of symbolic variables, then I
think the register names could be hidden.

~~~
chrisseaton
> when it knows how many GP registers there are

But compilers don't know this! They know how many registers there are in the
ISA, but not how many there really are in the physical architecture.

Physical architectures map ISA register names into register file locations.
It's an abstraction! You can really use a register more than once at the same
time because they will be renamed. Your parent is suggesting that we read and
write from memory as normal, and just map memory locations into the register
file, rather than ISA register names.

Registers may be more of an abstraction than you realise.

(Maybe compilers do know about how large the register rename buffer really is
on certain physical chips and take this into account when allocating them.
Sounds like something Intel's C compiler might do. I'm not an expert.)

~~~
vardump
> You can really use a register more than once at the same time because they
> will be renamed.

What do you mean by this?

Do you realize register renaming is only done for instruction scheduling
purposes, to avoid bubbles in the pipeline?

~~~
Someone
I guess he refers to pipelining, which sort-of can give you a logical register
twice. For example, you may be able write a new value to a register before the
instruction writing out the old value has completed.

~~~
chrisseaton
Yes. I'm not an architecture expert but I understand that if you do something
like:

    
    
        addl    %ebx, %eax
        movl    %eax, foo(%rip)
        addl    %ecx, %eax
        movl    %eax, bar(%rip)
    

Then the second add can start while the first and the first mov are still
running, because the logical reuse of eax is independent of the first and so
will receive a different entry in the rename buffer.

Happy to be confirmed or corrected by someone who knows more.

------
jkeler
It defines extensions but no way to detect them. Am I missing something?

~~~
cesarb
Take a look at the mcpuid register (one of the CSR registers) in the draft of
the privileged architecture specification.

