Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
Cellphones Intel Hardware

Intel Medfield SoC Specs Leak 164

Posted by Soulskill from the just-over-the-horizon dept.
MrSeb writes "Specifications and benchmarks of Intel's 32nm Medfield platform — Chipzilla's latest iteration of Atom and first real system-on-a-chip oriented for smartphones and tablets — have leaked. The tablet reference platform is reported to be a 1.6GHz x86 CPU coupled with 1GB of DDR2 RAM, Wi-Fi, Bluetooth, and FM radios, and an as-yet-unknown GPU. The smartphone version will probably be clocked a bit slower, but otherwise the same. Benchmark-wise, Medfield seems to beat the ARM competition from Samsung, Qualcomm, and Nvidia — and, perhaps most importantly, it's also in line with ARM power consumption, with an idle TDP of around 2 watts and load around 3W."
This discussion has been archived. No new comments can be posted.

Intel Medfield SoC Specs Leak More

Intel Medfield SoC Specs Leak

Comments Filter:

  • One benchmark (Score:2, Insightful)

    by teh31337one ( 1590023 )

    It beats the current crop of dual core ARM processors (Exynos, snapdragon s3 and Tegra 2) in one benchmark that "leaked".

    Nothing fishy about that at all.

    • Re:One benchmark (Score:5, Informative)

      by icebike ( 68054 ) * on Tuesday December 27, 2011 @10:23PM (#38511084)

      It beats the current crop of dual core ARM processors (Exynos, snapdragon s3 and Tegra 2) in one benchmark that "leaked".

      Nothing fishy about that at all.

      Quote Vrzone:

      Intel Medfield 1.6GHz currently scores around 10,500 in Caffeinemark 3. For comparison, NVIDIA Tegra 2 scores around 7500, while Qualcomm Snapdragon MSM8260 scores 8000. Samsung Exynos is the current king of the crop, scoring 8500. True - we're waiting for the first Tegra 3 results to come through.

      But the same paragraph says

      Benchmark data is useless in the absence of real-world, hands-on testing,

      If the performance figures are realistic this is one fast processor, and it appears to be a single core chip, (or at least I saw nothing to the contrary). That's impressive.

      Single cores can get busy handling games or complex screen movements, leading to a laggy UI. If they put a good strong GPU on this thing you might never see any lag.

      • Re: (Score:2, Redundant)

        by teh31337one ( 1590023 )

        Sure, it's great, and compares well to this gen of processors (which are all at the 45/40nm fab (the exynos 4210 is 45nm, not 32nm as vr-zone incorrectly states)).
        But what about the next gen chips that will have 32/28nm fab?

        And how will it compare to the Quad-Core A9 processors (Tegra 3), higher clocked dual core A9 processors (Exynos 4212) or A15/A15 based designs? (Exynos 5250 and Krait/Snapdragon S4)

        • Re: (Score:3)

          by icebike ( 68054 ) *

          At the stated bench mark scores Medfield IS THE NEXT GEN Chip.
          And its single core. When they dual well it, the others will still be trying hard to catch up.

          • Great. How about comparing it to a NEXT GEN chip then? Not to mention power consumption - which is its Achilles heel - still can't compare to THE LAST GEN ARM CHIP.

            • Re: (Score:2)

              by icebike ( 68054 ) *

              Actually go read the story. It specifically states that the power consumption is pretty close to the ARM chips.

              • Re:One benchmark (Score:5, Informative)

                by teh31337one ( 1590023 ) on Tuesday December 27, 2011 @11:14PM (#38511486)

                Yeah... no.

                vr-zone [vr-zone.com]

                As it stands right now, the prototype version is consuming 2.6W in idle with the target being 2W, while the worst case scenarios are video playback: watching the video at 720p in Adobe Flash format will consume 3.6W, while the target for shipping parts should be 1W less (2.6W)

                extremeTech [extremetech.com]

                The final chips, which ship early next year, aim to cut this down to 2W and 2.6W respectively. This is in-line with the latest ARM chips, though again, we’ll need to get our hands on some production silicon to see how Medfield really performs.

                • Re:One benchmark (Score:5, Insightful)

                  by Anonymous Coward on Tuesday December 27, 2011 @11:38PM (#38511620)

                  Yeah... no.

                  vr-zone [vr-zone.com]

                  As it stands right now, the prototype version is consuming 2.6W in idle with the target being 2W, while the worst case scenarios are video playback: watching the video at 720p in Adobe Flash format will consume 3.6W, while the target for shipping parts should be 1W less (2.6W)

                  extremeTech [extremetech.com]

                  The final chips, which ship early next year, aim to cut this down to 2W and 2.6W respectively. This is in-line with the latest ARM chips, though again, we’ll need to get our hands on some production silicon to see how Medfield really performs.

                  And which ARM SoC's idle at 2W? That's at least an order of magnitude greater than any ARM SoC - those typically idle at a few tens or hundreds of milliAmps. ARM's big.LITTLE architectures will bring that down even further.
                  So, Medfield may be competitive on speed and TDP at full load, but if you are a mobile device maker, would you care? You would probably be more interested in eking out more uptime from your tiny battery.

                  • Re: (Score:2)

                    by gl4ss ( 559668 )

                    it would be usable for tablets and media consumption devices, and devices which can hibernate quickly.

                    of course there's this one nagging thing about using them for phones, which is.. well, fuck, they'd still need an arm chip or two there for the radios.

                  • Re: (Score:2)

                    by AmiMoJo ( 196126 )

                    I was about to say the same thing. A typical high end smartphone has a 1700mAh battery. That means 1.7A for one hour before the battery is depleted. A phone that idles at 2W will last less than an hour on a full charge, and that is assuming that the screen is off. I don't have tablet battery specs to hand but they won't be that much better.

                    Android has a handy feature where you can check power consumption built in, and there are apps on the Market that can give you the real-time current consumption. At idle

                • Re:One benchmark (Score:5, Interesting)

                  by LordLimecat ( 1103839 ) on Wednesday December 28, 2011 @12:32AM (#38511900)

                  According to what I could dig up (memory, and corroboration here [blogspot.com]), snapdragons use about 500mw at idle. Thats one quarter to one sixth the power consumption of intel's offering.

                  Doing some research, it looks like Tegra3s use about .5w per core as well. Again, Intel is pretty far back if theyre throwing out a single core and hitting 2-3 watts.

              • Re:One benchmark (Score:5, Insightful)

                by Anonymous Coward on Tuesday December 27, 2011 @11:14PM (#38511490)

                I did read the story - but did you? Its idle TDP stands at 2.6W. A 1700mAH battery (typical in a cell phone) @ 3.6V = 6.12 Volt-Amps (i.e. Watts). So, you'll get around 2.5 hrs of uptime under idle conditions, assuming the battery is new. Good luck trying to charge that monster ever 2 hrs!
                Who cares about performance when your phone will be dead before making a single call? Not much better in tablets either!
                So, what is this chip competing against? Other laptop chips from Intel?

                • That's just powering the processor. You've got all the support chips, radio and such to. The single biggest power draw in most phones and tablets is the screen, when it's on - a good deal of power management goes into just trying to keep it turned off as much as possible.
              • No, it talks complete bullshit. The idle power consumption is 2W! The full-load power consumption of a typical ARM SoC (including CPU and GPU) is usually under 2W. Idle power consumption is generally well under 100mW, typically closer to 20mW. It's 'pretty close' if you mean 'within two orders of magnitude'. Or as we would normally say 'not close at all.'

      • whoosh (Score:5, Insightful)

        by decora ( 1710862 ) on Tuesday December 27, 2011 @10:37PM (#38511186) Journal

        teh37737one's point, if i may, was that this 'leak' was actually a 'plant', a PR move by Intel to get people posting ridiculous speculative nonsense, like, exactly the stuff you posted in your comment.

        "if this is realistic, intel has an awesome CPU" etc etc etc.

        Does anyone care if its realistic? Intel sure doesn't, it just wants people to speculate that it might be realistic, and then talk about Intel, and how awesome Intel is.

        But of course, it might be a load of crap... when the actual numbers come out, who knows what they will say? And when real programs hit the thing, who knows what it will do?

        That's why Intel is 'leaking' it. On purpose. So they can have 'plausible deniability'. They can churn the rumor mill, get their product mentioned in the 24 hour ADHD cycle of tech news, get people posting on slashdot, etc, but Intel itself never has to sully it's good name by engaging in outright pushing of vapor-ware.

        If only the guys at Duke Nukem had been smart enough to 'leak' stuff 'anonymously' to the press, instead of giving out press releases...

        Of course, another way to look at it is this: It's yet another example of the corporate philosophical suite that is drowning our civilization in garbage and awful values. Never say anything directly, never take responsibility for your words or actions, never be straight with people, and hide everything you are doing in layers and layers of techno jargon, babble, and nonsense.

        • Re:whoosh (Score:4, Insightful)

          by Jeremi ( 14640 ) on Tuesday December 27, 2011 @10:57PM (#38511366) Homepage

          Does anyone care if its realistic? Intel sure doesn't

          Intel will care if the leaks create unrealistic expectations that their product can't meet. The result could be consumer rejection of an otherwise respectable product, because the public had been (mis)led to expect more than the product could actually deliver. (see: Itanium as replacement for x86)

          So the "secret Intel propaganda strategy" only works if Intel actually has a reasonable chance of living up to their own unofficial hype. And based on their recent track record, they probably do.

          • Re:whoosh (Score:5, Informative)

            by Svartalf ( 2997 ) on Wednesday December 28, 2011 @12:41AM (#38511944) Homepage

            Recent track record... Yeah, sure...

            http://www.pcper.com/reviews/Graphics-Cards/Larrabee-canceled-Intel-concedes-discrete-graphics-NVIDIA-AMDfor-now [pcper.com]

            There's a few others like this one. This includes the GMA stuff where they claimed the Xy000 series of GMA's were capable of playing games, etc. They're better than their last passes at IGPs, but compared to AMD's lineup in that same space, they're below sub-par. Chipzilla rolls out stuff like this all the time. Been doing it for years now.

            Larrabee.
            Sandy Bridge (at it's beginnings...).
            GMA X-series.
            Pentium 4's NetBurst.
            iAPX 432.

            There's a past track record that implies your faith in this is a bit misplaced at this time.

          • Recent track record... Yeah, sure...

            http://www.pcper.com/reviews/Graphics-Cards/Larrabee-canceled-Intel-concedes-discrete-graphics-NVIDIA-AMDfor-now [pcper.com]

            There's a few others like this one. This includes the GMA stuff where they claimed the Xy000 series of GMA's were capable of playing games, etc. They're better than their last passes at IGPs, but compared to AMD's lineup in that same space, they're below sub-par. Chipzilla rolls out stuff like this all the time. Been doing it for years now.

            Larrabee.
            Sandy

      • What does the number of cores have to do with a "good, strong" GPU, or a lag of the UI? Lag is usually interrupt-based (think network or disk access), or the result of software, when operations are poorly ordered and/or uncached lookups perform often.. therefore your benchmark has a rabbit with a pancake on it's head -

        • Re: (Score:2)

          by icebike ( 68054 ) *

          If you have a good GPU, you can off load a lot of processing that might be otherwise have to do with the CPU. Sift enough work, and you can do with a single core what others might do with a dual. Thats all I was trying to point out.

        • Re:One benchmark (Score:4, Informative)

          by Tr3vin ( 1220548 ) on Wednesday December 28, 2011 @12:52AM (#38512012)
          UI lag is almost exclusively limited to fill-rate on mobile devices. This is a problem on Android, since it is hard for them to optimize it for all of the various chipsets. If the GPU cannot quickly fill pixels, more of the preparation of a frame has to be offloaded to the CPU. For modern GUIs, each pixel can be touched several times, so without a good fill rate, more heavy lifting is required from the CPU. Multiple cores can help, since more processing power can be dedicated to quickly updating the UI.

      • Re: (Score:2)

        by godefroi ( 52421 )

        Single cores can get busy handling games or complex screen movements, leading to a laggy UI.

        I know, right? The entire computer industry was plagued with these "laggy UI"s until multi-core processors were invented and saved us. If only someone had thought out a way to run multiple paths, or maybe call them "threads", of execution on a single CPU.

        Oh well, too late for that.

    • It beats the current crop of dual core ARM processors (Exynos, snapdragon s3 and Tegra 2) in one benchmark that "leaked".

      Nothing fishy about that at all.

      So it beats (maybe) the ARMs of the moment. But what about the ARMs when Medfield actually ships? And the quad-core ARMs now?

  • The Atom's have always had a reasonable core power consumption... but the external chipsets that ruin the system power consumption figure. Will be curious to see what the total system consumption is going to be with these new one, maybe time to look towards a nice replacement for my Asus eeebox B202's for the desktop.

    • It's a SoC. No external chipset necessary.

      • Re: (Score:3)

        by inflex ( 123318 )

        For sure, yes, it's a SoC, but I'm still going to wait for a complete "on the shelf" system to make an appearance before holding my hopes too high. Leaked releases are about as useful as "New solar cell technology yields 50% more efficiency" announcements.

        What is interesting is that they only mention the elevated power consumption in relation to video playback (720p) which is something that'd likely be handed off to a dedicated section of silicon, not something done in the general purpose CPU core. Hopefu

    • The point of Medfield is to integrate the external chipsets. They aren't there any more, so I don't see where system power consumption would be at any disadvantage to an ARM chip.

      It's hard to imagine how Intel could not win this, now or soon. They have the best chip designers and process.

      • Re: (Score:2)

        by darronb ( 217897 )

        Well, the limiting factor is quite certainly backwards compatibility.

        The architecture itself very possibly cannot compete with ARM on low power... no matter what the "best chip designers and process" can bring to the table.

        I think it's getting to be time to finally retire x86. It'll be hell to bring a new architecture to market... but what's the alternative? Microsoft is dying. Apple is starting to make their own chips.

        They probably do have the best people and starting fresh they could very likely do amazin

        • Re: (Score:2)

          by Belial6 ( 794905 )
          The solution is actually pretty straight forward. Multi-core is the present. To make a complete clean sweep, the solution is for Intel to make a processor that has say, 4 x86 cores, and 2 xWayBetterThan86 cores. They then design the system to allow code that is written for the xWBT86 cores to run in parallel with the x86 cores. Get MS to port Windows to use the xWBT86 cores for the OS, and advocate to the developers. Basically turn the old x86 into a legacy compatibility co-processor. They would want

      • Re: (Score:2, Insightful)

        by mollymoo ( 202721 )
        x86 is a a huge, complex instruction set. All else being equal. implementing it costs more silicon and more power than ARM architectures. Intel's great engineers and unmatched process can make up for this somewhat, but it would be a good effort for them just to achieve parity with ARM. To do so they're likely going to need to stay one process step ahead of the competition, which has cost implications.
        • The first x86 processor, the 8086, only had 29,000 transistors total, whereas this new chip uses over 34,000 times that many (a billion) just for DRAM, so how much complexity can x86 really be adding? Too many other architectures have come and gone - 68K, PowerPC, SPARC, ARM on the desktop... whatever advantage they gained from more elegant architecture wasn't enough to overcome x86s' 30 years of refinement and Intel's lead in process and design. With Itanium, even Intel itself massively blundered over-es

          • Re: (Score:3)

            by makomk ( 752139 )

            The first x86 processor, the 8086, only had 29,000 transistors total, whereas this new chip uses over 34,000 times that many (a billion) just for DRAM, so how much complexity can x86 really be adding?

            The 8086 was a 16-bit processor that could only address 1 MB of RAM (split up into 64k segments) with no support for virtual memory, didn't have any floating point hardware let alone stuff like SSE, and took an awfully large numbers of clock cycles to execute each instruction by modern standards. If you want something capable of actually running modern applications, you're looking at a lot more complexity.

        • Re: (Score:2)

          by rev0lt ( 1950662 )
          I won't argue that ARM architectures are probably simpler to implement (chipwise) than Intel's x86/ADM64. What is usally called x86 instruction set is actually a blend of multiple instruction sets of different generations of processors, but most instructions aren't implemented in silicon, and Intel clearly describes it in the architecture manuals. CISC instructions are decoded in "micro-ops" (internal RISC instructions) and then those instructions are fed to the execution pipelines. You have microcode updat

    • The Atom's have always had a reasonable core power consumption... but the external chipsets that ruin the system power consumption figure. Will be curious to see what the total system consumption is going to be with these new one, maybe time to look towards a nice replacement for my Asus eeebox B202's for the desktop.

      I thought that problem was only with the early Atoms paired the 945GSE, and then later Pine Trail included the power-proper NM10 chipset.

  • 2 watts idle? (Score:5, Funny)

    by viperidaenz ( 2515578 ) on Tuesday December 27, 2011 @10:13PM (#38510996)
    Awesome, with smartphones these days containing 6 watt-hour batteries you'll get 3 hours standby time! Thats nearly as much an an iPhone 4S

    • Re: (Score:2)

      by Ark42 ( 522144 )

      I think batteries are rated in mAh, not mWh. For example, my Netbook has a 6600mAh battery that outputs 11.1v. I think that's basically 73.26Wh, or 36 hours of idle time at 2W. I don't have any smartphone to compare, nor do I know the actual idle usage of the Atom CPU in my netbook, or the other components in it.

  • 2W idle power consumption! (Score:2, Interesting)

    by Anonymous Coward

    That just doesn't cut it. Based on that, I'd assume the mobile version of the chip to consume at least 1W at idle loads. That _still_ doesn't cut it.

    • It gets worse: the summary is actually misleading. They benchmarked it around 2.6 idle and 3.6 active ("around", right), and it "aims" to get down to 2W idle and 2.6 active by next year.
      • Oops, my first "around" should have been "at". As in, they benchmarked it exactly at 2.6W and 3.6W idle and active, respectively (and rounded it down - way down - in the summary)

    • Re:2W idle power consumption! (Score:5, Insightful)

      by mirix ( 1649853 ) on Wednesday December 28, 2011 @02:00AM (#38512358)

      Bingo. My ageing Nokia, while lacking in horsepower, has excellent battery life... It has a 600MHz ARM, and a 3.2Wh battery. It manages to idle for a week at least, I'm sure it's hit 10 days before, but lets say 7, to be safe.

      3.2W / 7 / 24 = 20mW idle. Two fucking orders of magnitude better than their *target*. (not to mention this includes the entire phone, not just the core, in real life).

      I presume the more powerful android rigs still keep it within 100mW for the whole phone, idling. - That would give you roughly two days idle on a decent sized phone battery (5Wh). That's still more than an order of magnitude difference.

  • I think the tablet will be interesting.

  • beat ARM on what, 45nm? (Score:4, Interesting)

    by Locutus ( 9039 ) on Tuesday December 27, 2011 @10:26PM (#38511112)
    come on, when talking about comparing embedded SoC's is it really fair to say a new die shrunk version of another architecture best another using a much larger die size?

    So here we have Intel putting their low cost product on their high cost process and claiming a victory? I don't buy it but since Intel is going to be selling these things at deep discounts, I might buy a product or two. I don't think in the long run they can continue this game but it's fun to see them attempting it.

    LoB

    • It's not Intel's high cost process (Score:5, Informative)

      by Sycraft-fu ( 314770 ) on Tuesday December 27, 2011 @11:00PM (#38511382)

      These days 32nm is their main process. They use 45nm still but not for a ton of stuff. Almost all their chips have moved to it. Heck they have 22nm online now and chips will be coming out rather soon for it (full retail availability in April).

      Once of Intel's advantages is that they invest massive R&D in fabrication and thus are usually a node ahead of everyone else. They don't outsource fabbing the chips and they pour billions in to keeping on top of new fabrication tech.

      So while 32nm is new to many places (or in some cases 28nm, places like TSMC skipped the 32nm node and instead did the 28nm half node) Intel has been doing 32nm for almost 2 years now (first commercial chips were out in January 2010).

    • Re: (Score:3)

      by Kjella ( 173770 )

      So here we have Intel putting their low cost product on their high cost process and claiming a victory?

      Developing the process is ungodly expensive, pushing out chips is not. Why wouldn't Intel use their state of the art process? It's not like it would be cheaper to produce on 40/45nm, far from it.

      I don't think in the long run they can continue this game but it's fun to see them attempting it.

      Well, it's the game Intel's been running since the 1980s and has kept AMD a distant second even when their chip designers have been smoking crack. Smaller process = more dies/wafer and so higher margins and more money to funnel back into R&D.

      Do I believe everything Intel says? Hell no. But their tick-tocks have

    • High cost process? The more you shrink the die, the cheaper it gets to produce. Once the R&D and fabs have been done, you want to move everything to the smaller process if the yields are okay. Smaller dies mean that you get more chips per wafer. That means lower costs.

      • Re: (Score:2)

        by rev0lt ( 1950662 )
        Smaller dies means more defects per wafer. And electric problems at subatomic level. And defects that may manifest only when voltage is applied (leaking electrons, capacitance problems, etc). Also, smaller dies means that the specs for the raw materials are tightened, so it usually translates to "more expensive".

  • no AM? (Score:3)

    by decora ( 1710862 ) on Tuesday December 27, 2011 @10:30PM (#38511144) Journal

    think of all those amplitudes not being modulated.

    this is a terrible, terrible loss for America.

  • apples and oranges? (Score:4, Interesting)

    by viperidaenz ( 2515578 ) on Tuesday December 27, 2011 @10:44PM (#38511244)
    It looks like CaffeineMark 3 is single threaded. At least the online version is anyway.
    How can you compare a 1.6ghz presumably single core against dual core cpus on a single thread benchmark?

    I just compared my laptop which is 2.2ghz dual core with my desktop, 3ghz single core. laptop gets 16,000, desktop gets 24,000. Laptop was at 50% cpu, desktop was at 100%.

  • Just let x86 die, please. (Score:4, Interesting)

    by VortexCortex ( 1117377 ) <VortexCortex AT ... trograde DOT com> on Tuesday December 27, 2011 @11:57PM (#38511718)

    It's bloated. It had its time. I LOVED writing in assembly on my 80286, the rich instruction set made quick work of even the most complex of paddle ball games...

    However, that was when I was still a child. Now I'm grown, it's time to put away childish things. It's time to actually be platform independent and cross platform, like all of my C software is. It's time to get even better performance and power consumption with a leaner or newer instruction set while shrinking the die.

    Please, just let all those legacy instruction's microcode go. You can't write truly cross platform code in assembly. It's time to INNOVATE AGAIN. Perhaps create an instruction set that lets you get more out of your MFG process; Maybe one that's cross platform (like ARM is). Let software emulation provide legacy support. Let's get software vendors used to releasing source code, or compiling for multiple architectures and platforms. Let's look at THAT problem and solve it with perhaps a new type of linker that turns object code into the proper machine code for the system during installation (sort of like how Android does). DO ANYTHING other than the same old: Same Inefficient Design made more efficient via shrinking.

    Intel, it's time to let x86 go.

    • We still use Imperial units in the US. And do you remember the shortage of competent Cobol programmers back when Y2K was the big worry?

      The world does indeed move on, but the past stays with us for a long while. A low power x86 SOC is still a useful and a wonderful thing.

      My first thought when I read the article was "Cool! You'll be able to get a notepad to run WINE and native Windows XP now!" I can see TONS of uses for this, even with the lousy power specs. Industrial/business types don't like to le

    • Hahahaha... oh wait, you're serious.Ok, so what high performance, low-cost, and power efficient processor should we all migrate to then? And will you pay to have all my software ported over to this new ISA?

    • Re:Just let x86 die, please. (Score:5, Interesting)

      by AcidPenguin9873 ( 911493 ) on Wednesday December 28, 2011 @01:37AM (#38512242)

      I scoured your post for one actual reason why you think x86 is an inferior ISA, but I couldn't find any. I'll give you a couple reasons why it is superior, or at least on par with, any given RISC ISA, on its own merits, not taking into account any backwards compatibility issues:

      • Variable length instruction encoding makes more efficient use of the instruction cache. It is basically code compression, and as such it gives a larger effective ICache size than a fixed length instruction encoding. Even if you have to add marker bits to determine instruction boundaries, it's still a win or at least a wash.
      • x86 has load-op instructions. Load-op is a very, very common programming idiom both for hand written assembly and for compiler generated code. ARM and other RISC ISAs require two instructions to accomplish the same thing.
      • AVX, the new encoding from Intel and AMD, gives you true RISC-like two source, one non-destructive dest instructions.
      • Dedicated stack pointer register allows for push/pop/call/return optimizations to unlink dependence chains from unrelated functions. With a GPR-based stack, RISC has false dependence problems for similar code sequences that they can't really optimize,
      • AMD64 got rid of cruft, added more GPRs, and added modern features like PC-relative addressing modes, removing that advantage from RISC too.
      • ARM's 64 bit extensions were just announced and won't be shipping until 2014. x86 has been 64 bit for 8 years.

      x86 should be able to compete quite well with any RISC ISA on its own merits today.

      • Re: (Score:2, Informative)

        by Anonymous Coward

        1. Having variable length instructions complicates instruction decoding, which cost die space and cycles (once for actual decoding and once for instructions spanning fetch boundaries). Also several processor architectures save 16-bit instructions (ARM, SH, MIPS, TI C6x off the top of my head), still having access to 16 general purpose registers as x86-64 with its up to 16 byte insns.

        2. Load-op insns and many others are split up internally in smaller micro-ops. They are about as useful as assembler macros. L

        • 1. Having variable length instructions complicates instruction decoding, which cost die space and cycles (once for actual decoding and once for instructions spanning fetch boundaries). Also several processor architectures save 16-bit instructions (ARM, SH, MIPS, TI C6x off the top of my head), still having access to 16 general purpose registers as x86-64 with its up to 16 byte insns.

          Yes, those are the standard arguments against variable length instructions. But both Intel and AMD use extra marker bits to mark the instruction boundaries, which removes the extra-cycles penalty. I'd argue that the extra area with the marker bits is *still* smaller than wasting area on non-compressed instructions. With the cycle penalty gone, now you're just left with a die size argument for the initial decode hardware and the cross-fetch-boundary hardware. I'll argue that that area cost is absolutely

      • Re:Just let x86 die, please. (Score:4, Interesting)

        by JackDW ( 904211 ) on Wednesday December 28, 2011 @08:47AM (#38514120) Homepage

        Indeed. And the ARM ISA isn't even RISC anyway. In fact, which ARM ISA are we even talking about here? Thumb, Thumb2, ThumbEE, Jazelle or the 32-bit ISA? And which extensions, I wonder? NEON, maybe? Or one of the two different sorts of FPU? That's already a significantly complex instruction decoder. The x86 microcode-for-uncommon-instructions approach is probably better.

        Whenever this topic comes up, the discussion is immediately flooded with ARM fanboys insisting that x86 can never compete for magical reasons that don't stand up to sensible analysis. And as Intel approaches ARM's level of power consumption, as they inevitably must (for there is no magic in ARM and there is nothing physically preventing parity), what we hear is denial: the insistence that Intel is playing dirty tricks.

        At least, post OnLive, nobody is claiming that there is no demand for x86 applications on mobile devices. I suppose the "ARM = magic" power claims will have a similar lifetime, and one day will look as silly as claims that Windows XP will be a failure because everyone will be using Linux by 2005. Hope is a good thing, but this is just foolishness.

      • I scoured your post for one actual reason why you think x86 is an inferior ISA, but I couldn't find any. I'll give you a couple reasons why it is superior, or at least on par with, any given RISC ISA, on its own merits, not taking into account any backwards compatibility issues:

        • Variable length instruction encoding makes more efficient use of the instruction cache. It is basically code compression...
        • x86 has load-op instructions. Load-op is a very, very common programming idiom both for hand written assembly and for compiler generated code. ARM and other RISC ISAs require two instructions to accomplish the same thing.

        The latter pretty much amounts to "code compression"; maybe assembler-language programmers would also find it convenient, but compilers probably don't really care much, except for a little extra register pressure.

        • Dedicated stack pointer register allows for push/pop/call/return optimizations to unlink dependence chains from unrelated functions. With a GPR-based stack, RISC has false dependence problems for similar code sequences that they can't really optimize,

        x86 has some instructions that use one of the GPRs - ESP/RSP - specially. RISC processors have calling conventions that use one of the GPRs specially. What exactly are the differences here?

    • Well... I will like (and buy) a tablet where I can install and use Paint Shop Pro 7 (yep, is old) without emulation and can use my finger or a stylus to draw, and be capable of using Miranda IM without ugly hacks. Applications my friend, applications.

      P.S: I know that I can have simmilar applications on Android or iPad... But I really, really do not like the idea of "happy walled garden" with pseudoapplications ("apps" in html/javascript? WTF), sorry.

      • Tablets are the future apparently. People keep telling me that on here and calling me all sorts of names when I point out all the things that I want from a computer that tablets can't do, like run my software or upgrade the storage or RAM without having to buy a new tablet.

    • However, that was when I was still a child. Now I'm grown, it's time to put away childish things.

      There is IBM Mainframe System 360 code from the '60s still running on current zEnterprise systems today. That code was probably written while you were still swimming around in your dad's balls (no offense intended; it's just an amusing expression).

      This will also be the case with x86. It will stay around forever, because it has been around forever. Tautology intended.

      However, supporting legacy stuff does not necessarily preclude innovation.

    • Re: (Score:2)

      by rev0lt ( 1950662 )
      The 80286 instruction set was simply god-awful. It was basicly a 8086 with better performance and a castrated and inconsistent protected mode support. You can't write truly cross platform assembly in most of the available RISC processors either. There's always extensions, issues, extra register, hiccups and whatnot.

      Intel has been translating x86 legacy instructions to RISC operands for ages. It happens in almost every major CPU released in the last decade. So, technically, x86 is already gone a long time.

    • Perhaps create an instruction set that lets you get more out of your MFG process; Maybe one that's cross platform (like ARM is).

      What do you mean when you say the ARM instruction set is "cross platform"?

      Let's look at THAT problem and solve it with perhaps a new type of linker that turns object code into the proper machine code for the system during installation (sort of like how Android does).

      Or how the IBM System/38 and successors do it (compilers generate a very CISCy high-level virtual instruction set; core OS code translates it to machine code when it's first run). ("How Android does" is, I think, pretty much "how Java does".)

  • If this thing can compete on performance with ARM chips, it's only because Intel can make miracles happen in silicon. Of course, we might never know what would happen if Intel used their latest process technology to print ARM chips like Apple's A6 or whatever the next generation will be. But it would be very good.

  • So...how's the performance per watt if we compare these recent ARM and Intel offerings?

    I was also thinking that the Atoms probably have more all sorts of acceleration units. I'm not sure how important would those be on a tablet or a phone though. Anyway, there was an interesting discussion [foldingforum.org] pondering if it would be possible to run Folding@Home on a phone. It ended by realizing that the ARMs wouldn't have the same kind of FPU power.

  • Perhaps everyone is too stoned from Christmas but 28nm stamping is already approved with GlobalFoundries, TSMC and Samsung.

    http://arm.com/about/newsroom/globalfoundries-and-arm-deliver-optimized-soc-solution-based-on-arm-cortex-a-series-processors.php

    http://www.tsmc.com/tsmcdotcom/PRListingNewsArchivesAction.do?action=detail&newsid=6181&language=E

    http://www.samsung.com/global/business/semiconductor/newsView.do?news_id=1254

Slashdot Top Deals

You know you've landed gear-up when it takes full power to taxi.

Close