Slashdot Mirror

You can read more in the slide 4 from ARM's presentation at http://www.arm.com/files/downloads/ARMv8_Architecture.pdf:

- Fundamental motivation is evolution into 64-bit
- - Ability to access a large virtual address space
- - Foresee a future need in ARM’s traditional markets
- - Enables expansion of ARM market presence

- Developing ecosystem takes time
- - Development started ahead of strong demand
- - ARM now seeing strong partner interest in 64-bit
- - -Though still some years from “must have” status

The ARMv8 architecture consists of two main execution states, AArch64 and AArch32. The AArch64 execution state introduces a new instruction set, A64 for 64-bit processing. The AArch32 state supports the existing ARM instruction set.

- ARM press release

Here's a better description of the new Architecture:

ARMv8 Architecture PDF

It's entirely possible smartphones will have more processing power than next gen consoles by the time they come out.

Bzzzzzzt. Thanks for playing.

The improvements are tremendous, but the Cortex-A15 Processor almost certainly falls short of the original CoreDuo.

Trinity packaged in a quad-channel socket FM2 with integrated Radeon 7000 graphics core is about the level of performance I expect from the next generation consoles by the time they arrive.

Sony originally hoped to make Cell a one-chip solution. But hey, they'll probably go full custom again just to preserve the DRM co-processor. Maybe they'll try to woo the new chick at IBM for another tango.

The modern phone platforms have been shipping with "TPM" for quite a while:
http://www.arm.com/products/processors/technologies/trustzone.php

The Cortex-A15 will be available in up to octo-core configurations at 2.5Ghz, using a fraction of the power of a P4 (vs the 1.0Ghz benchmark you provide). You can make up arbitrary hardware requirements for "most people" but that doesn't exactly explain why Apple is selling tens of millions of iPads to ecstatic customers with a fraction of the "power" of a P4.

Well, pretty soon we'll have 2.5Ghz (up to octo-core) ARM CPUs so it might be a good time to get your feet wet in the ARM world.

Second of all, why the hell would Intel have something to fear from a 96 MHz Cortex-M3 part? This makes no sense, since this isn't even a segment Intel is actively pursuing. What might be competitive with Intel's offerings could be something like an Cortex-A15 part (which AFAIK there are none of on the market as of now) or even a Cortex-A9 part with some of the low-end Atoms. However, the Cortex-M3 definitely has absolutely nothing to do with any of Intel's offerings, so this clearly demonstrates a lack of understanding of how microprocessors work in the market (and how ARM and something like Arduino falls into the real-world marketplace) on the part of the submitter.

Second of all, why the hell would Intel have something to fear from a 96 MHz Cortex-M3 part? This makes no sense, since this isn't even a segment Intel is actively pursuing. What might be competitive with Intel's offerings could be something like an Cortex-A15 part (which AFAIK there are none of on the market as of now) or even a Cortex-A9 part with some of the low-end Atoms. However, the Cortex-M3 definitely has absolutely nothing to do with any of Intel's offerings, so this clearly demonstrates a lack of understanding of how microprocessors work in the market (and how ARM and something like Arduino falls into the real-world marketplace) on the part of the submitter.

Can you confirm that that device will have the optional FPU system?

http://www.arm.com/products/processors/technologies/vector-floating-point.php
http://www.arm.com/products/processors/classic/arm11/arm1176.php, under specifications under ISA support, FPU *OPTIONAL* this is a must have.

This is listed as OPTIONAL... media codex require the FPU to be used ie: LAME, ogg etc... for encoding...

I am not discussing what it may decode, ENCODING of audio for streaming in mp3, ogg, AAC, FLAC etc...

Can you confirm that that device will have the optional FPU system?

http://www.arm.com/products/processors/technologies/vector-floating-point.php
http://www.arm.com/products/processors/classic/arm11/arm1176.php, under specifications under ISA support, FPU *OPTIONAL* this is a must have.

This is listed as OPTIONAL... media codex require the FPU to be used ie: LAME, ogg etc... for encoding...

I am not discussing what it may decode, ENCODING of audio for streaming in mp3, ogg, AAC, FLAC etc...

New hardware has bought us the ability to use managed code for most (not all) software. Isn't this much better than expecting every programmer to perfectly manage his memory every time? Just wait a couple more years and we won't be feeling the hardware pinch even on phones.

