AT&T asm syntax

[pini]

I prefer nasm's syntax than AT&T syntax, but however I have to use it in a GCC inline asm statement. I want to achieve a retf (not a simple ret). Currently, I'm using this :

Code: Select all

asm(".byte 203");

Because the retf opcode is 203 decimal.
I tried replacing this by a simple "retf" statement, but gcc (v 3.2.3-r1) says that "retf" is unknown...

[Pype.Clicker]

i think AT&T uses "retl" or "lret" instead of retf ... to be sure, encode a retf with nasm and disassemble the code with objdump -d and see how it is called

Alternatively, you can use the .intel_syntax trick when writing your code ...

There are chances that your ".byte" just went to the data section ... Anyway, forcing a return instruction in a C function is dangerous because you might miss some pops the compiler could have placed in the function epilogue.

[Solar]

While we're at it... can someone explain to me why everyone seems to be using inline assembly?

Blame my lack of experience (yet), but wouldn't it "feel cleaner" to have assembly modularized in an assembly file?

[Pype.Clicker]

because it would be very inefficient to have a function call everytime you want to issue "out edx,al" or "ltr", and unpractical for "sti" and "cli". Though i think in any other case, asm "functions" or code blocks (like interrupt stubs) should be in separate asm files, for small operations, having them in inline functions or macros defined in some kind of CPU abstraction header (#include <cpu/io.h>, for instance) allows the compiler to include them softly in generated code without impact on the pipeline or branch predict table ...

[Tim]

because it would be very inefficient to have a function call everytime you want to issue "out edx,al"

The function call overhead here (a few CPU clocks) is tiny compared with the bus transactions (many PCI clocks).

[pini]

i think AT&T uses "retl" or "lret" instead of retf

You were right : "retl" produces a simple "ret", but "lret" gives a "retf".

Thank you for your help.