Hello.
I've been reading the tutorials on the wiki here at osdev.org and found them very helpful. Unfortunately I've been reading around on this forum and apparently:
1) BIOS is becoming more depreciated
2) 32bit is also becoming more depreciated
If this is correct, could anybody redirect me in the correct direction? Also, why are the wiki tutorials still reflecting BIOS/32bit?
Future proofing
Re: Future proofing
Read on Brendan's response to http://forum.osdev.org/viewtopic.php?f=1&t=26482
BIOS is becoming obsoleted, and it is already being emulated on top of uEFI application on some hardware; however it should still be usable in a few years, and the most important part is that you should design your OS or boot code that rely less on BIOS so that you face less impact for the transition.
32-bit system is however not entirely depreciate, it is widely used on mobile.
BIOS is becoming obsoleted, and it is already being emulated on top of uEFI application on some hardware; however it should still be usable in a few years, and the most important part is that you should design your OS or boot code that rely less on BIOS so that you face less impact for the transition.
32-bit system is however not entirely depreciate, it is widely used on mobile.
Re: Future proofing
Thank you, but I don't plan on developing for mobile platforms.
Also, my two questions still remain, where can I find more updated information?
Also, my two questions still remain, where can I find more updated information?
Re: Future proofing
Information about both these subjects is widely available via Google. The best reference for 64-bit assembler programming is the Intel (or AMD) Programmer's Reference Manual.
Re: Future proofing
I appreciate the reference, but I'm a newbie and need a bit of a helping hand, do you know any modern books or online resources?
Re: Future proofing
Hi,
For 64-bit it's probably best to start with your favourite Intel or AMD manual.
Cheers,
Brendan
For UEFI:DrHaximus wrote:Thank you, but I don't plan on developing for mobile platforms.
Also, my two questions still remain, where can I find more updated information?
- http://wiki.osdev.org/UEFI
- http://www.uefi.org/home (specs, etc)
For 64-bit it's probably best to start with your favourite Intel or AMD manual.
Cheers,
Brendan
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.
Re: Future proofing
Cheers!
Have a good day everyone.
Have a good day everyone.
Re: Future proofing
You can find more information, and references, about UEFI in this Wiki: http://wiki.osdev.org/UEFI
Re: Future proofing
To be really future proof I recommend modularizing your OS correctly.
E.g. why would you want to use the BIOS? To get the memory map and to load your kernel from the boot device. Both those things can be combined into a module, let's call it the boot loader. If done correctly the boot loader will hand over control with a defined state to the loaded kernel. The Multiboot specification is a good example of that. Then as Brendan already pointed out it doesn't matter whether your kernel is booted via BIOS, UEFI, coreboot or PXE.
Then do the same with your entire OS. 32bit vs 64bit? Why not use a programming language to hide the differences? So instead of using assembler use C. I was able to "port" a small 32bit x86 kernel to 64bit by merely recompiling it to x86_64, granted I had to modify the boot up process a little so I could call my kernel's entry point in 64bit but on the grand scheme of things this was neglectable. But for this to work you need to be aware of how your C code is compiled to machine code, e.g. you should avoid ambiguous types such as int, unsigned int, ... but rather make your own (or use the one's from stdint.h) int32_t, uint32_t, ... this way you should not have any problems moving between architectures.
Next you must also encapsulate all your hardware dependent code, like drivers. This starts with simple functions such as I/O ports. You might feel tempted to just use inline assembler or whatnot, but you should rather make an interface to the I/O ports which you can then use in both 32bit and 64bit.
Then also do this for your memory management. x86 vs x86_64 paging can be hidden behind an interface, as well, etc.
Now if you do this for you entire OS - that is always thoroughly investigation whether particular code or routine is machine dependent or not 32bit vs 64bit should not be a problem. x86 vs ARM vs PPC will be a little harder to tackle but if modularization of dependant and independent is followed by the book it will also be no problem.
E.g. why would you want to use the BIOS? To get the memory map and to load your kernel from the boot device. Both those things can be combined into a module, let's call it the boot loader. If done correctly the boot loader will hand over control with a defined state to the loaded kernel. The Multiboot specification is a good example of that. Then as Brendan already pointed out it doesn't matter whether your kernel is booted via BIOS, UEFI, coreboot or PXE.
Then do the same with your entire OS. 32bit vs 64bit? Why not use a programming language to hide the differences? So instead of using assembler use C. I was able to "port" a small 32bit x86 kernel to 64bit by merely recompiling it to x86_64, granted I had to modify the boot up process a little so I could call my kernel's entry point in 64bit but on the grand scheme of things this was neglectable. But for this to work you need to be aware of how your C code is compiled to machine code, e.g. you should avoid ambiguous types such as int, unsigned int, ... but rather make your own (or use the one's from stdint.h) int32_t, uint32_t, ... this way you should not have any problems moving between architectures.
Next you must also encapsulate all your hardware dependent code, like drivers. This starts with simple functions such as I/O ports. You might feel tempted to just use inline assembler or whatnot, but you should rather make an interface to the I/O ports which you can then use in both 32bit and 64bit.
Then also do this for your memory management. x86 vs x86_64 paging can be hidden behind an interface, as well, etc.
Now if you do this for you entire OS - that is always thoroughly investigation whether particular code or routine is machine dependent or not 32bit vs 64bit should not be a problem. x86 vs ARM vs PPC will be a little harder to tackle but if modularization of dependant and independent is followed by the book it will also be no problem.