The area of virtualization is one that I would definitely have looked at as an opportunity had I started out as a PhD student today. The work of his group is a good example of how Simics is being used for research and teaching in universities around the world.

Going one level up in abstraction, I note that this is probably the first time I have published an actual interview. I have been active in writing things since high school, but it has pretty much always been direct writing, not interviewing.  However, I really hope that this is not the last. Having a series of user interviews on the Wind River blog could be really neat, as a way to dive deeply into some particular areas of technology. Will be interesting to see if any other university user is interested in being featured.

VirtualBox is able to give a guest OS up to 32 virtual processors for its use. The system virtualizes cores so that you can allocate more cores than you have on your host. You don’t want more active cores than you have physically, or performance might suffer badly (there is a good blog post hosted by blogs.sun.com about VirtualBox 3 and its SMP support, read it before Oracle decides to kill off all the old content…).

Second, the development of that SMP support only took some six months. But getting it to work right took 18 months. Sounds like a familiar story for parallelizing software of this kind. The interviewees made it sound like the code for this was utterly complex, and I can believe that too.

VirtualBox makes extensive use of hardware virtualization support on x86 hosts to enhance performance (Intel VT-X and AMD AMD-V). As they see it, all other alternatives are inferior, including the VmWare tradition of binary translation and patching. They claimed that VmWare actually interpreted all of the code in a guest, but I find that a bit hard to believe.

It is interesting to compare their approach to something like Simics, which was made parallel in the Spring of 2008 with Simics 4.0 Acclerator. The advantage an IT run-time virtual machine like VirtualBox has over a virtual platform like Simics in creating a parallel system is that they can make use of the cache coherence on the host to propagate information between the cores. A virtual platform cannot assume that the host and target are of the same type, which is necessary for this to make sense. It also makes VirtualBox entirely nondeterministic, but that is just plain normal for a physical computer system. One interesting intermediate form here is the IBM CECsim system, where a z-series mainframe is used to simulate a slightly different z-series mainframe, including running multiple simulated processors in parallel. CECsim also makes use of the hardware cache coherence and is nondeterministic.

David Patterson’s article is very similar in its message to what we used to hear five years ago as everyone woke up and panicked when single-core computing ran out of steam. Chris Nicols is extrapolating from the current state in desktop PCs, and asking how the programs we run today will work when you have scores of cores rather than two or four.

The main message in both articles is that software needs to adapt to multicore, and that this is not happening as quickly as it needs to. It is clear that automatic parallelization of existing code is a no-starter, and the Computer World article proposes the use of domain-specific languages (which I agree is a very good way to go). David Patterson is less clear on what he thinks is a good programming model for multicore, leaving that as an open problem. Patterson does point out that we have quite a few success stories in parallel computing. I think it is important to not underestimate the set of problems which are amenable to parallelization. In particular, in the embedded field, we have many naturally parallel problem domains. For example, networking offers abundant parallelism as many clients, servers, and data streams are active.

However, both articles also miss some of the things which are happening to make multicore easier to use, especially in embedded. My favorite example of a technology that nobody seems to talk about outside of the embedded field is the hypervisor. With an hypervisor (such as the Wind River Hypervisor), you can take existing distributed systems and consolidate them onto a single multicore device, continuing a long tradition of multiple-processor programming in embedded. Also, the hardware-based debug tools which are available for embedded systems – including multicore – do not seem to register at all with the mainstream researchers. It is really a shame, and hopefully we can start to change that with conferences like the S4D where we start to bring  industrial debugging experience to the academic community.

Another aspect which is missing from both articles is any discussion about the debug and test of parallel software. Coding a parallel program is one thing, making sure it works is quite another. I think this is an interesting problem in its own right, as exposing parallel bugs is often just as hard as writing the buggy code to begin with. Wind River Simics is a tool that can be used to really stress multicore software, thanks to its ability to vary configuration parameters and inject some extra delays into the target system. Simics is also a very good tool for debugging multicore software thanks to its controlled deterministic execution environment. I have already discussed this in a Wind River blog post, and I will not repeat the argument here.

