OSDev.org

Yup, this is a serious question.

I've been playing with C for some time, but here I've started learning about inline assembly in C, and hence wanted to express some rant.

Theoretically, it looks cool : you put a keyword somewhere, and voila, you can write assembly code in the middle of your function, reutilizing your variables, and everything works fine provided that you abide by some rules (ie keeping some registers unchanged).
Practically, that's how it works in languages like Pascal Object where the compiler is smart, helpful, and boringly rigorous. Not in C. Each time I see some inline assembly code in C, I want to vomit. It's just looks so much like a hack in terms of cleanness and readability. Surely, people who invented inline assembly syntax used trigraphs everyday in their code.

To me, it looks like it would be much cleaner in most cases to write an assembly function in a separate .S source file and call it directly. I don't see the benefit of using inline assembly over that solution, except maybe the slight performance penalty of using a CALL statement. Could someone please tell me if there actually is another ?

Neolander wrote:Each time I see some inline assembly code in C, I want to vomit. It's just looks so much like a hack in terms of cleanness and readability. Surely, people who invented inline assembly syntax used trigraphs everyday in their code.

ISO/IEC 9899:1999 specifies:

J.5.10 The asm keyword
The asm keyword may be used to insert assembly language directly into the translator
output (6.8). The most common implementation is via a statement of the form:
asm ( character-string-literal );

Standard doesn't specify any kind of syntax for inline assembly. GCC just happens to implement it in a way you don't like.

IMO you pretty much nailed good sides of inline assembly. You can insert assembly snippets to your functions, so you don't have to write functions for that, and depending on implementation, you may be able to use automagically your variables in your inline assembly block and compiler does the dirty job assigning registers etc.

I think calling a separate function for a simple "CLI" or "MOV CR3, EAX" is a bit of overkill. I do agree to the extend that inline assembly should best be placed in an inline function or function-like macro.

I also agree inline Assembly is useful. What I however don't like is GCC's way of doing it. Besides the fact that it uses AT&T syntax (I like Intel syntax more, but that's a matter of preference*), I also think all the strings and colons are bloating. I personally like Visual C++'s inline assembly much more (although I don't have any specific preference for the compiler, both GCC and VC++ have their benefits): the way it's done (__asm { opcodes }) is just so much simpler than GCC. It probably has a few side-effects too, though (e.g. I don't really know of any way to do clobbered registers in VC++).

* Yes, I know you can set it to use Intel syntax.

Creature wrote:the way it's done (__asm { opcodes }) is just so much simpler than GCC. It probably has a few side-effects too, though (e.g. I don't really know of any way to do clobbered registers in VC++).

Last I checked, VC assumes every register is clobbered, and has to emit extra moves to set up all the registers with the variables you like.

The gcc format is hideous (and Motorola syntax is an abomination "(%esi, %ebx, 2)"), but it allows the compiler to do register optimizations and trace all the clobbers...

point.
do check out freebasic's inline assembler.
http://www.freebasic.net/wiki/wikka.php?wakka=KeyPgAsm
pretty neat, IMO..

Personally, I like GCC's way of inline assembly. Basically, you could think of it as an output format string where the %specifiers are replaced with the arguments that follow. The main benefit is that GCC doesn't have to understand a single line of it and still knows exactly all side effects. There are some quirks, yes, for example why do output constraints need a "=" prefixed to them while they are already in a separate list? But in general I consider it very powerful.

Hobbes wrote:Personally, I like GCC's way of inline assembly. Basically, you could think of it as an output format string where the %specifiers are replaced with the arguments that follow. The main benefit is that GCC doesn't have to understand a single line of it and still knows exactly all side effects. There are some quirks, yes, for example why do output constraints need a "=" prefixed to them while they are already in a separate list? But in general I consider it very powerful.

Actually, I found out. http://ibiblio.org/gferg/ldp/GCC-Inline ... HOWTO.html
The "output" word in GCC doc is a bit misleading, because in truth it only means that said variables are going to be rewritten by the assembly snippet.
"=" is for variables that are going to be rewritten and whose original value isn't important to the assembly code, whereas for "normal" output variables, the original value is considered important as well, just as if you used some pointer parameter for your function in C.

Hi,
I agree with Neolander.I hate inline assembly and avoid it like plague .The point is inline assembly leads to code that's specific to architecture.One fundamental design principle is "Factor out that which changes".To remain faithful to this important design principle,I normally write seperate .asm files for architecture specific code even if it means reducing the efficiency by little .

{Please excuse my poor English }
--Thomas

Thomas wrote:Hi,
I agree with Neolander.I hate inline assembly and avoid it like plague .The point is inline assembly leads to code that's specific to architecture.One fundamental design principle is "Factor out that which changes".To remain faithful to this important design principle,I normally write seperate .asm files for architecture specific code even if it means reducing the efficiency by little .

{Please excuse my poor English }
--Thomas

In the way I would use inline assembly in operating system most inline assembly blocks are inside parts which are architecture specific and need to be seperated fully from architecture independant code and possibly needs to be written seperately for different architectures. When writing "normal" software I don't use inline assembly, because I don't see any reason for it (or better, haven't used - haven't seen).

{Please excuse my poor English}
--Joonas

fronty wrote:When writing "normal" software I don't use inline assembly, because I don't see any reason for it (or better, haven't used - haven't seen).

Have you tried writing games for the good old DOS ? Anyways its my point of view and I maintain mine,enough said
--Thomas

Thomas wrote:Have you tried writing games for the good old DOS ?

No, I haven't, and most likely won't. If I would, I would most likely seperate bigger parts of code into pure assembly or use some library supplied by compiler vendor to use when doing that kind of stuff in pure <insert hll>.

When I think of it twice, I found that page which I mentioned earlier quite helpful, and more complete than the wiki article in places. I'd gladly merge its new content in the "Inline Assembly" wiki article, if everyone agrees that it's not abusing the "knowing some basic assembly" OSdev prerequisite.

Inline assembly is very seldom used outside of the OS and high-performance computing world, so it should not become a prerequisite knowledge imo (but I may be biaised, since I think that hand-crafted LD scripts are pretty rare outside of the OS world too, which does not seem to be everyone's view on the subject).

ACK to Neolander

IMO, if you think something will be useful in the wiki, then add it.

In this case in particular, it would indeed be helpful to have a nice article in the wiki on inline assembly.