His experience is just like mine: programmers create the tools they need to solve a problem, and over time, certain useful point solutions get generalized and suddenly appear as full-blown or semi-full-blown languages. He traces the interesting case of the UNIX “adb” debugger “macro language” from its beginnings as list of very simple operations in the PDP “odt” debugger (octal address plus single-character operator) to something that was used to encode quite complex OS kernel inspection operations in Solaris. And how he found it necessary to provide an implementation of the adb macros for the mdb debugger created for the Solaris 64-bit port. Good tools just won’t die…

Another point that I had missed but that really shows the prevalence of domain-specific languages in highly complex systems and advanced development practice is that Solaris 10 shipped with a few new languages added. The “D” language used for dTrace is the best-known example, but there were a few other ones as well… It sounds like the point I made at a DATE 2008 panel debate (last year, missed this year due to conflicts with other duties in my life) where I took issue with the idea that “embedded software is written in C or C++” and said that “any real system contains at least 10 different languages” and that “there is a zoo in there”.

The last important point, I think, made in the article is the common design pattern of taking the expression syntax of an existing language and use that as the core of a domain-specific language. C is especially popular for this, since it also makes compiling simple: just generate a C-language program containing the snippets of C expressions in your language (the yacc model). It also avoid reinventing the wheel…

So overall, I found this article a very interesting read, not the least thanks to its long historical view of language design and tools.

Finding information on this card was very hard, and here is the best that I could find:

With front and back LEDs and a removable system configuration card, the Sun Fire V120 server maximizes system availability by allowing system administrators to concentrate on scheduled service through easy installation and management. The removable system configuration card allows you to store a system’s host ID, MAC address, and NVRAM settings to another server while you perform routine maintenance. As a result, system downtime is minimized.

Why I find this interesting is that it is also a nod to commercial software companies relying on hostids for licensing. In this way, you can maintain the same hostid even when a server has issues, and without compromising the integrity of licensing. Sun’s hostids are unusually safe and reliable, unlike the common x86 anchors like Ethernet MAC addresses (which are easy to change) and disk IDs (which are not available on Linux typically).

Making the ID physical in this way is usually the best way to handle identity in general. A GSM/UMTS SIM card is another example of a physically represented identity, which is way preferable to virtual identies that are just software. Much easier to handle, and safer for all involved.

The themes are:

• The way there is to provide programming environments that express algorithms in a way that is clear in terms on intent but that does not constrain the implementation too much. It should hide parallelism to the user, and make that a property of the compiler and implementation, not the program. But to make this work, you need higher-level expressivity. For example, Kunle says that you want to say “do a matrix multiply” rather than “here is a pile of loops and expressioins implementing a matrix multiply”. Very sensible.
• The proper way to do parallel programming this is to be domain-specific. Create domain-specific languages that map to how domain experts think about a problem, and then have a compiler and runtime take care of how to implement it for a particular machine. Rather than provide a low-level language that lets you express parallelism explicitly, like CUDA, Brook, threading libraries, etc, you should be using MatLab if you are doing science (which is something that National Instruments have been doing with their LabView tools).
• Future hardware will be heterogeneous, with a mix of control-oriented simple cores (Niagara-style), data-processing-oriented cores (DSPs, security accelerators, etc.), and the occasional heavy-weight ILP-oriented core (Intel Core 2-style) for the occasional program that just needs maximal single-thread performance.
• Operating systems today were created in an era where processors were precious resources that had to be efficiently shared. This is no longer really the case, it makes sense to dedicate single cores to single tasks for extended periods of time, as this maximizes efficiency. There are cores to spare, no problem on that accord. Nice to hear this from a general-purpose proponent, and not just embedded people.

I fully agree with all of these, and I find the use of domain-specific languages and frameworks especially important. Software people in all ages have become more efficient by designing better languages, more suited for a particular task than a very general language. A language is a just a tool, after all, not a religion (even if some people seem to view it that way), and should be changed depending on the task at hand.

Final note for us embedded folks: when Kunle talks about how he realized around 1995 that lots of simple processors on a chip becoming feasible thanks to Moore’s law, the first real multicore chips were already shipping. Motorola had the QUICC 68000+CPM heterogeneous network processors on the market by then, and Texas Instruments had the C80 four-simple-DSPs-plus-a-simple-RISC multicore chip for digital video also out. But the ISCA crowd really did not notice this development at all, at the time.

Obscure note two: Virtutech Simics was actually used by Afara to help in the design work of the Niagara, since Simics had very good support for 64-bit SPARC architectures thanks to the early work done with Sun.

