programming – Observations from Uppsala

ChatGPT and Code

In my previous blog post about ChatGPT and Simics, I tested it on its knowledge and abilities with a fairly niche subject. Not unsurprisingly it did not do all that well. However, one area where ChatGPT appears to really work well is when dealing with program code. This seems more practically useful as well, especially as a generator of starting points and boiler-plate code. It can also sometimes do a decent job explaining code, subject to quite common bizarre mistakes and errors.

DVCon Europe 2022. Verification, System Simulation, and People!

The 2022 DVCon (Design and Verification) Europe conference was back in physical form at its usual venue at the Holiday Inn München. It was a great conference, and just like at the 2022 DAC people were very happy to be back in person.

Notes from our DVCon Europe 2022 Tutorial

I presented a tutorial about the “verification of virtual platforms models” at DVCon Europe last week. The tutorial was prepared by me and Ola Dahl at Ericsson, but Ola unfortunately could not attend and present his part – so I had to learn his slides and style and do my best to be an Ola stand-in (tall order, we really missed you there Ola!). The title maybe did not entirely describe the contents – it was more a discussion around how to think about correctness and in particular specifications vs implementations. The best part was the animated discussion that we got going in the room, including some new insights from the audience that really added to the presented content.

Updated: Included an important point on software correctness that I forgot in the first publication.

Elektroniktidningen Magazine Article about DML

The November 2022 on-paper magazine from Swedish electronics news site Elektroniktidningen features an article I wrote about the Device Modeling Language (DML). Among many other really good articles.

Update: The article is now available online in HTML format.

Intel Blog: Open-Sourcing the Device Modeling Language

The Device Modeling Language (DML) that we have used with Simics since 2005 is now available in open source! Some more details and examples of what DML looks like can be found in an Intel blog post.

Testing what the User will See (and why it might not work out)

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?

A Study of Cognitive Biases in Software Development

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.

Blog: Grug Brained Developer Make Sense

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.

Intel Blog: Catching a Tricky Bug by Running Simics on Simics

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).

The ESA Schiaparelli Crash & Simulation

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.

Building or Designing, Lego and IKEA

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.

SystemC Evolution Fika: Parallel SystemC

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.

Don’t Look behind the Curtain! (Please)

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?

Easy to Assemble, just like Lego – Right…

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.

Blog – Damn the Torpedoes, Full Code Ahead!

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.

DVCon Europe 2021 – Testbenches, AI, and Open Source

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.

Microsoft Windows memset Optimization – Stores are Free

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.

Jerry Fiddler on the Early Days of Wind River and Building a Product

Wind River is celebrating their 40^th 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.

Professor Reinhard Wilhelm on the History of WCET Analysis

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.

Renovations and Software

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.

DVCon Europe 2020 – Developing Hardware like 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).

CACM on DSAs

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.

Intel Blog Post: “Quit Thinking and Look” – Mea Culpa Chasing a Performance Bug

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-performance

“Studying the Advancement in Debugging Practice” / 2016 Paper

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.

More on Programming

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.

Programming for Everyone, Everyone’s a Programmer?

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?

Intel Blog: Simics 6 Device Register Coverage

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.

Using FPGAs to Simulate old Game Consoles

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.

Intel Blog Post: Clear Linux for Simics Demo & Training

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.

DOOM Black Book – This is Brilliant!

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.