Peter Nowak argues that most of the major technological advances of the last sixty years have stemmed from the trio of billion-dollar industries that cater to our basest impulses. From Saran Wrap to aerosols, digital cameras to cold medicine and GM foods to Google, many of the gadgets and conveniences we enjoy today can be traced back to either the porn, military or fast food industry.

This certainly sounded interesting. And the book was a good read. However, it was not a great read.

I applaud the research that Peter Nowak has put into the book, and all the fun anecdotes collected. Certainly makes for good conversation pieces and it explained a few long-standing mysteries to me. For example, the story about The Lena, which was a picture that kept popping up when I was doing desktop publishing in the early 1990s, without any explanation for why. It is a fun read, fluent and quick.

However, the book leaves me slightly disappointed and a bit annoyed.

It is a book that I consider to be “light fact” – with a title that plays on the “heavy scholar”-class book Guns, Germs, and Steel. It is nowhere near that book in depth, rigour, or explanation power. A bit presumptuous, simply.

The book is indeed very focused on the post-world-war-2 era, which makes some sense. But it would have been much more satisfying if Nowak had gone back and drawn the lines from antiquity forward. Also, it would have been nice with some contrasting between the Cold War’s strong drive to take on almost any technology with the 19th century’s somewhat more conservative military approach to new technologies like steam power. It is also a bit US-centric, and slightly chauvinistic in places. Sure, the US has led many innovations (and still does) – but a more global perspective would have made the book a bit more compelling.

If you look closely at the arguments being made, I have to find a bit of a fault with the inclusion of the porn (sex) industry. Sure, porn has been an early adopter of several new communications technologies, from the printing press and on. But it is not an innovation industry of its own, it is just an early adopter with some amount of money to spend. It certainly makes for a good provocative book title, but it is not really well reasoned. I would say that vanity is a better prime driver – showing off wealth and sophistication by consuming very expensive luxury goods has historically been an important financier of both fine arts and fine technology. It even ties back to sex – since in the end, strutting your stuff like a peacock is about capturing a fine specimen of the opposite sex.

The food (burger) industry is more apropos, since it is a huge enterprise industry of the kind that has traditionally both picked up on new innovations and set up labs to do its own innovation. No fault with that. But there are other industries that have done the same, including telecoms and computing.

Where the book really goes off and annoys is when Nowak switches from describing little-known facts in history to preaching and predicting the future. That just does not fit into the flow and premise of the book. Nowak talks about how automatic translation will make our online friendships span the globe – which is prediction, not description. And one that sounds a bit more like techno-hype than reasoned analysis. He does the same for robotics, maybe because robots are not really yet a part of everyday life, or he does not find industrial robots interesting enough.

The worst bit is the strange and misplaced discussion on genetically modified organisms. Their connection to the war theme is a bit a tenuous, and the lashing out at the EU for being skeptical and wanting to move slowly is pretty unreasoned. Nowak sounds like either a lobbyist wanting to get things marketed globally, or a techno-evangelist who thinks that technology can solve all problems. Which is a bit strange, since in other places in the book Nowak does address the many problems that modern technology has introduced along with the problems it solved. Still, his bias is very much on the benefits side rather than the risks involved.

In summary, a nice little collection of anecdotes that is worth reading in order to understand the funny background of many things we take for granted today. But it is no more than that, and be prepared for some out-of-scope chapters that preach and predict rather than describe the facts.

This is a small detail, but one where I have always had a feeling that some fundamental assumption was missing in my discussions with various people from the hardware design community. It always seemed that hardware designers assumed a different basic design – and Grant Martin explained it very well just what that was. They only check for interrupts at the beginning of a time slice. Which makes interrupts less precise  versus the code, but also makes the core interpreter fairly simple since all it has to do is to churn through instructions.

There is another solution, which is employed in Simics, where the processor can take an interrupt at any point in a time quantum. To do this, the processor needs to be aware of what is going to happen. The essentials of the solution is to have devices call the processor and tell it that they intend to interrupt it at some point T in time. The processor simulator then makes sure to stop and give the device model a chance to act at that exact point in time. It is obvious that this solution is easily generalized to cover all time callbacks needed to drive device work. A significant part of the responsibility for running the event-driven simulation is moved into the processor core.

