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

181–190 of 229 posts

Re: Hobby x86 kernel written with Zig

#181

Post by loeg »

blackhaz wrote: post #20
nicoburns wrote: post #10

Earlier quoted context omitted.

Zig is lower level than either (it's more like C than C++: expect to manually call 'free'on allocated values). It has a lot of nice improvments over C however, like proper arrays, no null, a module system, and proper compile time evaluation (no need for the hacky preprocessor).

May I ask why people invent new languages rather than trying to extend or improve existing ones, like C?

C can't break backwards compatibility and remain C. So... how would you make language changes without resulting in the entire C++ mess new languages are trying to get away from?

Re: Hobby x86 kernel written with Zig

#182

Post by loeg »

simias wrote: post #25
blackhaz wrote: post #20

Earlier quoted context omitted.

May I ask why people invent new languages rather than trying to extend or improve existing ones, like C?

You could argue that it's what these languages do, the C heritage is very strong in every one of them. The problem is: do you want to maintain full backcompat or are you willing to break things to do it cleanly? If you do the former you end up with something like C++ which retains almost complete compatibility with C (but they you have a lot of baggage to carry around, which may get in the way at times) or you're wil…

C had a standard published in 2018. It's "ancient" in that it's not new, but not ancient in that it's abandoned or unused.

Re: Hobby x86 kernel written with Zig

#183

Post by loeg »

pjmlp wrote: post #68
matheusmoreira wrote: post #24

Earlier quoted context omitted.

The Road to Zig explains the essence of the language: https://youtu.be/Gv2I7qTux7g C but with the problems fixed.

It doesn't fix use-after-free, double free().

There is some aphorism about perfection, the enemy of good, and some way in which they relate. It is relevant to understanding "why Zig?"

Re: Hobby x86 kernel written with Zig

#184

Post by senderista »

sov wrote: post #163
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…

Your point about unsafe pointer handling in Rust is specifically what dissuaded us from using it in an upcoming project. It really feels bad prepending all of the code that you actually care about being safe with `unsafe`.

`unsafe` before a block simply means "the following code has been manually checked for memory safety, because the compiler is unable to automatically do so". Before a function it means "this can only be called from an unsafe block, because the compiler cannot enforce the preconditions it requires to ensure memory safety". What alternative term would make you feel less bad?

Re: Hobby x86 kernel written with Zig

#185

Post by loeg »

sigjuice wrote: post #147
mratsim wrote: post #91

Earlier quoted context omitted.

C is portable assembly until it isn't: - no access to carry/overflow flag in registers making it a chore to write bigint libraries - no way to guarantee emitting add with carry or sub with borrow even though those are simple instructions and some architecture (6502) don't even provide a normal add/sub - need to drop down to assembly to implement resumable function/fibers to avoid the syscall costs of ucontext/setjmp/…

need to drop down to assembly to implement resumable function/fibers to avoid the syscall costs of ucontext/setjmp/longjmp Which syscalls would be involved in setjmp/longjmp?

For inexplicable reasons, ucontext/setjmp/longjmp include signal masks, which, for lack of VDSO implementation, must be obtained by invoking syscalls.

(FreeBSD provides the non-portable _setjmp/_longjmp, which do not preserve signal mask state and avoid the syscall. There are also the POSIX sigsetjmp/siglongjmp, which with savesigs=0 may bypass the syscalls as well. Both FreeBSD and Linux provide the POSIX routines.)

Re: Hobby x86 kernel written with Zig

#186

Post by loeg »

antpls wrote: post #170
jackhalford wrote: post #77

Earlier quoted context omitted.

> caring about the assembly output is a spectacular case of premature optimization I don't agree! at least for operating systems. Consider that some operating system code may be run a million times per second, on a million different machines (e.g: block system IO on linux). We very much want our assembly to be pristine in this case. I also like the idea of "optimality" brought forward by zig. In the post you link, th…

> Consider that some operating system code may be run a million times per second, on a million different machines (e.g: block system IO on linux). We very much want our assembly to be pristine in this case. I would believe that most of the time of a processor is dedicated to run userspace code, not OS code (regarding to the work that must be done). At the end of the day, the OS is "only" a scheduler to share hardware…

> I would believe that most of the time of a processor is dedicated to run userspace code, not OS code (regarding to the work that must be done). At the end of the day, the OS is "only" a scheduler to share hardware resources between unrelated tasks.

Yeah, that's true if the OS is well-written and has had continual and extensive performance work done. Passing 200 Gbit of network traffic in software with firewalling is non-trivial and the number of cycles you get per packet is pretty modest. These things do matter.

Re: Hobby x86 kernel written with Zig

#187

Post by nimmer »

mratsim wrote: post #155
nimmer wrote: post #137

Earlier quoted context omitted.

The majority of stdlib modules does not depend on GC. Also, the new ARC memory manager replaces GC and can run in a kernel.

No that's not true. As soon as you use sequences or strings or async you depend on the GC. You can however compile with gc:destructors or gc:arc so that those are managed by RAII.

I used various modules with gc:none

I meant that new ARC GC, that will replace the current one, can be used for the kernel.

It's still a GC, technically, but, quoting Araq on ARC:

Nim is getting the "one GC to rule them all". However calling it a GC doesn't do it justice, it's plain old reference counting with optimizations thanks to move semantics.

Re: Hobby x86 kernel written with Zig

#188

Post by roblabla »

loeg wrote: post #175
roblabla wrote: post #119

Earlier quoted context omitted.

Small nitpick: Google isn't using Rust for the Fuchsia kernel. The kernel, Zircon, is written entirely in C and is based on Little Kernel. Google is using Rust for some userspace drivers (Fuchsia being a micro-kernel).

> The kernel, Zircon, is written entirely in C No, it's written in C++[1]. They're very different languages. That said, Google seems to think C++ has something to offer to all kinds of development. It seems to work for them, but they are a heavily C++ shop. I wouldn't read too much out of their use of C++ anywhere; it'd be more surprising and interesting to see them use anything else. [1]: https://fuchsia.googlesourc…

Oh that's interesting. Zircon is based on LK[0] which is in C, which is why I thought it was still written in C. I wonder how much is left of the original LK code then.

[0]: https://fuchsia.dev/fuchsia-src/concepts/kernel/zx_and_lk

Re: Hobby x86 kernel written with Zig

#189

Post by Bekwnn »

knebulae wrote: post #140

I tried to do this with Zig about 13 months ago. It was not where it needed to be at that time; the biggest impediments were its rudimentary handling of C pointers to one vs pointers to many (which has long since been fixed), and its meta programming issues (lack of a macro language or pre-processor) that made OS development tedious. I have not revisited it as much as I would have liked simply because I chose to step…

I've been waiting for something that looks like a firm step forward in the domain of games programming and has ideals which align with the domain. I'm extremely excited for zig and have been messing around with getting a smallish simulation running with SDL on Windows.

At work in C++ I've switched from working on fairly isolated types, where my changes had fast recompile times to lower level changes which cause a good chunk of the engine to recompile. 10 minute compile times, with a lot of tech trying to get that time down as much as possible, are a huge killer to productivity and I can feel myself getting much less done than I was before.

Zig tossed away a lot of the constructs that make C++ slower to compile. I haven't had a chance to see its timings on large projects, but stuff like Jai compiling 90k LoC full commercial game project live on a laptop in 1.4 seconds (which caused Jonathan Blow to say "what? That's weirdly slower than it should be...") gives me hope that Zig is similar.

Re: Hobby x86 kernel written with Zig

#190

Post by flukus »

swiley wrote: post #15
simias wrote: post #9

Earlier quoted context omitted.

I'm curious too, I'm quite familiar with Rust and never written any Zig in my life so I went digging through the source and I find the syntax remarkably similar for the most part. The only thing that stood out is that apparently you can drop the braces for single-line `if` bodies like in C whereas Rust makes them always mandatory but I'm firmly on Rust's side on this one. The part where Rust can get really messy is w…

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

Ugh, I was planning to learn zig at one point but things like this mean I'm going to pass. This doesn't even seem to be in the documentation that I could find.

Throw in their plans to add a package manager and it's own make system and it seems to be getting further and further from the C replacement I was interested in.

Post reply on HN