Imagination Technologies Acquires MIPS

Imagination said:
Patent Portfolio sale

MIPS has also entered into a definitive acquisition agreement with Bridge Crossing LLC, whereby Bridge Crossing LLC is to acquire 498 out of 580 of MIPS' patent properties for US$350 million in cash in a separate transaction that will complete before Imagination's proposed acquisition of MIPS completes.

Interesting. ARM Holdings is one of the main members of Bridge Crossing LLC. I believe ARM alone is paying 167,5 million of that $350 million.
Here is a linky to that: http://www.arm.com/about/newsroom/a...ights-to-mips-technologies-mips-portfolio.php
 
Last edited by a moderator:
I really hope they`ll push the mips architecture. I cant stand the x86 isa and ARM surely aint a beauty either (though their 64bit ISA is an improvement and a radical departure), both dont deserve their respective dominance.
yay for 32 and 64 bits programs without mode switches, having a nice architecture 30 years ago and not duct-taped over
 
What's so beautiful about MIPS? Not even having register + register address modes is pretty weak.. and if you want to talk microarchitectural warts that made it into the ISA there's always delay slots...
 
Yeah, delay slots are horrible. OTOH Alpha was pretty nice. But I find ARMv8 Aarch64 even nicer, though I am heavily biased.

BTW non Aarch64 ARM also has a nice microarchitectural detail that made it into the architecture: the value of the PC when you read it :)
 
What's so beautiful about MIPS? Not even having register + register address modes is pretty weak.. and if you want to talk microarchitectural warts that made it into the ISA there's always delay slots...

Its 160 experienced engineers just a couple of blocks away from IMG's US engineering department maybe? :p

On an unrelated note, does anyone know if Shenzhen in China is some sort of "silicon valley"?
 
Its 160 experienced engineers just a couple of blocks away from IMG's US engineering department maybe? :p

On an unrelated note, does anyone know if Shenzhen in China is some sort of "silicon valley"?

I bought a cheapo Android tablet from a company in Shenzhen earlier this year and many of the sellers on Aliexpress who supply technology are based in this city.

Looks as though it is some sort of 'Silicon Valley' by design:

http://en.wikipedia.org/wiki/Shenzhen#Industrial_zones
 
Its 160 experienced engineers just a couple of blocks away from IMG's US engineering department maybe? :p

I was asking what's beautiful about the MIPS ISA, ie in response to Npl who was hoping that MIPS CPUs would still be available because the ISA is a lot nicer than x86 or ARM.
 
What's so beautiful about MIPS? Not even having register + register address modes is pretty weak.. and if you want to talk microarchitectural warts that made it into the ISA there's always delay slots...
It allows for parallelism. decoding ops is almost trivial, as it uses only a handful opcode formats. What I mean is, that you can pretty much start fetching registers without decoding the op.
No additional decencies like status registers or flags, rather easy out-of order/super-scalar operation.
Usefull synchronization primitives (ll/sc) since the early nineties (I`m stuck with an recent soc using Armv5 and swp - what a horror).
No ugly do this, if some bit is set do that, then do something else depending on what register you use (thinking of arms load/store multiple, does different things depending if you read/write the PC register. different modes when you are in an ISR - worst bit-but-ing possible).
32bit isa is a subset of 64bit isa

If you look at how isas devolved (at keast internally), most converge toward MIPS-like (except with 20+ years legacy crap on top).

So what are the wharts on Mips.
1) branch delay slots arent a problem for me, both for writing code, neither for parrallelism. They still help if you have an in-order CPU, and are easy to figure out out-of-order
2) seperate multiply/divide units. this is painfull do use and implement. The only annoyance for me.
3) no complex addressing modes - what for? just use 2 instructions, or an macro if you write in assembly. Neither a problem in in-order or out-of-order. Keeps the isa clean.
 
It allows for parallelism. decoding ops is almost trivial, as it uses only a handful opcode formats. What I mean is, that you can pretty much start fetching registers without decoding the op.

