Slashdot Mirror

Windows doesn't run on ARM.

Windows CE does.

Maybe... or maybe not. Progress is seldom linear, and tomorrow is not specially supposed to me just "more of today". It may on the contrary be very different, and even opposite to some respect (think of the automobile or computer products from 1950 to 1970 and try to extrapolate that to 2010, you get very strange results ;-)

The key to many things is scale economy. If you can offer the same service at 30% less manufacturing and storing cost by having 10x longer series, you win. By the way, this is what ensured success of the Ford T and the VW Bug at a time. The Renault/Dacia Logan seems to be a success too in Europe with its "non-nonsense" approach, as well as Netbooks have been in 2008. Future is almost never "more of the same thing". That is incidentally why the Wii was such a sucess too. See aloso this :

http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=9131098

http://www.arm.com/events/presentations/Robin's%20Semico06%20Keynote%20Speech_FINAL06Mar06.pdf

... and extrapolate that to any other movement, like batteries :-)

Look at this PDF, page 8, top left picture

It's actually from here

http://www.snopes.com/inboxer/hoaxes/computer.asp

That said, I suspect whoever wrote it was aware of the Snopes article.

I got a kick out of reading his blog. Seems like a really neat project to learn how computers work at the lowest level.

I agree with you about the choice of microcontroller, though. Atmel AVRs are very popular, and are available in significantly more powerful varieties. Check out this one; it has 16KiB of S-RAM on the CPU, so you can save yourself the 2x8KiB chips he used, which means reduced cost.

Another one to consider is the Parallax Propeller. They aren't too popular, but have impressive capabilities, ignoring the price. It's basically an ultra-low-power 8-core microcontroller. The design is... fascinating. They created it with the same philosophy as older CPUs; rather than stamping big blocks together, every transistor was charted out by hand. (well, for the most part :P ) Apparently it has no interrupt handling, which introduces some different programming philosophies as well.

And failing that... a Cortex m3. That's a powerful one. Although it uses a standard un-interesting architecture, it's also quite fast. With enough RAM you could do SNES-level stuff quite easily.

Windows CE runs on ARM. Granted, CE doesn't have the level of application support you'll find in other versions of Windows though.

Its their compiler, they are damn well allowed to do what they want - call me when AMD pour that kind of resource into having their own compiler.

ARM put money into GCC. That's far better than them trying to make their own compiler.

ARM may have put money into GCC, but... ARM also sells their own compiler - RealView Development Suite (RVDS).

As for why ARM would do both - the RVDS is a high-performance ARM compiler and ARM's code, so they'll put a lot of optimizations into it. (Ignore the ARM/GNU compatibility - it's because ARM wisely thought up of an ABI and calling convention that most people subscribe to - unlike the x86 where you can have cdecl, stdcall, fastcall, pascal, among others - there's only one real one in ARM).

But ARM also realizes that there's a competitive advantage to having GCC as well - having an easily available set of development tools can only encourage others to adopt your platform. (Which is probably how ARM catapulted from "just another CPU architecture" into more or less the top-selling processor architecture around, outselling even x86 - heck, an x86 PC probably already has a few ARM cores in it).

That said, GCC 2.9.x on ARM basically sucked as a compiler - when a speed up can be obtained by changing a test for zero (i.e., "if (variable == 0)") into the more usual form ("if (!variable)"), something's wrong. I believe GCC 3.x and 4.x are now very much improved these days because of it. (In the end, I actually managed to rewrite the code to get rid of that...).

The instruction set has an awful lot of bearing performance. The RISC ARM instruction set has only instructions that take exactly 1 cycle (last time I looked). This makes both efficiency and optimisation such as pipelining very effective. The CISC x86 instruction set has instructions that can last varying amounts of time. This makes things such as branch prediction misses expensive. To compensate for this x86 chips use a translator which turns the x86 into VLIW pseudo-RISC internally. Unfortunately this translator takes up most of the power and silicon real estate on the chip.

You can compare the instruction sets of ARM and x86. Writing assembler for the former is a dream, unlike the latter. Mhz for Mhz, ARM blows x86 away.

Phillip.

