Atom, the little CPU that can...err... could.

Lately, the Atom core has been making some really big waves around the computer market. Some are saying that it is the future, some that it's a really nice complement and almost everyone is forgetting the old "Intel wants the iPhone" stuff.
The Atom is becoming such a big success that Intel is getting afraid of it, castrating it in full force, wherever it can.

Intel is afraid that the Atom will soon canibalize most of the rest of their market, eating all the way through the lower lines of the Core 2 and leaving nothing were the Celeron stands today, driving the profits down in the same way.
That is the most apparent explanation for what they've been doing to the netbook versions of the CPU and to the desktop platforms.

The Desktop

In the desktop space they have even released a very appealing 330 version which, with it's dual cores and four threads, is able to more than easily run HD 1080p video content, making it perfect for small HTPCs... if not for the awful 945G - which doesn't even have a DVI or HDMI output. This pairing is so deliberate that you, as a manufacturer, can't add more than one DIMM slot to your motherboard design. Same goes for PCI-Express, which the 945 has. No go.
God rid if you give people a chance to built a low-end gaming rig with one of these; especially now that you have PhysX to help it. Good luck gaming on a PCI card, if you can find one.
So no PCI-Express, no more than one DIMM.

The netbooks

The portable, netbook, variations also suffer: you can't find one Atom CPU for netbooks(that's the Z and N series) that has x86-64 support and most also don't have support for hardware virtualization technologies.
The Z models with a clock greater than 1100MHz do have hardware virtualization (the lesser models probably won't ever need it) but the lack of x86-64, when it's already embedded in the die of all Atom processors, is appalling.

While most netbook users probably won't ever need 64bit support, with the apps moving to the web, you might find yourself with a yet capable CPU, in a processing power sense, without the feature capability that would allow it to run up-to-date software. Face it, software is slowing down, cloud computing is upon us, and if profit is to keep going to Intel's pocket, they must do something to keep selling new stuff now and then. Removing x86-64 is a way.
The Yonah cores experienced a similar situation with the lack of PAE but the silicon itself didn't have PAE embedded, it was a bad design decision, not a marketing one.

A dual-core Atom would be perfect to replace Pentium Dual-core laptops and even some ultra low-voltage Core 2s, since the TDP(8W) is similar and most of them run in the 1GHz range. Intel could easily bin dual-core Atom's at 1866MHz(Z540's clock), stick two of them together(2.4W times two), have them priced in the $200 range and still sell them like hot cakes for classy netbooks, ultraportables and on, and on. The current top Core 2 Duo ULV clocks at 1.4GHz and has a TDP of 10W, it costs $286 and takes 82mm^2.
The Atom 330? Fifty-two. Or cheap in semiconductor lingo. Can you say Macbook Air?

Some business decisions are incomprehensible to me and this is one of them. The CPU is smaller, cheaper to manufacture and could be more profitable than current models.
If nothing changes, soon, at the blue camp, we'll have another "Yonah/Pentium M on the Desktop era" - rogue, "underground" and expensive - just this time some lawsuits may actually be involved, judging from the fierceness of the grasp that Intel currently has on the Atom.

Intel's Core i7 TLB bug clarification

Some people around the web have been posting some FUD about the existence of a TLB bug in Intel's new Nehalem, Core i7, processor, most notably, FudZilla. AFAIK, this matter is being blown way out of proportion.

Fudzilla's Fuad Abazovic refers to AAJ1, in the chapter of specification clarifications, which states:

In rare instances, improper TLB invalidation may result in unpredictable system
behavior, such as system hangs or incorrect data. Developers of operating systems
should take this documentation into account when designing TLB invalidation
algorithms. For the processors affected, Intel has provided a recommended update to
system and BIOS vendors to incorporate into their BIOS to resolve this issue.

So, the developers of operating systems and BIOS, should take the updated documentation into account, if so, nothing goes wrong. This documentation referred is the Intel® 64 and IA-32 Architectures Software Developer's Manual,Volume 3A: System Programming Guide, which will be updated soon, if it hasn't already.

As for the TLB invalidation process, it should occur if:

As noted in Section 3 and Section 4, the processor may create entries in the TLBs and the paging-structure caches when linear addresses are being translated and may retain these entries even after the paging structures used to create them have been modified. To ensure that address translation uses the modified paging structures, software should take action to invalidate any cached entries that may contain information that has since been modified.

More information is available in this Intel document. To put it bluntly, "Nehalem" has a slightly modified paging structure, which I won't go into much detail about, that needs to be taken into account when software needs to perform a TLB or Paging-Structure cache invalidation, a fairly common procedure. A TLB invalidation may occur if software, like the operating systems, performs a context switch, or a task change, which replaces the process virtual address space with another, entries "cached" inside the TLB will then be defunct and subject to removal.
If, and only if, the invalidation algorithm doesn't take "Nehalem" architectural changes into account, will then, "In rare instances", the system suffer "unpredictable behavior" or a crash. Hence, this is not a bug. Don't worry your Core i7 will be safe.

On another note, a real TLB bug does exist, errata AAJ42, which you can see states:

Incorrect TLB Translation May Occur After Exit From C6
Under certain conditions when C6 and two logical processors on the same core are
enabled on a processor, an instruction fetch occurring after a logical processor exits
from C6 may incorrectly use the translation lookaside buffer (TLB) address mapping
belonging to the other logical processor in the processor core.

This isn't of much a trouble, since it only occurs when the processor has entered the C6 sleep state, something very uncommon in desktops and even in laptops, when most don't go further than the C3 or C4 state, some staying as high as C2(for wakeup delay reasons). The C6 state was introduced with Intel's "Penryn" core and, as far as I'm aware, it's not a requirement for Suspend-To-Ram, or S3, so it goes pretty much unused in everyday life.

Neither of these two problems pose any danger, not performance or feature wise, like the TLB bug in AMD's Barcelona(Phenom) B2 steeping posed. I leave the rest of this paragraph open for discussion but, if I'm not mistaken, the fix for this bug required disabling at least one level of the TLB, probably related to the L3 cache, hence bringing some very significant performance drops. This is nowhere near close of what either of these two "bugs" pose.

Intel's Core i7 is fast, fast, very fast and expensive. If you have the funds go ahead, it's one hell of a CPU, let no FUD about one or two bugs which are completely avoidable at none or little cost scare you from having the greatest desktop CPU currently available. This isn't a Barcelona B2 scenario.

Temporarily back to blogger.com

As the work on the new site (slowly) continues, I've decided to start posting somethings on blogger also, since the site has been up well, recently.

As I said before, this is a "Duke Nukem Forever thing", so don't wait on it :)


Best regards to all readers,

Tiago Marques