Forgot your password?
typodupeerror
Intel Portables Hardware

Intel Demos Phone and Tablet In New Mobile Chip Push 99

Posted by Unknown Lamer
from the we-can-make-it-smaller dept.
holy_calamity writes "Intel is making another assault on the mobile processor market, showing off a prototype phone and a tablet using its newest mobile processor Medfield. The company claims that products based on the chips will appear in the first half of next year. There's reason to believe that Intel might get somewhere this time. Its chipsets traditionally comprise three separate chips, a design that guzzles power. Medfield introduces an all-in-one chip, mirroring the power efficient design of the ARM-based chips that run smart phones and tablets in the market today."
This discussion has been archived. No new comments can be posted.

Intel Demos Phone and Tablet In New Mobile Chip Push

Comments Filter:
  • by bogaboga (793279) on Wednesday December 21, 2011 @02:11PM (#38451004)

    Surely, it is no longer the "Intel Inside" mantra we had become so used to seeing and hearing in the late 90s and early 2000s. Agree?

    • by sinij (911942)
      Your Mileage May Wary, but *I* purchase my computing devices, including CPUs, based on cost-performance analysis adjusted for ease of future-proofing. I'd still buy it if it called "S**t Inside" as long as it delivers.
    • by gasmonso (929871) on Wednesday December 21, 2011 @02:18PM (#38451072) Homepage

      Disagree! From their 3rd quarter financials...

      "Intel managed to exceed analyst predictions, posting record revenue of $14.3 billion -- up $3.2 billion, or 29 percent year-over-year. The company also set new records for microprocessor units shipped, and expects further growth over the next quarter, with notebook computer sales driving $14.7 billion in predicted Q4 revenue."

      gasmonso ReligiousFreaks.com [religiousfreaks.com]

  • by JabrTheHut (640719) on Wednesday December 21, 2011 @02:19PM (#38451084)

    ... I eagerly scan the article to see if the predictions here were true: http://www.tealdragon.net/humor/startrek/power.htm [tealdragon.net]

    "It's that miserable 80986 with the 512K bit bus multiplexed down to one pin."

    That's so Intel...

  • by timeOday (582209) on Wednesday December 21, 2011 @02:19PM (#38451088)
    That's a bit of a cheap shot. Increased component integration has been a driving force for longer than Intel has been a company, and Intel has been as much of a driving force as anybody else. In fact Intel should excel at system-on-a-chip, since it's all about getting lots of transistors on a small piece of silicon, something they happen to be pretty good at.
    • Re: (Score:2, Interesting)

      by Anonymous Coward

      That's a bit of a cheap shot. Increased component integration has been a driving force for longer than Intel has been a company, and Intel has been as much of a driving force as anybody else. In fact Intel should excel at system-on-a-chip, since it's all about getting lots of transistors on a small piece of silicon, something they happen to be pretty good at.

      Except that full system-on-a-chip designs, including X86 versions courtesy of AMD's Geode, have been around quite a while, but Intel has seemed hesitant to actually do it.

      Though I will point out that it's cyclical... at some point, people will start saying "Hey, why don't we make that bit there modular, so we can upgrade is separately without having to redesign the rest of the chip?".

    • by markhahn (122033)

      though it's interesting that Intel hasn't done much in the way of SoC until recently - they've traditionally kept the CPU quite separate from support chips. from a fab perspective, this makes a certain amount of sense, since the cpu needs transistors that perform quite differently (voltage, drive, frequency, etc) and the limited SoC integration present in, say, sandybridge, is mixed in performance (good memory and pcie controllers, mediocre gpu).

      the real question with intel mid SoCs is whether they can dr

  • by SirGarlon (845873) on Wednesday December 21, 2011 @02:20PM (#38451098)
    Apart from just rooting for different companies as if they were in a horse race, which seems to be a popular pastime in the press and blogosphere, the summary omits any reason why we might care about Intel's new offering. In what way is it different from the prevailing ARM chip? The answer is buried on page 2 of TFA:

    Intel has tested its reference handset against a handful of the leading phones on sale today. It says these tests show that Medfield offers faster browsing and graphics performance and lower power consumption than the top three, says Smith.

    and

    "Medfield is based on 32-nanometer technology, while the biggest fabs making ARM-based processors are today shipping either 40 or 45 nanometers," he says.

    So it looks like a bit of incremental leapfrog (if that), not some kind of breakthrough. Meh.

    • by Baloroth (2370816) on Wednesday December 21, 2011 @02:44PM (#38451370)

      The prevailing difference is it isn't an ARM chip. It is an x86 chip, meaning off-the-shelf x86 programs and OSes should run on it. Getting an x86 processor below the performance/power threshold of an ARM chip (while keeping it small enough to fit in a phone) is a pretty major breakthrough.

      • by Anonymous Coward on Wednesday December 21, 2011 @02:54PM (#38451492)

        Who is going to run current desktop software/OS on a mobile device that has a drastically different spec in other areas (memory, screen size, touchscreen, etc.)?

        Intel getting better performance/power threshold compared to ARM is a great selling factor; but x86-compatibility especially for off-the-shelf program isn't one of them.

        • by sgt scrub (869860)

          Who is going to run current desktop software/OS on a mobile device that has a drastically different spec in other areas (memory, screen size, touchscreen, etc.)?

          It looks like sgt scrub, Baloroth, and Gothmolly so far.

        • Re: (Score:3, Insightful)

          it is not that they are going to run the desktop software unaltered but they can recycle most of the code and simply rewrite the gui rather than rewrite from scratch

          • by vipw (228)

            Because the other portions were written in x86 assembly? I just don't get it.

            • no but just because it is written in a higher level language does not make it portable, despite that being the original intent of thing like c and java as well as many other languages

        • by bemymonkey (1244086) on Wednesday December 21, 2011 @03:22PM (#38451774)

          ARM level performance and power consumption with X86 compatibility would open up a whole new world for netbook-type devices. Think 48 hour battery life with your average 50Wh laptop 6-cell...

          • by makomk (752139)

            Except that Intel doesn't want to improve netbook-type devices because that would cut into their sales of more profitable x86 chips.

            • Hmmm, I don't see a problem with charging a premium for this tech. Say the processing power of a mid level Core 2 Duo (running a P8400 right now and that's pretty much the sweet spot for mobile computing power when it comes to me), but 3W power draw for the whole system running at full tilt including screen and radios (which is roughly similar to the iPad and other tablets)... with a 100Wh battery, you'd be looking at over 30 hours of heavy use, and far longer runtimes with more realistic use.

              I'd pay upward

        • by timeOday (582209)

          Who is going to run current desktop software/OS on a mobile device that has a drastically different spec in other areas (memory, screen size, touchscreen, etc.)?

          Smartphones and tablets are currently adjacent to (rather than replacing) PCs. But if I could have one tiny portable computer for everything and just plug it into larger peripherals for heavy-duty work, I would.

        • I'm becoming convinced this is the future direction. It sure would be handy to have a limited phone view and then a full-scale desktop interface when plugged into a docking station; a tablet like monitor could be plugged in as a secondary docking station. In either case the processing core is the size of a mobile and the interface is exchanged.
          • That is Win8 in a nutshell.
            I have a feeling (having played with it for several months now) that it will be OK, but that MS will learn a lot on this gen and Win9 will be the next WinXPEmbeded while Win7 will stay mainstream in the enterprise.
            -nB

        • Who is going to run current desktop software/OS on a mobile device that has a drastically different spec in other areas (memory, screen size, touchscreen, etc.)?

          Hence Win8, Unity, Gnome3 etc.

          Arguably, x86 support would be most important for Win8, since on Linux you'd just recompile the apps. But there are still some binary-only packages there.

      • by Gothmolly (148874)

        Mod parent up. Low power x86 = win.

    • by beelsebob (529313)

      Intel has tested its reference handset against a handful of the leading phones on sale today. It says these tests show that Medfield offers faster browsing and graphics performance and lower power consumption than the top three, says Smith.

      But have they done something like taken 3 of the fastest android phones out there, and benchmarked it against Medfield on iOS, and then performed tasks that cause Android's lack of hardware accelerated UI to suck the battery and speed out of the chip?

      • I imagine they've tested Android on x86, since they've had it running for a while now and that's the main target for 2012. iOS does NOT run on x86 at this point. The stated goal is to double the pace of Moore's law for mobile processors in the next few generations. They have the room to do this for 2-3 more cycles, which would imply intercepting ARM pretty soon.

        • by ceoyoyo (59147)

          Actually, iOS probably does run on x86. The iOS simulator runs on x86, and runs iOS programs compiled for x86.

          There's no reason Intel would try to run it on their chip and compare to Android though.

        • by beelsebob (529313)

          iOS does NOT run on x86 at this point.

          Doesn't it? Funny, I ran the iOS simulator (iOS on x86) on my Mac earlier today.

          • by Guspaz (556486)

            Saying that iOS runs on x86 because of the iOS simulator is like saying that Windows runs on PowerPC because of WINE. It's just an implementation of the iOS APIs, not the OS itself. The simulator just makes a set of iOS-like APIs available to Mac applications.

            • by Bucky24 (1943328)
              I always thought it was running the compiled iOS program through some sort of virtualized hardware.
            • by beelsebob (529313)

              Given that the APIs and apps are pretty much the only thing that differ between Mac OS and iOS, that's pretty much iOS running on x86. I'm sure it would take *very* little for apple to provide a full x86 build of iOS to intel – especially if intel is sat there saying "we have chips we could sell you".

              • by Guspaz (556486)

                True, a larger concern is that even if existing applications CAN run on x86 with just a recompile, you still need all those developers to recompile their apps. I've got more than a few apps on my phone that are no longer actively updated. I'd lose them all in a switch to x86.

                Fundamentally, it comes back to the basic question: why should Apple switch? ARM's licensing fees are cheap, Apple makes their own SoCs (and they've consistently moved in the direction of doing *more* of the design themselves, rather th

    • by Anonymous Coward

      You might possibly care because this will create additional competition in the mobile processor market which is a good thing(tm). Like all competition it will spur innovation on both sides and provide you with better, faster, cheaper products. Unless, you know, you don't like that kind of thing.

    • by alen (225700)

      the only reason ARM is more power efficient is that it's SoC. everything is on one chip so less electricity gets used traveling around the motherboard and PCI bus.

      for years intel treated Atom like a bastard with the oldest manufacturing lines when they should have put it on their newest processes. they would have killed ARM a long time ago

      • Re: (Score:3, Insightful)

        by Anonymous Coward

        This is not true.

        ARM is more power efficient because it has a simpler ISA which requires much less logic to execute. Intel chips take CISC instructions, and have a pile of optimization and translation logic to turn instructions into smaller micro-code RISC instructions. This is all necessary just to support a legacy ISA. ARM chips don't have this problem, at least to the same extreme.

        • by JDG1980 (2438906) on Wednesday December 21, 2011 @04:20PM (#38452480)
          Everyone says this, but it's nonsense. Modern x86 chips have a RISC back-end; the x86 instruction set is really more of an API than anything else. And the amount of silicon needed to do the translation is comparatively tiny. (The oldest and least-used instructions can be shunted off into microcode.)
      • by Andy Dodd (701)

        No, there's a hell of a lot of other reasons ARM is more power efficient - the core designs themselves are fundamentally more efficient than any x86 core I've ever seen.

    • Re: (Score:3, Insightful)

      by Jah-Wren Ryel (80510)

      Apart from just rooting for different companies as if they were in a horse race, which seems to be a popular pastime in the press and blogosphere,

      I'm always up for making fun of fanbois. But on reflection, I think rooting for companies is a better pasttime than rooting for professional sports. When it comes down to brass tacks, multi-billion dollar organizations like the NFL, NBA, etc are nothing more than bread and circuses. At least what these companies do has the potential to make a significant difference in people's daily lives.

    • by Necroman (61604) on Wednesday December 21, 2011 @02:54PM (#38451490)

      If you have ever touched the Android SDK, you learn very quickly that doing development on a desktop is rather painful. The main reason is their dev test environment completely emulates an ARM processor (on top of your desktop x86 system), which is extremely CPU intensive. If we get android running x86 (there are already a number of people out there working towards this), we can then do our testing in an x86 based simulator, which will be much easier on desktop system.

      • by daviee (137644)

        This is in terms of application developer. The x86 for Android is much faster than the one with ARM emulation, but is the ARM emulation speed that much of a hinder for usual development?

        What about the actual application usage by end-users? Will the x86 Android phone come with an ARM emulator to run applications that has native ARM libraries (at least until there are enough generic or x86-specific Android apps)?

        • I imagine that, since Google is partnering with Intel on this, we'll have a sort of fat binary like during the Mac's transition era from PowerPC to x86. An added benefit would be that developers stick to bytecode libraries if they want to be able to run anywhere, and everyone will benefit from the added portability.

        • by gman003 (1693318)

          What about the actual application usage by end-users? Will the x86 Android phone come with an ARM emulator to run applications that has native ARM libraries (at least until there are enough generic or x86-specific Android apps)?

          Andoid apps are run on a platform-independent, Java-esque virtual machine. All that would need porting is Dalvik, not the individual apps.

          • by Guspaz (556486)

            Unless that app was written with the Android NDK, or links to a library built with the NDK. Then it's running native code, and is not platform independent.

        • by expatriot (903070)

          Android on ARM development on an ARM-based laptop would give the best of both worlds. Remember that ARM has not had any motivation for high-performance chips until recently. The ARM11 was fast enough for almost all phone and embedded applications. Within two years there will be eight-core 64-bit socs with high performance GPGPUs.

      • by sgt scrub (869860)

        If we get android running x86 (there are already a number of people out there working towards this), we can then do our testing in an x86 based simulator, which will be much easier on desktop system.

        Very interesting comment. It might be possible to create a VServer instance and install the SDK. There wouldn't be any emulation needed.

      • But why use the emulator if you can debug directly on a physical device attached to the USB port of the PC. Works much better and easier to test as some sensors cannot be emulated easily. Use a physical device for devlopment and the emulator for automated unit testing.

      • If we get android running x86 (there are already a number of people out there working towards this)

        Actually, I am running Android on my x86 tablet [android-x86.org]. The speakers and touch screen don't work so you have to plug a mouse, and it's unstable, but it does run already.

      • by Anonymous Coward

        Or, alternatively, we need an ARM desktop machine.

    • by tyrione (134248)

      Apart from just rooting for different companies as if they were in a horse race, which seems to be a popular pastime in the press and blogosphere, the summary omits any reason why we might care about Intel's new offering. In what way is it different from the prevailing ARM chip? The answer is buried on page 2 of TFA:

      Intel has tested its reference handset against a handful of the leading phones on sale today. It says these tests show that Medfield offers faster browsing and graphics performance and lower power consumption than the top three, says Smith.

      and

      "Medfield is based on 32-nanometer technology, while the biggest fabs making ARM-based processors are today shipping either 40 or 45 nanometers," he says.

      So it looks like a bit of incremental leapfrog (if that), not some kind of breakthrough. Meh.

      The statement about faster graphics is bull shit. ARM doesn't make GPGPUs. ImgTec makes them and sorry but Intel's OpenCL and OpenGL graphics against the VR tech from ImgTec version 6 is nowhere near their 600 series that has OpenCL 1.1/2.x and OpenGL 3.2 full support. That's right up there with Intel claiming it's graphics support compares to Nvidia and AMD. It's a crock of shit.

  • Faster than the current top 3. Hmm not really surprising since you are demoing something 6 months out. What does ARM, or Apple have coming up in 6 months? Still good to see Intel come out with a much stronger offering.
    • by Guspaz (556486)

      Today: 1.5GHz 45nm dual-core Cortex A9 or 1.3GHz 40nm quad-core Cortex A9
      3-6 months: 2.0GHz 32nm Cortex A15.

      Samsung expects to get that out in 2012Q2, which would be in less than 6 months. Inside of 2012, we should also see 28nm Cortex A15, as well as quad-core parts.

      So, the problem is that Intel is touting these performance advantages for their next-gen part, but are comparing it to current-gen ARM stuff. An accurate comparison would be between the next-gen Atom and the next-gen ARM, since that's what it'l

  • Since Intel and Samsung are the driving forces behind Tizen, a new "open" Linux project for phones and tablets, maybe we will see Tizen running on this processor next year? When I say "open" I mean as in door; full access without jail breaking. Although the details about Tizen are still murky, at best.

    Or maybe Mer, the folks who are picking up where Meego left off, could use this. But they need to get a hardware manufacturer on board.

    • Intel was also the driving force behind Meego and Moblin and Maemo and lost interest in all of them.

      Intel is terrible at seeing software through to completion, other than their compiler.

      • by Microlith (54737)

        Err, no. Intel has continued to be a driving force behind them, despite the setbacks. Moblin merged with Maemo because Nokia approached them with the goal of creating something that wasn't so tied to one vendor, and created MeeGo. Then MeeGo got taken over by Microsoft, damaging the relationship and catching MeeGo in the middle. So Intel has gone off looking for another partner and found Samsung.

        And since it looks unlikely that Samsung is going to drop everything and go Microsoft-only, I doubt that we'll se

        • by Microlith (54737)

          Then MeeGo got taken over by Microsoft

          should read

          Then Nokia got taken over by Microsoft

  • If it's Windows 8, penetration may be in the single digits. In the tablet marketplace, Microsoft, and by extension Intel based processors, are not major players. It's not just the power consumption. I've heard a rumor that Android would be ported to X86, but how will that work, I wonder? Would there be a separate marketplace? Development requirements to compile and test on two different architectures?

    • by Anonymous Coward

      I've heard a rumor that Android would be ported to X86, but how will that work, I wonder?

      Did you read TFA?
      From page one of the article:

      The phone prototype seen by Technology Review was similar in dimensions to the iPhone 4 but noticeably lighter, probably because the case was made with more plastic and less glass and metal. It was running the version of Google's operating system shipping with most Android phones today, known as Gingerbread; a newer version, Ice Cream Sandwich, was released by Google only about a month ago.

      From page two of the article:

      Intel's reference tablet, which used the same Medfield chip as the phone, was running the latest version of Android, Ice Cream Sandwich. It had a slightly larger screen than the iPad 2 but was about the same in thickness and weight. A limited trial suggested that it was noticeably nicer to use than older tablets based on the abandoned Honeycomb version of Android.

    • by Belial6 (794905)
      There would be no need for a separate marketplace. The current marketplace will filter based on device. The only apps that should have a problem with a processor change are the ones that use the NDK. This is why I would rather have developers stick to the standard SDK whenever possible. Processors will get faster, but they don't become more compatible.
    • I can tell you Android runs on x86 already [android-x86.org], albeit in an unstable state. I expect with Intel behind this, things will develop faster. Regarding the compatibility issues, Android is bytecode with only specific libraries compiled natively, and they're being ported. I imagine we'll see some sort of fat binary support for both architectures on the Android Market.

      • by ensignyu (417022)

        Google TV currently runs on Atom (x86) hardware. I'm guessing the main issues for broader x86 support are drivers and performance.

    • by ceoyoyo (59147)

      iOS apps virtually always compile for both x86 and ARM, with no distinction. Why shouldn't Google be able to do the same thing?

      • by roc97007 (608802)

        I have no idea why Google shouldn't be able to do the same thing. But before I touch an Intel tablet, I'd want to know what I'm getting into. If it isn't completely interoperable with ARM devices in the Android universe, it's not interesting. And Windows 8 is a complete non-starter.

    • Microsoft, and by extension Intel based processors, are not major players. It's not just the power consumption.

      Yes, it's the fact that Windows was simply not designed for touch-centric mode of use. Not even the various "Tablet PC" editions, which really required a stylus to be useful.

      However, the whole point of Win8 is that it is designed for touch - that's what the new Metro stuff is all about. And yet it will still run old x86 apps if you need them. And if it'll also have a 12-hour battery life, like Transformer Prime does? pray tell, why wouldn't it be a major player?

      • by roc97007 (608802)

        > However, the whole point of Win8 is that it is designed for touch - that's what the new Metro stuff is all about. And yet it will still run old x86 apps if you need them. And if it'll also have a 12-hour battery life, like Transformer Prime does? pray tell, why wouldn't it be a major player?

        I've looked at Metro, and it looks like repurposed Windows 7 Mobile and Windows Media Center stuff. Indications are, Windows 8 was a small amount of "designed for" and a much larger amount of "rebrand and reuse the

      • by roc97007 (608802)

        Something to think about: The various *nix solutions tend to fall into a pattern -- a GUI for KVM (OSX, Ubuntu) and a different GUI for touch devices (iOS, Android). This is because touch is a whole different paradigm from KVM and trying to make one GUI do both leads to incompatible design decisions. Mind you, the underlying OS can be the same (if it's decent, and supports resources required by both paradigms). But the actual interface design choices are radically different. In the past, Microsoft has

        • Something to think about: The various *nix solutions tend to fall into a pattern -- a GUI for KVM (OSX, Ubuntu) and a different GUI for touch devices (iOS, Android).

          True. This is exactly what Win8 does, too, except it lets you switch between two modes as you go.

          What I see in Windows 8 is not so much a different interface as a different marketing campaign.

          Are you seriously claiming that Win8 Metro is "not so much a different interface" compared to classic desktop?

          • by roc97007 (608802)

            > True. This is exactly what Win8 does, too, except it lets you switch between two modes as you go.

            ...which means that as a practical matter you'll be able to play music from the Metro interface but will always have to drop back into the KVM interface to get work done. That's not a tablet, it's a computer that happens to have a touchscreen. So, for instance, we have a Windows Media Center, but the media center interface has just enough drawbacks (example: will not play mkv files, which requires exitin

            • ...which means that as a practical matter you'll be able to play music from the Metro interface but will always have to drop back into the KVM interface to get work done.

              The same goes for iPad and Android, except that you have to "drop back" to a different device in that case.

              Your basic argument is flawed from the get go because you assume that Metro has something in common with WMC. Not only it doesn't, the far more important point is that it's extensible in the same way iOS is - you install Metro apps that let you things you need to be done.

              Microsoft, on the other hand, appears to see the touch interface as an additional feature that might control simple things

              Not true either. If anything, the classic desktop in Win8 feels more like an "additional feature", what with Start menu's replacemen

              • by roc97007 (608802)

                >> ...which means that as a practical matter you'll be able to play music from the Metro interface but will always have to drop back into the KVM interface to get work done.

                > The same goes for iPad and Android, except that you have to "drop back" to a different device in that case.

                At the moment. Adobe has some ports coming out that promise to sever my last connection to the PC. And I'll let you in on a secret -- I don't own a tablet yet, of any kind. I own an Android phone because Microsoft make

  • When someone shows it has battery life comparable to the current dual-core ARM A9 SoCs, then they will have something to talk about. Until then, it's just a PR pipedream.

  • How many times Intel has tried to compete against Risc?

    First, ð [wikipedia.org]ere was ðe iAPX 432 [wikipedia.org]. I never saw any use of it.

    Ðen ðere was ðe i80860 [wikipedia.org], today remembered for being ðe demonstration vehicle to Microsoft OS/2 3.0 NT.

    Next try, ðe i80960 [wikipedia.org], was actually succeß [wikipedia.org]ful — in printers, network and I/O controllers.

    Ðen we had Merced, later named Itanium [wikipedia.org], AKA Itanic, ðe biggest flop around.

    Intel actually ditched perfectly fine StrongARM [wikipedia.org] and Alpha [wikipedia.org] architectures it bought

    • How many times Intel has tried to compete against Risc?

      [...]

      Forgive me, but colour me skeptic this time around.

      It's true that Intel hasn't achieved great success with it's own RISC designs, but what about the times that Intel competed using its CISC designs against:

      • Alpha? [wikipedia.org] (You mentioned Alpha as something that Intel threw out, no something that it competed against)
      • SPARC? [wikipedia.org]
      • POWER? [wikipedia.org]

      It's also worth noting that all of the modern ARM-based SoCs that Medfield will compete against are CISC designs, not RISC, so I guess my list doesn't even matter :-/

      • > It's true that Intel hasn't achieved great success with it's own RISC designs, but what about the times that Intel competed using its CISC designs against:

        []

        > It's also worth noting that all of the modern ARM-based SoCs that Medfield will compete against are CISC designs, not RISC, so I guess my list doesn't even matter :-/

        Yes, but all ðese were hampered in ðe desktop by ðe prevalence of binary, proprietary software. While binary, proprietary software also dominates ðe mobile market, it is compiled against iOS and Android, where it is Intel, not Risc, which fights an uphill battle.

        Ðat, and talking about a proceß-derived advantage in a not yet ðere product is easy. Most probably ARM (and MIPS) will be already ðere if and when Intel hits ðe shelves.

        Now, how is ARM Cisc? Last time

        • Now, how is ARM Cisc? Last time I checked, it stood for Advanced Risc Machines has technology subverted the acronym?

          ARM chips since ARMv7 have supported the Thumb-2 instruction set, which has 32-bit instructions with CISC features like making an optional left shift available to most instruction, and allowing each comparison to be followed by up to four conditional statements. It's what most JIT and my compilers target now, IIRC.

          While binary, proprietary software also dominates the mobile market, it is compiled against iOS and Android, where it is Intel, not Risc, which fights an uphill battle.

          It's absolutely true that it's Intel whom must the uphill battle here. The fact that many Android applications are compiled to DEX, and the emergence of HTML5 runtimes offer some relief. I stil

          • by leandrod (17766)

            ARM chips since ARMv7 have supported the Thumb-2 instruction set, which has 32-bit instructions with CISC features like making an optional left shift available to most instruction, and allowing each comparison to be followed by up to four conditional statements. It's what most JIT and my compilers target now, IIRC.

            Ðat is quite different from being a Cisc proceßor in ðe mobile market, being able to choose some Cisc instructions wiðout carrying ðe full Cisc legacy is an advantage. And ARM has chosen ðe Thumb 2 instructions not to go back to Cisc, but to achieve a code density which is a furðer advantage over anything Intel can do wiðout throwing out its only real competitive advantage, which is ðat people are familiar with ðe x86 instruction set. Not ðat it buys

My idea of roughing it turning the air conditioner too low.

Working...