Post scriptum: setting some facts straight

I want to quickly correct some factual mistakes in the Computer World article: the processor power wall at 130W that he discusses is often much lower in embedded systems – a mobile phone drawing 130W would not be very popular, and in networking infrastructure, the magic limit today seems to be around 30W. So it all depends, and the Itanium example is totally irrelevant. In certain mainframe computers, the limit is higher than that. The same is true for the claimed upper possible clock speed limit at 4 GHz. This has been surpassed by several companies, most notably by IBM who clocked the Power6 to 4.7 GHz a few years ago. However, he is right that we will see cores multiplying in almost all systems as single cores run out of speed increases.

As Jack Ganssle said, us embedded folks get no respect.

Here is a list of some of the ideas I have seen floating around:

• They are going to put Windows 7 on ARM to defend against Linux in the sub-netbook segment. Certainly a useful move – but do you need an architecture license for that? It would not make much sense to put Windows on ARM in a way that requires you to have a Microsoft-designed processor core to run it.
• It is a case of Apple “A4″ envy – if Apple can build their own custom ARM chip for a consumer devices in the tablet space, so can Microsoft. I think this makes a lot of sense. But once again, what use is a license to design your own ARM core and ARM instructions? Apple does not seem to have created a custom processor core, instead using a standard ARM Cortex-A8 core in the A4 chip as far as I understand.
• Handheld gaming, building their own phone. It is essentially the A4 envy argument, and I cannot see how an architecture license will help.
• Deeply embedded devices. Microsoft wants to ride the ARM wave into things like power meters and other truly embedded systems. Once again, that might certainly be a good idea – but why an architecture license?
• As a defensive move in the Microsoft-Intel relationship. If Intel is toying with Linux, Microsoft can be toying with ARM. In that context, a few million dollars to acquire a license to do nothing much with it might make sense as negotiation leverage.

The best idea I think is the server angle. ARM is making inroads into servers where single-thread processor speed is not that important. The power consumption advantage over x86 is significant, as long as you do not need utter speed or very many cores sharing memory.

Power-efficient servers is an area where Microsoft can certainly see the potential for truly revolutionary changes in the IT field. There is no reason why x86 would be the best architecture there, and the fact that x86 is controlled by Intel and AMD makes it very hard for Microsoft to really take part in hardware-software innovation. Essentially, Intel and AMD design the processors, and the software has to adapt. This model is not optimal if you want to really see what you can do with the hardware-software boundary.

Thus, if I think Microsoft might do with the ARM license is to start tinker with the OS interface of the hardware. The beneficiary would be both Microsoft and ARM, since Microsoft innovations for ARM might well become standard in ARM land. For example, an OS might benefit tremendously from small changes in the processor in areas like:

• Memory management – a hardware scheme tailored to what Microsoft sees being done in their operating systems and their third-party server software could certainly be very beneficial to efficiency.
• Multicore and multithreading – ARM has some special support in their MPCore designs for communicating between cores in a multicore system. Such support could be extended to help the OS manage both threads and processors across multicore designs. Also, ARM might want some help from Microsoft to design a scalable OS interface that works for tens or hundreds of tightly-coupled cores (rather than the current limit of 4 in ARM Cortex-A9 MP).
• More bits – the biggest architectural problem I see with ARM in servers is that ARM is currently a 32-bit architecture. 32 bits are not enough for even medium servers today. Having Microsoft help ARM design a 64-bit version of the ARM architecture sounds far-fetched, but it is certainly something where a license to change the ARM instruction set would help.
• ARM instruction set additions to help build an emulator for x86 instructions on ARM, to allow current x86-Windows applications to run on an ARM-based device. This is an idea which has been tried in the past and which has never been very successful in the market. ARM currently has a set of instructions which help accelerate virtual machines such as .net and JVM, and I think that is as far as this idea has been proven useful.

