FLOSS Weekly

I was a bit disappointed that they did not discuss paravirtualization, the concept that at least I think is the main contribution of Xen. Paravirtualization is the idea of modifying the hardware interface of an operating system just slightly to make it much more convenient and efficient to run it on top of a hypervisor. This is really not that different from the architecture in the classic heavy-duty server world, with the programming interface of the Sun Niagara, IBM POWER, and IBM zSeries machines all being not bare-metal but rather a more structured API to a layer partially implemented in software.

Xen is shaping up nicely to be a lot of things to a lot of people. I liked their work on live migration (done in the same way as I think I read IBM doing it in POWER). The discussion on snapshotting was also good, even if I felt he introduced it as something completely new, which it is not. VMWare has had it for ages. And my favorite simulator, Simics, also has it in an even more powerful way. Another interesting aspect is the use of Xen on ARM-based mobile devices, even where no real hardware support exists for virtualization (incidentally, this was the starting point for Xen on the x86 back in 2001 and the reason I understand for going with a paravirtual solution rather than a VmWare-style binary rewrite solution). Busy field, with lots of contenders.

The open-source nature of Xen is also very important to the project (and the reason for Ian Pratt being interviewed by FLOSS Weekly, as that show is all about open-source projects). In addition to enabling the exploration of new additions to the core “product”, it also means that Xen is  a great research tool. With Xen, researchers can implement virtualization-related ideas in a real industrial-strength product, which makes it much easier to do applicable and realistic research. Indeed, one of the greatest thing with the current strong open-source trend in the world is that research institutions have a complete system and application software stack that can be modified at any point to try new ideas. From the hypervisor to operating systems, compilers, middleware, language virtual machines, and lots of server and desktop application software.

Pratt was not exactly overly humble, but I think he is correct in taking some credit for having put virtualization front-and-center in the x86 market. Before Xen, it was not at all as hot as a topic. Or it might just be coincidence. I was a bit annoyed at his lack of painting a bigger picture: I would have liked more credits and more comparisons to previous work, especially the IBM classic architectures and what VmWare and others have been doing on the PC. If you had no context and listened to this show, you could well come away with the impression that Xen invented virtualization, which is not really the case at all.

Note that FLOSS weekly is still one of my regular podcasts, despite the occasional episode that I take issue with.

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.

The best bit is the discussion around named parameters and how that was introduced into Visual Basic for Application in Excel — and at the same time they reduced the argument counts to most functions by replacing them with manipulating properties of objects. I think that approach does make some sense, if you have something that lends itself to that kind of expression. Their comparison of having a single function call with 83 arguments to change the style of text in Word by silently effecting a dialog box, or actually setting each of 83 properties of a dialog box object makes eminent sense… Sense that applies to simulators as well: in Simics, we do have a system like that, with attributes on all objects in the simulation that can be set to change their behavior and connections. Trying to configure that in the SystemC-style with function calls and constructors from scratch would be a pain, definitely.

Another topic that struck a chord with me was the notion that we are moving towards a world of “little languages” built for particular purposes. I definitely think this is the right way to go, as domain-specific languages do make getting particular things done easier. The more general a language is, the worse it is at any particular task. Better then to use a smaller language built to do one thing. As Jeff put it, for databases uses SQL, for text processing using Perl, etc… Using a multitude of languages is the hallmark of good software design and a natural instinct for a computer scientist.

They also found a YouTube video of the old computer science (CS) song “Write in C“. They do not seem to get that this is a really old song, I remember singing it way back when I was a fresh undergrad CS student here in Uppsala… and it was part of the first edition of our nice leather-bound songbook called “Manualen”. The lyrics are starting to feel a bit dated, but it is still a very elegant piece of writing that I think took place in the mid-1980s, judging from the other languages referenced.

Anyway, an unusually listen-worthy edition of Stackoverflow.

The z10 is the latest generation of the classic IBM mainframe family that started with S/360 back in the 1960s. The simulation for just running the firmware of these beasts is making most other virtual platforms look positively puny – focusing on single SoCs for consumer or digital devices. It also shows that virtual platforms as a technology can scale all the way from single-core bare-metal simple machines that are useful for developing initial software for simple embedded systems up to servers and racks containing hundreds of processing units and very diverse hardware.

