MIPS Strikes Back: 64-bit Warrior I6400 Arrives
by Stephen Barrett on September 2, 2014 10:00 AM ESTFinal Words
When it comes to processors, enthusiasts and laymen alike can identify the three largest players: Intel, AMD and ARM. Those names are also not mutually exclusive: AMD utilizes ARM designs for consumer security coprocessors and in its Opteron A1100 server processor. There are other processors out there (e.g. IBM's POWER CPUs), but they're generally not as well known. That's also the case with MIPS.
Not everyone knows the name MIPS, but Imagination hopes to change that by offering a viable alternative to the embedded market dominated by ARM. MIPS already has a large presence in networking and embedded devices. Introducing the I6400 keeps MIPS relevant and places additional pressure on ARM. According to the provided numbers (admittedly from MIPS) and feature descriptions, the I6400 appears to compete with and even surpass the highly anticipated ARM Cortex-A53. Imagination projects general availability of the I6400 to SoC designers by December 2014. We can estimate end-user availability at least 6 to 9 months after that.
Consumers will most likely directly experience the MIPS I6400 CPU in low cost Android tablets and handsets. Due to Android's Java heritage, some applications will work out-of-the-box. Other applications using the Android Native Development Kit (NDK) targeting Intel or ARM ISAs will unfortunately be incompatible. Until MIPS achieves enough volume to convince application developers to code to the MIPS3264 ISA or stick with Java, MIPS Android devices will be second class citizens. This is something to keep in mind if you're purchasing a phone for yourself or a tech savvy friend. Of course, basic operating system features like email, phone, text, web browsing, and chatting should all work fine.
Intel has enjoyed dominance of its performance leading processors in non-handset settings for the better part of a decade. ARMs embedded low power heritage has emerged as Intel’s biggest threat as mobile devices have exploded and now dominate the computing landscape. As Intel and ARM continue to battle for the high end embedded market, Imagination and MIPS hope to erode away ARM’s mid-range and low-end core competency. As a consumer, we can lean back and enjoy the competition that will force each company to work harder each and every year.
The I6400’s revised MIPS3264 Release 6 ISA, instruction bonding, and SMT execution pipeline bring a refreshing set of new innovations to the small-core market. In our A53 coverage we noted ARM was pushing in-order CPU performance about as far as it could possibly go. I’m always happy to see we might have been wrong.
Facebook
Twitter
RSS
84 Comments
View All Comments
extide - Tuesday, September 2, 2014 - link
No.. it's correct, and it has nothing to do with Android L. NDK apps are compiled directly to a specific ISA. For java apps, Android L/ART works the same way as Dalvik ... the only difference is WHEN the compiling to native code happens.coder111 - Tuesday, September 2, 2014 - link
Imagination technologies? Same company that's responsible for the disaster that was the GPU in Intel Poulsbo? With no drivers coming to Linux and the most hostile approach to any Linux driver development?And they want to succeed in embedded/mobile space, where lots of things run Linux? I hope they change their stance on open-source development and hardware support, and soon...
dwforbes - Tuesday, September 2, 2014 - link
Imagination Technologies, the makers of PowerVR used in a significant percentage (if not majority) of mobile devices, doesn't just want to succeed -- they have been fairly dominant for years.Lonyo - Tuesday, September 2, 2014 - link
I think that's an Intel problem partially, and it would be interesting to see if Imagination changes their approach. Intel licensed the GPU but didn't have all the access they need to develop proper drivers, and Imagination didn't care as it was a third party chip using their IP, I'd guess.It's 50/50 Intel not being sensible with the licensing and Imagination not feeling a need to care.
And yes, they were a mess. DXVA support didn't exist in XP and caused BSOD every time, and in Win Vista/7 it didn't really do much, from my own personal non-Linux experience. No support for that GPU, but I'd mainly blame Intel for not managing to sort it out when they licensed the IP. They are the ones putting their name on the product and seem to have forgotten to sort out a proper way to support it, and Imagination probably don't care when they have their money.
When it's Imagination's name on the side they would probably care.
extide - Tuesday, September 2, 2014 - link
You mean Imagination Technologies who has been the GPU provider in all of the Apple SOC's in All of the iPhones, iPads, and MANY existing android devices already on the market? That whole Atom GPU disaster was really more of Intel's fault than IMG's.patrickjchase - Tuesday, September 2, 2014 - link
On page 3 you state "even though the core is listed by Imagination as in-order, the SMT feature (when present) allows the I6400 to behave as a superscalar core".Superscalar and out-of-order are orthogonal concepts. It is possible to have a core which is superscalar but not OoO (Cortex-A7/A8/A53, MIPS R5000, the original Pentium) as well as a core which is OoO but not superscalar (IBM 360/91, the very first OoO design). Note that all of the examples I gave do not use SMT/Hyperthreading.
Stephen Barrett - Tuesday, September 2, 2014 - link
I cleaned up that paragraph. Thank you for the feedback. I think I got my wires crossed when Imagination's details discussed superscalar at the same time they discussed SMTSarahKerrigan - Tuesday, September 2, 2014 - link
"I would imagine the superscalar execution is limited to the next two instructions within a thread (as there is no reorder buffer); otherwise the entire core wouldn’t be listed as in-order."The diagram clearly shows that it can issue two ops from two different threads in a cycle. This is what makes it *simultaneous* multithreading, instead of fine-grained multithreading.
There have been plenty of examples of in-order cores with SMT - for instance, the first-gen Atom core could issue from both hardware contexts in the same cycle, as could the lightweight dual-issue in-order PowerPC core in the Xbox 360 and the Cell. Issuing from multiple contexts per cycle isn't dependent on reorder capability.
Stephen Barrett - Tuesday, September 2, 2014 - link
Yes that was hopefully made clear in the previous paragraph about how SMT works. What I was discussing in that quoted sentance is the superscalar execution capability of a single thread (not SMT). See the preceeding sentance in the same paragraph "Even though the core is in-order, the I6400 performs superscalar execution for a given thread. Since it is dual dispatch, two instructions from a single thread can be executed in parallel."alexvoica - Tuesday, September 2, 2014 - link
It behaves like a superscalar CPU when used in a single threaded configuration and like an in-order design in multithreading variants.