At least we'll always have the PS2. ...until the last one breaks, I guess.
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.
Originally, AS/400 used its own bytecode called MI (or TIMI or OMI). A descendant of the System/38's bytecode. That was compiled to CISC IMPI machine code, and then after the RISC transition to POWER instructions.
However, around the same time as the CISC-to-RISC transition, IBM introduced a new virtual execution environment – ILE (Integrated Language Environment). The original virtual execution environment was called OPM (Original Program Model). ILE came with a new bytecode, W-code aka NMI. While IBM publicly documented the original OPM bytecode, the new W-code bytecode is only available under NDA. OPM programs have their OMI bytecode translated internally to NMI which then in turn is translated to POWER instructions.
The interesting thing about this, is while OMI was originally invented for the System/38, W-code has a quite different heritage. W-code is actually the intermediate representation used by IBM's compilers (VisualAge, XL C, etc). It is fundamentally the same as what IBM compilers use on other platforms such as AIX or Linux, and already existed on AIX before it was ever used on OS/400. There are some OS/400-specific extensions, and it plays a quite more central architectural role in OS/400 than in AIX. But W-code is conceptually equivalent to LLVM IR/bitcode. So here we may see something in common with what Apple does with asking for LLVM bitcode uploads for the App Store.
> 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
Not always true. The object contains two sections – the MI bytecode and the native machine code. It is possible to remove the MI bytecode section (that's called removing "observability") leaving only the native machine code section. If you do that, you lose the ability to migrate the software to a new architecture, unless you recompile from source. I think, most people kept observability intact for in-house software, but it was commonly removed in software shipped by IBM and ISVs.
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.
The Mill does something like this, but only for their own chips. "Binaries" are bitcode that's not specialized to any particular Mill CPU, and get run through the "specializer" which knows the real belt width and other properties to make a final CPU-specific version.
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 avoid.)
Non-web use cases of WASM in practice seem more focused on isolation, sandboxing, and security rather than architecture independence - stuff like "edge computing" - and I haven't read about anyone using it for AOT compilation. But perhaps it has some potential there too?
You've re-invented UCSD P-code.
The BCPL compiler always outputs ocode. Then a back end for the particular system statically generates machine code (or assembly language)
Back in 1983 I helped take a BCPL running on a VAX and add a M6809 back end to it.
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.
Efforts like Bootstrappable Builds and Debian's rebootstrap aim to reduce the barriers for new architectures:
https://bootstrappable.org/ https://bootstrapping.miraheze.org/wiki/Main_Page https://wiki.debian.org/DebianBootstrap https://wiki.debian.org/HelmutGrohne/rebootstrap
For eg the Synopsis folks are bootstrapping a Debian ARC port right now using rebootstrap.
https://github.com/foss-for-synopsys-dwc-arc-processors/rebo...
IBM's OS/400 (originally for the AS/400 hardware, now branded as System i) did precisely this: Compile COBOL or RPG to a high-level bytecode, which gets compiled to machine code on first run, and save the machine code to disk; thereafter, the machine code is just run, until the bytecode on disk is changed, whereupon it's replaced with newer machine code. IBM was able to transition its customers to a new CPU architecture just by having them move their bytecode (and, possibly, source code) from one machine to another that way.
https://en.wikipedia.org/wiki/IBM_System_i
Other OSes could definitely do it.
See https://en.wikipedia.org/wiki/Architecture_Neutral_Distribut...
Using ANDF you could produce portable binaries that would run on any UNIX system, regardless of CPU architecture. It was never commercially released though. I think while it is cool technology the market demand was never really there. For a software vendor, recompiling to support another UNIX isn't that hard; the real hard bit is all the compatibility testing to make sure the product actually works on the new UNIX. ANDF solved the easy part but did nothing about the hard bit. It possibly would even make things worse, because then customers might have just tried running some app on some other UNIX the vendor has never tested, and then complain when it only half worked.
Standards are always going to have implementation bugs, corner cases, ambiguities, undefined behaviour, feature gaps which force you to rely on proprietary extensions, etc. That's where the "hard bit" of portability comes from.
https://en.wikipedia.org/wiki/Architecture_Neutral_Distribut...
It didn't last.
There are a lot of universal-binary candidates both current and historical. Javascript, Java, SPirV, LLVM intermediate representation are some of the current ones. So, this isn't a new idea, it's just that most of the software I use regularly is compiled specifically for x86-64. Maybe it would be better if that were a rare exception rather than the norm.
> 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 JavaScript, Java, and Safe Rust are pretty much ISA-independent by definition, it's 'just' a matter of getting the compilers and runtimes ported across.
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.)
For programs which are architecture-sensitive by nature, such as certain parts of kernels, there are no shortcuts. Or, rather, I'm confident the major OSs already use all the practical shortcuts they can think up.
> When you run your program the first time, it's compiled to native code for your architecture and cached for later use.
Source-based package management systems already give us something a lot like this.
There are operating systems that take this approach, such as Inferno. [0] I like this HN comment on Inferno [1]: kernels are the wrong place for 'grand abstractions' of this sort.
> I realize I've sort of just re-invented Javascript
Don't be too harsh on yourself, JavaScript would be a terrible choice as a universal IR!
> [[ to the bulk of your second paragraph ]]
In the Free and Open Source world, we're already free to recompile the whole universe. The major distros do so as compiler technology improves.
> Processors would be able to compete directly with each other without regard to vendor-lock-in.
For most application-level code, we're already there. For example, your Java code will most likely run just as happily on one of Amazon's AArch64 instances as on an AMD64 machine. In the unlikely case you encounter a bug, well, that's pretty much always a risk, no matter which abstractions we use.
[0] https://en.wikipedia.org/wiki/Inferno_(operating_system)
Maybe, but PNaCl (unfortunately deprecated by Google) "defines a low-level stable portable intermediate representation (based on the IR used by the open-source LLVM compiler project) which is used as the wire format instead of x86 or ARM machine code" https://www.chromium.org/nativeclient/pnacl/introduction-to-...
That sort of works, but duplicating the proper development environment in the end-user's computer would take a lot of space and would be complicated by the enormous variety of programming languages and environments. Linux distros manage this with a lot of effort. I'm imagining something like a universal intermediate representation that can be compiled quickly (because a lot of the early language-specific part of compilation will have already been done by whoever you get your packages from) and in a uniform way because there's a common intermediate representation format that all the compiled languages use.
Universal binaries might also be acceptable for commercial, closed-source applications where source distribution would not.
What problem did MIPS solve in a unique way that others didn't? Because it wasn't desktop, mobile, embedded, graphics or AI.
After all MIPS's original insight was that machine code was now overwhelmingly written by compilers and not handwritten assembly, so they made an ISA for compilers. I think history proved them absolutely right, actually these days there are often a couple of layers between the code people write and the instructions fed into the CPU.
I guess my point is that nowadays I'm sure that many competent devs don't know what little-endian means and probably wouldn't have any idea of what "register windowing of the stack" is, and they're completely unaffected by these minute low level details.
Making it a bit easier for OpenBSD to find subtle bugs is certainly nice, but that seems like a rather weak argument for the vast amount of work required to support a distinct ISA in a kernel.
Honestly I'm not convinced by the argument for diversity here, as long as the ISA of choice is open source and not patent encumbered or anything like that. Preventing an x86 or ARM monoculture is worth it because you don't want to put all your eggs in Intel or Nvidia's basket, but if anybody is free to do whatever with the ISA I don't really see how that really prevents innovation. It's just a shared framework people can work with.
Who knows, maybe somebody will make a fork of RISC-V with register windows!
So, I immediately saw it had issues on a variety of different platforms, including an endianess problem. Cpantesters.org lets you drill down and see what went wrong in pretty good detail, so I was able to fix the problems pretty quickly.
It used to have a ton of different platforms like HPUX/PA-RISC, Sun/Sparc, IRIX/MIPS and so on, but the diversity is down pretty far now. Still lots of OS's, but few different CPUs.
Even today, comparing modern MIPS64 and ARM aarch64, I find ARM's new ISA to be perhaps more similar to MIPS than to ARMv7.
https://tvtropes.org/pmwiki/pmwiki.php/Main/SeinfeldIsUnfunn...
The MIPS R2000 was debatably the first commercial RISC chip. It solved whatever problem you needed a really fast CPU for in 1985. The alternatives on the market were the Intel 386 and the Motorola 68000. The Intel 386 at 16 MHz did about 2 MIPS (heh - millions of instructions per second) with 32 bit integer math. At 16 MHz, the R2000 did about 10 MIPS. Even accounting for RISC code bloat, that's 3 - 4x faster.
Note how there were only two competitors selling 32-bit designs in the market they entered. I think that's probably the biggest impact of MIPS. They actually sold the chip! They wanted companies to design their own computer systems around it. Use it in an embedded device. Whatever. That was not the norm c. 1985 - 1988 for high-end silicon.
There were machines faster than the 386 or 68020 at that time. You could buy one of the fast microprocessor-based VAXes recently introduced. Or if not too squeezed for office space and with a blank cheque, one of the super-minis like a real VAX or IBM's new "mini-mainframe". After '86, maybe you'd buy one of the other RISC options, like SPARC or PA-RISC.
Whatever you bought, it would be the whole system. Take it or leave it. DEC would not sell you something like a CVAX processor all by itself just so you can build it into a product that will compete against them. (Well, they would sell you one, just not at a price you could afford if you aren't a defence contractor.)
Both DEC and SGI would use MIPS processors in their workstations of the late 80s, as did some less well-known names. The embarrassment of having to use a competitor's processor to sell a decently fast and affordable UNIX workstation would inspire DEC to create the Alpha. In this vein of "we'll sell it to whoever wants to buy it!" MIPS was also doing ARM-style core IP licensing, before ARM did. That's probably part of why MIPS was so prominent as an embedded architecture in the late 90s and early 2000s, in everything from handhelds to routers to satellites.
I don't know about unique way, but MIPS certainly was good at embedded; there's plenty of networking gear using it.
As far as I understand, it's not that MIPS is the best at embedded, it's just that it's cheaper to sell as the license cost is non-existing and good support already exists in kernels and so on.
I suppose it will live on in that form, especially if the IP is opened up.
I do think the simplicity of MIPS was a big plus there, including simplicity of simulating it (http://spimsimulator.sourceforge.net/). I suppose a lot of students may appreciate being taught on something that is or is about to be very widely used, even if it's more complicated in various ways -- and the fact that one of the textbook authors was a main RISC-V designer makes me assume that educational aspects are not at all neglected in the RISC-V world.
Perhaps CPU diversity is in decline but it seems to me that the industry as a whole is moving towards more diversity. It's gotten significantly cheaper to roll your own chips to the point that we've seen entirely new processors emerging (e.g. GPUs, TPUs, etc) and becoming commonplace if not essential.
Isn't the point of RISC-V that the CPU is simple and augmented or complimented by any number of custom co-processors? If this is the general tend in the industry then the CPU itself might become a commodity part to be easily swapped out as something better emerges. Particularly if it can be abstracted away from the ISA.
https://openpowerfoundation.org
https://github.com/antonblanchard/microwatt
Unfortunately it isn't gaining any traction. From a Long term Cost perspective it is actually cheaper choosing ARM even if OpenPOWER is free. And ARM is already inexpensive.
ppc64le and 32-bit Arm are part of the wider family, but have some notable differences that make them slightly less RISC-like. Both include e.g. more complex condition code handling and instructions that operate on more than three registers.
If you want something really different, whether in operating systems or programming languages, you have it. KolibriOS and Haskell, say.
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?
One big difference is most consumers, and I think even many companies using the chips, don't really care what architecture they are using, unlike with an end-user OS/"ecosystem". So if they can use their abilities and experience from MIPS to make RISC-V chips with good price to performance, they could do OK.
Mips has seemingly been on life support sine the late 90's. I kind of think the SGI buyout and later spin-off doomed them as they were focused on building high performance workstation processors while Arm was busy focusing on low power and embedded systems. Guess who was better prepared for the mobile revolution of the 00's?
You can buy them on Amazon.
https://www.amazon.com/dp/B08W2J9B8J
https://www.mouser.com/ProductDetail/?qs=pUKx8fyJudB1sOWbbEn...
> Currently unavailable. We don't know when or if this item will be back in stock.
Clearly not!
At one point there were a few more MIPS and even OpenPOWER solution on NAS and router, but at the end having everything on ARM is just so much easier. Little sad to see it go. Especially good old Broadcom MIPS tends to be exceptionally stable.
In contrast, with RISC-V you can put your hand in your pocket for early models, can't you?
(I've got a single board computer from those people that I got in, I think, 2019)
No, not at this point. RISC-V already has plenty of momentum without this. The only thing that might change that analysis is if MIPS has some architecture patents that they could leverage to get some kind of RISC-V performance advantage. But I doubt they have anything like that now. And it's not like they have a stable of CPU designers that are now going to be switched from working on MIPS to working on RISC-V - they likely haven't had any of those folks working there since the 90s.
1. Stick with MIPS for as long as possible.
2. Follow MIPS into RISC-V.
3. Or go to some other camp.
Not really, I think the only thing they have going for them is that they probably have IP cores that would port easily and have history. However, places like SiFive [1] appear to have early mover advantage and are likely to be quicker to gain critical mass.
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 major company (AMD) is pushing 32x32-bit on one market (6xxx series) and 64x32-bit in another market (MI100 / Supercomputers).
* 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.
I believe the Neoverse V-cores (high-performance) will have access to the SVE instructions for example. So the SVE-SIMD is not necessarily locked to Fujitsu (though Fujitsu's particular implementation is probably crazy good. HBM2 + 512-bit wide and #1 supercomputer in the world and all...)
I suspect for consumer uses, SIMD is already used for nearly all the use cases it can be.
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 libraries don't exist today yet.
SIMD compute is highly niche, and clearly today's population is overly focused on deep-learning... without even seeing the easy opportunities of XML parsing or simple regex yet. Further: additional opportunities are being discovered in O(n^2) operations: such as inner-join operations on your typical database.
Citations.
* For Regular Expressions: Read the 1986 paper "DATA PARALLEL ALGORITHMS". Its an easy read. Hillis / Steele are great writers. They even have the "impossible Linked List" parallelism figured out in there (granted: the nodes are located in such a way that the SIMD-computer can work with the nodes. But... if you had a memory-allocator that worked with their linked-list format, you could very well implement their pointer-jumping approach to SIMD-linked list traversal)
* For whitespace folding / removal, see http://www.cse.chalmers.se/~uffe/streamcompaction.pdf. They don't cite it as XML-whitespace removal, but it seems pretty obvious to me that it could be used for parallel whitespace removal in O(lg(n)) steps.
* Database SIMD: http://www.cs.columbia.edu/~kar/pubsk/simd.pdf . Various operations have been proven to be better on SIMD, including "mass binary search" (one binary search cannot be parallelized. But if you have 5000-binary searches operating in parallel, its HIGHLY efficient to execute all 5000 in a weird parallel manner, far faster than you might originally imagine).
----------
SIMD-cuckoo hashing, SIMD-skip lists, etc. etc. There's so many data-structures that haven't really been fleshed out on SIMD yet outside of research settings. They have been proven easy to implement and simple / clean to understand. They're just not widely known yet.
SIMD processors are being put in self driving cars, robots with vision, doorbell cameras, drones, etc. We're only at the beginning of SIMD use-cases.
ARC, Xtensa, V850, arguably MIPS, etc. all worked in the "we're cheaper to license than ARM, and will let you modify the core more than ARM will" space. I'm not sure how they maintain that value add when compared to lower end RISC-V cores. I expect half of them to fold, and half of them to turn into consulting ships for RISC-V and fabless design in general.
Should open the path for the modernization of the auto chip industry, according to [1], 80% of ADAS chips are based on mips.
[1] https://www.globenewswire.com/news-release/2019/02/28/174460...
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=18701145
Open Source is so hip and pop these days, lets do that!
4) Can MIPS Leapfrog RISC-V? https://news.ycombinator.com/item?id=19460470
Yeah, sure, that'll happen
5) Is MIPS Dead? Lawsuit, Bankruptcy, Maintainers Leaving and More https://news.ycombinator.com/item?id=22950848
Whoops
6) Loose Lips Sink MIPS https://news.ycombinator.com/item?id=24402107
And there is the answer to the question from previous headline
And now we are here.
I also have a tube of ARM 610s (VY86C060s I think) from the same project, but R3041 was PLCC, whereas ARM was fine pitch PQFP. PLCC was easier to deal with at the time...
The rest is history.
In many ways modern MIPS and RISC-V are pretty much just different binary encodings of the same ideas.
[this was already posted as a comment in a thread, but on reflection it probably deserves its own]
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.
It's no coincidence that MIPS used roman numerals for its architectures, MIPS-I, MIPS-II, MIPS-III, MIPS-IV, and MIPS-V.
So instead of using MIPS-V Berkeley created RISC-V.
You aren't going to get anybody who was involved to say this on the record -- that they changed just barely enough to evade the licensing (instruction encoding) and trademark ("MIPS-V") problems. Openly admitting in print that it was a "minimum noninfringing change" simply invites lawsuits claiming that they were one hair's width on the wrong side of that line.
RISC-V owes MIPS about as much as MIPS owes Patterson. MIPS-V was already ~15 years old when RISC-V was first used in the classroom. RISC-V purposefully paired back the layers of marketing cruft and failed experiments that had grown over Patterson et al.'s original RISC architecture.
There is less confidence in the extensions, but as RISC-V turns 10 ... patent trolls had better hurry if they want to extort anyone based on the ISA alone.
[1]: https://live-risc-v.pantheonsite.io/wp-content/uploads/2016/...
There have been "minimum noninfringing change" MIPS clones, by doing something like leaving out the patented unaligned load and store instructions, but otherwise being identical and compatible with MIPS software and compilers etc.
RISC-V is completely different and incompatible with MIPS at the binary level. The opcodes are all different. The opcode and register fields are build from opposite ends of the word. The conditional branching model is different (MIPS r6 later copied RISC-V's version). The sizes of immediate and offset values is only 12 bits vs 16 in MIPS – which is a major reason for RISC-V having a lot more encoding space free for future instructions. There are of course no branch or load delay slots in RISC-V – something that MIPS again copied in r6.
There is a certain flavour that is similar, but the details are utterly different.
https://www.reddit.com/r/RISCV/comments/lqxwif/dylan_languag...
Swift wasn't used for anything I was aware of when I was there -- Scala was popular. Now that Chris Lattner works there, who knows?
I've been doing a little Swift programming on my M1 Mini. It's pretty nifty.
Is anyone still developing SPARC?
Microchip these days, Atmel got acquired few years back..
The packaging looks cool of those https://www.microchip.com/wwwproducts/en/AT697F
I wonder what that form factor with the chip suspended like that actually does for it.
- 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 than the Patterson/Berkeley side.
And it was supposed to go open source: https://www.mips.com/mipsopen/
but that effort sadly seems to be dead: http://mipsopen.com
That's really too bad. MIPS doesn't deserve to die.
Fortunately as mentioned above it will live on as long as there are PS2 consoles or emulators around.
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 Berkeley to allow them to use the MIPS instruction encodings for processor cores that Berkeley would design entirely themselves. So they made up their own encodings instead.
The rest is history.
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.
:)
Just so I get this straight: Wave Computing, the company that bought the remains of MIPS, is now (after bancruptcy) spinning it off as a separate company, that is going to work under the name MIPS, holds the rights to the MIPS architecture, but is doing RISC-V?
[1] https://www.prnewswire.com/news-releases/wave-computing-and-...
https://spectrum.ieee.org/semiconductors/design/the-death-of...
As the cost of continuing Moore's Law approaches infinity yes, it will cease to continue. But not before all but one foundry has been driven out of business.
And then that one remaining foundry will dominate the entire chip industry.
Also: they'll treat startups like dogshit unless they use automatic place-and-route. So chip startups will be reduced to glorified FPGA jockeys. Hard to differentiate when all you're allowed to do is sling Verilog.
Disclaimer: I knew someone who worked at Nintendo
They were so much easier to work with in assembler than x86.
I was quite impressed.
Then came the SGI Indy for me. Good times.
Sorry to see them go.
But for those who design SoC, and who needed embedded CPU of intermediate power, it's very good news. ARM is expensive here (it's considered cheap compared to Intel, the embedded world is different). The RISC V newcomers are interesting but... new, and it always get a bit of time to bring solutions to maturity, which matters in embedded. And if ARM owns the high-end (where a design must be co-optimized for the latest advanced nodes to really shine, which is very labor intensive and costly), for the mid-range it's much more open.
MIPS had a good mid-range design with the I-7200. Their problem was that the old MIPS ISA was not dense enough (larger I cache, larger Flash footprint) compared to the competition, and their compact versions not good enough. So they designed for the I-7200 a new ISA, nanoMIPS, which has "MIPS" in its name but is completely different. And guess what: nobody cared. It became another proprietary ISA, only supported by MIPS own GCC version.
But still, the design was good, and in particular the LLC/coherency support is much more mature than what many newcomers offer today. Which shouldn't be a surprise, as it's the result of a long line of (good) mid-range CPUs.
By evolving their design to RISC-V, MIPS will have one of (if not the) best mid-range CPU/cluster IP in the market soon for quality vs price --- depending on how fast the competition move, they're definitely not sitting still! And RISC V will solve the toolchain/tools support nanoMIPS has. If there had been such a RISC I-7200 equivalent a few year ago, I may have used it.
So very nice, and I look forward for more competition in the embedded mid-range CPU IP market soon.
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.
MIPS is still used in routers and set-top-boxes, but the steam is running out quickly, nearly all routers/set-top-box new design are now using ARMs already. There is a last hope though.
Strong "not with a bang but a whimper" vibes in my office today.
that being said... MIPS is certainly smaller than it once was. i hope there are still people around who remember how to build CPUs.
