Can MIPS Leapfrog RISC-V? | Hacker News Reader

Can MIPS Leapfrog RISC-V?

eetimes.com

84 pointsCieplak78 comments

I don't think it will. This is clearly a totally reactionary move of a company that has been absolutely trounced in the commercial market by ARM and saw the writing on the wall that once RISC-V established itself the few gaps they lived in would be eventually replaced.

This, 'throw it over the wall' style open sourcing has worked before, Docker being an example.

The problem is their current 'open' strategy is probably not open and dynamic enough to compete with RISC-V. And the consumers that don't care still don't have much reason to use it over ARM.

Maybe they can find a gap but I don't think they have a long term growth curve.

Genuine question related to riscv: what is the value of a standard when a majority of it is part of optional extensions? Doesn't that make riscv a ton of distinct standards, marketed as one?

RV32I is nothing close to RV64IMAFDQCPBS. It seems like all the fragmentation standards are made to avoid packaged up as a "standard" to make sure everything under the sun can use risc-v.

(see also usb-c)

They're designed to cover a lot of different processor types. Servers have different needs to microcontrollers. Nevertheless you would expect code that works on the microcontroller, to scale up and work on the server so there is some value.

You probably don't need to same code to run on such differing hardware though. The value is in your code working on 2 processors with optional FPUs.

I don't think you're ever going to get to USB levels of plug and play, but you don't really need that.

Edit: So yes you might get usb 3/c/whatever levels of confusion, but you don't swap processors multiple times a day so not really a problem.

Many of the optional extensions are either trivial to implement (think multiplier/divider) with minimal logic or are almost considered standard by now (e.g. compressed, because code size is critical for embedded CPUs)

For now, the vast majority of RV CPUs will go into embedded CPUs, where an extension is a compile switch away.

In practice, I think all embedded CPUs will be RV32IMAC.

For bigger CPUs, it's pretty simply: almost all them will be RV64GC.

ISA fragmentation is nothing new: x86 and ARM don't seem to have a problem with them, and one could easily argue that those are way more fragmented than RV right now.

>RV32IMAC

Or RV32IMAC+some extension that makes sense for the application.

There's also a non-defined but planned RV32E for embedded.

>RV64GC

I suspect this will be the case at first, then a superset will take over.

e.g. bitfield operations extension and vector extension are unlikely not to be taken advantage of by e.g. Debian. Likely resulting in a few arch variants with increasingly more such extensions, such as further adding DSP and JIT extensions.

It should be a bit messy at first, and calm down later when there's a lot of frozen extensions that handle most popular tasks.

If anything, I fear calling the 'G' subset was premature. That we're already talking about RV64GC and not just RV64G does strongly point to that.

When you deal with complex telecom chips on 28nm and smaller on a daily basis, it's hard to imagine that a resource savings of just 512 FFs (the difference between RV32E and RV32I) is worth the trouble!

IS fragmentation is a red herring. We already have it, it somewhat of a nuisance, but RV doesn't make it worse.

> Can MIPS Leapfrog RISC-V?

Not if the company will continue being run by the legal department. From industry insiders, I heard people having exchanges with them like "you are gonna fail, thus we are not gonna be working with you..."

https://news.ycombinator.com/item?id=18701898

How much does open-source hardware really matter? It sounds really cool, and i hope it takes off. But is this really where the industry is going, or is this a flash in the pan that gets a lot of attention from people like us?

Quite a bit! Look at all the places Linux ended up. Servers, phones, embedded systems, etc. The freedom to modify and tinker encourages innovation. The cost encourages cheap experimentation.

The difference is that most of us don't own million-dollar fabrication labs. At best, we would be tinkering with FPGAs with custom cores, but FPGAs are an order-of-magnitude slower than traditional CPU ASICs.

So we the typical user can't make use of open source designs.

------

An open source "conglomerate" of companies may work. But I haven't fully thought about the economics of it.

