For those unfamiliar with the Stretch machine, it was a supercomputer developed by IBM which introduced many of the performance techniques and basic computer technologies that we all use today (most of them handed down to us via the IBM System/360). For example, it was the first to use 8-bit bytes and 64-bit floating point. It also introduced memory protection, memory interleaving, and instruction prefetching.

More relevant for my blog is the fact that the Stretch used the world’s first pipelined main processor, complete with interlocks to maintain program-order semantics. When developing this pipeline, Frederick Brooks claims that IBM developed a program to simulate the pipeline. This simulator was used to test the performance of the pipeline design on various test programs (this was before they were called benchmarks), and tune the design accordingly. The simulator was created by Harwood Kolsky. There is no firm date for the pipeline simulator, but based on the development time of the Stretch, it can be dated somewhere around 1960.

Thus, the simulation-driven approach to computer architecture is about 50 years old by now. Should have gone to ISCA and used this as an excuse for a party I guess…

It is also interesting to note that the Stretch computer acquired a co-processor in 1962, to do cryptology work. This machine was the one-off IBM 7950 “Harvest” and was tailored for the needs of the NSA in the US. It was a seriously special-purpose hardware unit adding a few instructions to the Stretch machine, and beating any other machine at the time by about 50 to 200 on the particular NSA workloads.  Sounds like the kind of performance claims that Tensilica and other application-customized processors claim. 50 years ago.

Please be kind to any mistakes… I am trying to paint a broad picture for a computer-history-ignorant audience here.

The silly thing is that I don’t have a strong recollection of it. My most vibrant memory from that tumultuous Fall is from December, as we saw tanks roll through the streets of Bucharest on TV. I saw it on the American Armed Forces Network, to be precise, a night on the base with my friends from Keflavík Naval Air Station, also known to the Icelanders as “the base”. This was during the year I lived in Iceland, and went to school on the AT Mahan High School on NAS Keflavik. Sometimes I would sleep over on the base with some friends, despite being a “neutral” (non-NATO). But I digress…

The impact of the wall coming down was felt much more clearly the next year, when me and some friends drove down to Berlin. The wall was gone, but the space it had left was still there. The trade in East Bloc memorabilia was rampant, and we had several East German military caps and some cool medals with us as we drove home. Indeed, for the next few years, East Bloc and Soviet stuff was all the rage.  I actually found the cap when we cleaned out some boxes of old memorabilia the other week, guess it was fate. Or just coincidence.

It feels strange to know that the freshmen in university this year were not even born then. They have no memory of the cold war, and newspaper articles carry sidebars about “this was the DDR”… to the youngsters of today, DDR means dual-data-rate RAM, not the Deutsche Demokratische Republik.

1989 was also the year that I got my first Macintosh. An SE, with a 8 MHz 68000 processor and 2 MB of RAM, and 20 MB of HDD. It is dizzying to compare it with the machine I have at home today, a cheap Core i7 Dell. The processor is probably around 2000 times faster (300x clock, and at least 6x more efficient per clock), the memory is 4000 times bigger, the HDD 30000 times larger. Still, it does not feel as magic as that first Macintosh did… The next year, I got myself an SE/30, with a 16 MHz 68030 and an 68882 math co-processor. Screaming machine at the time, total clunker by today’s standards.

Finally, what other big events have I seen, events that you can peg a date and a memory on? The second biggest one is the killing of Olof Palme on Feb 28, 1986. Then we have “September 11″ which was quite a shock. Chernobyl. U137. I have no personal relationship to the other two big recent disasters of Sweden, the Estonia disaster and the Thailand Tsunami, but they could have counted otherwise.

Still, the end of the cold war is a big deal, and the way in which it opened up Europe to what it is today.

The article is highly recommended for its long historical look at network processing and network processing offload. As the balance  between speeds of networks, processors, memory, and interconnects between network cards and the rest of the system has changed over the years, it is an idea that occasionally (four or five times since the 1970s) has made sense. However, in the end, Mike thinks that it usually does not, and for a machine with multiple cores and a modern fast interconnect, it is hard to see how a hardware accelerator can actually help speed things up much when the coordination between the hardware and the software is accounted for. Even if there would appear to be a big bottleneck somewhere today, we can be sure that it wil be removed in the next generation of hardware, rendering the market window for an accelerator quite short.

