4 ms·

but you don't get to decide whether to use 32bit or 64bit mode, your firmware does for you.

by pgeorgi 12y ago

exDM69 12y ago
Firmware? No, the OS will have to explicitly choose the mode the CPU operates in. The PC, under "normal" legacy BIOS, always boots to 16 bit mode (like in OP). From there on, you manually have to change the processor operating mode to 32 bits (protected mode) or 64 bits (long mode), by setting some privileged registers and doing a jump to 32/64 bit code. In the case of UEFI, it may be possible to explicitly ask for a certain operating mode at boot, but I am not familiar with that (yet).
- JoshTriplett 12y ago
  > In the case of UEFI, it may be possible to explicitly ask for a certain operating mode at boot, but I am not familiar with that (yet). That was the point of the comment you replied to. Normally, EFI either runs in 32-bit or 64-bit, and only loads and runs binaries for that mode.
JoshTriplett 12y ago
True, the portion of your OS that actually uses EFI services must work in both 32-bit and 64-bit mode, so you'll have to write it portably. That's somewhat easier since you don't need to write any assembly; you can write in any high-level language with an FFI to C. However, you can run a 64-bit OS with 32-bit EFI or vice versa; you just have to switch modes yourself. And you can defer that until later in the development of your OS.
- pgeorgi 12y ago
  Once you switch modes, you better stick to Runtime Services, so networking etc is out. But yes, for the beginning all that might not matter too much and you can get by running your "OS" as BDS application and incrementally migrate away from that.
  - JoshTriplett 12y ago
    Once you switch modes, you shouldn't touch EFI at all, and if you do, you'll have to switch back to do so.
    - pgeorgi 12y ago
      Even switching back and forth at the right times seems somewhat risky to me before ExitBootServices(), while Runtime Services are restricted to a subset that's much more resilient to external state changes (and doesn't run background stuff). NetBSD rump kernels may provide a better base for OS experiments where you can use working code until you have replacements ready - based on a real OS, not some API that accidentally became one.

but you don't get to decide whether to use 32bit or 64bit mode, your firmware does for you.

by pgeorgi 12y ago

but you don't get to decide whether to use 32bit or 64bit mode, your firmware does for you.

Firmware? No, the OS will have to explicitly choose the mode the CPU operates in. The PC, under "normal" legacy BIOS, always boots to 16 bit mode (like in OP). From there on, you manually have to change the processor operating mode to 32 bits (protected mode) or 64 bits (long mode), by setting some privileged registers and doing a jump to 32/64 bit code. In the case of UEFI, it may be possible to explicitly ask for a certain operating mode at boot, but I am not familiar with that (yet).

JoshTriplett 12y ago
> In the case of UEFI, it may be possible to explicitly ask for a certain operating mode at boot, but I am not familiar with that (yet). That was the point of the comment you replied to. Normally, EFI either runs in 32-bit or 64-bit, and only loads and runs binaries for that mode.

JoshTriplett 12y ago

True, the portion of your OS that actually uses EFI services must work in both 32-bit and 64-bit mode, so you'll have to write it portably. That's somewhat easier since you don't need to write any assembly; you can write in any high-level language with an FFI to C. However, you can run a 64-bit OS with 32-bit EFI or vice versa; you just have to switch modes yourself. And you can defer that until later in the development of your OS.

pgeorgi 12y ago
Once you switch modes, you better stick to Runtime Services, so networking etc is out. But yes, for the beginning all that might not matter too much and you can get by running your "OS" as BDS application and incrementally migrate away from that.
- JoshTriplett 12y ago
  Once you switch modes, you shouldn't touch EFI at all, and if you do, you'll have to switch back to do so.
  - pgeorgi 12y ago
    Even switching back and forth at the right times seems somewhat risky to me before ExitBootServices(), while Runtime Services are restricted to a subset that's much more resilient to external state changes (and doesn't run background stuff). NetBSD rump kernels may provide a better base for OS experiments where you can use working code until you have replacements ready - based on a real OS, not some API that accidentally became one.