As a side note, a few years ago, I presented on efficient C programming for IAR Systems, guess that would have made Jack Ganssle happy: he complained about the lack of resource-constrained C programming skills in today’s university graduates in a column at Embedded.com recently. Apparently, the major market-driven education companies in the US have also dropped plain C programming from the course rosters… sounds like an opportunity or void to be filled by the embedded companies. Buy a C compiler, get a free efficient programming course.

Our talk will be on how approximate you can be in simulating multicore computers, and still get useful results out from the software running on the simulator. It is something that we at Virtutech have spent a lot of time working on, and we want to bring our results to a wider community. Really exciting to present, and it is a pity that I could not be there myself.

Any case, the panel said the following, including feedback from the audience (including the author of this post):

• Gary Smith laid out some data indicating that software is overtaking hardware as the main effort even for the core SoC designers for multicore. Today, some 50% is software, by 2012, 75% of the design cost will be software.
• Rudy lamented the difficulty of doing anything with regular unrestrained C code, and
  described some IMEC research where they restrict down C to make it palatable. Probably related to their work on “2D” VLIW architectures. Their “clean C” can easily be analyzed and create statically scheduled code (my interpretation) that runs well without caches and cache coherency. The audience asked how you could actually write a program without using pointers… good point. I think it can work nicely for data crunching, but fails horribly for control-oriented and dynamic codes.
• Grant made the point that there is no need to panic. Today, we can see people actually building successful multicore systems with today’s tools. It is a bit of muddling through, but it does get through. There is a lot of truth to that, but it misses the issue of converting or containing all legacy code that has a hard time moving from a single to multiple processors.
• Grant also said that the applications he had seen the most success with where those typically called “embarrassingly parallel”. But why should anyone be embarrassed that they have such nice problems? There is nothing to be embarrassed about, rather you should be proud of having such a nice system/algorithm.
• Simon Davidmann echoed my favorite theme that simulation is a key tool to develop software for multicore, as it gives you insight and control.
• When asked about hardware debug support, Simon was downright negative and wanted it all in simulation. Grant said that the proper solution was a mix of hardware debug and software simulators, which I agree with (see http://jakob.engbloms.se/archives/17 for some more thinking on this topic).
• Someone pointed out that hardware debug is sometimes taken out of volume chips and is only used in development versions — apparently, that is common in automotive, as the cost of each shipping chip is of utmost importance. Less practical for larger machines, though, where you cannot easily build a development version of your rack/router/switch/server…
• When asked about how to handle billions of lines of legacy code in a mix of C, C++, Java, and other languages, Rudy sounded downright exasperated. He seemed to be most comfortable with expressing algorithms and mapping them down to hardware using tools, rather than trying to deal with managing a zoo of legacy code… that is what I mean with the data-plane/data-crunching mindset of this panel.

Overall, an interesting panel, but a bit disappointing in the lack of large-scale software thinking. Would have been nice to mix in someone with an HPC, server, or large-scale control-plane embedded-systems background in the panel.

See you there!