Page 1 of 2
problem in putting asm in c files
Posted: Wed Feb 24, 2010 1:45 pm
by psnix
hi
how can I convert this code which gcc compiler support this:
Code: Select all
static void gdtInstall (void)
{
#if _HAL_COMPILER ==_HAL_COMPILER_MSVC
_asm
{
lgdt [_gdtr]
mov ax,0x10 // 0x10 is the offset in the GDT to kernel data segment
mov ds,ax // load all data segment selectors
mov es,ax
mov fs,ax
mov gs,ax
mov ss,ax
jmp 0x08:.flush // 0x8 is the offset to kernel code segment in GDT
.flush
}
#elif _HAL_COMPILER == _HAL_COMPILER_GNUC
// GCC CODE HERE
}
#endif
Re: problem in putting asm in c files
Posted: Wed Feb 24, 2010 1:59 pm
by Selenic
If GCC won't compile that asm block as it is, try surrounding it with quotes and see if that works
For anything more complicated (passing values to the assembly code or whatever), these two sections of the GCC manual are *very* useful:
Extended assembly and
Assembly constraints
Re: problem in putting asm in c files
Posted: Wed Feb 24, 2010 5:29 pm
by Owen
Selenic wrote:If GCC won't compile that asm block as it is, try surrounding it with quotes and see if that works
For anything more complicated (passing values to the assembly code or whatever), these two sections of the GCC manual are *very* useful:
Extended assembly and
Assembly constraints
I somehow doubt it will "just work" because, well, AT&T syntax looks quite different.
You'll just have to learn GCC's assembly syntax. It's more effort, but it's worth it: The code produced around it is miles better than that by MSVC for the same value
Re: problem in putting asm in c files
Posted: Thu Feb 25, 2010 12:00 pm
by Selenic
Owen wrote:I somehow doubt it will "just work" because, well, AT&T syntax looks quite different
Oh yeah, I didn't notice that. OTOH, I think GAS supports both styles, if you put the right directives around your code. If not, you just need to convert it to AT&T syntax (not very difficult)
Re: problem in putting asm in c files
Posted: Thu Feb 25, 2010 12:03 pm
by Combuster
Selenic wrote:you just need to convert it to AT&T syntax (not very difficult)
cough cough
I doubt the n00b next door could pull it off.
Re: problem in putting asm in c files
Posted: Thu Feb 25, 2010 12:39 pm
by Selenic
Combuster wrote:Selenic wrote:you just need to convert it to AT&T syntax (not very difficult)
cough cough
I doubt the n00b next door could pull it off.
By 'not very difficult' I meant in comparison to, say, converting C to Haskell (as an example). You still have to be careful to make sure you get everything, but you *could* cheat and use an assembler in one format and disassemble it in the other (though for the OP's case that would probably be more work than doing it by hand)
Re: problem in putting asm in c files
Posted: Thu Feb 25, 2010 12:42 pm
by Combuster
Selenic wrote:By 'not very difficult' I meant in comparison to, say, converting C to Haskell (as an example).
Oh, but that's easy! You just don't do that
Re: problem in putting asm in c files
Posted: Thu Feb 25, 2010 1:03 pm
by XanClic
Selenic wrote:Owen wrote:I somehow doubt it will "just work" because, well, AT&T syntax looks quite different
Oh yeah, I didn't notice that. OTOH, I think GAS supports both styles, if you put the right directives around your code.
Using -masm=intel as a command line parameter when invoking gcc is sufficient.
Re: problem in putting asm in c files
Posted: Sat Feb 27, 2010 1:27 pm
by psnix
hi
finally i convert this code but something is wrong and compiler can not compile it!
what is wrong in this code ?
Code: Select all
asm("lgdt (%0)": :"p" (&_gdtr));
asm("movl $0x10,%eax \n\t" // 0x10 is the offset in the GDT to kernel data segment
"movl %eax,%ds \n\t" // load all data segment selectors
"movl %eax,%es \n\t"
"movl %eax,%fs \n\t"
"movl %eax,%gs \n\t"
"movl %eax,%ss \n\t"
"jmp $0x8:flush \n\t" // 0x8 is the offset to kernel code segment in GDT
"flush: nop \n\t"
);
errors:
../hal/gdt.c|59|Error: junk `:(flush)' after expression|
../hal/gdt.c|59|Error: suffix or operands invalid for `jmp'|
Re: problem in putting asm in c files
Posted: Sat Feb 27, 2010 4:36 pm
by pcmattman
The error says what is wrong with the code. Now, how do you do a far jump in AT&T syntax compared to Intel syntax? Hint: the colon shouldn't be there.
Re: problem in putting asm in c files
Posted: Sat Feb 27, 2010 6:38 pm
by NickJohnson
Or you could just remove that non-portable inline assembly, and instead use a separate assembler and combine them at link time. That way you're guaranteed it will work regardless of which compiler you're using. You can even run the C preprocessor on the assembly code if you need macros for configuration.
Re: problem in putting asm in c files
Posted: Mon Mar 01, 2010 6:52 am
by Owen
NickJohnson wrote:Or you could just remove that non-portable inline assembly, and instead use a separate assembler and combine them at link time. That way you're guaranteed it will work regardless of which compiler you're using. You can even run the C preprocessor on the assembly code if you need macros for configuration.
And also much slower at runtime
A separate assembler is unportable anyway.
To the OP: You need to tell GCC you're clobbering EAX.
Re: problem in putting asm in c files
Posted: Mon Mar 01, 2010 8:01 am
by Solar
Owen wrote:NickJohnson wrote:Or you could just remove that non-portable inline assembly, and instead use a separate assembler and combine them at link time. That way you're guaranteed it will work regardless of which compiler you're using. You can even run the C preprocessor on the assembly code if you need macros for configuration.
And also much slower at runtime
A separate assembler is unportable anyway.
I don't see where calling
static void gdtInstall (void) makes "much" difference, performance-wise, whether it's written in inline or extern ASM? The extern solution is definitely cleaner, as you have separate source files for separate languages. (Warning: ASM noob here, I might just be missing the obvious.)
Re: problem in putting asm in c files
Posted: Mon Mar 01, 2010 9:36 am
by Brendan
Hi,
Solar wrote:I don't see where calling static void gdtInstall (void) makes "much" difference, performance-wise, whether it's written in inline or extern ASM? The extern solution is definitely cleaner, as you have separate source files for separate languages. (Warning: ASM noob here, I might just be missing the obvious.)
Performance wise, using an external (assembly) routine would cost a CALL/RET, which adds about 2 cycles on a modern CPU. As this code would be run once during boot, the end result is that the OS would take about 1 nanosecond longer to boot.
On the other hand, for the life-time of the code, it'll probably cost programmers 20 hours or more in maintenance and assorted hassles.
Simple maths says that unless the OS is booted more than 72000000000000 times (e.g. 36 million users that boot it 2 million times each), using inline code is a waste of time (the time spent maintaining it is more than the time saved booting it).
However, there is a compromise - do the entire "gdtInstall()" in an external assembly routine. That way you avoid the extra CALL/RET, and separating architecture specific code from the portable C code will make it easier/quicker to port to a different architecture (and avoid time spent for "maintenance and assorted hassles"). It's a "win win" situation...
Cheers,
Brendan
Re: problem in putting asm in c files
Posted: Mon Mar 01, 2010 1:30 pm
by Owen
I wasn't refering to "gdtInstall" specifically there - but some functions probably have higher impact.