Forgot your password?
typodupeerror
Hardware

RISC Vs. CISC In Mobile Computing 126

Posted by kdawson
from the comin'-around-again-on-the-guitar dept.
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.'"
This discussion has been archived. No new comments can be posted.

RISC Vs. CISC In Mobile Computing

Comments Filter:
  • CISC is dead (Score:5, Insightful)

    by jmv (93421) on Monday May 19, 2008 @07:56PM (#23469032) Homepage
    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).
    • by gangien (151940)
      i believe the hardware that mainframes run on would be classified as a CISC (ESA/390 i think?), which aren't dead. Not by a long shot, unfortunately.
      • Re: (Score:3, Informative)

        by 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.
        • by gangien (151940)
          ok but there's not tons of old main frames running still?
          • Re:CISC is dead (Score:4, Informative)

            by hey! (33014) on Monday May 19, 2008 @09:33PM (#23469796) Homepage Journal

            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.
        • by Guy Harris (3803)

          The CPU's in today's IBM Mainframes are based on the POWER archictecture.

          Not according to an IBM slide presentation on the Z6 microprocessor [ibm.com], which is the latest processor for the z/Architecture machines (the machines that are descendants of the System/360 mainframes).

          The AS/400^WiSeries^WSystem i midrange machines do use PowerPC processors, but they're different from the z/Architecture machines.

    • Re:CISC is dead (Score:5, Informative)

      by RecessionCone (1062552) on Monday May 19, 2008 @08:22PM (#23469238)
      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.

      • We're in a post-RISC era.
        You know you've been on Slashdot too long when you see a statement like this and immediately try to make a "post-Columbine era" joke out of it.
    • by erice (13380) on Monday May 19, 2008 @08:28PM (#23469268) Homepage
      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.
      • by Waffle Iron (339739) on Monday May 19, 2008 @09:08PM (#23469580)

        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.

        • 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 concurrentl

          • by Waffle Iron (339739) on Tuesday May 20, 2008 @03:29AM (#23472124)

            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.

            • Not quite (Score:3, Informative)

              by MarkusQ (450076)

              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

              While this was by far the most common sort of implementation, it wasn't what drove the definition. Many factors can effect how things ultimately get laid out on the silicon, and nobody ever said "well, we thought it was going to be micro coded but the ROM area wound up L shaped instead of rectangular, so I guess it isn't."

              What drove the definition was what

      • by sjames (1099)

        The distinctions can get really blurry around the edges, but in a sense it really IS fair to claim the x86 is a RISC core with CISC wrapped around it. The x86-64 moreso.

        Under the surface, tyhe execution units look a lot like a set of specialized RISC processors with a large set of registers. They do no branch prediction or out of order instructions, they just execute the instruction stream from the dispatcher.

        Above that layer, the familiar registers of the CISC instruction set are actually virtual regis

    • Re: (Score:1, Insightful)

      by Anonymous Coward
      CPU architecture not a huge deal?

      "Neither Intel nor Motorola nor any other chip company understands the first thing about why that architecture [Burroughs B5000] was a good idea.

      Just as an aside, to give you an interesting benchmark -- on roughly the same system, roughly optimized the same way, a benchmark from 1979 at Xerox PARC runs only 50 times faster today. Moore's law has given us somewhere between 40,000 and 60,000 times improvement in that time. So there's approximately a factor of 1,000 in efficien
      • by sjames (1099)

        It's just a question to who and when. CPU architecture does matter overall. It does NOT matter to the programmer of an embedded system today. All that matters there is is it fast enough to do what needs doing. To the hardware guy the question is is it low enough power (and heat) to make a practical device today. Somewhere in there, the unit cost will come into play as well.

        Being a particular architecture has little to do with any of that. Thus, as long as you have the source and the toolchain needed it's

    • by exley (221867)

      There are no CISC CPUs anymore.

      For cutting-edge processors that is definitely the case. CISC really doesn't lend itself well to techniques like pipelining, so Intel takes its "complicated" legacy CISC instructions and breaks them down into several smaller RISC operations (much like parent was saying).

      I believe there are still a lot of older processors out there still being used that would be considered CISC CPUs though. This would be more true in spaces like embedded systems where they don't need the latest and greatest to accomplish

      • by sjames (1099)

        While embedded apps often don't need the latest and greatest, low power and little enough heat to go with passive cooling are a BIG plus. RISC lends itself better to low power and heat.

    • Re: (Score:3, Interesting)

      by Darinbob (1142669)

      There are no CISC CPUs anymore.

      One big difference between CISC and RISC was with philosophy. CISC didn't really have a philosphy though, it was just the default. The RISC philosophy was to trim out the fat; speed up the processing and make efficient use of chip resources even if it makes the assembler code. Ie, toss out the middle-man that is the microcode engine, moving some down to hardware and some up to the programmer's level. Then use that extra savings for more registers, concurrency, etc.

      The new x86 Intel CPUs don't really ha

      • by marxmarv (30295)

        One big difference between CISC and RISC was with philosophy. CISC didn't really have a philosphy though, it was just the default.

        Insofar as there was a philosophy, it was to make best use of the scarce resources of the time: memory (so pack as much functionality as possible into an instruction byte) and programmer labor (so make the assembly language as versatile to hand-code as possible).

        Of course Intel is in a bind here. They can't dump the x86, it's their bread, butter, and dessert. They have to make CISC fast because their enormous customer base demands it. They're forever stuck trying to keep an instruction set from 1978 going strong since they can't just toss it all out and make something simpler.

        I wouldn't be quite so sympathetic toward them. They do it because it's a good barrier to entry and they already own most of the ways around it. Besides, people just won't buy a desktop processor that doesn't natively run x86 code, so if you wan

      • by jmv (93421)
        Compilers are still stuck trying to optimize at the CISC level.

        No. Compilers are fully aware of what's happening and take into account what happens after CISC instructions are broken down. Of course there is some gymnastics and overhead involved in translating CISC instructions into RISC instructions, but it's not as bad as you make it sound. What's really complex in modern general-purpose CPUs is all the stuff related to superscalar execution: dependencies, out-of-order execution, branch prediction. Those
      • Re: (Score:3, Informative)

        They tried to throw x86 out with the Itanium. That initially went over about as well as selling ice to Eskimos in December but IA64 has started to get a little more traction in the huge-iron arena as of late. While it would be nice to be done with x86, IA64 isn't where it's at as Intel owns the ISA licenses lock, stock, and barrel. This means it's back to the Bad Old Days when chips cost a fortune and performance increases were small and infrequent. Also, IA64's EPIC model sucks on most code as it's strictl
      • Re:CISC is dead (Score:4, Insightful)

        by RzUpAnmsCwrds (262647) on Tuesday May 20, 2008 @12:24AM (#23470982)
        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.
      • by jhol13 (1087781)
        When the RISC was "invented" the CPU was the bottleneck. Therefore making it simpler could make it faster (MHz, pipeline, ...) and that way speed up the computation.

        This is no longer true, now the bottleneck is memory.
        • When the RISC was "invented" the CPU was the bottleneck. Therefore making it simpler could make it faster (MHz, pipeline, ...) and that way speed up the computation.

          This is no longer true, now the bottleneck is memory.


          I'd also make the claim that single-threaded performance is a bottleneck.

          Designers wowed us in the 1980s and early 90s with fully-pipelined designs that approached an IPC of 1. This gave you double or more performance over non-pipelined architectures. Even Intel surprised the world with the
    • Re: (Score:3, Informative)

      by phantomfive (622387)
      Don't know if you read the article, but the author goes into great detail about the advantages of RISC over CISC. While you are right, that Intel has managed to play some tricks to get CISC running really fast, it has been at the cost of other things. Imagine if all that space on the die used for transistors to do microcode translation had been used for cache, instead. Also, as you mention, it takes more power. This is extremely important in the embedded area, and is becoming more important in the server
      • by jmv (93421)
        If you had bothered to read my post, it is essentially what I'm saying. There *are* penalties to CISC, but they're not that big on *non* embedded CPUs. And I consider x86 CPUs to be mostly RISC chips with a CISC front-end. They've been like that since the Pentium Pro (hence why I said CISC is dead).

        In the x86, there are so many instructions, the chip designers don't optimize all of them equally. If you want maximum efficiency, you will need to use the correct instruction, and it may vary from chip to chip.

      • I hate the way RISC is embraced by many as a pretext to operate their brain in neutral.

        Consider the x86 read-modify-write address mode, which few RISC chips incorporate.

        Compared to the RISC load, operate, store sequence, this saves you: two instruction fetches, the unnecessary use of a named register, unnecessary read/write transfers to the permanent register file, and transferring the *same* load/store address to the memory order buffer *twice*.

        Fixed width RISC instruction sets with large register files an
  • What the Heck? (Score:5, Insightful)

    by AKAImBatman (238306) <akaimbatman@NosPAm.gmail.com> on Monday May 19, 2008 @08:02PM (#23469086) Homepage Journal
    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.
    • Reminds me of a 90s movie:

      It's a P6 chip. Triple the speed of the Pentium
      Yeah. It's not just the chip, it has a PCI bus
      RISC architecture is gonna change everything

      Yes, I know. Not technically correct. But had to do it.
      • by billcopc (196330)
        Perhaps I hold a fonder memory of that film than most, but I thought the P6 line was a nice little "what if" moment. Sure, they got a lot of the tech wrong, but isn't it funny how 10 years later, Macs run on Intel ? Might it be that the movie's technical consultant dreamed of a faster Intel-based Mac ? The whole point of that scene was to convey the fact that the kids had bleeding-edge hardware.

        *sigh* Despite its flaws, it was a fun shiney movie. Nobody would pay $10 to see what geeks REALLY do. Not ev
        • Despite most, I still enjoy this movie. Actually have it running now due to the inspiration this article gave me. Still have my red book somewhere. ;)
          It really was 'bleeding edge' tech (in theory) when it came out. We've come so far so quickly. A friend and I still joke about the '28.8bps' modem (which I had the zoom modem featured in the film).
          Now on the same note, the virus attack scene at the end was repeated today at my place of work. I haven't seen bugz crawling across the screen literally eating it
    • by EmbeddedJanitor (597831) on Monday May 19, 2008 @08:32PM (#23469308)
      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.

      • by Salgat (1098063)
        The AVR32 is a RISC Processor that is competing for the mobile embedded market.
      • by NuShrike (561140)
        What is 'Windows compatibility'?

        Currently deployed Windows Mobile is a working subset of the Win32 api used on PCs, uses the same 'standards compliant' protocols to communicate with other computers, and the only difference is it was compiled for the ARM.

        With such a blistering example that the x86 instruction set is unnecessary to achieve platform portability, what advantage can the Atom bring the table? Out-of-order execution isn't really a big advantage especially when ARM already is already sampling such
      • by MoxFulder (159829)

        Mostly little 8-bitters (PIC and AVR), ...

        If you consider PIC to be RISC, then you, sir, are quite the masochist. :-)

        PIC may have a "reduced" instruction set, but it violates nearly every other principal of RISC design: its instruction set is hopelessly non-orthogonal, it is severely lacking in general-purpose registers (ONE), and its addressing modes are extremely crude, requiring bank switching and making position-independent code essentially impossible.

        AVR on the other hand is great. It has a fully orthogonal instruction set, 32 general purpos

    • Re: (Score:3, Interesting)

      by Darinbob (1142669)

      Microcode has done wonders in turning complex instructions into a series of simpler instructions like one would find on a RISC processor.

      But that's exactly what most CISC style computers were doing when RISC was first thought about. This is the classic CISC computer design model, such as with the VAX. High level instructions with complex addressing modes, all handled by a microcode engine that had it's own programming with a simpler and finer-grained instruction set (some had a VLIW-like microcode, some was more RISC-like).

    • 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.[...] 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.

      Back in the 90s Intel's x86 ISA managed to take over the desktop, not as much because of its inherent benefits, but because of software.
      The market for workstation was increasingly flooded with users who were looking for the only thing they recognize : a machine running Windows with associated software.
      Given that Microsoft's presence and quality in non-Intel architecture was a joke at best, all of these newcomers catered to Windows-capable architecture. Then with market economics doing their work, price of

    • Re: (Score:2, Insightful)

      by benhattman (1258918)

      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.

      I for one think this might be an excellent migration path for the industry. Let the mobile industry settle on a non-x86 processor. Then develop all the necessary software for that processor (lightweight OS, web browser, etc). Then produce an amped up version of that chip for laptops/desktops. Voila, we bootstrap the software that is needed to sell a chip, and we end up with a significantly more efficient platform than anything we'll ever see with x86.

      A guy can dream can't he?

  • Is not the only question. What about how much are the Intel and AMD brand names worth?
  • Completely pointless (Score:5, Interesting)

    by El Cabri (13930) * on Monday May 19, 2008 @08:06PM (#23469122) Journal
    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.
    • 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).

      Expelled simply because backwards-compatibility is important and performance comparisons between different architectures was difficult. Everywhere else, good design/low power is what selects which are used most.

      • by vought (160908) on Monday May 19, 2008 @09:29PM (#23469762)
        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.

        • by prockcore (543967) on Monday May 19, 2008 @10:50PM (#23470374)
          The PowerPC is nothing without the AltiVec vector unit, which is a decidely CISC concept.
          • by renoX (11677)
            >The PowerPC is nothing without the AltiVec vector unit, which is a decidely CISC concept.

            Ahem, the first PowerPC didn't have the AltiVec vector unit..

            As for being a CISC concept, in some way it's true that they are complex intructions (division is also a complex instruction provided by many RISC), but they have also a fixed length, register-register operation only with separated load-store, etc so they're also RISC in many ways..
          • by vought (160908)

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

            I beg to differ. The G3 with 1MB backside cache absolutely spanked the PIII at the same clock speeds - the G3 had no vector unit. If you have evidence that a vector unit was all that made PPC competitive, please provide it - but Apple regularly kicked Intel's butt from 1994 through 1999 without vector units - of course Motorola and IBM were still interested in making general purpose CPUs back then, too.

    • by Cyberax (705495)
      To be fair, there's also MIPS (on almost all wireless home routers) and SH.

      Personally, I prefer MIPS for my embedded devices. It's cleaner than ARM and dev-boards are easier to use.
      • Many of the MIPS dev boards are actually FPGA's. Therefore if you need to switch to a different variant you just reprogram the FPGA. Very cool.
    • Re: (Score:1, Troll)

      they are vector machines

      Yeah, I like vectors. Takes all of the hard work of having a dynamic-sized array of thingies.
    • Re: (Score:3, Informative)

      by LWATCDR (28044)
      SPARC? POWER?
      Both of those are actually popular when it comes to big iron. Yes Intel is it on the desktop but for big honking server it is just so so. For small lower power devices it is pretty lame. There is no reason why a small light mobile device has to be an X86.
  • by serviscope_minor (664417) on Monday May 19, 2008 @08:07PM (#23469128) Journal
    Intel sucessfully killed the high end CPU manufacturers. However, recently they have had poor performance in the very low power arena. Their main offering (XScale, until they sold it) was poor compared ot the competitors. Compare the Intel PXA27x to the Philips LPC3180. The philips chip has about the same instruction rate for integer instructions (at half the clock rate), hardware floating point (so it's about 5x as fast at this) and draws about 1/5 of the power. I know which one I prefer...

    Unlike the old RISC workstation manufacturers which relied on a small market of high margin machines, the current embedded CPU manufacturers operate in a huge, cut-throat world where they need to squeeze up the price/performance ratio as high as possible to maintain a lead. I think this market will be somewhat tougher to crack than the workstation market, since intel does not have what they had before: an advantage in volume shipped.

    • How is the parent post offtopic?

      The article mentions that Intel killed the old workstation RISC vendors. Parent posts suggests why this is not so easy for Intel.

      And further, how is intel having a poor track record for embedded processors compared to other manufactureres offtopic for an article about intel producing embedded processors?
    • agreed. Xscale had lots of early promise, but alternatives such as Ti's OMAP offer better performance for lower power consumption - simply compare the performance of the Sharp Zaurus with its 400MHz PXA270 against the Nokia N800 with its 400MHz OMAP, the latter beats it hands down.

      However, Xscale was a key Intel product for handhelds, and so I was not the only one puzzled when Intel sold Xscale to Marvell, and it was not until the Atom appeared that all became clear.

  • The only "benefit" that has come of having x86 processors in MIDs so far has been seeing the developers cram Vista on an already slow device, making it crawl even worse. Or they stick XP on it, packing an OS completely not designed for MID use on it.

    Using ARM on mobile platforms at least offers some hope of making a clean break from all the backwards compatbility cruft that x86 has dragged along with it for decades now.
  • The RISC philosophy was to have every instruction be as simple as possible, so that the execution of each instruction could be as efficient as possible. The idea was that even though you might have to execute more instructions to get the job done, the speed you gained from the simple instruction set would compensate.

    I've had to work with the ARM ISA in the past (I was studying its implementation as a soft core on an FPGA), and I can tell you it doesn't follow the RISC philosophy well, if at all.

    One ver

    • by plalonde2 (527372)
      The shifter doesn't have to be on the ALU path as such, it can be wired to write-back register bus at relatively low cost. You can set up the variable shift in parallel to the ALU work. I don't know ARM's instruction encoding, but throwing 5 bits at that shift register seems like it might not be a bad tradeoff, considering how nice it is to have power-of-two manipulations for free.
      • by marxmarv (30295)
        You can only shift one of the source registers, right? So think of the shifter as an extension of the register number and it fits neatly into a RISC architecture, and into the register fetch stage where you probably have time to burn.
    • Re: (Score:3, Interesting)

      by Chris Burke (6130)
      That's pretty standard in a lot of "RISCy" architectures, though. The POWER instruction set has a lot of ALU instructions that look like multiple operations jammed together. It has one particularly complicated shifting and masking instruction that makes me think that they decided to add programmatic access to the load data aligner in the data cache. I've always wondered if they regretted that as they changed the micro-architecture, and most likely the DC ended up being farther away from the integer sched
      • by cbrocious (764766)

        It has one particularly complicated shifting and masking instruction that makes me think that they decided to add programmatic access to the load data aligner in the data cache.

        Ugh, PPC is full of shit like that. I'm implementing a PPC core as part of my emulation platform ( http://sourceforge.net/projects/ironbabel/ [sourceforge.net] ) right now, and instructions like rlwinmx, srawx, srwx, slwx, cntlzwx, crxor are just painful. PPC/Power is really well designed, but god it's painful to deal with.

      • I've always wondered if they regretted that as they changed the micro-architecture, and most likely the DC ended up being farther away from the integer scheduler.

        They probably just duped the alignment logic in the integer unit as it moved away from the data cache (because chip densities were growing at the same time), so it didn't bother them much at all.

    • by cbrocious (764766)
      Also can't forget the conditional prefixes on instructions. Makes hacking on ARM code easy, but damn it makes things more complex.
    • by Aardpig (622459)
      About your last remark: when ARM was originally developed by Acorn, it stood for "Acorn RISC Machine". It was one of the first 32-bit RISC CPUs available in the personal computing arena. Having written assembly language for the ARM back then, it most certainly was a RISC architecture.
  • RISC architecture, interestingly, makes things hella fast. The decoder stage follows an easy path; conditionals occur as prefixes, just like cmov in i686 land. This means when the chip makes an instruction fetch, it does pretty much no extraneous work; it just wanders through a couple paths (a decision to execute or skip, and then into execution or back to fetch) in one go. Modern CPUs do a hell of a lot of work just to decide how to handle an instruction.
  • by m.dillon (147925) on Monday May 19, 2008 @08:42PM (#23469402) Homepage
    There's no distinction between the two any more, and hasn't been for a long time. The whole point of RISC was to simplify the instruction format and pipeline.

    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.

    So what does that leave us with? A load-store instruction architecture verses a read-modify-write instruction architecture? Completely irrelevant now that all modern processors have write buffer pipelines. 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. And regardless of the distinction cpu architectures already have to optimize across multiple instructions, so again the concept devolves into trivialities.

    Power savings are certainly a function of the design principles used in creating the architecture, but it has nothing whatsoever to do with the high level concept of 'RISC' vs 'CISC'. Not any more.

    So what does that leave us with? Nothing.

    -Matt
    • RTFA much? (Score:4, Informative)

      by tepples (727027) <.moc.liamg. .ta. .selppet.> on Monday May 19, 2008 @09:23PM (#23469714) Homepage Journal

      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 [arstechnica.com] 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?
    • Re: (Score:3, Interesting)

      by Darinbob (1142669)

      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.
      PowerPC manages without that. It still has to use 1 special load and 1 special store instruction though, but it has no read-modify-write or test-and-set instructions.

    • by Anonymous Coward on Monday May 19, 2008 @10:46PM (#23470320)
      ""
      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.
  • by mykepredko (40154) on Monday May 19, 2008 @08:53PM (#23469486) Homepage
    As I read the previous posts, it seems like the focus is on RISC vs CISC but I think the real question is there value-add for designers to have an x86 compatible embedded microcontroller?

    People (and not just us) should be asking would end customers find it useful to be able to run their PC apps on their mobile devices? Current mobile devices typically have PowerPoint and Word readers (with maybe some editing capabilities) but would users find it worthwhile being able to load apps onto their mobile devices from the same CDs/DVDs that were used to load the apps onto their PCs?

    If end customers do find this attractive, would they be willing to pay the extra money for the chips (the Atom looks to require considerably more gates than a comparable ARM) as well as for the extra memory (Flash, RAM & Disk) that would be required to support PC OSes and apps? Even if end customers found this approach attractive, I think OEMs are going to have a long, hard think about whether or not they want to port their radio code to the x86 with Windows/Linux when they already have infrastructures built up with the processors and tools they are currently using.

    The whole thing doesn't really make sense to me because if Intel wanted to be in the MCU business, then why did they spin it off as Marvell (which also included the mobile WiFi technology as well)?

    The whole think seems like a significant risk that customers will want products built from this chip and the need for Intel and OEMs to recreate the infrastructure they have for existing chips (ie ARM) for the x86 Atom.

    myke
    • The whole thing doesn't really make sense to me because if Intel wanted to be in the MCU business, then why did they spin it off as Marvell (which also included the mobile WiFi technology as well)?
      So people could make jokes about Spiderr-Mann ;-)
    • Re: (Score:3, Insightful)

      by billnapier (33763)
      Huh? It takes more than just the same processor to be able to run the same apps. You gotta have the same operating system. And running Vista on a cell phone doesn't sound like a good idea to me (the mouse is a poor interface for a cell phone).

      Almost all application code written today is done in some portable manner. Writing custom assembly specific to a processor in an application is only done in certain performance critical things (ffmpeg anyone?). This is one of the reasons that Apple was so easily a
      • Re: (Score:2, Informative)

        by Game_Ender (815505)
        Except for VBA in Microsoft Office. Its implemented in tens of thousands of lines assembly (on both Windows and Mac) using specific knowledge of how the complier lays out the virtual function tables of C++ classes. Even the x86 assembly makes calls into the windows API, so its not even portable to other x86 platforms (like Intel Mac). In Excel, they have the floating point number formating routines hand codded in assembly. I assume the office team does this keep these apps nice and snappy under a large w
      • It doesn't necessarily need to be that compatible. Even for developers, it might be useful if their code hand-optimized for x86 can be reused in some mobile version of their app. Porting things to ARM is not easy if you want to keep the performance; there might not be any floating point support, some instructions might cause exceptions and be emulated by the OS, etc.

        Also, it seems that the Atom chips provide a lot more performance than even the fastest ARM systems. Maybe we'll see more mobile devices whi
  • I never delved too far into the RISC vs CISC debate, but my understanding is that RISC uses a small number of simple, generic instructions that execute very quickly, and the compiler builds functionality upon those tiny building blocks. CISC uses a larger number of specialized instructions, each one doing a larger amount of "work" as one black box, where the RISC chip would break that down into several smaller tasks. Since RISC executes faster, overall performance is still good.

    So my point is: if RISC nee
    • by cbrocious (764766)
      Perhaps doing a bit more research before posting is a Good Thing (TM).

      RISC processors usually (always, in practice) have higher performance for the same clock speed when compared to CISC processors. Although they require multiple instructions to do things, these are almost always 1 or 2 cycles each. That means that although it may have to execute 3 instructions to do the same as 1 CISC instruction, it's often done it in half the clock cycles.
      • Re: (Score:3, Interesting)

        by vought (160908)

        Although they require multiple instructions to do things, these are almost always 1 or 2 cycles each. That means that although it may have to execute 3 instructions to do the same as 1 CISC instruction, it's often done it in half the clock cycles.

        Unfortunately, marketing rules the day in the mind of consumers, so AltiVec/VMX and Apple's PowerPC ISA advantages were lost on consumers looking for the "fastest" machines in the consumer space.

        Until recently, there were still speed advantages to using a four core multi-processor G5 for some operations over the 3.0GHz eight-core Xeon Mac Pros because of VMX.

        It is somewhat ironic that the Core architecture chips now used by Apple in all but the Mac Pros are all below the 3GHz clock "wall" that was never ov

        • by Guy Harris (3803)

          It is somewhat ironic that the Core architecture chips now used by Apple in all but the Mac Pros are all below the 3GHz clock "wall" that was never overcome by the G5

          Mac Pros and top-of-the-line iMacs, as per the iMac technical specifications [apple.com].

        • by Sentry21 (8183)

          but the Intel name seems to have gone a long way in assuaging consumer doubts about buying a Mac.
          Or, more likely, the ability to say 'I hate OS X, I'm going back to Windows' without having wasted a thousand dollars has provided a comfortable fallback so people aren't out as much if they decide they didn't like the choice they made.

          Oh, and being able to run Windows at the same time as OS X is a pretty nice touch too.
    • by fishbowl (7759)

      >So my point is: if RISC needs more instructions to do the same work, does it require a higher clock frequency to
      >achieve similar performance to a CISC chip ? Since clock speeds do not scale to infinity, this implies that a
      >RISC chip will hit the frequency wall sooner, thus limiting its maximum speed.

      Learn about things like pipelining and forwarding, out-of-order execution, etc.
      A non-trivial amount of work is involved in decoding machine instructions, this
      is far simpler on a RISC machine. Register
    • by Darinbob (1142669)

      Since clock speeds do not scale to infinity, this implies that a RISC chip will hit the frequency wall sooner, thus limiting its maximum speed.

      This is why you have concurrency. Ie, long pipelines, multiple arithmetic units, etc. You should never use clock speed to figure out how fast a CPU is (no matter what the marketting says).

      Even in the CISC world the same thing holds. They're limited by an internal clock speed. Just because they may have a instruction that does "indexed load, indexed load, add, indexed store" does not mean they can do that in a single clock cycle. Internally they need parallelism to get the most speed out of the silicon

    • by sznupi (719324)
      Actually, I do want low performing laptop if that means longer battery time.
  • As many other people have noted, the classical RISC vs. CISC debate is moot, since all modern processors have elements of both. The real fight in the mobile space now is between general-purpose low-power processors, which may consume more power when doing certain computationally expensive tasks, and processors with specialized acceleration units that optimize certain tasks, at the expense of performance and power efficiency for general-purpose work.

    I suspect that in the near future, the more interesting fi
  • The mobile world does lots of wireless communication ( My cellphone alone does: bluetooth v1 / 2, IR, GSM, Wifi ). The best chips suited for these wireless communication tasks are DSP / CISC chips. Given that there is lots of wireless communication tasks I forsee DSPs / CISC chips having a significant percentage of the tasks.

    BUT the DSPs / CISC chips won't ever REPLACE the General Purpose Processors / RISC chips. Most cellphones today are actually a combo platform with a General-Purpose-Processor that does
    • by syn1kk (1082305)
      "DSP Or A GPP? You Decide" , http://electronicdesign.com/Articles/Index.cfm?AD=1&ArticleID=7722 [electronicdesign.com] --> "Solutions that mix a GPP and a DSP in one chip have many advantages, but they significantly increase the complexity of the underlying system."

      "Lost cost General Purpose Process vs low cost DSP" , http://www.bdti.com/articles/evolution/sld024.htm [bdti.com] , GPP gets score 7 vs DSP gets score of 10.

      -----

      FYI, BDTI is a company that specializes in designing benchmarks for GPP and DSP chips. Their benchmarks are w
    • by Darinbob (1142669)

      BUT the DSPs / CISC chips won't ever REPLACE the General Purpose Processors / RISC chips.
      I always considered most DSPs to be somewhat RISC-like. Just because they have a lot of instructions doesn't make them CISC. They don't have a lot of unnecessary instructions, lots of addressing modes, etc. The "R" in RISC means "reduced", not "minimal".
  • x86, which is the classic CISC, is also a variable-length ISA. That means certain instructions take just a single byte to encode, compared with a fixed 4 bytes on the most common RISCs. This can be a factor in instruction cache size/effectiveness. Fewer bytes for instructions == more instructions fit in the ICache == ICache is more effective. I don't have any numbers, but I would expect the average instruction length on CISC to be in the 10s of % smaller than RISC. That means either greater performance

  • by Jacques Chester (151652) on Monday May 19, 2008 @11:46PM (#23470748)
    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.
  • by bill_kress (99356) on Tuesday May 20, 2008 @12:19AM (#23470944)
    I understand the theory--you simplify instructions, do things to speed up the processor so it can run faster, then optimize the processor to run as fast as you can.

    In other words, you are designing your instruction set to your hardware.

    Now, assuming that you are going to have close to infinite investment into speeding up the CPU, it seems that if you are going to fix an instruction set across that development time, you want the instruction set that is the smallest and most powerful you could get it.

    That way for the same cycle instead of executing one simple instruction you are executing one powerful one (that does, say 5x more than the simple one)

    Now at first the more powerful one will take more time than the simple one, but as the silicon becomes more powerful, The hardware designers are going to come up with a way to make it only take 2x as long as the simple one. Then less.

    I guess I mean that you will get more relative benefit tweaking the performance of a hard instruction than an easy one.

    Also, at some point the Memory to CPU channel will be the limit.

    I'd kinda like to see Intel take on an instruction set designed for the compiler rather than the CPU (like Java Bytecode). Bytecode tends to be MUCH smaller--and a quad-core system that directly executes bytecode, once fully optimized, should blow away anything we have now in terms of overall speed.
    • Sounds good -- do bytecode execution, as bytecode is optimized for compilation...

      But - turns out bytecode directly executed is in the same ballpark as "regular" instructions. Doesn't really gain much. (sorry, can't cite)

      The reason(s)?

      - programming languages following instruction conventions (example: C). C is simple, and follows a "PDP-11" model

      - programming languages not expressive enough, unless they are profiled (examples: C, Java). No way to mark code "rarely used", No way to indicate parallelism.

      The ol
      • by bill_kress (99356)
        > But - turns out bytecode directly executed is in the same ballpark as "regular" instructions. Doesn't really gain much. (sorry, can't cite)

        Not sure what you mean. If you are saying that a CPU running bytecode tends to run your code as fast as a CPU running assembly, that's what I'm assuming. But the CPUs running bytecode haven't been optimized as much as the intel CPUs..

        Also, we could put more powerful instructions into the bytecode if they tend to execute too quickly. Stuff like complete control ov
        • by ratboy666 (104074)
          But, look at the WAY that Java gets faster than C: by interpreting and being introspective (in your example, detecting idempostent like functions). Doesn't matter if the processor is executing Java bytecode or not. Indeed, HP has been inserting a PA-RISC interpreter into binaries to pick up similar gains.

          As to the idea of higher order functions -- it's been tried. As an example, the Intel architecture has "task switch" segments. Not used, because it turns out that the incomplete case is faster. Or, examine
  • uh huh huh he said vacillate

HOST SYSTEM NOT RESPONDING, PROBABLY DOWN. DO YOU WANT TO WAIT? (Y/N)

Working...