Could you introduce yourself?
Jon Stokes: I'm a co-founder of Ars Technica, and a Senior Editor at the site. I typically cover microprocessors and graphics hardware, but over years I've covered a pretty broad array of additional topics, including intellectual property, national security, privacy and civil liberties, outsourcing and the H1B visa program, and electronic voting. I have an undergraduate degree in computer engineering from LSU, graduate two degrees in the humanities from Harvard Divinity School, and I'm currently working on a Ph.D. at the University of Chicago. I am the author of Inside the Machine.
I found a list of bugs inside Intel Core Duo/Solo that was released just 20 days after the official release of these CPUs. It's pretty shocking. Is it something common? How do CPUs manufacturers react? With new revisions? Letting the software guys find a workaround?
Jon Stokes: Generally speaking, many of the major errata are fixed with new steppings of the processor. Other errata can be worked around using BIOS and OS tweaks.
There were quite a few errata with the Core Duo/Solo line, and maybe even a higher number than usual for which no fix is planned. However, I think Intel's reasoning behind not planning fixes for these is pretty clear in this particular case.
Specifically, Core Duo/Solo (aka "Yonah") is a transitional design between the Pentium M and the more advanced Core 2 Duo/Solo (aka "Conroe"). There really wasn't much of a time gap between when Yonah was released in January of 2006 and when Conroe was released in July of that same year. So Yonah was obsolete pretty quickly. This being the case, there was no reason for Intel to put a lot of effort into updating this transitional microarchitecture.
Overall, I think too much is typically made of these errata in some forums. As I said above, the important bugs are fixable with new steppings, BIOS tweaks, and OS updates.
Browsing CPUs specs and datasheets I see a lot of reserved stuff. They are probably used for debugging the hardware during the development cycle, but I'm wondering what they could be used for once these CPUs hit the market. The paranoid android inside me could argue that maybe it's just security through obscurity, and that some combinations of these reserved bits could be used to 0wn the system. Or maybe the always cool story about NSA conspiracy, so there could be a backdoor somewhere... What can you say about the hardware development process and the use of reserved bits?
Jon Stokes: My understanding of reserved bits is that they're often intended not for secret features, but so that the architects can add new features to the ISA at some future point. In other words, a reserved bit gives you a "place" to insert a new option or capability, without breaking legacy software.
If I recall correctly, AMD made use of at least one reserved bit in the x86 instruction format when they created their 64-bit ISA, x86-64.