Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

MIPS Becomes RISC-V

eejournal.com

Post reply on HN
Print view View original

81–90 of 225 posts

Re: MIPS Becomes RISC-V

#81

Post by Taniwha »

spamizbad wrote: post #75
MaxBarraclough wrote: post #36

Everyone's right to celebrate the success of RISC-V, but part of me thinks it's a shame that there's relatively little architectural diversity ( edit I should have said ISA diversity ) in modern CPUs. MIPS, Alpha, and Super-H, have all but faded away. Power/PowerPC is still out there somewhere though. Apparently they're still working on SPARC, too. [0] At least we'll always have the PS2. ...until the last one breaks,…

I feel like MIPS and RISC-V are so closely related they're not terribly diverse. Academic MIPS evolved into RISC-V.

Nope - they have different competing heritages - in this case the headline is "Berkeley beats Stanford"

https://www.youtube.com/watch?v=09kPcg8Hehg

Re: MIPS Becomes RISC-V

#83

Post by dataangel »

elihu wrote: post #74
MaxBarraclough wrote: post #36

Everyone's right to celebrate the success of RISC-V, but part of me thinks it's a shame that there's relatively little architectural diversity ( edit I should have said ISA diversity ) in modern CPUs. MIPS, Alpha, and Super-H, have all but faded away. Power/PowerPC is still out there somewhere though. Apparently they're still working on SPARC, too. [0] At least we'll always have the PS2. ...until the last one breaks,…

I wish the barriers to using new architectures were lower. For instance, suppose binaries were typically distributed in a platform-agnostic format, like LLVM intermediate representation or something equivalent. When you run your program the first time, it's compiled to native code for your architecture and cached for later use. I realize I've sort of just re-invented Javascript. But what if we just did away with nati…

> For instance, suppose binaries were typically distributed in a platform-agnostic format, like LLVM intermediate representation or something equivalent.

The Mill does something like this, but only for their own chips. "Binaries" are bitcode that's not specialized to any particular Mill CPU, and get run through the "specializer" which knows the real belt width and other properties to make a final CPU-specific version.

Re: MIPS Becomes RISC-V

#84

Post by retrac »

elihu wrote: post #74
MaxBarraclough wrote: post #36

Everyone's right to celebrate the success of RISC-V, but part of me thinks it's a shame that there's relatively little architectural diversity ( edit I should have said ISA diversity ) in modern CPUs. MIPS, Alpha, and Super-H, have all but faded away. Power/PowerPC is still out there somewhere though. Apparently they're still working on SPARC, too. [0] At least we'll always have the PS2. ...until the last one breaks,…

I wish the barriers to using new architectures were lower. For instance, suppose binaries were typically distributed in a platform-agnostic format, like LLVM intermediate representation or something equivalent. When you run your program the first time, it's compiled to native code for your architecture and cached for later use. I realize I've sort of just re-invented Javascript. But what if we just did away with nati…

That's how IBM implemented the AS/400 platform. Everything compiled down to a processor-agnostic bytecode that was the "binary" format. That IR was translated to native code for the underlying processor architecture as the final step. And objects contained both the IR and the native code. If you moved a binary to another host CPU, it would be retranslated and run automatically. The migration to POWER as the underlying processor was almost entirely transparent to the user and programming environment.

https://en.wikipedia.org/wiki/IBM_System_i#Instruction_set

Re: MIPS Becomes RISC-V

#85

Post by msla »

elihu wrote: post #74
MaxBarraclough wrote: post #36

Everyone's right to celebrate the success of RISC-V, but part of me thinks it's a shame that there's relatively little architectural diversity ( edit I should have said ISA diversity ) in modern CPUs. MIPS, Alpha, and Super-H, have all but faded away. Power/PowerPC is still out there somewhere though. Apparently they're still working on SPARC, too. [0] At least we'll always have the PS2. ...until the last one breaks,…

I wish the barriers to using new architectures were lower. For instance, suppose binaries were typically distributed in a platform-agnostic format, like LLVM intermediate representation or something equivalent. When you run your program the first time, it's compiled to native code for your architecture and cached for later use. I realize I've sort of just re-invented Javascript. But what if we just did away with nati…

> For instance, suppose binaries were typically distributed in a platform-agnostic format, like LLVM intermediate representation or something equivalent. When you run your program the first time, it's compiled to native code for your architecture and cached for later use.

IBM's OS/400 (originally for the AS/400 hardware, now branded as System i) did precisely this: Compile COBOL or RPG to a high-level bytecode, which gets compiled to machine code on first run, and save the machine code to disk; thereafter, the machine code is just run, until the bytecode on disk is changed, whereupon it's replaced with newer machine code. IBM was able to transition its customers to a new CPU architecture just by having them move their bytecode (and, possibly, source code) from one machine to another that way.