Personally I hope new machines start learning from the past and implementing processor instructions to make GC easier and support things like runtime type checking. ARM has ThumbEE which is definitely a step in the right direction. Basically, I see the proliferation of "Managed" run time environments as a consequence of computer architectures remaining dangerous to write code for — we can pack a lot of transistors onto a die nowadays so why not use some of that space for features people have been implementing in software for decades?

Intel's aquisitions may be changing that. See their quote on this recent press release.

ARM does have a logo. It's just rather plain. typing it out is close enough. Maybe they're going with elegance in simplicity, even in their logo. :)

The conditional instructions in ARM work very well in pipelined designs, which is why Intel adopted the same idea in Itanium. You basically execute the instructions unconditionally, but only retire the result if the condition is met, meaning no pipeline stalls for a bad prediction. It costs more to stall the pipeline until you know which branch to take than it does to just execute a few instructions and discard the results (at least, for short branches).

ARM chips do have branch predictors and have since at least ARM11. Here's the reference for Cortex A8's predictor. Unlike x86, it doesn't actually depend on it so heavily. It's important for long branches, where you could otherwise completely fill the pipeline with instructions that will never be retired.

The free barrel shift is really useful for pointer arithmetic. In a language like C, you might do something like:

int *a = b;
a += n;

The second line really means 'add n*sizeof(int) to a'. Since sizeof(int) is always a power of two, this really means add n left shifted by a constant. A lot of pointer arithmetic operations can be compiled down to a single ARM instruction.

16 GPRs is not huge by RISC standards - most RISC chips have 32 - but it's still pretty good. x86-64 has the same number if you are doing 64-bit operations (ARM needs two registers per 64-bit operand, so you effectively only get 8 64-bit GPRs), but in all other cases it does well. This doesn't make a huge difference with C code (although it is nice), but it makes a massive difference if you are compiling a language like Lisp or Haskell. Compare the benchmarks of the Steel Bank Common Lisp compiler on SPARC and x86 - it's close to the performance of a C compiler on SPARC, but a fair way behind on x86.

A modern x86 implementation actually cheats slightly. The ISA has register-memory instructions and aliases the top few addresses in the stack segment with hidden registers, so if you use these instructions you are really doing register-register operations on implicit registers. As you can imagine, this adds a lot of complexity to the entire pipeline, and comes with an associated power consumption cost.

The only reason that x86 is competitive at all is that Intel has economies of scale that let it throw huge teams of engineers at it. They can design and produce much more complex chips than the competition, and their process team lets them fit them on a smaller die than the competition. If Intel threw the same resources at another architecture, they'd produce something amazing - the ARM-compatible line that they produced was pretty impressive, but they sold it to Marvell to concentrate on x86...

Linux Support for the ARM Architecture

According to ARM's web site, there are 'Long Physical Address Extensions (LPAE)', that allow addressing 1 TiB (40 bit). The marketing schematics for the processor mentions a "Virtual 40b PA" for each CPU.

Unfortunately, the detailed A15 documentation is not available yet, so we're left to speculate over what this means. But at the same time, the supported architecture remains ARMv7 and there is no hint of any major changes on the instruction side. An easy implementation would use a MMU with 40-bit physical addresses to map this amount of memory, but the process size would remain at 4 GiB to avoid any drastic change to the programming model.

Answering my own question: I guess it is DRM amongst some processor scheduling/bus control stuff, yeah. There's a reference to "data security using the TrustZone memory model" below:

The Snoop Control Unit (SCU) connects one to four Cortex-A5 processors to the memory system through the AXI interfaces. The SCU maintains data cache coherency between the Cortex-A5 processors and arbitrates L2 requests from the processors and the ACP. The SCU programmers model also includes support for data security using the TrustZone memory model.

-- Cortex-A5 MPCore Technical Reference Manual - 2.1.8.: Snoop Control Unit

It's part of maintaining cache-consistency (I presume between multiple processors etc.) http://infocenter.arm.com/help/topic/com.arm.doc.ddi0407e/CHDFJICC.html

After Samsung "announced that it is adopting the Mali [GPU]...for its future graphics-enabled ...SoC ICs", it sounds plausible that the speedup and the lack of information about the GPU could relate to this Mali technology from ARM.

ARM has recently released source for some parts of the Linux drivers for current Mali GPUs under GPLv2, which might be the first step towards ARM SoC's with fully-open GPU drivers.

There are no guarantees, but at the moment it appears that ARM is much more receptive to the idea of open GPU drivers than Imagination Tech (PowerVR GPUs) or NVidea.