Java is compiled Just-in-time, though I don't know about smaller, obscure or embedded platforms.

On mobile phones that use ARM chips Java byte-codes can also be executed directly by the CPU if the ARM chip implementes Jazelle. These ARM chips have a "J" in their names (eg. ARM926EJ-S).

Read about it here: ARM Jazelle.

Don't know about Intel, but ARM shipped 1 billion processors last quarter, according to their Q3 results statement.

Other things that must ship in the billions: screws, nails, paper clips, thumbtacks, staples, sweets (candy), baked beans, soda, LEDs (actually almost any discrete electronic component), copier paper, post-it notes, coins, pens, pencils, bin liners ... it's too easy.

Just two details: ARM7TDMI is a mmu-less processor, so i can't run linux (although it can run uclinux). ARM9 isn't ARMv5 ARM926E is an ARMV5TEJ. ARM920T is an ARMV4. http://www.arm.com/products/CPUs/ARM920T.html and http://www.arm.com/products/CPUs/ARM926EJ-S.html

Just two details: ARM7TDMI is a mmu-less processor, so i can't run linux (although it can run uclinux). ARM9 isn't ARMv5 ARM926E is an ARMV5TEJ. ARM920T is an ARMV4. http://www.arm.com/products/CPUs/ARM920T.html and http://www.arm.com/products/CPUs/ARM926EJ-S.html

Oh ZipIt wouldja?

Having Ubuntu is going to raise the viability of ARM processors? ARM isn't quite a tiny product line.

One thing about the Transmeta buzz that I've never understood here on Slashdot is why almost no-one ever raise the ARM challenge that Transmeta faced. Transmeta wanted to be better than Intel at chips and better than ARM at low power design and their differentiation was....

Bugger all.

A massively over-hyped, post .com bubble company that had a better spin machine than a product line. Now can we all as engineers now formally apologise to ARM for thinking that Transmeta was worthy of being considered competition.

I seriously doubt they would try to enter the x86 market. Perhaps it's just this that people are mistaking it for. That's frankly a bigger market than anything x86 based.

Am I supposed to be impressed?

The new Cortex-A8 ARM processor consumes 300mW; less than a tenth that of the Atom. The Atom is marginly faster, but not much so --- the figures I've found show that a Cortex develops about 2.0 Dhrystone MIPS per MHz, vs about 2.4 for the Atom. Plus, the Cortex is a CPU core, not a discrete chip; most actual products couple it with an on-chip OMAP DSP engine, which is ideal for doing things like video encoding or decoding or OpenGL. With Atom you end up having to couple it with a dedicated GPU...

And c'mon who knows if there will be PowerPC support or not? All we know is that the current developer version requires Intel.. Hell, it's probably running (as buggy as any developer version ever is) on the PPC and they may not even have decided whether to ship it or not. They may have decided to support the PPC but will change their mind before release. They may have decided not to support it but will change their mind before release.

Smaller binaries could be provided by changing the installer. Or perhaps the binaries are smaller because Snow Leopard will only support new machines built around Thumb processors.

People should stop getting their panties all bunched up. All we know is that the current developer version requires Intel..

While the Atom certainly delivers impressive power statistics compared to our typical laptop processors, they are still far from the level of the ARM family. A recent article on Ars Technica will explain why. ARM processors are by far the most common processor on the low power frontier and the reason seems apparent; even at 1GHz they claim to reach operational power consumption around 300mW. Now, granted, it is on a RISC instruction set, but their upcoming Cortex-A9 will support multicore and starts to sound like a very interesting alternative for a notebook processor.

Could someone drop me a message as soon as those things start entering the market?

While the Atom certainly delivers impressive power statistics compared to our typical laptop processors, they are still far from the level of the ARM family. A recent article on Ars Technica will explain why. ARM processors are by far the most common processor on the low power frontier and the reason seems apparent; even at 1GHz they claim to reach operational power consumption around 300mW. Now, granted, it is on a RISC instruction set, but their upcoming Cortex-A9 will support multicore and starts to sound like a very interesting alternative for a notebook processor.

Could someone drop me a message as soon as those things start entering the market?

