Does anyone below the age of 18 go through these scanners?

They should charge them with manufacturing child pornography.

You could send them an invoice for the use of your work.

No 64 bit architecture now... I'll bet anyone they won't have any 64 bit products by 2011.

I guess you could stick a Coretex A9 in a box and call it a server, just like you can stick an Atom in a box and call it a server. At least the atom would support large address spaces.

If they've reduced their ideas to practice, then hooray for them. More ideas that must be licensed on Fair, Reasonable, and Non-Discriminatory grounds.

If they haven't, then their patents may not be valid.

The GSM side of 3G standards has many different upgrades to the basic WCDMA air interface:

• HSDPA: 7.2 MBit/sec downlink
• HSUPA: 5MBit/sec uplink
• HSPA+: 21 MBit/sec - 48 MBit/sec downlink

The most interesting thing is that HSPA+ is getting close to the same efficiency (bits/Hz) as LTE; 21MBit/sec in a 5MHz channel vs. 100MBit/sec in a 20MHz channel.

Haven't disk manufacturers been doing this forever, using faster memories to cache disk? I guess the difference now is that the memory is slower than DRAM and non-volatile so it isn't lost in the event of power failure? Or maybe you can get more flash storage at a low price point?

Isn't Google an AP licensee?

So even if Google doesn't index, say, the Wall Street Journal, can't Google still get the same news contributions form the AP newswire?

Or is there something special about AP license terms or something?

C. S. Lewis wrote a series of books about this exact premise. In his stories, there is indeed life on other planets, but the life there is not fallen as it is on Earth. The first one is entitled "Out of the Silent Planet," and the collection is known as the "Space Trilogy".

Look, I'm not saying x86 isn't crazy. It doesn't have just shifting addressing modes, but ones with multiplies. That really forces you to have (A) an architecture that uses multicycle instructions, (B) a really horrid pipeline, or (C) splitting up instructions into multiple components that flow through a normal pipeline.

Having shifts in the address calculation is fine for ARM7 where you're trying to squeeze every possible functionality out of a tiny number of gates, and don't really care about performance. But for even a reasonably high-performance design, you need to have a consistent pipeline.