In summary, the only reasonable use I can see that Microsoft would make of a license to build custom ARM processor cores and tweak instruction sets would be to build better servers, by improving multicore communications mechanisms, upping ARM to 64 bits, tweaking the MMU design, and possibly creating some kind of x86 emulation support.

That said, I think the most likely result is a custom ARM-based chip to power a phone or tablet or other consumer electronics device, running a Microsoft software stack (derived from Win CE/Windows Phone) on Microsoft hardware, all sold as a Microsoft product. Essentially, doing the Apple all-integrated solution.

There are two important aspects to this worm, as I see it.

First, it only works due to the fact that the software in question is running on regular Windows PCs.  An attack on a real embedded OS like Wind River VxWorks or Enea OSE would be more interesting, and much scarier since that would mean a much more devoted enemy. In this case, the attackers are opportunistic, using the window of vulnerability of a new Windows flaw to attack Windows-based plant control systems. They also use signed Windows drivers, which is apparently a new development in malware. All quite interesting in its own right, and worth reading about for those interested in security.

Second, the malware spreads using physical movement of USB memory sticks rather than attacks over the Internet or other networks. This makes the very important point that even if systems are not connected to the Internet, they can still be attacked if something crosses the “air gap” that separates them from the outside world. In this case, a plant would be infected by using social engineering to make some employee carry an infected USB stick into the plant and putting it into some internal PC. Once the infection is inside the plant, it might spread over networks or by USB sticks moving around inside the presumably protected perimeter.

The lesson I think we can draw from this is that using general-purpose desktop operating systems for critical systems is a bad idea. Using a more obscure real-time OS (or even Linux) would probably reduce the number of vulnerabilities – but more importantly, it would make it much more difficult to make an infection hop from computer to computer until it reaches its target.

In this particular case, all Windows machines are potential bearers and spreaders of the infection. An attacker can rely on that fact to seed the Windows ecosystems at some place, hoping to get the infection hopping from machine to machine until it reaches something interesting. There is no real need to seed the infection directly into the target plant. If the target systems had been running a different OS, the attackers would have had to get really close to the target, making them easier to stop.

Overall, embedded systems security is something that we need to take much more seriously going forward. As we rely on embedded control systems to run much of the modern infrastructure and economy, we really need to be concerned about how to secure these systems. Security needs to be part of the architecture of embedded systems, including their operating systems (please make them as robust as possible), application designs, and networking systems. Unfortunately, current embedded technology tends to be designed to work, with little care for how they could be broken by an intentional attack. One scary example of this was provided in the SecurityNow podcast episode #251, where a listener shows how easy it could be to take remote control over a car due to carelessly designed fleet management units.

Updated information

I found some more in-depth information on the issue at Infoworld. It notes that the software that is attacked is vulnerable since all installations use the same password to login – changing it is likely to break it. That is totally ridiculous as a security solution, period.

We recently got ourselves an iPod Touch, to entertain our oldest child on long trips. It is a brilliant device in many ways, I can understand why people love their iPhones (even though I am very happy with the very different style of the Blackberry phone that I was given by my employer). However, I have found one weird behavior in the music player that leaves me wondering how it got through into the shipping product.

The issue appears in the Cover Flow presentation of music, when I have several songs from different albums – but these albums have the same name. That is most obvious in the case of albums called “Greatest Hits”. I have quite a few of those by various artists, and I have synched only a few select songs from a few of those onto the iPod. In this precise case, there are two songs by  Billy Idol, one by Robbie Williams, and two by Bruce Springsteen (revealing my boring music taste I guess…).

We start coverflow and find an album “Billy Idol” and “Greatest Hits”:

So far so good. Now touch it, and turn it around to see the songs in the album:

This is starting to look interesting. The two first songs make sense… but the three later ones are not by Billy Idol.  When I tapped the third song to play it, the display turned into play mode:

