Could MIPS be a threat to ARM and x86?

[lamedude]

PSX>3DO therefore MIPS>ARM.😉

 

[denev2004]

These days, with code being so portable and written in high-level languages, whoever can deliver the cheapest, and most power-efficient processors wins.

Funny isn't it, how we had the big RISC versus CISC (ie: x86) wars in the 1990s, and RISC was supposed to win, but we're still all running Intel CPU's, and the instruction set is more bloated than its ever been?

Yeah that sounds interesting.

BTW I got a question to ask. Someone told me Android's software is totally based on JIT, means an x86-Android can run all the software that are capable running on an ARM-Android. Is that correnct? If that's true, now MIPS has something which can help them.

 

[ElFenix]

These days, with code being so portable and written in high-level languages, whoever can deliver the cheapest, and most power-efficient processors wins.

Funny isn't it, how we had the big RISC versus CISC (ie: x86) wars in the 1990s, and RISC was supposed to win, but we're still all running Intel CPU's, and the instruction set is more bloated than its ever been?

RISC vs. CISC has nothing to do with the number of instructions. it has to do with the complexity of the instructions themselves. RISC instructions, ideally, do exactly one thing. CISC (which is just a backward made up term after the term RISC became common) instructions would do things like LOAD then ADD then STORE with just one instruction. RISC would take 3 instructions to do that.

 

[Blitzvogel]

I didn't know that Loongson was MIPS derived/based/whatever....

And this in the wiki article:

Loongson 3B
The updated 8-core 65nm Loongson 3B processor runs at 1.05 GHz, with a peak performance of 128 GFLOPS double-precision, or 256 GFLOPS single-precision.[10] This is accomplished by having two 256-bit vector processing units in each core. They produce a peak performance of 8 double-precision floating-point fused Multiply-Add results per cycle, or 16 GFLOPS per core operating at 1 GHz. The Godson-3B has exceptional energy efficiency in terms of performance per watt -- executing 128 GFLOPS using 40 watts.

HOLY **** 128 GFLOPS double precision?! Are they trying to negate the need for a graphics processor by focusing so much on vector unit throughput? And how much room do those vector units take up leaving little for everything else? It's like the Emotion Engine on steroids.

 

[nenforcer]

Yeah that sounds interesting.

BTW I got a question to ask. Someone told me Android's software is totally based on JIT, means an x86-Android can run all the software that are capable running on an ARM-Android. Is that correnct? If that's true, now MIPS has something which can help them.

Android APPS are programmed in essentially Java which is run on a Davlik Virtual Machine which is nearly identical to Java Byte Codes.

However, the backend and operating system itself is based on open source Linux hence you have projects such as Android x86

http://www.android-x86.org/

which are porting the original ARM backed to x86.

Now only if MIPS had this amount of software support you would see it on more devices.

 

[Tuna-Fish]

HOLY **** 128 GFLOPS double precision?! Are they trying to negate the need for a graphics processor by focusing so much on vector unit throughput?

No. Loongson 3B is explicitly designed for supercomputer use, for fluid simulations and the like. For these loads, FLOPS are *the* thing they want. Everything else is (necessary) overhead.

 

[ncalipari]

Android APPS are programmed in essentially Java which is run on a Davlik Virtual Machine which is nearly identical to Java Byte Codes.

However, the backend and operating system itself is based on open source Linux hence you have projects such as Android x86

http://www.android-x86.org/

which are porting the original ARM backed to x86.

Now only if MIPS had this amount of software support you would see it on more devices.

Android for MIPS already exist: http://developer.mips.com/android/ and it can be ported to any OOO architecture.

The problem is that the java machine for android contains some critical tuning for ARM neon architecture. On x86 and other architecture you end up with lower perfomance, poor battery and possibly with crashing (ANR Error).

We need someone to invest a huge amount of money on improving the JVM for x86 or MIPS. Oracle will not do it, and Google is worried with the explosion of cost of android development, so....

 

[CTho9305]

Yeah that sounds interesting.

BTW I got a question to ask. Someone told me Android's software is totally based on JIT, means an x86-Android can run all the software that are capable running on an ARM-Android. Is that correnct? If that's true, now MIPS has something which can help them.

I think apps can use native code (i.e. ARM) if they want - I've heard that Angry Birds is not available for x86 Android devices. I think I recently saw some stuff about ARM trying to get developers to increase the use of native code (for obvious reasons).

 

[hooflung]

Not only does MIPS Android exist, but there are actually thousands units already sold on the market. A lot of those cheap android e-readers actually have a MIPS cpu inside.

 

[TuxDave]

Actually new Intel Processors are RISC when you get to the heart of it, x86 is still "CISC" but it gets decoded into RISC. If intel allowed us to program in whatever micro-op language they use, you could bypass the decode stage. Though this is incredibly impracticable because it generally changes with every new architecture.

This is probably one huge advantage of having it this way. That way programmers don't have to deal with the fact that different architectures will want to do certain code in different ways. We have put in hardware here and there to reduce the # of micro-ops to improve performance for the same instruction. You don't get to see it and you probably don't want to see it.

Generally speaking, from what I heard software usually recompiles once for a major uArch revision (Tocks) and rarely do so for Ticks. So we just need programs to adopt the new instructions and then we can continue improving the microcode to make it faster.

 

[exdeath]

From my work on Gameboy Advance I prefer ARM over MIPS or x86. It's just a more fun instruction set. I especially enjoyed the optional 4th operand giving a free post instruction logical/shift/mask operation available on just about every instruction. Then the flexibility of Thumb mode, etc, ARM can't be beat IMO, it's the best ISA from an assembly junky perspective.