Linux is funded by billion dollar companies (https://www.linuxfoundation.org/membership/members/), and it is put into phones & cloud servers by billion dollar companies.

How many of those billion dollar companies own a fab?

Realistically, only Samsung, Intel, and TSMC can make next-generation chips. (Global Foundries just quit the 7nm race. They're going to be stuck at 12nm). Intel is fully proprietary tech, so that leaves Samsung and TSMC as the only companies that make chips for other companies.

At the end of the day, an open-source chip isn't really much benefit when there are only two manufacturers of chips.

Intel actually does do contract fab work - they just happen to be really bad at it so they don't get much business.

But there is a long tail of chip-making at older nodes to reduce cost, and for analogue integration. Risc-V is getting its start here. I hope we'll see a practical desktop version at some point, but that's not necessary for Risc-V to win.

TSMC is fab-only.

It does not compete with its clients who produce chips.

Thus anyone with a contract with TSMC can be a chip producer.

I think the open source hardware has more appeal in that end-users can "audit" their hardware... I'm not sure how true it is, but that's the idea...

Maybe a bit like the OpenPOWER project?

Yeah, but its a bad example. Because OpenPOWER doesn't need an open-source chip to function. POWER9 is still owned and controlled by IBM.

OpenPOWER is basically a set of documents and specifications that is analogous to IBM's original "PC" specification. This is good for sure, but it doesn't mean that POWER9 is open source like RISC-V is.

If anything, I think OpenPOWER is a good example of why an open-source chip is unnecessary. It shows that a group of companies can work together and build a major platform without the need of open sourcing the chip. I'm unsure what RISC-V gains above and beyond the OpenPOWER consortium.

quite a bit of open source software is maintained and consumed by megacorps nowadays - like, OSS really does become a way for conglomerates of companies to share tech (when the alternative is monopoly-supplied monocultures, it makes a lot of sense). The hardware world seems analogous to what the software world was like in the 90s - a small number of proprietary platforms.

This is where part of the industry is going. There’s a high demand for cores with low licensing costs. Think of how many cores you have in your cell phone or laptop… dozens? Hundreds? (Honestly I have no idea.) The CPU and GPU are just a small part of it. A company that makes baseband processors, SSDs/HDDs, GPUs, network equipment, etc. needs a bunch of cores. The cores aren’t big or powerful, they don’t need to be. RISC-V means those cores have zero licensing costs for the ISA, and you get good toolchain support.

Yep. It's huge for large manufacturers, who get to save a bunch on licensing fees, and cut bom costs.

For one it would be really nice to be able to have a computer without a highly insecure and backdoorable management engine inside its CPU, basically all x86 computers sold since 2010.

How would you know that other than the assurances of the company that designed the chip? They could easily insert a few gates in the layout to subvert protections under the right conditions.

With intel/AMD you have an assurance that your chip does contain a backdoor. I know this is probably difficult to do, but if we have access to published architecture specs/layouts, it might be easier to audit the chip design, even if doing so requires an x-ray microscope.

> it might be

This is the crux of the matter. While your statements are perfectly correct, their implications aren't. The assumption with open source is always that it's easily auditable and anyone can see the source (code, floorplan, etc.) which somehow implies the finished binary or chip that you have received is "safe". And herein lies the problem:

1) Assuming the source is really clean there's no guarantee the end product is;

2) Even if the source appears to be clean you have no guarantee it was actually (thoroughly) checked because "someone else" always checks.

The best example I can give you is OpenSSL, a library used by most of the internet and hundreds of billion+ $ companies (and hundreds of thousands of million+ $ ones). It took 2 years for anyone to notice it. And there are far more qualified SW engineers around that could have spotted the bug than there are HW engineers capable of finding the equivalent backdoor in a complex piece of silicon. So I am very skeptical that someone would notice one if one was there.

> ...but if we have access to published architecture specs/layouts, it might be easier to audit the chip design...

there are no "architecture specs/layouts" provided by RISC-V. it's an ISA. companies making RISC-V chips can put whatever they want in them, and don't have to document any of it.

True, but that's a lot better than your CPU running a non-stop Java webserver / rootkit.

When you know you have a backdoor you may take some steps, small as they may be, to protect yourself. For example in some cases you can remove the ME blob from the BIOS, effectively disabling the ME. You can choose to drop the product entirely. You definitely can't protect yourself from something you don't know exists.

