A comment on my old blog post about the history of reverse execution gave me a pointer to a fairly early example of replay debugging. The comment pointed at a 2002 blog post which in turn pointed at a 1999 LWN.net text which almost in passing describes a seemingly working record-replay debugger from 1995. The author was a Michael Elizabeth Chastain, of whom I have not managed to find any later traces.
I followed-up on my visit to the Bovington Tank Museum in the UK with a visit to the Swedish equivalent, Arsenalen in Strängnäs. It is about 100 km from Stockholm, and thus less far off than the UK variant. Arsenalen is strictly speaking a “vehicle” museum, not just a tank museum, even though a majority of the vehicles on display are indeed tanks or at least armored vehicles.
Last week, I visited the rather wonderful tank museum (http://www.tankmuseum.org/home) at Bovington in England, UK. Fascinating, and I am happy to have seem so many legendary machines for real.
Today, I visited the Portsmouth Historic Dockyard in Portsmouth, UK, together with my kids. Somewhat surprisingly maybe, the kids mostly loved it and I got to see and learn a lot of interesting history. I found it particularly usful to compare the three main ships on display: the 1510 Mary Rose, the 1765 HMS Victory, and the 1860 HMS Warrior. They show both the development and continuity of the Royal Navy over a very long period of time.
In a dusty bookshelf at work I found an ancient tome of wisdom, long abandoned by its previous owner. I was pointed to it by a fellow explorer of the dark arts of computer system design as something that you really should read. The book was “Fortress Rochester”, written by Frank Soltis, and published in 2001.
I just read an article from IEEE Annals of Computing history about the COMIC Color-Matching Analog computer built and sold by Davidson and Hemmendinger, a US firm. It seems the computer is pretty well known inside the colorant industry, actually, and it provides an interesting example of how to do a good-enough solution to break open the market – while leaving the user in control of the process to build faith in the approach.
I just found and read an old text in the computer systems field, “Why Do Computers Fail and What Can Be Done About It?” , written by Jim Gray at Tandem Computers in 1985. It is a really nice overview of the issues that Tandem had encountered in their customer based, back in the early 1980s. The report is really a classic in the computer systems field, but I did not read it until now. Tandem was an early manufacturer of explicitly fault tolerant and highly reliable and available computers. In this technical report Jim Gray describes the basic principles of fault tolerance, and what kinds of faults happen in the field and that need to be tolerated.
This is another vacation-related post, of the kind that I do every once in a year or so. I recently came back from a family vacation to Gothenburg (Göteborg in Swedish), where I had some time to visit a few great museums dealing with history, and in particular with military history and the history of technology.
Apple just released their new iPhone 5s, where the biggest news is really the 64-bit processor core inside the new A7 SoC. Sixty four bits in a phone is a first, and it immediately raises the old question of just what 64 bits gives you. We saw this when AMD launched the Opteron and 64-bit x86 PC computing back in the early 2000’s, and in a less public market the same question was asked as 64-bit MIPS took huge chunks out of the networking processor market in the mid-2000s. It was never questioned in servers, however.
Note: This post was caused by listening to an interesting science podcast while thinking about the theories of startups, and the connection might seem a bit odd. Still, I think there is something to be learnt here. End note.
I recently listened to the episode on Bliss, by the Radiolab podcast. As always, Radiolab manages to take a theme and connect all kinds of things to it. In this case, bliss as in happiness turned into Bliss, the man, and his invention of Symbolics. Symbolics was an attempt to create a rational language based on symbols that would not allow the manipulation of human opinion or feeling like regular languages do. It was an attempt to create an antidote to the manipulations of dictators, tricksters, and populists (Bliss himself had been briefly interned in a pre-war German concentration camp, so he definitely knew what words could do). He designed a symbolic writing scheme that was intended to only communicate ideas clearly and unambiguously and with no room for demagogery and oratory. In the end, nobody wanted to use the language for its original purpose.
After some discussions at the S4D conference last week, I have some additional updates to the history and technologies of reverse execution. I have found one new commercial product at a much earlier point in time, and an interesting note on memory consistency.
I recently read the classic book The Soul of a New Machine by Tracy Kidder. Even though it describes the project to build a machine that was launched more than 30 years ago, the story is still fresh and familiar. Corporate intrigue, managing difficult people, clever engineering, high pressure, all familiar ingredients in computing today just as it was back then. With my interesting in computer history and simulation, I was delighted to actually find a simulator in the story too! It was a cycle-accurate simulator of the design, programmed in 1979.
In this final part of my series on the history of reverse debugging I will look at the products that launched around the mid-2000s and that finally made reverse debugging available in a commercially packaged product and not just research prototypes. Part one of this series provided a background on the technology and part two discussed various research papers on the topic going back to the early 1970s. The first commercial product featuring reverse debugging was launched in 2003, and then there have been a steady trickle of new products up until today.
This is the second post in my series on the history of reverse execution, covering various early research papers. It is clear that reverse debugging has been considered a good idea for a very long time. Sadly though, not a practical one (at the time). The idea is too obvious to be considered new. Here are some papers that I have found dating from the time before “practical” reverse debug which for me starts in 2003 (as well as a couple of later entrants).
For some reason, when I think of reverse execution and debugging, the sound track that goes through my head is a UK novelty hit from 1987, “Star Trekkin” by the Firm. It contains the memorable line “we’re only going forward ’cause we can’t find reverse“. To me, that sums up the history of reverse debugging nicely. The only reason we are not all using it every day is that practical reverse debugging has not been available until quite recently. However, in the past ten years, I think we can say that software development has indeed found reverse. It took a while to get there, however. This is the first of a series of blog posts that will try to cover some of the history of reverse debugging. The text turned out to be so long that I had to break it up to make each post usefully short. Part two is about research, and part three about products.
Continue reading “Reverse History Part One”
On the very binary date of 11-11-11, my alma mater, the computer science (DV, for datavetenskap) education at Uppsala University celebrated its thirty years’ anniversary. It was a great classic student party in the evening with a nice mix of old alumni and fresh-faced students. Lots of singing and some nice skits on stage. Great fun, and my voice has still not recovered. It also got me thinking about it is that we really do as computer scientists.
Just for fun, I tried to surf the web of today using a Netscape 4 browser from 2001.
The result: not exactly useful. Netscape 4 was bad back then, and it does not work at all with the current style of web coding.
From what little I had heard and read, the IBM AS/400 (later known as iSeries, and now known as simply IBM i) sounded like a fascinating system. I knew that it had a rich OS stack that contained most of the services a program needs, and a JVM-style byte code format for applications that let it change from custom processors to Power Architecture without impacting users at all. It was supposedly business-critical and IBM-quality rock solid. But that was about it.
So when Software Engineering Radio episode 177 interviewed the i chief architect Steve Will, I was hooked. It turned out that IBM i was cooler than I imagined. Here are my notes on why I think that IBM i is one of the most interesting systems out there in real use.
I just read an interview with Steve Furber, the original ARM designer, in the May 2011 issue of the Communications of the ACM. It is a good read about the early days of the home computing revolution in the UK. He not only designed the ARM processor, but also the BBC Micro and some other early machines.
There is a new post at my Wind River blog, about some computing history. Wind River turns thirty this year, Simics twenty, and simulation for debug (and probably debug in general) turns sixty. Computing has come a long way.
I recently read the “Cubase64 White Paper” by Pex Tufvesson. It is a fantastic piece of retro computing, where he makes a Commodore 64 do real-time audio effects on a sampled piece of music. There is a Youtube movie showing the demo in action. Considering how hard we worked in the early 1980s to make a computer make any kind of useful noise at all, this is an amazing feat. It is also a feat that I think would have been impossible at the time.
In the June 2010 issue of Communications of the ACM, as well as the April 2010 edition of the ACM Queue magazine, George Phillips discusses the development of a simulator for the graphics system of the 1977 Tandy-RadioShack TRS-80 home computer. It is a very interesting read for all interested in simulation, as well as a good example of just why this kind of old hardware is much harder to simulate than more recent machines.
The EDSAC was an early computer in the mathematics laboratory at Cambridge in the UK. I have just read an old article on the machine and how it was programmed, from a 1998 issue of the IEEE Annals of the History of Computing.
There are many fascinating aspects to the machine and its utter simplicity, but one that struck me as I read the paper was that so many of the fundamental ideas of programming and practical computing were invented then and there. Indeed, the EDSAC was designed as a machine to experiment with programming, rather than as a machine for maximal computing performance.
I have just found what almost has to be the first cycle-accurate computer simulator in history. According to the article “Stretch-ing is Great Exercise — It Gets You in Shape to Win” by Frederick Brooks (the man behind the Mythical Man-Month) in the January-March 2010 issue of IEEE Annals of the History of Computing, IBM created a simulator of the pipeline for the IBM 7030 “Stretch” computer developed from 1956 to 1961 (photo from IBM.com).
Wow. The eruption of Eyjafjallajökull in Iceland and the resulting ashcloud has had an effect that I would never ever have expected. A near-total closing down of the European airspace is such a drastic thing to happen to nobody seems to have expected. It has certainly not been included in the list of worst-case scenarios to plan for in company and government contingency plans. Where does this leave us? In a very interesting situation indeed. Worst-case, we will have to do without air travel for months.
I am a regular listener to the Matt’s Today in History podcast. When Matt asked for contributions for this spring (in order to meet a goal of 500 podcasts before Summer) I did give some thought to what I could contribute. Looking over some books, I found one suitable Spring date: the launch of the IBM System/360 back in 1964. The resulting podcast is now live at Matt’s Today in History.
Please be kind to any mistakes… I am trying to paint a broad picture for a computer-history-ignorant audience here.
During the Christmas holidays, I got the chance to compare my oldest child’s brand new Lego set with some from the mid-1980s. It is quite striking how much larger the things in the sets have become, and how much more affordable (in relative terms) Lego has become since then.
Unless you have been living under a rock I guess the media deluge has made it clear that it was twenty years ago on November ninth that the Berlin Wall fell. Wow. Without a doubt the most momentous and important event that I have lived through. Not at all on the topic of this blog, but important enough to write some personal recollections about.
IEEE Spectrum has an article in its May 2009 issue called “25 Microchips that shook the world“. Not long or deep, but an interesting mix of chips from the 1970s, 80s, 90s, and the 2000s. Recommended as light reading.
Yes, when does hardware acceleration make sense in networking? Hardware acceleration in the common sense of “TCP offload”. This question was answered by a very nicely reasoned “no” in an article by Mike Odell in ACM Queue called “Network Front-End Processors, Yet Again“.