I read this article as another great motivation for the need to carefully consider the functional design of the hardware-software interface for acceleration devices. For simple data-pumping or media-processing units, this looks easy. For something as complex as TCP/IP processing, it is not. I think the key is that for TCP, we have something that is much more like control-plane processing than data-plane processing, and that is harder to efficiently integrate between hardware and software. Also, there is not really that much work left to offload once data copies have been architected in the right way (and I read Mike’s article to say that we now know how to do this in a sufficently few-copies way that software is close to optimal in architecture).

From a market perspective, it would also indicate that the acceleration circuits that are in common use today are by definition those that make sense. Having hardware-accelerated graphics and video decoders does seem to help build more efficient and attractive computer systems, as do cryptography accelerators. With this view, it will be interesting to see which of all the accelerators found in modern networking SoCs like those from Freescale and Cavium will survive the test of time. I am willing to put a small bet that pattern-matching engines for traffic inspection is one of them. Apart from that, hard to say.

So go read that article before you start designing your next brilliant accelerator for a common expensive operation.

It also reminds me of a whitepaper I wrote early this year on how to evaluate performance of a hardware accelerator in the context of a full system with a full software stack, considering the details of the hardware-software interface.

The Spectrum came with a built-in BASIC interpreter that are up the bottom 16kB of the 64kB addressing space. The BASIC was actually fairly powerful and easy-to-use, and included a very fun programming textbook. I just reread that textbook, and it is quite strikingly well-written and manages to cover both basic computer-science-style programming and deep close-to-the-machine and real-time programming in a compact 150 pages. There is no credit to a particular author in the book I have (Swedish translation by a group of people at Ord & Form here in Uppsala), but an online scan credits Steven Vickers.

Overall, the book does a very good job of explaining both the Sinclair BASIC interpreter, as well as some general programming concepts. And how the machine works deep down. Here are some highlights.

Explaining Functions

The way that functions are explained made me laugh out loud (quoting the original English according to the online resource I found):

Consider the sausage machine. You put a lump of meat in at one end, turn a handle, and out comes a sausage at the other end. A lump of pork gives a pork sausage, a lump of fish gives a fish sausage, and a load of beef a beef sausage.

Functions are practically indistinguishable from sausage machines but there is a difference: they work on numbers and strings instead of meat. You supply one value (called the argument), mince it up by doing some calculations on it, and eventually get another value, the result.

This is a very good analogy to introduce functions, in a fairly gender-neutral way and assuming no mathematical background on part of the user. I wonder if I ever cared to define any functions… as I recall it, GOSUB was as far as I got in sophistication before leaving BASIC and starting writing everything in Z80 assembler.

Reading a Changing Counter

Later on in the book, a suggestion is made to get a better time counter. Essentially, by reading a 24-bit value incrementing at 50 Hz, using three separate PEEK commands:

(65536*PEEK 23674+256*PEEK 23673+PEEK 23672)/50

This code does subject you to the issue of reading during an update and counter wrap from one byte to the next. This complication is cheerfully noted after a complete program using this feature as a by-the-way-the-code-is-correct by a small loop. There are many such small gems in the book, essential tricks and caveats that still apply to programming close to the hardware and doing real-time programming.

We have No Clock

The ZX Spectrum, as most computers of its day, did not have a real-time clock on board. Instead, you had to time things using the 50Hz screen refresh interrupt (which is what the code in previous section reads) or by just adjusting your code to wait appropriately. One example program is supposed to show a clock updating every second. However, getting to a second is a bit tricky when there is no firm time-base to work on. The suggesting instead is this:

This clock will run down after about 55.5 hours because of line 60, but you can easily make it run longer. Note how the timing is controlled by line 210. You might expect PAUSE 50 to make it tick one a second, but the computing takes a bit of time as well and has to be allowed for. This is best done by trial and error, timing the computer clock against a real one, and adjusting line 210 until they agree. (You can’t do this very accurately; an adjustment of one frame in one second is 2% or half an hour in a day.)

