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.
I have a documented love for keyboards with RGB lighting. So I was rather annoyed when one of my Corsair K65 keyboards suddenly seemed to lose its entire red color component. The keyboard is supposed to default to all-red color scheme with the WASD and arrow keys highlighted in white when no user is logged in to the machine it is connected to – but all of a sudden, it went all dark except a light-blue color on the “white” keys. I guessed it was just a random misconfiguration, but it turned out to be worse than that.
Recently I stumbled on a nice piece called “Always Measure One Level Deeper” by John Ousterhout, from Communications of the ACM, July 2018. https://cacm.acm.org/magazines/2018/7/229031-always-measure-one-level-deeper/fulltext. The article is about performance analysis, and how important it is to not just look at the top-level numbers and easy-to-see aspects of a system, but to also go (at least) one level deeper to measure the components and subsystems that affect the overall system performance.
I recently asked myself the question of just how many Powerpoint files I had on my work laptop and on my home machines. It turns out that it was pretty easy to figure that out using Windows Powershell, with some commands I found on a random website.
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.
I just found a story about Undo software that was rather interesting from a strategic perspective. “Patient capital from CIC gives ‘time travelling’ company Undo space to pivot“, from the BusinessWeekly in the UK. The article describes a change from selling to individual developers, towards selling to enterprises. This is an important business change, but it also marks I think a technology thinking shift: from single-session debug to record-replay.
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.
There have been quite a few security exploits and covert channels based on timing measurements in recent years. Some examples include Spectre and Meltdown, Etienne Martineau’s technique from Def Con 23, the technique by Maurice et al from NDSS 2017, and attacks on crypto algorithms by observing the timing of execution. There are many more examples, and it is clear that measuring time, in particular in order to tell cache hits and cache misses apart, is a very useful primitive. Thus, it seems to make sense to make it harder for software to measure time, by reducing the precision of or adding jitter to timing sources. But it seems such attempts are rather useless in practice.
[Updated 2018-01-29 with a note on ARC SEM110-120 processors]
Continue reading “Timing Measurements and Security”
The introduction of non-volatile memory that is accessed and addressed like traditional RAM instead of using a special interface has some rather interesting effects on software. It blurs the traditional line between persistent long-term mass storage and volatile memory. On the surface, it sounds pretty simple: you can keep things living in RAM-like memory across reboots and shutdowns of a system. Suddenly, there is no need to reload things into RAM for execution following a reboot. Every piece of data and code can be kept immediately accessible in the memory that the processor uses. A computer could in principle just get rid of the whole disk/memory split and just get a single huge magic pool of storage that makes life easier. No file system, no complications, easy programmer life. Or is it that simple?
A while ago, I visited my Intel colleagues in Costa Rica and ran a workshop for university teachers and researchers, showing how Simics could be used in academia. I worked with a very smart and talented intern, Jose Fernando Molina, and after a rather long process I have published an interview with him on my Intel blog: https://software.intel.com/en-us/blogs/2017/12/05/windriver-simics-to-inspire-teachers-costarica
Over time, Intel and other processor core designers add more and more instructions to the cores in our machines. A good question is how quickly and easily new instructions added to an Instruction-Set Architecture (ISA) actually gets employed by software to improve performance and add new capabilities. Considering that our operating systems and programs are generally backwards-compatible, and run on all kind of hardware, can they actually take advantage of new instructions?
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 🙂
Intel Software Guard Extensions (SGX) is a pretty cool piece of technology that aims to make it possible for user programs to hide secrets from other user programs and the operating system itself. It establishes enclaves in the system that hides the data being processed and the code processing it from all other software. The original application for SGX was to support client-machine features like DRM, to create a safe space on a client that a server can trust. Recently, the people behind the Signal messaging system have provided a really interesting example of an application that makes use of the of SGX “in reverse”, to make it possible for a client to trust a server.
Integration is hard, that is well-known. For computer chip and system-on-chip design, integration has to be done pre-silicon in order to find integration issues early so that designs can be updated without expensive silicon re-spins. Such integration involves a lot of pieces and many cross-connections, and in order to do integration pre-silicon, we need a virtual platform.
IEEE Spectrum ran a short interview with Thomas Knoll, the creator of Photoshop, who made a very interesting point about the move to subscription-based software rather than one-time buys plus upgrades. His point is that if you are building based sold using the “upgrade model”, developers have to create features that cause users to upgrade. In his opinion, that means you have to focus on flashy features that demo well and catch people’s attention – but that likely do not actually help users in the end.