Considering nation state actors have been consistently backdooring everything they can get their hands on (network equipment, CPUs, software, storage devices, you name it - and they've done it without the manufacturer ever knowing sometimes) the assumption that such an open source project would not have it and it's "a lot better" is based purely on wishful thinking.

Same could be said for MIPS or RISC-V or indeed any piece of silicon.

As an embedded designer I know for a fact that CPUs used in embedded systems get so much scrutiny on their I/O messages all the way up the stack, it would be real good subversion to hide something like this and not be discovered in all use case scenarios. More likely is some sort of back door when you can access the hardware. Disclaimer I only work on the smallest MIPS and ARM embedded chips not those with full MMU's

I think there are a lot of reasons RISC-V matters beyond just being open source. Working with MIPS tool chains is positively ghoulish, but they fill a niche.

If another architecture that is reasonably well designed, with reasonable core licensing fees, and had even decent tooling came out I think even that would have broken MIPS's back.

RISC-V hits the mark on all of those by either being open source or by using existing open source tooling effectively. There will be a transition period slowly moving to new hardware and learning barriers (but IMHO they're pretty low), but yes I'd say these kind of details are going to start to matter to the industry.

It's definitely not a flash in the pan. It's already taking off. Many chip makers today are moving towards RV for their embedded controllers. Western Digital moved to RISC-V for their embedded controllers, Microchip has a SiFive CPU in their upcoming PolarFire FPGA, Nvidia moved to RV to replace their controllers, Chinese chip makers (e.g. Sipeed) are moving to RV instead of using ARM. Those are only the ones that we know about. Why would they not do it? There's really no good reason to choose a Cortex-M0 over some RV core as long as your customers (internal or external) are OK with it.

Do it matter that it's open source? Maybe not in terms of the CPU RTL being open source: you still need to do a lot of verification if you take your job seriously.

But the fact that the ISA was open source made a bunch of people interested enough to start tinkering with it and contributed to tools etc. I think the open source part was essential to get the RV thing moving.

Clang is the sound of the bell that tolls for Arm which isn't in as strong of a place as it used to be.

It matters a lot. But there are different technologies that are converging that give it a better shot at success this time.

An Instruction Set Architecture (ISA), by itself, is really nothing more than a computer science exercise. However, a systems architecture which allows you to build complete systems, that is something entirely different.

For a new "system" to take hold, you need four things:

1) An ISA that can express useful computation in a way that the computation can be completed in a useful amount of time. Everyone loves to build a little Turing machine which can compute anything, but nobody really wants to run and editor that is running on a simple Turing processor because it isn't performant enough to be useful as an editor. So the combination is critical, good ISA, and an efficient way to process that ISA in hardware.

2) Tools to convert algorithms expressed in a common high level language, into a reasonably efficient use of the ISA. The gcc suite of tools has really helped here for a large number of ISAs. The majority of engineers express their algorithmic ideas in languages like C and C++ Etc. When they are compiled into code on a machine, the less space they use in RAM and FLASH and the faster they can run, increase the value of the ISA.

3) Resource and configuration management for the systems. Typically the operating system, Linux works well for this, it is software that is already built/available that means you only need to invest in the "new" algorithm code to get your idea running, not a bunch of basic system management code. For example, developing for Android, you just need to write your app, you don't need to create a new compiler, or write an OS, or device drivers, just your app. Successful systems have this "eco-system" already in place to support a wide variety of applications.

4) An effective I/O channel. If you want a good example of this, look at routers in the early 2000's. The Power architecture had a much better infrastructure for building many many lanes of I/O into the CPU and so folks like Cisco, Juniper, and others used systems based on that architecture for their routers and switches. The "software" could run on x86 architecture systems, but those systems were always challenged in creating hundreds of I/O endpoints in part due to the legacy of the IBM PC and Intel's "southbridge"/chipset strategy for holding on to additional margin (aka profits).