When I then turned the iPod back to landscape mode to see coverflow, things have changed in a strange way. We are still at the same position in the list of albums, but the artist and cover picture have changed to now depict Robbie Williams. Funny. This means that this album is out of sort order (as the sorting is clearly by artist name in this view).

Tapping that album to view the songs on it, we have a very confused display. The album artist is Robbie Williams. The songs are the same as in the first picture above. The small icon of the album cover is Billy Idol, though. Interesting.

To me, this looks like someone at Apple thinks that album names can be used as unique identifiers for certain tasks, such as displaying album covers in Cover Flow. How that fell through testing amazes me, but maybe it only happens if you synch partial albums? It once again shows how hard it is to imagine and test all the odd cases that might happen out in the real world once a product (hardware or software or a combination thereof) is given to real users.

Basically, they stopped working due to a problem with cooling (!). The roads around here tend to be salted in the Winter. The temperatures also often hover around freezing, with the result that you have roads covered in snow-water slush. This slush clogged up cooling fans for the motors and electronics which are located on the bottom of the cars, around the rear axle.

Putting fans on the bottom of a car where things from the road are quite likely to enter would seem totally silly in hindsight. The root cause is somewhat jokingly referred to as the cars being designed in sunny California. There is probably some truth to that, even though all big automakers make sure to cold-weather test their cars in places like Arvidsjaur. However, that is probably too cold to get much of the slush that caused the issue.

Another issue that has been much more publicized is the Apple iPhone 4 reception problems when holding the phone in certain ways. Also obvious when discovered, but not found in pre-launch testing. Some people speculate that this is due to too much secrecy at Apple preventing a shake-out test with many people using the phones every day in the way they would post-launch.

Once again we see that good testing and destructive creativity is needed during the development of products to make them truly great and avoid embarrassing “obvious” mistakes. Tesla and Apple have great product designers and great products – but you seem to also need great testers to really build solid products.

Sounds like this is turning into a testers lament – and I must confess to never having worked as a professional tester, just as an accidental tester with a knack for breaking things.

Essentially, they are voxel graphic representations that must be very hard to plan and execute.  The standard single-stud 1×1 Lego brick is their smallest unit, or maybe its 1/3 height flat version. Here are some examples that I photographed in Legoland during my visit this Summer.

Airbus A380, close to the entrance:

If we look up close at the nose, we see the stepping of voxels very clearly:

The wing roots show how the wings are constructed:

I also really liked this Volvo XC90 that I found in one of the town displays. It uses a few more types of elements compared to the big Airbus. I am not so sure about the way they do the windows, but maybe the murkiness is just due to its having been outdoors for a few years. It is interesting though that you immediately recognize this as a Volvo, which is a great testament to the Lego designers.

Another car is the Citroen found on the canalside in Amsterdam:

A typical example of the large-scale animals and people present all over Legoland:

Finally, a Danish flag in a very traditional Lego flat style:

The houses at Lalandia are all very new, the block where we stayed (the one furthest away from the central building) cannot be more than two years old. They have not finished the roads yet, nor are the lawns completely grown up.

Everything feels fresh and new, and you cannot complain about the standard of the houses.You have a fully equipped kitchen, as well as a dishwasher and a washing machine – families with children is clearly the target audience. You do need to bring some basic household supplies with you from home, there are no spices, washing powder, or dishwasher tables available in the houses. You have to pay for electricity and water in addition to the basic rent, which feels unnecessarily stingy as the basic rent is pretty high and the cost for utilities ends up being about one or two percent of the cost. I guess it is a way to steer people towards not wasting resources, though.

Lalandia is intended mainly for visitors who come by car. Each house has two parking spaces in front of it, and the idea is clearly that several families can share a house. The smallest houses are sufficient for four adults, we rented a six-person house (which worked well with five adults and two children), and there are also eight-person houses available in a few different styles. Since the place is next door to Billund Airport, you could also fly in, distances are short enough that you don’t really need a car during your stay anyway (you can literally walk from the airport terminal to Lalandia and Legoland). The airport does cause the occasional burst of noise as aircraft take off, but is was not really bothersome while we where there.

