These are the wires used to make my intergalactic spaceship

Ihave been becoming increasingly disheartened in recent years by how little the new generation of programmers know about how computers work. Their understanding of the relationship between what they tap into a computer and what the microprocessor actually ends up doing with it has degraded to effectively zero. Only a minority of dedicated explorers ever understand anything more a sprinkling of the basics. I have moaned before about this when holding out hope for the Raspberry Pi computer but ultimately, it is an entire computer with a complete modern operating system. You will have had to compile many tens of thousands of lines of code before you are even beginning to create your clone of Space Invaders.

Prof. Farnsworth: Let me show you around. That's my lab table and this is my work-stool. And over there is my intergalactic spaceship! And here's where I keep assorted lengths of wire.

Fry: Whoa! A real live spaceship!

Prof. Farnsworth: I designed it myself. Let me show you some of the different lengths of wire I used.

From little wires, great things are built: simple things in quantity - just like your computer

This knowledge gap was highlighted by Cliff, an independent developer, when he wrote a post recently about the advantages that he has had that allowed him to get to a position where he can make a good living doing something he absolutely loves. Other than the obvious “work hard” type observations he raised the point that he had grown up with a Sinclair ZX81. A commenter asked why this was an advantage and I offered a brief, badly structured reply along the lines of it providing a framework understanding of the lowest level components of hardware and software; an understanding that provides a firm set of foundations upon which to build incredible applications. I also grew up with such machines: I cut my teeth on an Oric 1. Back in those days, you plugged your computer into a telly, switched it on and were presented with a prompt. No windows, no icons, no mice. And this wasn’t a shell type prompt, this was an interactive interface to the computer’s programming language, usually BASIC.

With no cover-disks or Internet, most teenagers of the 80s ended up typing in program listings from magazines. By hand1. After a while, you couldn’t help but pick up the basics of BASIC and in no time at all you would be annoying Dixons sales staff by typing in programs to display the latest swear word you’d learnt all over the shop’s screens. Many of us went further: we learnt assembly language2. This is as close to the microprocessor’s actual binary instructions as you can possibly get: there was a one to one mapping between each instruction you typed and the binary code that was executed on the CPU. Even the simplest programs taught the programmer about memory, fetch-execute cycles and the inner details of how a CPU performed its magic… and then we learnt that it was not magic. It was incredibly simple, there was just a lot of it. Even more amazingly, that knowledge scaled. It scaled from 8 bit processors to 16 bit processors through 32 bit processors to today’s multi billion transistor state-of-the-art eight core mega processors. Even today, the biggest, baddest CPU Intel can deliver is still made from the same basic building blocks as the first CPU I ever programmed directly… there’s just a hell of a lot more of it.

This knowledge is an incredible tool for programmers to have. Understanding how a CPU does its work makes it easier to write faster, better code. It lets you achieve in 100 instructions what someone else may require a thousand to do. For low-level languages such as C, C++ and Objective C, old school assembly language programmers can still visualise what happens to their code. They still tend to use “old tricks” even though modern optimisers will almost certainly handle them automatically. Either way, when it comes to super-fast code, the advantage that they have is vast: they architect and create better structured and cooler code. One area where this advantage really renders your walls and skins your oranges is games.

The games that excite me for the future are worlds so real that I cannot tell the difference any more. I want a holodeck. I want the Matrix in my living room. I want to see what it feels like to stand on the top of the tallest mountain, what it feels like to fall to earth from space, what it is like to bounce around the moon. In the absence of the truckloads of cash that would allow me to actually do these things, virtual reality entertainment environments are probably as close as I am going to get with the added advantage of no risk of actual death. Creating software that does this kind of thing is going to take some serious innovations: the problem is waaaay to vast and complex to be solved from the top-down, one will have to create the code out of which the world can emerge. Biology, I am convinced, will be a vital source of inspiration. Innovating the solutions that will lead to this is firmly greased by an understanding of how the machine works. I humbly suggest that treating the computer as a machine for modelling machines is a valuable step towards creating the next generation of virtual worlds: the computer is simply a container of machines that can be combined to produce more machines – an Nth order computational device, if you like.

Dreams of the future aside, your favourite super-cool modern 3D PC, 360 or PS3 game is not written in Java. It is not written in Flash. It is not written in C#. It is written in C++ and it is created by a team of programmers who understand how disastrous a cache miss is to the performance of software. The best of them know how to get each core of a parallel system burning at 100% all of the time. They have developed data structures that are super compact so that the maximum amount of data can be cached in RAM and the maximum amount of that fits in the CPU’s internal caches. They have innovated new ways of rapidly extracting critical data and new ways of preprocessing and storing that data to improve runtime performance. In short, they are using their knowledge of how computers work to write software that roars. This is non-trivial. Any computer games company will tell you how hard it is to find programmers who know this stuff. Unfortunately, modern computers and the complexity and size of their APIs are simply not helping to bring up a new generation of true software innovators: you can’t simply start without jumping through a daunting number of hoops — some of which are flaming.

To be fair, it is possibly not helped by whoppingly unrealistic expectations. When I was a teenager my expectations of what I could achieve on a computer were, well, pretty low – and I barely met those. I blame girls with their boobs and things along with the positively ungenerous twenty odd thousand bytes coupled with an eight-bit processor. This kind of stuff generally limits one to the simple stuff so it was pretty straightforward to keep your feet at least within sight of the ground. Now, many set off on projects of huge proportions such as MMOGs, for example, without the tiniest clue of how they are going to be executed. The inevitable crash and burn is hardly going to be a morale boost. Now, I’m not one whose conscience is entirely clear when it comes to the mountains from molehills issue, but I figured that it might be fun to do a series of posts over a month or six on how to write an old style adventure game: we’d start from nothing and then knock out an 80s style adventure game in C++. A sort of “hello, welcome to programming” type course. It might be worth a shot, yes?

1 Nothing is more heartbreaking than spending four hours typing in a program only to lean on the power cord. Regular saves to… tape… were required.
2 … and then used that knowledge to patch the restart vectors so that those annoying programs were really, really hard to get rid of without a power-cycle. The BBC Micro was a cracker for this!

This entry was posted in Software development and tagged , , , , . Bookmark the permalink.