Hacker News Reader

To address a couple of these points:

- Assembler syntax is a matter of personal preference. I also loved programming the 68K, writing OS-9/68k drivers back in 1990. However the vast majority of even kernel/embedded programmers rarely touch assembler these days.

- SPARC & register windows. A very unfortunate design choice in hindsight. The RISC-V ISA developers have paid very close attention to existing designs, and other ISAs and microarchitectures are frequently referenced. Have a look at the discussions on the ISA-Dev mailing list: https://groups.google.com/a/groups.riscv.org/forum/#!forum/i...

- RISC-V is trying to avoid patents, so they cannot necessarily reuse existing ISAs, even open ones.

- SPARC & register windows. A very unfortunate design choice in hindsight.

What do you mean, unfortunate design choice? The register windows help compilers and provide 256 virtual registers, thus significantly boosting performance. It's one of the biggest, best features of the Scalable Processor ARChitecture.

And that's the exact feature RISC-V considers "unfortunate". I cannot believe it!

Considering that the OpenSPARC cores are under the GPL, what impact do patents have in that case?

Register renaming is a better way to provide large numbers of hardware registers.

Another aim of RISC-V is to provide an architecture which is both easy to implement at the low end, and can be scaled at the high end. Register windows are not easy to implement. Register renaming OTOH can be left out of low end designs and included (as an invisible microarchitectural detail) at the high end.

The smallest RISC-V implementation is PicoRV32 which is ridiculously small (https://github.com/cliffordwolf/picorv32 - smallest is 725 LUTs in an FPGA). It couldn't have been done if the architecture had register windows.

BTW I'm fairly certain that high end SPARC implementations must be doing register renaming, otherwise each function is limited to 8 or 16 registers.

Okay, so if we assume that implementing register windows is hard, why tackle the problem again, instead of reusing what is already there? The entire work appears to me to be the authors' personal bias against SPARC, possibly wanting to implement an entire processor from scratch, at all costs, no matter what. The patent argument seems very illogical for a code base under the GPL. Something just doesn't seem right.

> possibly wanting to implement an entire processor from scratch

Wanting to facilitate others to do so, sure. This is a common thing to do in a computer engineering program, and I believe it was an explicit design goal that student projects could be real RISC-V implementations instead of targeting the toy ISAs commonly used for this purpose.

If RISC-V is supposed to scale down to the low end, why doesn't it have delay slots? On an implementation with a simple instruction pipeline, delay slots not only improve performance, they also simplify the hardware.

Because you shouldn't expose such micro-architectural details in an ISA which is trying to be stable for the next 50 years (yes really -- see discussions on the mailing list).

The very very low end PicoRV32 is not pipelined (unsurprisingly). More ordinary low end (eg. Rocket) has the canonical Hennessey-and-Patterson 5 stage pipeline and still doesn't need to expose branch delay slots in the ISA.

I should say also that the classical MIPS -- ie. no instruction dependencies -- was another mistake in hindsight.

Because you shouldn't expose such micro-architectural details in an ISA which is trying to be stable for the next 50 years

...and earlier you wrote

However the vast majority of even kernel/embedded programmers rarely touch assembler these days.

It is unclear to me why this double-standard is okay: on one hand, that which is really important, like assembler syntax and mnemonics is exposed and yet not considered relevant, but "micro-architectural details" which really don't hurt me as the coder one way or the other should be hidden.

I am not sure who the RISC-V designers expect for their audience, nor why this double standard, but in the light of "the 50 year plan", it appears that the designers haven't given it much thought, if any at all.

In the end is this: we have a RISC-V processor design which is not human friendly as far as mnemonics go, and with such processors, relying on compilers will be the only practical solution. Who has not learned from the lessons of history is in for another bitter teaching: such attempts have failed miserably in the past. As evidence, I point to PA-RISC and Itanium. If it were but for a better compiler!

Microarchitecture has a technical meaning here - it means the implementation of the chip. The ISA should be separate from the microarchitecture, although very often they are not (common examples being: branch delay slots, register windows, non-interlocking pipeline stages).

The microarchitecture is nothing to do with the assembler syntax or instruction set.

The microarchitecture is nothing to do with the assembler syntax or instruction set.

I know that, my point is that this processor design has completely screwed up priorities in terms of features and usage.

I should say also that the classical MIPS -- ie. no instruction dependencies -- was another mistake in hindsight.

What do you mean by "no instruction dependencies"?

I actually meant "without Interlocked Pipeline Stages" which is what the "IPS" originally stood for in MIPS. Again it's a microarchitectural detail which was exposed through the instruction set, and later MIPS abandoned it.

My understanding is that the very large number of registers on the SPARC made context switching very slow --- you need to flush up to several hundred registers onto the physical stack and then restore them again later; while at the same time, processors rarely had enough registers to run non-trivial programs without causing overflow traps. So, the extra complexity wasn't really considered worth it, and it was better to devote silicon to other optimisations rather than exposing what is basically a processor implementation detail in the ISA.

However, my knowledge is years old. Have these problems been solved?

However, my knowledge is years old. Have these problems been solved?

They must have been. I used some Snoracle T4 hardware, and the CPU's were blazingly fast. How they did it though, I don't know, as I didn't have a chance to look into it.

Oracle is the steward of SPARC, who knows what might happen to it. RISC-V is controlled by a non-profit industry consortium.

SPARC International is the steward of SPARC.

Based on your behavior in this comment thread -- downvoting comments that give valid criticism of the RISC-V ISA -- I have to conclude that the reason the RISC-V folks chose not to reuse a patent-unencumbered ISA such as SH2 or MIPS32 (minus the unaligned load-store instructions) is simple vanity.

What does your comment add to the discussion, and what is the proof of what you are attributing to the user?

For one, MIPS32 and SH2 are both 32-bit ISAs. Extending them to 64-bit would require just as much compiler re-working as building a new RISC ISA -- and it'd no longer be MIPS32 or SH2 anyway.

I haven't downvoted a single thing in this thread. Other people are doing the downvoting.

That's funny, I don't like much the RISC-V because of the focus on minimalism(1), but the points I dislike are totally different from yours..

1: no trap on integer overflow instructions? Come on:

a) the MIPS (a processor designed for simplicity too) has those!

