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

CISC is dead

[jmv]

There are no CISC CPUs anymore. There are RISC CPUs with RISC instruction sets (e.g. ARM) and there are RISC CPUs with CISC instruction sets (e.g. x86). The cores are mostly the same, except that the chips with CISC instructions need to do a little more work in the decoder. It requires a bit extra transistors and a bit more power, but it's not a huge deal for PCs and servers. Of course, for embedded applications, it makes a difference and for those it makes sense to have more "specialised" architectures (from microcontrollers to DSPs, ARM and all kinds of hybrids).

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.

Re:CISC is dead

[Anonymous Coward]

The CPU's in today's IBM Mainframes are based on the POWER archictecture. That makes them technically RISC processors. You're a bit behind the times.

Re:CISC is dead

[hey!]

ok but there's not tons of old main frames running still?

No, there's not lots of old mainframes running still. But there are probably more new mainframes running than when computers were exclusively located in data centers. Back on the day, your chances of working directly with a mainframe, given that you worked with computers, was 1.0; now it's probably more like 0.001. But there's a lot more people working with computers.

Re:CISC is dead

[RzUpAnmsCwrds]

People don't get RISC, and they don't get CISC.

The defining characteristic of CISC is that it assumes that the fetch part of the fetch/execute cycle is expensive. Therefore, instructions are designed to do as much as possible so you need to use as few as possible.

The defining characteristic of RISC is pipelining. RISC assumes that fetches are cheap (because of caches) and thus higher instruction throughput is the goal.

The KEY difference between RISC and CISC isn't the number of instructions or how "complex" they are.

RISC instructions are fixed-size (usually 32 or 62 bits). CISC instructions tend to vary in size, with added words for immediate data and other trimmings.

CISC has lots of addressing modes, RISC tends to have very few.

CISC allows memory access with most instructions. Most RISC instructions operate only on registers.

CISC has few registers. RISC has many registers.

Arguing about whether CISC or RISC is faster is moot. Core 2 isn't fast because it's "CISC" or "RISC", it's fast because it's a very well designed architecture. The fact is, designing ANY competitive CPU today is extraordinarily difficult. RISC made a difference in the early 90s when CISC designs were microcoded and RISC could be pipelined. But most performance CPUs today are vastly different internally.

Re:CISC is dead

[Guy Harris]

The third slide in the presentation clearly states that the Z6 is a sibling of the Power6

As that slide says, "Siblings, not identical twins", "Different personalities", and "Very different ISAs=> very different cores".

Further along in the presentation, slide 14 talks about the use of multiple-passes and millicode to handle CISC ops.

To be precise, it says "Multi-pass handling of special cases" and "Leverage millicode for complex operations"; that means "complex instructions trap to millicode", where "millicode" is similar to, for example, PALcode in Alpha processors - it's z/Architecture machine code plus some special millicode-mode-only instructions to, for example, manipulate internal status registers. See, for example, "Millicode in an IBM zSeries processor".

Clearly the Z6 is exquisitely optimized to execute the z/Architecture instruction efficiently. It is also clear that it is part of the Power6 family.

It's clear that, as the the third slide says, the Z6 "share[s] lots of DNA" with the Power6, i.e. it shares the fab technology, some low-level "design building blocks", large portions of some functional units, the pipeline design style, and many of the designers.

It's not at all clear, however, that it would belong to a family with "Power" in its name, given that it does not implement the Power ISA. If it's a sibling of the Power6, that makes it, in a sense, a member of a family that includes the Power6, but, given that its native instruction set is different from the Power instruction set, it makes no sense to give that family a name such as "Power6" or anything else involving "Power" - and it certainly makes no sense to assert that it's "sed on the POWER archictecture", as the person to whom I was responding asserted.

What the Heck?

[AKAImBatman]

RISC vs. CISC? What is this, the early 90's? There are no RISC chips anymore, except as product lines that were originally developed with the RISC methodology in mind. Similarly, true CISC doesn't exist either. Microcode has done wonders in turning complex instructions into a series of simpler instructions like one would find on a RISC processor.

The author's real point appears to be: x86 vs. Other Embedded Architectures. Without even looking at the article (which I did do), it's not hard to answer that one: There is no need for x86 code in a mobile platform. The hardware is going to be different than a PC, the interface is going to be different than a PC, and the usage of the device is going to be different than a PC. Providing x86 compatibility thus offers few, if any, real advantages over an ARM or other mobile chip.

If Intel's ATOM takes off, it will be on the merits of the processor and not on its x86 compatibility. Besides, x86 was a terrible architecture from the get-go. There's something mildly hilarious about the fact that it became the dominant instruction set in Desktop PCs across the world.

Re:What the Heck?

[AKAImBatman]

Weird. Half the responders disagreed with him and you didn't notice?

RISC design was really, really attractive from an architectural standpoint. It simplified the hardware to such a great degree that it was completely worth the pain and suffering it put compiler writers through. With microcode, even stupid CISC architectures like x86 were able to run on a RISC CPU.

