OSDev.org

Hi, I have a basic x86 OS with most of the core features (memory managment/multitasking/interrupts/etc) working.

However, I recently started considering making the transition to 64 bit, since 32 bit feels too old and limited.
I wanted to do it from the beginning but I was barely familiar with x86 and x86-64 seemed too far away and scary, now that I'm 3 months in I feel more confident.
Here are a few questions that I have:

- How expensive is the transition gonna be? How many things do I have to scrap? Does any of the old stuff stop working on 64 bit? (like PIT and other legacy hardware)
- Should I consider keeping compatibility with 32 bit mode? If so, do I just put thousands of ifdefs to make it work both ways?
- Since I have my own tool to make MBR FAT32 formatted virtual hard disks as well as a bootloader, I would have to rewrite them to do GPT and create EFI partitions, and my bootloader would have to become a PE executable right? Is this mandatory for x64?
- Is using legacy BIOS for booting even a sane thing to do for x64?

Rewriting all of my tools to support the modern x64 stuff seems like the most expensive thing out of all of these, so maybe I can stick with MBR and BIOS for now? idk...
(and I don't wanna use 3rd party stuff because thats just not how I roll )

Thanks

Switching from x86 to x86-64 is not that difficult. If you have paging enabled and you are not using segmentation, then there is not much difference between the two.

• You will have to change your startup code (obviously) since you need to enable long mode from protected mode. Also, in long mode, paging is mandatory. Long mode uses 4 level paging structures, so that's something you'll have to read about. CPU side of interrupt handing must be completely rewritten. IDT has different structure, and you need to save/restore different registers.
• Your physical memory manager must be changed. You are dealing with 4 level paging and 64 bit addresses now.
• All hardware operates exactly the same, no matter what mode CPU is in. You can use PIT, PIC, etc. just fine.
• Your linker scripts will need to be modified to accomodate new address ranges. You will probably have troubles mixing 32 and 64 bit code in one executable file in startup code. I deal with it by writing my startup code in position independent manner (like keeping all addresses relative to a single symbol).
• If you wan't to keep 32 bit mode code is completely up to you. It introduces some complications at source code level, but helps later with porting to other architectures.
• BIOS/MBR stuff stays completely unchanged. BIOS only booting is perfectly valid for x86-64.

Thanks! Great to know BIOS is still ok.

For older hardware, or for VMs. If you can install a valid MBR (not a dummy compatibility one) and boot from Legacy BIOS at all, you can boot into long mode from it.

TL;DR: BIOS is going away, and mostly has already.

All modern motherboards (by which I mean motherboards made after 2010, and specifically any which can mount an Intel or AMD CPU from around 2012 onwards) use UEFI firmware - the CPU manufacturers simply stopped supporting the older style of BIOS in their firmware, so it became next to impossible to make a BIOS-only alternative for the Intel and AMD parts.

The UEFI specification does define a way of booting with the Legacy BIOS called the Compatibility Support Module (CSM). This includes support for a bare MBR rather than a GPT. This was an optional feature however, and was only intended to make the transition to UEFI smoother, as it let people install existing operating systems on computers using newer motherboards.

As of this year, newer Intel and AMD firmware won't support CSM, and a most existing motherboards from around 2015 onward have already dropped support for the CSM.

You can still run a BIOS system in a VM, since that can use its own simulated firmware, but for bare metal, you'll be out of luck.

On a more positive (?) note, there's reason to think that Intel will shift entirely to 64-bit as the default and only mode some time in the next few years, so it might not be an issue for later PCs. But then, perhaps Microsoft will talk the PC manufacturers into following Apple's lead, and the monster known as x86 will be slain forever...


Baseless speculation ahoy!
My guess? Apple is going to buy up ARM, or try to since the SEC will surely have something to say about it. I don't know if Apple would stop licensing it or not, but given the goal of this move, it is possible they would. Chances are either way they would want to own ARM so that they won't be beholden to another IP owner.

Alternately, Amazon may preemptively buy ARM, either to keep it for their own server designs or to ensure Apple doesn't hoard it. If they refuse to continue licensing it to Apple, I expect that Apple would - and probably already are - design their own CPUs on a proprietary architecture.

If either of them succeed, and then move to lock out others from the ARM design, PCs will stay as they are for a while longer, but the SBC world will scramble to move to RISC-V, or MIPS, or some similar open-standard CPU architecture.

Either way, SBC manufacturers are not going to want to risk getting their legs cut out from under them, which is why I expect a move to RISC-V if any of this happens. The impact of jumping to RISC-V before there are any efficient core designs available for the architecture is left ans a exercise for the readers.

This depends solely on your preference. FYI, mainstream OSes started to drop 32 bit support if they haven't already.
Nope, but your loader should be upgraded to load a long mode kernel. You could do that terrible GDT and trampoline code hackery (mandatory with GRUB as it boots you in protmode), but I'd advise against. It's better to have a clean long mode kernel.
Definitely. I was booting 64 bit Linux kernel long before I had my first UEFI machine, and BIOS is smaller, faster, better in every way, and hopefully won't go away in VMs (booting qemu with BIOS is almost instant and requires 1M RAM, while booting with TianoCore takes half a minute at least and requires 64M of RAM at least. It does make a HUGE difference when you're doing lots of testing.)
You should reconsider how you roll. You can't do UEFI efficiently without 3rd party stuff (you can, but it is insanely hard. Use GNU efi or at least the uefi.inc on our wiki for Assembly). Quick way out: let the boot loader go, use BOOTBOOT, that will load your 64 bit kernel right into long mode, no trampoline code needed, and it works with BIOS and UEFI as well. Although the boot loader would be 3rd party, but it does not force anything on your kernel, no libraries, nothing, it just works. You kernel doesn't have to care if it was booted under BIOS or with UEFI (only if it wants to).

Cheers,
bzt

Yeah thats part of the reason why I don't wanna go there. It's just too much for a single person working on a hobby project. Thanks for the information.