4 ms·

bit sad in the era of 64 bit computing still every resource is at most about protected mode. osdev wiki has some info about long mode, but it's all fragmented.

bit sad in the era of 64 bit computing still every resource is at most about protected mode. osdev wiki has some info about long mode, but it's all fragmented. Been working now for ages to try to decipher amd and intel manuals about that :'). Still ,nice this page, always good to inspire people to write their own system softwares because i think it's to much 'magic' still where as it's doable even for 1 person to write an OS that is dedicated to for example a single task runnign in user mode. writing a multi-user / multi-purpose OS is maybe more work, but in those OSs a lot of problems exist today which is causing a need for people (imho) to step back and look at if this is really the way we want to go with computing... i don't see why a webserver or something with a single purpose like that needs to be on a multi-purpose OS. It just increases complexity and overhead and people have a world of trouble configuring an OS to do just 1 task good, have to stip our 90% of what comes with a basic install to reduce attack surface and get resource usage under control. I hope we will see more dedicated purpose OSes come up which handle 64 bit, and perhaps someday some resources for programming specifically that. I'm thinking of sharing some of my knowledge on the area sometime, but i dont know how much interest there is and seeing as i'm a bad writer and still pretty shit coder it will probarbly take me too much time now compared to how much use it would be (if i do it, compared to some veteran in the field!).

eadmund 9y ago
> bit sad in the era of 64 bit computing still every resource is at most about protected mode. I've an interest in writing a hobbyist OS, and I completely agree. Also, (almost) everything focuses on BIOS, rather than UEFI. And again, (almost) everything focuses on calling things from C, with a minimal amount of assembly, rather than doing everything from assembly. I'd like to see a resource which walks through an honest-to-goodness minimal UEFI application written in assembly. At the moment, I think that I'll need to write it myself …
- pjmlp 9y ago
  On the doing everything from Assembly. https://www.cl.cam.ac.uk/projects/raspberrypi/tutorials/os/index.html https://www.cl.cam.ac.uk/projects/raspberrypi/tutorials/os/i...
- vectorEQ 9y ago
  I do a lot with assembly. most of the code that launches long mode is easier / essential to be in assembly. I personally opted for using GRUB, but now i have a good idea on what that does for me i want to go back to writing a bootloader for my OS too. (done some basic ones, but didn't really know what information i had to pass. multiboot info from grub contains this). I dont use UEFI, but i think there you will need to consult the EFI manuals and use the SDK for EFI to build a module. This module then takes over from the boot loader, so in essence you will need code in there that gathers a memory map/info, vbe and apm informations, ACPI pointer (rsdp) and some more informations. efi is a firmware framework, so using an sdk here makes sense. otherwise you need to find out the offsets to the firmware functions yourself. BIOS uses interrupts for this but not sure how uefi does it sorry, i never tried! I will say that once you land in kernel land C is really nice. it saves a lot of typing. But i started out using pure assembly as it made more sense typing these instructions based on the manuals, c can be a bit too obscure to translate too if you're starting out. (still have trouble :') sometimes ...) Also stuff like loading CR3 with new page table pointer etc. just isn't possible atall in C. (you can inline it with asm volatile (); but inline asm is tedious in itself...) i'd reccomend using GRUB bootloader, then you can write a loader stub in there which moves the CPU into 64 bit mode and is in ELF format, so you can also compile the os itself in ELF format. I used to use binary blobs from nasm, but i had a world of trouble generating C code into binary blobs. The linking procedure to link a 32 bit loader into a 64 bit kernel is a bit tedious but once it's working you can have 1 script which only does some generation of .o files and links it all together instead of catting binary blobs together and using hardcoded offsets to load them into memory etc. (that was a fun adventure, but really caused me a lot of headache more than anything :D) if you want to do your own bootloader, consider that you should really write an ELF parser. i dont like the idea of sticking with some file format that's made by other people, but if you want to do it in your own executable format then you need to figure out to write a compiler / assembler for that format which is a lot of work. hence the choice to make an elf parser will get you started easier. if you want to just use nasm -fbin to make everything binary blobs you need to figure out how you will load everything and create mappings in pages to contain data. hardcode a lot of things which the linker/loader usually does for you. i think this will be the next level :D i can't imagine a better project for learning about how computers really works :D reccomened for anyone interested in computers!

eadmund 9y ago

> bit sad in the era of 64 bit computing still every resource is at most about protected mode. I've an interest in writing a hobbyist OS, and I completely agree. Also, (almost) everything focuses on BIOS, rather than UEFI. And again, (almost) everything focuses on calling things from C, with a minimal amount of assembly, rather than doing everything from assembly. I'd like to see a resource which walks through an honest-to-goodness minimal UEFI application written in assembly. At the moment, I think that I'll need to write it myself …

pjmlp 9y ago
On the doing everything from Assembly. https://www.cl.cam.ac.uk/projects/raspberrypi/tutorials/os/index.html https://www.cl.cam.ac.uk/projects/raspberrypi/tutorials/os/i...
vectorEQ 9y ago
I do a lot with assembly. most of the code that launches long mode is easier / essential to be in assembly. I personally opted for using GRUB, but now i have a good idea on what that does for me i want to go back to writing a bootloader for my OS too. (done some basic ones, but didn't really know what information i had to pass. multiboot info from grub contains this). I dont use UEFI, but i think there you will need to consult the EFI manuals and use the SDK for EFI to build a module. This module then takes over from the boot loader, so in essence you will need code in there that gathers a memory map/info, vbe and apm informations, ACPI pointer (rsdp) and some more informations. efi is a firmware framework, so using an sdk here makes sense. otherwise you need to find out the offsets to the firmware functions yourself. BIOS uses interrupts for this but not sure how uefi does it sorry, i never tried! I will say that once you land in kernel land C is really nice. it saves a lot of typing. But i started out using pure assembly as it made more sense typing these instructions based on the manuals, c can be a bit too obscure to translate too if you're starting out. (still have trouble :') sometimes ...) Also stuff like loading CR3 with new page table pointer etc. just isn't possible atall in C. (you can inline it with asm volatile (); but inline asm is tedious in itself...) i'd reccomend using GRUB bootloader, then you can write a loader stub in there which moves the CPU into 64 bit mode and is in ELF format, so you can also compile the os itself in ELF format. I used to use binary blobs from nasm, but i had a world of trouble generating C code into binary blobs. The linking procedure to link a 32 bit loader into a 64 bit kernel is a bit tedious but once it's working you can have 1 script which only does some generation of .o files and links it all together instead of catting binary blobs together and using hardcoded offsets to load them into memory etc. (that was a fun adventure, but really caused me a lot of headache more than anything :D) if you want to do your own bootloader, consider that you should really write an ELF parser. i dont like the idea of sticking with some file format that's made by other people, but if you want to do it in your own executable format then you need to figure out to write a compiler / assembler for that format which is a lot of work. hence the choice to make an elf parser will get you started easier. if you want to just use nasm -fbin to make everything binary blobs you need to figure out how you will load everything and create mappings in pages to contain data. hardcode a lot of things which the linker/loader usually does for you. i think this will be the next level :D i can't imagine a better project for learning about how computers really works :D reccomened for anyone interested in computers!