This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Article on mixing 'C' and assembler (ARM focussed, but largely generic)

Here's a good paper from ARM TechCon about mixing assembler with High-Level Languages (HLLs) such as C and C++

very dangerous in the hands of a novice."

It seems to me that the vast majority of questions about inline assembler on this (and other) forums are from novices - and, thus, are generally bad ideas.

The article outlines 3 ways to access assembler functionality, in order of preference:

1. First, use Compiler Intrinsics wherever possible;

2. Use separate assembler source files, with functions to be called from the HLL;

3. As a last resort, and only for experienced developers, use inline assembler.

These principles would equally apply to C51 - and any other compiler...

Parents
  • > "While [inline assembly] may be an acceptable mechanism for somebody familiar with the inner
    > workings of the ... compiler to provide assembly capabilities, they are very dangerous in the
    > hands of a novice."

    I believe this particular statement mostly refers to GCC inline assembler. Since a platform independent tool chain like GCC doesn't usually understand the instructions, developers will have to tell GCC separately about the side effects of the code (e.g. memory/register access, parameters). These operand constraint strings are easy to get wrong to begin with and will cause grief when they get out of sync with the code after applying "minor" changes.

    A problem with inline assembler in target-specific tools like e.g. RVCT is that the code is not WYSIWYG. You might be able to use real C variable names and the register allocator will sort things out for you. That means that your assembler code might get speckled with stack accesses and other unexpected instructions. Instruction level optimizations are applied after this step. IOW, you are no longer in control of the instructions generated, which is normally the main reason for using assembler in the first place.

    Both, GCC and RVCT offer a great selection of intrinsic functions (GCC: builtins) that make people less dependent on inline assembler.

    In ARMv7 architectures (and perhaps also v6T2 and v6-M), inline assembler is deprecated for RVCT.

    --
    Marcus
    http://www.doulos.com/arm/

Reply
  • > "While [inline assembly] may be an acceptable mechanism for somebody familiar with the inner
    > workings of the ... compiler to provide assembly capabilities, they are very dangerous in the
    > hands of a novice."

    I believe this particular statement mostly refers to GCC inline assembler. Since a platform independent tool chain like GCC doesn't usually understand the instructions, developers will have to tell GCC separately about the side effects of the code (e.g. memory/register access, parameters). These operand constraint strings are easy to get wrong to begin with and will cause grief when they get out of sync with the code after applying "minor" changes.

    A problem with inline assembler in target-specific tools like e.g. RVCT is that the code is not WYSIWYG. You might be able to use real C variable names and the register allocator will sort things out for you. That means that your assembler code might get speckled with stack accesses and other unexpected instructions. Instruction level optimizations are applied after this step. IOW, you are no longer in control of the instructions generated, which is normally the main reason for using assembler in the first place.

    Both, GCC and RVCT offer a great selection of intrinsic functions (GCC: builtins) that make people less dependent on inline assembler.

    In ARMv7 architectures (and perhaps also v6T2 and v6-M), inline assembler is deprecated for RVCT.

    --
    Marcus
    http://www.doulos.com/arm/

Children