Intel and LG Team Up For x86 Smartphone

gbjbaanb writes "I love stories about new smartphones; it shows the IT market is doing something different than the usual same-old desktop apps. Maybe one day we'll all be using super smartphones as our primary computing platforms. And so, here's Intel's offering: the LG GW990. Running a Moorestown CPU, which gives 'considerably' better energy efficiency than the Atom, it runs Intel's Linux distro — Moblin. Quoting: 'In some respects, the GW990 — which has an impressive high-resolution 4.8-inch touchscreen display — seems more like a MID than a smartphone. It's possible that we won't see x86 phones with truly competitive all-day battery life until the emergence of Medfield, the Moorestown successor that is said to be coming in 2011. It is clear, however, that Intel aims to eventually compete squarely with ARM in the high-end smartphone market."

Comments

Intel and LG Team Up For x86 Smartphone

[omar.sahal]

compete squarely with ARM in the high-end smartphone market

How can they do that when producing an ARM processor cost only ARMs royalty + costs added on from many producers (Texas instruments qualcomm et al).

Re:Intel and LG Team Up For x86 Smartphone

[Anonymous Coward]

I guess by adding greater capability.

Re:Intel and LG Team Up For x86 Smartphone

[Locutus]

To top it off, Intel has to use their highend processing factories to get the chips in the ball park as ARM. They just announce the 32nm Atoms along with their new i3, i5 and i7 all on the same process. But as you mentioned, they have to sell the Atom far far far cheaper than the iX CPUs to be competitive. IMO, the FTC should look into this to make sure their not dumping. Atleast with main PC CPUs, they charged high prices at first and then ramped the price down as the newer processes started to come online. With these Atoms, they can't charge what they cost and still be competitive.

And these new phones will probably have a fan and require 2GB of memory so it can run Windows. lol. If they only talk about Gnu/Linux then we'll know they are serious but if they pull Microsoft in, you know it's a PR game and like the netbook segment, it'll run the prices up so high few will want them.

LoL

Re:Intel and LG Team Up For x86 Smartphone

[JackDW]

Part of the plan would surely involve getting into the IP core business, like ARM. AMD are doing it, and some Intel researchers already have a prototype.

Re:Intel and LG Team Up For x86 Smartphone

[KazW]

compete squarely with ARM in the high-end smartphone market

How can they do that when producing an ARM processor cost only ARMs royalty + costs added on from many producers (Texas instruments qualcomm et al).

I hate quote mining... You should have used the entire sentence, because you might have had to re-read it and you might have picked up on a key idea of the sentence. I think you did notice though, because your quote conveniently starts just after that word, which makes your post a troll in my eyes, and you're lucky I don't have mod points this week.

It is clear, however, that Intel aims to eventually compete squarely with ARM in the high-end smartphone market.

Re:Intel and LG Team Up For x86 Smartphone

[sznupi]

...and order of magnitude less power usage for the same performance. Meaning less problems with heat, smaller battery, much smaller phone with comparable performance.

There is no benefit of x86 on smartphones that could drag Intel into this market, quite the contrary; ARM is established, and working very fine.

Re:Intel and LG Team Up For x86 Smartphone

[omar.sahal]

Ok, that makes sense then. Mod this up.

Re:Intel and LG Team Up For x86 Smartphone

[Totenglocke]

How can they do that when producing an ARM processor cost only ARMs royalty + costs added on from many producers

I was going to ask, how can they compete when x86 processors cost an ARM and a leg!

Re:Intel and LG Team Up For x86 Smartphone

[beelsebob]

Show me 125,000 windows 3.1 applications and I'll be impressed.

I'd be pretty impressed if you could do that for Windows 98 these days even.

Re:Intel and LG Team Up For x86 Smartphone

[Pentium100]

I don't need 125000 apps in my phone.

Only Win98SE, MS Office, Opera/Firefox (whichever has a newer version that still supports 98), some media player, pdf reader.

I can also write my own apps for it in Delphi7 (Delphi does not work on Linux).

Re:Intel and LG Team Up For x86 Smartphone

[MaraDNS]

Opera/Firefox (whichever has a newer version that still supports 98)

That would be Opera. Firefox, as of Firefox 3, no longer supports Windows 98 (this caused a lot of grumbling on Firefox's support forums), but the latest Opera happily runs on Windows 98.

I can also write my own apps for it in Delphi7 (Delphi does not work on Linux)

If you're an old-school Delphi programmer, you might look in to Lazarus. It's 95% Delphi, but FOSS software.

While I'm mainly a C programmer these days, I've quite impressed with Delphi: There is an excellent tiny little Civilization clone, C-evo, out there written in Delphi (that fits on a single floppy if you remove the sounds and 7-zip compress it), as well as a free (beer) office suite called SSuiteSoft.

Re:Intel and LG Team Up For x86 Smartphone

[JackDW]

While I certainly would not want Windows on my phone, any system capable of running legacy x86 applications would need to be open. On such a system, you would be able to develop applications without a proprietary SDK, and you'd be able to sell your applications without going through the vendor's App Store and dictatorial application approval process. To me, these are invaluable benefits.

Re:Intel and LG Team Up For x86 Smartphone

[Pentium100]

I am not that much of a programmer, I use Delphi, because it has the same syntax as Pascal which I learned some time ago. My programs are usually simple (a decent programmer could probably make one in an hour), for example a batch youtube video downloader that automatically selects the best available quality. I googled for such program, but could not find one I like, so I wrote it myself.

Re:Intel and LG Team Up For x86 Smartphone

[Chees0rz]

IMO, the FTC should look into this to make sure their not dumping. Atleast with main PC CPUs, they charged high prices at first and then ramped the price down as the newer processes started to come online. With these Atoms, they can't charge what they cost and still be competitive.

Hate Intel for their integrated graphics, software packages, chipsets, or CPUs. But you cannot hate on their manufacturing process (which is 1st class). Your comment ignores the fact that Intel is at 32nm, which brings costs way down, and the atom is a TINY cpu compared to the core series (duh). Yield cost is directly related to die size. Looking @ the numbers below I pulled from a simple google search and you'll see that these chips (in the millions) will cost much less to make...

Some interesting numbers:
Atom @ 45nm process: 26mm^2
Corei5 @ 32 nm process: 81mm^2 (or 296mm^2 w/ gfx)

The FTC can investigate for other reasons... but not because they are making smaller chips cheaper than bigger chips.
sources: http://www.neoseeker.com/Articles/Hardware/Reviews/intel_core_i5_661/
http://en.wikipedia.org/wiki/List_of_Intel_Atom_microprocessors

Re:Intel and LG Team Up For x86 Smartphone

[BikeHelmet]

Why? I would be happy if my cellphone could run Windows NT or 98. They do not require a lot of CPU power and are much more compatible with modern Windows versions than Linux, Symbian or whatever other smartphone OS.
I would be happy even with Windows 3.11. There is a lot of software even for this version.

LOLOLOL

I'm sorry, that's the only response this deserves. Tons of modern FOSS software is Win32/Linux. More will run on Linux than Win98. And that's if you ignore the backend enhancements. Linux has vastly improved hardware support, and lower memory usage. (most smartphone OS's use less memory than Win98 did - obviously a desktop distro like Ubuntu is another story)

You would rather have an exploit filled BSOD'ing OS with pitiful hardware support and lacking modern software instead of a stable and more streamlined OS with modern cross-platform software and a more intuitive skinnable UI?

I repeat:

LOLOLOL

Re:Intel and LG Team Up For x86 Smartphone

[Locutus]

Atom on 45nm is old news, it's how they got into the game while the ARM systems were still on 65nm. Now that many ARM processors are going to 45nm and getting multi-core and over 1GHz speeds, it forced Intel to bump their 32nm process plan forward. This is why I brought up the FTC comment. As long as Intel is really charging fair prices based on cost then all is good. But, they normally charge high prices for new chips on the new process tech and I questioned if they were going to charge a comparable price. Show the 32nm Atom sizes and some pricing and we should be able to tell if it really is $/mm^2 they are charging.

I doubt that is the case. Like I said, using the same silicon process they use for their new high end chips and selling them at prices to compete with much smaller and cheaper ARM chips sounds like it would have to be subsidized. BTW, the ARM chips are being sold in the millions too because they are in all these smartphones.

I'm surprised Intel isn't using some of their other CPU tech to compete instead of trying to go x86 since all that baggage is not needed or used in these smartphones. And I've already read that some ARM systems are going to be built on some of AMD's factories at sub45nm real soon. Intel is going to have to rely on PR more than tech or it'll be eating up way too much of their wafer space for very little return just to keep up.

It is good to see the game get interesting again and competition pushing things ahead.

LoB

Re:Intel and LG Team Up For x86 Smartphone

[Anonymous Coward]

Because high end "smartphones" are way more expensive than the MID I already own (the Viliv S5: http://www.umpcportal.com/2009/05/viliv-s5-premium-umpc-full-review/ ).

Some information:
1) If you're comparing it to the previous generation (like the S5), you should probably say "Running a Moorestown CPU, which gives 'considerably' better energy efficiency than the Menlow platform" to be consistent with your naming, since those are both the family code names for the processors in that family. I think Intel is still going to call Moorestown stuff "Atom processors."

2) You can install Windows or whatever x86 OS you want on an MID (which Moorestown devices are), you're not limited to Moblin (though it certainly is well optimized). Therefore you can use whatever applications you want, this is x86.

Personally, I love it, and I'd never trade it for some ARM crap, it's hugely convenient to have the gigantic program base of x86, you don't have to rely on the slow support chain of the company you purchased your device from.

3) I'm sure battery life on Moorestown must be ridiculous, because my Menlow device (Viliv S5) already has a better battery than my old laptop (which it completely replaced for half the cost). I can run XP with the screen on for 5 hours, easily. If I turn on my music player (through Windows) and leave it playing through external speakers on a loud volume with the screen off, it can last 12-15 hours.

That's a lot longer than I can talk on my phone before it dies (not even a smartphone, and it's brand new with a new battery).

4) Oh, and my Viliv S5 has 1 GB of RAM, 32 GB SSD hard drive, 1.33 Ghz processor, no fan, doesn't overheat, and cost $550.

I'm sure Moorestown specs will be even more impressive.

----------

Long story short, this isn't a new device, just none of you know about the devices that have been on the market since 2007.

Re:Intel and LG Team Up For x86 Smartphone

[TheRaven64]

Atom @ 45nm process: 26mm^2

For reference, a Cortex A8 is a little under 9mm^2 on a 65nm process. Clock for clock, it performs better than Atom for some workloads, worse for others, but is roughly comparable. For the same transistor budget as an Atom, you get an entire ARM SoC. An OMAP3530 was only 60mm^2 on a 65nm process (I think TI is using 45nm now), which gives you a Cortex A8, a PowerVR GPU (OpenGL ES 2.0), a DSP, and all of the controllers you're likely to need (Flash, memory, USB, and so on).

Atom does quite well against the A8, but can't touch the A9 or Snapdragon in either performance or power usage.

Re:Intel and LG Team Up For x86 Smartphone

[bhtooefr]

First, what other CPU tech? Intel sold off quite a lot of the XScale tech to Marvell, Itanium is fail, i860 and i960 have gone away. x86 is all they've really got.

