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

141–150 of 225 posts

Re: MIPS Becomes RISC-V

#141

Post by projektfu »

monocasa wrote: post #93
dfox wrote: post #72

Earlier quoted context omitted.

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.

Yeah, I figured that most of the previously microcoded CISC instructions were basically software at this point.

Re: MIPS Becomes RISC-V

#142

Post by bigbillheck »

slezyr wrote: post #88
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.

Tell it to Digikey: https://www.digikey.com/en/products/detail/seeed-technology-...

(I've got a single board computer from those people that I got in, I think, 2019)

Re: MIPS Becomes RISC-V

#143

Post by inkyoto »

retrac wrote: post #84
elihu wrote: 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…

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

App uploads to the iOS store in the LLVM's own Bitcode format is a distant echo of the CPU ISA agnostic IR approach IBM employed at the time. Bitcode is transpiled down to the underlying CPU instructions via the static binary translation and optimisation, and the translation between Bitcode -> x86 or Bitcode -> ARM has been possible to do for some time: https://www.highcaffeinecontent.com/blog/20190518-Translatin...

Rosetta 2 AOT, whilst not being exactly the same thing as the ISA agnostic IR solution, is another example of the static binary translation. Theoretically, Apple could start requiring OS X app submissions to the app store in the Bitcode format as well, so they could be transpiled and optimised at the app download time and perform efficiently on M3, M4, M5 etc CPU's in the future. However, with their habit of obsoleting certain things fast, it is not clear whether they will choose to go down the Bitcode path for the OS X apps.

Re: MIPS Becomes RISC-V

#144

Post by phendrenad2 »

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

There isn't much diversity in software, why hardware? Maybe standardization is a strength.

Re: MIPS Becomes RISC-V

#145

Post by phab »

I spent a summer interning with MIPS hardware when they were owned by Imagination. It's kinda odd to see something you helped make die (be killed?) like this.

Strong "not with a bang but a whimper" vibes in my office today.

Re: MIPS Becomes RISC-V

#146

Post by dragontamer »

gnufx wrote: post #108
dragontamer wrote: post #9

Earlier quoted context omitted.

The big innovation in architectures is in the SIMD world. AVX512 (x86 512-bit), SVE (ARM 512-bit), NVidia PTX / SASS (32x32-bit), AMD RDNA (32x32-bit), AMD CDNA (64x32-bit). 64-bit cores (aka: classic CPUs) are looking like a solved problem, and are becoming a commodity. SIMD compute however, remains an open question. NVidia probably leads today, but there seems to be plenty of room for smaller players. Heck, one maj…

The V in SVE is for vector, the S isn't for SIMD, and it's length-agnostic; I don't know how similar it is to the RISC-V vector extension. Think CDC, Cray, NEC, not AMD/Intel. I guess the recent innovation in that space is actual matrix multiplication instructions in CPUs.

Some GPU assembly advancements...

* Bpermute and permute. (Pshufb is like permute, a gather operation. Bpermute is the opposite, like a scatter. Bpermute Doesn't exist on x86 yet)

* __shared__ memory crossbar: every simd unit can read, or write, to shared memory in parallel per clocktick. The crossbar can also broadcast 1-to-all each clocktick.

* Butterfly permute: the fundamental pattern in permutations for a variety of operations. Most noticably for scan, and FFTs. Butterfly networks are closely related to pext and pdep implementation (showing how common that particular permute is).

* 8+ way hyperthreads / SMT. GPUs have very bad latency, but very high SMT counteracts that problem well in practice.

* PCIe Atomics: perform those compare and swap negotiations over I/O, allowing tight CPU and GPU memory integration.

* Crazy RAM. 1000GBps on HBM2. 800GBps over GDDR6x thanks to 2-bits transferred per clock ticks.

* Crazy networks. AMD Infinity fabric pushes over 100GB. NVlink is 600GBps. A GPU network link has more bandwidth than a typical CPU's DDR4 RAM bandwidth.

* NVidia SASS has the craziest instruction set, the compiler figures out read / write hazards and publishes them in the SASS assembly itself. NVidias ISA decoder + assembler team is doing something crazy here, the likes I haven't seen in any other instruction set ever.

* "Ballot" instructions. Its... really hard to explain why these are useful. They just are, lol.

Just a few cool concepts I've seen in the GPU world recently. Sure, matrix multiplications get the headlines because of tensors / deep learning. But don't sleep on the obscure stuff.

Re: MIPS Becomes RISC-V

#147

Post by notacoward »

A few jobs ago, the company I worked for based their own custom processor on a MIPS core. Why MIPS? The answer I got when I asked was that it was the only affordable option. ARM in particular was called out as beyond reach financially. Years later, long after that company was gone, RISC-V came in at an even lower price point. AFAICT there's no need to look for other reasons behind this news.

Re: MIPS Becomes RISC-V

#148

Post by tachyonbeam »

TorKlingberg wrote: post #122
hamburglar wrote: post #113

Earlier quoted context omitted.

- the NOP instruction is 0x0 :)

I don't know if MIPS is the same, but I worked on an other architecture where NOP is 0x0, and it had an interesting effect. If you called an uninitialized function pointer, and it happened to point into zero:ed out memory, the CPU would execute NOPs for a good while until it hit something else. If that something else was code, it would start executing some function from the start, but with garbage arguments. It would…

Seems like a better design choice would be to have instruction 0x0 throw some kind of page fault violation or other exception the OS can catch then.

Re: MIPS Becomes RISC-V

#149

Post by lmm »

dragontamer wrote: post #19
londons_explore wrote: post #14

Earlier quoted context omitted.

SIMD today is only really helpful with a few usecases. If you want to encode some video, decode some jpegs, or do a physics simulation quicker, it's really going to help. It won't boot Linux any quicker tho. I suspect for consumer uses, SIMD is already used for nearly all the use cases it can be.

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…

> 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 libraries don't exist today yet.

That's exactly why I don't believe it's ever going to happen. If these things could actually be useful in practice, surely someone would have done it already.

Re: MIPS Becomes RISC-V

#150

Post by bogomipz »

retrac wrote: post #84
elihu wrote: 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…

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

This is really fascinating. Is there a reason why we haven't seen more of this approach as it seems like it was pretty successful for IBM. Is there a practical reason that would prevent an open source project from building something similar?
Post reply on HN