Is there any point in making a 32bit OS anymore?

[TylerH]

I suspect that 64-bit processors will support legacy mode a long time yet, mostly so that 64-bit OSes can still run 32-bit programs. Those will need to be supported in the Windows environment for a long time yet.

I suspect you're right, seeing as they still support real mode. I don't think any big 80x86 maker is going to gamble(again) by breaking compatibility with even the 8086, more less the 80386. As you can see, the gamble, that is Itanium, didn't work out so well for Intel.

[rdos]

I suspect that 64-bit processors will support legacy mode a long time yet, mostly so that 64-bit OSes can still run 32-bit programs. Those will need to be supported in the Windows environment for a long time yet.

I suspect you're right, seeing as they still support real mode. I don't think any big 80x86 maker is going to gamble(again) by breaking compatibility with even the 8086, more less the 80386. As you can see, the gamble, that is Itanium, didn't work out so well for Intel.

Right, and every new 64-bit OS written today (including MS Windows), cannot operate without IA32, because 64-bit mode is defined to first setup protected mode (IA32), and then switch on to long mode. Also, the VBE interface is designed in such a way that it cannot work if 16-bit protected mode segmentation doesn't work. And many 64-bit OSes designed today to be able to change video resolution will need to resort to using this interface (unless they have specially built device-drivers for changing video mode, which would be an exception).

This means that as long as there is not a shift in how long mode is enabled, and a new VBE-interface, chip designers have no way of dropping IA32 support, andIA32 OSes will work just fine. Even those that rely on segmentation.

[JamesM]

I suspect that 64-bit processors will support legacy mode a long time yet, mostly so that 64-bit OSes can still run 32-bit programs. Those will need to be supported in the Windows environment for a long time yet.

I suspect you're right, seeing as they still support real mode. I don't think any big 80x86 maker is going to gamble(again) by breaking compatibility with even the 8086, more less the 80386. As you can see, the gamble, that is Itanium, didn't work out so well for Intel.

Right, and every new 64-bit OS written today (including MS Windows), cannot operate without IA32, because 64-bit mode is defined to first setup protected mode (IA32), and then switch on to long mode. Also, the VBE interface is designed in such a way that it cannot work if 16-bit protected mode segmentation doesn't work. And many 64-bit OSes designed today to be able to change video resolution will need to resort to using this interface (unless they have specially built device-drivers for changing video mode, which would be an exception).

This means that as long as there is not a shift in how long mode is enabled, and a new VBE-interface, chip designers have no way of dropping IA32 support, andIA32 OSes will work just fine. Even those that rely on segmentation.

I hardly think the fact that 40 or so lines of bootstrap assembly is required to get to long mode qualifies as a reason to damn solely 64-bit operating systems. Also regarding your previous point, there isn't exactly much x86 market penetration in embedded systems.

[Owen]

Right, and every new 64-bit OS written today (including MS Windows), cannot operate without IA32, because 64-bit mode is defined to first setup protected mode (IA32), and then switch on to long mode. Also, the VBE interface is designed in such a way that it cannot work if 16-bit protected mode segmentation doesn't work. And many 64-bit OSes designed today to be able to change video resolution will need to resort to using this interface (unless they have specially built device-drivers for changing video mode, which would be an exception).

This means that as long as there is not a shift in how long mode is enabled, and a new VBE-interface, chip designers have no way of dropping IA32 support, andIA32 OSes will work just fine. Even those that rely on segmentation.

No 64-bit OS needs to enter real or protected mode to setup long mode. Never heard of EFI? 64-bit EFI can enter 64-bit operating systems directly. This also obviates your VBE comment, because VBE is intrinsically BIOS linked; not that VBE matters too much anyway (or ever really worked in protected mode either).

Once people transition to EFI, Intel and AMD can, if they want, remove real mode and protected mode from their processors and dump them straight into one or another form of long mode. Transition complete.

(Whether they will or not is another matter. For the foreseeable future, I see it unlikely.)

[Gaidheal]

As discussed elsewhere, Long Mode can be entered directly from Real Mode, actually, even if the AMD64 documentation doesn't say so and actually details stepping up the chain. Even if this weren't so, it would not be a good argument for making 32 bit OSes, however, any more than the fact that all 8086 family processors start in Real Mode is an argument for making 16 bit Real Mode OSes.

