OSDev.org

I hate using weird inline asm syntax which has different syntax based on what compiler you are using. So I am wondering if I have an external asm function such as



I am wondering if I have an external asm function that I am calling in my kernel code.
such as for example to make it equivalent to inline asm
could I just use this declaration in my c code (header file)

extern inline int func2() ;

would this be the same as using _asm{ ,...etc}

because currently I just have it extern int func2() ;

If inline is going to manual copy this in then maybe I shouldn't have a ret and just assign eax to a c varible. But that is assuming it is going to 100% copy in.

Anybody know

Sam111 wrote:I hate using weird inline asm syntax which has different syntax based on what compiler you are using. So I am wondering if I have an external asm function such as



I am wondering if I have an external asm function that I am calling in my kernel code.
such as for example

Code: Select all

global func2
func2:
;some random kernal stuff then return 4
mov eax , 4
ret

to make it equivalent to inline asm
could I just use this declaration in my c code (header file)

extern inline int func2() ;

would this be the same as using _asm{ ,...etc}

because currently I just have it extern int func2() ;

If inline is going to manual copy this in then maybe I shouldn't have a ret and just assign eax to a c varible. But that is assuming it is going to 100% copy in.

Anybody know

Of course it won't work. Compilers and assemblers only compile or assemble from a single source file at a time. Since your asm and c files are in separate source files, the compiler has no visibility of one from the other. The reason inline assy works is that the inlined functions are placed in a header file that is included at compile time.

With regards to calling assy code from c, be very sure to follow the relevant ABI document when writing your assembly code. That means you must pass parameters, preserve registers (including cc registers), look after the stack and return values exactly as the compiler expects or weird stuff will happen.

well , Correct me if I am wrong

but inline means that it copies the function or block of code for it where ever it is used.
i.e if I have a inline function called func where ever I reference use it at compile time it copies the same func code where ever it is used.

so if I have an external asm function extern int func in my header file.
Then adding the inline keyword to it won't this be the same as using inline asm tags?

Or are you saying you could never use the keywords extern , and inline in conjunction?

The compiler doesn't know about the contents of an external function.
Inlining is more complex than just a copy/paste.

Also, even to copy/paste assembly of a function you would need to know the length.
In order to know that, that information would need to be stored which it is not, once
compiled (assembled, etc). Keep in mind as well that assembly doesn't necessarily need
to be restricted to the same conventions used in higher level code (functions are just a
label that represents a location, so there isn't any length).

but inline means that it copies the function or block of code for it where ever it is used.
i.e if I have a inline function called func where ever I reference use it at compile time it copies the same func code where ever it is used

No. For inlining to work, the inlined code must exist in the same translation unit. You must be able to understand why this limitation exists.

so if I have an external asm function extern int func in my header file.
Then adding the inline keyword to it won't this be the same as using inline asm tags?

No it won't.

Or are you saying you could never use the keywords extern , and inline in conjunction?

I didn't say that. Have you read any c specifications ?

NOTE: The inline keyword and inline assembler have absolutely nothing to do with each other. The keyword for gcc inline assembler is __asm__.

Sigh.

Your 25 last posts are all about the following things:
- Not using google
- Not knowing the basics of C.
- Not knowing toolchain basics.

This is an community of programming experts, not a training camp for noobs. Do you mind redirecting to cprogramming.com?

Combuster wrote:This is an community of programming experts,

Alas, we're not very literate.

Either way, I have to agree with Combuster. You don't even understand the difference between inline assembly (i.e., using asm blocks introduced in C99) and inline functions (compiler hints which may very well be ignored).

Either way, I usually discourage the use of assembly in programs because it makes them unportable (rarely, certain situations call for performance/size optimizations and then assembly is needed). In OSes this can be avoided even less so here's my take on the situation: if you're going to use assembly, use separate files and link everything together at the end. You will clobber your source less, will make the code tree easier to maintain (e.g., if you wanted to port your OS to a new architecture, you'd see all the .asm files there, you wouldn't need to scan thousands of .c files for their assembly bits) and most importantly, you will be able to use more compilers to compile your code. The usage of the asm keyword varies from implementation to implementation and this is okay, according to the standard. For instance, in MSVC you have asm blocks ( asm { /* ... */ } ), while in GCC you have something similar to functions that take string parameters (a mess, IMHO).

The only advantage to inline assembly is that it abstracts the ABI bits (e.g., in a separate file you will need to know the proper calling convention that your compiler uses). However, I for one would rather want to have a clean C code base and a messy asm one than the other way around as there's a lot more C in a typical project.