My overall project objective is a developers tool kit and prototyping system. To date, I've loaded a disk image 0x800 - 0x8fb00 with my chain loader in a flat protected model. As 32 bit is native to the processors I use, logic dictates, develop system in 32 bit. In part, it will broaden the utility to older hardware and anything in 64 bit can be done in compatibility mode "I hope". My concern is predicated on the fact I code in assembly exclusively and even though it is my preference, it's not without drawbacks.
Is my logic sound or is a compatibly layer later going to present me with a problem in 64 bit that I'm not anticipating?
32 vs 64 Design Methodology
-
TightCoderEx
- Member
- Posts: 90
- Joined: Sun Jan 13, 2013 6:24 pm
- Location: Grande Prairie AB
-
chickendinner
- Posts: 11
- Joined: Thu Aug 01, 2013 9:47 am
Re: 32 vs 64 Design Methodology
I'm not sure what you mean. So you want to create a 64bit operating system that has a 32bit interface?
This is what Windows x86-64 does through a process called thunking (It calls a 32bit stub that then calls the 64bit API) with a negligible performance cost. Which works well and doesn't really have any restrictions apart from the address space of the process being capped at 4GB.
Or do want to develop a system in 32bit but are worried that porting to 64bit will be hard due to design choices you make?
The way the system works is very similar on 32bit and 64bit. There isn't really any major architectural features that will mess you up. I can think of a couple of things that you would never do anyway:
1. Use segmented memory protection instead of paging: Completely non-functional in longmode. Your GDT entries need to be flat and span the entire address space and you can't use the local descriptor tables.
2. Not use a higher half kernel. The canonical addressing scheme means a higher half kernel is required in x86-64.
3. Rely on v86 mode to access BIOS interrupts. Removed in long mode. You'll need to emulate your BIOS interrupts with an 8086 emulator.
4. Use hardware task switching: It shouldn't be used on 32bit either due to horrible performance but it's unusable in x86-64.
These things were never used in modern 32bit Operating systems anyway, the only real difference is they now no longer work at all. If you don't use these the only real difference is the amount of addressable memory you can use. There are other little quirky differences like long mode using instructions like gswap to get a kernel stack pointer easily, but they can worked out and rewritten in little time.
Your actual assembly code when porting to 64bit mode won't need to be completely rewritten, just heavily modified. The general instruction set is mostly a superset 32bit mode code. It's actually usually optimal to use 32bit opcodes and 32bit variables most of the time and only use 64bit instructions when storing and loading from memory or working with pointers or values that actually need be 64bits wide.
(FYI compatibility mode != 32bit protected mode and is not available on 32bit only processors, compatibility mode is a submode of longmode so it can use the long mode page tables and the legacy architectural features that were removed from long mode also don't work in compatibility mode while in the 32bit protected mode they would).
This is what Windows x86-64 does through a process called thunking (It calls a 32bit stub that then calls the 64bit API) with a negligible performance cost. Which works well and doesn't really have any restrictions apart from the address space of the process being capped at 4GB.
Or do want to develop a system in 32bit but are worried that porting to 64bit will be hard due to design choices you make?
The way the system works is very similar on 32bit and 64bit. There isn't really any major architectural features that will mess you up. I can think of a couple of things that you would never do anyway:
1. Use segmented memory protection instead of paging: Completely non-functional in longmode. Your GDT entries need to be flat and span the entire address space and you can't use the local descriptor tables.
2. Not use a higher half kernel. The canonical addressing scheme means a higher half kernel is required in x86-64.
3. Rely on v86 mode to access BIOS interrupts. Removed in long mode. You'll need to emulate your BIOS interrupts with an 8086 emulator.
4. Use hardware task switching: It shouldn't be used on 32bit either due to horrible performance but it's unusable in x86-64.
These things were never used in modern 32bit Operating systems anyway, the only real difference is they now no longer work at all. If you don't use these the only real difference is the amount of addressable memory you can use. There are other little quirky differences like long mode using instructions like gswap to get a kernel stack pointer easily, but they can worked out and rewritten in little time.
Your actual assembly code when porting to 64bit mode won't need to be completely rewritten, just heavily modified. The general instruction set is mostly a superset 32bit mode code. It's actually usually optimal to use 32bit opcodes and 32bit variables most of the time and only use 64bit instructions when storing and loading from memory or working with pointers or values that actually need be 64bits wide.
(FYI compatibility mode != 32bit protected mode and is not available on 32bit only processors, compatibility mode is a submode of longmode so it can use the long mode page tables and the legacy architectural features that were removed from long mode also don't work in compatibility mode while in the 32bit protected mode they would).
-
TightCoderEx
- Member
- Posts: 90
- Joined: Sun Jan 13, 2013 6:24 pm
- Location: Grande Prairie AB
Re: 32 vs 64 Design Methodology
Your points are succinct enough that when all is considered, 64 is the way to go. I develop on a 64 bit machine and test on an AMD Sempron. The Lenovo system has pretty much everything I need, especially the ability to boot from USB. Thanks for the input, it did help narrow my focus.
Re: 32 vs 64 Design Methodology
If designed correctly, most of the OS should not need to care if it is running in protected mode or compatibility mode. My OS switches in and out of long mode when needed, to seamlessly run V86 and 64 bit applications alongside each other.
-
TightCoderEx
- Member
- Posts: 90
- Joined: Sun Jan 13, 2013 6:24 pm
- Location: Grande Prairie AB
Re: 32 vs 64 Design Methodology
The point in a nutshell. My OS is for me and all the goodies I envision a prototyping system should have. I was getting too hung up on compatibility and that was skewing my focus. Currently I am working on a console interface, keyboard and mouse using Pure64 as a backbone until I can extract information from my system independent Bochs. Then I'll drop back to the OS part and start implementing all my own drivers and interrupts.Gigasoft wrote:If designed correctly