Second, let's say they did have other CPU tech that was viable. Right now, Intel is very, very heavily invested in x86. They're benefitting greatly from x86 owning the desktop market - AMD and VIA are their bitches, basically.

Intel likes x86 lock-in. x86 lock-in means that everyone has to either go through them, or someone who has to license technology back to them.

Sounds like...hell!

[syousef]

Maybe one day we'll all be using super smartphones as our primary computing platforms.

Oh I sure hope not. Sounds like hell to me, and I'm an aetheist!

Re:Sounds like...hell!

[Hurricane78]

Well, that’s only your lack of imagination.

Imagine a very powerful cell phone. With super-fast bluetooth. (Or wired bus if you prefer that.)
Now imagine a normal screen, keyboard, mouse, and speakers/amplifier. All with bluetooth.
There. If the speed and storage size are good, that’s all you usually need.

Now imagine a dock where you put the phone in, to give it monstrous 3d hardware acceleration capabilities, or something else that needs a faster bus than bt can provide.
Then you got games and professional use covered too.

Finally one or multiple contact-lens displays, glasses, and a gesture glove reduced to some tiny ring or something. (There is something better, but I can’t talk about that right now.)

I don’t see what’s missing there...

Re:Sounds like...hell!

[ColdWetDog]

Oh I sure hope not. Sounds like hell to me, and I'm an aetheist!

Perhaps maybe just purgatory. But it could work. Carry your uberdevice in your pocket (lead foil lined), use it with it's native human interface devices when wandering around. Pop it in some sort of dock at work with a decent keyboard, mouse and screen. Remember to pick it up before you go home.

Obviously this sort of thing raises a number of issues and problems and the hardware in a smart phone just can't compete with a real computer for now for anything other than email / browsing / light apps. I'd love it at the hospital that I work - walk around the bedside inputting data, looking up things, pop the thing in the dock at the nurses station, look up an xray on a decent monitor, type in some notes, get up and walk around some more.

Right now I have to scribble stuff on paper, walk over to a generic computer, log in to several different applications, gripe because Firefox isn't on this particular machine or doesn't have a utility that I like, actually do something useful, then log out of everything, rinse and repeat.

So it might not be as bad as you envision it. Of course, this sort of thing requires significant multi vendor coordination and standards, so I don't hold out much hope for it. I guy can dream ...

Re:Sounds like...hell!

[SirWinston]

I don't see smartphones as our future primary computing platforms...or even as our future mobile computing platforms...in fact, I don't see them in the future at all. My guess is that--considering how texting and mobile browsing seem to be a larger part of the future than voice--we'll see touch tablets too large to be called phones but small enough to be reasonably portable take over eventually, with a tiny bluetooth or successor earclip or earbud headset for voice calls over the tablet's wireless internet connection.

The mobile tablet will be our primary computing device, and our own mobile wireless hotspot. The desktop computer will be largely relegated to the office, as most home users will be happy using their tablets for basic use and wirelessly displaying their contents on their large flatscreen TVs for other uses. Power users will still have home desktop computers, but most people won't need them.

The future is indeed portable--but it ain't a tiny phone. The phone itself is just going to disappear into the mobile internet tablet, with a bluetooth earpiece as its last vestige.

Re:Sounds like...hell!

[Anonymous Coward]

Actually the Celio Redfly Mobile Companion would give a "taste" of that. Its 7- or 8-inch screen (depending on model) provides a nice display of a 800x480 pixel view of a (supported) Windows Mobile Smartphone, and the keyboard is quite decent compared to any of those pathetic slide-out or onscreen attempts at providing rapid text entry (in QWERTY layout no less - where's the Dvorak "innovation" to let thumbs learn a more efficient layout since they have to learn something new anyway?).

I tried the 7-inch model for a few weeks, but returned it since the phone's CPU and software did not really provide the netboook/MID experience the bigger screen almost demands. It is much more efficient with a phone like that (XV6700) to use it to tether a more capable device such as a netbook or MID like my Nokia N810, either of which cost less than a Redfly. Those devices make much better use of the phone's data bandwidth than the phone could with its onboard apps.

Now the idea of such a dock/terminal for a much more powerful smartphone along the lines of an Android-based model or even a phone-sized successor to this GW990 gets much closer to a synergy that provides what you seek. A little intelligent design for this evolution could have big payoffs.

RO

Re:Sounds like...hell!

[AmberBlackCat]

If all that can be fit into a cellphone, imagine what can be fit into a laptop or desktop...

Re:Sounds like...hell!

[Anonymous Coward]

The aetheist part says it all, you dumbass.

Re:Sounds like...hell!

[cntThnkofAname]

That all sounds so complicated... wouldn't it be easier to add a GSM antenna in my laptop and shrink it to fit in my hand?

Re:Sounds like...hell!

[Anonymous Coward]

Now imagine trying to refresh a normal size screen display over bluetooth. You really haven't thought this through, have you?

Re:Sounds like...hell!

[Anonymous Coward]

I actually read an interesting blog just the other day (www.yellowsquared.com) where they were talking about the future and how in their opinion smartphones would replace people's computers. They saw the rise of Software as a Service applications where more processing is done server side as a possible solution to the problem of limited processing power on mobile devices.

Wouldn't work for all applications though I guess. I can't really imagine doing any graphics work using a web based app!

Re:Sounds like...hell!

[Urkki]

Oh I sure hope not. Sounds like hell to me, and I'm an aetheist!

Perhaps maybe just purgatory. But it could work. Carry your uberdevice in your pocket (lead foil lined), use it with it's native human interface devices when wandering around. Pop it in some sort of dock at work with a decent keyboard, mouse and screen. Remember to pick it up before you go home.
 

At least Maemo can do this today for real. The "docking station" will just have to be a PC running VNC and phone needs to connect to it with WLAN or USB. There are also other possibilities (like running phone apps on PC X server instead of the phone X server), but VNC is the most universal and easy one I think. Is there a VNC server for Android yet, or even for iPhone?

Or then you could use cloud apps, they do work at least technically (at least Maemo5 stock browser, and I assume also mobile-Firefox release candidate, can run for example Google Docs and Google Wave), though user interfaces would need some serious optimization for touchscreens and crappy keyboards... But I bet at least some of the cloud apps available are bound to be pretty good on phone browsers.

Or then you could use network disk shares to store documents, and edit them in-place, whether using a phone/tablet or a PC.

But the point is, what you describe is possible today. This future started already last year :-).

Competition

[Anonymous Coward]

Has anyone made a scatter plot of benchmark score vs watt, for a given benchmark and various x86 and ARM processors?

Intel

[mxh83]

Times are rough for Intel, I read that their processor proposed for the Apple tablet was ditched in favor of one from a smaller company. These big companies somehow seem glacial compared to the more agile competition. They are all going to be forced to really innovate now.

Re:Intel

[RAMMS EIN]

You seem to be saying that Intel doesn't innovate. I beg to differ. I see a fair bit of innovation coming from Intel, even if not all of it ends up taking the market by storm.

Re:Intel

[mdwh2]

Citation? Has the Apple tablet moved beyond rumour yet?

Times must be tough for Intel if they're even getting turned don for non-existent vaporware. They'll have to focus their efforts on real products instead :)

Re:Intel

[mxh83]

http://www.guardian.co.uk/technology/blog/2010/jan/06/apple-tablet-chip-leaks-latest The tablet is real, if you were paying any attention to news and patents, you'd know that. It will most likely be announced around Jan 27.

Re:Intel

[mxh83]

What is this "innovation" you refer to? Adding more cores? Surely you can't mean moblin?

Re:Intel

[mxh83]

More specific link http://www.thestreet.com/story/10656904/1/exclusive-apples-tablet-has-no-intel-inside.html

Re:Intel

[moosesocks]

Intel's style of innovation seems to be quite similar to that of Microsoft. Although both companies have extremely capable R&D departments that regularly do churn out exciting and innovative research, the stuff that makes it into actual products is largely a rehash of whatever AMD/Apple did 2 years ago.

Wow, that's big

[Overzeetop]

I know...that what she said...

Anyway - that's a pretty damned big phone. I'm more excited about the possibility of dual processor netbooks (or any notebook) with a fast processor and a ULV/super efficient processor that can shif on the fly to get a day's use if you're just surfing, or 3-4 hours of hot-n-heavy processing, without a 4 pound battery.

I guess on the x86 front, it's not much use if I'm stuck with a limited set of apps. I'm still waiting for a really good mobile browser, and it would be awesome to get some of my discipline-specific utility apps on a phone. Of course, that means windows, since that's all the apps are written for. So I guess this is cool for what it is, but it's still a pretty long stretch to get to useful.

PS - why would they indicate the capacity of the battery at 1850mAh without a voltage of the pack? I thought tech reporters at CES were supposed to be better than this.

Re:Wow, that's big

[ickleberry]

It's probably lithium ion or that variety so 3.7v or 7.4v if they are using two cells in series.

Twould be interesting if you could simply format this phone and put your own OS on it.

Do Not Want

[marcansoft]

Here we have a platform where there is no reason whatsoever to have an ass-backwards-compatible architecture in order to run legacy Windows apps. There is zero reason to use x86 here other than marketing and Intel. Please go away, we're perfectly happy with a modern RISC architecture (ARM), thank you very much.

Here's to hoping that ARM will permeate its way up into the netbook market and beyond, instead of the other way around. We've been tortured by x86 long enough already.

Re:Do Not Want

[TorKlingberg]

I am honestly curious: What advantage is a "modern RISC architecture" if you are not writing in Assembly anyway?

Re:Do Not Want

[91degrees]

RISC was actually developed because most people were using compilers, so instructions for things such as BCD and ASCII and such were seen as a pointless waste of silicon.

The main point of RISC is that it's cheaper. This isn't about penny pinching. It means that a chip of the same cost can work faster.

Plus if we're looking at any modern CPU vs. x86, the extra registers are very useful for optimisation. It's a lot easier to keep a value in a register if there are more of them.

Re:Do Not Want

[Anonymous Coward]

I am honestly curious: What advantage is a "modern RISC architecture" if you are not writing in Assembly anyway?

A competitive OS marketplace not undermined by a Windows monopoly?

Re:Do Not Want

[marcansoft]

The x86 CISC instruction set is so convoluted and ancient that x86 CPUs spend a lot of die area (and power) dealing with it and the weird ways that extensions have been tacked over time. The fact that it's old also means the CPU requires tons of logic because the instruction set was designed for simpler, less well performing CPUs. Newer techniques to speed things up usually work best with software support, while x86 CPUs have to implement these older techniques and then add a compatibility layer to make them work seamlessly with the old instruction set and old OSes that know nothing about them.

One large difference between ARM and x86 that people rarely realize is that ARM only (usually) guarantees compatibility at the application (usermode) level, while x86 has to maintain compatibility down to the OS (kernelmode) level. ARM is free to update their architecture, add features required for modern performance, and require that the OS deal with them. This is hardly an issue because OSes adapt fast these days and the ARM market has no dependency on ancient OSes. x86 still has to deal with the fact that some nutjob might want to run Windows 3.11. Even when x86 does implement newer stuff, like the SYSCALL and SYSRET instructions that aim to replace the ancient and slow software interrupt system call mechanism, OSes are slow to adapt and the CPU still has to carry around the logic for the old crap. Forever.

Re:Do Not Want

[TheRaven64]

