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

71–80 of 225 posts

Re: MIPS Becomes RISC-V

#71

Post by scj »

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?

It likely forces an inflection point for existing MIPS users:

1. Stick with MIPS for as long as possible.

2. Follow MIPS into RISC-V.

3. Or go to some other camp.

Re: MIPS Becomes RISC-V

#72

Post by dfox »

projektfu wrote: post #52
rst wrote: post #22

Earlier quoted context omitted.

Depends where you look. Hard to see IBM's z/Architecture dying out in that timeframe (the latest branding for S/360-derived mainframes), for example, and the embedded space is likely to remain an odd bestiary for quite some time.

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 when you look at the execution units and overall system design, but the ISA is completely different and even the performance profile of the mostly similar CPU is different (z/Architecture is "uber-CISC" with instructions like "calculate sha256 of this megabyte of memory").

Re: MIPS Becomes RISC-V

#74

Post by elihu »

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 native binaries entirely, except as ephemeral objects that get cached and then thrown away and regenerated when needed? It seems like this would solve a lot of problems. You could deprecate CPU instructions without worrying about breaking backwards compatibility. If a particular instruction has security or data integrity issues, just patch the compiler not to emit that instruction. As new side-channel speculation vulnerabilities are discovered, we can add compiler workarounds whenever possible. If you're a CPU architect and want to add a new instruction for a particular weird use-case, you just have to add it to your design and patch the compiler, and everyone can start using your new instruction right away, even on old software. You'd be able to trust that your old software would at least be compatible with future instruction architectures. Processors would be able to compete directly with each other without regard to vendor-lock-in.

Re: MIPS Becomes RISC-V

#75

Post by spamizbad »

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.

Re: MIPS Becomes RISC-V

#76

Post by zdw »

Fordec wrote: post #59
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,…

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

Re: MIPS Becomes RISC-V

#77

Post by jnwatson »

yjftsjthsd-h wrote: post #62
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.

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.

PowerPC was the dominant processor in telecom equipment as far as I was aware. Perhaps the low end went MIPS.

Re: MIPS Becomes RISC-V

#78

Post by dragontamer »

sujayakar wrote: post #56
dragontamer wrote: post #19

Earlier quoted context omitted.

Are you sure about that? The original SIMD-papers in the 1980s show how to compile a Regex into a highly-parallel state machine and then "reduced" (aka: Scan / Prefix-operation: https://en.wikipedia.org/wiki/Prefix_sum ). A huge amount of operations, such as XML-whitespace removal (aka: SIMD Steam Compacting), Regular Expressions, and more, have been proven ~30 to 40 years ago to benefit from SIMD compute. Yet such l…

I'm very interested in this space! I've been hacking on some open-source libraries around these ideas: rsdict [1], a SIMD-accelerated rank/select bitmap data structure, and arbolito [2], a SIMD-accelerated tiny trie. For rsdict, the main idea is to use `pshufb` to implement querying a lookup table on a vector of integers and then use `psadbw` to horizontally sum the vector. The arbolito code is a lot less fleshed out…

Cool stuff! I'll give it a lookover later.

A few years ago, I wrote AESRAND (https://github.com/dragontamer/AESRand). I managed to get some well-known programmers to look into it, and their advice helped me write some pretty neat SIMD-tricks. EX: I SIMD-implemented a 32-bit integer -> floating point [0.0, 1.0] operator, to convert the bitstream into floats. As well as integer-based nearly bias-free division / modulus free conversion into [0, WhateverInt] (such as D20 rolls). For 16-bit, 32-bit, and 64-bit integers (with less bias the more bits you supplied).

Unfortunately, I ran out of time and some work-related stuff came up. So I never really finished the experiments.

----------

My current home project is bump-allocator + semi-space garbage collection in SIMD for GPUs. As far as I can tell, both bump-allocation and semi-space garbage collection are easily SIMDified in an obvious manner. And since cudamalloc is fully synchronous, I wanted a more scalable, parallel solution to the GPU memory allocation problem.

Re: MIPS Becomes RISC-V

#79

Post by Ericson2314 »

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…

Come to Nix and Nixpkgs, where we can cross compile most things in myriad ways. I think the barriers to new hardware ISAs on the software side have never been lower.

Even if we get an ARM RISC-V monoculture, at least we are getting diverse co-processors again, which present the same portability challenges/opportunities in a different guise.

Re: MIPS Becomes RISC-V

#80

Post by trulyme »

rwmj wrote: post #33
zokier wrote: post #20

The progression of headlines is funny: 1) MIPS Strikes Back: 64-bit Warrior I6400 Arrives https://news.ycombinator.com/item?id=8258092 We are still in the game 2) Linux-running MIPS CPU available for free to universities – full Verilog code https://news.ycombinator.com/item?id=9444567 Okay, we are not doing so great, maybe we can get young kids hooked? 3) MIPS Goes Open Source https://news.ycombinator.com/item?id=187…

I have one of the purple MIPS SBCs from back when MIPS was briefly owned by Imagination ( https://en.wikipedia.org/wiki/Imagination_Creator https://elinux.org/MIPS_Creator_CI20 ). Slow as hell even back in 2014. I wonder if one day it'll be a museum piece :-?

Is it something special? If no, then no.
Post reply on HN