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

221–229 of 229 posts

Re: Hobby x86 kernel written with Zig

#221

Post by DSMan195276 »

pjmlp wrote: post #214
DSMan195276 wrote: post #204

Earlier quoted context omitted.

I highly disagree with that assessment, in regards to C you're comparing apples to oranges IMO, because C is very lax compared to what Rust enforces now and could enforce in the future, just by virtue of having so many less actual features. With that, if you commit to being `gcc` (and `clang`) specific, you have a very high number of guarantees and flexibility, even more depending on what extra feature flags you pass…

Well, it took 40 years for C to have any kind of memory model, so Rust has still some time available.

That's a bit hand wavy - The Linux Kernel has been doing atomics in C for I believe over 20 years now, well before C11 came out. And even after it came out they don't use C11 atomics. `gcc` gives them enough guarantees on its own to implement correct atomics and define their own memory model, in some ways better then the C11 one (and in some ways worse, but mostly just from an API standpoint).

When that said, my concerns are more with the state of `unsafe` overall, the memory model is only one part of that (though it somewhat spurred conversions about the other issues).

Re: Hobby x86 kernel written with Zig

#222

Post by pjmlp »

DSMan195276 wrote: post #221
pjmlp wrote: post #214

Earlier quoted context omitted.

Well, it took 40 years for C to have any kind of memory model, so Rust has still some time available.

That's a bit hand wavy - The Linux Kernel has been doing atomics in C for I believe over 20 years now, well before C11 came out. And even after it came out they don't use C11 atomics. `gcc` gives them enough guarantees on its own to implement correct atomics and define their own memory model, in some ways better then the C11 one (and in some ways worse, but mostly just from an API standpoint). When that said, my conc…

Linux kernel is just one kernel among many.

I bet that the pre-C11 memory semantics on Linux kernel aren't the same as e.g. on HP-UX kernel, across all supported hardware platforms.

It is also ironic that Java and .NET did it before C and C++, with their models being adopted as starting point.

Re: Hobby x86 kernel written with Zig

#223

Post by antpls »

loeg wrote: post #186
antpls wrote: post #170

Earlier quoted context omitted.

> 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 i…

> 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

If that's the only function of the program, are we still talking about an "Operating System" ?

Re: Hobby x86 kernel written with Zig

#224

Post by littlestymaar »

pron wrote: post #220
littlestymaar wrote: post #217

Earlier quoted context omitted.

> That's where the effort comes in. Those false positives are removed by adding annotations or changing code. With the former you lose all guarantees and fall back to a safe/unsafe duality, with the latter you need to rethink how your code works to comply yo the analyzer's mindset: in the end it's pretty much like Rust, but in an ad-hoc way, much less ergonomic. > I said they require relatively little effort, because…

> With the former you lose all guarantees and fall back to a safe/unsafe duality This is simply not true. The annotations are checked. It's exactly like adding type annotations when inference fails. > with the latter you need to rethink how your code works to comply yo the analyzer's mindset No. I'm talking about adding something like a bounds check in a function entry. > in the end it's pretty much like Rust, but in…

> Except that it is cheaper than a rewrite in Rust, which is one of the several reasons why this is currently the preferred approach in industry segments that require certain correctness guarantees. I don't know if you know this, but Rust isn't exactly making big headways in the safety/security-critical software world, especially, though not only, in embedded (for a multitude of reasons). Those sound static analysis tools, on the other hand, are showing nice growth.

Rust is way too new for that obviously. And as I said, because tooling and hiring pool are not here yet, it would be a critical mistake to attempt such move at the moment.

For new projects however, Rust is a really interesting bet. (I was until recently working on a new medical robot, whose software was mostly Rust and the speed at which we got it working was really exciting!).

> in any event, few people in the low-level programming space who aren't currently using C++ are even thinking about, let alone considering, Rust.

That's not my experience. Not many are considering it for a lot of reasons (too new, not enough people mastering it, resistance to change etc.) But “thinking about” is another story ;).

> You are assuming that Rust is the preferrable choice

Zig isn't really a choice at this point. It might become it in a few years, but there still a long way to go.

Re: Hobby x86 kernel written with Zig

#225

Post by DSMan195276 »

pjmlp wrote: post #222
DSMan195276 wrote: post #221

Earlier quoted context omitted.

That's a bit hand wavy - The Linux Kernel has been doing atomics in C for I believe over 20 years now, well before C11 came out. And even after it came out they don't use C11 atomics. `gcc` gives them enough guarantees on its own to implement correct atomics and define their own memory model, in some ways better then the C11 one (and in some ways worse, but mostly just from an API standpoint). When that said, my conc…