Open source hardware is getting to the point where all of these conditions are close to being met, and when they are, it really changes who gets to keep the 'value' that is derived from selling complete systems. It takes it away from the chip maker and moves it toward the system integrator. Perhaps it is surprising but that translates into systems integrators selling systems for less money and making more (or at least the same) profit on them.

Too little too late probably. But openness and competition is good!

> MIPS’ target customers will include Arm licensees looking for alternatives.

> MIPS’ advantages over competitors are many. Its instruction sets already have extensions such as SIMD (single instruction, multiple data) and DSP.

But…ARM has those things?

ARM has those things but MIPS, once this process is completed, will be open source. This makes a difference regarding license pay.

Also you can modify the instruction set, which you cannot do with Arm. Risc-V has a detailed model of which bits you can change,what is the common core and so on, which Mips will need too.

ARM has vendor extension space as well. Intel used that for DSP and "Wireless MMX" in their Xscale CPUs.

Depending on what the license actually will be. ARM has for example presented "free" cores to fight against RISC-V. Free as in slightly cheaper beer.

https://www.bit-tech.net/news/arm-responds-to-risc-v-threat-...

Yes, and so to some extent so does RISC-V. Some RISC-V ISA extensions are still under development, but getting getting stable. Also the RISC-V is in comparison to MIPS a cleaner ISA. No delay slots for example.

Are there delay slots in modern / 64-bit MIPS? I've heard they're only really present in very old MIPS

Good question. I took a look. What is being released is the Release 6 ISA. And I stand corrected, according to wikipedia that ISA doesn't have delay slots:

MIPS32/MIPS64 Release 6 in 2014 added[22] the following:

    a new family of branches with no delay slot:
        unconditional branches (BC) and branch-and-link (BALC) with a 26-bit offset,
        conditional branch on zero/non-zero with a 21-bit offset,
        full set of signed and unsigned conditional branches compare between two registers (e.g. BGTUC) or a register against zero (e.g. BGTZC),
        full set of branch-and-link which compare a register against zero (e.g. BGTZALC).
    index jump instructions with no delay slot designed to support large absolute addresses.
    instructions to load 16-bit immediates at bit position 16, 32 or 48, allowing to easily generate large constants.
    PC-relative load instructions, as well as address generation with large (PC-relative) offsets.
    bit-reversal and byte-alignment instructions (previously only available with the DSP extension).
    multiply and divide instructions redefined so that they use a single register for their result).
    instructions generating truth values now generate all zeroes or all ones instead of just clearing/setting the 0-bit,
    instructions using a truth value now only interpret all-zeroes as false instead of just looking at the 0-bit.

Removed infrequently used instructions:

    some conditional moves
    branch likely instructions (deprecated in previous releases).
    integer overflow trapping instructions with 16-bit immediate
    integer accumulator instructions (together HI/LO registers, moved to the DSP Application-Specific Extension)
    unaligned load instructions (LWL and LWR), (requiring that most ordinary loads and stores support misaligned access, possibly via trapping and with the addition of a new instruction (BALIGN))

Reorganized the instruction encoding, freeing space for future expansions.

https://en.wikipedia.org/wiki/MIPS_architecture#MIPS32/MIPS6...

seems until very recently it still had delay slots[1]

[1] https://en.m.wikipedia.org/wiki/MIPS_architecture (see mips64 release 6)

I'd really like to some new OS efforts to go along with new chips. Does it really have to be *nix on everything?

If it can't run a browser, adoption is going to be crippled, and porting a browser to a new OS is a much bigger project than writing your own OS.

Or, in general, getting code to run on it at all. Almost every OS that hasn’t offered C (and arguably some sort of POSIX) has floundered without gaining traction.

Almost every OS that has offered C and POSIX has floundered without getting traction, too.

The number of operating systems that have succeeded in any real way is tiny, and probably not big enough to draw any conclusions from. None of the major players today got to where they are now by following the conventional wisdom of their day. I assume the next big OS (or three) will similarly succeed by breaking all the rules we thought we knew.

These chips aren’t going to be running browsers in the near future, unless you mean in a TV (one of the last places you could find MIPS).