Probably the most important pipeline is the Decode->RegRead->AddressFormation->Dcache->Writeback pipeline. The latency of this pipeline is critical for performance. ARM has some advantages here: uniform (or, somewhat less so, semi-uniform, a la Thumb2) is easier to decode than variable-length at the byte level x86. Most architectures have an adder in the AddressFormation part (though notably not ia64). If you add two registers (which you can't in MIPS) you probably want to be able to shift by the access size because you're doing something like indexing into an array. So a small left shifter before the adder isn't uncommon, and it's usually about a 4:1 mux in terms of delay.

But ARM allows you to do full rotations in front of the adder. This means you need more levels of logic in front of the address calculation adder, which hurts your memory latency. You can make it a multicycle instruction or split it up into multiple instructions (and many implementations do), but that of course adds significant complexity.

The page table formats are kind of kooky. Most 32 bit architectures choose 4K pages as the minimal page size. 4K L1 translation and 4K L2 translation translates all 20 bits you need. The page tables are a multiple of the page size, which is handy. It's so clean, it's pretty obviously the "right" thing to do.

ARM has a 16KB l1 translation, because they used to support 1KB pages, but no longer do. They have strange attributes that move around the format, which makes it more difficult to manipulate the page table entries. They also have no free bits, which makes it a pain in Linux to keep information like how new or clean the page is.

I will say that the page tables are getting cleaner as they deprecate things like 1KB pages, but they're still pretty painful compared with other architectures.

The Alpha Architecture Handbook is a good read, and Alpha is my very favorite RISC. Not that it's magical, either, but it's a lot cleaner than ARM. And it's less than half the length of the ARM Architecture Reference Manual (ARM ARM, which I must admit is a clever acronym).

Let me illustrate.

ARM has ARM mode, Thumb Mode, Jazelle Mode, and ThumbEE mode. FOUR instruction sets. Multiple different floating point unit specs that are incompatible with each other. Crazy page table formats. The architecture spec is over 2000 pages long, for pete's sake!

ARM has a more uniform encoding, but actually has a large number of instructions, and does crazy things like put a rotating shifter in the load address path. Not good from a modern pipeline perspective. You can get around it by breaking up the operation, but then you're getting into complex instruction decode like x86.

I'm not saying ARM is bad. I'm just saying they have no magic. You're right, Intel doesn't either (though they do have manufacturing and an army of engineers to do hand-layout). Nor does MIPS or PPC. But MIPS does make energy efficient cores, roughly as good as ARM. They haven't been as popular as ARM, but they're around.

And I'm certainly not saying x86 is great -- it's certainly not. I don't think it's quite as bad as people make it out to be...

Look, I wish the architecture made a difference. For one, we'd all probably be using Alpha. That was a great, elegant, beautiful processor architecture. For another, I'd have much better job prospects. But it doesn't matter that much. Scalar architectures are scalar architectures. Instruction set makes some difference, but not very much.

Yes, ARM marketing (notoriously overoptimistic) says they will have a 2GHz A9 in 28nm, relatively high performance process.

But A9, in terms of efficiency, is not substantially better than where Atom will be. That shouldn't be surprising. They're both scalar architectures. They both have a little less than 15 useful registers. They both have similarly deep pipelines. They both rely on branch prediction for performance. Neither company has magic, it's not surprising that they're similar on the curve of performance / efficiency.

Put another way, your instruction encoding doesn't really buy you all that much.

Now ARM has some lower-end cores (ARM9, ARM11, Sparrow/CoretexA5) that are much more energy efficient than Atom. But they're also much lower performance.

But this is how ARM's marketing plays it out: we have super-efficient cores (ARM9)! We have higher-performance cores (Theoretically, A9)! You think that ARM cores are somehow both high performance and much more efficient than Atom will be in the same technology... but this will probably turn out to be false.

Put another way... are MIPS or PowerPC cores dramatically more efficient than x86 at similar performance levels? No. They have most of the same architecture benefits that ARM does... more, in many ways, because they have about double the number of useful registers. But they're on basically the same efficiency/performance curve as everyone else.

You could probably do an x86 implementation that was similar to ARM11/A5... no floating point, no SSE, just the basic 386 instruction set. Give it a short pipeline and turn down the frequency, and it will probably compete relatively well on energy efficiency with those low-end ARMs.

The thing I DON'T understand... why does ARM marketing get an article on slashdot every week or so?

VLIW will be back soon enough

Sooner than you know.

I'm continually unimpressed with ARM implementations.

They claim that they are low power and high performance, but at the end of the day, on real benchmarks, they always disappoint.

And it's not surprising. It's a serial architecture with only 15 registers. That's the same as x86-64. x86 decode isn't trivial, but Intel has gotten good at it. And ARM isn't without its instruction set issues; the encoding isn't incredibly straightforward as they've gone back and crammed things in like Thumb2.

So the architectures are roughly a draw. Maybe ARM has a slight advantage theoretically in slightly smaller code size, and Intel likely has an advantage in practice that there is a bigger ecosystem.

So then it all comes down to implementation and process. Both of which Intel does very well. Atom is a full-custom, well floorplanned, very nice chip. It was their first try as a "low power" chip, and it performs quite well for the energy on real-world things you need to do. ARM, which traditionally has sold soft macros, hopes to compete? For those of you software folks, "full custom" == hand-optimized, "soft macro" == source code. Sometimes the compiler can do a decent job, but Intel does fully custom designs for a reason.

I think the main thing ARM has going for it is hype. TrustZone(TM) is the most highly-marketed physical address bit I've ever seen. They lucked into being the default control processor at the low end, and have made a decent business out of selling soft cores to folks needing small amounts of processing power.

But they have no special magic. They have a ho-hum architecture, certainly inferior to something like Alpha. They have a set of simple, low-performance designs that get decent energy efficiency. And they have a great marketing engine and speak loudly.

The real reason you might see netbooks with ARM cores is that the manufacturers are just reusing smartphone chips, or have some other special SOC they want to reuse. You can license an ARM and put around it all kinds of interfaces and accelerators. But now you can get an Atom core from TSMC, too, so maybe the advantage is waning....

Why don't you see phones that only support the 3G protocols?

Because they're not ubiquitous. You will end up somewhere where coverage isn't so great for your new protocol. If you can handoff to an older protocol, you will keep your connection. So this is why even a few years ago you could get Verizon phones that still supported AMPS, why every phone that supports EV-DO also supports 1X (and older standards), and why every phone with WCDMA/HSDPA/HSUPA/etc still supports plain old GSM/GPRS/EDGE.

It's also why it doesn't make a lot of sense to have a WiMAX only phone. You need at least WiMAX+GSM, or WiMAX+CDMA1X. You need to be able to hand off to the older interfaces. And probably you want to support everything... WiMAX when it's available, HSDPA or WCDMA when that's available but WiMAX isn't, or GSM/GPRS/EDGE when that's all that's available.

Or maybe you never leave downtown Atlanta. Then maybe WiMAX-only would be fine, assuming you trust the reliability of the relatively new network.