Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Hobby x86 kernel written with Zig

github.com

Post reply on HN
Print view View original

81–90 of 229 posts

Re: Hobby x86 kernel written with Zig

#81

Post by jackhalford »

rehemiau wrote: post #5
jackhalford wrote: post #4

Hi, author here! I've just finished writing the pre-emptive multitasking [0](only round robbin though, nothing fancy). I'm currently writing an ATA driver [1], the idea is to implement ext2. I used to do this in Rust but I switched to zig for maintainability and readability over Rust. It seems that with `comptime` I'm able to make a lot of things optimal. Overall I have to say kernel programming is _hard_ but very re…

Looks awesome! Planning to do a similar thing in Jai once it comes out

I don't follow JAI but maybe Jonathan Blow should try zig, it's a great fit for game development and I remember him mentioning that he wants a language that is fun to write in.

Re: Hobby x86 kernel written with Zig

#82

Post by simias »

chungus_khan wrote: post #42
simias wrote: post #29

Earlier quoted context omitted.

I don't mind opinionated coding style (my Rust integration scripts all enforce that stock "rust clippy" doesn't return any error) and I do think that using tabs for indentation simply doesn't work in practice regardless of how great they are in theory because hardly anybody uses them correctly (including the vast majority of code editors by default). It might be strange to back it straight into the compiler but I don…

> including the vast majority of code editors by default Which ones exactly? Not really a problem I've encountered often except when someone tries to mix both spaces and tabs, and in general editors are built with the existence of this very common character in mind. People tend to hit the tab key to indent anyway, and one tab char meaning one level of indent is perfectly intuitive and allows users to individually con…

Many editors (including the venerable Vim and Emacs) indent and align with tabs by default, which means that if you want your code to look right you standardize tab width which in turn removes one of the only (meager) advantages tabs have over spaces: configuring the indentation width to match your personal taste.

>Not really a problem I've encountered often except when someone tries to mix both spaces and tabs

Mixing spaces and tab for indentation and alignment is how it should be done if you want things to remain aligned when you change the tab width.

Re: Hobby x86 kernel written with Zig

#83

Post by jackhalford »

archsurface wrote: post #70

The hello world examples for master and 0.5.0 seem quite different - any trouble keeping up with the changes?

migration from 0.4 to 0.5 was ok. AFAICT there the big change for 0.6 syntax wise is the drop or varargs in favour of tuples. I'll take some time to do the switch when 0.6 hits but I'm confident it won't take long because of how concise the language is.

Re: Hobby x86 kernel written with Zig

#84

Post by mratsim »

Touche wrote: post #46
alehander42 wrote: post #36

Earlier quoted context omitted.

you're right, it is confusing, but it is optional: some toy kernels already work in nim , and with latest work on memory, you should be able to use most of the language for kernel development ! not the perfect language for that yet though, but i hope we should see more nim os examples

Are you saying that the GC is optional? If you don't use it how do you allocate/free memory?

You call malloc/free, or if working with GPU cudaMalloc/free. You can write your own memory pool or object pools, you can use destructors, and even implement your own reference counting scheme.

This is what I use for my own multithreading runtime in Nim and the memory subsystem makes it faster and more robust than any runtime (including OpenMP and Intel TBB) that I've been benchmarking against, see memory subsystem details here: https://github.com/mratsim/weave/tree/master/weave/memory

Example of atomic refcounting in this PR here: https://github.com/mratsim/weave/blob/025387510/weave/dataty...

Also one important thing, Nim current GC is based on TLSF (http://www.gii.upv.es/tlsf/) which is a memory reclamation scheme for real-time system, it provides provably bounded O(1) allocations. You can tune Nim GC with max-pauses for latency critical applications.

Re: Hobby x86 kernel written with Zig

#85

Post by simias »

clarry wrote: post #37
simias wrote: post #29

Earlier quoted context omitted.

I don't mind opinionated coding style (my Rust integration scripts all enforce that stock "rust clippy" doesn't return any error) and I do think that using tabs for indentation simply doesn't work in practice regardless of how great they are in theory because hardly anybody uses them correctly (including the vast majority of code editors by default). It might be strange to back it straight into the compiler but I don…

> I do think that using tabs for indentation simply doesn't work in practice It has worked just fine for decades for projects with millions of lines of code. It might not work for babby's first patch and how do I configure an IDE??