So what we have here is a classic “how long must I wait to get a steady pace of execution for my periodic code?” issue familiar to anyone using an RTOS and trying to determine how long to sleep a process for until the next periodic interval starts. Once again, illustrated in ten lines of BASIC and a few lines of text.

Repeatability and Randomness

In Chapter 11, randomness using the built-in random function is introduced. This was a 16-bit periodic pseudo-random system where you could set the random seed to put start the random generation at any particular point in a 100% repeatable manner. Indeed, the book introduces the concept of doing this in order to ensure repeatable execution of a program relying on randomness. This sounds familiar from my previous post on simulation determinism:

If you had a program with RND in it and it also had some mistakes that you had not found, then it would help to use RANDOMIZE like this so that the program behaved the same way each time you ran it.

Delving into Details

The BASIC manual does not try to hide how the BASIC interpreter works internally, rather on the contrary, including a list of all system variables so that they can be POKEd and changed if need be. It also explains the data layout of all variable types (the Spectrum BASIC used 32-bit integers, impressive for an 8-bit machine, and 40-bit floating point numbers).

The only useful information for me in the way I used the machine as a pure assembly-language target was the memory layout of the screen. Which is bizarre to say the least. It had a separate black-and-white bitmap and color overlay for every 8×8 character. And each scan line was NOT consecutive with the previous in memory, but rather offset by 256 bytes. I think the idea was to make it easy to insert a single character into the bitmap by just incrementing the high byte of the address by one for each pixel line.

To make that work, the screen was divided into three pieces of 8 character lines/2048 bytes each (8 character lines of 8 pixel lines each, each with 32×8 bits of data).  The sprite drawing routines that would work with that to plot a 16×16 sprite in any screen position was amazing code, to say the least. I independently invented unrolled loops to make this run fast. And misused the POP instruction to pull in data to draw (it took 11 cycles, rather than 12 as a more usual register-indirect load would do) — provided that you turned off interrupts or data corruption would ensue.

These were fun programming times. It shaped my programming habits for a decade, culminating in an infamous 68000 assembler hack in my first undergrad year at Uppsala, with some 50 pages of very tight and complicated assembly language making use of most features of the 68k instruction set… poor TA.

Final Notes

On it goes like that. The chapters are short but very much to the point, and a large number of fairly subtle concepts are introduced. The Spectrum was a good school for a budding programmer, with no compiler, no safety net, but also no way to break the machine in a way that a reboot would not cure.

I actually recommend seeking out the aforementioned online repository for the Spectrum programming book, it is almost still in shape to be used as an introduction to real-time and embedded programming.

I am currently trying to figure out what is a good ZX Spectrum emulator to relive these old times if I can find time. The hardware unit I have depends on an analog tape drive to load software… and I gave up analog sound back in 1993. As if the magnetic tapes which have been in storage for 20 years have any chance of containing useful data anyway.

However, moving to Vista has made the printing bit harder.

In Windows XP, there were drivers available for the printer, since it was fairly recent when XP was released. In Vista, no such luck. So you have to resort to using “LPR” printing (optional install), and using the generic “Microsoft Imagesetter” as the printer profile. This, somewhat surprisingly, works pretty well.

With one exception: Acrobat.

It seems that Acrobat is trying so hard to be smart about printing that it gets confused by the Imagesetter bit, and decides that the thing on the other end is not a Postscript printer. And thus, it needs to have a 600 dpi bitmap of the page being printed sent to it. Needless to say, my old printer with its upgraded 12 MB of RAM (it came with 4, and I scavenged 8 more MB from some old dead PC that passed through my hands in the late 1990′s) usually chokes on this.

When my last XP machine was retired, this did indeed create a problem, since all official online forms tend to be Acrobat-based.

However, by accident and luck I decided to try the Foxit Reader as an Acrobat Reader alternative. This has turned out to be the perfect to solution to my printing woes. With Foxit, a PDF file prints as a small nice regular vector graphics file that my LaserWriter has little problem printing. It makes printing PDFs feasible and reliable again, and means that I do not have to go out and figure out which new printer to buy. It is kind of cool to have such a decade-old technology icon at home, and still in working order.

