Live data from Hacker News

MIPS Becomes RISC-V

eejournal.com

91–100 of 225 posts

Re: MIPS Becomes RISC-V

#91
There's a lot to like about MIPS. It's a perfectly usable RISC architecture that:

- is easy to implement

- is supported by Debian, gcc, etc..

- is virtualizable

- scales from embedded systems (e.g. compressed MIPS16 ISA) up to huge shared-memory multiprocessor systems with hundreds of CPUs

Like RISC-V, MIPS traces its lineage to the dawn of the RISC revolution in the 1980s, though on the Hennessy/Stanford side rather than the Patterson/Berkeley side.

And it was supposed to go open source: https://www.mips.com/mipsopen/

but that effort sadly seems to be dead: http://mipsopen.com

That's really too bad. MIPS doesn't deserve to die.

Fortunately as mentioned above it will live on as long as there are PS2 consoles or emulators around.

Re: MIPS Becomes RISC-V

#92
post #67
post #24

Earlier quoted context omitted.

> Atmel Microchip these days, Atmel got acquired few years back.. The packaging looks cool of those https://www.microchip.com/wwwproducts/en/AT697F

That's how it's packaged prior to trimming and lead forming, which looks like this: https://www.youtube.com/watch?v=4CfEN5R13w4

[deleted]

Re: MIPS Becomes RISC-V

#93
post #72

Earlier quoted context omitted.

Isn't z/Architecture just emulated on top of POWER? That's been my impression for a while.

You probably mean "TIMI" which is the user-visible ISA of IBM's "midrange" systems (ie. AS/400 or System/i) which was from the start meant as virtual machine ISA that is then mostly AOT transpiled into whatever hardware ISA OS/400 or i5/OS runs on. z/Architecture (S/360, ESA/390, what have you...) is distinct from that and distinct from PowerPC. Modern POWER and z/Architecture CPUs and machines are somewhat similar w…

No, they're probably talking about how modern z/Arch and POWER cores share a lot of HDL source these days.

Re: MIPS Becomes RISC-V

#94
post #59

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,…

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.

MIPS and Berkeley RISC started an entire revolution. They appear "not unique" only because other ISAs copied them so thoroughly. I think it's safe to say that Alpha, ARM, POWER, PA-RISC, etc wouldn't have been designed as they were without MIPS.

Even today, comparing modern MIPS64 and ARM aarch64, I find ARM's new ISA to be perhaps more similar to MIPS than to ARMv7.

Re: MIPS Becomes RISC-V

#95
post #74

Earlier quoted context omitted.

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…

"does" is not exactly the right word here. "Proposes to do"?

Re: MIPS Becomes RISC-V

#96
post #74

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…

This sounds a bit like Google’s Portable Native Client.

Re: MIPS Becomes RISC-V

#97
post #66
post #61

Earlier quoted context omitted.

MIPS was a nice simple ISA for CE students to learn and implement. Both ARM and RISC-V have gotchas that make them more complicated. I suppose it will live on in that form, especially if the IP is opened up.

I remember CS 61C at Berkeley used to use MIPS to teach assembly language programming and a bit about computer architecture, using the original MIPS version of Patterson and Hennessy's Computer Organization and Design . Now that book is available in both MIPS and RISC-V versions, with, I've assumed, much more effort going into the RISC-V version... I do think the simplicity of MIPS was a big plus there, including sim…

Not entirely related, but I found MARS (http://courses.missouristate.edu/KenVollmar/MARS/) to be much nicer to use than SPIM.

More on topic, though, RISC-V seems to really be designed in a way that makes it easy to teach. This is partially why I have doubts that it can be made very performant, but the focus of a prettier design over a more practical one is probably going to help it be more accessible to students.

Re: MIPS Becomes RISC-V

#98
post #74

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 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.

We're doing a pretty good job on portability these days already. Well-written Unix applications in C/C++ will compile happily for any old ISA and run just the same. Safe high-level languages like JavaScript, Java, and Safe Rust are pretty much ISA-independent by definition, it's 'just' a matter of getting the compilers and runtimes ported across.

Adopting LLVM IR for portable distribution, probably isn't the way forward. I don't see that it adds much compared to compiling from source, and it's not what it's intended for. (LLVM may wish to change the representation in a subsequent major version, for instance.)

For programs which are architecture-sensitive by nature, such as certain parts of kernels, there are no shortcuts. Or, rather, I'm confident the major OSs already use all the practical shortcuts they can think up.

> When you run your program the first time, it's compiled to native code for your architecture and cached for later use.

Source-based package management systems already give us something a lot like this.

There are operating systems that take this approach, such as Inferno. [0] I like this HN comment on Inferno [1]: kernels are the wrong place for 'grand abstractions' of this sort.

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

Don't be too harsh on yourself, JavaScript would be a terrible choice as a universal IR!

> [[ to the bulk of your second paragraph ]]

In the Free and Open Source world, we're already free to recompile the whole universe. The major distros do so as compiler technology improves.

> Processors would be able to compete directly with each other without regard to vendor-lock-in.

For most application-level code, we're already there. For example, your Java code will most likely run just as happily on one of Amazon's AArch64 instances as on an AMD64 machine. In the unlikely case you encounter a bug, well, that's pretty much always a risk, no matter which abstractions we use.

[0] https://en.wikipedia.org/wiki/Inferno_(operating_system)

[1] https://news.ycombinator.com/item?id=9807777

Re: MIPS Becomes RISC-V

#99

Earlier quoted context omitted.

Throwing out diversity because you don't see any immediate benefit is a great way to not have it when a different problem does show up. I don't know about unique way, but MIPS certainly was good at embedded; there's plenty of networking gear using it.

> MIPS certainly was good at embedded As far as I understand, it's not that MIPS is the best at embedded, it's just that it's cheaper to sell as the license cost is non-existing and good support already exists in kernels and so on.

What are the criteria for 'best'?

If MIPS offered adequate performance and features, good performance-per-watt, and a competitive licence fee, and if none of its competitors could beat it, doesn't that count as 'best'?

Re: MIPS Becomes RISC-V

#100
post #17

"Development of the MIPS processor architecture has now stopped" Is anyone still developing SPARC?

Fujitsu for general purpose servers, and Atmel (maybe others too?) for rad-hardened Sparc.

Given that Fujitsu has jumped ship to ARM for their supercomputers I wonder if they'll be doing so with their other hardware as well?
Post reply on HN