problem in putting asm in c files

[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

[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

[Owen]

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

[Selenic]

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)

[Combuster]

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.

[Selenic]

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)

[Combuster]

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

[XanClic]

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.

[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'|

[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.

[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.

[Owen]

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.

[Solar]

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.)

[Brendan]

Hi,

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

[Owen]

I wasn't refering to "gdtInstall" specifically there - but some functions probably have higher impact.