MIPS Instruction Set: 64-bit Release 6

Computer processors accomplish tasks by following instructions. The processor, however, only understands instructions in a specific "language". The language of a processor is called its Instruction Set Architecture (ISA). The code sent to a processor must be in that ISA to be understood. It's similar to what would happen if someone proceeded to give me instructions in Portuguese: I unfortunately would have no idea how to execute them. When a program or operating system is authored and compiled, the compiler is parameterized to generate the 1s and 0s of binary code using a specific ISA.

In general, there are two types of ISAs. Complex Instruction Set Computing (CISC) and Reduced Instruction Set Computing (RISC).  The difference between them being of course their relative complexity. In general, a RISC ISA contains significantly fewer instructions that are far simpler than a CISC ISA.

Despite its increased complexity, CISC actually predates RISC and was only named retroactively. CISC ISAs were a necessity when low level code (assembly) was often authored by hand, and compilation was crippled by dramatically less powerful compilers than those available today. Having higher level instructions in the ISA, such as looping, allowed simple compilers to extract sufficient performance and human assembly authors to write programs. The most popular CISC ISA ever written is the x86 ISA used in Intel, AMD, and VIA processors. Interestingly, these processors now use dedicated decoding hardware to actually translate CISC instructions into RISC instructions that are executed internally.

RISC ISAs push much of the instruction complexity into the code compiler. Instead of using instruction decode circuits inside the CPU core to translate complex instructions into simple ones, RISC processors operate directly on the simple instructions provided by the compiler. This benefit is somewhat offset as often code compiled for RISC ISAs is larger; it may take multiple RISC instructions for the equivalent CISC instruction. This holds true in computer science theory, as one of the first things taught is there is often a tradeoff between storage and efficiency. If there is a desire for increased efficiency, precompute items ahead of time and then store them. If you need to save storage (or reduce the memory footprint), compute items on-the-fly.

The most popular RISC ISA ever written is the ARM ISA. The MIPS ISA, like ARM, is RISC. It has been revised several times since its inception in 1985. The first five releases are named according to roman numerals I through V, and each was a super set of the last. In 1999, MIPS announced a large revision of the ISA which deprecated the old hierarchical I through V scheme and instead focused on two ISAs: MIPS32 and MIPS64.

Release 6 occurred in 2014 and the I6400 is the first CPU utilizing the new ISA. I won’t go through all the changes in the ISA, but the most significant is a culling of the instructions. Significant work was done to simplify the ISA by removing infrequently used instructions, in particular those that overlapped with Imagination’s PowerVR GPUs. Additional instructions were also added specifically targeting today’s applications like web browsers. The fruit of these instructions has recently been seen as Google Chrome’s V8 rendering engine added experimental support for MIPS64 release 6 in July.

In the MIPS programmer’s guide the release 6 ISA is actually referred to as MIPS3264 release 6. This naming is not by accident, as MIPS64 ISA is actually a direct superset of the MIPS32 ISA. In contrast to AMD64 (x86-64), there are no "operating modes" that dictate the bitness of instructions executed on the CPU but rather an entirely new set of instructions specifically for 64-bit. Registers inside the CPU are all 64bit, and when a 32-bit instruction executes, results saved in registers are sign-extended to the entire 64-bits of space. This means there is no mode switching, and 32-bit and 64-bit applications can coexist and even be executed using the same hardware resources like registers (more on this later).

The MIPS ISA contains several optional instructions called Application Specific Extensions. These rely on optional portions of the CPU core that a licensee may or may not implement. Additionally, a MIPS CPU has optional modules that can enhance performance when paired with certain instructions.

Release 6 drops the legacy MIPS16e ASE as well as the redundant 3D ASE now that Imagination offers GPUs alongside MIPS CPUs.

MIPS CPUs in Mobile Devices

While MIPS CPUs are quite popular in networking equipment and many other embedded industries, consumers will likely only experience one firsthand when it's integrated into an Android handset. Since Android 4.0, Google has supported three ISAs: x86, ARM, and MIPS. Several devices have shipped running MIPS processors, most notably the low-cost Novo 7 tablet. MIPS devices will continue to be low cost alternative devices for now, but low cost devices have the largest volume. The volume should eventually help MIPS push app developers to address their #1 problem: compatibility.

Android applications are either written in Java, then compiled on the device to the specific required ISA before running (a processes called JIT compilation), or written in the Android Native Development Kit (NDK) to target a specific ISA. Apps written in Java can therefore run on any ISA that Android itself supports, including MIPS. Apps written with the NDK (many of which exist, especially games) cannot run on anything but the specific ISA they were written for. The Android NDK does allows packaging multiple ISA specific binaries into a single app, but with the vast majority of Android devices using ARM processors and therefore the ARM ISA, a multiple NDK Android app is simply uncommon.

What does this mean for an end user? There are many Android apps that simply won’t run if you have a MIPS processor in your device. Intel has the same NDK compatibility problem, but with their considerably larger engineering resources, Intel implemented a layer that translates ARM ISA applications to the Intel x86 ISA (albeit at a performance penalty). Until MIPS implements the same or ships enough volume to convince Android app developers to put in some extra work, a MIPS Android device will unfortunately be a second class experience.

Despite some existing Android app compatibility woes, the MIPS I6400 CPU contains some interesting technology designed to address many more markets than handsets. In fact, Android usage of MIPS processors is really a minor part of the MIPS business. A few slides from the MIPS announcement indicate just how many other markets they are targeting.

Introduction The MIPS I6400 CPU
POST A COMMENT

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. Reply
  • 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...
    Reply
  • 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. Reply
  • 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.
    Reply
  • 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. Reply
  • 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.
    Reply
  • 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 SMT Reply
  • SarahKerrigan - 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.
    Reply
  • 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." Reply
  • 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. Reply

Log in

Don't have an account? Sign up now