Since you are likely to cook most of your food yourself, you also need to go buy it somewhere. There is a somewhat pricey “supermarket” in the main building, which is almost impossible to avoid thanks to its convenient location and good opening hours. Shopping in downtown Billund is about ten minutes walk away, but this being a small town, shop hours are pretty poor, 9-18 or 9-19, shorter on Saturdays and closed (!) on Sundays. This was  a surprise for someone used to Swedish shop hours which tend to be 10-22 all days all weeks. Try to arrive on a weekday, or bring lots of supplies for the first day.

It also seems that Denmark is not quite as credit-card-friendly as other countries. If you use a foreign card, they charge you, the customer, the 2.5 to 3% charge that the credit card company charges the store. This is something I have only seen in very small shops living on tight margins in Sweden, and in the Netherlands. In everyday life, this never happens in Sweden or the US, or in most other countries. The fact that Denmark is outside the Eurozone makes some of these charges possible, since the tougher EU rules against card charges currently only applies to transactions in Euros. To be fair, Lalandia actually has lower credit card charges than other places in Billund.

I read a number of online reviews of Lalandia, and they tended to complain that Denmark is expensive. I can agree, it feels about 20-25% more expensive than Sweden, but it is not astronomical or any worse than downtown München or Paris or London.

Lalandia itself is really not about the houses or the food or credit card charges, though. It is a waterpark, and the hangar-like main building contains the Aquadome, biggest waterpark I have ever seen. It also holds a fairly camp indoor fake Mediterranean town square (with a roof painted like a blue sky), an indoors playground, a gym, and several restaurants (which we never tried). It reminds me of the plastic fake milieus in Disneyland Florida.

The Aquadome is just fantastic! It is claimed to be the biggest water park in Scandinavia, and I can certainly believe that. It is all indoors, except a small section on the outside that you can swim out to from the inside. It has the best water slides I have ever tried, all of which require you to use some form of craft to go down. They also all leave the building and come back in, making for a very dramatic ride. See the picture below for how the water slides protrude from the building. The biggest tube is a water slide where you ride four people at once, on a four-person rubber raft!

There were pools with activities suitable for children as small as one year, and all the way up to those who rather 40 than 4 years old.  Very impressive. You need several visits to explore all the options, and fortunately unlimited access is part of the package with the holiday homes.

It is annoying that they do not allow you to bring your own food inside. Since we have some allergies in the family, it is not that easy to find food that is safe, and we would much prefer to bring our own. Overall, you do get the feeling that they are trying a bit too hard to make you part with your money; it is a bit too aggressive to feel entirely right.

Legoland Denmark is right across the street from Lalandia’s main building, and I will write a separate blog post about that.

A final note is that the ownership structure of Lalandia is interesting. Each house is actually privately owned, and the Lalandia company is just a broker organizing the renting-out of the houses. The are still selling houses, and claim that the yearly cost with mortgages is no higher than the cost of renting for a week. It does look like quite a few Norwegians have taken up on the offer, judging from the large number of expensive cars from Norway we saw parked in front of something like half the houses.

]]> http://jakob.engbloms.se/archives/1162/feed 0 http://jakob.engbloms.se/archives/1159?&owa_from=feed&owa_sid= http://jakob.engbloms.se/archives/1159#comments Mon, 28 Jun 2010 19:08:00 +0000 Jakob http://jakob.engbloms.se/?p=1159 I have a blog post called “When is Scripting Really Programming” up at the Wind River blog network. In that post, I discuss how scripting is really not clearly separated from “real programming” in the way I once believed it was… today, the line between higher-level programming languages and scripting languages look very thin in many cases. I illustrate with examples from Simics and its CLI and Python scripting systems.