I hate the way RISC is embraced by many as a pretext to operate their brain in neutral.

Consider the x86 read-modify-write address mode, which few RISC chips incorporate.

Compared to the RISC load, operate, store sequence, this saves you: two instruction fetches, the unnecessary use of a named register, unnecessary read/write transfers to the permanent register file, and transferring the *same* load/store address to the memory order buffer *twice*.

Fixed width RISC instruction sets with large register files and full orthogonality typically have terrible code density. This directly reduces the efficiency of the icache, which in modern chips represents far more transistors than RMW address mode support introduces into the core.

ARM is a good study in this. What did ARM end up doing to address their code density / speed problem? They invented Thumb-2, which sacrifices half the register set to achieve a better balance in time and space.

http://www.arm.com/products/CPUs/archi-thumb2.html

Some of the original RISC ideas might have been good at the time, but times change.

Excessive orthogonality is simply wasteful. Modern compilers don't have great problems with register coloring to achieve efficient code generation. Yes, someone once had to think very hard to code this. How cruel.

Orthogonality is most beneficial to programmers writing assembly by hand, because people aren't nearly so good as compilers at remapping all the registers in a loop every time one instruction in the loop changes.

An excessively large register file can become a liability at call boundaries and context switches. The x86 addressing modes permit more aggressive use of the L1 dcache as an adjunct to the paltry register file. Otherwise, it would have fallen out of the game long ago.

In some areas, x86 is pure liability: the instruction prefix bytes, too many partial flag register updates, a terrible floating point architecture, and a museum of dead and useless 286 instructions which seemed like a bright idea at the time (I think the PHB interned at Intel that year).

In terms of power efficiency, the x86 instruction encoding and paltry register file can't be redeemed. The magic to make these problems disappear costs a lot in power.

But it's stupid to say that x86 has no advantages over traditional RISC. It has plenty, if you stop to think about it.

Intel, of course, are producers of the ARM chips. You were aware, weren't you, that Intel's X-scale processors are ARM-architecture parts? Go here to read: "Further implementations of the ARM architecture are available from our Partners such as the Intel® XScale(TM) microarchitecture"

I'm less than impressed that you've discovered what an embedded controller is. Every computer sold comes equipped with a mouse. The mouse often has a Xilog or Microchip PIC processor in it. Yay! Yay! Those processors just plain beat Intel out. *shrug*

Those same computers feature motherboards that have diodes on them! Often they are 1N4148 diodes made by Motorola or Fairchild! There are MANY of said diodes on the motherboards! So Intel looses out again! To Fairchild or Motorola, or Lite-On, etc....

Look closer at the CPU (arm11) included in the iPhone.

It includes hardware Jazelle DBX extensions:

ARM Jazelle DBX (Direct Bytecode eXecution) technology for direct bytecode execution of JavaTM delivers an unparalleled combination of Java performance and the world's leading 32-bit embedded RISC architecture - giving platform developers the freedom to run Java applications alongside established OS, middleware and application code on a single processor.

Performance isn't really an issue..

This is even sillier than your reply indicates. By the same logic we could conclude by the failure of the Pentium IV that x86 was doomed. Then Intel came up with Core Duo to show what should have been achieved in the first place (and saved the world many gigawatt years of unnecessary power generation in the meanwhile).

Intel botched their first hack at Itanium. They weren't willing to pony up another couple of billion to get it right the second time. By then their performance war against AMD had set the bar so high on x86 performance, their "pull the rug and own the world" marketing strategy was no longer viable (not even within the Intel boardroom ego chamber).

Intel killed Itanium in the false belief they could go cold turkey on out-of-order (OoO) execution. It's true that OoO scales badly, both in terms of complexity and power consumption, as you broaden the execution pathways. Intel's solution: exterminate OoO. Right from the beginning I thought this was a daft and deadly embrace of determinism.

The sensible solution: constrain the design to a reasonable fixed upper bound on OoO depth. They could have done this by having bundles express groups of *dependent* operations. The OoO ceiling would then be a single bundle unit.