• How Transmeta pointed Intel and the industry into the right direction of lower power computing.
• How multicore processing in the mainstream world (not embedded) can be seen as a way to keep the size of processor dies up in order to keep up prices of processors and keep all the fabs busy. For someone like an Intel, if they cannot add new complexity to their processor cores (which is practically the case today in David’s opinion), they would be stuck making processors half the size with each process generation. And pretty soon they would only need one fab to push out all the processors the world would ever need. So by using multicore, they can fill all the space they have in their fabs, space that has to be filled to keep the economic engine of Intel running. They need to keep making things more complex and to keep the die size about the same in each generation.
• How Sun did business in the old 68k days, and how they are now doing business in x86 land.
• The Elbrus company that Sun acquired, who had a pretty innovative VLIW design, and whose leading lights are now at Intel after a tour through Sun and Transmeta.
• The coming-back of accelerators even in server/desktop computing. David has a take on the Sun Niagara design as a potential accelerator for web work, running alongside a Rock processor in the same chassis. And talks about rumored IBM work to the same effect, using a massively threaded Power Architecture design as an accelerator for certain types of jobs together with the main Power6 processor in a pSeries server. This is another argument in my ongoing homogeneous vs heterogeneous argument.

So it is both history, computer architecture, and business history and assessment all in one. As I said, highly recommended!

The Rock is a very interesting piece of work. It tries to be both a throughput-oriented design like the Niagara/Ultrasparc T machines, and a single-thread high-performance design. Even though on balance, it is more skewed towards the throughput computing aspect. What is very cool is how they use additional threads to help boost the performance of a main thread using “scout threads” (a concept I saw presented back at ISCA 2004). This makes it possible to use threads to either boost single-thread performance OR do throughput, creating a more flexible design than is usually the case. It is also the first commercial implementation of transactional memory. And 16-way. And due for next year.

So far, Rock seems like a very successful and very visionary project that is trying in yet another way to gain momentum by pure hardware innovation. Just like the UltraSparc T line, Sun is trying to out-invent IBM and Intel/AMD. Who seem to be mostly progressing by just piling on more of the same old features. I really hope this play goes well, if we were down to just IBM/PPC & System Z and Intel-AMD/x86-64 on the server and desktop side, the world would just be too boring.

The Intel and IBM talks on programming were both grounded in the idea that to make people accept a new programming language/API, it has to be an evolution of what the programmers already know. Which pretty much ties us down to C/C++/Java/C# with extensions and modified semantics.

X10 is basically Java with some nicely considered features to support local and global memories and programs that can scale to BlueGene-style massively clustered machines. Tim basically tells everyone to stop inventing new languages and focus on improving existing frameworks like MPI and OpenMP in collaboration with industry. Presented in a very funny style, Tim is a great presenter, and tries hard to get the audience to react. In this crowd, most people agreed. Except the Erlang people, who feel that they do have a better solution to multithreading and multicore than any patched-up language in the C-Java family. I must agree with them, and I do feel that Erlang today is mature enough to serve that purpose.

The panel session at the end was very entertaining, where some people (including myself and Joe Armstrong) tried to ask tough questions to the keynote speakers (and Ulf Wiger of Ericsson). Quite engaging and a rare chance to directly engage with some industry heavyweights who otherwise tend to sit on the other side of the Atlantic.

I think the prize for coolest tech of the day goes to QuviQ, a spin-off from Chalmers doing automated testing tools that really work well for parallel and distributed systems. Their method of minimizing the trace of a failed test case is really interesting, and finds things that no human tester would ever find.

I also presented a talk on “Debugging Multicore Software using Virtual Hardware”, in the breakout sessions. I guess our Tools track was the least visited of the three tracks, but the audience asked some good questions. And there were some good discussions afterwards.

However, to summarize the day, I am a bit disappointed that not more is being done on the hardware side to help people debug their multicore and multiprocessor parallel programs. Transactional memory is all nice and dandy and can help simplify low-level locking primitives for threaded programs. But I would like to see much more in terms of smart tracing, hardware breakpoints and triggers, massive synchronized stops, and similar features. And instructions and features that make parallel expressions simpler. Here, the embedded folks doing things like ARM CoreSight seems to have been much more successful than the server-class designers at Sun, Intel, and IBM. But even ARM do not spend more than 10-15% of the chip area on debug support.

I think it would be interesting to see what would happen if you could spend 25-30% of the chip on some seriously powerful debug features. Full support for remote control of all cores at the same time, lots of bandwidth for debug data and commands, and fat traces of all traffic on and off the chip. Performance and event counters everywhere. That would make the peak performance of chip likely less than a competing chip not spending as much space on debug support — but it would make achieving a high utilization much easier, and that might actually make the debug-intense chip more economical. Would be interesting to try. But I guess nobody would dare to buy such a design.

But I guess this is just the latest instance in a long string of flying pig events that has happened in the past few years in the technology industry.

Apple switching to Intel-provided x86 processors also felt way out.

Microsoft using Power architecture processors in the Xbox 360 was also just to weird to imagine.

I guess Sun selling x86-based servers was also in the same league.

But all these things did happen. And that probably means something. Question is what.

I hope and guess that it could be business sense winning out over technology inertia. And technology becoming good enough that inertia is going down. In retrospect, all these technology decisions make sense. The end products are better in some significant way. Factors involved are performance, price, power consumption, software available, scalability, or just standards agreement. Not-invented-here and the tyranny of the legacy seems to be reduced powers in the industry. Or it just means that companies have changed their idea on what their core business and value is. If it is all about branding, it does not matter what is inside the box called Apple, Sun, IBM, or Microsoft. As long as it works.

So I would expect more flying pig events in the future. But I have none to predict currently. It is going to be an exciting and surprising time.