Simpler decoder. The instruction decoder is the one part of a CPU that you can't turn off while executing anything. An x86 decoder is much more complicated than, for example, an ARM decoder, so the minimum operating (i.e. not suspended) power consumption for the CPU is higher.

An x86 chip has weird instructions for things like string manipulation that no compiler will ever emit, but which have to be supported by the decoder just in case. The usual advantage that x86 has over RISC chips is instruction density. Common instructions are shorter (actually, older instructions are shorter, for the most part, but old has quite a high correlation with common) and there are single instructions for things that are several RISC instructions, meaning that they can get away with smaller instruction caches than RISC chips.

This doesn't apply to ARM. ARM instructions are incredibly dense. Most of them can be predicated on one or more condition registers, which means that you often don't need conditional branches for if statements in high-level languages. More importantly, there are things like Thumb and Thumb-2, which are 16-bit instruction sets suitable for a lot of ARM code, but which get very good cache density. Unlike x86, these are separate instruction sets. This means that the core can turn off the decoder hardware for the full ARM chip while in Thumb mode, and turn off the Thumb logic while in ARM mode. This gives you x86-like icache density and RISC-like decoder complexity, so you have the best of both worlds.

Re:Do Not Want

[aristotle-dude]

I am honestly curious: What advantage is a "modern RISC architecture" if you are not writing in Assembly anyway?

Your higher level language still has to run on a platform which has to do hide all of the nasty memory address space stuff and sometimes that architecture can come back and bite you in the arse. Take running 32bit X86 apps like VS.NET on X64 Windows Server 2008 for example. That application will come down on you faster than a crack whore if you don't run a wrapper to make it large address space aware and to patch the memory fragmentation problems with WOW (Windows on Windows). Granted, much of that is caused by bugs in Windows on windows but companies like Apple had to work that much harder to make sure that their OS handled 64bit apps running in 32bit OS mode and 32bit apps running in 64bit OS mode of Snow Leopard.

Re:Do Not Want

[TheRaven64]

The x86 CISC instruction set is so convoluted and ancient that x86 CPUs spend a lot of die area (and power) dealing with it and the weird ways that extensions have been tacked over time

It's worth noting that how true this is depends a lot on the market that the chip is aimed at. An Atom and a Xeon both have approximately the same number of transistors dedicated to decoding instructions. In the Atom, it's a noticeable chunk of the total, both in terms of die area and power consumption. In the Xeon it's an insignificant amount.

The x86 decoder was a big problem comparing something like a 386 to a SPARC32. The SPARC32 could use the same number of transistors but have a far higher percentage devoted to execution units. Comparing a Core 2 to an UltraSPARC IV, it's not nearly as relevant. The percentage of the die dedicated to the decoder is pretty small on both and the difference between using 1% of your transistor budget for the decoder and 2% is not significant. Particularly when the more complex decoder lets you get away with a smaller instruction cache.

When you scale things down to the size of an Atom or a Cortex A8, the difference becomes significant again. In 5-10 years, chips for mobile devices may well be in the same situation that desktop chips were a decade ago, and then x86 will be a minor handicap, rather than a crippling one, but even with a 32nm process the decoder is still a big (relative) drain on a mobile x86 chip.

From what I've read, Intel doesn't have anything that comes close to the Cortex A9 (as seen in Tegra 2) or the Snapdragon in terms of performance per Watt.

Re:Do Not Want

[marcansoft]

Thumb is implemented as a layer on top of ARM (at least last I checked), so usually the ARM decoder will still be active while in Thumb mode. However, Thumb and Thumb-2 are essentially compressed versions of ARM, so the vast majority of the decoder can be shared. The combined decoder for a modern ARM CPU is still much simpler and better performing than the decoder for an x86 CPU.

Another large advantage is that ARM programs by definition do not use things like self-modifying code without informing the CPU (i.e. issuing a dcache store and an icache invalidate). This means that ARM CPUs can be essentially Harvard architecture machines and they practically don't need any snooping logic for the caches. x86 CPUs always have to watch for insane things like an instruction modifying the instruction immediately after it in the pipeline, while that doesn't even work at all on ARM (you need the aforementioned flush/invalidate plus a write barrier and whatnot). Having CPUs impose these kinds of (reasonable) demands on the software is a very good thing for performance.

Re:Do Not Want

[marcansoft]

