When Wave Computing acquired MIPS, “going open source” was the plan Wave’s CEO Derek Meyer had in mind. But Meyer, a long-time MIPS veteran, couldn’t casually mention his plan then. Wave was hardly ready with the solid infrastructure it needed to support a legion of hardware developers interested in coming to the MIPS open-source community.
To say “go open source” is easy. Pulling it off has meant a huge shift from MIPS, long accustomed to the traditional IP licensing business.
MIPS will compete with and exist alongside RISC-V. The future of truly open source hardware is getting more and more interesting.
Second link is broken. I believe it should be pointed to: https://www.eetimes.com/document.asp?doc_id=1334317
Thank goodness! It was looking pretty bleak for a while.
Pro-Competition,
SPARC was opened as an architecture, so what would help MIPS succeed where SPARC couldn’t?
To be fair, SPARC is a very complex architecture. I think MIPS has a much cleaner architecture and will likely be easier to work on. For example, according to Wikipedia, a SPARC processor has between 72 and 640 general purpose registers. Is that sort of overkill really necessary?
MIPS, on the other hand, has a much simpler design and has a history of being used in embedded environments. Before smartphones were all the rage, I remember thinking MIPS was going to be the future of embedded systems. Then Apple released the iPhone with an ARM CPU and everyone else took the path of least resistance and followed that formula.
ARM was already the standard for low power reasonable powerful electronics. PDAs and many cellphones (dumb and feature alike) used ARM.
teco.sb,
Probably not, but I would have thought being open source meant that people could modify the design to reduce complexity to suit their needs. I can only assume that OpenSPARC wasn’t so horrible as to be completely unmodifiable.
One of the big benefits of RISC is that it isn’t limited to an extremely small number of registers the way many CISC designs often are (especially x86, even with amd64). 64+ registers isn’t a ridiculous idea.
…and in education, to learn asm programming.
As Megol says, ARM was an established player long before iPhone; it was Apple who “took the path of least resistance and followed that formula” – the first iPhone (which was hardly a smartphone…) used fairly standard off-the-shelf Samsung SoC; almost all dumb-, feature and smartphones before the iPhone already used ARM SoCs.
(smartphones were quite the rage before iPhone: from https://en.wikipedia.org/wiki/List_of_best-selling_mobile_phones Nokia 6600, a Symbian smartphone from 2003, 5 years before iPhone, sold 150 million units, which is more than any iPhone except “iPhone 6 and iPhone 6 Plus” (which for some reason are grouped together …while for example Nokia had many phones from the same hw gen which differed less than iPhone 6 and 6 Plus, but were under different names / counted separately)
…well, except it possibly wasn’t that visible in some always atypical places like the US, perspective from which you might have)
Seems you have fallen prey to RDF…
SPARC is the worst modern RISC architecture out there, because it forces needless replication of registers in implementations to support the “register windows” feature (minimum of 3 register windows), which doesn’t deliver much of a performance benefit to justify the cost.
Ironically, Intel managed to work around their own problem of too few registers in x86 with register renaming and hidden registers, there is no solution for the SPARC problem of too many register windows. So much for SPARC being a better design. Cleaner? Yes. Better? No
If you are not running Solaris (the non-x86 flavor) you have no reason looking at SPARC. Nobody chooses SPARC for clean sheet designs.
kurkosdr,
But x86 register limitations were notoriously bad. Register renaming could only do so much in the context of super-scalar pipelines by taking advantage of temporary local calculations, but for many algorithms that fundamentally required more state information than x86 had registers for were forced to push and move values onto to stack. While you can create very fast memory caches to try and mitigate the performance loss from this, 1) it’s still slower than having adequate registers in the first place, 2) it creates far more complexity (ie cache coherency protocols) , and 3) all those transistors require more power than simple registers.
At least AMD64 helped address the x86’s pathetic lack of GP registers.
rax, rcx, rdx, rbx, rsp, rbp, rsi, rdi, r8, r9, r10, r11, r12, r13, r14, r15
It’s possible that 32 registers would be better still, though I don’t know where the sweet spot is.
kurkosdr,
But SPARC is open now. What’s to stop someone just implementing it without register windows? That’s the whole point of going open source on processor design.
The question I was asking pertains to open sourcing a design. Where would MIPS succeed, by being open, that SPARC didn’t, by being open.
Removing register windows would make it basically not Sparc. Coincidentally, it’s the main difference in between Sparc and MIPS, both of which were built on the original RISC design (which in some iterations did include register windows).
FlyingJester,
Yes, but that’s not the point of open sourcing a design, or using an open source design. It might make it not SPARC, but at the end of the day, the implementer has a tested design that they don’t have to get reanalyzed from the ground up. Everything else works and you didn’t have to spend a whole bunch of R&D to get the rest of it working.
And if that couldn’t make OpenSPARC work, I don’t see how opening MIPS would work even if it didn’t come with the slightly extra cost of having to remove a feature.
…or if you don’t work for European Space Agency (Leon OpenSPARC radiation-hardened chips are fairly standard there 😛 )
This could be bad. RISC-V was designed to be an improvement over MIPS and other RISC ISAs, but now that MIPS is open and is more developed / proven its temptations may lock us into the past, just like x86 did. Wave should have adopted RISC-V. Ultimately it’s a better platform for their mission.
I disagree. I like that architectures which have open implementations, large-scale existing support from compilers and OSes, and reasonably clean designs are getting attention. I wish the same for SH and UltraSparc.
Also, keep in mind that no practical working design will ever stay “clean” forever, not even RISC-V.
FlyingJester,
You are right to highlight the problem, but there is a realistic technical solution to this. By making use of the “VM” concept used by Java/dotnet/Dalvik/art/etc, we can have a robust abstraction between software and the ISA.
We’ve learned so much since the dawn of computing, but the truth is we still struggle to embrace everything we’ve learned and to clean up legacy baggage due to the ongoing reliance on legacy software. New software platforms are already headed in the right direction, but it’s just taking so long to displace legacy environments on the PC. There’s a lot of resistance to change, and unfortunately, some of the resistance is due to new platforms coming with strings attached (ie loss of ownership rights & app store fees). I can’t in good faith recommend any new platforms that would have owners & developers loosing rights even if they address some of the legacy software issues.
It can also be hard to walk away from mature and robust (or at least “robust except for well-known, well-documented bugs”) platforms.
It’s going to be curious to see how open, open is going to be.
I guess open only matters when things go awry. MIPS may open up the IP and designs, but if no one else forks it, does it really matter?
Outside of filling up an FPGA, the start up costs of making new silicon are not low, much less board and peripheral development and integration.
But, still, good news.