Is assembly language programming a dead-end skill? So much marketing material for embedded development tools seems geared toward making it seem that developers no longer need to work at the level of assembly language for their designs. How true is this message? My observation of the embedded market suggests that the need to program in assembly language is quite alive and well.

I think I have an explanation as to why compilers have enabled the majority of software development to occur in a higher-level language, and yet, they are falling short of eliminating that “final mile” of assembly programming. One target goal for compilers is that it can generate code that is as good as hand-coded assembly, but requires less time, energy, and resources to produce than hand-coded assembly.

While faster compilation is a good thing, I think we have reached a point of diminishing returns for many types of embedded software projects. While automated project and configuration management enables developers to spend even more minutes on software, it does not actually make those extra minutes more productive. Increasing the productivity of saved minutes is essential for today’s software development tools because embedded systems are growing in complexity, and a significant portion of that additional complexity (more than 50% from my estimate) manifests in the software portion of the design.

The problem I see is that while compilers are strong at scheduling and sequencing the loading and execution of opcodes and operands, they are horrible at partitioning and allocating global resources, such as memory spaces beyond the register set and possibly tightly coupled memories. This limits the compiler’s ability to increase a developer’s productivity in precisely the area that contributes a significant portion of the additional complexity in new designs.

Processor architects perform at herculean levels to deliver memory architectures that minimize silicon cost, minimize energy dissipation, and the hide latency of data reads and writes in the memory system so that the instruction execution engines do not stall. A problem is that programming languages do not capture, beyond register files, how the memory subsystem experiences varying access times for each of the different types of limited memory resources. Currently, it is only through manual assembly language coding that the software can match the different types of data with the access times for each memory resource that the processor architect provided.

Matching data with the different memory resources is an involved skill set, and it may be a long while before compilers can perform that partitioning with any level of proficiency. However, what other things should compilers do better to improve the productivity of software developers and offset the increasing amount of complexity they must account for in their embedded designs?

This entry was posted on Wednesday, August 11th, 2010 at 10:40 am and is filed under Question of the Week. You can follow any responses to this entry through the RSS 2.0 feed. You can skip to the end and leave a response. Pinging is currently not allowed.