What you say is true of the decoder, but the issues with insane software demands do affect even large CPUs significantly. The percentage of the CPU dedicated to instruction decoding can go down as you increase the amount of execution units etc., but x86 CPUs still have to dedicate a lot of chip routing and logic to the (many) "special cases" that software might demand yet are incompatible with modern CPU optimizations. Things like snooping writes in case the CPU needs to invalidate a TLB, etc. As you add complexity, you have to keep adding these special cases and workarounds for things that were once implicit in older, more trivial CPUs. These things don't scale down when you add complexity; instead, they come along with complexity that you add. I wouldn't be surprised if up to 25% of the silicon area of a modern x86 chip could be shaved off if only the ISA requirements on the software were more like those of PowerPC or ARM (not the ISA itself, just the requirements and limitations on what the software can and can't do).

Re:Do Not Want

[itsme1234]

Here we have a platform where there is no reason whatsoever to have an ass-backwards-compatible architecture in order to run legacy Windows apps.

There are tons and tons and tons of x86 apps that run on some (potential) over sized x86 phone with 800x600 resolution, 512MB RAM, 1GHz CPU, 8-16-32... GB flash. Yes, you can do MANY things with iPhone, Android, Windows Mobile or Maemo. However with a small x86 box no matter how underpowered you can do MOSTLY ANYTHING. And there's a big difference. Examples: flash is big news on iPhone and Android. Java (as in browser applets): no chance in Android (don't know about the other platforms). That means some banking sites and some remote access software don't work. Get different servers? Switch banks? Heck, they work fine even with Windows 95!
Tried to print directly from your phone directly to some dumb printer? Tried to scan something (no, I don't mean take a picture with the crappy camera)? Get some files from some NTFS USB drive? Connect a TV tuner? Connect to some strange nasty corporate VPN?

Yes, 90% of the usage is covered with a nice basic browser, some media player and maybe a voip client. But there's a lot in the 10% left and I don't have the patience to have it all ported to arm (not that it'll ever happen as the market is so divided).

Re:Do Not Want

[TheRaven64]

Yes, you're quite correct. I remember a story from a former Intel Chief Architect about a bug in one instruction on the 486 that accidentally set a condition flag in some situations. A few game designers found that they could take advantage of this, and just slapped a minimum requirement of 486 on their game. Then the early Pentium designs crashed the game (when they ran it in the simulator), so every subsequent chip had to implement that buggy behaviour, only now it was documented behaviour...

Re:Do Not Want

[TheRaven64]

There are tons and tons and tons of x86 apps that run on some (potential) over sized x86 phone with 800x600 resolution, 512MB RAM, 1GHz CPU, 8-16-32... GB flash

And how many of those apps run on Linux? Of those, how many do not run on ARM?

Re:Do Not Want

[EvilNTUser]

If my phone had a USB host port, I could do all of the things you mentioned, and it runs Maemo + ARM Debian. Nasty corporate software excluded - and we'll all be better off if those guys are forced to modify their crap.

Might I also suggest that you don't switch to a bank with a website that wants to run binaries on your computer. For your own good.

Re:Do Not Want

[Bengie]

"The instruction decoder is the one part of a CPU that you can't turn off while executing anything"

The i7 can disable its decoder. Since the decoder turns x86 into micro-ops, if the i7 detects a loop, then the decoder won't be used until the loop ends. It'll turn off the decoder during these. But yeah, too many deprecated instructions that should just be dropped.

Re:Do Not Want

[itsme1234]

And how many of those apps run on Linux? Of those, how many do not run on ARM?

I know this is slashdot and all but let's not pretend commercial software doesn't exist. Plus as I said I don't have patience to wait. Oh, they just brought Flash to my platform. How nice. Maybe we'll have Java in mobile browsers by 2011.

Re:Do Not Want

[itsme1234]

If my phone had a USB host port, I could do all of the things you mentioned, and it runs Maemo + ARM Debian. Nasty corporate software excluded - and we'll all be better off if those guys are forced to modify their crap.

Might I also suggest that you don't switch to a bank with a website that wants to run binaries on your computer. For your own good.

We all know even x86 linux can't support all I mentioned unless you chose your hardware wisely. And that "if my phone had USB host" is a really really big if. When was the last time USB host was somehow vaguely widespread? Windows Mobile 2003 with high end PDAs? Of course in theory you could have USB host with anything but as of now you just don't have it (as far as smartphones go). If you get a small XP capable machine OF COURSE you'll get USB with it.

And frankly I'm not impressed with Maemo, as far as applications go. There are (many) places in the world where the only navigation programs/ecosystems that have any useful maps are iGo and Garmin. iGo can run on Windows (barely), Windows Mobile, iPhone (barely), Android (anounced). You can use Garmin with Windows, Windows Mobile, Palm non-Pre (barely), Symbian. See what I mean? Anywhere you turn and you have something more complicated than a Firefox extension you're stuck if there isn't a big open source project to fill that particular need (like Apache, Firefox, Gimp,...).

Running sandboxed Java applets (=normal browser Java) is reasonably secure and is not just "a website that wants to run binaries". If you are too afraid to do it I suggest you find a bank that works with lynx. And run it as nobody. Chrooted. In a virtual machine. From a CDROM.
Apart from banks there are many servers/remote access systems that need java (you can have alternative for VNC browser applet but you might not have alternative for something that might be even implemented in firmware from Sun, Compaq, Dell, etc). And because I don't have time to wait until "those guys are forced to modify their crap" can you let me know if Maemo runs applets from browser (I know Android doesn't)?

Re:Do Not Want

[EvilNTUser]

AFAIK the Maemo browser will not run java applets, but Iceweasel will.

A bank's java applet doesn't have to be nefarious per se, but in the case of a bank site it shows such poor design vs. plain html that you should expect other things to be wrong too. Also, read this.

Re:Do Not Want

[noidentity]

But but how are we going to run the vast library of malware written for x86? That's just a killer app waiting to happen on smartphones, and what's holding them back from becoming truely mainstream. I'm excited about this latest development. Oh, that and the ability to synergistically leverage all the x86 compiler expertise built up over the years.

Re:Do Not Want

[bcmm]

Tried to print directly from your phone directly to some dumb printer?

Tried to print directly from your laptop to someone else's dumb printer? Windows printer drivers are pretty horrible. At well over a gigabyte (!) of disk space required for some HP drivers (including all the non-optional utilities), it'd need a lot of storage (for a phone) to make you want to do that without thinking carefully...

Re:Do Not Want

[ascari]

Which is why the SPARC architecture is superior! (That was a joke, ok?)

Re:Do Not Want

[MemoryDragon]

I personally think that in the mobile space there is another factor, there is no need for x86 compatibility whatsoever more for the ARM compatibility since lots of CE programs are binary only.
So we have a clean table, and unless Intel pulls out dirty tricks from their heat (by forcing the third partys to use their junk) I cannot see how they even can gain any ground there.

Re:Do Not Want

[MemoryDragon]

Actually there are not too many banks which use Applets nowadays, and it comes down to porting the Applet API, Android already has most of Javas APIs underneath (only swing is left outside mostly which can be cross ported)
since it runs most of its infrastructure on java.
You the rest comes down to delivering the drivers and having the usb port to outgoing mode switched, the printer drivers are in linux so you have a higher chance to get them there than on WinCE which does not have any printing infrastructure, or older Windows versions which dont even be able to run decently on any phone thanks to their mouse centric ui which does not fit properly thanks to missing layout management mechanisms.
So again where is the point in x86 for a phone? You loose WinCE binary compatibility, Android binary compatiility in some cases, and iPhone binary compatibility and you gain higher battery drainage than on ARM, and equal to worse speeds than a decent Cortex A9 can do.

One x86 to rule them all?

[A12m0v]

I don't see Intel competing with ARM, ARM has an advantage over x86 in performance per watt, then again DEC, MIPS and many other RISC vendors didn't see Intel competing with them in the high-end workstation and server market. Hindsight is 20/20.

Re:One x86 to rule them all?

[Anonymous Coward]

When humans get to the point where the technology of Star Trek is reality, the spaceships computers will be running x86. That makes me sad.

Re:One x86 to rule them all?

[JDeane]

How else will they use this attack on the Borg?

http://web.thock.com/humour/startrk.shtml

Re:One x86 to rule them all?

[MemoryDragon]

Actually I dont find that funny, because it is true. For the first time in 20 years we finally have the possibility to bury the overloaded awful power consuming x86 garbage in a future segment of computing without too much hurt and yet again it seems that we cannot do it entirely for the sake of filling the pockets of a handful of people.
ARM has one of the best instruction sets ever created for a computer, it is probably the best power saving processor architecture in existence, yet Intel wants again to bury better competition for the sake of another pocket filling market they can dominate with their utter garbage. I hope they wont get very far this time, since their usual advantage is not there.

In my opinion Intel is worse than Microsoft ever was (but not as bad as Monsanto), but my opinion does not count!

what will it look like

[Locutus]

maybe the image used on this topics OP? Seriously, Intel has to make their Atom chips on the top-of-the-line 32nm or better process equipment just to be in the ball game with the ARM or PPC chips with regards to performance per watt. They now want to put x86 chips in smartphones? I guess they can try to spin up the press about this failure and hope they can drag it out for another few years. Maybe at 24nm it'll work but by then, ARM will be on 32nm and probably running quad cores and still beating them.

My guess is that LG is getting paid by Intel to play along and nothing more.

LoB

Re:what will it look like

[MemoryDragon]

Actually ARMs Cortex already will be produced with the GlobalFoundrys 28nm process, this was one of the big news of the CES this year. That is the advantage of having a low transistor count and many manufacturers, you always can move to the best one and you wont have to fight so hard to get to smaller structures. By the time Intel is on 32 nm we probably will see a 2-4 Ghz cortex A10 with 28 nm and less power consumption than the best A9 today running circles again around Intels Low End offerings.

Intel cannot win this by legal means if they rely on their x86 garbage!
ARM has 20 years of low power - good performance experience which Intel never had!

Re:what will it look like

[MemoryDragon]

here is the link http://www.linuxfordevices.com/c/a/News/ARM-and-AMD-spinoff-Globalfoundries-partner/

Re:what will it look like

[hattig]

I thought Moorestown was 32nm, that was used in this LG demo phone-brick.

It takes time to get products made in foundries - signing something now might mean a product in a year's time. Moorestown will be out before then.

Of course the lack of integration in Moorestown means any implementation needs additional support chips to add other functionality, such as 3G chips, etc.

Marvell already announced a Quad-Core ARMv7 (Cortex A9 equivalent) SoC.
ARM have announced 2GHz ARM Cortex A9 hard cores for TSMC.

I do think that if in ten years time everybody is using x86 still, that something is severely wrong in the world.

"than the Atom"

[Anonymous Coward]

uh Mooresville is the latest iteration of the Atom.

Advantages...

[91degrees]

ARM: Low power.

x86: Runs most desktop PC applications.

For a desktop PC the ability to run most PC applications is extremely important. For a smartphone, who cares? I don't want to run Paintshop Pro, Word, or Call of Duty on my smartphone. The apps that I do want to run already work on ARM. I do want low power. The improvements Intel has made are barely significant next to ARM's huge advantage here.

Re:Advantages...

[Pentium100]

I want to run desktop PC applications on my smartphone.

I now have a Nokia N93 which is quite old and may not have all of the features of a new phone (or rather new version of Symbian OS).

It can open MS Office files, but really mangles them - shows only text, no graphics, no formatting and cannot edit the files. This is not because the phone has too little memory - it has 22MB free when booted up. MS Office 97 works on a PC that has 16MB RAM total.
I want to watch videos on my phone, but it only supports a very specific format - mp4 container, xvid or x264 codec at specific max bitrates and resolution (compatible with iPod), which means that I cannot just copy a video file to the memory card, I have to convert it first, and converting takes time. On x86 smartphone I could install codecs, filters and splitters to, for example, support mkv container. Or ogg format for audio.
There are less programs available for my phone than my PC, also, there are a lot of free (open or closed source) programs for PC, while their counterparts for the phone may be expensive.
Also, if the phone had x86 and Windows, I could use PC hardware with it (for example - mouse, keyboard, USB flash memory...).

As for the power issues, I think it would be possible to have two modes of operation. A phone mode, where the x86 cpu is turned off and some other CPU is used for the basic phone functions (calls, SMS, camera) and a full mode when the xd86 CPU is used for everything. The phone may not be able to work for very long in this mode (a few hours), but I would rather carry a small power adapter or a spare battery than a netbook in addition to my phone.

I have a Psion Series 5mx PDA, which is great, but has compatibility problems, for example, while I can browse the internet (using infrared connection to my phone) and download MS Word documents, I have to also have a laptop to convert them to the Psion format. But if I already have my laptop, why would I also carry the Psion?
I once installed an emulator that could emulate an 8086 CPU and installed Windows 3.10. I would have used it like this, if it wasn't so slow (Psion 5mx was made in 1999 and has an ARM 710T 36.864MHz CPU). Maybe with modern CPUs this emulation could be possible and maybe I could even run Windows for Workgroups 3.11...

Re:Advantages...

[Thantik]

why is it that you think you couldn't already use 'pc' hardware with an ARM-based device? -- You can. It's the fact that these smartphone companies try to keep costs down. You *can* use any PC peripheral with an ARM device using linux just fine. Check out www.openpandora.org - That's an ARM A8 I believe and they have a USB device host, so you can hook in a hub, usb mouse, keyboard, camera, gps, you name it...you can hook it up and use it. Just like a PC.

And blame Microsoft for not supporting ARM - x86 doesn't mystically, magically make everything run that otherwise wouldn't. It's the software vendors who decide what will run on what. Tell them about it. Microsoft could easily patch together an ARM-based Office reader in a day, but they chose not to.

Re:Advantages...

[Pentium100]

why is it that you think you couldn't already use 'pc' hardware with an ARM-based device?

Because some of that hardware might need drivers that the ARM OS does not have.

And yes, x86 is just another instruction set, like ARM, PowerPC and others. However, there are a lot of programs written for Windows on x86. Those programs would not work on another instruction set, even if Windows could, unless Windows on non-x86 CPU could emulate x86 CPU to run those programs, but that would be slower than a native x86 CPU.

A lot of those programs are written in high level programming languages, so in theory they could be recompiled to work on another CPU, but what if the company that made the program no longer exists or wants $(a lot) for the recompiled version?

Windows (currently; except the mobile version) supports only x86 and is compatible with most of the programs written for older versions. I can safely assume that if program x worked on WinNT, it will work on XP, after all, Windows is Windows. There are some programs that do not work on a newer version of Windows, but these are a minority.

Not so much with Linux - while Linux itself is compatible with a lot of CPU architectures, the programs are not. What it means is that a program may work on SuperLinux on my x86 PC it won't work on PhoneLinux on my ARM phone, even thought they are both Linux. Yes, if the program source code is available I could probably recompile it to work on the phone, but not all programs are open source.

Re:Advantages...

[Thantik]

Now your just getting into semantics. Again, it's not the architecture that determines if you can/cannot run those items. The same thing you say exists on linux, exists in Windows 7 as well. The architecture has NOTHING to do with it.

Re:Advantages...

[hattig]

The world has moved on since 1999. Seriously, are you really comparing x86 to ARM based around an eleven year old device's features and compatibility?

x86 JIT emulation on a 1GHz Cortex A8/A9 in the vein of the Alpha FX!32 emulation might equal a low-end Atom in performance. It does require someone to write it, and somehow integrate it into an ARM version of Wine though.

And a 2006 mobile phone running one of the more limited smartphone OSes. Brilliant. You do know that there is plenty of Office compatible software out there, like Documents2Go, that does all you need? Well, maybe you need VBA in Excel or something ...

Hell, a 1GHz A9 could run OpenOffice. Not that it would be pretty on a 4" 800x480 display, but ...

Needs to be open no APP store lock / sim locks as

[Joe The Dragon]

Needs to be open no APP store lock / sim locks as well.

but it's still a phone

[r00t]

There goes **everything** if I'm using the phone for everything. When I drop it down a pit toilet, I'm not getting it back.

Say, these are dirt cheap, right? I'm putting mine in the clothes washer you see...

Should it also serve as my photo album, identity, and debit card? BTW, I just might drop it next to a 600v 3rd rail. Want to fetch it for me?

Re:but it's still a phone

[Anonymous Coward]

There goes **everything** if I'm using the phone for everything. When I drop it down a pit toilet, I'm not getting it back.

That's actually a good thing. The increased likelihood of losing a phone would push reliable backup solutions into the mainstream. Right now, backups are kind of like exercising and eating healthy -- everyone has a vague sense of it being important, but it's easy enough to put it off and worry about it later.

If phones became the primary computing devices, then you'll see a lot more automated, network-aware backup solutions. Pick any combination of "backup over cellular data service", "backup over WiFi", "backup to a cloud-based service like Mozy or Carbonite", and "backup to network-attached storage at your home or office". Those options are already somewhat viable now, and it'd only get easier in the future.

So given a future where phones are a primary platform, the average bad case for dropping it in a pit toilet would be the loss of everything you did since leaving home that morning. And if you're in a circumstance where losing the phone is a lot more likely or where even half a day's work is too valuable to lose, you'd probably have it backing up over the cell network on a regular basis.

Re:but it's still a phone

[maxume]

It wouldn't be so bad if you could put a cryptographic certificate on your phone and use that for various identity and credit authorization needs.

Oh, and the solution to the certificate being compromised is to revoke it and issue yourself a new one.

Re:but it's still a phone

[Hurricane78]

Have you ever heard of the concept of backups? Hell my mobile phone has a backup cron job that is configured to back up everything at night right now. And that function is even built-in! I think all recent Symbian phones have it.
I then have the phone software on the PC, that also has a built-in function to sync and backup the data in the background, whenever I connect the phone.

I could throw the phone away right now, and lose nothing.

I only consider having something like a data safe, so nobody does shit with the private stuff stored in there. (Like harass my friends, create fake porn with the photos, get into my mail account, etc.) That is the real risk here. But hey, there already is software for that on the market. I saw several security suites for Symbian phones. With firewall, IDS, anti-virus, and a data safe.

Re:but it's still a phone

[ChunderDownunder]

I'm putting mine in the clothes washer you see...
I did this once. :( The phone was clean but never worked again.
Luckily the SIM card still worked when I purchased a new, unlocked, phone.

Yay for also-rans

[Anonymous Coward]

They're trying to pull a micros~1: Realise you've fscked up, then splash lots of dosh, marketeering, and the finest FUD you can come up with around in very large quantities. Add a crap product and boy, see the great unwashed eat it all up like candy. Polished turd vomit flavoured candy.

x86 desperately needs to die, and if intel doesn't like that because they can no longer come up with anything else and make it work, tough cookies. I don't care that this thing "runs linux" to appease the slashdot crowd. Please support something that is worthy of support. Arm, mips, powerpc, anything but x86.

Re:Yay for also-rans

[RAMMS EIN]

Perhaps I should point out at this point that Intel has, in fact, made several non-x86 processors.

In fact, the 64-bit variant of x86 that the world seems to be migrating towards isn't even from Intel, but from AMD. I think it's fair to say that, had it been up to Intel, we'd be moving away from x86.

Re:Yay for also-rans

[TheMiddleRoad]

The tried. It's called Itanium. People want their x86.

Can we lose the can't do attitude?

[copponex]

This solutions to this are simple. This took me about a minute, not counting proof reading.

1) The charging device also has a small hard drive built into it that always syncs the data - just like iTunes already does if you have an iPhone.

2) The unique data - contact, calendars, documents - are constantly backed up to a server over the internet connection. Program data can easily be preloaded or reloaded onto a new phone.

