1. 43
  1.  

  2. 3

    Most of these arguments are either incorrect or taste-based. And coming from a competing group it’s not surprising that a lot of it’s negative.

    RISC-V has extensive academic study and backup. It’s not just a flash in the pan. It’s a well designed, extensively studied architecture. While no architecture is perfect it’s probably the most carefully academically considered architecture of all time.

    1. 16

      extensive academic study and backup

      After having dealt with Scala, this claim has pretty much lost all its meaning to me.

      Is there any evidence that they are actually looking at the facts and prior art?

      1. 2

        A quick search shows hundreds of publications related to RISC-V:

        https://scholar.google.com/scholar?hl=en&as_sdt=0%2C5&q=risc-v&btnG=

      2. 11

        RISC-V has extensive academic study and backup. It’s not just a flash in the pan. It’s a well designed, extensively studied architecture. While no architecture is perfect it’s probably the most carefully academically considered architecture of all time.

        Could you give some examples? I don’t design hardware in any capacity, and most of my direct experience writing assembler is with older CPUs (e.g. 680x0 or classic MIPS and ARM), so I can’t judge a lot of the opcode comments. But…the complaints I do understand seem entirely legitimate to me. x86 has a lot of flaws, but honestly has a very good atomics story, and I remember other CPUs (such as PowerPC) being comparatively worse. The minimalism bit it opens up with directly speaks to me; I remember how ARM was a lot more pleasant than MIPS specifically because MIPS was overly minimalistic, so it’d take a surprising number of instructions to get stuff done.

        I’m not saying the author isn’t biased, or even that he’s right, but the parts I understand don’t seem incorrect or taste-based

        1. 1

          This guy picks off a few of the more obvious points:

          https://www.reddit.com/r/programming/comments/cixatj/_/ev9z9fp

        2. 9

          RISC-V has extensive academic study and backup

          To rephrase this a bit: RISC-V provides plenty of canvas on which lots of postdocs can paint their careers. Doesn’t mean it’s practically sound.

          Funnily, some of the decisions I despise the most about RISC-V (its introduction of the machine and hypervisor modes) are all about imitating (some of the worse aspects of) x86 (that is, “practical” decisions).

          1. 1

            The hypervisor mode of x86 is a complete mess - which perhaps accounts for its popularity.

        3. 2

          I was under the impression that the presence of precise timecounters doesn’t make a difference for the sidechannel vulnerability folks. Is that not the case?

          x86 can also hide rdtsc from userland but that was an argument against doing so.

          1. 6

            A precise global counter is a great way to measure your CPU time slice (look for the jumps), which is a useful proxy for other processes’ activity on the system.

            If the counter merely measures process local ticks, it would only be useful for latency measurements, for example cache timing side channels (do a memory op, check how long it takes).

            If your timer is local and has 1ms granularity, it gets harder while not really affecting the timer’s usefulness for “regular” tasks.

            1. 5

              A timing channel communicates information by modulating the timing of an observable event. That’s usually how long something takes. I’ll give a simple example. If it’s quick, maybe that’s a 0. If it’s a slowdown, it’s a 1. The observation needs a timer precise enough for whatever mapping they’re doing of timing to information. That’s why low-precision timers and counters were the earliest attempt at solving that problem. Each app or subject only got as much accuracy as it truly needed.

              1. 2

                Maybe we can just make Shrodinger’s Timer, and have it become less accurate the more often you call it? :D

              2. 2

                Just based on trends – Moore’s law and Spectre/Meltdown – my impression is the same: RISC-V is designed for simplicity, not modernity.

                What I expect from a “trendy” ISA:

                • Instruction level parallelism: SIMD, VLIW or a combo should be the way it works. Who even needs scalar instructions anymore, except for branching.
                • A minimum of conditional instructions: Branching is now bad both for instruction level parallelizability (above point) and for relying on branch prediction for performance, which is the new security liability.

                These points go hand in hand, and RISC-V is doing none of it.

                1. 5

                  Instruction level parallelism: SIMD, VLIW or a combo should be the way it works. Who even needs scalar instructions anymore, except for branching.

                  Eh, I don’t really feel like we’ve solved any of the compiler issues that caused this to fail the last time around with MAJC, Itanium, or even things like the i860. What I could see would be Erlang-style concurrency on a highly multicore CPU, such that most programs could run linearly on their own core, but that’d require a heavy-enough redo of how operating systems work that I don’t think that’ll actually happen, either. (This isn’t a particularly novel idea; it was covered years ago in The Future of Programming, where it in turn was pointing out an idea that had been new several decades earlier.)

                  Branching is now a bad thing, and branch prediction a security liability. Conditional instructions to the rescue.

                  We still need branches; they’re not going anywhere. Yeah, you can write branchless/low-branch code in some cases, such as graphics pipelines, but normal code can’t get away without them. And at that point, you’re going to want branch predictors. Maybe slower, more careful ones, but you’re still going to want them. And the second you do that, you don’t want conditional instructions: ARM originally worked that way, and it was awful for performance, because they get in the way of having good branch prediction.

                  1. 2

                    Let’s say “a minimum” of conditional instructions. We don’t need to predicate all instructions to get branchless in most cases of course. Aarch64 has a conditional select, and GCC is very good at using it.

                    I’m not convinced about always wanting a branch predictor, such as on mobile. The 4-core Cortex A53 in most people’s pockets is an in-order CPU that is somehow Spectre immune. It actually has a little branch predictor, but only uses it for some things, if I understand it right.

                    1. 1

                      Eh, I don’t really feel like we’ve solved any of the compiler issues that caused this to fail the last time around with MAJC, Itanium, or even things like the i860.

                      Do you know where I can find some sources to learn more about this? All I’ve been able to find about Itanium compiler internals is “it’s hard”, with Knuth saying “basically impossible” in an interview and someone somewhere mentioning the algorithm for instruction selection for bundles was O(n^2). To me the instruction selection and bundling looks like an optimization problem of the mathematical type, which is certainly stupidly hard to solve perfectly but there’s probably pretty good techniques out there for solving it “well enough”. There’s certainly intractable problems in the world, but it seems like we should have learned at least something useful in the last 20 years.

                      My bigger concern is VLIW is that it often seems to expose details about the innards of the CPU like number of pipelines of different decoder pipelines of different types… which then becomes part of the API of using the computer, even when the hardware changes to no longer reflect this.

                      (Yes, everything I learned about CPU design I learned from reading Raymond Chen’s articles.)

                      1. 2

                        VLIW instruction selection is now a solved problem. LLVM’s documentation on VLIW code generator explains how it is done.

                        1. 1

                          Oh, hot. Thank you!

                    2. 3

                      I gotta agree with gecko: VLIW is a very cool idea that seems to not work. I am undecided on SIMD, although, in practice it’s hugely ugly. https://www.sigarch.org/simd-instructions-considered-harmful/

                      x86/arm spectre/meltdown is just bad engineering. The fundamental constraint is pretty simple: errors in v to p translation should prevent any access.

                    3. 1

                      It’s interesting that it includes “…though I will also say that if I was building a 32 or 64-bit CPU today I’d likely implement the architecture to benefit from the existing tooling.”

                      Usability trumps design yet again, I suppose!