I think it's a shame that AMD isn't moving faster w.r.t the embedded/mobile market. Sure, they're planning to make SoC's with a GPU on the same silicon, but as of last week they're not currently interested in competing with ARM for market share. And AMD's the chipmaker that's most actively supporting and creating open drivers for their graphics hardware.

It'll be interesting to see where the hardware goes in the next couple of years. Can Intel (and AMD, if they get serious) pull marketshare from ARM, or will the RISC chip reign supreme?

Is this anything more than ARM's Cortex A9 making it into chipsets?

Don't get me wrong, it's an extraordinary amount of progress, but it's not like the chip makers are doing all the innovation and competing here; ARM's done the real smarts and licensed the CPU IP to a number of chip makers who then have to integrate, verify and make a system out of it.

So it's no surprise that all the chip makers are coming out with multicore A9's at roughly the same time.

It's not quite the same thing. HTC is not an ODM, it's an OEM. It has its own software and brand name. When I talked to someone on the Microsoft stand at Computex he told me that HTC was irritated about Windows Phone 7. Since WinPhone can't run native applications HTC would have to rewrite their software (e.g. TouchFlo) in .Net to run on it. What they really wanted was a new version of Windows Mobile with the latest Windows CE kernel. Windows mobile 6.x uses Windows CE 5.x which has a 32MB per process limit because it uses FCSE on ARM. Windows CE 6.x has a 2GB per process address space.

So HTC want later versions of Windows Mobile. If Microsoft want to build Windows 7 Phone devices they'd be better off getting someone like Foxconn, Quanta or Compal to do it. They are ODMs and basically do whatever the customer wants. The end product would then be branded Microsoft (or Kin, Yo!, Hipstaah or something). Foxconn for example make the iPhone.

Now my argument is that they could do both. They'd sell Windows Mobile 7 based on WinCE6 with native app support to HTC who'd sell devices to me. And they'd get an ODM to make the Windows Phone 7 devices which they'd then sell effectively to operators the way Apple does with the iPhone. These devices would be slick and locked down and would have a low upfront cost like the iPhone does, though you need to sign up for an expensive monthly contract some of which would go back to Microsoft. This is how iPhones work.

I think the two markets are actually complementary. People that want an iPhone don't want Windows Mobile. And people that want Windows Mobile don't want an iPhone. And they certainly don't want a Microsoft knock off of an iPhone whch won't run their old apps.

Interesting speculation but unlikely. The Java-specific mode (Jazelle) is deprecated; ARM's for a few years already been moving instead to a mode that supports CLR and JVM managed runtimes equally well, called ThumbEE, which is already in the newer Cortex A8-based smartphone chipsets:

ThumbEE in Jazelle article on Wikipedia
Information on ThumbEE from the ARM tech docs

It's a much more elegant approach -- do all the easy transformations via JIT compilation to the existing native ARM instructions, and add a handful of extra instructions to speed up the expensive things you do all the time, like null pointer checks and array bounds tests.

It does have Neon but no powerpc. Strange that this information did not came from someone with a compiler. Does apple withhold information what code can be generated? Are devs so spooked by the apps license?

ARM 8 means no out-of-order or dual issue.

Correction: ARM Cortex 8 does mean dual issue. I apologize for the error. (I was correct about the lack of out-of-order execution.)

http://www.arm.com/products/processors/cortex-a/cortex-a8.php

Also, I think I was remiss in not mentioning that the Tegra 2 is only available in small (prototype) quantities right now. But I believe the first Tegra 2 devices will ship within the next 3 or 4 months.

steveha

Otherwise, it will just perform a word read, and if the pointer isn't aligned you get garbage.
Some but not all arm chips can be told to generate an exception in this case.

from http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/1228.html
ARM processors with full MMUs (e.g. ARM920T) support optional alignment checking where the processor will check every access to ensure it is correctly aligned. The MMU will raise a data abort if an incorrectly aligned access occurs.

Some ARM partners using simple cores such as the ARM7TDMI have implemented alignment-checking for their ASIC/ASSP. This can be done with an additional hardware block external to the ARM core, which monitors the access size and the least significant bits of the address bus for every data access. The ASIC/ASSP can be configured to raise the ABORT signal in the case of an unaligned access. ARM recommends that such logic is included on ASIC/ASSP devices where code will be ported from other architectures.

Linux can use these exceptions to fix up access if you desire (or you can set it up to generate a bus error signal to help in debugging)