Anyway, the question you asked is not the one you seem to really want answered, or rather, what you asked doesn't actually make any sense, the real question is whether 32 bit development is the right choice for your goals. For the record, I made a design choice, right from the get go, that my 'real' project will be a kernel that runs in Long Mode and gets there as close to immediately as is possible, that is to say, 64 bits across the board with no legacy support for 32 bit code. I have the luxury of having easy access to AMD64 hardware and actually most of the people I know who own PCs have an AMD64 platform as their current machine, though they usually also have an older IA-32 based machine gathering dust or as an alternative (such as a netbook or older laptop).

The real question is what you're looking to do and why. If you want to take on commerical, 'desktop user' operating systems then you probably do want to go for 64 bits, not least because the development time is long enough that you can probably safely ignore people who wouldn't be able to run it (think carefully about how many 32 bit users of today are actually running on AMD64 hardware in 32 bit Protected Mode - 'Legacy Mode' - before you try and flame me on that). That may or may not be a realistic goal, at all, of course. On the other hand if you're going for the 'lowest common denominator' of hardware, whilst strictly speaking that would Real Mode and 16 bits, it's generally accepted that ignoring anything earlier than a 386 is fair enough (after all, Microsoft managed it to great commercial success).

RE: RDOS's comment Owen's comment, I meant of course, (which appeared as I was posting), you're quite right but again we come back to the fact that what is common today is BIOS that effectively goes all the way back to the PC XT, at least.

[rdos]

I hardly think the fact that 40 or so lines of bootstrap assembly is required to get to long mode qualifies as a reason to damn solely 64-bit operating systems.

The mere fact that this code exist in present binaries of many OSes makes it dependent on a functioning IA32 mode.

[rdos]

No 64-bit OS needs to enter real or protected mode to setup long mode. Never heard of EFI?

You just move the switch from the OS to (U)EFI. The binary code is still there, meaning you cannot upgrade these systems with processors that don't support IA32.

64-bit EFI can enter 64-bit operating systems directly. This also obviates your VBE comment, because VBE is intrinsically BIOS linked; not that VBE matters too much anyway (or ever really worked in protected mode either).

And a 32-bit OS can either use (U)EFI to boot into 32-bit mode, or switch back to 32-bit mode with a dummy loader. The possible near-future replacement of BIOS with UEFI will not put an end to running 32-bit segmented OSes on these machines. Just as I can boot RDOS with GRUB (which enters the OS in a flat-memory model) by simply reverting to segmentation again, I can do the same from a 64-bit UEFI protocol that no longer supports 32-bit mode. The only thing that can stop this is removing IA32 from processors.

Once people transition to EFI, Intel and AMD can, if they want, remove real mode and protected mode from their processors and dump them straight into one or another form of long mode. Transition complete.

(Whether they will or not is another matter. For the foreseeable future, I see it unlikely.)

Possible, but unlikely. If it happens, it will take many years before it happens because Intel don't want to repeat their mistake with Itanium. BTW, EFI IS the legacy of Itanium.

[rdos]

The facts are that AMDs processor site does not even mention EFI, but instead provides a very long document targeted for BIOS developpers written april 2010. I cannot find any mention of EFI on Intels site either, and their Xeon server processor (7500 series) talks about virtualization and supporting 32 bit and 64 bit systems. Hardly any signs from any of these of dropping BIOS and/or IA32. They instead market themselves for compability.

I think it is wishful thinking that BIOS will be replaced by EFI to any significant extent anytime soon.

[JamesM]

The facts are that AMDs processor site does not even mention EFI, but instead provides a very long document targeted for BIOS developpers written april 2010. I cannot find any mention of EFI on Intels site either, and their Xeon server processor (7500 series) talks about virtualization and supporting 32 bit and 64 bit systems. Hardly any signs from any of these of dropping BIOS and/or IA32. They instead market themselves for compability.

I think it is wishful thinking that BIOS will be replaced by EFI to any significant extent anytime soon.

Most new motherboards are EFI, atom boards are EFI. Dropping BIOS != dropping IA32-e.