3) As far as monetary risks are concerned, there is something called insurance. You may want to look into it.

The line between what a cell phone and a laptop and a computer mean intrinsically will continue to blur. Soon it will be simply the size of the interface. You'll have a mobile. Maybe the mobile will dock into a laptop or tablet style chassis to provide extra power and a full keyboard and larger screen - just like Lenovo just demonstrated at CES. The mobile can also be docked to your desktop system if you really need some extra horsepower or a fiber connection to the net. Meanwhile, your data is always with you. Doesn't sound so bad.

Re:Can we lose the can't do attitude?

[Anonymous Coward]

This solutions to this are simple. This took me about a minute, not counting proof reading.

1) The charging device also has a small hard drive built into it that always syncs the data - just like iTunes already does if you have an iPhone.

2) The unique data - contact, calendars, documents - are constantly backed up to a server over the internet connection. Program data can easily be preloaded or reloaded onto a new phone.

You know what that sounds like? A blackberry. Everything gets synchronized automagically over the air to a server back at your office.

Maybe the mobile will dock into a laptop or tablet style chassis to provide extra power and a full keyboard and larger screen - just like Lenovo just demonstrated at CES.

Back when Palm Pilots were the best PDA on the market, you could buy a small fold-out keyboard - they never were that popular though.

Sounds like you want a usb cable between your blackberry & your laptop.

Re:Can we lose the can't do attitude?

[Anonymous Coward]

As far as monetary risks are concerned, there is something called insurance. You may want to look into it.

Most insurance (or warantees!) for mobile phones does not cover water damage; read the small print. Using your phone after having a shower, or outside if it is raining is explicitly warned against in mine.

you've read Hennessy/Patterson/Tannenwhatever

[r00t]

The BCD instructions are insignificant. They are nothing compared to stuff like vector floating point and crypto. Despite the waste, x86 instructions are still really compact compared to normal RISC instructions.

A dirty little secret about RISC compilers is that they seldom use more than a few registers. No kidding. Disassemble a wide variety of things and you'll see.

Modern x86 gives you 16 integer registers, the same as ARM. Old x86 gives you 8, the same as ARM Thumb. If there is a difference worth mentioning, it's that x86 chips are often designed to dynamically map the architectural registers onto over 100 hidden implementation-specific registers. This can even be done for memory in some cases.

In the end, it's about the implementation. Intel has the best foundries (best silicon). While optimizing x86 isn't easy, Intel has the money to throw lots of excellent engineers at the problem. In other words, a pig will fly if you provide enough thrust.

Re:you've read Hennessy/Patterson/Tannenwhatever

[marcansoft]

Old x86 gives you 8, the same as ARM Thumb.

Bzzt, wrong. ARM Thumb gives you 16 registers, it's just that you can only really compute on 8. The others are still accessible by a few instructions (mov, add) and they are still extremely useful for storing values around during the life of a function without having to constantly hit the stack.

Re:you've read Hennessy/Patterson/Tannenwhatever

[r00t]

Bzzt, wrong. ARM Thumb gives you 16 registers, it's just that you can only really compute on 8. The others are still accessible by a few instructions (mov, add) and they are still extremely useful for storing values around during the life of a function without having to constantly hit the stack.

If you're going to cheat, I may as well cheat too. I can use the MMX and XMM registers you see. That's 24 registers on older CPUs, or 40 registers on newer CPUs.

Of course, that's a load of shit. (despite the fact that x86 can actually compute in MMX and XMM registers, and damn fast too)

More legitimately, one might use plain old memory. While this works for ARM too, x86 hardware can treat the near part of the stack almost like registers. It's really fast.

Re:you've read Hennessy/Patterson/Tannenwhatever

[marcansoft]

If you're going to cheat, I may as well cheat too. I can use the MMX and XMM registers you see.

Except no compiler actually does that, while ARM Thumb compilers routinely make use of the extra registers for longer-term less-frequent storage within larger functions.

Re:you've read Hennessy/Patterson/Tannenwhatever

[91degrees]

Yes. Vector processing is a useful addition, which explains why many modern chips implement it:)

Despite the waste, x86 instructions are still really compact compared to normal RISC instructions.

Is this really an advantage though? Pipelined processors are much simpler when you can just grab 32 bits (or whatever) for an instruction. I'm not a hardware guy (have worked on a CPU design but was involved more in the compiler side) but it seems that it makes more sense to be consistent. Size of binary hasn't been a factor for years, even on handhelds.

Modern x86 gives you 16 integer registers, the same as ARM.

x86-64 made some great improvements. What did Intel actually do? Is this an entire parallel instruction set? I will admit to being a bit of a dunce when it comes to this. Can we multiply using a different result register than AX:DX (this one has always annoyed me)

If there is a difference worth mentioning, it's that x86 chips are often designed to dynamically map the architectural registers onto over 100 hidden implementation-specific registers. This can even be done for memory in some cases.

The clever stuff that x86 chips do with register renaming and out of order execution is quite brilliant. It makes them great for running existing code. Still, it makes more sense to leave optimisations to the compiler rather than on-the-fly in silicon. And the conditional execution is a useful feature that I really can't do without.

In other words, a pig will fly if you provide enough thrust.