from http://www.mjmwired.net/kernel/Documentation/arm/mem_alignment
15 Now for user space applications, it is possible to configure the alignment
16 trap to SIGBUS any code performing unaligned access (good for debugging bad
17 code), or even fixup the access by software like for kernel code. The later
18 mode isn't recommended for performance reasons (just think about the
19 floating point emulation that works about the same way). Fix your code
20 instead!

Umm... ARM would beg to differ.

It may be less similar to ARM Cortex reference designs than some of its competitors; but it is definitely ARM based.

finally i can get my neocortex-m3 implant!

Nehalem is about 800 DMIPS/Watt (75500/95W), Cortex A9 is about 8,000 (4000/.5W). The Nehalem figure is based on Sandra results for the Core i7 870 link, Cortex is based on ARM's numbers for their power efficient model link

I'm tired of people shoehorning the power-hungry x86 architecture into small devices. If there's one thing that Apple did right it's not using the Atom. The WePad runs Linux: there's no reason to stick with the legacy x86 architecture. Even Adobe Flash works on ARM (just not Flash 10 yet).

How did you get modded up? Linux runs on the ARM processor too, as noted on the arm.com website.

and SuSe lists none of their repositories in their installer

Software update ... starts the package manager.

Click on "Repositories" menu (duh!)

Click on "add" button.

Click on the "community repositories" radio button, and/or choose "scan with slp"

Right now my main desktop has more than 360,000 files reported by apt as being installed.

... and I've got between 2 and 3x that. Pick the defaults and it works. I get conflicts because I override the defaults, but I also know how to fix that with a quick click on the second choice instead of the first.

So what cpu and motherboard are you running on? It can't be Intel or ARM or AMD

And which of these companies claim to be devoted to open source? Not a one

Both AMD and Intel are into open source. Do your research. They're both members of the Eclipse Foundation, AMD has contributed hardware to developers, as well as the servers running groklaw, etc., and Intel is active with all sorts of stuff, and ARM sponsored the code to get debian to run on ARM.

So again, since all these companies have put money where their mouth is with respect to open source - Intel, for example, contributed 4.1% of the kernel code

Intel's position as the fourth-biggest corporate source of contributions "happened by virtue of the work done by four of the top-20 developers. ... Intel has a lot of people working on the kernel, many of whom spend little time in the limelight," Corbet wrote in the same posting.

So, since Chipzilla also works with the Beast from Redmond, my question stands - what cpu and motherboard do you use? Because that's no reason not to use OpenSUSE. Novell has done a LOT for the community.

Name one product that ARM makes?

ARM Compiler

The Xbox merely repackages IP from Intel, NVidia, Samsung, and Seagate. Hardly counts as a Microsoft product when you source so much IP from other companies, does it?

Buttercup sat up in bed. It must be his teeth. The farm boy did have good teeth, give credit where credit was due.

It's Microsoft's keyboard division that validates Microsoft as a manufacturing venture and not a patent troll.

Flash is proprietary I'd like to see it fade into oblivion.

It isn't going to happen any time soon.

Flash has supported H.264 since Flash Player 9 in 2007.

Flash Player 10.1 supports H.264 video hardware decoding on desktop and mobile devices and hardware (GPU) graphics rendering on mobile devices
  Flash Player 10.1 hardware acceleration for video and graphics, Flash Player 10.1 Beta 2 - Downloads

Freescale is bringing Adobe Flash Player 10.1 to its ARM based i.MX platforms, enabling the creation of consumer products running either the Linux or Android operating systems.
Smartbooks, smartphones, netbooks and other Internet-centric consumer products based on the i.MX51 family of processors will be able to access full H.264 video playback when accessing rich content built with the Flash Platform, including HD and SD video from sites such as YouTube. Collaboration For Flash Player 10.1 on Freescale i.MX

Um, what? ARM isn't trying to compete with GPU manufacturers.

I guess you never heard of ARM Mali.

Everyone wants to move to 64 bit on x86 not for the larger word size, but for the fact that the ISA is a bit more sane (more GPRs, fewer restrictions on target and destination registers, simpler memory model) giving an overall speed benefit.

My current computer has 4GB of main memory. I bought it 3 years ago. 64 bits is about addressing space indeed. One of ARM's competitors is Intel Atom. Atom is 64-bit. VIA Nano: also 64-bit. If people expect ARM to be used in tablets and netbooks, it is going to need the extra addressing space. Linus himself said it best: once you add that to the virtual memory space required by the GPU (e.g. my 3 year old graphics card has 512MB) there is not much left. Even the new generation of GPUs (e.g. Tesla) is planned to be 64-bit.