Depends of your definition of "fine". The linux kernel works fine indenting with tabs but it mandates 8-space tabs and a lot of code ends up looking borderline unreadable if you use anything else, meaning that the only thing they get by using tabs is slightly smaller file sizes. Besides if you want to enforce the 80column limit you have to standardize a tab width anyway.

It's simply not worth it IMO. The pros are simply too small and inconsequential to justify not using spaces on new projects. Although now that automatic code formaters are becoming ubiquitous it really doesn't matter what you use in your editor I suppose.

Re: Hobby x86 kernel written with Zig

#86

Post by pron »

gw wrote: post #76
pron wrote: post #44

Earlier quoted context omitted.

I wouldn't call Zig's comptime "C++-style." Unlike Rust, there's very little in Zig that is borrowed from C++. Zig's error reporting and comptime makes it easy to write arbitrary compile-time checks, so Zig uses a single construct and keyword, comptime, to replace all special instances of partial evaluation: generics, concepts/traits, value templates, macros and constexprs. The main difference between Zig and Rust is…

comptime does not replace macros though...there is no way to manipulate AST in zig, nor will there ever be, according to the author.

Well, it is intentionally weaker than macros (and I agree with Zig's designer that that's a very good thing, though it is a matter of taste), but it does replace many of the cases where in Rust you'd have to use macros (or the preprocessor in C/C++). So it replaces macros everywhere where it deems their usage reasonable.

Re: Hobby x86 kernel written with Zig

#88

Post by AnIdiotOnTheNet »

gw wrote: post #76
pron wrote: post #44

Earlier quoted context omitted.

I wouldn't call Zig's comptime "C++-style." Unlike Rust, there's very little in Zig that is borrowed from C++. Zig's error reporting and comptime makes it easy to write arbitrary compile-time checks, so Zig uses a single construct and keyword, comptime, to replace all special instances of partial evaluation: generics, concepts/traits, value templates, macros and constexprs. The main difference between Zig and Rust is…

comptime does not replace macros though...there is no way to manipulate AST in zig, nor will there ever be, according to the author.

Which is the right call really. It is valuable to have the code you're looking at actually be what it appears to be.

Re: Hobby x86 kernel written with Zig

#89

Post by [deleted] »

simias wrote: post #29
swiley wrote: post #15

Earlier quoted context omitted.

If you want more syntax weirdness: tab characters are illegal.

I don't mind opinionated coding style (my Rust integration scripts all enforce that stock "rust clippy" doesn't return any error) and I do think that using tabs for indentation simply doesn't work in practice regardless of how great they are in theory because hardly anybody uses them correctly (including the vast majority of code editors by default). It might be strange to back it straight into the compiler but I don…

[deleted]

Re: Hobby x86 kernel written with Zig

#90

Post by jackhalford »

simias wrote: post #79
jackhalford wrote: post #28

Earlier quoted context omitted.

In general you'll find that zig is easier to read than Rust (see the first version of this project in Rust [0]) because it's a simpler language. For kernel programming this is even more so the case: * zig has native support for arbitrary sized integers. In Rust I used to do bitshifts, Now I just have a packed struct of u3/u5/u7 whatever (see `src/pci/pci.zig`). Of course Rust has a bitflags crate but I didn't find it…

It's true that for bare metal programming Rust is quite far from 1.0. You can't even do inline assembly in stable rust... Arbitrary sized integers do sound very convenient, although I guess the counterargument would be that they simply can't map to machine types so you'll have to have magic behind the scenes which may not make complete sense in low level languages. Still, C has bitfields in structs which are sort of…

Ok maybe I was user pointers wrong in Rust. And I must confess that I never really understood lifetimes either, however

* I don't think that low level code needs to be "messy", and

* I don't think that adding an abstraction on top solves anything complexity wise.

For memory paging I used to have a whole library in Rust that handled hierarchy of page tables with very abstract pagetable classes and interfaces [0]. Now I just have 80 lines of zig that handles everything [1]. I much prefer the latter.

> I think this is reasonable even for kernel code.

It's not, for some of the reasons that Linus doesn't want C++ code in the kernel [2]

[0] https://github.com/gz/rust-x86/blob/28d5839933973e0b639ef354...

[1] https://git.sr.ht/~jzck/kernel/tree/master/src/arch/x86/pagi...

[2] https://yarchive.net/comp/linux/c++.html

Post reply on HN