OSDev.org

bloodline wrote:Shouldn't the first opcode be lgdtl (%0), as we are loading a pointer?

I forgot to mention: we're not loading a pointer. The operand being passed via inline ASM is the GDTR struct itself, not a pointer to said struct. This has two advantages: the compiler can generate the pointer however it wishes instead of loading it into a register, and the compiler is aware that the value of the struct has significance instead of just the value of the pointer to the struct.

That last bit is one of the many reasons why inline assembly is hard. The compiler assumes values not used as inputs or outputs have no significance to the inline assembly, so if you pass a pointer to inline assembly, the compiler only sees the value of the pointer as being significant, and not the object it points to. You can use a "memory" clobber to tell the compiler that the inline assembly may affect values other than its inputs and outputs, but then the compiler must spill all objects to memory.

None of that is a problem if you use an external function written in assembly.

bloodline wrote:I attempted to build my interrupt stack frame using inline asm, but I must have made a mistake somewhere as it caused the interrupts to not return properly, so currently my int handler code is in a separate asm file... I will attempt to do it inline again when I get better at x86 asm.

I don't think that's a supported use case for inline assembly. There's a function attribute you can use, but it's specific to x86 and requires some extra compiler options you may not want to use.

Octocontrabass wrote:

bloodline wrote:Shouldn't the first opcode be lgdtl (%0), as we are loading a pointer?

I forgot to mention: we're not loading a pointer. The operand being passed via inline ASM is the GDTR struct itself, not a pointer to said struct. This has two advantages: the compiler can generate the pointer however it wishes instead of loading it into a register, and the compiler is aware that the value of the struct has significance instead of just the value of the pointer to the struct.

That last bit is one of the many reasons why inline assembly is hard. The compiler assumes values not used as inputs or outputs have no significance to the inline assembly, so if you pass a pointer to inline assembly, the compiler only sees the value of the pointer as being significant, and not the object it points to. You can use a "memory" clobber to tell the compiler that the inline assembly may affect values other than its inputs and outputs, but then the compiler must spill all objects to memory.

None of that is a problem if you use an external function written in assembly.

I think I need to tread very carefully with inline asm... It is fun though and that is the whole reason to do this. I appreciate your guidance here!

bloodline wrote:I attempted to build my interrupt stack frame using inline asm, but I must have made a mistake somewhere as it caused the interrupts to not return properly, so currently my int handler code is in a separate asm file... I will attempt to do it inline again when I get better at x86 asm.

I don't think that's a supported use case for inline assembly. There's a function attribute you can use, but it's specific to x86 and requires some extra compiler options you may not want to use.

I guess given C's dependence upon the stack, screwing around with it is a recipe for disaster, especially since I have no idea what the compiler is doing (despite spending too much time on Compiler Explorer... https://godbolt.org) and my ignorance with x86 asm.

Ok managed to get it all up and running quite easily.

Now time to figure out the multiboot structure and add a memory manager