I replaced my netbook with a Nokia N900, because of:

- Built-in physical keyboard, and external full-size standard bluetooth keyboard.
- It is the first { Linux + X11 + phone } that works nicely (OpenMoko was a poor attempt), and it's Debian based! (Maemo).
- As music player: impressive.
- As video player: impressive for h264 (hardware accelerated), not bad for mpeg4-baseline.
- As photocamera: quite good (5MP + two-LED flash, quite sharp for a mobile camera, and much better than my previous standalone 3MP Canon Powershot 4 year old camera).
- As agenda: very good.
- For notes: I love the default notes application provided by Nokia. You can use Conboy too, which is also OK.
- Multitasking: very good, the best I've seen in smartphones, because of using Linux plus plenty RAM (256MB + 768MB for swap) is years-light ahead from Symbian, iPhone, and Windows Mobile devices.
- User interface: uses desktop composition, but with the vertical sync disabled (it is possible to enable it, but I will not enable it until some other does it and confirm that it is safe). That makes it less smooth than the one from the iPhone or from Android devices.
- Geekness: Linux, X11, 256MB RAM + 768MB of swap, 2-way in-order supescalar ARM CPU (ARM Cortex A8 @600MHz, 1200MIPS, 2.4-4.8GFLOPs (4.8 GFLOPs when using the VMLA -FMAC, floating point multiply and accumulate-)), ssh, sshd, xterm, dosbox, game console emulation, perl, python, clisp, ml, airodump/aircrack, etc. With the exception of the C++ compiler, which haven't manage to install into the device yet (I'm using a cross compiler in my main PC, provided with the SDK), because I'm afread of broken the shared library links (I'll do it when I'm sure I'll don't break anything), the device runs most Linux applications!
- Presentations/slideshows/portable video player/etc: TV-out (composite NTSC/PAL plus stereo sound, via 3 RCA connectors).
- Storage: 32GB built-in (write speed is about 10 MB/s), expandable up to to 48GB with an additional 16GB micro-SDHC card.

It's a port, I tried it this morning: runs in full resolution (800x480), accelerated 3D, and it is very smooth. The N900 is tiny monster: Linux, X11, composite desktop, 256MB RAM + 768MB swap, 2-way-in-order superscalar ARM ARM Cortex A8 CPU @600MHz, 1200MIPS, 2.4-4.8GFLOPs (4.8 GFLOPs when using VMLA opcode -similar to the FMAC, floating point multiply and accumulate-), hardware accelerated OpenGL ES 2.0, etc.

As contrast, using Dosbox on the N900 is slow, barey enough for simulating an 8MHz 80286.

Fine:
http://www.arm.com/markets/embedded_solutions/armpp/25333.html

Doesn't take much looking.

The 48-core chip that Intel demonstrated is 45nm!