Linux kernel is just one kernel among many. I bet that the pre-C11 memory semantics on Linux kernel aren't the same as e.g. on HP-UX kernel, across all supported hardware platforms. It is also ironic that Java and .NET did it before C and C++, with their models being adopted as starting point.

> Linux kernel is just one kernel among many.

> I bet that the pre-C11 memory semantics on Linux kernel aren't the same as e.g. on HP-UX kernel, across all supported hardware platforms.

Yeah, but if they both work, why does it matter? There exists more than one valid possible memory model. The point I was making is that with C, it has been possible to define valid semantics well before C11 because compilers and the language give enough guarantees already.

To that point, while I focused on atomics (Since atomics and threading are largely what was added in C11), the bulk of the actual memory model that made that possible was defined well before then. Strict-aliasing was a thing in C89 (Though I'm not sure compilers enforced it at that point) and is probably the only real notable "gotcha", and `gcc` and `clang` let you turn it off outright (And if you're not doing weird kernel stuff, it generally is easy to obey).

`gcc` and `clang` also have lots of documentation on the extra guarantees they give, such as very well documented inline assembly, type-punning via `union`, lots of attributes for giving the compiler extra information, etc.

Compared to what Rust offers right now, there is no comparison. With Rust, the aliasing model (Which `unsafe` code is not allowed to break) is still unknown, and a lot of the nitty/gritty details like the stuff I listed for `from_raw_parts` are simply leaky implementation details they're inheriting unintentionally from LLVM (And effectively from C - C is where things like "not allowed to go past one past the end of an allocated block" restriction comes from, along with a host of other things).

Re: Hobby x86 kernel written with Zig

#226

Post by pjmlp »

DSMan195276 wrote: post #225
pjmlp wrote: post #222

Earlier quoted context omitted.

Linux kernel is just one kernel among many. I bet that the pre-C11 memory semantics on Linux kernel aren't the same as e.g. on HP-UX kernel, across all supported hardware platforms. It is also ironic that Java and .NET did it before C and C++, with their models being adopted as starting point.

> Linux kernel is just one kernel among many. > I bet that the pre-C11 memory semantics on Linux kernel aren't the same as e.g. on HP-UX kernel, across all supported hardware platforms. Yeah, but if they both work, why does it matter? There exists more than one valid possible memory model. The point I was making is that with C, it has been possible to define valid semantics well before C11 because compilers and the l…

While I do agree that Rust still needs to improve in this area, what happens when you port pre-C11 from gcc on Linux (x86) to aC on HP-UX (Itanium) and xlc on Aix (PowerPC), to keep up with my example?

Re: Hobby x86 kernel written with Zig

#227

Post by DSMan195276 »

pjmlp wrote: post #226
DSMan195276 wrote: post #225

Earlier quoted context omitted.

> Linux kernel is just one kernel among many. > I bet that the pre-C11 memory semantics on Linux kernel aren't the same as e.g. on HP-UX kernel, across all supported hardware platforms. Yeah, but if they both work, why does it matter? There exists more than one valid possible memory model. The point I was making is that with C, it has been possible to define valid semantics well before C11 because compilers and the l…

While I do agree that Rust still needs to improve in this area, what happens when you port pre-C11 from gcc on Linux (x86) to aC on HP-UX (Itanium) and xlc on Aix (PowerPC), to keep up with my example?

Well, I would clarify - In reference to the memory models I was talking about, it only applies to code written as part of those kernels, userspace code does not "inherit" that memory model. And I don't think portability of kernel code is much of a concern, the memory model is only one of a large variety of problems.

That said, for userspace, pthreads already gives enough guarantees on ordering via mutex's that there aren't really any problems unless you're trying to do atomics in userspace, which before C11 would have been hard to do portability. And the rest of the things I was talking about like the aliasing model are defined as part of the C standard (C89 and C99), so it's always the same regardless of the compiler (ignoring possible bugs).

Re: Hobby x86 kernel written with Zig

#229

Post by renox »

mratsim wrote: post #91
baq wrote: post #64

Earlier quoted context omitted.

C is portable assembly, I’d recommend learning it together with the assembly for the platform you’re learning on, so you can actually understand the stack, heap, calling conventions, etc.

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/…

> C is portable assembly until it isn't:

> - no access to carry/overflow flag in registers making it a chore to write bigint libraries

C is portable assembly: so it provides access to a minimum common set of features which allow the code to be portable:

good luck trying to use the carry flag on the RISC-V..

Post reply on HN