The teminology used is unusual, compared to the EDA/ESL and computer architecture research worlds. But it is good. The key concept is a “VPO”, Virtual Power On. For a computer of this class, doing Power On is a major event, and calling it a “boot” does not really cover its full complexity, involving many different layers of software running on the same and different computers. The VPO was targeted at four months prior to hardware tape-out — and this means that at that point in time the virtual system would be complete and the firmware complete enough to do a power on.

The simulation system used for the z10 mixes IBM’s in-house CECsim with Virtutech Simics. CECsim executes the code for the central zSeries processors, while Simics simulates the FSP-1 “flexible support processor” based on the Power Architecture. In previous generations of simulation, the FSP code had been host-compiled and run on an x86 workstation instead of running the actual Power Architecture binaries. Running the real binaries brought additional verification value to the software, finding 3 times more bugs than in the previous host-based simulation:

Because the Simics environment now enables us to execute all FSP code in simulation, a far greater amount of code is simulated. Correspondingly, the number of defects found in simulation also increased, by more than 33(Table 2).

The article also describes how hardware-accelerated simulation of the actual VHDL of complex new IO chips were used to validate the bits-and-cycles-level interfacing between code and the logic, as well as to validate the logic design itself.

Overall, the article is one of best presentations of comprehensive use of various types of simulation tools and techniques to remove firmware defects as early as possible in the system development project.

For more on the history of this, I refer to a previous blog post here, “The 1970 rules strikes again“, where I described some late 1960′s mainframe simulation technology and its uses. Also, browse the back issues of the IBM JRD archives, there are lots of nuggets to be found there!

The authors are experienced parallel software writers working at Intel, and who wrote this book for Intel as part of the multicore push.

The book covers the obvious topics for any introduction book to parallel programming:

• Application patterns for parallel programs: various ways to structure computations to extract or expose parallelism.
• Programming APIs.
• Common problems in parallel code.
• Debugging parallel code.
• Performance tuning parallel code.
• Fundamental computer architecture.

In my mind, the best part of the book is the application patterns and programming APIs section. The most interesting aspect of the book was the weight given to the programming APIs and debug tools for Windows. In comparison, most other texts that I have seen focus on the portable and generally available pthreads/Posix threads API or OpenMP. The Windows APIs are actually pretty cool and powerful. Note that the .net managed code (CLR) environment has its own set of APIs similar to but distinct from the general old Win32 API.

The authors clearly have a weak spot for OpenMP, and more time is spent on OpenMP than any other API. I remain unconvinced about its generality, but it certainly has some interesting properties. But it is far from automatic parallelization. MPI gets a very strange treatment, being tucked away in a late part of the debugging chapter. Why it was not considered a full programming API is beyond me.

A section on memory consistency is pretty well written and is one of the best expositions on how that actually works on x86 and Itanium architectures.

The worst part of the book is the strangely confused and forced section on hardware architecture. Being an Intel (trademark) book about Intel (trademark) processors and programming them, the chapter on Pentium (r) and Core (r) and Itanium (trademark) processors was probably mandatory. But to someone with prior knowledge of computer architecture it is all very confused, trying to press ILP together with SMT (HyperThreading) and multicore into some joint thread concept that just does not work as a pedagogical concept.  Also, Itanium takes up an inordinate amount of space for what is basically a moribund architecture. But I guess that Intel (trademark) cannot acknowledge that Itanium (trademark) is a titanic disaster. At least not yet.  This chapter is also full of little (r) and ™ markers and various Intel product names that really makes it harder to read.

There is a good description of Intel multithreaded programming tools, not surprisingly.

Overall, the book offers a good read, but it suffers from also being Intel PR material. I do not recommend against reading it, especially not if you are programming in an x86 desktop environment. But if you are attacking an embedded Power Architecture problem, I think there are better sources.

Note for publicity thinkers: I bought this book after reading a technical article at Embedded.com “Technical Insights”. Submitting book chapters or excerpts as technical articles there could drive readers and buyers to your books. Worked on me at least, at least this one time.