http://withimagination.imgtec.com/i...rrior-cpu-cores-the-next-revolution-in-cpu-ip
Not sure if it is enough to make a comeback.
Not sure if it is enough to make a comeback.
If mobile device makers used this CPU or Atom, wouldn't those devices be at a disadvantage running all the mobile apps. which were compiled for ARM?
In the desktop space, competitors to X86 never got any traction because of the software deficit, either not enough native software or poor emulation performance.
So isn't it too late for alternate CPU architectures in the mobile space?
In the desktop space, competitors to X86 never got any traction because of the software deficit, either not enough native software or poor emulation performance.
So isn't it too late for alternate CPU architectures in the mobile space?
For Android, MIPS is healthy. You get MIPS system images by default now, plus toolchain support in the NDK, and if you build for all NDK architectures you get MIPS binaries in the resulting .apk. Obviously for non-native code it's also fine.
I can't comment on other OSes, but we obviously work on them all where we can.
I can't comment on other OSes, but we obviously work on them all where we can.
NDK use may be more common than you think.. for starters, anyone that wants reasonable portability with iOS. And that's really only part of it. I don't know what the total percentage of apps use, but that can be a misleading comfort since what really matters is the number of apps weighted by their popularity and surely a lot of the most popular ones use NDK.
Rys said:
Sure, most apps built using the NDK after a certain date will already have MIPS support. From what I can tell that date is a little over a year ago. For apps before that you're out of luck unless the original developer updates - if the original developers are even active anymore. I can't see this as being a totally unimportant issue. It was at least critical enough that Intel decided to employ binary translation, and they had support longer (by about another year). They also have more money to throw around to try to get devs to update, although I really can't say how invested MIPS will or won't be in doing the same thing.
It's part of the NDK, it's in the APK (as a fat binary) if the developer enables it (I have no idea if it is or isn't by default). The store really doesn't have anything to do with it.
There are many STBs with MIPS cores around,
For example Linux Satellite Receivers
Some of them very popular
STBs are a natural fit, not so much power constrained as phones/tablets, and always price sensitive to components.
So I guess there is a consumer market - There is a market - it might not be so large, but it is nice to have a modern MIPS core around.
Also don’t forget that the Chinese have used a MIPS derivative for HPC. So there is some demand for know-how and integration services
For example Linux Satellite Receivers
Some of them very popular
STBs are a natural fit, not so much power constrained as phones/tablets, and always price sensitive to components.
So I guess there is a consumer market - There is a market - it might not be so large, but it is nice to have a modern MIPS core around.
Also don’t forget that the Chinese have used a MIPS derivative for HPC. So there is some demand for know-how and integration services
You're right, and we've made pretty good inroads into getting developers to add MIPS support to NDK apps, especially games, from what I can tell (haven't been involved directly with that), but we necessarily won't be able to catch them all.
As for binary translation, I'm curious myself; I'll check when I'm back at work next week.
I am curious about how this works. Does the code get compiled for all architectures by default. What if somebody uses ARM intrinsics? Are they translated to equivalent intrinsics for other architectures? How come a date's cutoff is relevant here?
You set APP_ABI in Application.mk. 'all' builds for all, not sure what happens if you use architecture intrinsics but I imagine it'd be a compile failure.
The date cutoff is relevant because non-ARM ABI support has been phased in over time. Actually it's a bit more complicated than that for ARM too, but MIPS and x86 certainly weren't there in the first NDK.
MIPS 64-bit IP launched for phones/tablets
In retrospect the title needs editing, poor choice as it is clearly designed for many other applications than phone/tablet
PR
http://www.imgtec.com/news/detail.asp?ID=923
Blog posting
http://blog.imgtec.com/mips-processors/meet-mips-i6400-warrior-cpu-for-64-bit-computing-revolution
Highlights from the PR.
4 Threads per core
Up to 6 cores can be clustered, cores can work on separate clocks/voltages
Design permits up to 64 clusters.
30-50% perf improvement per core over ARM (err "competitor 64-bit") on similar die area
Unspecified licensees secured across multiple markets.
In retrospect the title needs editing, poor choice as it is clearly designed for many other applications than phone/tablet
PR
http://www.imgtec.com/news/detail.asp?ID=923
Blog posting
http://blog.imgtec.com/mips-processors/meet-mips-i6400-warrior-cpu-for-64-bit-computing-revolution
Highlights from the PR.
4 Threads per core
Up to 6 cores can be clustered, cores can work on separate clocks/voltages
Design permits up to 64 clusters.
30-50% perf improvement per core over ARM (err "competitor 64-bit") on similar die area
Unspecified licensees secured across multiple markets.
D
Deleted member 13524
Guest
Not to mention the fact that this will find no space in the smartphone/tablet market.
Look at how troublesome it was for Intel.. and they're a bottomless pit of money, talent and alien technology.
Servers, render farms, routers and maybe consoles is the most likely scenario
If MIPS becomes popular in the future, we might need to add MIPS SIMD (http://www.imgtec.com/mips/architectures/simd.asp) support in our vector library at some point. Currently it only generates x64 (SSE4/AVX) and ARM (NEON) intrinsics. Hopefully the instruction set is good 
Nebuchadnezzar
Legend
Stephen did a good writeup:
http://www.anandtech.com/show/8457/mips-strikes-back-64bit-warrior-i6400-architecture-arrives
Offers good competition to the A53, but I doubt we'll see silicon for another 2 years.
http://www.anandtech.com/show/8457/mips-strikes-back-64bit-warrior-i6400-architecture-arrives
Offers good competition to the A53, but I doubt we'll see silicon for another 2 years.
Well, there is the multithreading to improve utilization of ALU resources. The blend of cost/efficiency/performance on offer is too much of an unknown to judge the appeal at the moment.
So it looks like the MIPS r6 removes and changes some things. Here's what I could find:
- Packed single float operations
- Trapping arithmetic
- LWC2/STWC2 encodings
- FP (COP1) and COP2 conditional branches (BC*{T/F})
- All "likely" form of branch instructions
- Conditional branch and link instructions (BGEZAL, BLTZAL)
- All mul/div using HI/LO regs (and the move to/from those regs)
- FP reg + reg address load/store
- Unaligned partial load/store (LL/LR, etc)
- FP chained MADDs (replaced with FMA instructions)
- Conditional moves ("replaced" with conditional select zero)
- Prefetch with register + register address
- FP round to integer
And a bunch of instructions have had their encodings moved around.
Most of this is cruft, but not necessarily cruft no one used. I know I used conditional branch/link and conditional moves in code years ago. I guess the plan is to handle compatibility with a mix of load time translation (maybe for the stuff with 1:1 mappings?) and trapped emulation, which I'm sure is not going to be fast. So I guess we can expect yet another NDK target in Android.
According to the AT article, "Additional instructions were also added specifically targeting today’s applications like web browsers." I have no idea what these instructions are supposed to be.
- Packed single float operations
- Trapping arithmetic
- LWC2/STWC2 encodings
- FP (COP1) and COP2 conditional branches (BC*{T/F})
- All "likely" form of branch instructions
- Conditional branch and link instructions (BGEZAL, BLTZAL)
- All mul/div using HI/LO regs (and the move to/from those regs)
- FP reg + reg address load/store
- Unaligned partial load/store (LL/LR, etc)
- FP chained MADDs (replaced with FMA instructions)
- Conditional moves ("replaced" with conditional select zero)
- Prefetch with register + register address
- FP round to integer
And a bunch of instructions have had their encodings moved around.
Most of this is cruft, but not necessarily cruft no one used. I know I used conditional branch/link and conditional moves in code years ago. I guess the plan is to handle compatibility with a mix of load time translation (maybe for the stuff with 1:1 mappings?) and trapped emulation, which I'm sure is not going to be fast. So I guess we can expect yet another NDK target in Android.
According to the AT article, "Additional instructions were also added specifically targeting today’s applications like web browsers." I have no idea what these instructions are supposed to be.
Similar threads