Making the event queue visible to the processor also gives the processor a chance to hypersimulate, or skip idle time. Since it knows the next point in time that something will happen (either the end of a time quantum or an event posted by a device), it can very easily, safely, and repeatably jump forward in time without any impact on simulation semantics.

When dealing with multiple processors, this means that each processor will have precise interrupts from the devices that are close to it. Timers and IO interrupts tend to work closely with a certain processor for a prolonged period of time. Interrupts between processors suffer a time-quantum delay sometimes, but that is no worse than the solution of checking all interrupts at time-quantum boundaries.

Qemu uses a solution which is a mix of the two. According to the 2005 Usenix paper, devices do call into the processor to announce an interrupt, but this is handled by “soon” returning to the processor main loop. Processors are not responsible for keeping track of interrupts, making it very imprecise and not very repeatable when interrupts will happen.

Thus, we can see that there are a few different ways to implement interrupts in virtual platforms. Each approach comes from a different tradition and features different trade-offs.

I was a bit surprised by the comment in the Tensilica chapter that only correctly synchronized programs will work on a temporally decoupled simulation. In my experience, temporal decoupling is transparent to software functionality – all software runs. The perceived timing of operations can be different, and some tightly-coupled code might behave in suboptimal ways, but it certainly runs and works. And lets you observe  parallel code errors.

Temporal decoupling is necessary in any fast platform, and its effect on semantics are really minor. With the simple tweak of having a processor know when interrupts might happen, it will also not affect the device-processor interface very much, maintaining very tight synchronization between processors and their controlled hardware.

It is one of the more comprehensive introductions to how to think about and use multicore architectures in the high-end embedded space. It is free to download and print, but if you want a printed copy, such can be ordered at a price of (I am told) 15 USD (did not try it myself).

The PDF is at http://www.freescale.com/files/32bit/doc/ref_manual/EMBMCRM.pdf .

It will also be linked from the “Documentation” section for most Freescale multicore chips’ information pages.

The book is obviously a collection of previous work, and the style is quite inconsistent from section to section. Not so much that it detracts from the value of the information, but it does feel a bit rushed.

The book presents four sets of taxonomies:

• Models, which is by far the richest part. In addition to a definition of terms in the field of building models of digital systems, it also offers a detailed classification scheme for the models. The classification scheme uses five “resolution” axes along with an external/internal perspective to define what a model contains and at what level of resolution.
• Functional Verification, which is really just a collection of terms.
• Platform-Based Design, which is more of a marketing discussion in how to define and design platforms. Also mostly a definition of terms.
• Hardware-Dependent Software (HdS), which defines terms. It has some attempts to classify software along some axes, but it does not really work out too well.

The main value is really in the second chapter, where it does provide a decent basis for discussing the level of abstraction at which models are created (note that accuracy is different from abstraction: a very detailed model at a very low level of abstraction can be totally off when considered from an accuracy perspective).

However, I fear that the impact of this work has been fairly limited. No discussion on modeling that I have been participating in has really gone back to this basis and worked from there. I think a key problem here is that the material is only available as a quite expensive book from Springer, rather than as a freely downloadable document on the web. It is clear to me that spreading ideas today depends on free and easy digital access to the information… that’s why I have my own publications page up to make stuff that I have created available for reading.

The hardware-dependent software (HdS) section gave rise to several “but they forgot X” comments from my part. For example, it is missing important aspects like processor virtualization, hypervisors, and IO virtualization (which totally change the game on HdS). Also, SMP operating systems are only giving a passing reference, with the focus on uniprocessors. And why do people keep using the term “Rate-Monotonic Analysis? There are so many much more modern fixed-priority scheduling analysis theories, methods, and tools available that RMA is like talking about programming in assembler…

What a choice for summer vacation reading…  and thanks to Bart Vanhournout at CoWare for the tip about the book in a discussion trying to pin down abstraction levels.

I just got my personal copy, but my first impression of the book overall is very positive. The contents seems quite practical to a large extent, not as academic as one might have feared. Do check it out if you are into the field. It is not a collection of research paper, rather instructive chapters informed by solid research but with applications in mind.