We recently had a malfunction in our spam filters at work, so I had to go back and review the catch for possible false positives. I sort things into two bins using spamassassin, one for most likely spam, and one for probable spam. When things started to go bad, the most likely folder had reached more than 2 GB, and the probable some 500 MB.
In his most recent Embedded Bridge Newsletter, Gary Stringham describes a solution to a common read-modify-write race-condition hazard on device registers accessed by multiple software units in parallel. Some of the solutions are really neat!
I have seen the “write 1 clears” solution before in real hardware, but I was not aware of the other two variants. The idea of having a “write mask” in one half of a 32-bit word is really clever.
However, this got me thinking about what the fundamental issue here really is.
An embedded researcher friend of mine has posted some data on code sizes from various compilers at http://embed.cs.utah.edu/embarrassing/. The “embarrassing” bit is the idea that compiler writes should be ashamed when other compilers do better than theirs. It is worth looking over the data, even though the methodology and benchmarks are not yet perfect by any means.
Last week, I finally got the last “OK” from the maintainers of GDB, the Gnu Debugger, indicating that my contribution to the GDB project was accepted. This is my first contribution to an open-source project, and the piece of code that has my name on it is positively puny. It is actually not really code at all, it is just a piece of documentation, for the extensions to the GDB-MI command set needed to support reversible debugging. The actual code doing the work was contributed by a colleague of mine, Tomas Holmberg, credit where credit is due.
I just won a battle against Eclipse, managing to finally rid myself of a string of strange out-of-heap warnings. It is a long story, involving lots of web searching and fiddling with the eclipse.ini file options for the JVM. It just never seemed to work as I wanted it to, despite changing the -Xmx VM argument to 256, then 512, and finally 1024m.
For my parental leave, I have just bought myself a Lego Mindstorm NXT 2.0 kit. It is not much fun for our youngest, who mostly gets a bit scared by a piece of Lego driving around making noises, but I hope to be able to use it to teach my older child (almost five) to program. Let’s see how that turns out. It looks hard to make the NXT environment provide the kind of Roborally-style programming blocks that I had hoped to create, as I cannot for some reason get a sufficiently custom icon onto custom blocks.
It also presented me with an opportunity to try some domain-specific high-level graphical programming. The programming environment provided for the NXT series of Mindstorms kits is based on LabView from National Instruments, and it really does seem to work. It even features parallel tasks, which I tried to use…
For the next few months, I will be on parental leave, so there is likely to be less blogging about technical subjects (and less blogging overall). There is simply less inspiration about virtual platforms, and a bit more about toys.
During the Christmas holidays, I got the chance to compare my oldest child’s brand new Lego set with some from the mid-1980s. It is quite striking how much larger the things in the sets have become, and how much more affordable (in relative terms) Lego has become since then.
We bought some ski goggles for our kids… and look who have infiltrated that business:
Continuing on my series of posts about checkpointing in virtual platforms (see previous posts Simics, Cadence, our FDL paper), I have finally found a decent description of how CoWare does things for SystemC. It is pretty much the same approach as that taken by Cadence, in that it uses full stores a complete process state to disk, and uses special callbacks to handle the connection to open files and similar local resources on a system. The approach is described in a paper called “A Checkpoint/Restore Framework for SystemC-Based Virtual Platforms”, by Stefan Kraemer and Reiner Leupers of RWTH Aachen, and Dietmar Petras, and Thomas Philipp of CoWare, published at the International Symposium on System-on-Chip, in Tampere, Finland, in October of 2009.
I just listened to the November 16, 2009, issue of the BBC podcast called “Peter Day’s World of Business“. It is a rerun (in memoriam) of an interview with business professor Russell Ackoff, which was originally published in 2007.
It is the end of the road for SAAB. As a Swede, it feels sad (and a bit scary) to see a part of our industrial heritage go down and end. It lasted a bit more than 60 years, but now the manufacturing of cars called SAAB has ended for good. But to be quite honest, it is hard to see how things could have gone differently. The closing of SAAB cars must have been considered inevitable for the past ten years or more. There will be lots of finger-pointing in the coming weeks, with the opposition parties trying to smear this on the government. However, I don’t see what the government could have done other than possibly postpone the inevitable.
For some reason (I guess it is the job…) I was browsing through the Power ISA version 2.06 specification last week and hit the following gem of an instruction: “rvwinkle“. It is named after a short story I had never heard about, but which apparently is sufficiently well-known in the US literary canon to warrant a sleep mode being named after it.
Read more…
The presentations from the 2009 Swedish Workshop on Multicore Computing (MCC 2009) are now online at the program page for the workshop. Let me add some comments on the workshop per se.
This post is a belated comment on the FDL 2009 conference that I attended some months ago. I have had some things in mind for a while, but some recent podcast listening has brought the issues to front again. What has been striking is the extent to which FDL was about languages only to a very small degree. Compared to programming-language conferences like PLDI, there was precious little innovation going on in input languages, and very little concern for the programming aspects of virtual platform design and hardware modeling.
