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

211–220 of 225 posts

Re: MIPS Becomes RISC-V

#211

Post by MaxBarraclough »

MaulingMonkey wrote: post #90
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…

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

I think the short answer is that the performance penalty is so significant that it doesn't make sense to use WASM unless you're running untrusted code.

Re: MIPS Becomes RISC-V

#212

Post by MaxBarraclough »

karteum wrote: post #209
MaxBarraclough wrote: post #98

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

> "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.)" Maybe, but PNaCl (unfortunately deprecated by Google) "defines a low-level stable portable intermediate representation (based on the IR used by the…

Sure. I'm not saying it's impossible to construct such an IR and get it to work, I'm saying I doubt it's the best way forward. See my other comment [0] where I mention Google Native Client.

It would be a poor fit for certain languages, there may be performance penalties depending on target platform, it would preclude legitimate platform-specific code such as SIMD assembly, it would preclude platform-specific build-time customization, etc.

The way toward painless portability is to move away from unsafe languages like C and C++, where you're never more than an expression away from undefined behaviour, and where programmers may be tempted to make silly mistakes like writing code sensitive to the endianness of the target architecture. [1] With C and C++, disciplined developers working carefully, can write portable code. With Safe Rust, code can be pretty close to 'portable by construction', like Java. If you feed Windows-style path strings to Linux, or vice versa, then things might go wrong, but for the most part you'll be on solid ground.

[0] https://news.ycombinator.com/item?id=26398199

[1] https://commandcenter.blogspot.com/2012/04/byte-order-fallac...

Re: MIPS Becomes RISC-V

#214

Post by segfaultbuserr »

brucehoult wrote: post #204
segfaultbuserr wrote: post #152

Earlier quoted context omitted.

> In 2010 MIPS wanted $2 million from Berkeley to allow them to use the MIPS instruction encodings Do you have a source for that? I see that you're a RISC-V expert, and I know MIPS, Inc. is notorious for patent lawsuits, so I trust you. I'm just curious about the Berkeley project.

Krste (or maybe Dave?) said so in a video somewhere not that long ago -- I assume in the RISC-V International channel on youtube but I don't recall which one.

Thanks.

Re: MIPS Becomes RISC-V

#216

Post by dsand »

pabs3 wrote: post #167

There are a couple of vendors of multi-architecture CPUs where the native architecture is MIPSish and the other supported arches are MIPS, ARM, RISC-V & x86. Tachyum is one of them, here is another: https://www.zhihu.com/question/414069789

That is a very interesting article. For how they aim to run existing software by binary translations to an ISA optimized for such binary translations. And how much they dread possibly being cut off from foreign foundries and ARM and x86 chips.

Re: MIPS Becomes RISC-V

#217

Post by Wowfunhappy »

saagarjha wrote: post #96
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…

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

(Which is deprecated now, and scheduled for removal.)

Re: MIPS Becomes RISC-V

#218

Post by thr0w__4w4y »

brucehoult wrote: post #134
musicale wrote: post #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…

There is no, one, MIPS ISA. They've been through a number of incompatible changes over the years. MIPS r6 added some things more like RISC-V. NanoMIPS loops even more like RISC-V, though with its own twist (and with some 48 bit instructions, which RISC-V doesn't have yet). In many ways modern MIPS and RISC-V are pretty much just different binary encodings of the same ideas. In 2010 MIPS wanted $2 million from Berkele…

Excellent point. MIPS overplayed its hand.

It's funny how this story repeats itself over and over again, yet companies never seem to learn.

The flipside of this is when companies like Apple, Microsoft and Adobe, like it or not, become part of the de facto tech learning arc for college students, who one day grow up to be senior engineers, lead engineers, architects and principal engineers.

Re: MIPS Becomes RISC-V

#219

Post by thr0w__4w4y »

I consulted with MIPS and ARM many years ago - pre Y2K (background is microprocessor design and firmware). ARM was a little formal but easy to work with, cooperative and supportive (they opened doors and provided everything I asked for). Working with MIPS was a nightmare, every step of the way. Weren't responsive, difficult to work with, engineers were stubborn, etc.

I realize these are generalizations and I'm a sample size of one. But I was plugged in at a pretty high technical level with both companies, and I remember telling my wife at the time that I thought ARM would skyrocket and MIPS would be unable to get out of its own way.

Glad I bought a lot of ARM stock before most people knew about them.

Re: MIPS Becomes RISC-V

#220

Post by dingosity »

meh. there's more to a CPU architecture than its instruction set. this isn't the "death of MIPS." far from it, it's the remaining MIPS people applying their own understanding of design to implement a CPU with the RV64 instruction set (plus extensions, presumably.)

that being said... MIPS is certainly smaller than it once was. i hope there are still people around who remember how to build CPUs.

Post reply on HN