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!”
A few weeks ago, I talked about temporal decoupling in virtual platforms at DVCon Europe 2018. I just posted some additional notes on the topic temporal decoupling on my Intel blog. In this new blog post, I discuss some more aspects of temporal decoupling, and how it affects simulation semantics. I also explain some of the clever techniques used to minimize the impact of temporal decoupling on the software running on the virtual target system.
Read the full text at as “Additional Notes on Temporal Decoupling“.
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.
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.
During this year’s vacation trips, we sampled an unusual number of ice cream places around Sweden & Europe. Here are some notes on a few places we visited and where I took the time to actually take some photographs…
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.
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.
The Matias Quiet keyboard that I have been using for a couple of years recently gave up the ghost. The Enter key broke off and it seemed kind of unreliable in the USB department too – sometimes not activating when attached to a laptop, and sometimes just disappearing. I had got complaints about it being a little noisy still, despite being a lot quieter than a standard ALPS-style Matias keyboard. The replacement I got was a Corsair Strafe RGB Silent. I am rather fond of Corsair keyboards and mice, and this variant sounded promising.
Earlier this week, I attended a Google IO Extended event in Stockholm. It was really nice event organized by Google to extended the reach of Google IO across the globe and those of us who would not be able to attend live. The main event was watching the IO keynote live, but before it started we had some good team games (my team did so-so I must admit) and talks on WebRTC and real-time communications using standard web technology rather than custom plugins. Watching a keynote like this live in a theatre setting gives a different experience from just reading about it post-facto or watching it on your own where it is easy to be distracted (which is something that was addressed in the keynote…).
I work with virtual platforms and software simulation technology, and for us most simulation is done on standard servers, PCs, or latptops. Sometimes we connect up an FPGA prototype or emulator box to run some RTL, or maybe a real-world PCIe device, but most of the time a simulator is just another general-purpose computer with no special distinguishing properties. When connecting to the real world, it is simple standard things like Ethernet, serial ports, or USB.
There are other types of simulators in the world however – still based on computers running software, but running it somehow closer to the real world, and with actual physical connections to real hardware beyond basic Ethernet and USB. I saw a couple of nice examples of this at the Embedded World back in February, where full-height racks were basically “simulators”.
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.
Show like the Embedded World are full of vendors vying for attention and wanting to get their name onto your mind, desk, or appearance. This is the giveaway game: what can you hand out that will make people get a good and long-lasting impression of your company?
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.
I had the honor to have a scheduled talk at the Embedded World 2018 show in Nürnberg, right at the start of the show on Tuesday morning. Getting to Nürnberg for the Embedded World without paying a fortune for plane tickets is tricky due to all the other people flying down from Swedish embedded and tech firms at the same time. This year, I was lucky and I had managed to get a very convenient flight at a decent price. Leaving Stockholm in the afternoon around 14.00 on Monday, flying via Frankfurt and then on to Nürnberg, arriving in the early evening just in time for a nice Bavarian dinner. No stress, no late evenings on the U-Bahn into town. A good night’s sleep before getting up and getting to the show with plenty of time to set up for my talk. What could possibly go wrong?
I will be presenting an Exhibitor Forum talk at the Embedded World in Nürnberg next week, about how to get to Agile and small batches for embedded. Using simulation to get around the annoying hard aspect of hardware.
The USB standard has spawned quite a few connector variants over the year. Apart from the basic “A” connector (the one that you put in one way, then the other way, and finally the right way), there have been quite a few mini and micro variants of the “B” connector. Now, with “C” we seen to be approaching, finally, a reduction in the number. But it seems to me that there is a need for another variant…
There is a blog post out on my Intel Developer Zone blog where I take a look at the Gartner “Top Ten Tech Trends” for 2018. There are a couple of them where I found clear roles for the kinds of simulation tools we build in my little corner of Intel. In particular, Digital Twins is a concept that is all about simulation. To find the other trend where I found a big role for simulation, read the full blog post.
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”
I am an avid podcast listener, using podcasts as the main source of entertainment on my commute, when I go to gym, go shopping, cook at home, et cetera. In the past, I have used a long line of iPod nano devices to serve my listening needs (see my review of the 7th and final generation iPod Nano), downloading podcasts to a Windows PC and then syncing them over to the device. This worked well enough, and I kind of liked separating out the battery used for listening from the battery my phone used for calls and data traffic. But nothing lasts, and now that Apple killed off the iPods I had to find a replacement solution before my last iPod broke.
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
In a previous Intel blog post “Question: Does Software Actually Use New Instruction Sets?” I looked at the kinds of instructions used by few different Linux setups, and how each setup was affected by changing the type of the processor it was running on (comparing Nehalem to Skylake). As a follow-up to that post, I have now done the same for Microsoft* Windows* 10. In the blog post, I take a look at how Windows 10 behaves across processor generations, and how its behavior compares to Ubuntu* 16 (they are actually pretty similar in philosophy).