[rdos]

Most new motherboards are EFI, atom boards are EFI. Dropping BIOS != dropping IA32-e.

Not true. I have an eMachine's mini-PC with an Intel Atom processor, and it is not EFI. It runs fine with the old GRUB loader that loads a "dummy" image that switches the processor to 16-bit protected mode and starts RDOS kernel from there. Looking through the BIOS setup, there is not any mention of EFI anywhere. It was sold with Windows XP preinstalled.

I also have a dual-core Athlon processor (a few years old), and it is not EFI either.

[StephanvanSchaik]

I have got a lot of computers, recently bought one with an Asus motherboard. Even an Intel Atom N270 netbook is present among them. All of them run PC BIOS or OF. I can only name two companies that produce motherboards with (U)EFI and only one company that actually uses it: Intel, MSI and Apple. Most new motherboards aren't using (U)EFI instead of PC BIOS, especially when you consider how hard it is to just drop legacy hardware/software.


Regards,
Stephan J.R. van Schaik.

[Brynet-Inc]

Most new motherboards are EFI, atom boards are EFI. Dropping BIOS != dropping IA32-e.

Not true. I have an eMachine's mini-PC with an Intel Atom processor, and it is not EFI. It runs fine with the old GRUB loader that loads a "dummy" image that switches the processor to 16-bit protected mode and starts RDOS kernel from there. Looking through the BIOS setup, there is not any mention of EFI anywhere. It was sold with Windows XP preinstalled.

I also have a dual-core Athlon processor (a few years old), and it is not EFI either.

Actually, EFI is indeed replacing the traditional BIOS in x86/amd64 computers, but they provide a compatibility support module (CSM) to load legacy 16-bit operating systems (..or bootloaders).

I as well purchased a system from 2010, first time in very long time, it's an Acer Aspire 5551.. during POST it briefly mentions "InsydeH2O" which is an EFI firmware.

On the site they highlight that it's written in C, with "drivers" running in protected mode, even a non-EFI BIOS tends to run in protected mode now.

Early chipset and device initialization is totally operating mode agnostic, you can write a kernel that runs exclusively in 32/64-bit mode.. and on legacy x86 systems the boostrap will most likely need to operate briefly in another mode, but there very well could be a system and firmware cable of loading it directly one day.

We can all agree that x86 is a big clusterfuck, the concept of multiple operating mode is annoying, you just have to look at other more sane architectures and wonder.

[rdos]

At least I've now been able to separate DOS emulation / PC BIOS modules out of my OS image. I can run native (OpenWatcom) executables without any emulation (DOS or PC BIOS) support other than VBE. If the processor supports VME, and I have several new motherboards, including PPCL61 that doesn't, it is easy to handle VBE in V86 mode. If not, I'll need the CPU emulator module in order to be able to handle the traps on int xx, iret and similar that the PC BIOS will generate when switching video-mode. So, the only thing I need to do in order to handle EFI is to figure out how to boot using EFI, and how to switch video-modes (at run-time) using EFI. But until I have an EFI-enabled motherboard, I will do nothing.

[rdos]

Actually, EFI is indeed replacing the traditional BIOS in x86/amd64 computers, but they provide a compatibility support module (CSM) to load legacy 16-bit operating systems (..or bootloaders).

I as well purchased a system from 2010, first time in very long time, it's an Acer Aspire 5551.. during POST it briefly mentions "InsydeH2O" which is an EFI firmware.

Ah, ok. My laptop actually do use InsydeH20, and it does have a graphical interface, and it loads GRUBs boot-loader just fine.

We can all agree that x86 is a big clusterfuck, the concept of multiple operating mode is annoying, you just have to look at other more sane architectures and wonder.

No, it is actually a very good and long-time stable design, unlike most RISC processors that needs to be programmed in C (with frequent compiler rewrites). The only problem is that Intel tried to sabotage x86 architecture totally with Itanium, and when AMD later introduced their fix broke the chain of mode interoperability (IOW, 16/32 bit cannot live with 64 bit).

[JamesM]

No, it is actually a very good and long-time stable design, unlike most RISC processors that needs to be programmed in C (with frequent compiler rewrites).

Eh?!