Lol. True. It does seem though that the comparison is between a nimble stunt plane and an H-4 Hercules (maybe unfair. an x86 is pretty useful, the Spruce Goose wasn't).

Re:you've read Hennessy/Patterson/Tannenwhatever

[r00t]

Despite the waste, x86 instructions are still really compact compared to normal RISC instructions.

Is this really an advantage though? Pipelined processors are much simpler when you can just grab 32 bits (or whatever) for an instruction. I'm not a hardware guy (have worked on a CPU design but was involved more in the compiler side) but it seems that it makes more sense to be consistent. Size of binary hasn't been a factor for years, even on handhelds.

You'd have been 100% correct about 25 years ago. It used to be that CISC instruction decoding was a major cost. Today, CISC instruction decoding is fairly cheap.

Binary size still matters because the instruction cache and the TLB have limits. As code size increases, you tend to "fall out" of the cache. (no longer fitting) This is a severe performance hit.

Modern x86 gives you 16 integer registers, the same as ARM.

x86-64 made some great improvements. What did Intel actually do? Is this an entire parallel instruction set? I will admit to being a bit of a dunce when it comes to this. Can we multiply using a different result register than AX:DX (this one has always annoyed me)

Many of the more useless instructions go away when you set the "long mode" bit. That frees up bytes for a few new instructions and for 16 new prefix bytes, collectively known as the REX prefix. When you use a REX prefix on an instruction, you get access to extra registers and you can perform 64-bit operations.

Still, it makes more sense to leave optimisations to the compiler rather than on-the-fly in silicon.

Intel tried that with the Itanium. It didn't work out so well. There are two huge problems for the compiler. Parallelism is hard for the compiler to identify when dealing with typical code. Memory latency is hard for the compiler to predict. These two problems mean that the compiler will generate code that stalls quite a bit. The "smart" CPU isn't so limited because it can exploit information that is only available at run-time.

And the conditional execution is a useful feature that I really can't do without.

It is a fun feature. You do at least get conditional move on x86, which covers most of the need.

Re:you've read Hennessy/Patterson/Tannenwhatever

[Anonymous Coward]

Isn't it a logical fallacy to proclaim that something does not exist?

Re:you've read Hennessy/Patterson/Tannenwhatever

[MemoryDragon]

Well lets say it that way, ARM has way less transistors and the instruction set is very compact, they design their chipsets that way that you can use older fabs, but yet still you can shrink them, the cortex A9 will be produced in ranges from 40nm to 28nm so Intel does not have the advantage there.
It is even worse, Intel can only do a power reduction by changing the fab process and yet they still are not at the performace /watt levels ARM provides on 40-60nm, now that ARM is moving downwards into the 28nm and 32nm area (Globalfoundries will do that) it will look even worse.
Intel I assume hopes to push into the market by their strong foot in the third party vendor area where they can apply pressure over Netbooks and PCs (you wont sell one of our handheld processors, oops there goes your pricing advantage in buying the x86 of the year for your PCs). Time will tell how good that will work out.
But I assume Intel will have a hard time matching ARM.

Re:you've read Hennessy/Patterson/Tannenwhatever

[hattig]

Modern x86 gives you 16 integer registers

But not on IA32, which this Atom will be running (desktop Atoms support it, but it will be disabled here). In addition using AMD64 means longer instruction prefixes, negating your "really compact" argument. Of course when smartphones are coming with 512MB RAM (Nexus One), is code compactness really an issue any more?

Thumb2 negates the limitations of Thumb1, giving full access to registers and operations. And it has decent code compactness on top, although I don't know how it compares with x86 - maybe there are some comparisons out there? http://iccd.et.tudelft.nl/2009/proceedings/459Weaver.pdf has some interesting data but neglects to include Thumb.

In the end, ARM is dominant in the mobile and smartphone arena, and backwards compatibility with x86 isn't a concern. Looking at the size of this "phone" it'll require another generation of integration to get x86 competitive in terms of implementation area. In the meantime an 800MHz Atom is going to compare very badly with dual-core >1GHz A9s.

Re:you've read Hennessy/Patterson/Tannenwhatever

[r00t]

But not on IA32, which this Atom will be running (desktop Atoms support it, but it will be disabled here).

The initial x86 Mac was IA32 as well. That lasted for one hardware generation. These phones won't be IA32 for long.

In addition using AMD64 means longer instruction prefixes, negating your "really compact" argument.

Oddly enough, AMD64 code is more compact. The extra registers, native "long long" support, and other improvements more than make up for the occasional extra byte. (most instructions don't use the extra byte)

Of course when smartphones are coming with 512MB RAM (Nexus One), is code compactness really an issue any more?

Yes, because the cache size remains small. The L1 cache will always be small because larger caches run slower. Large code will "fall out" of the cache, causing it to run with lots of expensive cache misses.

Re:you've read Hennessy/Patterson/Tannenwhatever

[Rockoon]

Can we multiply using a different result register than AX:DX (this one has always annoyed me)

We've been able to do that since at least the 80386. In Intel/MASM syntax:

imul ebx, ecx ; works just fine on 386, ebx = ebx * ecx

What you can't do is get that double-wide answer without using EDX:EAX (or using more that one instruction, which is silly.) This isnt that big of an issue from a high level language point of view, since most of them wont give you a double-wide answer under any circumstances other than intrinsics/inline assembler. The flags are set correctly too (ex: overflow)

There is even a 3 operand form:

imul ebx, ecx, 1000 ; ebx = ecx * 1000, the last one has to be a constant.

In all instances, the second operand can be a memory reference.

Re:you've read Hennessy/Patterson/Tannenwhatever

[hattig]

Does it really matter if a large cache is running slower when it is attached to a ~1GHz dual-issue CPU? I'm sure ARM have already sacrificed performance however to reduce power consumption.

It would be interesting to see how cache use differs between a platform like Android, with its Dalvik VM and multitasking on ARM and Windows 7 and desktop applications on Atom.

Note that the amount of cache in an ARM SoC is configurable by the implementor. I believe most A8 designs are using 256KB L2. The L1s are 32KB/32KB I/D (in most implementations), which already compares well with Intel's desktop CPUs.

Putting Atom into 64-bit mode on the 45nm variants takes it from 2.5W to 4W per core. It might be more negligible on the 32nm version however. I don't know what ARM are doing about 64-bit support down the line, I presume they'll create a 64-bit capable core, and a new instruction decoder.

Re:you've read Hennessy/Patterson/Tannenwhatever

[r00t]

Does it really matter if a large cache is running slower when it is attached to a ~1GHz dual-issue CPU? I'm sure ARM have already sacrificed performance however to reduce power consumption.

In any half-reasonable CPU design, you're going to have an L1 cache that is tiny and fast. It can't be big, because that would make it slow.

When code is compact, it tends to be almost 100% cached. It runs fast.

As code grows, there comes a point when it suddenly becomes **much** slower. This is called "falling out of the cache". It isn't normally gradual. If you plot a graph of bloat against speed (normally only done for data because that is easier) you'll see a sharp cliff in the graph.

For most CPUs, you have L2 or even L3 cache. For each level you have, the above-mentioned graph will show a distinct cliff.

A more-compact instruction set moves the positions of those cliffs. Your code can get away with more features, more abstraction, more copy-and-paste hacks, and so on. You have more of a safety margin before performance goes to Hell.

Re:you've read Hennessy/Patterson/Tannenwhatever

[hattig]

I meant that when you can get decent sized cache optimised for 3GHz+ CPUs (e.g., AMD's 64KB/64KB L1 I/D), optimising it for 1GHz CPUs and low power can mean you still have large L1 caches that are as fast as the CPU core requires to operate at its designated clock speed. I.e., you can still have large caches on ARM CPUs.

Also a slower CPU reduces latency as seen by the application running, when you have to go down the memory hierarchy - especially when the memories are fast or the memory controller is local.

Maybe you will be caching (e.g.,) 30% less instructions in ARM Thumb2 code than in x86 code in the same sized cache. But you have 32KB of cache available, so most loops will be happily accommodated. It's not like the ARM Thumb2 code is going to be massively larger than x86:

http://www.csl.cornell.edu/~vince/papers/iccd09/iccd09_density.pdf suggests Thumb1 code density is between slightly better than x86 through to twice the size. It also says that Thumb2 has better density because it fixes the deficiencies of Thumb1 in many areas, but I haven't read the referenced article that states that - but I've seen ARM's PR about it and am willing to believe that it has the overall performance of ARM code in the size of Thumb code.

It would also be interesting to see how L1 ICache size correlates with performance increase. I would imagine that going from 0 to 1KB would have a massive effect (indeed going to 256 bytes in the 68020 had a massive performance increase over disabling the cache), but going from 16KB to 32KB would have far less of an effect.

If Intel wants to beat ARM

[jmknsd]

If Intel wants to beat ARM they would have to take a page from the microsoft playbook and release their low end processors for (near)free.

Re:If Intel wants to beat ARM

[hattig]

Indeed. Check out the price of the 1GHz Snapdragon CPU, GPU, and Baseband (and video, 3D, security, I/O, etc) chip in the Nexus One:

http://www.isuppli.com/News/Pages/Google-Nexus-One-Carries-$17415-Materials-Cost-iSuppli-Teardown-Reveals.aspx

In short: $30.50.

Sure, Mooretown will integrate a CPU and GPU with 3D and video. It might support the AES instructions added to x86 recently by Intel too. But it doesn't have the baseband processor which would be separate in such a phone. It might also need a separate I/O chip. It won't run as cool as the A9 SoC either. And Intel won't want to sell such a chipset for such a low price.

Re:Needs to be open no APP store lock / sim locks

[BitZtream]

No it doesn't.

You want it to be.

However, as the market has shown, it doesn't have to be and it can be very successful without being 'open' as you define it.

Most of the rest of the world doesn't have some ideological battle against the man to fight, they just want their phone to work.

If it needed to be open with no lockin, then it would be or they'd lose money.

You guys really need to wake up and smell reality. Learn the difference between 'It needs' and 'I want' at the very least.

Forgive my cynicism

[Hillview]

But I've never understood the theory that someday smartphones will be our primary computing platform. I may be a crusty old bastard, but I like to have a display I can read from at least two feet away, and "typing" on most mini qwerty phones is a pain in the arse at best.

Useful? yes. Primary? Not until we can eliminate monitor and keyboard. Neural interface, anyone?

Re:Forgive my cynicism

[Anonymous Coward]

Eh, how hard would it be to integrate ports for video and usb keyboard/mouse? Really?

Re:Forgive my cynicism

[TheRaven64]

Keyboards can be bluetooth, they don't need to be built into the device. Most modern TVs have HDMI input. Add a power port next to that, and you can just drop your phone in a dock next to your TV and pick up a Bluetooth keyboard and mouse when you are at home, but then pick up the computer when you leave.

Re:Forgive my cynicism

[im_thatoneguy]

I like the idea of an x86 phone but....

Wouldn't it be easier to just keep a VM instance in a memory card on your phone than to actually require the phone to do the processing?

Re:Forgive my cynicism

[Hillview]

I hadn't thought of this.. that has possibilities. :)

Re:Forgive my cynicism

[TheRaven64]

Take a look at the work Samsung have done with the ARM port of Xen. They are building ARM chips into their TVs, so the idea is that you'll live-migrate your phone's VM to your TV when you are home. They're also working on an idea of partial migration, so the phone-and-TV will look like a single (NUMA) machine to the OS and it can migrate tasks between the processors as required. x86 not required.

FFS

[mister_playboy]

You'd rather run Win 3.11 than a modern Linux distro streamlined for a phone? You're either a huge MS fanboy or a troll.

In any case, MS has already killed and buried all the OSes you mention, so the choice is already made for you.

Re:FFS

[Pentium100]

OK, I now want a version of vmware that runs on that phone Linux. I know that there is a desktop Linux version of vmware, but does it run on phone Linux?

Also, OS is not a tape recorder - you can still use it the same as before even if blank tapes are no longer made.

Re:FFS

[AmberBlackCat]

I think if you compare custom Linux to standard Windows 3.11, Linux wins. But it gets more interesting if you compare (standard Windows to generic Linux) or (custom Windows to custom Linux).

Comparing "right-out-of-the-box" versions of both, standard Windows 3.11 will support whatever VGA resolution this phone uses and maybe even the sound, while generic Linux won't. The lack of pre-emptive multitasking won't be a problem if you're used to only running one app at a time on your phone anyway. And yes there is an awful lot of software out there for old Windows; even Photoshop is available.

If you compare custom versions of both operating systems then both will work fine. Most of the advances in Linux won't matter on a phone. And in any case, Windows 3.11 would kill any modern desktop OS in terms of CPU usage and memory requirements. It will have way better battery life and way more free memory. As a bonus, you get to run the version of Norton utilities from back when it was worth something...

Re:FFS

[NeoStrider_BZK]

Exactly. The said backward compatiblity is a trap. Its not worth carrying all the burden.
Try running a DOS game in Windows and you will see this in action. Sure you can boot DOS 6.22 and run it, but I doubt you will get sound and other nifty stuff. So , to get sound you go for emulation that happens to run on ARM machines as well. End of case.NEXT!

Ubuntu?

[DaveSlash]

But which one of these smartphones is going to let me install Ubuntu 9.10 and let me have root ? That's all I want. A pocket computer with wireless Internet that can make and receive phone calls, and that will let me do "apt-get install " Also let's not go over the board with the size. That LG phone is not going to fit in my pocket, and I don't want to get a purse. http://www.engadget.com/photos/lg-gw990-hands-on/2595625#2595617

Re:Ubuntu?

[EvilNTUser]

Do you even have to ask after all the articles on slashdot? Nokia N900. (Not Ubuntu, but meets all your other criteria.)

Re:Ubuntu?

[DaveSlash]

Sweet. I'll get one and be "almost" happy with it.

Re:Ubuntu?

[EvilNTUser]

Why the insistence on Ubuntu? There's already a Debian installer in Maemo's alpha quality repo, and I don't understand why that wouldn't be good enough.

Only problem is you'll have to install it under Maemo rather than replace it due to driver issues, but then again neither Debian or Ubuntu have mobile phone UI's, so...

Re:Ubuntu?

[DaveSlash]

I love Ubuntu and its juicy repositories full of pre-compiled and tested x86 apps. You insist in selling me a Nokia phone that doesn't fulfill all my requirements. And I'm supposed to say, "Oh ok that's good enough. Almost there". Alpha quality repo for my phone? No, thanks. Ubuntu LTS quality? Yes, please.

Re:Ubuntu?

[EvilNTUser]

I don't think you understand. It's the Debian *setup tool* that's alpha quality. What it installs is 100% Debian quality, with the full Debian repos available. After it's done, you use synaptic or apt-get. In fact, apt is how you install Maemo software too.

There are two major showstoppers left: some GUI programs don't get keyboard input, and PulseAudio doesn't work as it should. Once that's patched on the N900, I'm sure the installer will be in the main repo within weeks.

If you still insist on Ubuntu, you can probably replace the Debian image with an Ubuntu image you've made yourself without much trouble.

And I'm not trying to sell you anything. You complained about not getting what you want, and I'm trying to tell you about my experiences with the N900.

Re:Needs to be open no APP store lock / sim locks

[Anonymous Cowar]

I own a phone that will never be popular. It will never be the iphone killer that it could be given 6 more months of hardcore development and polish. The nokia n900 runs similar hardware, but improves on it in many places (slide out keyboard, comes with tv-out cable right out of the box, ctrl+shift+x brings up xterm, integrates skype which means that skype calls are just as easy as phone calls), however, it will never be as popular as the iphone because it is so damn open, is without a major carrier's blessing/store shelf space (who orders a phone online? well, besides This Guy!), and, really, is rather unpolished (needs 6 months of hardcore development and polish).

People don't want open, they want easy. They want to be able to walk into a cell phone store, say "ooh! That looks pretty!" and they want a sales associate to come up to them and say "Yes, not only is it pretty, but look at all these widgets and e-doodads you can install on it with the touch of a finger! They will be useful and enhance your life in ways you can barely imagine!" and then the customer will say "Please sir, but it looks so expensive!" to which the associate will reply "But not as such! Thanks to this sim lock-in, you can pay $2000 over the course of 2 years to save $400!" and the customer will end the conversation with a triumphant reply of "Please, kind sir, relieve me of my hard earned currency!"

The end.

Re:Needs to be open no APP store lock / sim locks

[EvilNTUser]

If you're referring to the iPhone, the market has shown that it's nowhere near top market share. In fact, with Symbian, Android and Maemo, over half of 2010 smartphone production will be open or opening source.

WTF, are we winning?

Remember to vote with your wallet and demand root access.

"compete"

[farble1670]

It is clear, however, that Intel aims to eventually compete squarely with ARM in the high-end smartphone market

woe to the company that intel decides to "compete" with.

Can we use the right tool for the right job?

[syousef]

For pity sake, a smartphone is not going to do everything a laptop or desktop will do as well, no matter how you design it. I'm all for using a smartphone, but not as a panacea. Just as I don't use a hammer when I want to saw something.

There are plenty of problems and solutions (some of which you have outlined) when it comes to phones, but that's not going to make them some piece of magic that does everything well. I don't want to do everything on a tiny screen with a tiny keyboard. Also note that some manufacturers and service providers have refused to offer the solutions you have outlined.

Re:Can we use the right tool for the right job?

[Urkki]

For pity sake, a smartphone is not going to do everything a laptop or desktop will do as well, no matter how you design it. I'm all for using a smartphone, but not as a panacea. Just as I don't use a hammer when I want to saw something.

There are plenty of problems and solutions (some of which you have outlined) when it comes to phones, but that's not going to make them some piece of magic that does everything well. I don't want to do everything on a tiny screen with a tiny keyboard. Also note that some manufacturers and service providers have refused to offer the solutions you have outlined.

A smartphone doesn't have to do everything well, only well enough, and (with docking station connecting to the TV and wireless keyboard, and ADSL-WLAN if 3G isn't speedy enough in the area) it can satisfy all computing needs of average computer user. Niche markets, like high-end gaming, serious media editing etc will of course require a real PC for a long while, but people did already do high-end gaming and serious media editing in the time when high-end PC had less power than a smartphone today (let alone in two years, because the performance race for smartphones is clearly starting, as indicated for example by the TFA). So why couldn't a smartphone of today do gaming and media editing at the level of those old PCs, quite sufficient for a random user who just wants for example cut pieces out of a video they captured with the very same smartphone?

Super Smartphones?

[dangitman]

This article is full of shit. By the time smartphones become our primary computing platform, we'll be using at least Super Duper Smartphones, if not Super Mega Hyper Fragilistic Smartphones.

Rerun

[that this is not und]

I love stories about new PDAs; it shows the IT market is doing something different than the usual same-old desktop apps.

Same old, same old

Who codes x86 only in this age?

[Ilgaz]

I am not a Java hater but while there is something perfectly fitting to mobile (J2ME), Java Applets are a huge overkill for that kind of device. On the other hand, as it is a Linux powered thing with gcc compiled things working, it is a possibility that even a better Java with applet support can be shipped. Obviously, Nokia would be the last one to ship such a battery killer for 0.0001% interest.

If Navigation companies can't release their application for ARM, it is their non portable crap and they have no future. Sorry for all people coding X86 only code in 2010. IMHO it is more related to how popular device is. Navigation companies support down to Symbian UIQ3 which is -dead-. Nokia ships their own very impressive Nokia/Ovi Maps and yet advertise other solutions on their own Ovi store (they aren't Apple).

ARM is _designed_ for mobile. X86 which has to support things back from 1978 is the last thing I would want on a mobile device.

And now imagine

[SmallFurryCreature]

The power you could have in a normal sized PC, where you can upgrade parts, swap broken parts, expand what you want.

Sorry, but what you are describing is the laptop, and I hate it when I am made to use one as a regular PC.

Re:And now imagine

[bhtooefr]

http://www.liliputing.com/2010/01/shuttle-launches-push-for-notebook-motherboard-standards.html

How succesfull is the closed app store?

[SmallFurryCreature]

Apple sells a lot, but could it sell more?

SOE sold a lot of copies of Everquest, it didn't need to improve the game, it was succesful.

And then Blizzard changed the game and redefined what success meant for a MMO.

Rougly the same thing the happened to Apple earlier by the way. Apple did fine with its first Mac's. And then WinTel (compaq) showed what success really meant as they broke all sales records everyone had made before.

Success is relative.

What for ?

[DrYak]

OK, I now want a version of vmware that runs on that phone Linux. I know that there is a desktop Linux version of vmware, but does it run on phone Linux?

VMWare is closed source and is only supported on the platforms that its developpers choose to (so you would be restricted to Linux running on one of those x86 monstrosities). On the other hand, there are plenty of open-source emulators which are only a recompile away to be run on whatever platform you choose. QEMU is an exemple of such an emulator. And DOSBox is an exemple of emulator which HAD ALREADY been ported to esoteric platform, just to enable access to old games while on the move.

Now, just why would you need a full blown emulator in a smart phone ? Given the input/output and battery life limitation, VMWare on a smart phone sounds like a pointless overkill. Are you trying to play WoW on your phone ?!?

Also, OS is not a tape recorder - you can still use it the same as before even if blank tapes are no longer made.

On the contrary. Closed source OSes are much more quickly deprecated than anything else once the developers drop support : The reason being : DRIVERS. You could, in theory run Win 3.11 on a smartphone x86 compatible processor. In practice, the rest of the hardware will hardly ever look like anything remote to a PC. You just won't be able to use anything else : keypad, screen, GSM/UTMS chip, etc. Everything is hardware which came years after the latest Windows 3x and there's no way at all that a drivers was written back then that could be still useful today.
You would need not only a x86 compatible chip, but also dozens of other legacy devices (the keypad had to be communicating through PS/2 with the system, the GSM/UTMS chip should communicate serially over what is exactly an old era UART COM port, for the screen you would need something which behave exactly as a legagy VGA, etc.)

That's why open OS are much better in the longterm and are getting so popular in the embed world (pretty much all of modem/routers, multimedia players/disk enclosures, home NAS, etc.. seem to be running some variation of Linux+Busybox) : because their are much more customisable.

Re:What for ?

[bhtooefr]

OK, how about drivers for, say, RedHat 6.0 (or, rather, the kernel and XFree86 versions included in that ancient version of RedHat)?

And that's newer than Windows 3.1 by quite a lot.

The reason why older OSes are poorly supported is that they're older, and nobody uses them any more. The strongest exceptions I can think of are actually in the closed source realm - mainframe software, which gets virtualized, and Windows XP.

Re:What for ?

[MBGMorden]

The point is that with open source software you can easily add or borrow code to make something work on a newer device. Wanna make Redhat 6.0 work on newer hardware? Download the latest kernel and compile it. Bang. Support for tons of devices immediately. Or, if you really wanted to keep the old kernel for some insane reason, you have source code from newer kernels that contains plenty enough information to write a new driver.

Windows 3.1 on the other hand - if something doesn't work right then you're SOL. Hard drives above a certain size aren't supported for example. Even then the only filesystem supported is FAT16 which caps out at 2GB per partition. Those are limitations that you simply cannot fix. If it were open source and you wanted to, you could take a look at the FAT32 code (or any other FS) on another OS and backport it if you wanted.

Re:What for ?

[bhtooefr]

What if that newer hardware has closed source drivers?

I guess you could write a shim to use the newer drivers, but that gets to be a pain.

And, Windows 3.1 has public APIs for drivers and doesn't handle filesystem access - it just calls DOS for that, and there are DOS filesystem drivers for quite a few filesystems (and a few different DOS variants from multiple vendors, including Microsoft, that natively handle FAT32, including an open source DOS clone.)

Re:What for ?

[bhtooefr]

Wait, redundant? Really?

It's not -1, Disagree, it's -1, Redundant. Which means something that's been said before, not something you disagree with.

your textbook/professor was wrong

[r00t]

An x86 chip has weird instructions for things like string manipulation that no compiler will ever emit, but which have to be supported by the decoder just in case.

Sorry, that's just wrong. Lots of compilers will emit those instructions, especially when optimizing for size or when the string is known to be small or unaligned. Both gcc and Visual Studio will do it. The string instructions perform very well for small strings, and decently for large strings.

Even if compilers wouldn't emit those instructions, they are sometimes used in C library assembly.

ARM instructions are incredibly dense. Most of them can be predicated on one or more condition registers, which means that you often don't need conditional branches for if statements in high-level languages.

In the real world, compilers almost never do this. (way too difficult) When they do, it's almost never anything more complicated than a conditional move. You can get conditional move on x86 now.

More importantly, there are things like Thumb and Thumb-2, which are 16-bit instruction sets suitable for a lot of ARM code, but which get very good cache density. Unlike x86, these are separate instruction sets.

That tosses out your beloved conditional execution and so much more. Thumb code is nasty shit, full of jumps and PC-relative constant loads. It makes x86 look almost... beautiful. :-/

self-modifying code == JIT

[r00t]

Another large advantage is that ARM programs by definition do not use things like self-modifying code without informing the CPU (i.e. issuing a dcache store and an icache invalidate). This means that ARM CPUs can be essentially Harvard architecture machines and they practically don't need any snooping logic for the caches.

This was true until people JITed code became common. (ActionScript, JavaScript, Java, .NET CLR, etc.) Now x86 has an advantage.

x86: translate to native code and then just run it

ARM: translate to native code, call into the OS, have THE CACHE FLUSHED (**ouch**), and then run it

When do we most worry about performance? Oh, when running bloated stuff written in awful scripting languages that must be JITed. Uh oh...

Re:self-modifying code == JIT

[marcansoft]

On ARM, you call into the OS and store DCache/invalidate ICache ranges. That means only blocks you touched are stored on the D side and invalidated on the I side. This invalidation on the I side is likely to cost near nothing because chances are you weren't running code out of there before.

x86 has to do the same thing, except the CPU has to devote a huge gob of logic to guessing when. And sometimes it guesses wrong and flushes stuff needlessly.

Just because something is easier on x86 doesn't mean it's cheaper. In fact, most "easy" stuff on x86 is expensive precisely because it goes against modern CPU design principles.

Re:self-modifying code == JIT

[r00t]

On ARM, you call into the OS and store DCache/invalidate ICache ranges.

Yeah, I know. That's unusually stupid; on PowerPC at least they made those instructions unprivileged. System calls are not free.

That means only blocks you touched are stored on the D side and invalidated on the I side.

It's even cheaper on x86, because you can delay doing that work. Cache lines get flushed naturally as time passes. By the time the CPU needs things flushed, it might have already happened. Some JITed code will never run; it's best to never pay the cost of handling it.

Of course these details are only explanations of why the system as a whole might perform well or poorly. The simple fact is that ARM is terribly slow in real-world use. You can blame the compiler, the architecture, the fabrication process, the cache size, whatever... but the end result is the same.

Re:self-modifying code == JIT

[ChunderDownunder]

Hence ARM invented ThumbEE?
If and when the LLVM JIT targets ThumbEE, hey presto, the performance problem disappears. e.g. using Redhat's shark implementation of Hotspot.

Re:self-modifying code == JIT

[marcansoft]

Yeah, I know. That's unusually stupid; on PowerPC at least they made those instructions unprivileged. System calls are not free.

Yes, PowerPC is a nice architecture too. I wouldn't mind a world with PowerPC desktops and laptops and ARM netbooks and cellphones. FWIW, there's nothing preventing ARM from adding unprivileged operations on the cache.

It's even cheaper on x86, because you can delay doing that work. Cache lines get flushed naturally as time passes. By the time the CPU needs things flushed, it might have already happened. Some JITed code will never run; it's best to never pay the cost of handling it.

If you're not going to run the JIT code why on earth are you compiling it anyway? There's a reason why it's called JIT. Not to mention that you can just stick the cache ops right before the JIT code is run, instead of as it is compiled.

Of course these details are only explanations of why the system as a whole might perform well or poorly. The simple fact is that ARM is terribly slow in real-world use. You can blame the compiler, the architecture, the fabrication process, the cache size, whatever... but the end result is the same.

Oh yeah, because saying an architecture as a whole is "slow" makes so much sense. You're aware that it beats anything made by Intel on performance/watt, right? Sure, there are no ARM chips currently competitive with desktop and laptop x86 offerings, but we're talking about cellphones and netbooks here.

Re:self-modifying code == JIT

[r00t]

If you're not going to run the JIT code why on earth are you compiling it anyway? There's a reason why it's called JIT. Not to mention that you can just stick the cache ops right before the JIT code is run, instead of as it is compiled.

Code contains branches. For a branch that isn't taken, you have a few choices.

A. You don't JIT until you hit the branch. On x86, this is mildly bad because you add instruction cache pressure ever time you code back into the JIT engine. On ARM, this is severely bad because you're doing a system call for every handful of JITed instructions.

B. You batch things up. You'll JIT some stuff that never runs.

I forgot to mention another difference. ARM caches tend to be virtually indexed and/or virtually tagged. This normally means that you need to flush the whole thing. Partial flushes are too complicated. On x86, the cache is physically indexed and physically tagged. Properly flushing a cache line is trivial; there aren't any aliasing issues.

Re:self-modifying code == JIT

[marcansoft]

You don't JIT until you hit the branch. On x86, this is mildly bad because you add instruction cache pressure ever time you code back into the JIT engine. On ARM, this is severely bad because you're doing a system call for every handful of JITed instructions.

System calls have tiny overhead on just about every system. Except x86.

Nevermind that I doubt most JIT stuff out there works at a branch level; they tend to compile at a procedure level.

You batch things up. You'll JIT some stuff that never runs.

ICache flushes are going to do nothing for a JIT anyway (most of the time), so they are little overhead too. So we've eliminated system calls and ICache invalidates as valid points for your argument. You're down to claiming that a single DCache partial store at the right point is going to be more expensive than the ridiculously complex and poor auto-flushing that x86 does. Good luck with that.

ARM caches tend to be virtually indexed and/or virtually tagged. This normally means that you need to flush the whole thing.

That's bullshit. You can't JIT from one address space affecting another without telling them about it anyway (else how are they going to know what to run?), so they'll have a chance to invalidate the right thing anway (hint: not flush, get your vocabulary right. If you write code, the writer has to store/flush it in DCache, and then those who want to run it have to invalidate it in ICache).

Properly flushing a cache line is trivial; there aren't any aliasing issues.

Properly flushing a cache line is all but impossible on x86, since it only got a cache line flush instruction with the introduction of SSE2. Before that, the only real cache management instruction was "flush and invalidate everything in every cache all at once". x86 depends solely on guesswork by the CPU, and guesswork is by definition going to be worse than the programmer flushing what's needed ONLY when it's needed.

Finally, x86 is a horrible instruction set to JIT/translate to anyway. JIT for RISC is a lot more efficient and easier to write. And if you look at emulators that do binary translation, x86 is just about the worst possible arch for that. Translating RISC to x86 is horrendously inefficient.

Re:self-modifying code == JIT

[r00t]

ICache flushes are going to do nothing for a JIT anyway (most of the time), so they are little overhead too. So we've eliminated system calls and ICache invalidates as valid points for your argument. You're down to claiming that a single DCache partial store at the right point is going to be more expensive than the ridiculously complex and poor auto-flushing that x86 does. Good luck with that.

I looked up the ARM code for Linux 2.6.31 and it doesn't generally work the way you think it does.

The whole instruction cache gets invalidated.

Ouch. Even the Pentium-4 wasn't that awful.

(hint: not flush, get your vocabulary right.

Normally they go together. ARM Linux has exactly one system call for this, and the name is "cacheflush".

Properly flushing a cache line is trivial; there aren't any aliasing issues.

Maybe you should tell the ARM Linux developers how to do this if you really think it is so easy.

Properly flushing a cache line is all but impossible on x86, since it only got a cache line flush instruction with the introduction of SSE2.

Well, if you want to be explicit. Normally it comes free.

x86 depends solely on guesswork by the CPU, and guesswork is by definition going to be worse than the programmer flushing what's needed ONLY when it's needed.

You ignored my example showing that this is not the case. The delayed flushing of x86 lets you take advantage of normal background writeback and it lets you take advantage of the possibility that the data might never need to be flushed.

Finally, x86 is a horrible instruction set to JIT/translate to anyway. JIT for RISC is a lot more efficient and easier to write. And if you look at emulators that do binary translation, x86 is just about the worst possible arch for that. Translating RISC to x86 is horrendously inefficient.

Hell no.

You get full-size offsets and other constant values on x86. There is no need to screw around with painful restrictions. Look at the constant generation offered by ARM and weep. It's very limited and even redundant. Jump offsets are limited too. If you generate too much ARM code in one place, you can no longer reach constant values that had to be stored near the instruction stream.

Translating RISC to x86 requires a register allocator for decent performance. Fortunately, there is no value in RISC binaries and thus no need to translate from RISC to x86. :-)

Re:self-modifying code == JIT

[marcansoft]

I looked up the ARM code for Linux 2.6.31 and it doesn't generally work the way you think it does.

The whole instruction cache gets invalidated.

Ouch. Even the Pentium-4 wasn't that awful.

Ah, so you're blaming a poor OS implementation now.

Normally they go together. ARM Linux has exactly one system call for this, and the name is "cacheflush".

That's probably because JIT isn't popular enough that someone cared to add proper support.

Well, if you want to be explicit. Normally it comes free.

No, it comes at a huge expense in die area and power, and at a drop in performance due to unnecessary flushing by the CPU logic. The only "free" thing about it is the programmer doesn't have to do anything.

You ignored my example showing that this is not the case. The delayed flushing of x86 lets you take advantage of normal background writeback and it lets you take advantage of the possibility that the data might never need to be flushed.

"Delayed" flushing isn't so "delayed". Stop pretending like x86 implementations are 100% perfect and ideal at flushing only when necessary. a) they aren't nearly as optimal in your case as you think, b) they flush tons of unneeded stuff because they guess wrong, and they can't afford to miss a flush and cause bugs.