A final note: 12 MB in my printer. My first hard drive back in 1990 had 20 MB on it. My new desktop Core i7 machine just got upped to 9 GB of RAM. Back in 1991, I had my high school’s most powerful home computer: a Macintosh SE/30 with all of 5 MB of RAM (which cost a fortune at the time).

Strongly recommended thread at stackoverflow: http://stackoverflow.com/questions/102714/what-was-your-first-home-computer is about your first home computer. Some good product shots, and also some really funny things inserted.

Living in a decently old city does provoke a certain interest in history and how to access the past. Note that Uppsala, like everything in Sweden, is fairly recent on the grand scale of things. We have a cathedral from the 1200s, and some older churches going back to the 1000s, but before that there is not much to boast about. It is not like Rome or Egypt or China with thousands of years of civilization and with impressive buildings that still stand. But I digress…

The real problem with archives and digital technology is that it is really hard to preserve a large portion of the intellectual data that we produce today. When I was an archivist at Smålands Nation here at the university in the 1990s, it was real fun to browse through the old papers we had in the archive (only stuff from the past century, all the really old and valuable stuff was in professional hands at the national archives). Reading a menu from a party held in 1945, or the time plan for a large formal celebration in the 1950s, or a guest list from such an event was actually quite intruiging. You could see how tastes and traditions change, even as students all believe they are maintaining ages-old traditions faithfully… Browsing the member list in old handwritten ledgers was also great fun.

In another fifty year’s time, what will we have left from today’s activities? The party plans are now all just printouts from a throwaway word document, the member list a database on a PC, and unless you make a conscious effort, memories and printed papers will quickly fade (you do need to use the appropriate laser toner on low-acid archive-quality paper if you want the things to last even a decade, let alone a hundred years) and the students fifty years from now will have no idea on we ran our parties, who were in the nation, and other such facts of daily life. “Print it out” is easy to say but hard to do. Much of today’s digital data does not really print out in a useful way. A wiki, for example, can be printed as a snapshot. But the links and the edit history is gone.

But imagine if we could retain these digital documents accessible, in their living digital form. Having a proper database available for use and query is so much more interesting and powerful than a stack of papers. Being able to look at the audit history of a wiki, or the commit history of a program’s source code would offer a much deeper insight into the people and processes that produced the end results compared to just looking at a static snapshot.

What does it take to do that? A huge and known problem in digital archiving is the physical media access. All great archival institutions in the world have scores of different tape readers, disk readers, some new, some antique, and try to use these to pry the bits of equally antiquated storage media. This is bad, just like we have problems looking at old movies as the reams of film are literally falling apart. Clay tablets start to look positively sophisticated and a smart choice compared to our very brittle technologies.

Second, once we have the bits, what can we do with them? Now we have to tackle the file formats, and having pried them open, to find the fonts and character sets which are suitable for displaying them. Rendering a MacWrite document from 1985 on a modern machine will likely not quite give the same wonderful black-and-white 72-dpi view that you got back then… Or figuring out that for a while, we used 7-bit ASCII to write Swedish texts by replacing [, ], |, {, }, \ with å, ä, ö, Å, Ä, Ö (not in exactly that order — but I used to be fluent in reading and writing that!). Even worse, decoding a database file or purely binary CAD/CAM file is going to require some serious reverse engineering of the old programs that created them… unless you could run these same old programs in some way.

At least to me, an “obvious” solution is to use virtual platform technology to make keep the old software stacks running. Some archivists are apparently working on OS emulation of various kinds to keep the old software running, but I do think that it is much simpler and more general to just simulate the entire machine hardware. This will result in the smallest risk of error, and the greatest fidelity to the original software as oddities such as word lengths and character sets can be faithfully reproduced. Simply because the SW-HW interface in a machine is the best document and narrowest interface in the entire machine. Old tapes and disks should be turned into files stored on the mass storage of current machines, and these files can then be migrated to new machines as they come online. As long as you maintain the copies of the materials by reproducing them on new hard drives, they will not rot.