But here's the rub: It is always slower to use multiple instructions to complete a task that could be completed in a single instruction with dedicated silicon.

With that simple fact in mind, it didn't take long for CISC-style instructions to start reappearing in the silicon designs. Especially once the fab technologies improved enough to negate the speed advantages in early RISC chips. (e.g. Alpha seriously kicked ass back in the day.) Chip designers like Intel took note of what instructions were slowing things down and began adding them back into the silicon.

Thus the bar moved. Rather than trying to keep the silicon clean, the next arms race began over who could put fancier vector instructions into their CPUs. Thus began the war over SIMD instructions. (Which, honestly, not that many people cared about. They are cool instructions, though, and can be blazingly fast when used appropriately.)

An interesting trend you'll notice is that instructions take more or fewer instructions to execute between revisions of processors. (Especially with x86.) Part of this is definitely changes in the microcode and CPU design. But part of it is a re-evaluation of silicon usage. Some instructions which used to be fast thus become slow when they move to microcode, and some instructions that were slow become fast when they move to silicon.

Rather interesting to watch in action. :-)

Completely pointless

[El Cabri]

RISC vs CISC was the architecture flamewar of the late 1980s. Welcome to the 21th century, you'll like it here. It's a world when, since the late 90s, the ISA (instruction set architecture), is so abstracted away from the actual micro-architecture of microprocessor, as to make it completely pointless to make distinctions between the two. Modern processors are RISC, they are CISC, they are vector machines, they're everything you want them to be. Move on, the modern problems are now in multi-core architecture and their issues of memory coherence, cache sharing, memory bandwidth, interlocking mechanisms, uniform vs non-uniform, etc. The "pure RISC" standard bearers of yore have disappeared or have been expelled from the personnal computing sphere (remember Apple ditching PowerPC ? Alpha anyone ? Where are those shiny MIPS-based SGIs gone?). Even Intel couldn't impose a new ISA on its own (poor adoption of IA-64). The only RISC ISA that has any existence in the personnal computing arena, including mobile, is ARM, but precisely, they do only mobile. There's really no reason at all to build any device on which you plan to run generic OSes and rich computing experience on anything else than x86 or x86-64 machines.

Re:Completely pointless

[vought]

Not in disagreement, but Apple didn't ditch PowerPC because RISC offered no performance advantage; indeed, the G5 at lower clock speeds marginally outperformed the first Intel-based Macs at the same price points.

Apple got rid of PowerPC because Motorola and IBM had no incentive to innovate and develop competitive processors in the mid-range; RISC was most worthwhile in the high-end big iron IBM machines using POWER and the low end embedded market served by Motorola/Freescale.

Re:Completely pointless

[prockcore]

The PowerPC is nothing without the AltiVec vector unit, which is a decidely CISC concept.

CISC is alive and well and so is RISC

[erice]

They just aren't very important distinctions anymore.
Both refer to the instruction sets, not the internal workings. x86 was CISC in 1978 and it's still CISC in 2008. ARM was RISC in 1988 and still RISC in 2008. AMD64 is a border line case.

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's how most CISC processors work. RISC process rarely use anything like microcode and when they do, it is looked upon as very unRISCy.

Today, the internals of RISC and CISC processors are so complex that the almighty instruction set processing is barely a shim. There are still some advantages to RISC but they are dwarfed by out-of-order execution, vector extensions, branch prediction and other enormously complex features of modern processors.

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.

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.

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.

Spotting those who RTFA'd

[Jacques Chester]

Every 4+ comment has the same "RISC|CISC is dead" comment talking about how x86 chips break down that massive, warty ISA into a series of RISC-like micro-ops for internal consumption. And that this has been the case since at least the Pentium Pro.

Read the article. Jon Stokes makes that point: but he also makes the point that in embedded processors, it does matter, because the transistor budget is much, much smaller than for a modern desktop CPU. It may come to pass in a few generations of die feature shrinking that we arrive back at the current situation of ISAs becoming irrelevant, but for the moment in the embedded space it does matter that you need to give up a few million transistors to buffering, chopping up and reissuing instructions compared to just reading and running them.

Remember, this is Jon Stokes we're talking about: he's the guy that taught most Slashdotters what they know about CISC and RISC as it is.

Re:Looks like microcode, smells like microcode,...

[Waffle Iron]

Modern CPUs "translating instructions into hardware instructions" with a gate maze is essentially the same thing as pulling a wide microcode word from ROM whose bits directly control the logic units.

Only if you ignore the mechanism of how it's done. However, the term "microcode" was created to describe the mechanism, not the result.

Under your definition, it would appear any division of an instruction into multiple suboperations would qualify as microcode. That would presumably include the old-time CPUs that used state machine sequencers made from random flip flops and gates to run multi-step operations.

The end result of those state machines was the same as microcode, and the microcode ROM (which included the next ROM address as part of the word) was logically a form of state machine. However, the word microcode was used to differentiate a specific type of state machine, where the logic functions were encoded in a regular grid-shaped ROM array, from other types of state machines. Modern CISC code translation does not involve ROM encoding, and is not this type of state machine.