Case Studies: Assembly Language in the Real World

These days Simon Long is a Senior Principal Software Engineer at Raspberry Pi, but in the past he worked in contract research and development and sometimes found himself having to work with assembly language. Here are a couple of incidents that stuck in his mind:

Speed-up

For one project I was working on a rebar scanner which used a magnetic sensor to detect and graphically display the depths and widths of steel bars embedded in reinforced concrete. In one mode the scanner could be rolled along a wall and the display would show a diagram of the positions of the bars within that part of the wall. This was originally designed to be used on relatively small 5 metre sections of wall – however, the engineers using it wanted to be able to attach it to a vehicle and drive along a much longer tunnel, 50 to 100 metres long, mapping out all the rebars in one go. This meant that the algorithm used to convert the raw sensor data into the diagram of the wall had to deal with much more data, and still give a result in just a few seconds.One way that I hoped to achieve the required speed-up in the algorithm was to re-write some parts of the code in assembly language, directly using the instructions and registers of the embedded processor in the scanner. This could be quicker than the existing program, which was written in the C programming language, because when a program written in C is converted into machine code it will be done in a standard way that isn’t necessarily the most efficient for this particular case, but works well generally.Luckily I didn’t have to re-write the entire program in assembly language; I was able to identify the most timing-critical repeated segments of the algorithm, and implement them in as few instructions as possible. Also, I didn’t start from nothing – I was able to start from the intermediate assembly language file produced from the C program. Even so, rewriting these sections didn’t speed the program up enough.In the end I was able to get the required improvement in speed by rewriting the algorithm itself so that it didn’t perform the slowest parts of the calculation for bars which were too deep to be of concern – but for some programs the re-write in assembly language could have been enough to speed up the program by 5 times, or even more.

Small chip

In another case, I was called in to debug a car part responsible for measuring the level of fuel remaining in a petrol tank. For some reason these devices were failing within a few hours of being activated, and the engineers at the company responsible were baffled.As the sensor was such a small component, it had a small and relatively simple processor, which meant that all of the code written for it was written in assembly language. To debug this I had to work through the code line by line, with pencil and paper to keep track of the contents of the registers. I eventually discovered that it was possible for the program to look for some data at position “0” of a table, when the positions went from “1” upwards, which would crash the program. Had the program been written in a language like C or Python this error would have been relatively obvious, but as it was in assembler it was easy to miss this subtle problem.Both of these cases showed situations where using assembly language was useful – either to speed up a program or to allow the use of a smaller, simpler chip – but also the problems that come along with it.