OSDev.org

Posted: **Tue Jul 23, 2024 12:13 pm**

thewrongchristian wrote: ↑Tue Jul 23, 2024 12:06 pm 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.

Posted: **Tue Jul 23, 2024 12:35 pm**

overlook17385 wrote: ↑Tue Jul 23, 2024 12:13 pm
thewrongchristian wrote: ↑Tue Jul 23, 2024 12:06 pm 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.

Posted: **Tue Jul 23, 2024 12:47 pm**

Octocontrabass wrote: ↑Mon Jul 22, 2024 10:21 pm
overlook17385 wrote: ↑Mon Jul 22, 2024 9:37 pmEdit: 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?

Posted: **Tue Jul 23, 2024 12:49 pm**

eekee wrote: ↑Tue Jul 23, 2024 12:35 pm 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.

Posted: **Tue Jul 23, 2024 2:06 pm**

thewrongchristian wrote: ↑Tue Jul 23, 2024 12:06 pm
overlook17385 wrote: ↑Mon Jul 22, 2024 12:18 pm 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.

Posted: **Tue Jul 23, 2024 2:20 pm**

eekee wrote: ↑Tue Jul 23, 2024 6:14 am 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.

eekee wrote: ↑Tue Jul 23, 2024 6:14 am 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.

eekee wrote: ↑Tue Jul 23, 2024 6:14 am 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.

Posted: **Tue Jul 23, 2024 2:51 pm**

Octocontrabass wrote: ↑Mon Jul 22, 2024 10:21 pm
overlook17385 wrote: ↑Mon Jul 22, 2024 10:00 pm
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:

Posted: **Tue Jul 23, 2024 3:41 pm**

overlook17385 wrote: ↑Tue Jul 23, 2024 12:47 pmI 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.

overlook17385 wrote: ↑Tue Jul 23, 2024 2:51 pmFixed it.
Code: Select all
tss:

The IOPB offset is still in the wrong place.

Posted: **Tue Jul 23, 2024 3:44 pm**

rdos wrote: ↑Tue Jul 23, 2024 2:20 pm
eekee wrote: ↑Tue Jul 23, 2024 6:14 am 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:

cal-4700 instructions wrote: 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.

rdos wrote: ↑Tue Jul 23, 2024 2:20 pm 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.

rdos wrote: ↑Tue Jul 23, 2024 2:20 pm
eekee wrote: ↑Tue Jul 23, 2024 6:14 am 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.

rdos wrote: ↑Tue Jul 23, 2024 2:20 pm
eekee wrote: ↑Tue Jul 23, 2024 6:14 am 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.

Posted: **Tue Jul 23, 2024 3:47 pm**

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:

Posted: **Tue Jul 23, 2024 3:52 pm**

overlook17385 wrote: ↑Tue Jul 23, 2024 3:47 pm
Code: Select all
    dd 0x0010ffff ; ESP0

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

Posted: **Tue Jul 23, 2024 3:57 pm**

Octocontrabass wrote: ↑Tue Jul 23, 2024 3:52 pm
overlook17385 wrote: ↑Tue Jul 23, 2024 3:47 pm
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

Posted: **Tue Jul 23, 2024 4:03 pm**

overlook17385 wrote: ↑Tue Jul 23, 2024 3:57 pmHow about now?

Still no. You know what alignment is, right?

Posted: **Tue Jul 23, 2024 4:42 pm**

Octocontrabass wrote: ↑Tue Jul 23, 2024 4:03 pm Still no.

Figured it out. Here's the updated version:

Code: Select all

dd 0x110000 ; ESP0

OSDev.org

Cant get interrupts to function in ring3 in my kernel

Re: Cant get usermode to function in my kernel

Re: Cant get usermode to function in my kernel

Re: Cant get usermode to function in my kernel

Re: Cant get usermode to function in my kernel

Re: Cant get usermode to function in my kernel

Re: Cant get usermode to function in my kernel

Re: Cant get usermode to function in my kernel

Re: Cant get usermode to function in my kernel

Re: Cant get usermode to function in my kernel

Re: Cant get usermode to function in my kernel

Re: Cant get usermode to function in my kernel

Re: Cant get usermode to function in my kernel

Re: Cant get usermode to function in my kernel

Re: Cant get usermode to function in my kernel