The call for papers for the third annual Swedish Workshop on Multicore Computing (MCC10) is now out! MCC is a nice venue for multicore research about everything from computer design to software and debug. It is fairly informal, but still attracts some good papers and provides good discussions. It is not restricted to Swedish submissions, in 2009 there were several international participants. I gave a keynote talk about multicore and Simics at last year’s MCC, and for this year, I am on the program committee and looking forward to many great submissions to review!

And almost inevitably, as you play around with a complex modern piece of software (which is what most of the phone is, after all), you find some obvious things which are just plain broken. You wonder, “why didn’t they think of this”, and “how could this ever escape testing?” My current best example is that the built-in web browser does not render the pages from Blackberry’s own support knowledgebase.

This is something that they have control over from both sides, so the only reasonable explanation is that they just have not thought to test that site with the browser. It seems strange that  a new user would uncover such holes after a few hours, when presumably thousands of planned and spontaneous testing hours are being spent at Blackberry on each device they release.

To be fair, this is not a showstopper for me, it is just a good example of how users tend to poke holes in all modern software products. Blackberry is not unique in this regard, and I fully admit that the software that I have worked on over the years did not always fulfill the requirement of being bulletproof. There is a classic saying that if you think something is foolproof, you just haven’t found the right fool yet.

So what is this telling us about software development? I think the main lesson is that you need people who just use your product and do so creatively, as part of the development process. Software developers usually lack the destructive imagination necessary to really poke holes in what they have created, and are usually not given time to develop elaborate test cases.

The moment you put code into the hands of users, you can expect them to find “obvious” issues in your product – simply because their “normal” use is something you yourself never dreamt could happen. In my example, I presume that Blackberry assumed that people will use the support forum when their phones don’t work – and therefore not surf to them from a phone. Sounds reasonable, until you press on a bit and ask if someone might not look at a friend’s broken phone out in the field and need to search support… or check for solutions to non-fatal errors.

I guess the key lesson for me, one which I apply in my daily work, is that product management, marketing, or testing, has to work through use cases with the software they create. Really work them through, and when sidetrack ideas appear, follow through on them, not ignore them to focus on the main task at hand. We have to combine features, and do more than what’s in typical tutorials.

Feature combination is especially powerful, I still recall the sense of “aha” I got when as a PhD student I talked to some colleagues researching the field of feature interaction. It sounds like quite an interesting field, even though I am not sure how you could formally capture something that will generate the test case “read our support site using the phone browser”…

This post used to end in “I guess this counts as a software development rant”. Now, I classify this as a “tester’s lament”…

The first movie is just the robot driving around using its MEPROM programming unit. I think this movie is slightly clearer than the old one I posted.

Next, here is how a program loop can be created in this system. By removing the white end marker from the program, the motor will just keep spinning the program until it spots a program step. This is a very mechanical infinite loop.

Finally, we have the emergency stop bumper that was added to the robot to make it stop when it hits something. It does not take effect immediately due to the latencies involved in the NXT programming environment, but at least the robot does not proceed to the next programming step.

Ever since Unix became the role model for operating systems, C has been the “base” language. In desktop operating systems like Windows and Linux the platform API is expressed as C function calls, and the ABI (the binary calling conventions) for linking code from different compilation units and binary distribution units is also expressed in terms of the code that a C compiler would generate. A C compiler is the first thing you need to get the platform going, and C is a language that allows arbitrary applications to be developed and run on the platform. The semantics of dynamically loadable and shared objects are expressed in C, not C++, as the C++ ABI is too variable.

This ubiquitousness of C has also proven to  be a key enabler for higher-level languages. C is the language of choice to implement the basic virtual machines used by languages and programming systems like Perl, Python, Erlang, and Java. C (or C++) is also used as the target language of many modeling tools with code generation, such as MatLab/Simulink, Rational Rose, Rhapsody, and Labview. A single generator of C code can be reused to target many platforms. Sometimes C++ is the generated language (in particular for UML-based object-oriented tools), but C++ essentially falls back on the ubiquitousness of C to be able to call platform APIs and connect to other tools.

