There is a new post at my Wind River blog, about how you actually do fault injection in Simics. This particular post is pretty detailed, showing the actual architecture of a fault injector in Simics, not just “yes you can do it”. It includes actual diagrams of system components and how you can insert fault injection into an existing system, so it is a bit more technical than most my Wind River blog posts that tend to be more conceptual.
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.
Read more…
I have now posted the slides from my keynote talk at the S4D 2011 conference to the presentations list on my regular home page. The topic of that talk was “System-Level Debug”, something which has started to interest me in recent years.
Is the touchscreen the end-all of user interfaces for mobile devices? There were rumors in early 2011 that the iPad2 would lose all physical buttons (which did not come true, obviously). To me, that sounds like a really good and bad idea. Good, in the sense that a device that is all a big screen certainly looks nice. Bad, since it would be much less user-friendly than a device with some real physical buttons to press.
I have been thinking about this subject lately, after using a BlackBerry Torch 9800 as my work phone for a few months. I like the device a lot, but there are certainly some rough edges and some places where there is a UI conflict between touching the screen and pressing the buttons. At the same time, I am using both an iPod Nano 3G, and a couple of iPod Touches. I used to have SonyEricsson Symbian-based P900, P990i, and G900 smart phones which also were combined touch/press devices with a stylus.
Fault Injection is a topic that has fascinated me for a long time. Not just the area of software-to-software fault injection, but more so how you inject faults into hardware using hardware (and how to conveniently approximate this using a simulator). I just stumbled on a short interesting note about such hardware-actuated fault injection in a Fujitsu article.
It used to be that Microsoft was the big, boring, evil company that nobody felt was very inspiring. Today, with competition from Google and Apple as well as a strong internal research department, Microsoft feels very different. There are really interesting and innovative ideas and paper coming out of Microsoft today. It seems that their investments in research and software engineering are generating very sophisticated software tools (and good software products).
I have recently seen a number of examples of what Microsoft does with the user feedback data they collect from their massive installed base. I am not talking about Google-style personal information collection, but rather anonymous collection of user interface and error data in a way that is more designed to built better products than targeting ads.
There is a new post at my Wind River blog, an interview with Dan Poirot at RTI who is using Simics to model and test heterogeneous, distributed, networked systems.
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.
Last week, I had the honor of presenting at and attending the talks of the Lindholmen Software Development Day. The first keynote speaker was Professor Jan Bosch from Chalmers, who did his best to provoke, prod, and shock the audience into action to change how they do software. While I might not agree with everything he said, overall it was very enjoyable and insightful talk.
On my Wind River blog, I just posted a fairly long post about simulation abstraction levels. It was inspired by a cool article in ArsTechnica about Nintendo emulators, and the costs and benefits of being ever more faithful to the hardware.
I just read a quite interesting article by Christian Pinto et al, “GPGPU-Accelerated Parallel and Fast Simulation of Thousand-core Platforms“, published at the CCGRID 2011 conference. It discusses some work in using a GPGPU to run simulations of massively parallel computers, using the parallelism of the GPU to speed the simulation. Intriguing concept, but the execution is not without its flaws and it is unclear at least from the paper just how well this generalizes, scales, or compares to parallel simulation on a general-purpose multicore machine.
Paul Henning-Kamp has written a series of columns for the ACM Queue and Communications of the ACM. He is pointed, always controversial, and often quite funny. One recent column was called “The Most Expensive One-Byte Mistake“, which discusses the bad design decision of using null-terminated strings (with the associated buffer overrun risks that would have been easily avoided with a length+data-style string format). Well worth a read. A key part of the article is the dual observation that compilers are starting to try to solve the efficiency problems of null-terminated strings – and that such heavily optimizing compilers quite often very hard to use.
I just had two articles published the Embedded Design part of the EETimes.
First, “Rethink your project planning with a virtual platform“, which talks about how virtual platforms can change your entire project planning. Essentially, by reducing project friction and risks related to hardware availability, software integration, and show-stopper bugs, you can make projects work much better.
Then we have “Transporting bugs with virtual checkpoints“, which is a shorter, popular science, version of the paper I published last year at S4D. This describes how you can use checkpointing in a virtual platform to communicate bugs across time, space, and teams.
Nvidia recently announced that their already-known “Kal-El” quad-core ARM Cortex-A9 SoC actually contains five processor cores, not just four as a “normal” quad-core would. They call the architecture “Variable SMP”, and it is a pretty smart design. The one where you think, “I should have thought of that”, which is the best sign of something truly good.
There is a new post at my Wind River blog, which could seem to be about shoes but which is really about process improvement. In particular, the need for companies to let their employees take a step or two back and look at what they are doing and what they could do better.
It is way too common to be so busy running around being inefficient that there is no time to think about how to become more efficient. Change also requires some discipline to actually keep pushing at habits until they change for the better.
Every once in a while I need to build demo setups to show debugging in action. As I have blogged before, finding a good bug when you need one isn’t always easy. The solution is to try to invent artificial bugs, and I was very happy when I managed to stage a buffer overrun in a VxWorks program.
It is pretty very nice demo in which you first start a period program A, which prints the value of an incrementing counter every target second. You then run a supposedly unrelated program B, resulting in the values that program A prints to become corrupted. Perfect to show off reverse execution and data breakpoints in reverse as you go from the point where the corrupted value is printed to the piece of code that overwrote the variable.
But then I ported the demo to a new platform… and the bug didn’t work anymore. My bug had caught a bug and was now not working, or at least not they way I expected it to. What had happened?
Read more…
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.
There is a new post at my Wind River blog, about hypersimulation in virtual platforms and how it lets virtual time fly much faster than real time. It was the result of simple mistake of leaving Simics running in the background as I did other work on my machine.
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 how you build virtual platforms with Simics. The post is more about the methodology than the nature of models, cycle accuracy, endianness, and all the other details of virtual platform modeling. I have written about modeling methodology on this blog too, and in particular I would recommend looking at “Two perspectives on modeling“.
I just read the book Sex, Bombs, and Burgers, written by technology journalist Peter Nowak. The summary (minus some unnecessary hyperbole) from the book’s website reads:
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.
Recently, Gary Stringham has been running a series of interviews with providers of register design tools on his website. Register design tools seems to be an active area with several small companies (and some open-source tools) fighting for the market. I have written about Gary Stringham and register designs before, and it is an area that keeps fascinating me. There is something about the task of register design that keeps it separate from the main hardware design languages, tools, and flows.The different approaches taken by the tools supporting the register design task also illustrates some points about programming language standards, domain-specific languages, and exchange formats that I want to address.
This Summer, our travel-away-from-home vacation was spent in Sälen, Sweden. Sälen is normally considered a winter destination, one of the biggest ski resorts in Sweden – but they are working on making it more of a year-round attraction. To be more precise, we went to Lindvallen, which is one of the seven or so separate “villages” that form the “Sälen” area. It was a nice and relaxed place, with little stress from having too many things to do, but enough to keep the kids happy. Seeing the mountains in the Summer was nice.
There is a new post at my Wind River blog, about the “Toddler stage” of software in general and Simics 4.6 in particular. To me, software in an early stage of development shares many traits with a toddler:
The software will sometimes behave as expected, but more often than not it will not. It will do something else, or crash, or generally do the wrong thing. It is very much like a toddler – you can rely on it to some extent, but you never know when it will decide to do something unexpected, funny, or just throw a fit over something that would have seemed inconsequential.
For some reason, in the past few weeks I have talked to more than a few PhD students and researchers about various ideas. It is striking how often fundamentally very smart people have a problem in articulating just why what they are doing is useful, relevant, and potentially commercially interesting. Of course, we all know that this is hard, and all PhD students get some kind of training in presentation and selling their ideas. It is also unfair to expect a fresh graduate student to be able to put on a show like a Simon Peyton-Jones.
However, this did get me thinking some about the articulation of problems.
By chance, I got to attend a day at the UPMARC Summer School with a very enjoyable talk by Francesco Zappa Nardelli from INRIA. He described his work (along with others) on understanding and modeling multiprocessor memory models. It is a very complex subject, but he managed to explain it very well.
I often have to create screenshots and screen recordings as part of my job, and to make that look good I don’t want any part of my Windows desktop or task bar to show in the results. Until now, I have done this the hard way by using very few desktop icons and putting them around the edges of the screen.
There is a better way.
