Back when I was a PhD student working on worst-case execution-time (WCET) analysis, one of the leading groups researching the topic was the “Saarbrücken gang” led by Professor Reinhard Wilhelm. Last year, Professor Wilhelm published a retrospective look on their work on WCET in the Communications of the ACM. It is a really interesting history write-up from the perspective of the Saarbrücken group.Continue reading “Professor Reinhard Wilhelm on the History of WCET Analysis”
The history show (and podcast) of Sverige Radio, Vetenskapsradion Historia, is one of the shows that I subscribe to and listen to regularly. In their look back at 2020, they reminded me of an episode from back in the summer that indirectly introduces what I believe to be the first programmer in Sweden.Continue reading “The First Swedish Programmer (1790s)?”
Continuing on my blog posts about our Hemester (part 1 covered Bodens Fästning), this blog post will cover Hemsö Fästning. Both are fascinating places, but also rather different, and clearly demonstrate the changes from the early 1900s to the Cold War of the 1950s.Continue reading “Hemsö Fästning – Coastal Defense from the 1950s”
Due to Covid-19, this year’s summer vacation involved a “staycation”, or “hemester” as we say in Swedish. We went up north in Sweden, and took the chance to visit some military museums. In particular, the fortresses at Hemsön and Boden (fästning means fortress). Both are fascinating places, but also rather different, and clearly demonstrate the developments from the early 1900s to the Cold War of the 1950s. This post covers Boden, with a separate post for Hemsö released a few days after this post.Continue reading “Bodens Fästning – A Fortress in the North of Sweden”
Recently, we had a discussion at work (in our daily virtual team “fika”) where we reflected on just how many weeks we had been working from home due to the Covid-19 pandemic. It has been quite a few; I last saw the office in week 11, and week 19 is beginning… so I am looking at eight weeks personally. Just how did it all begin? I thought it useful to go back and try to remember how we got to this point. In hindsight, I never thought it would be this huge.Continue reading “Recalling the Beginning of Covid-19 and Work-from-Home”
I heard about the DOOM Game Engine Black Book by Fabien Sanglard on the Hanselminutes podcast episode 666, and immediately ordered the book. It was a riveting read – at least for someone who likes technology and computer history like I do. The book walks through how the ID Software classic DOOM game from 1993 works and the tricks and techniques used to get sufficient performance out of the hardware of 1993. As background to how the software was written, the book contains a great description of the hardware design of IBM-compatible PCs, gaming consoles, and NeXT machines circa 1992-1994. It covers software design, game design, marketing, and how ID Software worked.Continue reading “DOOM Black Book – This is Brilliant!”
Last weekend, the yearly Flygdag (Airshow) of the Swedish Armed Forces took place in Uppsala at Ärna. Huge crowds, but it was still easy to get a good view of the aerial displays that took place. In this blog post, I just wanted to share a few photos.
Thanks to a tip from “Derek” on a previous blog post about a replay debugger from 1995, I was made aware of the reverse execution ability that was available in the Borland Turbo Debugger version 3.0 from 1992! This is the oldest commercial instance of “reverse” that I have found (so far), and definitely one of the oldest incarnations of the idea overall. Thanks to Google and the Internet, I managed to find a scanned copy of the manual of the product, which provided some additional information. Note that the debugger only does reverse execution, but not reverse debugging since you cannot run in reverse to stop at a breakpoint.
Bengt Werner was one of the first people to work on the simulator that would become Simics, way back in 1992. On my Intel Blog, I published an interview with Bengt a while back where we discuss the early days of Simics and the original product vision and use cases.
Last month, I (together with my family and some friends) tried the virtual reality (VR) experience that has been created for the museum in Gamla Uppsala. VR is used to let people explore the area around Gamla Uppsala, experiencing what it looked like back in the year 650 AD. 650 AD is in the middle of the Vendeltid era (before the Viking age which is typically considered to start around the year 800). At this point in time, Gamla Uppsala had been an important religious and political center for a long time. The big burial mounds that dominate the landscape to this day were already old by then, having built in the 500s.
I have a new blog post up at the Intel Developer Zone, this time about the Simics “fulprompt”. Every software team has its legends about spectacular mistakes, crazy users, and customer calls with strange questions. The Simics “fulprompt” is one example of this from the early days of Simics. It was a prompt that appeared where no prompt would normally appear, right in the middle of executing an instruction. As such, it was an ugly hack… and for Swedes who were around in the 1990s, the only name for a ugly hack is a fulhack.
Injecting faults into systems and subjecting them to extreme situations at or beyond their nominal operating conditions is an important part of making sure they keep working even when things go bad. It was realized very early in the history of Simics (and the same observation had been made by other virtual platform and simulator providers) that using a virtual platform makes it much easier to provide cheap, reliable, and repeatable fault injection for software testing. In an Intel Developer Zone (IDZ) blog post, I describe some early cases of fault injection with Simics.
Back in 2004, the startup Virtutech built a crazy demo for the 2004 Embedded Systems Conference (ESC). Back then, ESC was the place to be, and Virtutech was there with a battery of demos to blast the competition. The most interesting demo from a technology perspective was the 1002-machine network, as described in an Intel Developer Zone blog post of mine.
I have just released a new blog post on my Intel Developer Zone blog, about how Simics runs
large huge workloads. I look back at the kinds of workloads that ran on Simics back in 1998 when the product first went commercial, and then look at some current examples running on Simics. This is the first post in a series intended to celebrate 20 years of Simics as a commercial product.
A blog post from Undo Software informed me that Microsoft has rather quietly released a reverse debugger tool for Windows programs – WinDbg with Time Travel Debug. It is available in the latest preview of WinDbg, as available through the Windows Store, for the most recent Windows 10 versions (Anniversary update or later). According to a CPPcon talk about the tool (Youtube recording of the talk) the technology has a decade-long history internally at Microsoft, but is only now being released to the public after a few years of development. So it is a new old thing 🙂
I once wrote a blog post about the use of computer architecture pipeline simulation in the IBM ”Stretch” project, which seems to be the first use of computer architecture simulation to design a processor. After the ”Stretch” machine, IBM released the S/360 family in 1964. Then, the Control Data Corporation showed up with their CDC 6600 supercomputer, and IBM started a number of projects to design a competitive high-end computer for the high-performance computing market. One of them, Project Y, became the IBM Advanced Computing Systems project (ACS). In the ACS project, simulation was used to document, evaluate, and validate the very aggressive design. There are some nuggets about the simulator strewn across historical articles about the ACS, as well as an actual technical report from 1966 that I found online describing the simulation technology! Thus, it is possible to take a bit of a deeper look at computer architecture simulation from the mid-1960s.
Today, when developing embedded control systems, it is standard practice to test control algorithms against some kind of “world model”, “plant model” or “environment simulator”.
Using a simulated control system or a virtual platform running the actual control system code, connected to the world model lets you test the control system in a completely virtual and simulated environment (see for example my Trinity of Simulation blog post from a few years ago). This practice of simulating the environment for a control computer is long-standing in the aerospace field in particular, and I have found that it goes back at least to the Apollo program.
In the early 1990s, “PC graphics” was almost an oxymoron. If you wanted to do real graphics, you bought a “real machine”, most likely a Silicon Graphics workstation. At the PC price-point, fast hardware-accelerated 3D graphics wasn’t doable… until it suddenly was, thanks to Moore’s law. 3dfx was the first company to create fast 3D graphics for PC gamers. To get off the ground and get funded, 3dfx had to prove that their ideas were workable – and that proof came in the shape of a simulator. They used the simulator to demo their ideas, try out different design points, develop software pre-silicon, and validate the silicon once it arrived. Read the full story on my Intel blog, “How Simulation Started a Billion-Dollar Company”, found at the Intel Developer Zone blogs.
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.