The Place to Start for Operating System Developers
https://f.osdev.org/
Code: Select all
asm{
mov ax , 0x4c00
int 0x21
}
Code: Select all
__asm
{
mov al, 2
mov dx, 0xD009
out dx, al
}
Code: Select all
int current_task;
asm( "ltr %[output]"
: [output] "=r" (current_task)
);Code: Select all
int current_task;
asm( "str %[output]"
: [output] "=r" (current_task)
);Code: Select all
"movl %0, %%es" : "=r" (x)Code: Select all
// AtomicLock.h
#include <config.h>
class AtomicLock
{
private:
volatile int key;
public:
void Enter(void);
void Exit(void);
};
#include INC_ARCH(AtomicLock.h)Code: Select all
#define INC_ARCH(x) <arch/x86/x>Code: Select all
// arch/x86/AtomicLock.h
inline void AtomicLock::Enter(void)
{
asm volatile ("1: \n"
"pause \n"
"lock btsl $0, %[key] \n"
"jc 1b" : : [key] "m" (key));
}
inline void AtomicLock::Exit(void)
{
asm volatile ("movl $0, %[key]" : : [key] "m" (key));
}Code: Select all
// arch/m68k/AtomicLock.h
inline void AtomicLock::Enter(void)
{
asm volatile ("1: \n"
"bsetb #0, %[key] \n"
"beqs 1b" : : [key] "m" (key));
}
inline void AtomicLock::Exit(void)
{
asm volatile ("movel #0, %[key]" : : [key] "m" (key));
}Gee... I didn't check the examples from the original article enough, even though I already found some horrors in placesXenOS wrote:should probably beCode: Select all
int current_task; asm( "ltr %[output]" : [output] "=r" (current_task) );
You store the task register, you don't load itCode: Select all
int current_task; asm( "str %[output]" : [output] "=r" (current_task) );
I guess there is no output operand here, but an input operand instead.Code: Select all
"movl %0, %%es" : "=r" (x)
Now it's fixed. Thanks for your participation !Yup, I'm starting to sort of like it too as I begin to understand how it works, but I still think that the %x thing is a horrible mistake.As for the original topic, I like the way GCC handles inline assembly. GCC's operand constraint syntax offers the possibility to let the compiler choose which register(s) to use from a given set of registers, or choose memory or constant operands instead. The compiler can thus optimize the assembler code as well, which would not be possible if it was located in a separate file with fixed registers.
Well, this is more of a general problem with assembly, and not specific to inline assembly, isn't it ?Another drawback that has been mentioned in this thread is that inline assembly is not portable between different target architectures. Of course this is true. This is the reason why I use inline assembly only for architecture specific code. (A typical example is x86 paging code: Of course, an instruction like "movl %0, %%cr3" works only for x86 or x86_64, but this paging code will be used only for these, anyway.) There are some situations where a similar operation can be performed on different architectures, but with different instructions. (...)
I agree. At the beginning I was quite confused because of the additional %'s and used to forget them, with strange results.Neolander wrote:Yup, I'm starting to sort of like it too as I begin to understand how it works, but I still think that the %x thing is a horrible mistake.
1/Because it changes original GAS register syntax, where they could have used a new syntax like <variable name> instead.
2/Because it is error-prone : if you add an output operand in a code using input operands, you must rewrite the whole part of your code which uses them.
In principle, yes. But the advantage of GCC's syntax is that you can have different operands sharing the same register. For example, you can have something like:I don't fully understand the logic behind the new [] syntax either : it's better, but why not just use the output operand names right away ? It sounds more intuitive and less error-prone, while the benefit of doing otherwise is very small...
Code: Select all
asm ("cpuid" : "=a" (eax), "=b" (ebx), "=c" (ecx), "=d" (edx) : "0" (function));Code: Select all
struct
{
int first;
int second;
} data;
...
__asm
{
mov eax, &data
mov ecx, [eax].first
mov edx, [eax].second
}Yes, that's true. The problem with inline assembly is that it introduces this architecture dependence into the C source code, which otherwise could in principle be compiled targetting any architecture (even though it doesn't make sense, e.g. compiling x86 paging code for a M68K target). But especially in OS development, there are some things that simply must be architecture specific, and I don't see any disadvantage in putting them directly into some (architecture specific) C file via inline assembly. (Apart from the compiler dependence, of course.)Well, this is more of a general problem with assembly, and not specific to inline assembly, isn't it ?
