Imagination Tech Announces MIPS-based 'Warrior P-Class' CPU Core

MojoKid writes "Imagination Technologies has announced the first CPU based on its new version of the MIPS architecture. The new P5600 chip (codenamed Warrior) is a 32-bit CPU based on the MIPS Series 5 architecture and is designed to challenge companies like ARM in the embedded and mobile markets. Major features of the new chip include: support for 40-bit memory extensions, or up to 1TB of RAM, a 128-bit SIMD engine (Single Instruction, Multiple Data), and Hardware virtualization (MIPS R5 can virtualize other machines in hardware). The P5600 core is being touted as supporting up to six cores in a cache-coherent link, most likely similar to ARM's CCI-400. According to IT, the chip is capable of executing 3.5 DMIPs/MHz in CoreMark, which theoretically puts the P5600 on par with the Cortex-A15."

Comments

Re:32 bit?

[jockm]

It depends what you are doing. I don't think anyone is making servers or desktops out of this, and even with recent forays into 64bit ARM (Apple's A7 for example) 32 bit is far from dead. That being said MIPS64 has been around for quite a while, so I don't think it will be a problem to adapt to it at some point in the future.

In before the haters

[Rinikusu]

COMPETITION IS GOOD.

I'd love to see MIPS make a comeback. I've been looking for one of the looongson (?) netbooks for awhile now, just so I can have a MIPS Linux box to play with, but those seem hard to come by.

MIPS never went away, but why?

[Anonymous Coward]

You can still find plenty of MIPS based embedded cpus but they're getting more and more obscure.