It will also have the property that the entire look and feel of the old systems remains accessible. Which is a blessing in that it maintains our digital heritage and lets computer historians also go back and see how old software looked and worked. It is also considered a curse by practising archivists who do not particularly like the idea of learning how to operate strange old operating systems with arcane command lines. I think this is not necessarily a big problem. Just like people today study and learn ancient languages to learn more about ancient cultures as embodied in their written records, I can see historians of the future learning to use old operating systems and programming languages to study the ancient culture of our time as embodied in our computerized records.

Creating these kinds of virtual platforms is quite different from the dominant virtual platform thinking in the commercial market place today which is focused on modeling new and future hardwares. Rather, we need to study an existing artefact and make a very good model of it. It is a different type of task, requiring slightly different types of tools.

Of particular importance is that the simulation platform totally insulates simulation models from the underlying machine. You need to be able to port the simulation to new operating systems, machines, and architectures without changing a line in the source code of the models. This means making sure to locate all host dependencies inside the simulation framework, and making sure that models are completely portable regardless of word lengths, endianness, and other aspects. You want to be able to take a model that you run today on an x86-64 on Linux and run it on some future 128-bit middle-endian platform with a completely different type of operating system. Basically, the simulation platform has to be a complete virtual machine in its own right. Probably, over time, we are going to add more layers of virtual platforms to get around really major shifts in computer system architecture. There is nothing saying that you can only virtualize once, already the IBM S/370 showed that you could virtualize recursively and to an arbitrary depth.

I do think that some tools that we have today are perfectly useful for this kind of undertaking.

The business aspects are going to be interesting, though. We would like to use the technologies already available in the sophisticated commercial virtual platform tools, that’s kind of given. But the archival market place is not the most lucractive… and that they would like to have very good insurance that the tools remain available. Including source-code escrow that would make the requirements of 25-years military projects look positively light.

Developing a completely new totally open-source solution sounds like a nice idea in theory, but is probably a bit too much work. It also takes no advantage of all the commercial technology available today. Maybe as the virtual platform market matures, the industry can come up with some way to provide this technology for the greater benefit of society. Basically, doing a bit of social work where we really have the tools to help.

I have no good solutions to that to offer right now.

But imagine how cool it would be to, in fifty years from now, gather the old team from Virtutech around some kind of display device and watch an ancient Simics 4.0 run on top of a virtual quadcore x86 with Linux 2.6… all running on top of Simics 29.0 (estimating one major version every two years) on some future I-have-no-idea-what-it-will-be hardware and software system. That really is something that would be cool to see happen.

The paper in question was published in 1969, and is titled “A program simulator by partial interpretation“. In the previous post, I took note of its use of direct execution of software plus trapping of privileged instructions, but that was not really the most interesting bits in there.

They lay out in quite simple terms most of the key ideas behind today’s fast virtual platforms. Here are the best parts:

• They note that simulation of a computer is often used to overcome debugging difficulties, in particular repeating failed runs and tracing all that is going on in the target machine.
• They are hunting down race conditions using the simulator.
• They use recorded input and output to drive a deterministic simulation even of workloads involving communication with the external world.
• They simulate multiple processors on top of a single physical processor by means of giving each processor a certain time slice to do its work before switching to the next processor. This is known as temporal decoupling or quantized simulation today, and is a key to the high speed of solutions such as Simics. They note the same tradeoffs as we see today, 40 years later, for doing this: shorter slices more accurately depict the parallelism, but also cost performance.
• The temporally decoupled simulation also includes timers and similar non-CPU-hardware. Just like we do it today for virtual platforms.
• In a temporally decoupled simulation, they optimize the simulation of the IDL, Idle, instruction. When it is encountered, they skip immediately to the end of the time slice. This is what we today call idle-loop optimization or hypersimulation, and which is absolutely key to achieving scalable simulation of large multiprocessor and multi-machine setups (since most parts of a system are not usually maximally loaded).
• They are debugging operating systems on the simulator, not just user-level code.

The computer in question is a Japanese System/360-compatible machine called the HITAC-8400. The work was reported in 1969, but actually carried out in 1967.