That is the state of things as we know them today. What seems to be happening is that this is slowly being deprecated… platforms are coming out where user code might not be possible to write in C at all, or where C programs cannot access the real platform API. For these platforms, it is quite difficult  port in an existing C/C++ portable program.

The first example is Google’s mobile phone operating system Android,where  Java was the only supported language at launch. Google have since made it possible to use C and C++ for some parts of an application, but it does not seem to be a full platform API allowing a whole program to be written only in C or C++:

“The NDK will not benefit most applications. As a developer, you will need to balance its benefits against its drawbacks; notably, using native code does not result in an automatic performance increase, but does always increase application complexity,” the documentation says. “Typical good candidates for the NDK are self-contained, CPU-intensive operations that don’t allocate much memory, such as signal processing, physics simulation, and so on.”

To port an application written in C/C++ such as Firefox to the Android platform, the app has to be modified to work as a backend to the Java interface.  ArsTechnica has a write-up on how Firefox was brought to Android through just such a modification. Note that this does mean that ports are not as straight-forward as they would be to other platforms with a directly accesible C API. Interestingly, the Android approach essentially inverts the traditional relationship between C and other languages, where it was common to have a C adapter layer around other languages (like Java) in order to access the platform.

Note that the NDK quote does not mention language run-times. One of my favorite languages, Python, has had to be completely reimplented to run on Android. Either using a “Jython” approach of compiling Python to Java byte codes, or using the Android Scripting Environment.

Other languages that you would ordinarily just port using a simple recompile of the its C code base are not helped by this at all. One interesting example is the Erlang runtime, which is basis for CouchDB. According to an interview on FLOSS weekly show 99, about Ubuntu One, this fact prevents Ubuntu One from synching data from your desktop to your phone.  This demonstrates that the assumption that you can run a C program on “any Unix-like system” is no longer true for a large numbers of smartphones… and that is already affecting how you have to develop products.

Microsoft is also moving in the “no C for you” direction with Windows Mobile 7, where C# is the default language. This also prevents easy reuse of existing C programs on smartphones. Ars Technica notes how this killed Firefox on Microsoft-based mobiles.

Finally, we have Apples downright weird approach to languages and programming. Their recent banning of anything except Objective C and their own compilers for iPhones (and iPods and iPads) is downright bizarre. They explicitly forbid code-generating tools to be used with their platform, as well as kicking out any alternative language runtimes (which is a move aimed at Adobe Flash that also hits Erlang, Python, et al.). This might make some sense from a security perspective, as it prevents programs from loading executable code at run-time on the phone… but it also makes for a much more restricted set of programming tools.

The only mobile platform that seems honest to old traditions is really Nokia’s Maemo. And Symbian. Suddenly, what used to be considered “closed” platforms have become the most open and most desktop-like of all the mobile operating systems. Really, that is a very important reason to get a Nokia N900 rather than an Android or Apple device.

I think this points to a somewhat more complicated future, where mobile applications will cannot be cross-platform, as you have to use Android-Java, Windows-C#, iPhone-ObjC, and Maemo-C/C++/anything to code. It could also point to a move even in the desktop and server space away from C and to more sandboxed, controlled, and not-as-common programming platforms. That would be really bad from a programmer productivity and language innovation perspective, as so much of the innovations today are actually based on the ubiquitousness of C and the use of C as a good implementation language and code-generation target language.

Updates and clarifications

Given the comments below, it seems that I need to make some things clearer…

