Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: Ar Rakin <rakinar2@onesoftnet.eu.org>
Newsgroups: comp.lang.c
Subject: Re: [OSDev] How to switch to long mode in x86 CPUs?
Date: Fri, 28 Feb 2025 22:30:07 +0600
Organization: OSN Developers
Lines: 70
Message-ID: <875xkughgw.fsf@onesoftnet.eu.org>
References: <871pvje5yq.fsf@onesoftnet.eu.org> <vprtt6$3jah9$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain
Injection-Date: Fri, 28 Feb 2025 17:30:07 +0100 (CET)
Injection-Info: dont-email.me; posting-host="fe5f78b35297dc67a24ae7e577d95659";
	logging-data="3933318"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18IaFqRThAvtImytK28qEpNMlOKer2SrI0="
User-Agent: Gnus/5.13 (Gnus v5.13)
Cancel-Lock: sha1:8Bmyg3wdSkgQPPg6h4o+y6JpGW8=
	sha1:m1ef+788+ZWm4ds3pTEqjCkzQds=
Bytes: 4401

On 28 Feb 2025 09:59, David Brown <david.brown@hesbynett.no> wrote:

> On 27/02/2025 16:57, Ar Rakin wrote:
>> Hello there,
>> I am trying to develop my own, simple operating system to learn more
>> about how kernels work and low level stuff like that.  However, I am
>> stuck at setting up paging while switching long mode (64-bit protected
>> mode) in x86 processors.
>> 
>
> Are you trying to learn about OS kernels, or about the complexities of
> low-level x86 stuff?  Those are different things.

I am just trying to learn about OS kernels, by building one.

> If you want to learn about how operating systems work, you might
> consider starting on microcontrollers.  There are lots of RTOS's
> available to study, and it is much easier to understand what is going
> on - there is none of the multi-layered disaster of x86 modes to deal
> with.
>
> Once you are happy with threads, context switches, locks, priorities,
> and all the rest of that stuff, you can start moving up and adding
> features for MMU's, SMP, and more, using bigger target processors.

I actually wanted to build a simple kernel that would run specifically
on x86_64 systems.  I understand why you are recommending me to learn
about microcontrollers first, but at the moment I am almost done with
what I wanted to achieve - I just need to fix the paging issue I
described earlier.

> On the other hand, if you are interested in learning the intricacies
> of the x86 world, you need to look elsewhere for information - as
> Keith says, it is not really C related when you are writing
> assembly. comp.arch might be a helpful group.

Looks like comp.arch might be the group I needed to find! Thanks.

> However, it is possible to use C for almost all code here.  But it
> will not be standard C - it is not even standard free-standing C.  You
> will make use of compiler extensions, bits of inline assembly,
> pre-main C code (so none of the library will be initialised, and
> program-lifetime data will not be set up), and other such highly
> non-portable code.  I remember reading once about LinuxBIOS (now
> coreboot) having just four lines of assembly running out of reset,
> before everything else was in C.

That is true, I could have just used C.  Even articles on the osdev.org
website heavily use C, for stuff like setting up the Global Descriptor
Table (GDT), which I prefer to do in assembly because you would still
need to use a special x86 assembly instruction to load the GDT (lgdt).

I would much rather prefer having separate assembly files rather than
inlining them in the C source files whenever possible.  It's probably
just my preference.

Also just to clarify, from what I know, since the x86 processors start
in 16-bit real mode for the sake of compatibility, you'd have to start
writing 16-bit code first, then switch to 32-bit protected mode, then
finally switch to 64-bit long mode.  However if you use an existing
bootloader such as GRUB, then you usually would not need to worry about
16-bit code since GRUB drops you in 32-bit protected mode.  But still,
if you wish to switch to 64-bit long mode, you *will* have to mix 64-bit
and 32-bit code together.
Either I don't know how to, or I just don't feel comfortable mixing
32-bit and 64-bit code together *when in C* because you will have a hard
time linking those together.  Please correct me if I am wrong.

--
Ar Rakin