The Perfect Instruction Set

The x86 architecture is ageing, but rather than looking for re-invention, it only saw incremental extensions (especially for operating system instructions and SIMD) over the last decade or so. Before getting to the i7 core, we saw a long series of evolutions—not revolutions. It all started with the 8086 (and its somewhat weaker sibling, the 8088), which was first conceived as an evolutionary extension to the 8085, which was itself binary compatible with the 8080. The Intel 8080’s lineage brings us to the 8008, a 8 bits of data, 14 bits of address micro-processor. Fortunately, the 8008 isn’t a double 4004. The successors of the 8086 include (but the list surely isn’t exhaustive) the 80186, the 80286, the 80386, first in the series to include decent memory protection for multitasking, then the long series of 486, various models of Pentium, Core 2 and i7.

So, just like you can trace the human lineage to apes, then to monkeys, and eventually to rodent-like mammals, the x86 has a long history and is still far from being perfect, and its basic weakness, in my opinion, is that it still use the 1974 8080 accumulator-based instruction set architecture. And despite a number of very smart architectural improvements (out of order execution, branch prediction, SIMD), it still suffers from the same problems the 8085 did: the instruction set is not orthogonal, it contains many obsolete complex instructions that aren’t used all that much anymore (such as the BCD helpers), and that everything has to be backwards compatible, meaning that every new generation still is more of the same, only (mostly) faster.

But what would be the perfect instruction set? In [1], the typical instruction set is composed of seven facets (to which I add an eighth):

Lost+Found: Wisdom Teeth by Don Hertzfeldt

Also by Hertzfeldt : Rejected.

Suggested Reading: Find the Bug: A Book of Incorrect Programs

Adam Barr — Find the Bug: A Book of Incorrect Programs — Addison-Wesley, 2010, 306p. ISBN 0-321-22391-8

(Buy at Amazon.com)

This short book (306 p, but a quick read) asks us to debug 50 short programs written in 5 different languages: C, Python, Java, Perl, and x86 assembly. The book offers quite verisimilar code snippets, each of which containing exactly one bug; forfeiting the results. Barr proposes a taxonomy of bugs, from the logical bug to the off by one, and we must debug the programs with him.

C++ Logging

It seems that logging is something we do in about every program we write. Logging complements the standard output with richer messages and detailed information. And each time it seems like we’re asking ourselves how to do that exactly.

Of course, there are already existing logging frameworks out there, but I was wondering how much work it implied. I wanted something that would integrate seamlessly to the existing C++ streams: it had to behave exactly as a classical ostream from the programmer’s point of view, but had to insert timestamps and manage message priorities. The simplest way to do so is probably to have a class that inherits from ostream or similar and that already overloads all the operator<<s.

Finding Your Way Home

Like many of us, you may need to host stuff on your home computers and access it via the Internet. If you paid for a static address from your provider, you can map a domain name to it via your ISP’s DNS. But for the majority of us, getting a static address from our provider means paying a good deal more for little to nothing more. For example, my provider (which by the way offers excellent service) is so stable that my IP address changes once a year, or even less often. But for others, the IP address changes more often and it’s difficult to keep track of it.

Some services, like DynDNS, provide you with a script and a couple of tools to access your stuff via a virtual domain name (or something like that). The magic behind DynDNS maps your domain name to your ever-changing provider-specific IP address. But what if you just want to find your way home, without a domain name and without having to deal with an extra service provider?

Lost+Found: Lego Antikythera Mechanism

Being S.M.A.R.T. with Drives

As I mentioned before (here and here), you really can’t trust your hardware to maintain a good health all by itself. It can overheat because of bad case design, dirty fans, or it can just burn out because of a bad PSU. It can also die from old age, which can mean any kind of weird symptoms, from random freezes to programs that crash all the time. You can test bad RAM using the free Memtest86+ which is conveniently packaged with Ubuntu’s live CD, and you can test your drives using their built-in SMART capabilities.

SMART (or S.M.A.R.T) stands for Self-Monitoring, Analysis, and Reporting Technology, and it’s basically extra sensors and firmware added to your hard disks so that they can detect hardware failures and other conditions, such as the drive’s temperature. The tool of choice on Linux to access SMART status is Smartmontools, which turned out to be most useful.

Suggested Reading: Optimizing Compilers for Modern Architectures

Randy Allen, Ken Kennedy — Optimizing Compilers for Modern Architectures — Morgan Kaufmann, 2002, 790 pp. ISBN 1-55860-286-0

(Buy at Amazon.com)

The book presents all the high-performance and vectorizing optimizations a compiler should be able to perform on source code while using trade-offs from the underlying architecture (with considerations such as the memory hierarchy and the instruction set) and the semantics of the language.

Suggested Reading: Proof from THE BOOK

Martin Aigner, Günter M. Ziegler — Proofs from THE BOOK — 3rd ed., Springer, 2004, 240 pp. ISBN 3-540-40460-0

(Buy at Amazon.com)

Paul Erdős always refered to proofs that were particularly elegant or powerful as proofs from The Book, a book with a transfinite number of pages, held by God (in which he didn’t believe), containing all the most beautiful proofs of all mathematical theorems.