Hey I just start watching the first video of this series. I’m really interested about low level programming stuff, and building an OS is quite a huge project! I struggle a lot to find interesting project in low level, but finding your channel, with the terminal stuff.. And THIS ! Thanks ! Also, all of this is written in Rust, and I just moved from C to Rust, i’m gonna learn with you for the next 66 videos of this playlist aha :)
I'm really happy I found this series of videos. I've recently toyed with the idea of building my own kernel (in Rust), mostly because I wanted to use anything other than C/C++ :) I'll be interested to see how things go from here.
pro tip, when compiling gcc, do -j 16 (or whatever amount of jobs you want, I just looked at htop and looked at the amount of things there, 16 for me) the build went from over 10 minutes (I waited for over 10 minutes, but then just canceled it to try using -j) to under a minute.
Unless I'm misunderstanding you, I think this tip is more of a "make" or "ninja" tip. AFAIK gcc doesn't support running with multiple threads. In this video we did attempt to use a makefile, but pivoted to just using a shell script. This had the benefit of actually working, but would lose the parallelism of using multiple threads (if we were compiling enough translation units for it to be relevant) IIRC, there _are_ multi-threaded linkers though. On large builds, the linking step can actually take so long that the linker supporting -j flags is actually super useful. For compiling usually a project is split up enough that just compiling individual translation units on different threads is good enough. IIRC both mold and lld support this, but will pick -j ${NUM_CPUS} by default anyways. In this video though, our build times were essentially instant, so I'm not really sure how this applies here, but it is a good tip!
would using clang instead of GCC make it a bit easier since you would need less setup to get the cross compiler going since LLVM is inherently architecture-agnostic?
regarding the .bss stuff around 9:00 .bss doesnt actually contain anything in the binary itself, so your attempt to store and refer to a static int was never going to work the way you expected it to. If you instead initialized that int to some value, and then looked at the data section you should be able to find it. I will say though that in long form videos like this, I would much prefer to see someone actually take the time to read through a page like the stackeachange answer you glanced at, rather than flail wildly at something that is clearly wrong because you didn't want to take a moment to actually read something. I know that when recording a video you don't want to bore the audience with 2 hours of reading, but uh, your first half hour is already you just reading through stuff anyway, might as well take a few minutes more to slow down and pay a bit more attention to things. If this was 2 hours instead of 1, but the first hour was you patiently reading through the same stuff, I'd be just as willing to watch it, if not more so. The people with no attention span will already ignore an hour long video anyway.
I think you're a little confused CPUs don't run exes, they run a set of instructions that they support, often referred to as "machine code". This is a set of low level instructions, e.g. load memkry, add these two number, etc. An exe bundles machine code, but it also has a bunch of headers that tell windows what to do with the file. E.g. where in this file are the instructions that i want the cpu to run, what libraries do i use, etc. We would probably say that the operating system runs exes, but the cpu runs machine code ASM is just a human readable form of the machine code, no component really runs this directly When your computer boots, there isnt really an operating system. IIRC theres a hard coded address that the cpu just starts executing at, and this ends up being in the motherboards eeprom. This will load the bios, and the bios will eventually run some other machine code running at some other address Our operating system assumes a bootloader, so we havent looked too closely at what sits between bios and OS, but both the bios and bootloader dont really load files, they just jump to some spot in memory and start executing This is where we are starting. So to address your points directly * qemu boots asm files - no, it runs assembled machine code just like your computer * normal pcs boot from exes - no, windows loads executables from exes, but this is much much much after booting * this doesnt help making an os - i dont really know what to say here other than "yes it does"
Hi, how long would it take me to write an OS from scratch if I work on it about 4 hours a day, for the sole purpose of learning how stuff works?. Also it doesn't need to be complete just something I can play around with.
I don't know you, so hard to say. You can get a bit of a feel by browsing the github commits (and checking dates) associated with the project github.com/sphaerophoria/stream-os or looking at the playlist ua-cam.com/video/gBykJMqDqH0/v-deo.html Playlist indicates 66 videos, 2h of coding a day with maybe some extra cleanup and reading on the side. Lets assume 2h reading, 2h writing for each video -> 264h for the project. The OS was "usable" by some definition of usable day 1 though, so it really depends on your goals. By other definitions of usable it's still not usable :P
There’s gigavalue in demonstrating your research process. Thanks for the vid
Hey I just start watching the first video of this series. I’m really interested about low level programming stuff, and building an OS is quite a huge project! I struggle a lot to find interesting project in low level, but finding your channel, with the terminal stuff.. And THIS ! Thanks ! Also, all of this is written in Rust, and I just moved from C to Rust, i’m gonna learn with you for the next 66 videos of this playlist aha :)
I feel like I'm in the same boat. It's so hard but so interesting! Thanks for the video!
Fascinating
This Steam Simulator app makes me feel Like a little Kid that needs Subway gameplay in the Background to keep my attention
bro same. it's actually soooo distracting 😭
I'm really happy I found this series of videos. I've recently toyed with the idea of building my own kernel (in Rust), mostly because I wanted to use anything other than C/C++ :) I'll be interested to see how things go from here.
love it. is not just copy paste, is getting the warm up done haha
23:40 i believe GDT is more for segmentation which is like a simple early version of paging
pro tip, when compiling gcc, do -j 16 (or whatever amount of jobs you want, I just looked at htop and looked at the amount of things there, 16 for me)
the build went from over 10 minutes (I waited for over 10 minutes, but then just canceled it to try using -j) to under a minute.
Unless I'm misunderstanding you, I think this tip is more of a "make" or "ninja" tip. AFAIK gcc doesn't support running with multiple threads.
In this video we did attempt to use a makefile, but pivoted to just using a shell script. This had the benefit of actually working, but would lose the parallelism of using multiple threads (if we were compiling enough translation units for it to be relevant)
IIRC, there _are_ multi-threaded linkers though. On large builds, the linking step can actually take so long that the linker supporting -j flags is actually super useful. For compiling usually a project is split up enough that just compiling individual translation units on different threads is good enough. IIRC both mold and lld support this, but will pick -j ${NUM_CPUS} by default anyways.
In this video though, our build times were essentially instant, so I'm not really sure how this applies here, but it is a good tip!
@@sphaerophoria it was a tip for building the cross compiler
Ah, gotcha
here for the magic
would using clang instead of GCC make it a bit easier since you would need less setup to get the cross compiler going since LLVM is inherently architecture-agnostic?
God!
Chad
49:27 i think you just forgot to recompile?
cool, now write a lisp machine, in lisp.
going through strace is like reading ancient hieroglyphics for us noob programmers, thanks mannn
it's just system calls my man
@@gianni50725 for me who's a forever noob, it's magic heh
regarding the .bss stuff around 9:00 .bss doesnt actually contain anything in the binary itself, so your attempt to store and refer to a static int was never going to work the way you expected it to. If you instead initialized that int to some value, and then looked at the data section you should be able to find it.
I will say though that in long form videos like this, I would much prefer to see someone actually take the time to read through a page like the stackeachange answer you glanced at, rather than flail wildly at something that is clearly wrong because you didn't want to take a moment to actually read something. I know that when recording a video you don't want to bore the audience with 2 hours of reading, but uh, your first half hour is already you just reading through stuff anyway, might as well take a few minutes more to slow down and pay a bit more attention to things. If this was 2 hours instead of 1, but the first hour was you patiently reading through the same stuff, I'd be just as willing to watch it, if not more so. The people with no attention span will already ignore an hour long video anyway.
i feel like QEMU only boots ASM files and normal PCs boot from like COM or EXE files, so this doesnt help making an OS.
I think you're a little confused
CPUs don't run exes, they run a set of instructions that they support, often referred to as "machine code". This is a set of low level instructions, e.g. load memkry, add these two number, etc.
An exe bundles machine code, but it also has a bunch of headers that tell windows what to do with the file. E.g. where in this file are the instructions that i want the cpu to run, what libraries do i use, etc. We would probably say that the operating system runs exes, but the cpu runs machine code
ASM is just a human readable form of the machine code, no component really runs this directly
When your computer boots, there isnt really an operating system. IIRC theres a hard coded address that the cpu just starts executing at, and this ends up being in the motherboards eeprom. This will load the bios, and the bios will eventually run some other machine code running at some other address
Our operating system assumes a bootloader, so we havent looked too closely at what sits between bios and OS, but both the bios and bootloader dont really load files, they just jump to some spot in memory and start executing
This is where we are starting. So to address your points directly
* qemu boots asm files - no, it runs assembled machine code just like your computer
* normal pcs boot from exes - no, windows loads executables from exes, but this is much much much after booting
* this doesnt help making an os - i dont really know what to say here other than "yes it does"
@@sphaerophoria ok.
@@AlisalandOfficiallol
Hi, how long would it take me to write an OS from scratch if I work on it about 4 hours a day, for the sole purpose of learning how stuff works?. Also it doesn't need to be complete just something I can play around with.
I don't know you, so hard to say. You can get a bit of a feel by browsing the github commits (and checking dates) associated with the project github.com/sphaerophoria/stream-os or looking at the playlist ua-cam.com/video/gBykJMqDqH0/v-deo.html
Playlist indicates 66 videos, 2h of coding a day with maybe some extra cleanup and reading on the side. Lets assume 2h reading, 2h writing for each video -> 264h for the project. The OS was "usable" by some definition of usable day 1 though, so it really depends on your goals. By other definitions of usable it's still not usable :P