8 ms·

Author here. Thanks for posting this <3 Happy to answer questions.

by khaledh 2y ago

lagniappe 2y ago
Where are the screenshots
- russelg 2y ago
  Reading the planned work section in the readme, what kind of screenshots are you expecting??
- khaledh 2y ago
  I just added a few screenshots, including one from the graphics branch that is still a wip.
alberth 2y ago
Congrats, fascinating work! Q: has the GC of Nim caused any challenges? (And if not, would you attribute that to Nim unique GC that does NOT “stop-the-world”?) https://nim-lang.org/1.4.0/gc.html https://nim-lang.org/1.4.0/gc.html
- Tiberium 2y ago
  1.4.0 is a very outdated docs version (Nim is at 2.0 currently, and 2.0 release brought ORC as default with ARC as an option), you should refer to the updated https://nim-lang.org/docs/mm.html https://nim-lang.org/docs/mm.html and also https://nim-lang.org/docs/destructors.html https://nim-lang.org/docs/destructors.html
  - pests 2y ago
    Nim should take inspiration out of other languages doc sites where a banner is placed at the top notifying the reader it is for a previous version with a link to the current version. Could also add a rel=canonical meta tag pointing to the latest version so search engines funnel people there. "Nim gc" on Google indeed puts you at the 1.4 doc page.
    - alberth 2y ago
      Slight OT: are is the best documentation management system these day? ReadMe, Docusaurus, Mintlify, etc?
- khaledh 2y ago
  Thanks! As @Tiberium mentioned, Nim 2.0 defaults to using ARC (Automatic Reference Counting), so no runtime GC. The Nim compiler is quite smart about when to copy/move and when to destruct, with some hints like lent/sink for when you want to have a bit more control. Keep in mind that I also need to use ptr (as opposed to ref) types in a lot of cases when working at a low level, so there might be a need for some manual memory management as well.
suby 2y ago
I don't use Nim, but it's an interesting language. I've read someone else complaining about having to make changes to an old project every time he went to recompile it. I'm wondering how true this is, so in other words, I'm wondering about the frequency and severity of breaking changes in the language.
- khaledh 2y ago
  I haven't faced such issue. I think the only issue I faced was when I upgraded to 2.0, they made `--threads:on` the default, so I had to turn it off, but that's about it.
- deleted 2y ago
  [deleted]
- efilife 2y ago
  wasn't this about C/C++?
- PMunch 2y ago
  Doesn't happen a lot, but it does happen from time to time. Of course only if you actually update your Nim version, so it's not like interpreted languages like Python where stuff stops working if a new version comes out and your package manager upgrades it.
edu_do_cerrado 2y ago
Amazing work! What where the most troublesome parts of the project? Also, any tips if anyone want to write an OS from scratch, aswell?
- deaddodo 2y ago
  Read. A lot. Basically, OSDev is one of the few realms you can't really take shortcuts in. It's kind of like learning Rust, in that you'll have a lot of foundational work until you get some real payoff. Unlike rust, however, there isn't just some cliff where you start getting it; it's a constant uphill trudge. Learning the boot process of your target architecture, adding core functionality (process scheduling, filesystem/VFS support, IO management, etc), adding driver support, supporting your video device (just getting a basic framebuffer, and then adding each piece after that), supporting USB, supporting CRT and POSIX (if you choose to do so), etc are all herculean tasks of their own. That being said, it's a super incremental process, so you'll get to watch it grow and expand at each step. Reading up on the FreeBSD and Linux kernels are good starts. As well as reviewing other hobby OSes such as Serenity, TouruOS, Haiku, etc. And the OSDev wiki is invaluable. Also, accepting you probably aren't going to build the next big OS or trying to compete with the big dogs is something you'll have to humble yourself with.
- khaledh 2y ago
  > What where the most troublesome parts of the project? Task switching. It's a very intricate process, you really have to understand how to structure everything (especially the task stack) so that you can switch everything from underneath the CPU as if nothing has happened (the CPU is obliviuous to which task is running, including the kernel itself). Add to that switching between user mode and kernel mode (during interrupts and system calls) and it becomes even more challenging. > Also, any tips if anyone want to write an OS from scratch, aswell? As @deaddod said, you need to read a lot. Two invaluable resources for me were the Intel Software Development Manuals (SDM), and the osdev wiki. The SDM can be daunting, but it's surprisingly very readable. The osdev wiki has great content, but it can be a hit or miss. I complement them with various blog posts and code on github to really understand a certain topic. That being said, the most important aspect of this process is to have tons of curiousity and to be passionate about low-level systems programming. I love to learn how things really work at the lowest level. Once you learn it, you'll discover that there's no magic, and that you can write something yourself to make it work. [0] https://www.intel.com/content/www/us/en/developer/articles/technical/intel-sdm.html https://www.intel.com/content/www/us/en/developer/articles/t... [1] https://wiki.osdev.org https://wiki.osdev.org
