Slashdot Mirror
Imagination Technology Buys MIPS
New submitter HalWasRight writes "After years of struggle, MIPS Technologies — the original RISC processor company — is being sold to Imagination Technologies, best known for its popular mobile GPUs. Part of the deal included MIPS divesting much of its non-processor related patents to a group that includes ARM. This deal could change the landscape in the battle for mobile sockets."
MIPS press release, Imagination press release.
I thought MIPS was dead. And looking back a lot of architectures has been running out of steam. Motorola 68000, PA-Risc, Digital Alpha to name a few...
Right now there are only three or four architectures that delivers some punch, x86, ARM, Sparc and Itanium. But the last is only alive due to HP and Sparc is kept alive by Oracle so far.
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
Of all the assembly languages I learned in college, MIPS was by far the best design.
Learn something new.
True, the PlayStation Vita switched from the PSP's MIPS to a quad-core ARM, though it still uses an Imagination Technologies GPU. But PowerPC is being kept alive by all three major video game console makers.
Which has turned into a complete dogs dinner in the last couple of decades first with the FPU stack based instructions being glued to a register based architecture then all the endless psuedo parallel long word instruction sets intel have thrown at their cpus like confetti. Its long been said that compilers make a better job of generating assembler than a human, but these days I doubt if a human could even grok the entire x86 instruction set to start with. I gave up long ago.
Don't call me Shirley!
Agent K: A *person* is smart. People are dumb, stupid, panicky animals, and you know it.
Well, "RISC I" was the first VLSI RISC processor, as described in:
D. A. Patterson and C. H. Sequin, "RISC I: A reduced instruction set VLSI computer," in Proc. 8th Annu. Symp. Comput. Architecture, Minneapolis, MN, May 1981, pp. 443-457.
The architectural principle is generally credited to John Cocke, on the IBM 801 minicomputer, though others published first. Some (like me) might argue it goes back to Seymour Cray's designs at Control Data for the CDC6600 PPU but those definitely did not have a minimal instruction set, just a small one with a 6-bit opcode field.
Oh, I'm sorry sir, I thought you were referring to me, Mr. Wensleydale.
Fun (if you're into that sort of thing) discussion of the early days of MIPS at the Computer History Museum in 2011. http://www.computerhistory.org/events/video/?videoid=3paiCK3dlK0
Dear Slashdot: next time you want to mess with the site, add a rich-text editor for comments.
Commenting on SPARC and Itanium...
There was a time when SPARC was popular way beyond just Sun Unixstations. They were used in some networking gear (mainly from Sun), and even in a laptop from Tadpole. Also, there were some other companies that made SPARCstations - Integrix and Tatung, and companies that made SPARCS other than Fujitsu or Sun - Ross Technologies. Not sure what they do now. But Suns would have been a great platform for Linux - a pity that Oracle didn't deem it fit to offer Oracle Linux as an option on their SPARCservers. Also, had Oracle followed Sun's philosophy of selling the hardware and making the software free (as in beer), they could have offered their customers various options on the SPARCservers - Solaris itself, Oracle Linux, Debian Linux, FreeBSD, and OpenBSD, depending on the applications.
Incidentally, it's not Hitachi, but Fujitsu you were probably thinking about, w/ their SPARC64. They are the ones who've made the K supercomputer, so the SPARC is de facto increasingly a Fujitsu platform. Hitachi was one of the vendors that used PA-RISC in the past - not sure what they did since, whether they went Itanium, or something else.
Speaking of Itanium, it never made sense to port any of the old OS platforms to it. Talking first about the non-Unix OSs, OVMS should have remained on the Alpha, and the 2 should have been retired together - just like Irix did w/ the MIPS based SGIs (once SGI switched to Itanium, they also switched to Linux, and didn't bother to port Irix there). Same goes w/ NonStop and MIPS based Himalaya servers. Issue an EOL notification, maybe open up to just those existing customers the source code of all those platforms, do a final support for as long as the customer needs, and during that time, give the customer the option to hire their own in-house staff to maintain them as long as they survive. Moving OVMS and NonStop to Itanium - any customer would have to be pretty stupid to go for that proposition.
On the Unix side of things, a lot of parallel Unix projects had started, and died - such as SCO's Monterrey. It made no sense to port every other Unix to the platform: in fact, the Itanium was the perfect platform to launch a single Unix on (or maybe 2 or 3, to satisfy the closed source, open sourced and liberated software factions). In other words, something like an HP/UX or Unixware or OSF/1 could have been the standard Unix for the platform, FreeBSD could have been the standard bearer for open source, and Linux could have been the standard bearer for GPL.
Incidentally, given that in VLIW, and even in EPIC architectures, compatibility b/w different generations is deliberately broken since all the work is tossed to compilers, this is the ideal CPU for the FSF and advocates of liberated software, such as RMS. Right now, you have them advocating open drivers for GPUs, but w/ something like a VLIW, it would be a dream come true for them, since every time, for every generation and implementation, software would have to be recompiled. As a result, the source code would have to be made available. Make VLIW based GPUs, and the drivers would have to be Open Sourced. This would be the perfect platform for HURD.
In reality, since Itanium I & II bombed, nobody has to bother about their compatibility while coming out w/ Itanium III versions of their software. But I think that this would be the last, and if it continues, then from there, any enhancements would be done by simply adding more cores. Indeed, both VLIW and RISC lost their advantages over CISC the day multithreaded applications became popular, since vendors could simply throw more cores at the problem. By doing this, Itanium could lose the one major dealbreaking shortcoming that it has - inherent incompatibility b/w generations of CPUs.