RISC Vs. CISC In Mobile Computing

eldavojohn writes "For the processor geeks here, Jon Stokes has a thoughtful article up at Ars Technica analyzing RISC vs. CISC in mobile phones (Wikipedia on Reduced Instruction Set Computers and Complex Instruction Set Computers). He wraps it up with two questions: 'How much is the legacy x86 code base really worth for mobile and ultramobile devices? The consensus seems to be "not much," and I vacillate on this question quite a bit. This question merits an entire article of its own, though,' and 'Will Intel retain its process leadership vs. foundries like TSMC, which are rapidly catching up to it in their timetables for process transitions? ARM, MIPS, and other players in the mobile device space that I haven't mentioned, like NVIDIA, AMD/ATI, VIA, and PowerVR, all depend on these foundries to get their chips to market, so being one process node behind hurts them. But if these RISC and mobile graphics products can compete with Intel's offerings on feature size, then that will neutralize Intel's considerable process advantage.'"

Comments

Re:CISC is dead

[RecessionCone]

Actually, have you heard of micro-op and macro-op fusion? Intel is touting them as a big plus for their Core microarchitecture: basically, they take RISC internal instructions and fuse them into CISC internal instructions (micro-op fusion) and also take sets of CISC external instructions and fuse them into CISC internal instructions (macro-op fusion).

So basically, things are so much more complicated these days that you can't even call x86 chips RISC CPUs with CISC instruction sets.

We're in a post-RISC era.

There are very few RISC, but there are some

[EmbeddedJanitor]

Mostly little 8-bitters (PIC and AVR), but there are many processors that tend towards the RISC end of the spectrum (ARM, MIPS etc) which clearly have RISC roots. ARM, MIPS etc dominate in mobile space because they switch less transistors to achieve the same function (one of the goals of RISC design) and thus use less power.

The only real point in x86 is Windows compatability. Linux runs fine on ARM and many other architectures. There are probably more ARM Linux systems than x86-based Linux systems (all those Linux cellphones run ARM).

Apart from some very low level stuff, modern code tends to be very CPU agnostic.

Re:CISC is alive and well and so is RISC

[Waffle Iron]

People get confused with the way current x86's break apart instructions into microops. That's doesn't make it RISC. That just make it microcoded.

That most certainly does not make it microcoded. Microcode is a set of words encoded in ROM memory that are read out one per clock, whose bits directly control the logic units of a processor. Microcode usually runs sequentially, in a fixed order, may contain subroutines, and is usually not very efficient.

Modern CISC CPUs translate the incoming instructions into a different set of hardware instructions. These instructions are not coded in a ROM, and they can run independently, out of order and concurrently. They are much closer to RISC instructions than to any microcode.

The X86 still contains real microcode to handle the stupid complex instructions from the 80286 era that nobody uses anymore. They usually take many clocks per instruction, and using them is not recommended.

RTFA much?

[tepples]

The problem these days is that it doesn't actually cost anything to have a complex instruction format. It's such a tiny, isolated piece of the chip that it doesn't count for anything Did you understand the article? Page 2 is entirely about how the decoder on Atom isn't "such a tiny, isolated piece of the chip that it doesn't count for anything".

And, it turns out, you need to have a RMW style instruction anyway, even if you are RISC, if you want to have any hope of operating in a SMP environment. But if only one instruction is an atomic swap, that means it doesn't need to be on the critical path, right?

You all miss the point.

[Anonymous Coward]

""
The problem these days is that it doesn't actually cost anything to have a complex instruction format. It's such a tiny, isolated piece of the chip that it doesn't count for anything, it doesn't even slow the chip down because the chip is decoding from a wide cache line (or multiple wide cache lines) anyway.
""

The problem with your assumption is that it's _wrong_.

It does cost something. The WHOLE ARTICLE explains in very good detail the type of overhead that goes into supporting x86 processors.

The whole point of ATOM is Intel's attempt to make the ancient CISC _instruction_set_ work on a embedded style processor with the performance to handle multimedia and limited gaming.

The overhead of CISC is the complex arrangement that takes the x86 ISA and translates it to the RISC-like chip that Intel uses to do the actual processing.

When your dealing with a huge chip like a Xeon or Core2Duo with a huge battery or connected directly to the wall then it doesn't matter. Your taking a chip that would use 80watts TPD and going to 96.

But with ARM platform you not only have to make it so small that it can fit in your pocket, but you have to make the battery last at least 8-10 _hours_.

This is a hell of a lot easier when you can deal with a instruction set that is designed specifically to be stuck in a tiny space.

If you don't understand this, you know NOTHING about hardware or processors.