Cant get interrupts to function in ring3 in my kernel

[overlook17385]

If this was 50 years ago, you may have a point. But it's 2024, and modern compilers would certainly outperform my hand-crafted assembler, and be more correct to boot.

I don't think the current time period should affect whether or not this project moves forward.

[eekee]

If this was 50 years ago, you may have a point. But it's 2024, and modern compilers would certainly outperform my hand-crafted assembler, and be more correct to boot.

I don't think the current time period should affect whether or not this project moves forward.

Nor anything else, you can code your OS however you want. However, we see a lot of myths on this forum and we don't really like to see them spreading. The idea that you can write faster code in assembly language than in C has been a myth for a very long time now, and it would be sad to see it influence newbies choice of language. If you want to write your OS in assembly language, that's absolutely fine, we've seen several assembly language OSs come to a fairly well-developed state over the years, (a rarity in this difficult hobby,) but we just don't want this myth to spread.

[overlook17385]

Edit: I think I've figured it out.

Code: Select all

dd 0x0010ffff ; ESP0

You didn't change anything. It's still exactly the same as it was before. It's still misaligned.

I am a bit confused. That was the limit I was intending for my stack. Have I somehow chosen the wrong limit?

[overlook17385]

Nor anything else, you can code your OS however you want. However, we see a lot of myths on this forum and we don't really like to see them spreading. The idea that you can write faster code in assembly language than in C has been a myth for a very long time now, and it would be sad to see it influence newbies choice of language. If you want to write your OS in assembly language, that's absolutely fine, we've seen several assembly language OSs come to a fairly well-developed state over the years, (a rarity in this difficult hobby,) but we just don't want this myth to spread.

Makes sense.

[rdos]

That was simply a small preference that I had for this project. I am fully aware of what I am doing.
I do this because I am prioritizing speed and efficiency in my Kernel.

If this was 50 years ago, you may have a point. But it's 2024, and modern compilers would certainly outperform my hand-crafted assembler, and be more correct to boot.

Well, I don't think speed is the issue. The issue is that low-level C code often is unreadable, and that the assembly version is much easier to understand. The optimizer often can do strange thing to C code which sometimes needs to be disabled to work. In assembly, the assembler will not try to optimize your code by removing instructions that it regards as redundant, so what you write is what you get.

In my experience, more complex devices, like decoding HID descriptors, setting up audio codecs, and filesystem implementations, are far easier to do in C than in assembly. However, the physical memory manager, paging, task-switching, and code to handle PCI are more readable in assembly than in C.

[rdos]

I recall Chuck Moore ditching assembly because MASM moved his code around! He switched to machine code, which I guess is all very well for someone who probably learned to program before the first assembler was developed.

I once created machine code for Z80 since I lacked an assembler, but I would not write machine code for x86.

Well, I actually wrote the long mode EFI boot-loader using dbs since my assembler could only handle 32-bit code, and the switch from long mode to protected mode was easier to write in machine code. Actually, I got the machine code by using the 64-bit WASM.

But now we have CPUs which are more emulator than fact, optimizing on the fly, having over 100 hidden registers which are used in a functional-programming manner rather than the rigorously procedural nature of their machine code.

My idea is that it is more important if the code is fast on a 386 processor than on a modern 64-bit CPU. So, I don't care a lot about optimizing code for modern CPUs. It's typically fast enough anyway, and most things are not performance critical.

If we can trust such CPUs to behave as expected, why can't we trust C too?

Because low-level code operates on real CPU features/registers that are not defined in C. Examples are control registers, flag registers, and general CPU registers when it comes to task switching.

[overlook17385]

Code: Select all

    dw tss_end - tss

It's closer, but still in the wrong place.

Fixed it.

Code: Select all

tss:
    dd 0        ; previous TSS
    dd 0x0010ffff ; ESP0
    dd 0x10 ; SS0
    ;dw 0
    times 0x17 dd 0
    dw 0
    dw tss_end - tss
tss_end:

[Octocontrabass]

I am a bit confused. That was the limit I was intending for my stack. Have I somehow chosen the wrong limit?

ESP0 is the stack pointer, not the stack segment limit. The stack segment limit is set by the segment descriptor for SS0.

Fixed it.

Code: Select all

tss:

The IOPB offset is still in the wrong place.

[eekee]

I recall Chuck Moore ditching assembly because MASM moved his code around! He switched to machine code, which I guess is all very well for someone who probably learned to program before the first assembler was developed.

I once created machine code for Z80 since I lacked an assembler, but I would not write machine code for x86.

I was about to write, "Same, but 6502!" but then I remembered what language I'm using. Parts of the standard library look like this:

To add a byte to another byte:
Intel $8B8508000000. \ mov eax,[ebp+8] \ the byte
Intel $0FB600. \ movzx eax,[eax]
Intel $8B9D0C000000. \ mov ebx,[ebp+12] \ the other byte
Intel $0003. \ add [ebx],al

and the authors' justification is:

If you're wondering why I don't have a built-in assembler, it's because it's not necessary. There is actually very little machine language in my brain, and as I get faster, more and more of it is replaced with Plain English. Besides, Osmosian Masters like to assemble in their heads. It keeps them young.

¯\_(ツ)_/¯

I read somewhere that they only use 25 instructions, so I guess it's not too hard. Using CISC like it's RISC.

Well, I actually wrote the long mode EFI boot-loader using dbs since my assembler could only handle 32-bit code, and the switch from long mode to protected mode was easier to write in machine code. Actually, I got the machine code by using the 64-bit WASM.

I'll be getting much of the machine code I need from Nasm or something.

But now we have CPUs which are more emulator than fact, optimizing on the fly, having over 100 hidden registers which are used in a functional-programming manner rather than the rigorously procedural nature of their machine code.

My idea is that it is more important if the code is fast on a 386 processor than on a modern 64-bit CPU. So, I don't care a lot about optimizing code for modern CPUs. It's typically fast enough anyway, and most things are not performance critical.

Logical.

If we can trust such CPUs to behave as expected, why can't we trust C too?

Because low-level code operates on real CPU features/registers that are not defined in C. Examples are control registers, flag registers, and general CPU registers when it comes to task switching.

Well, yeah I guess. C is going to ignore most of those and do what it likes with some of the flags.

[overlook17385]

Now I think I've fixed it.

Code: Select all

tss:
    dd 0        ; previous TSS
    dd 0x0010ffff ; ESP0
    dd 0x10 ; SS0
    ;dw 0
    times 0x16 dd 0
    dw 0
    dw tss_end - tss
    dd 0
tss_end:

[Octocontrabass]

Code: Select all

    dd 0x0010ffff ; ESP0

The IOPB offset is at the correct location now. ESP0 still isn't aligned.

[overlook17385]

Code: Select all

    dd 0x0010ffff ; ESP0

The IOPB offset is at the correct location now. ESP0 still isn't aligned.

How about now?

Code: Select all

dd 0x10fff ; ESP0

[Octocontrabass]

How about now?

Still no. You know what alignment is, right?

[overlook17385]

Still no.

Figured it out. Here's the updated version:

Code: Select all

dd 0x110000 ; ESP0