The market they are headed for is embedded, where every cent of the BOM counts. Licensing costs can add up surprisingly fast as part of that.

Server parts are a big step above that - MIPS used to play there, but after a short peak they failed many times over. It tried in the networking and embedded space for a while, but then had its lunch stolen by all the cheap ARM vendors from below, and stomped on by x86 from above.

And then desktop/laptop parts? Unless you are Apple (and even then), pushing a new arch on the desktop is a massive, expensive task, and I can’t see it being worthwhile.

>> The market they are headed for is embedded...

Are you sure? RISC-V is about to explode in the embedded space. I always ask our suppliers about their RISC-V plans and it's shifted over the last 3 years. They've gone from "what's that?" to the point where they are all aware, some are hedging, and some are going full tilt but not quite at the stage of "here are our offerings". Anyone who is not currently a MIPS user (chip maker) in this space is years behind.

> Anyone who is not currently a MIPS user (chip maker) in this space is years behind.

RISC-V user?

Webkit is pretty portable.

Such defeatism is why we have to put up with clunky 50 year old abstractions and the over-complicated "ecosystem" of webshit we built on top of them.

(firstly, this is kind of off topic, since OS design is usually orthogonal to processor architecture, unless you've got something really funky going on)

Acknowledging the huge amount of work that needs to be done for an alternative to be adopted is not defeatism, it's realism. There have been plenty of minority, research, or experimental operating systems over the past few decades. Hardly any of them persisted, because it's a very Darwinian winner-take-all market.

> Acknowledging the huge amount of work that needs to be done for an alternative to be adopted is not defeatism, it's realism.

IMO this is bit of a "the chicken or the egg came first?" problem.

The industry had a lot of needs in terms of computing when computers started becoming physically small. The very first few things -- OS, any tech paradigmae, chip designs, shell architecture and what-have-you -- that seemed to do the job good enough got 99.9% of investments and mindshare and thus even if everything we currently use is ugly and barely working, there's no economic interest to revisit the other competing standards from the dawn of computing and see if there are golden geese hidden in there somewhere.

So when a carpenter tells you "I need a natural wood and screws because that's what works best" you really should be reading that as: "nobody tried to invent better materials and joinery techniques or tooling so I'll stick to what I know".

"Good enough" is not a slogan to follow.

I really want to see an introspective, single-user, programming-centric, graphical operating system that isn’t dumbed down to the lowest common denominator. A new ISA seems like a great opportunity to ditch the current models of computing for something more Genera-esque, since we now can produce commodity hardware that is powerful enough to achieve good performance at reasonable prices.

You and me both. I want something I can actually feel like I'm in control of because it not only respects me as a user but also is built on simple metaphors that map well to reality, allowing me to actually understand how it works without untangling a horrible spaghetti mess of legacy systems patched together with spit and rubberbands. Something meant to help me make my life better instead of making someone else a bunch of money making me miserable.

Sadly, I'm not aware of anybody working on such a project. Most people making "OS"s these days either just make yet-another-linux-distribution and confirm that old saying about the definition of insanity, or they're content to make some completely academic kernel that no one can use for anything but academic purposes. I wish I had the skills to start one myself.

How useful would a full-screen GUI application that runs on existing operating systems be? That way eliminates dealing with device drivers or building custom hardware.

The Lisp-all-the-way-down part doesn’t seem as useful as it was originally. You could get 80% of the functionality with 10% of the work of a full OS.

Part of the problem with that approach is that you're still reliant on the host OS and have just pasted a new layer of abstraction over the old one. Kinda like the web. You haven't really fixed any of the problems of the underlying platform, while at the same time you've added complexity and bloat.

I think there is, perhaps, value in a middle ground. You could take the Linux kernel (chosen here for its existing driver support, openness, stable syscall ABI, and presence of virtualization and namespacing features), but throw away basically everything on top of it and build a new "operating environment". Then, over time, you could fork the kernel away, ditching legacy syscalls and features, maybe creating a stable driver ABI finally, etc.

> The Lisp-all-the-way-down part doesn’t seem as useful as it was originally. You could get 80% of the functionality with 10% of the work of a full OS.

You're missing the point. If the only goal was "functionality," a quick-and-dirty hack on top of existing systems would suffice.

However, the GP wants a system that's reasonably comprehensible all the way down, so he can have some confidence that it's not working against him in some way. The accidental complexity of decades of legacy software works strongly against that.

I completely agree with you, which is why my highest-level comment in this thread suggested using a new ISA, too. However, for practical reasons, it would be a ton of work to design and build hardware and a complete operating system. That’s the holy grail, of course, but it’s going to be hard to achieve without a large company backing it up.

> I really want to see an introspective, single-user, programming-centric, graphical operating system that isn’t dumbed down to the lowest common denominator.

Hit the nail on the head.

Things are impossibly complex and convoluted nowadays. And working against us more often than not -- as you said.

It feels like we really need to start over. All the way down to the CPU and GPU hardware architecture.

Take a look at plan9 and haikuOS. O am not implying that this is a solved problem, just intriguing projects.

> Acknowledging the huge amount of work that needs to be done for an alternative to be adopted is not defeatism, it's realism.

Realism is often just a mask over defeatism.

Unless you are using programming languages that are native to the platform (which also happen to be clunky and 50 year old) you never have to deal with those 50 year old abstractions.

Not everything requires a browser...

The main use-case for these devices is in embedded-applications, for which there are many other operating systems (FreeRTOS and the like).

What you're not going to find is any real desktop-OS support (other than Linux). Its been a while since MIPS had any presence on the desktop. (i.e SGI).

FWIW, FreeBSD runs on MIPS just fine.

there's not that much OS dependence on chips unless you want to build it on segments and/or capabilities...there are viable ways to fake those. maybe if there were a novel form of parallelism?

i agree with you that we can do better, but as other people have commented, that wound is pretty much healed over.

integrated distributed management, process migration, and radically simplified OS state might put some devops people out of a job..but the industry doesnt like to take hops that large. the configuration and deployment hodgepodge is 'good enough'

did you have some specific ideas you think would be interested enough to drive adoption?

Isn't that basically what kubernetes is supposed to solve? I will admit my attempts to use it have been unsuccessful but the point still stands: There is no need for a completely new operating system.

we totally agree. i think things could be alot better. but even though I have alot of big ideas nothing seems to justify someone adopting such a thing. even completely ignoring the cost of building and testing it.

maybe some foundational advance in real security. better abstractions and performance aren't enough.

No ideas in particular, I just fondly remember for example the responsiveness of the Amiga - PCs still don't seem to be as solid clock-wise, and when you get into running apps in a browser it seems like the multiple layers of abstraction are really obvious. And that's just on a desktop - Android is even worse! A pretty horrible laggy UI, and once you get into the horrific disaster that is Android development the underlying cause kind of reveals itself.

Imagine the tightness of a mobile OS running close to the metal and how responsive that device could feel. You used to be able to switch on a device and the OS would immediately be there - indeed embedded devices are often still like this.

Perhaps I'm just being too nostalgic though, and I realise Amiga OS was missing essential things like memory protection etc. that we now take for granted.

It would be nice if the owners of IRIX (whomever that is now) would release it as open source, so we could run it on our open source MIPS system. I miss my old Octane.

Yikes. HPE owns it all now: https://en.wikipedia.org/wiki/Silicon_Graphics_International

http://metamodular.com/lispos.pdf

Here is some more info about the MIPS Open community MIPS is trying to establish:

https://www.mips.com/mipsopen/

Based on the FAQ, older MIPS architectures, for example Release 5 is not included, only Release 6. I don't see any info about what the exact license they plan to use.

Give me a big fat MIPS pizza box for the 21st Century, and I'm in. Give me a pocketable mobile MIPS device, and I'm in as well.

As long as they both work together as platforms.

>Swift added, “The 30+ year legacy of MIPS architecture should mean something. It’s a value.”

This reads so desperate. "should mean something" betrays they're not even sure themselves.

The general rule to this type of question titles is that the answer is NO, right?

usually it goes like "technically yes but in practice no"

Reply on news.ycombinator.com