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...
I guess I should add to that, "... or other specific language extensions"
eg, the Keil C51 compiler provides many specific language extensions to access the peculiar features of the 8051 architecture direct from 'C' without the need for assembler...
e2e.ti.com/.../264360.aspx
my.st.com/.../Flat.aspx
> "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/
Yes, it does specifically refer to GCC.
But I think the warning applies generally: in principle at least, inline assembler gives you direct, unfettered access to the entire CPU; so this is inherently a dangerous thing, only to be used with extreme care by those who really understand the issues - certainly not something for novices to play with!
As noted in my original post, my main concern about the vast majority of inline assembler questions that appear on this (and other) forums is that they are obviously not based on any clear understand - if any understanding at all - of the issues!
Hence anything that promotes a more excellent way must be a Good Thing...