b) in 21st century, security features should not be optional.

> 32-bit fixed encoding makes the decoder simple, but creates the same load-store problem as on SPARC - hello non-existent, synthetic instructions!

I'm not familiar with this. Could you explain the problem or point me in the right direction for background info?

If you have 32-bits available to encode the instruction and the operand, how do you encode a load of a 32-bit address, or even a 64-bit address?

That's why the SPARC assembler, as(1), accepts a completely made-up, non-existent, synthetic instruction, ld. In reality, what happens is that as(1) assembles this made-up fantasy into two instructions, sethi and or. This is the cold, hard reality of loading a 32-bit value from memory:

  String0:
  .asciz "Counter is %.2d\\n"
  .align 4

  main: sethi %hi(String0), %l0
        or %l0, %lo(String0), %l0

Looking at the RISC-V spec, you probably should be using the AUIPC instruction to address data in your .text, .data or .bss sections. As a bonus, your code becomes position-independent so you can actually use it in shared libraries. To use arbitrary 32-bit and 64-bit pointers known at compile-time (which should be pretty rare), you also have the option of loading them from memory, i.e. using AUIPC to generate a pointer to the value in your .text and then loading it to a register in addition to your approach.

Also, check out chapter 2 of this paper for the technical and licensing motivation to not go with SPARC or several other RISC ISAs: https://people.eecs.berkeley.edu/~krste/papers/EECS-2016-1.p...

Keep in mind, the UltraSPARC T1 and T2 are only two cores suited to specific workloads. They'd still be starting from scratch on the RTL if they wanted to do anything different with the microarchitecture. Now they've (UCB-BAR anyway) got at least one open out-of-order core suited to the higher end, a flexible in-order core for microcontroller up to cellphone operation; not to mention the gaggle of open RISC-V cores from outside UCB-BAR.