You get full-size offsets and other constant values on x86

You're proving my point. This is a waste of code and decoding logic (all the variable-length instruction crap). And it makes translating RISC to x86 a lot slower because you have to somehow recognize things like (this is powerPC) "lis 1, 0xdead" (more code) "stw 2, 0xbeef(1)" as a store to 0xdeadbeef. No one does this of course, you just have to waste all the time using complex and large CISC ops for trivial RISC ops.

There is no need to screw around with painful restrictions.

What are these "restrictions" that you speak of? Hint: on x86, each register is optimized a different way, which means that for proper performance compilers and JITs have to deal with not only a restricted set of registers, but very particular and odd semantics as to which is the faster register to use. On ARM all registers are just about equal, and on PowerPC all but a couple special purpose ones are too.

Look at the constant generation offered by ARM and weep. It's very limited and even redundant.

Which is why you use PC-relative loads for large constants. ARM constant generation covers the vast majority of common cases. CPUs aren't about wasting space and time giving you the ability to do everything in one instruction. That's the outdated CISC mindset.

Jump offsets are limited too.

Bullshit. Jump range is +/-32MB. If your code is larger than 32MB then you just use loads for external calls. Most single units of code (executables, shared libraries, etc) are well under 32MB. The largest program on my box is blender, which is 15MB.

