Talk:Inline Assembly/Examples

Rollback

Rolled back edit by imate900 that added the following lgdt function, which is wrong for many reasons. I just did not have time to fix the example yet.

void *lgdt(void *gdt, int entries)
{
 struct { unsigned short *length, void *base } gdtr_t;
 gdtr_t *gdtr;
 gdtr.length = entries;
 gdtr.base = gdt;
 asm("lgdt (%0)": : "p" (&gdtr));
 asm("mov %ax, 0x10");
 asm("mov %ds, %ax");
 asm("mov %es, %ax");
 asm("mov %fs, %ax");
 asm("mov %gs, %ax");
 asm("mov %ss, %ax");
 goto fix_cs;
fix_cs:
 return;
}

--quok 19:17, 2 May 2009 (UTC)

Problems with article

I see some problems with this article:

1. It only provides GCC inline assembly.
2. It uses GCC-specific extensions although the "inline" keyword was introduced in C99.
3. More importantly, everything here is more suited as a macro than inline assembly. It is important to understand that "inline" is just a compiler hint and may be ignored entirely as far as optimizations go (and probably will). The only thing one can be sure of is that a pointer to the function cannot be obtained.
4. I/O support is directly supported in C (TR 1169).

It would be nice if someone explained why this article is neccessary. --Love4boobies 05:44, 10 March 2011 (UTC)

1. This article is an extension to Inline Assembly, which reads "...this article describes the way it works in GCC since it is by far the most used compiler in the OS world." Feel free to add an example page for MSVC inline assembly if you want.
2. I agree there.
3. The "inline" in "inline assembly" has nothing to do with the "inline" keyword. Any ASM source written in a C source file is "inline", as opposed to ASM source in an external .asm / .s source file. You might want to note that an external ASM function can never be inlined, as the compiler lacks information on register usage etc. - and for the sake of presentation, I prefer a function declared inline over a preprocessor macro anytime.
4. You probably refer to the header <iohw.h>, which was added with TR18015 and TR18037. GCC still does not even follow C99 by default. The <iohw.h> header is absent from the GCC 4.1.2 installation I have available for quick checking. As such, it is not a viable replacement for the information provided in this article (which aims at providing examples of the modus operandi, not copy & paste code snippets anyway).

I hope this helps (some). -- Solar 12:57, 10 March 2011 (UTC)

I am not confusing inline assembly with inline functions. However, note that all the inline assembly code is implemented via inlined functions, which is why I suggested macros instead. The inline keyword is the problem, not the assembly. Using functions has not advantage because the compiler itself cannot assemble and has the potential performance disadvantage I have already explained. --Love4boobies 14:48, 10 March 2011 (UTC)

Functions > Macros. They are typed, more legible and improve debugging. If the compiler does inline such functions the performance difference is zero by definition. In professional C++, macro's are not done in favour of templates. For half of those reasons, I also prefer vim over emacs. For the other half, functions must stay. - Combuster 15:08, 10 March 2011 (UTC)

Yes, Combuster, C type checking is of huge advantage in inline assembly which is not even performed by the compiler. --Love4boobies 17:14, 10 March 2011 (UTC)

The C compiler will do type checking on the parameters of an inline function. Inline functions also allow you to decide whether you want them inlined (for speed) or not (for space, or debugging). But that is neither here nor there: Simply for didactic reasons I much prefer inline functions over macros. Replace them with macros if you have proven them not being inlined and being a performance problem. Or replace them with macros in your project on general principles. For presentation, I refuse to write macro code on the mere guess that an inline function might not get inlined. -- Solar 10:56, 21 March 2011 (UTC)

For didactic reasons you prefer inline functions over macros, yet I need to prove that some compiler doesn't inline although you are perfectly aware that the C standard allows both behaviors? I think you should reconsider what is didactic---foolishly sticking to rules or actually understanding why there are there and how to use them to your advantage. Maybe you like writing code on a per-tool basis. However, I prefer standards-compliant code. This is almost as ridiculous as this post, where you advocated for the craziest scheme just in order to work around the use of goto. The reason for which it should usually be avoided is to that it renders code less readable---but making the code unreadable just in order to avoid it kind of defeats the purpose, doesn't it? Not only is it unreadable since you need to scroll around to get to read some sequential code that logically is part of the same instruction stream, but it also suffers from the same technical difficulty with the inline keyword. --Love4boobies 13:42, 22 March 2011 (UTC)