Intel and LG Team Up For x86 Smartphone 157
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."
Intel and LG Team Up For x86 Smartphone (Score:4, Insightful)
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 (Score:4, Interesting)
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
FFS (Score:3, Informative)
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: (Score:2)
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.
What for ? (Score:3, Insightful)
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
Re: (Score:3, Informative)
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 S
Re: (Score:2)
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
Re: (Score:2)
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: (Score:2)
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: (Score:3, Informative)
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 [mozilla.com] (this caused a lot of grumbling on Firefox's support forums), but the latest Opera happily runs on Windows 98 [opera.com].
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 [freepascal.org]. It's 95% Delphi, but FOSS software.
While I'm mainly a C programmer these days, I've quite impre
Re: (Score:2)
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: (Score:2)
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: (Score:2)
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 strea
Re: (Score:2)
Re: (Score:2)
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 techn
Re: (Score:2)
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
Re: (Score:3, Insightful)
Part of the plan would surely involve getting into the IP core business, like ARM. AMD are doing it [eetimes.com], and some Intel researchers already have a prototype [acm.org].
Re: (Score:2)
Re: (Score:2, Informative)
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 [wikipedia.org]... 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 (Score:5, Insightful)
...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: (Score:2)
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!
Sounds like...hell! (Score:5, Funny)
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! (Score:5, Interesting)
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...
but it's still a phone (Score:2)
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?
Can we lose the can't do attitude? (Score:5, Insightful)
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.
Can we use the right tool for the right job? (Score:2)
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 manu
Re: (Score:2)
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 wit
Re: (Score:2)
I did this once.
Luckily the SIM card still worked when I purchased a new, unlocked, phone.
And now imagine (Score:2)
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: (Score:2)
http://www.liliputing.com/2010/01/shuttle-launches-push-for-notebook-motherboard-standards.html [liliputing.com]
Re: (Score:2)
Re:Sounds like...hell! (Score:4, Interesting)
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: (Score:2)
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
Competition (Score:2, Interesting)
Has anyone made a scatter plot of benchmark score vs watt, for a given benchmark and various x86 and ARM processors?
Do Not Want (Score:4, Interesting)
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: (Score:2)
I am honestly curious: What advantage is a "modern RISC architecture" if you are not writing in Assembly anyway?
Re:Do Not Want (Score:5, Informative)
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 (Score:5, Interesting)
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: (Score:3, Informative)
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 co
Re: (Score:3, Interesting)
Re: (Score:2)
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 (Score:5, Interesting)
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 (Score:4, Interesting)
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.
self-modifying code == JIT (Score:2)
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: (Score:2)
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 cheape
Re: (Score:2)
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
Re: (Score:2)
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.
Re: (Score:2)
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
Re: (Score:2)
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.
ICache f
Re: (Score:2)
If and when the LLVM JIT targets ThumbEE, hey presto, the performance problem disappears. e.g. using Redhat's shark implementation of Hotspot.
Re: (Score:2)
"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.
your textbook/professor was wrong (Score:3, Informative)
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 co
Re: (Score:3, Informative)
Do you even have to ask after all the articles on slashdot? Nokia N900. (Not Ubuntu, but meets all your other criteria.)
Re: (Score:2)
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? (Score:5, Informative)
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.
you've read Hennessy/Patterson/Tannenwhatever (Score:5, Interesting)
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: (Score:3, Informative)
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: (Score:2)
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: (Score:3, Informative)
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: (Score:2)
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. /watt levels ARM provides on 40-60nm, now that ARM is moving downwards into the 28nm a
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
Re: (Score:3, Interesting)
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,
Re: (Score:2)
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
Re: (Score:2)
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 expensi
Re: (Score:3, Insightful)
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 ban
Re: (Score:2)
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: (Score:2)
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 (Score:4, Insightful)
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: (Score:2)
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 [thedailywtf.com].
Who codes x86 only in this age? (Score:2)
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 f
Re: (Score:2)
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: (Score:2)
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
Re: (Score:2)
One x86 to rule them all? (Score:2)
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? (Score:5, Funny)
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: (Score:2)
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 bur
what will it look like (Score:2)
My
Re: (Score:2)
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 cann
Re: (Score:2)
here is the link http://www.linuxfordevices.com/c/a/News/ARM-and-AMD-spinoff-Globalfoundries-partner/ [linuxfordevices.com]
"than the Atom" (Score:2, Insightful)
uh Mooresville is the latest iteration of the Atom.
Advantages... (Score:2, Insightful)
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: (Score:2, Interesting)
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 so
Re: (Score:2)
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 the
Needs to be open no APP store lock / sim locks as (Score:3, Insightful)
Needs to be open no APP store lock / sim locks as well.
Re:Needs to be open no APP store lock / sim locks (Score:3, Insightful)
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.
Re: (Score:3, Insightful)
Re: (Score:2)
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.
How succesfull is the closed app store? (Score:2)
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.
Re: (Score:2)
Re: (Score:2)
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
"compete" (Score:2)
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.
Super Smartphones? (Score:2)
Re: (Score:2)
Twould be interesting if you could simply format this phone and put your own OS on it.
Re: (Score:3, Insightful)
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: (Score:2)
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.
Re: (Score:2)
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: (Score:3, Informative)
Re: (Score:2)
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: (Score:2)
Re: (Score:2)
Perhaps I should point out at this point that Intel has, in fact, made several [wikipedia.org] non-x86 [wikipedia.org] processors [wikipedia.org].
In fact, the 64-bit variant of x86 [wikipedia.org] 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: (Score:2)
The tried. It's called Itanium. People want their x86.