The other day, I checked out the web interface to the database of in-patient care diagnoses run by Swedish Socialstyrelsen. On first opening the site, it looked broken and unusable – the text was basically unreadable, mixing giant numbers with strange- looking regular characters, lines of text overlapping each other, and a general sense of being totally chaotic. That is not what you or I would expect from an official site of a government entity. They have no reason to play games with the look of the site. So how come it was all that broken? Didn’t they test the site properly under all circumstances?Continue reading “Testing what the User will See (and why it might not work out)”
I recently read a few articles on cognitive biases, decision making, and expert intuition from the field of management research. Then an article popped up from the Communications of the ACM (CACM) dealing with cognitive bias in software development. The CACM article is a small field study that serves up some interesting and potentially quite useful conclusions about how to think about thinking in software development.Continue reading “A Study of Cognitive Biases in Software Development”
A colleague pointed me at the grugbrain.dev website the other week. It is a very humorous set of observations on corporate life and advice to young developers – written in a silly “cave-man” style. It is obviously based on long experience. The text is also quite quote-worthy, with some passages even being quite poetic in their rough-hewn simplicity.Continue reading “Blog: Grug Brained Developer Make Sense “
I recently published a long post on the Intel Community Blog, talking about how my colleague Evgeny solved a nicely complicated bug using Simics-on-Simics. The bug involved UEFI, an operating system, SMM, SMI, and virtualization. Just another day in the office (or more like a year, given how long it took to get this one resolved).
Back in 2016, the European Space Agency (ESA) lost the Schiaparelli Mars lander during its descent to the surface on Mars. From a software engineering and testing perspective, the story of why the landing failed (see for example the ESA final analysis, Space News, or the BBC) is instructive. It comes down to how software is written and tested to deal with unexpected inputs in unexpected circumstances. I published a blog post about this right after the event and before the final analysis was available. Thankfully, that has since been retired from its original location-it was a bit too full of speculation that turned out to be incorrect… So here is a mostly rewritten version of the post, quoting the final analysis and with new insights.Continue reading “The ESA Schiaparelli Crash & Simulation”
Back in April, I presented a talk about how you can use Lego as an analogy for software development in the ProductBeats Show. The talk was based on my previous musings about Lego and software. It was a great fun 15 minutes with a good after-discussion moderated by Magnus Billgren. As always at the ProductBeats show, Magnus nudged me and the audience to think. He kicked off the talk by asking the audience and me about the process of assembling IKEA furniture. Is that assembly about building or designing? That is a very god question. Here is my attempt at an answer.Continue reading “Building or Designing, Lego and IKEA”
The SystemC Evolution Fika on April 7 had threading/parallelism as its theme. There were four speakers who presented various angles on how to parallelize SystemC models. The presentations and following discussion provided a variety of perspectives on threading as it can be applied in virtual platforms and other computer architecture simulations. It was pretty clear that the presenters and audience had quite different ideas about just what the target domain looks like and the best way to introduce parallelism to SystemC. Here is my take on what was said.Continue reading “SystemC Evolution Fika: Parallel SystemC”
In a previous blog, I talked a bit about the hazards of coding to an implementation and not a specification, based on 1980s home computers. While the specifics and peculiarities of that case is hopefully confined to old hardware, the lessons are still worth contemplating. There is a modern variant of this phenomenon that is based on open-source software, and that I must admit to feeling a bit annoyed by. Fundamentally, the question is this: when figuring out how to use an API – should you look at the documentation or the implementation?Continue reading “Don’t Look behind the Curtain! (Please)”
When discussing the design and integration of systems on chip and models of systems on chip, the Lego analogy is often brought up. The idea being that with Lego, anyone can put together anything and every component can be combined with all other components. Right. My recent building of Lego set 21327, Typewriter, makes me wonder if the people who talk about Lego-like construction have actually built anything from Legos in the past few decades.Continue reading “Easy to Assemble, just like Lego – Right…”
I have recently got back to developing training labs for the Simics simulator (and related technologies). During the process of developing a new accelerator model using as many of the latest frameworks and APIs as possible, it was basically guaranteed that I would hit some bugs and unexpected behaviors. That is a natural part of and benefit from creating training materials in the first place. It also provides a good illustration of two fundamentally different ways to look at software development. One is to play it safe and get things done in known ways, and the other is charge ahead, try the unknown, and see what happens. Damn the torpedoes, bugs are a benefit. No bug reports, no glory. In this post, I will share some recent examples of just coding ahead and breaking thing.Continue reading “Blog – Damn the Torpedoes, Full Code Ahead!”
Just like in 2020, the Design and Verification Conference (DVCon) Europe 2021 was a virtual conference. It took place from October 26 to 27, with the SystemC Evolution day on October 28 (as usual). As has been the case in recent years, the verification side of the conference is significantly larger than the design side. This is common with the other DVCon conferences in the world. In this blog, I will go through my main observations from DVCon Europe, and share some notes from some of the presentations.Continue reading “DVCon Europe 2021 – Testbenches, AI, and Open Source”
I recently stumbled on a blog post called Building Faster AMD64 Memset Routines, written by Joe Bialek of the Microsoft Security Response Center (MSRC). The blog describes his efforts to improve the performance of the Windows kernel memset() function, across all sizes of memory to set. The reported optimizations are quite fascinating, and could be summed by avoiding branches even at the cost of doing redundant stores. Basically, stores are free while branches are expensive.Continue reading “Microsoft Windows memset Optimization – Stores are Free”
Wind River is celebrating their 40th anniversary as a company with a series of historical look-backs posted on the Wind River channel on YouTube. One of the videos is an interview with Jerry Fiddler who founded Wind River back in 1981, by Wind River current CEO Kevin Dallas. Jerry Fiddler talks about how he got started in computers, and especially about how Wind River got started and grew. It is both a fantastic set of historical anecdotes and some solid product management and strategy insights.Continue reading “Jerry Fiddler on the Early Days of Wind River and Building a Product”
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”
Last year, we spent a significant part of the fall and early winter renovating some aspects of our apartment*. Things like (finally) updating the flooring in the living room, updating the wallpapers, painting the interior staircase white, and changing out all doors. The renovation process provides some interesting analogies to the process or updating an existing software code base – especially in discovering the design decisions of the past and unearthing the layers of legacy that underlies why things look like they do today.Continue reading “Renovations and Software”
The Design and Verification Conference Europe (DVCon Europe) took place back in late October 2020. In a normal year, we would add “in München, Germany” to the end of that sentence. But that is not how things were done in 2020. Instead, it was a virtual conference with world-wide attendance. Here are my notes on what I found the most interesting from the conference (for various reasons, this text did come out with a bit of delay).Continue reading “DVCon Europe 2020 – Developing Hardware like Software?”
The July 2020 edition of the Communications of the ACM (CACM) had a front-page theme of “Domains-Specific Hardware Accelerators”, or DSAs. It contained two articles about the subject, one about an academic genomics accelerator, and one about the Google TPU. Hardware accelerators dedicated to particular types of computation are basically everywhere today, and an accepted part of the evolution of computers. The CACM articles have some good tidbits and points about how accelerators are designed and used today. At the same time, I also found a youtube talk about the first hardware accelerator, the IBM Stretch HARVEST, showing both contrasts with today as well as a remarkable continuity in concept.Continue reading “CACM on DSAs”
I have written before about the debug advice to “Quit thinking and look.” It means that you should not form conclusions prematurely. Stop and look at what is going on instead of guessing and cooking up theoretical scenarios. Sound advice that I completely failed to follow in the case that I just chronicled on my Intel Blog: https://software.intel.com/en-us/blogs/2020/03/18/quit-thinking-and-look-chasing-simics-performanceContinue reading “Intel Blog Post: “Quit Thinking and Look” – Mea Culpa Chasing a Performance Bug”
I find debugging a very interesting topic of study, so when I stumbled on the paper “Studying the advancement in debugging practice of professional software developers”, I had to do a blog on its contents.Continue reading ““Studying the Advancement in Debugging Practice” / 2016 Paper”
My blog post from last week, “Programming for Everyone, Everyone’s a Programmer?,” gave rise to some good comments from friends and colleagues on the matter of programming. Some of the points are worth addressing in a continuation of the discussion. To get the starting point, please read the previous post first.Continue reading “More on Programming”
Recently, I have read some articles and seen product announcements based on the idea that we need to make programming easier. Making it easier is supposed to make more people program, and the underlying assumption is that programming can be easy enough that everyone can do it. I have also talked computer science undergraduate students who kind of asked me just how many years at the university you should do, and what do you actually in practice gain from a university degree in computer science? When I think about it, these two discussions really come down to the same question: Should everyone be a programmer? Can everyone be a programmer? What does it mean to be a programmer? How do you best learn to program?Continue reading “Programming for Everyone, Everyone’s a Programmer?”
I have a new blog post out on the Intel Developer Zone, about the Simics 6 device register coverage feature. I use device register coverage to look at how different operating systems use the same hardware. The differences are significant, demonstrating the (rather expected) observation that different software stacks use the same hardware in different ways.Continue reading “Intel Blog: Simics 6 Device Register Coverage”
A while ago, Ars Technica reviewed the Mega Sg, a modern clone of the old Sega Genesis gaming system. I stumbled on this review recently and realized that this is a fascinating piece of hardware. The Mega Sg is produced by a company called Analogue (https://www.analogue.co/), presumably named thus because they create analogues to old gaming consoles. The way this is done is different from most current “revive the old consoles” products that simply use software emulation to run old games. Instead, Analogue seems to have settled on using FPGA (Field-Programmable Gate Array) technology to basically build new hardware that is functionally equivalent to the old console hardware.Continue reading “Using FPGAs to Simulate old Game Consoles”
For Simics training and demo purposes, we often use Linux* running on the virtual platforms. In the early days of Simics and embedded Linux, we built our own minimal configurations by hand to run on simple target systems. Most recently, we changed our Linux default demo and training setup to use Clear Linux*. This change showed us just how sophisticated modern Linux setups are – which is good in general, but it also can make some low-level details more complicated.
I wrote an Intel Developer Zone Blog Post about our experience moving to Clear Linux for Simics demos and training, which contains a lot more details of what we observed and did to make this work for our purposes.
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!”
The US Defense Advanced Projects Agency (DARPA) ran a “Cyber Grand Challenge” in 2016, where automated cyber-attack and cyber-defense systems were pitted against each other to drive progress in autonomous cyber-security. The competition was run on physical computers (obviously), but Simics was used in a parallel flow to check that competitors’ programs were not trying to undermine the infrastructure of the competition rather than compete fairly inside the rules of the competition.Continue reading “Intel Blog Post: Simics in the DARPA Cyber Grand Challenge”
There are some things in computing that seem “obviously” true and that “clearly” make it “impossible” to do some things. One example of this is the idea that you cannot go backwards in time from the current state of a program or computer system and recover previous state by just reversing the semantics of the instructions in the program. In particular, that you cannot take a core dump from a failed system and reverse-execute back from it – how could you? In order to do reverse debugging and reverse execution, you “have to” record the state at the first point in time that you want to be able to go back to, and then record all changes to the state. Turns out I was wrong, as shown by a recent Usenix OSDI paper.Continue reading “Microsoft REPT: You CAN Reverse from a Core Dump!”
DVCon Europe took place in München, Bayern, Germany, on October 24 and 25, 2018. Here are some notes from the conference, including both general observations and some details on a few papers that were really quite interesting. This is not intended as an exhaustive replay, just my personal notes on what I found interesting.