Registers in ARM tend to be in the same fixed locations too. The question is, in any reasonably modern design would you actually want to start fetching operands that you might not even use?

No additional decencies like status registers or flags, rather easy out-of order/super-scalar operation.

Coprocessor registers don't count as status registers? They needn't be any more tightly integrated on ARM CPUs per se..

Flags have their positive sides too. They save read/write ports on the main register file and save on the space you need to rename into. And they save on needing to address registers for comparison on conditional branches, which take away from displacement bits.

It's a headache to have instructions that only partially update the flags though, which is probably why they rectified this for AArch64.

Usefull synchronization primitives (ll/sc) since the early nineties (I`m stuck with an recent soc using Armv5 and swp - what a horror).

I shudder to think what SoC is using ARMv5 but can be considered "recent", is it from Chinachip or something? :/ I'm not counting Atmel or Freescale products that were made forever ago but are still being sold..

No ugly do this, if some bit is set do that, then do something else depending on what register you use (thinking of arms load/store multiple, does different things depending if you read/write the PC register. different modes when you are in an ISR - worst bit-but-ing possible).

Checking if (s == 1b) && (rd == 1111b) hardly seems like a huge decoding burden. There's no special function for reading PC. You could argue MIPS has a special function for writing r0.

Don't know what you mean by different modes in an ISR, except that the register file is muxed, but it's not like the instructions do different things...

32bit isa is a subset of 64bit isa

Yeah, they could afford to do that because they underutilized the opcode space so badly.

If you look at how isas devolved (at keast internally), most converge toward MIPS-like (except with 20+ years legacy crap on top).

I don't buy this. Some have called AArch64 a MIPS clone but I think it offers plenty that MIPS fails to.

1) branch delay slots arent a problem for me, both for writing code, neither for parrallelism. They still help if you have an in-order CPU, and are easy to figure out out-of-order

They don't really help you at all if you have branch prediction, regardless of if you're in-order or not. You'll never fully utilize them and when you don't they waste code. CPU designers now tend to see them as an unfortunate consequence of the times at best and a mistake at most, but either way useless now.

3) no complex addressing modes - what for? just use 2 instructions, or an macro if you write in assembly. Neither a problem in in-order or out-of-order. Keeps the isa clean.

I think you mean three instructions, to do [reg + (reg * shift)]. You can't seriously be arguing that it doesn't matter if a sequence takes more instructions. Think of all the logic you need to try to make a sequence of three instructions dispatch in one cycle, and even if you can you still burn the fetch bandwidth and L1 space.
 
IIRC some Marvell chips are still based on ARMv5.

It would appear to only apply to ARMADA 100 series, and since the product brief is from 2009 I don't think they're recent SoCs.. of course you can buy PXA3xx XScales from them too but those are even older.
 
It would appear to only apply to ARMADA 100 series, and since the product brief is from 2009 I don't think they're recent SoCs.. of course you can buy PXA3xx XScales from them too but those are even older.
Many NAS used (use?) Feroceon which is a v5 chip. Also Armada 300 seems to use Sheeva which is v5 too.
 
Many NAS used (use?) Feroceon which is a v5 chip. Also Armada 300 seems to use Sheeva which is v5 too.

Sheeva is a family name and isn't strictly ARMv5, for instance:

http://www.marvell.com/application-processors/armada-600/assets/armada618_pb.pdf

It's hard to tell what uses what though, for instance in the case of ARMADA 500..

I guess my question is this: are there any SMP capable ARM SoCs that are stuck with v5? Or am I mistaken in my expectation that the synchronization primitives added in v6 (ldrex/strex) are mainly useful for true SMP concurrency?
 
Registers in ARM tend to be in the same fixed locations too. The question is, in any reasonably modern design would you actually want to start fetching operands that you might not even use?
You can start fetching, and abort later. its not like this happens in a single clock-cycle anyway
Coprocessor registers don't count as status registers? They needn't be any more tightly integrated on ARM CPUs per se..
Yeah, I wasnt talking about anything else but the ALU-operation. You dont touch too much on the COP0 side unless you are doing privileged stuff
Flags have their positive sides too. They save read/write ports on the main register file and save on the space you need to rename into. And they save on needing to address registers for comparison on conditional branches, which take away from displacement bits.

It's a headache to have instructions that only partially update the flags though, which is probably why they rectified this for AArch64.
all by adding more complexity for the decoder
I shudder to think what SoC is using ARMv5 but can be considered "recent", is it from Chinachip or something? :/ I'm not counting Atmel or Freescale products that were made forever ago but are still being sold..
were running i.mx28`s here its an ARM9 core... which uses the Armv5 ISA (which is what i meant). Launched in 2010.

Checking if (s == 1b) && (rd == 1111b) hardly seems like a huge decoding burden. There's no special function for reading PC. You could argue MIPS has a special function for writing r0.

Don't know what you mean by different modes in an ISR, except that the register file is muxed, but it's not like the instructions do different things...
writing the CPSR conditionally?

Yeah, they could afford to do that because they underutilized the opcode space so badly.
err... what is missing? I`d rather think its the only arch that thought about a clean 64bit transition early enough. Actually I think they got alot things right, or atleast right enough while the rest had to undergo tons of drastic changes.
I don't buy this. Some have called AArch64 a MIPS clone but I think it offers plenty that MIPS fails to.
Not a clone, but it moved a rather big step from arm32 in mips direction.
They don't really help you at all if you have branch prediction, regardless of if you're in-order or not. You'll never fully utilize them and when you don't they waste code. CPU designers now tend to see them as an unfortunate consequence of the times at best and a mistake at most, but either way useless now.
Useless at best, but its no biggies swapping 2 instructions in the stream.
I think you mean three instructions, to do [reg + (reg * shift)]. You can't seriously be arguing that it doesn't matter if a sequence takes more instructions. Think of all the logic you need to try to make a sequence of three instructions dispatch in one cycle, and even if you can you still burn the fetch bandwidth and L1 space.
doubt it matters too much in something like memory access which will sit in the queue anyway.
Certainly not as bad as having to read 32bit immediates from memory instead of setting them with 1 or 2 instructions.
 
I think you should get more info about Aarch64, it really is far from MIPS and in some aspects farther than previous ARM ISA.

BTW, ARMv6T2 introduced a way to load a 32-bit imm in 2 instructions.
 
Sheeva is a family name and isn't strictly ARMv5, for instance:

http://www.marvell.com/application-processors/armada-600/assets/armada618_pb.pdf

It's hard to tell what uses what though, for instance in the case of ARMADA 500..
This looks like an interesting read. What a mess...

I guess my question is this: are there any SMP capable ARM SoCs that are stuck with v5? Or am I mistaken in my expectation that the synchronization primitives added in v6 (ldrex/strex) are mainly useful for true SMP concurrency?
You mean SWP isn't enough? :p
 
I guess my question is this: are there any SMP capable ARM SoCs that are stuck with v5? Or am I mistaken in my expectation that the synchronization primitives added in v6 (ldrex/strex) are mainly useful for true SMP concurrency?
They are usefull for any threaded environment, unless you want to disable interrupts (kinda expensive from a nonprivileged thread).
Guess what I want to say is, that for Mips you have a solution for this since the early nineties... for arm its been done in the last ten years, and you still have lines of v5 stuff been sold.
 
You're right, I was thinking to disable interrupts around critical sections but I forgot that this was expensive. This along with cache maintenance operations also being system only can be problems with ARM. At least the latter is fixed in AArch64. The former is probably moot with proper synchronization now..

That's not to say allowing interrupt disabling from user mode is really an acceptable idea.. I wonder if there could be a reasonable alternative? Like a bit you can quickly set that the OS can read, maybe with an associated timestamp, to tell it not to switch your thread for some window of time? I guess the whole thing is pretty messy and problematic :/
 
Back
Top