First, the iPhone. It is really a special case, in that you do have C/objective-C access to the API. So in principle, you could port any C program including language virtual machines to the iPhone. Firefox, for example, would work. However, Apple for commercial (and maybe security) reasons does not allow programs that implement virtual machines to be distributed across their controlled application store. That you can implement a VM there does not really help you, as it is the first openly programmable platform that I have seen where a control body actually forbids certain classes of programs. The Apple approach is apparently even more idiotic than I first believed.  According to some more reports I read and heard, they do not enforce a technical limitation on the final program (such as running in a JVM or .net VM), but rather require all software to be originally and directly written in C, C#, or C++.  All just a swipe at Adobe and flash… so even Flash compiled to native code is disallowed.  And with it goes all other higher-level languages.

Second, on security. I do think that running programs on top of a VM like done with Java and .net does have security benefits. It gives you a level of indirection which can be used to check what applications does. Obviously not perfect since there will always be bugs and mistakes, but still it is a better architecture than raw access to the underlying machine. The  iPhone controlled mode of distribution could also be beneficial here. The SecurityNow podcast episode 245 discusses this topic.

Third, on appropriate programming languages for different tasks. I totally agree with some comments that C is not a very nice language for GUI programming. No doubt about that. However, that was not really the point I was trying to make. I want to use higher level languages! But not having C available might make that harder and with limited choice… leading up to point four.

Fourth, my core point. Having platform-level access in C is a basic technology used today to implement the higher-level environments. Languages like Python, Perl, Erlang, Lua, and even the basic Java and .net virtual machines, all depend on having C available to bootstrap the process of getting the core virtual machine going. If we take this away, we limit choice in language and might stifle innovation, as well as the attractiveness of cross-platform environments.

Fifth, I agree with the comments C is definitely not going anywhere in terms of being used to develop operating systems and embedded systems (that’s where I spend most of my time, by the way). My observation is about what is happening to user-level programming for certain systems, not the systems programming which is intentionally made separate from user-level programming.

Another Update:

The Inquirer just pointed out that Apple is explicitly forbidding interpreters to run on their phones, unless it is an interpreter they created or one explicitly allowed. That’s making the above very clear, Apple is consciously denying iPhone users all modern programming languages. And that’s just to make sure Adobe can’t weasel Flash in there. Politics sometimes make no sense at all. The Inq quote is worth quoting:

Famously, when Apple released its iPhone SDK in spring of 2008, the end user licensing agreement barred applications from downloading and running any interpreted code. “No interpreted code may be downloaded or used in an Application except for code that is interpreted and run by Apple’s Documented APIs and built-in interpreter(s),” it said.

For those unfamiliar with the Stretch machine, it was a supercomputer developed by IBM which introduced many of the performance techniques and basic computer technologies that we all use today (most of them handed down to us via the IBM System/360). For example, it was the first to use 8-bit bytes and 64-bit floating point. It also introduced memory protection, memory interleaving, and instruction prefetching.

More relevant for my blog is the fact that the Stretch used the world’s first pipelined main processor, complete with interlocks to maintain program-order semantics. When developing this pipeline, Frederick Brooks claims that IBM developed a program to simulate the pipeline. This simulator was used to test the performance of the pipeline design on various test programs (this was before they were called benchmarks), and tune the design accordingly. The simulator was created by Harwood Kolsky. There is no firm date for the pipeline simulator, but based on the development time of the Stretch, it can be dated somewhere around 1960.

Thus, the simulation-driven approach to computer architecture is about 50 years old by now. Should have gone to ISCA and used this as an excuse for a party I guess…

It is also interesting to note that the Stretch computer acquired a co-processor in 1962, to do cryptology work. This machine was the one-off IBM 7950 “Harvest” and was tailored for the needs of the NSA in the US. It was a seriously special-purpose hardware unit adding a few instructions to the Stretch machine, and beating any other machine at the time by about 50 to 200 on the particular NSA workloads.  Sounds like the kind of performance claims that Tensilica and other application-customized processors claim. 50 years ago.

I think it is important for users of technologically advanced tools to know a bit of how they work. A classic example of this is compilers, where I taught an ESC class almost a decade ago which is my most popular piece of writing to date…