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 they 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? Hopefully, you don't use this to avoid break and continue as well because in this particular situation they are no different from goto. 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)

You are going way off-topic here. What I said elsewhere about "goto" hardly matters here. I say that presenting the examples as inline functions adds information (type of parameters and return values) as well as cleanliness of presentation. I also say that anyone who doesn't want to use inline functions despite the various advantages pointed out here, on the mere suspicion that they might not actually be inlined, can trivially convert the presented code into a macro. I also say that these here are examples, not templates for anyone to copy&paste without some thinking of his own. You are free to disagree, but you asked for your fellow user's input, and you got it. Can we now bury the hatchet and work on the article instead of attacking each other? -- Solar 14:13, 22 March 2011 (UTC)

Maybe a note would help but you are right that this wiki is not for production code; you're right in saying this is not production code. Also, sorry for going out of line in trying to prove my point regarding rules. Sometimes I just can't help being a bit of a douche. --Love4boobies 14:30, 22 March 2011 (UTC)

Don't worry about it. Happens to everyone once in a while. ;-)

I did a general cleanup of the article, which was in pitiful state. That's more important than whether it's inline functions or macros. ;-)

I assume you are more familiar with inline ASM in general; could you double-check the syntax of each example? I have a feeling there might be some bugs in there. The first 'io_wait()' looks funny, several 'asm' calls have only one colon, stuff like that. I'd also prefer 'uintX_t' instead of 'word' or 'unsigned short' and stuff like that (unless I get another flame from you for that ;-) ). -- Solar 14:41, 22 March 2011 (UTC)

There was nothing wrong with the io_wait labels but I changed the second anyway in order to avoid confusion. Having only one colon is okay as long as you only have output (the syntax is :output:input:clobber). With the exception of CPUID, everything looked fine but I also changed the way multi-instruction asm blocks were written so that the output doesn't contain all the instructions on a single line (this is only visible for people who want to see the assembly file generated by GCC). Regarding the uintX_t, I fully agree---however, I think there are quite a few articles that need to be modified because they don't use the freestanding headers, which I think is just silly. --Love4boobies 15:55, 22 March 2011 (UTC)