Also, Cortex-A9: "For 2000 DMIPS of performance when designed in a TSMC 65 nanometer (nm) generic process the core logic costs less than 1.5 mm^2 of silicon." ( http://www.arm.com/products/CPUs/ARMCortex-A9SingleCore.html ) So it seems "up to 3 mm^2" in your quote really means "up to" (and for a much older core of course, when it was just launching 4 years ago)

And Cortex-A9 "consumes less than 250mW per core"...

ARM recently released a 2GHz dual-core A9 hard-core for TSMC's process (40nm). I forget the power consumption, but it was quite low compared to Atom.

http://www.electronicsweekly.com/Articles/2009/09/16/46955/arm-produces-hard-cortex-a9-for-high-performance.htm

ah... http://www.arm.com/news/25922.html

"The Cortex-A9 power-optimized hard macro implementation delivers its peak performance of 4000 DMIPS while consuming less than 250mW per CPU when selected from typical silicon."

http://www.arm.com/products/security/trustzone/index.html

Yea cool

There are no Atoms in phones because they're way too hungry for a phone cpu. ARM have stuff that runs at around 85mW per GHz. Compare that to the lowest Atom at 0.65W for 800MHz.

There seems to be a lot of comments about how the average joe is going to be pissy when he discovers that he can't run his windows applications on his arm netbook, or print well for that matter. That is obvious, and therefore redundant to talk about. This is a website dedicated to (hopefully intelligent) nerds, right? I'm more interested in running Linux anyway, or possibly an up-and-coming Mac OS X for ARM.

I would like to say to DELL - excellent idea!!! ARM for netbooks / smartbooks only makes perfect sense! The battery will last longer, they're fully capable of doing everything that a netbook should (including all multimedia applications), they're SILENT / FANLESS. All of that makes me (a green geek / engineer) very happy! If you could pull off an aluminium unibody, then you would have Apple beat if they ever got around to making a Mac smartbook.

My advice though, is to choose your components wisely. People won't want to wait for application contexts to be reactivated from swap, so make sure that you have enough RAM to keep everything going. Also, make sure that you prelink all binaries so that loading times are much faster! Last but not least, I would highly recommend that you choose a dual-core ARM SoC like the TI OMAP-4, which is based on the Cortex-A9 ARM family. With dual-cores, there would be many more pipelines available for concurrent threads, which means very little noticeable lag times.

Specifically for the OMAP, I really hope that the integrated PowerVR 3D graphics core and integrated video codec will get full Linux support at some point soon. TI seems pretty dedicated to supporting Linux on their devices, so I don't think that full support is unrealistic. The enhanced DSP ARM instructions will accelerate any multimedia applications in the mean time, and those are fully supported by GCC, with optimizations in the works for mplayer, ffmpeg, etc, until a decent architecture-agnostic kernel drm layer is in place, with PowerVR / IVA support.

For Windows enthusiasts, I'm sure that Windows 7 will be available at some point for ARM, as we have seen some of the demonstrations already at Computex (although Android seemed to be much easier to port). Will Microsoft even bother making a compatibility layer for ARM? I have to hand it to Apple, that they are in a better position than MS to make a fully featured ARM netbook, given their universal binary format in Mac OS X.

Not much, if you have the right hardware.. http://www.arm.com/products/multimedia/java/jazelle.html

This is a bit confusing, but ARM claims 250 mW. That may be for a 2000 DMIPS single core, or it might be for an 8000 DMIPS quad core. Either way, that's 1 W at most for a quad, or half of Atom's power consumption.

If you're counting the SoC power, then please count the Atom's north and southbridges.

I sure wish the ARM devices would hit the market ASAP

They're on their way:
http://blogs.arm.com/smart-mobile-devices/first-taste-of-an-arm-powered-netbook-and-its-good/

Depends on the ARM, but all the processors that could be seriously considered for new laptop/netbook/t&l applications have FPUs of some sort.

Not sure exactly what sort of use you're considering; video decoding and 3d rendering are the only real FP-intensive operations in "normal" usage, and both tend to be handled more on the GPU side anyway (3d has been offloaded for years; video's more limited, but is trending up of late). Maybe you're talking scientific computing; some of them may not be so hot (might lack double- and quad-precision?) but the Cortex-A series all have NEON SIMD units, which have single- and double-precision, and should give ample performance for video work.

For the more performance-oriented ARM machines, you're looking at this sort of thing; I don't see a performance issue, and even if there was, the quad-cores should be running around 1-2W at 1GHz+ -- that leaves plenty of room for a graphics or video coprocessor and still come under the power envelope of a comparable x86 CPU.

In industry, as far as I can tell, Verilog seems to be more used in North America and VHDL in Europe, so that might affect what you care about, too.

When I worked at (UK-based processor designers) ARM, Verilog was the language of choice. I've been told VHDL is popular in academia, while Verilog is more popular in industry.

That said, the underlying concepts are pretty similar, and those are what you're teaching really, so either choice would be reasonable.

I did some more searching and I kind of realized more of what you mean. I had forgotten for a while that netbooks existed before the EeePC, except they called them ultraportables and charged 2 grand or more for them. I'm sure Intel would much rather you buy something like this than an Atom. Even this probably has a higher margin than the Atom. Initially when I saw the price of the Atom I was comparing it to desktop CPUs, but I can see how power consumption is a large factor in the price of x86 CPUs.

Personally, I'm in favor of ARM shaking up the netbook market, because I think with a well-designed RISC core they can do much better than Atom in terms of power consumption and still provide ample performance. This thing makes me drool every time I think about it... haha. Dual core, superscalar architecture with out of order execution consuming less than a watt under load... now THAT is a mobile CPU.

Except on everything not x86. The speed you currently see on desktop/server java is only accomplished by very good JustInTime compilers. Which are tweaked for x86. So everything else runs java like crap.

Have you not heard of Jazelle? It supprots just in time and ahead of time compilers for ARM and is mentioned in the wikipedia link you gave.

It provides direct execution of Java bytecode and was announced in 2000.

10 billion last year