sidkshatriya 2y ago
I heard that null is a valid value for objects in Nim for most situations. Is that correct ? I like languages that disallow null by default (e.g. Rust, OCaml etc) because it seems to be a huge source of errors.
- netbioserror 2y ago
  No, it isn't. The type must explicitly be a nullable type or pointer to be nullable. All other values must have a valid initialization. Anything not marked as a pointer or ref is by default managed by its scope. This includes dynamic types like seqs and strings, which are pointers to heap memory but managed by the stack scope and deallocated upon leaving scope.
- jasfi 2y ago
  I use the Options module which has a none/some check. None is the absence of a value. You can test for this quite easily and I see it as a feature, not a bug.
- khaledh 2y ago
  To be honest, I haven't found this to be an issue (yet). I try to keep most of my types value types (cannot be null), which the compiler can pass by reference under the hood if it detects that it's too big, without compromising memory safety.
- deleted 2y ago
  [deleted]
alberth 2y ago
Q: what made you choose Nim over Swift? (since they seem very similar at this point, yet Swift is more battle tested)
- khaledh 2y ago
  I did consider Swift for a brief moment, but was put off by the fact that targeting bare-metal was almost non-existent. It was more work than I would like to put into bootstrapping the dev environment.
  - kosolam 2y ago
    What made you use nim in the first place vs any other lang?
    - khaledh 2y ago
      I went over this in other comments, but basically the language appeals to me since: - it's close to Python in syntax (less noise, more readable) - has no garbage collector by default (it uses ARC) - has great C interop - can be optimized through the C backend compiler - can target bare-metal with minimal effort - supports inline assembly - has great template/macro system (I do use templates, but I haven't had the need for macros yet) There's probably other reasons, but those are the ones I could think of now. As for why not other languages, I think the only other languages suitable for this kind of work are: C, C++, Rust, and Zig. Here's my take on each: - C: The mother of all system languages, but outdated with lots of UB gotchas - C++: I don't like/need OOP, so why pay the prices of C++ complexity and manual memory management - Rust: I find the language too complicated for my taste. I know it's subjective, but it just doesn't feel right for me. Also writing a kernel involves a lot of unsafe code anyway. - Zig: I tried Zig and also found its syntax to be a bit too noisy. Also having to worry about allocators in most of the code distracts from the core logic I'm trying to focus on.
      - alberth 2y ago
        Thanks for the details. Any reasons why you would not recommend Nim? Or things Nim could improve? (Nim seems like this unicorn of languages, that's completely overlooked. And I don't understand why it's overlooked)

Author here. Thanks for posting this <3 Happy to answer questions.

lagniappe 2y ago

Where are the screenshots

russelg 2y ago
Reading the planned work section in the readme, what kind of screenshots are you expecting??
khaledh 2y ago
I just added a few screenshots, including one from the graphics branch that is still a wip.

alberth 2y ago

Congrats, fascinating work! Q: has the GC of Nim caused any challenges? (And if not, would you attribute that to Nim unique GC that does NOT “stop-the-world”?) https://nim-lang.org/1.4.0/gc.html https://nim-lang.org/1.4.0/gc.html

Tiberium 2y ago
1.4.0 is a very outdated docs version (Nim is at 2.0 currently, and 2.0 release brought ORC as default with ARC as an option), you should refer to the updated https://nim-lang.org/docs/mm.html https://nim-lang.org/docs/mm.html and also https://nim-lang.org/docs/destructors.html https://nim-lang.org/docs/destructors.html
- pests 2y ago
  Nim should take inspiration out of other languages doc sites where a banner is placed at the top notifying the reader it is for a previous version with a link to the current version. Could also add a rel=canonical meta tag pointing to the latest version so search engines funnel people there. "Nim gc" on Google indeed puts you at the 1.4 doc page.
  - alberth 2y ago
    Slight OT: are is the best documentation management system these day? ReadMe, Docusaurus, Mintlify, etc?
khaledh 2y ago
Thanks! As @Tiberium mentioned, Nim 2.0 defaults to using ARC (Automatic Reference Counting), so no runtime GC. The Nim compiler is quite smart about when to copy/move and when to destruct, with some hints like lent/sink for when you want to have a bit more control. Keep in mind that I also need to use ptr (as opposed to ref) types in a lot of cases when working at a low level, so there might be a need for some manual memory management as well.

suby 2y ago

I don't use Nim, but it's an interesting language. I've read someone else complaining about having to make changes to an old project every time he went to recompile it. I'm wondering how true this is, so in other words, I'm wondering about the frequency and severity of breaking changes in the language.

khaledh 2y ago
I haven't faced such issue. I think the only issue I faced was when I upgraded to 2.0, they made `--threads:on` the default, so I had to turn it off, but that's about it.
deleted 2y ago
[deleted]
efilife 2y ago
wasn't this about C/C++?
PMunch 2y ago
Doesn't happen a lot, but it does happen from time to time. Of course only if you actually update your Nim version, so it's not like interpreted languages like Python where stuff stops working if a new version comes out and your package manager upgrades it.

edu_do_cerrado 2y ago

Amazing work! What where the most troublesome parts of the project? Also, any tips if anyone want to write an OS from scratch, aswell?

deaddodo 2y ago
Read. A lot. Basically, OSDev is one of the few realms you can't really take shortcuts in. It's kind of like learning Rust, in that you'll have a lot of foundational work until you get some real payoff. Unlike rust, however, there isn't just some cliff where you start getting it; it's a constant uphill trudge. Learning the boot process of your target architecture, adding core functionality (process scheduling, filesystem/VFS support, IO management, etc), adding driver support, supporting your video device (just getting a basic framebuffer, and then adding each piece after that), supporting USB, supporting CRT and POSIX (if you choose to do so), etc are all herculean tasks of their own. That being said, it's a super incremental process, so you'll get to watch it grow and expand at each step. Reading up on the FreeBSD and Linux kernels are good starts. As well as reviewing other hobby OSes such as Serenity, TouruOS, Haiku, etc. And the OSDev wiki is invaluable. Also, accepting you probably aren't going to build the next big OS or trying to compete with the big dogs is something you'll have to humble yourself with.
khaledh 2y ago
> What where the most troublesome parts of the project? Task switching. It's a very intricate process, you really have to understand how to structure everything (especially the task stack) so that you can switch everything from underneath the CPU as if nothing has happened (the CPU is obliviuous to which task is running, including the kernel itself). Add to that switching between user mode and kernel mode (during interrupts and system calls) and it becomes even more challenging. > Also, any tips if anyone want to write an OS from scratch, aswell? As @deaddod said, you need to read a lot. Two invaluable resources for me were the Intel Software Development Manuals (SDM), and the osdev wiki. The SDM can be daunting, but it's surprisingly very readable. The osdev wiki has great content, but it can be a hit or miss. I complement them with various blog posts and code on github to really understand a certain topic. That being said, the most important aspect of this process is to have tons of curiousity and to be passionate about low-level systems programming. I love to learn how things really work at the lowest level. Once you learn it, you'll discover that there's no magic, and that you can write something yourself to make it work. [0] https://www.intel.com/content/www/us/en/developer/articles/technical/intel-sdm.html https://www.intel.com/content/www/us/en/developer/articles/t... [1] https://wiki.osdev.org https://wiki.osdev.org

sidkshatriya 2y ago

I heard that null is a valid value for objects in Nim for most situations. Is that correct ? I like languages that disallow null by default (e.g. Rust, OCaml etc) because it seems to be a huge source of errors.

netbioserror 2y ago
No, it isn't. The type must explicitly be a nullable type or pointer to be nullable. All other values must have a valid initialization. Anything not marked as a pointer or ref is by default managed by its scope. This includes dynamic types like seqs and strings, which are pointers to heap memory but managed by the stack scope and deallocated upon leaving scope.
jasfi 2y ago
I use the Options module which has a none/some check. None is the absence of a value. You can test for this quite easily and I see it as a feature, not a bug.
khaledh 2y ago
To be honest, I haven't found this to be an issue (yet). I try to keep most of my types value types (cannot be null), which the compiler can pass by reference under the hood if it detects that it's too big, without compromising memory safety.
deleted 2y ago
[deleted]

alberth 2y ago

Q: what made you choose Nim over Swift? (since they seem very similar at this point, yet Swift is more battle tested)

khaledh 2y ago
I did consider Swift for a brief moment, but was put off by the fact that targeting bare-metal was almost non-existent. It was more work than I would like to put into bootstrapping the dev environment.
- kosolam 2y ago
  What made you use nim in the first place vs any other lang?
  - khaledh 2y ago
    I went over this in other comments, but basically the language appeals to me since: - it's close to Python in syntax (less noise, more readable) - has no garbage collector by default (it uses ARC) - has great C interop - can be optimized through the C backend compiler - can target bare-metal with minimal effort - supports inline assembly - has great template/macro system (I do use templates, but I haven't had the need for macros yet) There's probably other reasons, but those are the ones I could think of now. As for why not other languages, I think the only other languages suitable for this kind of work are: C, C++, Rust, and Zig. Here's my take on each: - C: The mother of all system languages, but outdated with lots of UB gotchas - C++: I don't like/need OOP, so why pay the prices of C++ complexity and manual memory management - Rust: I find the language too complicated for my taste. I know it's subjective, but it just doesn't feel right for me. Also writing a kernel involves a lot of unsafe code anyway. - Zig: I tried Zig and also found its syntax to be a bit too noisy. Also having to worry about allocators in most of the code distracts from the core logic I'm trying to focus on.
    - alberth 2y ago
      Thanks for the details. Any reasons why you would not recommend Nim? Or things Nim could improve? (Nim seems like this unicorn of languages, that's completely overlooked. And I don't understand why it's overlooked)