There are some differences in scale and kind compared to today’s virtual platforms, but none that detract from the underlying principles. The 1967 system is host-on-host, so it is not the kind of cross-environment that is most common in today’s virtual platforms (Power Arch on x86, ARM on x86, etc.). The IO system is much easier to simulate since it is part of the instruction set of the processor rather than being a set of complex memory-mapped peripherals.

So the 1970 rule strikes again. Not the IBM rule, this time, this was all done by Hitachi. There are traces of similar work at IBM in other papers, but I have not been able to locate actual copies of any publication.

The interesting bit is really the uses that this system is put to:

In promoting the ETSS project a program simulator based on an idea of partial interpretation has been constructed, and its principle and design are described in the paper. This new approach has been introduced to provide the simulator with such features as high speed and high accuracy in simulation and simplification in implementation. The essence of the idea of partial interpretation is using direct execution of instructions by hardware and simulation of them by an interpreter in combination, wherewith the hardware interrupt mechanism intermediates the two phases of the whole simulation. An interruption takes place when executing a “privileged” instruction, which triggers the simulation of the instruction. The other type of instructions are normally rendered to direct execution by hardware. The simulation method for devices operating in parallel is also described with respect to the timing control and scheduling. A program simulator of this type provides a powerful tool for debugging “supervisor ” programs and opens a new approach to system expansion.

Note that last part. This is essentially a virtual machine used for operating-system debug. So far, the earliest mention of this idea that I have found. There are similar ideas in a classic 1972 IBM paper. If anyone has seen anything older, please comment and tell me!

It is also fun reading these old papers… they are usually scanned from a paper copy, and therefore really show how papers looked and felt forty years ago. Long before desktop publishing, or even TeX.

The picture shown here was saved as GIF for use on the web. But scarily enough, apart from a few more GIF files, I could not open or even understand the file type of most of the files from that time, only ten years ago. Our digital archives are not very robust — more on that below.

What is kind of scary is that apart from the various GIF and TIFF renderings of the logo in various uses (for usage on the primitive web pages of 1996 mainly), I cannot retrieve the design data. It is all inside FreeHand 4 or FreeHand 5 files, for the Mac platform, using postscript fonts that only worked on MacOS 7 and 8 with Adobe Type Manager. So even if the files themselves are salvagable using contemporary software in 2007, some of the basic data they are built from is irretrievable for me. I gave away my last old Mac five years ago, and it is now dead.

A bit scary. And a good example of when simulation of a computer system could serve us well as a way to preserve the entirety of old software environment. I think this is a typical case of when you need the complete system a document was built on and not just the document itself to correctly interpret it. I guess I should make sure to “freeze” some current system environment inside a disk image at some point, to have something to go back in the future. Provided some software behaving like a 2007 PC can be created and found.

Final note: it around this time that I designed the version of the “cons box” seen as part of the logo above. This served for quite a few years as the main style of the logo of the computer science program at Uppsala University. It seems to have fallen out of use now.

Today, this feels like almost fanatical in its level of difficulty and effort and time. But when you think of it, many hardware and software engineers are struggling in the same way, trying to accomplish things for which they do not really have any efficient tools. Sometimes because there are no really good tools (as for example for finding parallelism in a serial software code), more often because they do not know of the good tools. Or most commonly, because they cannot get the budget to buy the good tools.

The hardware folks do seem to have mostly good tools these days, and the budget and knowledge to buy them. If nothing else, I guess this is because of the much greater cost of hardware and chip design respins. But software engineers seldom get to buy a 10kUSD or 100kUSD tool, even when it would save its own cost within a year.

Jack Ganssle had a good rant about this earlier this year at embedded.com:

“Why are you pounding that nail with a brick?”

“Hammers cost too much.”

For a startup with zero budget, this is understandable. But not in going concerns with armies of engineers and money in the bank. If there are tools that would help, do get them in the hands of your software people. The fewer Amiga breadboard prototypes people have to deal with, the better.

But I must admit doing a prototype that way sure must have given them a very very thorough understanding of their design. There is always some gain with the pain.