https://en.wikipedia.org/wiki/IBM_System_i

Other OSes could definitely do it.

Re: MIPS Becomes RISC-V

#86

Post by simias »

zdw wrote: post #76
Fordec wrote: post #59

Earlier quoted context omitted.

We need diversity for solving different problems, not for diversity sake. What problem did MIPS solve in a unique way that others didn't? Because it wasn't desktop, mobile, embedded, graphics or AI.

SPARC is well known to be different enough (big endian, register windowing of the stack, alignment, etc.) that it exposes a lot of bugs in code that would be missed in a little-endian, x86 derived monoculture. https://marc.info/?l=openbsd-bugs&m=152356589400654&w=2

I always found SPARC's stack handling to be very elegant and I write enough of low level code that these architectural details do from time to time impact me, but isn't it largely irrelevant for the industry at large?

After all MIPS's original insight was that machine code was now overwhelmingly written by compilers and not handwritten assembly, so they made an ISA for compilers. I think history proved them absolutely right, actually these days there are often a couple of layers between the code people write and the instructions fed into the CPU.

I guess my point is that nowadays I'm sure that many competent devs don't know what little-endian means and probably wouldn't have any idea of what "register windowing of the stack" is, and they're completely unaffected by these minute low level details.

Making it a bit easier for OpenBSD to find subtle bugs is certainly nice, but that seems like a rather weak argument for the vast amount of work required to support a distinct ISA in a kernel.

Honestly I'm not convinced by the argument for diversity here, as long as the ISA of choice is open source and not patent encumbered or anything like that. Preventing an x86 or ARM monoculture is worth it because you don't want to put all your eggs in Intel or Nvidia's basket, but if anybody is free to do whatever with the ISA I don't really see how that really prevents innovation. It's just a shared framework people can work with.

Who knows, maybe somebody will make a fork of RISC-V with register windows!

Re: MIPS Becomes RISC-V

#87

Post by monocasa »

Taniwha wrote: post #81
spamizbad wrote: post #75

Earlier quoted context omitted.

I feel like MIPS and RISC-V are so closely related they're not terribly diverse. Academic MIPS evolved into RISC-V.

Nope - they have different competing heritages - in this case the headline is "Berkeley beats Stanford" https://www.youtube.com/watch?v=09kPcg8Hehg

Academic RISC was designed by Patterson and Hennessy. Hennessy went off and was one of the founders of MIPS, Patterson is one of the instrumental leaders in the RISC-V space.

Re: MIPS Becomes RISC-V

#88

Post by slezyr »

mortenjorck wrote: post #5

This is more or less analogous to Blackberry moving to Android, isn’t it? Storied, old-guard tech company loses most of its market share, trades in its first-party stack for a rising open-source alternative. Is MIPS still a big enough name to make this much of a coup for RISC-V? Or is this the last-ditch effort of a fallen star of the semi market?

Check your router's CPU. I own 4 routers and all of them use MIPS. RISC-V is more like Graphene, it's yet to leave the lab.

Re: MIPS Becomes RISC-V

#89

Post by monocasa »

tyingq wrote: post #70

The MIPS name was originally was an acronym for "Microprocessor without Interlocked Pipeline Stages". The RISC-V docs that I've skimmed seem to show quite a lot more hardware pipeline interlocking than the last gen MIPS processors. So the name is a bit funny now.

It's a lot harder to have pipeline stages and no interlocks when you don't have delay slots.

Re: MIPS Becomes RISC-V

#90

Post by MaulingMonkey »

elihu wrote: post #74
MaxBarraclough wrote: post #36

Everyone's right to celebrate the success of RISC-V, but part of me thinks it's a shame that there's relatively little architectural diversity ( edit I should have said ISA diversity ) in modern CPUs. MIPS, Alpha, and Super-H, have all but faded away. Power/PowerPC is still out there somewhere though. Apparently they're still working on SPARC, too. [0] At least we'll always have the PS2. ...until the last one breaks,…

I wish the barriers to using new architectures were lower. For instance, suppose binaries were typically distributed in a platform-agnostic format, like LLVM intermediate representation or something equivalent. When you run your program the first time, it's compiled to native code for your architecture and cached for later use. I realize I've sort of just re-invented Javascript. But what if we just did away with nati…

> I realize I've sort of just re-invented Javascript.

Or one of several bytecodes that get JIT or AOT compiled.

WASM in particular has my interest these days, thanks to native browser support and being relatively lean and more friendly towards "native" code, whereas JVM and CLR are fairly heavyweight, and their bytecodes assume you're going to be using a garbage collector (something that e.g. wasmtime manages to avoid.)

Non-web use cases of WASM in practice seem more focused on isolation, sandboxing, and security rather than architecture independence - stuff like "edge computing" - and I haven't read about anyone using it for AOT compilation. But perhaps it has some potential there too?

Post reply on HN