Thank you! :) The linux setup is nothing special just Konsole as terminal and tmux with very few tweaks I was worried that the video might be too long with 37 minutes and was thinking about re-recording it again. But I'm happy to hear that you find it straight to the point.
The reason why I prefer rust over C is that rust is way more ergonomic (once you understand the basics and overcome your first fight with the borrow checker and such) and it's more difficult to make certain mistakes (especially memory safety and concurrency related). Whether one is better than the other honestly depends on the use case for me. There are drawbacks for using rust just like there are drawbacks for using C. In the case of an operating system I prefer the robustness and guidance of rust even if it means that using it is not as simple and maybe not even quite as fast as C.
Maybe you can try and use AstroNvim, it has great rust support and its visually nicer. All in all I liked the video, now I'm going to try that myself. But, will you continue with this to you know have few things that we can do once it starts, that would be awesome.
Thanks for the suggestion though I am quite happy with vanilla vim. I will certainly continue this series, this is just the start. The goal of this series is to write a simple operating system that is capable of running multiple processes. After that it's up to the user to take it where they want it.
@@RootsterAnon It's possible because we're not using write_volatile(), as you saw at the end it also didn't work for me when I used print in the panic handler. To enable the floating point unit you can put this code into your boot.s: # Enable floating point bits FPEN mrs x7, cpacr_el1 mov x8, #(3
@@arryndoestech maybe you can address some of this in a new episode, btw, your gdb workflow is great, i just recreated it on my side, sick! Can you talk about heap in the next video, i tried to implement it and initialize it myself but got stuck. Just idea.
Made with rust 🔥🔥🔥 Blazingly fast 🚀🚀🚀 btw it`s funny how the first thing you do after making your entrypoint is writing some unsafe c-style puts and putchar. i guess C is just burnt in our brains already.
There is not really many other options to implement this as far as I know. We are writing to a device, for which you normally use write_volatile() on a raw pointer. I didn't do that because it seems that write_volatile() uses the floating point unit and since the video was already so long I didn't want to enable that in this episode. Especially in OSdev you will have to write a bunch of unsafe code.
@@arryndoestech got it. just interesting how libc somehow set the standard for naming functions and people use it even when writing rust. these names may be shitty and not very descriptive (idk, they just feel old to me), but for some reason people are still using them where it`s not even necessary. it puts char? -- then it`s "putchar". it puts a string? -- then it`s "puts".
@@namelastname3772 yeah as programmers I think we're all familiar with libc functions to a degree so naming functions similar makes sense, but I could've named them anything else I'd like. The code I wrote is safe though because the serial device on this platform is always at this address so I know I'm not accessing any invalid memory. Unsafe means just that it's on me as the programmer to verify that this is a safe operation
The code itself will be very different With uefi the compiler setup is plug and play, without it if things havent changed then you'd need to write the 16 bit bootcode (if you choose to write a bootloader too) in assembly. But as for details I'm not sure, x86_64 was always a mess that I'm not keen on learning. I also dont use any x86 machines and probably won't ever again.
Subbed man. Years back had plan to work with LFS but timing didnt worked well. Now trying to build Ben Eater style 6502 currently at 8 bit bus/register design (kinda stalled) but plan to make my OS for thsi 8 bit system.
Thank for the sub! That sounds like a really cool project. I really enjoyed the videos from Ben Eater. If you're pulling through, it would be really cool if you made a video showcasing your project!
Great video! Exactly what I was looking for. Going to watch the rest of the series now.
This is so great, the level of explanation is perfect. I hope you keep doing videos!
Thank you for your feedback.
I'll certainly make more videos very soon
i wish i could be this good some day
You got this! Keep on working on projects and do whatever you love and you'll certainly gain more and more experience :)
@@arryndoestech thx:)
I love this video.
Straight to point. Well explained. Cool linux setup. Rust :3
Thank you! :)
The linux setup is nothing special just Konsole as terminal and tmux with very few tweaks
I was worried that the video might be too long with 37 minutes and was thinking about re-recording it again. But I'm happy to hear that you find it straight to the point.
Its nice to see this. Everybody says that rust is better than c but we will have to prove it over Time
The reason why I prefer rust over C is that rust is way more ergonomic (once you understand the basics and overcome your first fight with the borrow checker and such) and it's more difficult to make certain mistakes (especially memory safety and concurrency related).
Whether one is better than the other honestly depends on the use case for me.
There are drawbacks for using rust just like there are drawbacks for using C.
In the case of an operating system I prefer the robustness and guidance of rust even if it means that using it is not as simple and maybe not even quite as fast as C.
@@arryndoestech actually, C is much more comfy to debug stuff :)
The bacon (available off of cargo install or nixpkgs) tool is magical for this compiler-driven workflow that you have going.
Looks like something you can do without installing anything:
watch --color -n1 cargo check --color always
Is there any benefit to bacon?
Great video
Thank you :)
Maybe you can try and use AstroNvim, it has great rust support and its visually nicer. All in all I liked the video, now I'm going to try that myself. But, will you continue with this to you know have few things that we can do once it starts, that would be awesome.
Thanks for the suggestion though I am quite happy with vanilla vim.
I will certainly continue this series, this is just the start.
The goal of this series is to write a simple operating system that is capable of running multiple processes.
After that it's up to the user to take it where they want it.
@@arryndoestech I am not able to print string like you did but I am able to print char. why is that?
@@RootsterAnon It's possible because we're not using write_volatile(), as you saw at the end it also didn't work for me when I used print in the panic handler. To enable the floating point unit you can put this code into your boot.s:
# Enable floating point bits FPEN
mrs x7, cpacr_el1
mov x8, #(3
@@arryndoestech maybe you can address some of this in a new episode, btw, your gdb workflow is great, i just recreated it on my side, sick! Can you talk about heap in the next video, i tried to implement it and initialize it myself but got stuck. Just idea.
@@RootsterAnon This will certainly be covered in the next episode :)
best asmr lov it
I'm glad that the audio made you enjoy it hahaha
Made with rust 🔥🔥🔥
Blazingly fast 🚀🚀🚀
btw it`s funny how the first thing you do after making your entrypoint is writing some unsafe c-style puts and putchar. i guess C is just burnt in our brains already.
really cool video btw. subbed. didn`t really care about rust for my whole life but now want to try it myself someday.
There is not really many other options to implement this as far as I know.
We are writing to a device, for which you normally use write_volatile() on a raw pointer.
I didn't do that because it seems that write_volatile() uses the floating point unit and since the video was already so long I didn't want to enable that in this episode.
Especially in OSdev you will have to write a bunch of unsafe code.
@@arryndoestech got it. just interesting how libc somehow set the standard for naming functions and people use it even when writing rust. these names may be shitty and not very descriptive (idk, they just feel old to me), but for some reason people are still using them where it`s not even necessary. it puts char? -- then it`s "putchar". it puts a string? -- then it`s "puts".
@@namelastname3772 yeah as programmers I think we're all familiar with libc functions to a degree so naming functions similar makes sense, but I could've named them anything else I'd like.
The code I wrote is safe though because the serial device on this platform is always at this address so I know I'm not accessing any invalid memory.
Unsafe means just that it's on me as the programmer to verify that this is a safe operation
What if I want to make a amd64 OS? Would it be any different to how you do this?
The code itself will be very different
With uefi the compiler setup is plug and play, without it if things havent changed then you'd need to write the 16 bit bootcode (if you choose to write a bootloader too) in assembly.
But as for details I'm not sure, x86_64 was always a mess that I'm not keen on learning.
I also dont use any x86 machines and probably won't ever again.
Subbed man. Years back had plan to work with LFS but timing didnt worked well. Now trying to build Ben Eater style 6502 currently at 8 bit bus/register design (kinda stalled) but plan to make my OS for thsi 8 bit system.
I have posted that on @kyuantym
Thank for the sub!
That sounds like a really cool project.
I really enjoyed the videos from Ben Eater.
If you're pulling through, it would be really cool if you made a video showcasing your project!