MIPS Series5 Now Official

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?
 
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.
 
android has the advantage that most apps are java and dont care for the architecture. But thats only half the thruth I guess, support for mips still is lackin in llvm and other important tools which are at least as important as software.
 
Yes, that's half the truth :) For Android, you have to ensure Dalvik (Java) and v8 (Javscript) generate good code and this can take a large amount of time. On v8 there's been public activity for months, and I guess it's the same for Dalvik.
 
android has the advantage that most apps are java and dont care for the architecture. But thats only half the thruth I guess, support for mips still is lackin in llvm and other important tools which are at least as important as software.

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:
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.

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.
 
But does the Google Play store distribute fat or MIPS binaries of those apps?

I guess they could if MIPS or Atom gains significant installed bases.
 
But does the Google Play store distribute fat or MIPS binaries of those apps?

I guess they could if MIPS or Atom gains significant installed bases.

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
 
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.
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.
 
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.

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?
 
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


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
 
Are there plans for fatter cores? Dual issue in-order seems a little unambitious even for mobile or low power server segments.

Cheers
 
Are there plans for fatter cores? Dual issue in-order seems a little unambitious even for mobile or low power server segments.

Cheers

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.
 
Back
Top