One of my very favorite things about the "smartphone revolution" is the proliferation of cheap ARM based SoCs. For a couple of bucks you can get a complete system in a package that runs on a couple of watts and runs circles around a high end workstation from a decade ago. (It's hard to belive 2003 was a decade ago.) And these aren't crippled micros. They're complete systems that run a real full fat operating system. Just look at the raspberry pi. Memory management On package DDR memory. Frame buffer with openGL aclleration and hardware video decoding. Amazing stuff.

Point is, arm is everywher, easy, and cheap. What's the benefit of going MIPS? (Or SH3, or PPC..)

Re:MIPS never went away, but why?

[Anonymous Coward]

It is not the problem of architecture but rather of MIPS company. I have worked on MIPS for many years and still do. MIPS architecture is not worse than ARM in any respect but MIPS company does not promote the architecture and therefore there are no inexpensive boards available. PIC32 is MIPS architecture but without the MMU. I found that when implemented correctly performance of MIPS is on par with ARM per MHz but ARM can clock higher in most common implementations. There is a perception of MIPS being slower or more power hungry. In my experience this is not the case. I also like architecture itself. It is very clean and with modern additions it has all of the tricks that ARM has.
If MIPS company would promote its chips the same way as ARM does it would be just as popular with the hobby crowd. MIPS is used in many devices - cars, settop boxes, routers, etc. It is just not popular in the DYI community due to absence of cheap hardware.

Re:32 bit?

[Anonymous Coward]

Go to ARM.com, try and download the ARM ISA, fail, sign NDA, get ISA.

Go to MIPS.com, download MIPS64 ISA, done.

Tell me again how ARM is more open than MIPS?

Re:32 bit?

[fuzzyfuzzyfungus]

In either case, the main stumbling block to 'openness' (from the perspective of people who don't have the cash to implement a core and get it fabbed, or even buy a run of a pre-cooked design, and don't want to enjoy the pleasures and efficiencies of implementing their CPU in an FPGA) isn't really the CPU ISA; but the fact that the SoCs you can actually buy tend to be coupled with GPUs that make Nvidia look like a model of transparency and AMD a model of driver-writing competence.

If memory serves, the rPi's SoC depends on a fairly massive binary blob driver and a 'VideoCore 4' GPU thing that is right up to Broadcom's usual standards for openness in documentation, which is presumably what the grandparent poster doesn't like.

Most of the punchier ARM options aren't a whole lot better (though some of them are somewhat less weird). Certainly, given that Imagination Technologies is already a supplier of GPU architectures to ARM licencees (and occasionally Intel), I'd assume that any MIPS SoCs you end up being able to buy will be approximately as bad as the ARM scene, maybe a bit worse.

Now, if you do want to bake your own CPU, MIPS64 is probably a better option (though don't they still have a few patented instructions? I vaguely remember some flap concerning the legal status of that Chinese MIPS-and-national-pride CPU a few years back...)

Re:32 bit?

[tlhIngan]

and even with recent forays into 64bit ARM (Apple's A7 for example) 32 bit is far from dead.

The main reason Apple with with ARMv8 (the big difference between ARMv7 and ARMv8 is basically 64-bit) is that the 64-bit architecture (AArch64) is way more efficient than 32-bit (AArch32). It's a lot easier to speed up the 64-bit system as it gets rid of a lot of legacy AArch32 features that get in the way of a modern superscalar design CPU.

Surprisingly, things like conditional execution, great back in the 80s, are painful these days with heavy pipelining, register renames, speculative sxecution and superscalar multi-issue back ends. Think about it - the only way to find out if you need to retire the instruction to the architecture registers is at the end when you find out if the instruction should've been executed.

And AArch64 has few other improvements to make it scale better in the future.

Apple went 64-bit not because they planned on putting 4GB of RAM in an iPhone, but because they needed the speed. That's why everything's 64-bit - you're able to take advantage of the speed up and efficiencies AArch64 has.

ARMv8 processors running 32-bit code aren't much faster than their ARMv7 counterparts. But the 64-bit code runs significantly faster.

MIPS is a better choice anyway

[AaronW]

MIPS provides a much cleaner upgrade path going forward than ARM. MIPS64 is a very clean extension to MIPS32. All of the MIPS32 instructions behave the same except that they are sign extended to 64-bit. 64-bit ARM on the other hand has almost nothing in common with ARM32. The instruction encoding is totally different. The register definitions are also completely different. A lot of the things that made ARM ARM are gone such as conditional execution.

I have spent many years working with MIPS and the last three working for a 64-bit multi-core MIPS manufacturer. MIPS also allows for clean extensions to the instruction set by various vendors, something ARM does not allow. For example, my employer has added a lot of instructions using coprocessor 2 (COP2) to add encryption, hashing, CRCs and more without breaking standard MIPS compatibility since COP2 is typically reserved for vendor extensions.

MIPS page tables are also interesting. They are entirely managed by software, allowing the operating system to use whatever format they want for them. While some vendors have added hardware walkers they typically don't make much difference in performance.

MIPS32 is fairly old and many implementations don't provide cache coherency which is a pain in the butt and impacts performance but the ones I deal with (Cavium's OCTEON processors) are fully cache coherent.

As for doing encryption in the instruction set it allows full acceleration in user space without needing to deal with descriptors or DMA or userkernel transitions.

Perhaps the only thing I would get rid of is the branch delay slot. It no longer really buys anything. The MIPS tools are much more mature than ARM, especially for 64-bit support. There are 32 general purpose registers with register 0 always being 0.

With ARM64 most of the interesting ARM features are gone and in fact it looks a lot more like MIPS except that the instruction decoding is a lot more complicated. MIPS hasn't been standing still either. Extensions have been added for things like virtualization, 16-bit instructions (like Thumb) which usually don't buy you much and some multimedia extensions.

I periodically work on MIPS assembly language with some of the bootloader stuff I do. All I can say is it's a joy to work with compared to X86 and is quite elegant. It's nice when I can have just a couple dozen lines of assembly language put a stack in cache memory and go straight to 64-bit C code. At this point it's quite hard for me to beat recent versions of GCC when it comes to optimizing code.

I don't know why they're limiting their Warrior P-Class CPU core to 32-bits though. Moving to 64-bit MIPS is not very difficult. Personally I'd love to see 32-bit MIPS go away and just do 64-bit MIPS and use either the N32 or N64 ABI. N32 runs in 64-bit mode but with 32-bit addressing so you get all the advantages of 32-bit pointers and 64-bit registers.

My employer makes MIPS processors with up to 32 cores and soon will have 48 cores and fully support Linux.