If you generate too much ARM code in one place, you can no longer reach constant values that had to be stored near the instruction stream.

Constant values are typically stored after each function. If your function is longer than the offset range (exceedingly rare), then all you have to do is put a pool in the middle. Laugh all you want (it's funny), but it's not a problem and does not affect performance. (The crap that x86 compilers have to do these days isn't funny, it makes me weep and cringe every time I try to read x86 code. x86-64 is somewhat better in that regard.)

Translating RISC to x86 requires a register allocator for decent performance. Fortunately, there is no value in RISC binaries and thus no need to translate from RISC to x86. :-)

Why did Intel ditch the StrongARM?

[lotho brandybuck]

What I want to know about this is why Intel sold off the StrongARM line... a few years ago, weren't these the fastest ARMs on the planet? Was it a case of "not invented here?"

Re:Why did Intel ditch the StrongARM?

[hattig]

They sold it to Marvell.

Marvell just announced a quad-core ARMv7 architecture (Cortex A9) system-on-chip that will have been an evolution of StrongARM / XScale.

Not In Here syndrome wins again, but I can see Intel's logic where they have an investment in x86 that they need to keep alive for a long time or they will become irrelevant, maybe in ten, maybe twenty years time.

if arm is so great

[Anonymous Coward]

why dont they build super computers or servers with it? wouldnt it save lots of energy?

Re:Needs to be open no APP store lock / sim locks

[Yfrwlf]

Yes, curse things that allow me to run what I want! Those all suck! What consumers would want to run what they want??? Oh yes, that's right, the ones who don't know anything but what they see before them, until their friends show them what they could have been running instead if it weren't for them using a locked down device with no freedom.

Re:Needs to be open no APP store lock / sim locks

[Yfrwlf]

Most of the rest of the world doesn't have some ideological battle against the man to fight, they just want their phone to work.

Let me reply again with less sarcasm and more clarity. =P

No, the world always wants more freedom. Freedom should not be belittled, hence my previous comment. That's what the "fight against the man" represents, is a desire to not be controlled, and in this way consumers have many reasons to rebel. Yes, you're right in that some may be happy being lulled into the "my device is an appliance, with the software locked to the hardware, and with the software locked down and restricted to what they want me to run instead of what I want to run", but when consumers see the freedom they could have and the programs they could be running if their device was more open, they will want that freedom too.

Not only does it effect the users directly, but the users should also be aware of the issues that effect developers as well. If the device of your choosing happens to lock developers out, that will end up hurting *you* too by limiting your choice in the future as well, and you will never know the programs which could have been by sticking to your restricted device.

Re:Needs to be open no APP store lock / sim locks

[BitZtream]

First off, Android isn't impressing anyone, don't try that crap.

The other two are used on more phones by more companies and have been around longer they have bigger groups that enjoy them.

If you watch the trends however, its not staying that way.

iPhone won't be the top smart phone, they aren't trying to be. But it IS massively popular.

I did vote with my wallet, and I don't care if I have root on my phone, I want it to work, not dick around with it and have it break in the middle of a call. Contrary to popular belief most people could give a fuck about that sort of thing, even if the very disconnected from reality slashdot crowd yells loudly about it.