Do I Go 64 Bit Now?

AJ · Post by AJ » Sat Sep 29, 2007 2:31 am

Hi,

Recently, I have been starting to add SMP support to by OS (sounds good, but still at an early stage!) and so have got in to the world of using the APIC instead of the PIC. This got me thinking about whether to cease support for 'legacy' hardware in a bigger way.

I had always intended to have a bash at a 32 bit OS and then maybe look at long mode, but I am currently liking the idea of going on to a 64 bit OS now. Only problem is - I don't currently have 64 bit real hardware so I would be relying on emulation in the early stages of development (until I can afford to build a new PC - which is on the shopping list anyway!).

So - what would you do? Stick with the 32 bit OS and try to improve that in a big way, or go straight on to the more up-to-date 64 bit? If I make my 32 bit OS 'complete' and then want to port it later, will that be more of a nightmare than if I switch to 64 bit now?

Any thoughts appreciated!
Cheers,
Adam

JamesM · Post by **JamesM** » Sat Sep 29, 2007 3:53 am

I'm making two versions. I already have the directory structure set out for multiple targets (like linux all the arch specific stuff is in /arch/x86 | /arch/x86_64 etc).

So essentially there will be 4 variants:

x86_32
x86_32SMP
x86_64
x64_64SMP

possibly to add more later, depending on what hardware I can test it.

AJ · Post by AJ » Sat Sep 29, 2007 4:29 am

Sounds good - I'll go and have a look at the source from the site in your sig when I get a chance - I haven't really though of being 'cross-platform friendly' up until now so I'll look at how it's done.

At the moment, I have a /cpu folder which contains things like cli(), sti(), hlt(), lgdt() and so on, because I would rather have these in asm modules than use inline assembly. Perhaps 'classing' these functions (I'm using CPP) and providing a different CPU class for each processor type is the way to go...

Cheers,
Adam

bluecode · Post by **bluecode** » Sat Sep 29, 2007 8:04 am

I also have a 32 and a 64bit version. But within the kernel it is not yet separated as clean as I would like it to be (I am thinking of a x86, x86_64 and a x86-shared subdirectory currently). My advice is to port your OS as soon as possible or it will be a big mess (and perhaps you loose motivation and just stick with a 32bit version). I also create separate crosscompilers for each architecture.
I started SMP support many months ago, I got to the stage where all application processors are booted into the correct mode (protected or longmode). If you want SMP you have to ./configure with "--smp".
Link is in my signature.

Dex · Post by **Dex** » Sat Sep 29, 2007 1:49 pm

I would say stay with 32bit, but when making design decision's, remember that it will need to be ported to long mode.
The best 64bit hobby OS example is menuetos, which was ported in about 9 months, which would of taken much longer to code a multi-taking OS from scratch.

From my OS's design point of view, it was designed from the start, to have 3 option's at bootup realmode, pmode, long mode.
But i think is should be possible to run long mode programs from pmode with my OS design, with the right libs.

bluecode · Post by **bluecode** » Sat Sep 29, 2007 2:58 pm

Dex wrote:The best 64bit hobby OS example is menuetos, which was ported in about 9 months, which would of taken much longer to code a multi-taking OS from scratch.

honestly, I think an OS written in assembler can not serve as a good example for 'portable'. Besides 9 months is a very long time to port something to an architecture that is not that different. From my subversion logs I'd say I had a working 64bit version after about 1month (there were some bugs till recently though).
btw. do they manage the two versions (32bit and 64bit) in one codebase or are they completely separated from each other (in terms of sourcecode)?

Dex · Post by **Dex** » Sat Sep 29, 2007 3:23 pm

bluecode wrote:
Dex wrote:The best 64bit hobby OS example is menuetos, which was ported in about 9 months, which would of taken much longer to code a multi-taking OS from scratch.
honestly, I think an OS written in assembler can not serve as a good example for 'portable'. Besides 9 months is a very long time to port something to an architecture that is not that different. From my subversion logs I'd say I had a working 64bit version after about 1month (there were some bugs till recently though).
btw. do they manage the two versions (32bit and 64bit) in one codebase or are they completely separated from each other (in terms of sourcecode)?

So give me a better example of a hobby OS thats been ported from 32bit to 64bit ?.
As for taking 9 months, its a gess on my part. But as the 32bit part is open source and the 64bit is closed source, than the answer must be the sourcecode is completely separated from each other.

os64dev · Post by **os64dev** » Sun Sep 30, 2007 3:47 am

I would go for 64-bit only as all future processors will likely to be supporting that and your OS wouldn't be complete in the next few years.
Further more you have more registers and your interrupt model is way easier.So 3 words performance, performance, performance

.
This is what i am currently doing i've played a bit with 64 bit and am now redesigning from scratch. A 64-bit only microkernel.

FutureDomain · Post by **FutureDomain** » Sat Nov 03, 2007 12:11 am

os64dev wrote:I would go for 64-bit only as all future processors will likely to be supporting that and your OS wouldn't be complete in the next few years.
Further more you have more registers and your interrupt model is way easier.So 3 words performance, performance, performance .
This is what i am currently doing I've played a bit with 64 bit and am now redesigning from scratch. A 64-bit only microkernel.

I would certainly agree. I had most of the same thoughts others had (make it 32-bit and port it to 64-bit later), but after looking at the AMD manuals, the 64-bit long mode is much simpler to use than the old 32-bit protected mode. Another reason was my design (SIP model, like Singularity) would only allow 4-GB of virtual memory total in a 32-bit system, whereas the address space limit is huge in a 64-bit system (AMD doesn't even use the full 64 bits, it only uses the first 48-56 bits). More registers that are 64-bits wide is also pretty much required for my nanokernel design (I pass RPC arguments in them).

I might try and backport it to 32-bit if there's a strong demand for it, but I'll have some limits (like the 4GB memory limit) and it'll require several kludges to get it to work.

My recommendation is to design the system for a 64-bit processor and then figure out how to get it to work on a 32-bit processor. I'll help you prepare for the future when 32-bit processors will go the way of MS-DOS.