When do you use your compiler’s inline assembler feature and for what reasons?

Wednesday, September 1st, 2010 by Robert Cravotta

I am working on a mapping for software that is analogous to the mapping I developed to describe the different types of processing options. The value of this type of mapping is that it improves the visibility as to the assumptions and optimization trade-offs that drive the design and implementation details of a given tool or architecture. A candidate mapping criteria is the coupling between different layers of abstraction between the software and the hardware target. I will be asking questions that try to tease out the assumptions and trade-offs behind the tools you use to move between different layers of abstraction in your designs.

For example, a compiler allows a software developer to write instructions in a high-level language that generally allows the developer to focus on what the software needs to accomplish without having to worry about partitioning and scheduling the execution engine resources such as register reads and writes. For the mapping model, a compiler would have a strong coupling with the high-level language. Additionally, if the developer is using an operating system, the compiler may also support targeting the software to the operating system API (application programming interface) rather than a privileged mode on the target processor. This would constitute another layer of coupling that the compiler must account for.

However, most compilers also include an inline assembler that allows the developer to break these abstraction layers and work at the level of the target processor’s assembly instructions and resources. Using the inline assembler usually means more complexity for the software developer to manage because the compiler is no longer directly controlling some of the target processor’s resources. Using assembly language can also reduce the portability of the software, so developers usually have a good reason to break the abstraction layer and work at the level of the target processor. Reasons for using an inline assembler include improving the execution speed of the software, optimizing the memory usage in the system, and directly controlling special hardware resources in the processor such as co-processors, accelerators, and peripherals.

Under what conditions do you use the inline assembler (or a separate assembler) for you software? What are the project management and technical trade-offs you consider when choosing to work at the assembly level? What features would a compiler need to support that would allow you to avoid using assembly language? Your answers will help refine the software sweet spot mapping that I am currently developing.

Tags: , , , ,

3 Responses to “When do you use your compiler’s inline assembler feature and for what reasons?”

  1. J.G. @ LI says:

    It’s rarely necessary to use inline assembler in applications space. Usually, using the optimizer results in improving performance or code size to an extent similar to assembler. There are a few exceptions and those are usually when the processor offers instructions that are particularly well suited to an algorithm and the compiler does not generate those instructions. In this case, write the algorithm in the compiler language , say C, and then in assembler, finally enclose this in conditional compile statements. You retain portability and still get the benefit you are looking for on a specific architecture.

    At the OS level, sometimes assembler is the best way to go but those instances tend to be rare.

  2. A.H. @ LI says:

    Expanding on J.’s response above – the most obvious is when you need a true semaphore and the compiler is unable (or the compiler writer is unwilling) to use an atomic instruction E.G TAS (test and set) on the Freescale Coldfire processors. The TAS instruction is atomic – guaranteed to be uninterrupted – and so saves having to disable interrupts, test a semaphore and set if unset, then re-enable interrupts. In several examples of RTOS this has not been the default mechanism and so an InLine TAS can solve a problem where interrupts can be disabled when they don’t need to be.

    Obviously a very specific case but one that has very real results in performance and reliability.

  3. N.M. @ LI says:

    A.’s right. The last time I used inline assembly was yesterday and it was to ensure the correct atomic instruction was generated.

Leave a Reply to J.G. @ LI