I would have set up bundles to encode at least five operations under ideal conditions. If the operations are dependent, you need to specify fewer total registers (and in fact, commit fewer total registers back to the register file, which can only be an advantage). I'm sure this would complicate validation and maybe there are some other gotchas I haven't consider, but it always seemed obvious to me that this would work better relative to the algorithms I worked with (which have sources of non-determinism you can't eliminate).

You would also add a rule concerning bundle independence. Say the architecture was designed to scale up to four bundles wide, with a peak five operations per bundle. Each of the bundles within the bundle group would be required to be fully independent (shared inputs would be allowed, nothing more).

You'd probably set up four bundle execution pipelines (each internally with an OoO dispatch queue). There would have to be rules on the maximum rate of forwarding operands from one bundle pipeline to another. Some portions of the register file would be somewhat "bound" to particular bundle pipelines. You'd have to sacrifice register file orthogonality. But it's a false orthogonality to begin with: a recently computed result can only be forwarded so far in a fixed time increment, and you can't afford to provision worst-case forwarding pathways from everywhere to everywhere on a fat uarch.

The Itanium design team was seduced by determinism and orthogonality. Partly this was because x86 instruction encoding is a horror show. With a more sensible ISA, you could have 90% of the advantage of x86 non-orthogonality (code density improvements) at 10% of the complexity of an x86 instruction decoder. I've been saying this for years. Finally, ARM came up with Thumb-2 to demonstrate my point: the best design is a carefully constrained and balanced non-orthogonality.

http://www.arm.com/products/CPUs/archi-thumb2.html

Why didn't ARM do this long ago? The 16/32 decoding mode is maybe 5% as difficult as x86 decoding, and look at the huge advantage it gives you in balanced time/space.

For an Itanium bundle, I would set up the rules for a finite fan out / fan in for every instruction field. In my version of things, a 128 bit bundle would be able (under ideal circumstances) to encode five operations. A bundle decoder must break the bundle into up to five independent instructions.

In my approach, you might have a rule that any bit-field within the bundle can have at most four distinct possible destinations (within the five exploded instructions). Each field within the exploded instructions can obtain bits from (one of) at most four different

The key point here is that you can get the best performance/watt around from ARM chips. AMD's Geode series has a 1.5-watt Geode LX900 (600MHz) and a 0.9-watt Geode LX800 (500MHz) (link). Note: AMD's site rates these at higher power (2.6W and 1.8W respectively) here.

ARM chips have always been more efficient than X86 chips and always will be due to CPU architecture and the way that every instruction is encoded. Each ARM opcode has got a 4-bit conditional field that governs whether that opcode is executed or not. In an IC, you've got quiescent power (always there from the moment you switch on) and dynamic power. Dynamic power comes from switching transistors on and off. If an instruction isn't executed, there is less switching and less power consumption.

With a "save the planet through electronic design" attitude, I'd love to see a large proportion of X86 desktops replaced with ARM-based machines. Especially when you consider that saving even 1 Watt per PC scales to many thousands of megawatts , especially when you see how many PCs are in use now.

As ARM CPU speeds increase beyond the point where you can have a modern, complex OS and good office software running at a comfortable speed to the user, isn't that a goal worth aiming for? The practical sides of that dream are daunting. I'd be naive to think that the world will port its software just because it's a good idea to save electricity where possible. A fresh start would be bigger than Haiku in it's ambition. Is it worth it? I'd like to think so. What's 10 years of OS and application development that could make a good dent in global power consumption that would last forever?

"a custom Java Bytecode interpreter that is highly specialized for the CPU" - Kind of hard to do that in an emulator on a PC. What CPU is this optimized for? (Guessing ARM... Still, to evaluate performance you need real hardware.)

The "custom Java Bytecode interpreter" probably means a Jazelle JVM or variant. These are specialized CPU/JVM combinations that execute Java bytecode in hardware. This technology is used on many of the Java phones already in the market.

This is not 1990 anymore. Embedded systems are not underpowered. Embedded systems today are quite literally THOUSANDS of times more powerful than the supercomputers that you and I grew up with. Here's one example of an RFID reader. 64MB of RAM. Windows Mobile 2003. Here's another one with an XScale processor. XSCALE. DO YOU HAVE ANY IDEA HOW POWERFUL AN XSCALE PROCESSOR IS? When I first was working with garbage collection and automatic bounds checking, I dreamed for something even a fraction as powerful as an XScale processor.

Granted, an RFID reader is not a desktop computer. But I guarantee the RFID readers these people are using have enough power to read an RFID, play a copy of Doom in the background, and have plenty to spare.

Garbage collection and automatic bounds checking were feasible when I used them on a 16MHz processor with 1MB of RAM. I'm going to go out on a limb and say they're STILL feasible on a 266MHz processor with 64MB of RAM.

You can't run a JVM on this thing, and even if you wanted to, it would be a bad idea.

I suspect that "this thing", like most embedded systems, supports the Jazelle instructions specifically because, actually, not only is running a JVM on an embedded system a good idea, but it's very common.

Hint: most cell phones run a JVM. Hint: most cell phones run their software almost exclusively on a JVM. Hint: an RFID reader is much more powerful than a cell phone. This is not 1990 anymore. "Embedded" does not mean underpowered. "Embedded" means the processing power is only slightly absurd.

This is not 1990 anymore. Embedded systems are not underpowered. Embedded systems today are quite literally THOUSANDS of times more powerful than the supercomputers that you and I grew up with. Here's one example of an RFID reader. 64MB of RAM. Windows Mobile 2003. Here's another one with an XScale processor. XSCALE. DO YOU HAVE ANY IDEA HOW POWERFUL AN XSCALE PROCESSOR IS? When I first was working with garbage collection and automatic bounds checking, I dreamed for something even a fraction as powerful as an XScale processor.

Granted, an RFID reader is not a desktop computer. But I guarantee the RFID readers these people are using have enough power to read an RFID, play a copy of Doom in the background, and have plenty to spare.

Garbage collection and automatic bounds checking were feasible when I used them on a 16MHz processor with 1MB of RAM. I'm going to go out on a limb and say they're STILL feasible on a 266MHz processor with 64MB of RAM.

You can't run a JVM on this thing, and even if you wanted to, it would be a bad idea.

I suspect that "this thing", like most embedded systems, supports the Jazelle instructions specifically because, actually, not only is running a JVM on an embedded system a good idea, but it's very common.

Hint: most cell phones run a JVM. Hint: most cell phones run their software almost exclusively on a JVM. Hint: an RFID reader is much more powerful than a cell phone. This is not 1990 anymore. "Embedded" does not mean underpowered. "Embedded" means the processing power is only slightly absurd.

The Intel transition introduced 32-bit hardware into the mix again, for a while before the Core 2 Duo shipped, so Apple actually has both 32-bit and 64-bit versions of both PowerPC and Intel Core hardware in the installed customer base. The really nifty thing is that for applications that work on large amounts of data, even the older 64-bit PowerPC hardware will get a serious performance boost with Leopard for a mere $129. The newest member of that hardware pool will be two years old by the time Leopard ships, but some of those machines are still pretty nice. Their owners will be happy that Leopard treats them as full 64-bit citizens.

What Apple is accomplishing with seamless support for those four machine architectures from one build of Mac OS X is quite impressive. It also preserves Apple's ability to adopt new CPU architectures as needed. Suppose Apple came up with an idea for an appliance for which the Cell processor would be an ideal choice? Apple could certainly ship such a device without breaking a sweat.

Furthermore, suppose Apple wanted to use OS X as the operating system on a new bit of hardware that required, say, a low power CPU like the ARM that happened to be 32-bit, say a cell pone or something. If the OS is designed to cleanly handle both 32-bit and 64-bit architectures, then the same version of the OS could be used across all five architectures.

What about dumb cellphones, I can garuantee that almost none of those would use a 32 bit chip, the almost is because invariably some products end up over-engineered.

I'm not sure that is true.

http://www.arm.com/markets/mobile_solutions/armpp/ 835.html

ARM7TDMI is a tiny macrocell, even on something like a Nokia 5110 it doesn't take up too much space on the ASIC. Thumb code is pretty dense, and an Arm cell has good mips/watt.

What about dumb cellphones, I can garuantee that almost none of those would use a 32 bit chip, the almost is because invariably some products end up over-engineered.

I'm not sure that is true.

http://www.arm.com/markets/mobile_solutions/armpp/ 835.html

ARM7TDMI is a tiny macrocell, even on something like a Nokia 5110 it doesn't take up too much space on the ASIC. Thumb code is pretty dense, and an Arm cell has good mips/watt.

I hope the software gets the community support it deserves.

http://www.arm.com/products/esd/jazelle_architectu re.html
What's the strategy for if other vendors begin to offer hardware support?

Last time I checked support was considered an encumberence by one or other party and removed from Hotspot.

It would be nice to test the possibilities of the hardware in some open source NAS device conversions (if possible).

Actually ARM has some new cars with FPUs and DSPs now http://www.arm.com/products/CPUs/ARM1020E.html. One has to wonder just how many ARM cores you could put on a single die at 90nm? Just think about an 8 or 16 core system with are good NVidia or ATI graphics chip running some flavor of Unix. You could use USB to connect drives and printers to it as well. Of course the ideal system would have sixty four sixty four bit cores and 64 gigs of memory :)
Back to reality that is one thing I do wonder about. Why didn't the OLPC project use an ARM or MIPs cpu instead of an X86. Both are better low power cpus than the X86.

That's no lightweight system, and it comes with a serious set of development tools who's big brother version is used in the real world.

Looks like they offer an educational version too:

http://www.arm.com/markets/embedded_solutions/armp p/14149.html

I don't think there's any true RISC chips out there any more....

Most people are familiar with the 8-bit Atmel AVR microcontrollers, similar to the Microchip 8-bit PIC microcontollers. The AVR32 is a 32-bit microcontoller. I believe it was developed by Atmel to be a easy to mirgrate to target to compete with Freescale's 32-bit offerings, and various manufacturers' low cost 32-bit ARM processors.

Up until now, I'd assumed that most corporate developers were using Fedora, simply because of its similarity to Red Hat Enterprise and for its maturity. However, I'm curious to know, for those fortunate enough to develop for embedded Linux, what distribution do you expect to be supported for a build environment?

When I worked for ARM (quite recently) they could work with most platforms, since all the heavy lifting was submitted to a cluster of machines and if you wanted a specific OS/distro/version you could specify it and the job would go to that machine (e.g. bsub -I -r "solaris" foo would queue command 'foo' to run on a solaris box).

However, the machine they had the most of was RHE3 (Red Hat Enterprise edition 3), so that's probably a good one to target.

Other good ideas for your tools include:
* Batch/command-line mode, so your tool can be called by a script.
* Parallelisability, if your jobs take more than ~10 minutes on a high-end machine. It's easy to get 4 * 3GHz cores, but hard to get 1 * 12GHz core. Xilinx place and route, this means YOU.

an 8-bit Java bytecode interpreter... But ARM won't give docs to the last out, because Sun won't let them do that

http://www.arm.com/products/esd/jazelle_architectu re.html

Put the processor in "Java bytecode" state, and it executes 8-bit Java bytecode directly. It's a third instruction set for the core, in addition to the ARM and Thumb instruction sets.

ARM doesn't document the Java bytecode. They refer you to Sun, which seems appropriate since that spec is proprietary to Sun.

Pick a processor core with "J" for "Jazelle" in the name, and read the Architecture Reference Manual.

"You can switch the operating state of the ARM7EJ-S core between:
        - { Thumb mode deleted }
        - ARM state and Jazelle state using the BXJ instruction"

http://www.arm.com/pdfs/DDI0214B_7ejs_r1_trm.pdf

"BXJ" stands for Branch and Exchange to Jazelle. It works like the other ARM branch instructions. If you have some bytecode at address X, then load X into r0 and "bxj r0". The processor starts executing the bytecode at that address.

What else do you need to know?

(Yes, the manual does go on to discuss exceptions that take you back out of Jazelle mode, what happens when the processor hits emulated/extended byte codes, and so on. You want to implement JIT to native ARM code, you can do that, too -- but that's your software problem.)

No big conspiracies here, it seems. Took me three searches on the ARM web site to find the info.

an 8-bit Java bytecode interpreter... But ARM won't give docs to the last out, because Sun won't let them do that

http://www.arm.com/products/esd/jazelle_architectu re.html

Put the processor in "Java bytecode" state, and it executes 8-bit Java bytecode directly. It's a third instruction set for the core, in addition to the ARM and Thumb instruction sets.

ARM doesn't document the Java bytecode. They refer you to Sun, which seems appropriate since that spec is proprietary to Sun.

Pick a processor core with "J" for "Jazelle" in the name, and read the Architecture Reference Manual.

"You can switch the operating state of the ARM7EJ-S core between:
        - { Thumb mode deleted }
        - ARM state and Jazelle state using the BXJ instruction"

http://www.arm.com/pdfs/DDI0214B_7ejs_r1_trm.pdf

"BXJ" stands for Branch and Exchange to Jazelle. It works like the other ARM branch instructions. If you have some bytecode at address X, then load X into r0 and "bxj r0". The processor starts executing the bytecode at that address.

What else do you need to know?

(Yes, the manual does go on to discuss exceptions that take you back out of Jazelle mode, what happens when the processor hits emulated/extended byte codes, and so on. You want to implement JIT to native ARM code, you can do that, too -- but that's your software problem.)

No big conspiracies here, it seems. Took me three searches on the ARM web site to find the info.

With ARM's new Cortex-A8 processor, why haven't I been seeing more micro-desktops and power efficient laptops and whatever based around this technology?

I see your MIPS and raise you an ARM

Are any ARM implementations superscalar? XScale sure isn't.

There are the JStamp http://jstamp.systronix.com/index.htm controllers or some of the ARM http://www.arm.com/products/CPUs/ARM7EJSCore.html controllers. These both run native Java Byte Code.

I believe you are referring to this from ARM. Nice tech, and you make a good point.

MIPS's power consumption is really nowhere near as good as ARM's. Plus ARM is bringing out the desktop-level cortex next year, and AMD really has nothing comparable waiting in the wings.

http://www.arm.com/products/CPUs/ARM996HS.html

and, since I'm posting,

        The ARM996HSTM processor is the industry's first
        licensable clockless processor and ...

"licensable"

ARM already dominates its own market - embedded processors.

For example, I already have an wireless AP, a cellphone, and an MP3 player that is known to use an ARM procesor. Adding up many more 'unknown' gadgets I have, I'd bet that I myself already have a dozen of these.

Go to ARM's homepage, and find a short list of gadgets that use ARM.
http://www.arm.com/

According to http://www.arm.com/products/CPUs/ARM996HS.html, 50-70 MHz. Plenty fast for embedded applications.

Intel LaGrande aims to 'protect' every IO path inside your computer, but this is still a work in progress - first TPM on every computer, the rest will be added piece by piece until the puzzle is complete.

Gigabit ethernet controller with built-in TPM (http://www.broadcom.com/press/release.php?id=7005 09/):

"Broadcom® Controllers Integrate TPM 1.2, Enabling OEMs to Offer Hardware-Based Security as a Standard Feature on All PCs
Platforms With TPM 1.2 Hardware Will Be Ready for Enhanced Security Functionality in the Next Microsoft OS (Code Name Longhorn) Expected to Ship in 2006 Breaking the Adoption Cost Barrier, Broadcom Has Integrated TPM 1.2 Functionality in Its Latest NetXtreme® Gigabit Ethernet Controller, Which Will Be Demonstrated This Week at the Windows Hardware Engineering Conference 2005"

You might already have it and not know it (the above link is almost one year old).

Your PDA/Mobile device/... will be next (http://www.arm.com/news/8308.html/):

"NDS Announces Availability Of Mobile DRM Application Based On ARM TrustZone Technology
NDS implements the first OMAv2 DRM solution leveraging the ARM TrustZone Software API which together delivers interoperable security and reduced porting costs"

Because I'm a minor ARM fanatic, they list the ARM7500 system-chip as a milestone in 1994 and ARM7500FE in 1996. Perhaps not putting the system RAM on the chip excludes it from being a true SoC in IBM's terms. Unless IBM wish us to believe that they invented the universe...