Slashdot Mirror
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."
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.
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.
Geeks don't grock information, they grep it.
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).
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.
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.
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.
Do what thou wilt shall be the whole of the Law
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.
I am TheRaven on Soylent News
Do you even have to ask after all the articles on slashdot? Nokia N900. (Not Ubuntu, but meets all your other criteria.)
My Sig: SEGV
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.
MaraDNS is an open-source DNS server.
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.
My Sig: SEGV
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.
"People who think they know everything are very annoying to those of us who do."-Mark Twain
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. :-/