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

Minimal x86 Kernel Zig

github.com

Post reply on HN
Print view View original

41–50 of 71 posts

Re: Minimal x86 Kernel Zig

#41

Post by flohofwoe »

lionkor wrote: post #39
bjourne wrote: post #34

Earlier quoted context omitted.

Zig is not faster than C.

Would you say its always slower, or always faster?

The optimization work happens in the LLVM backend, so in most cases (and using the same optimization and target settings - which is an important detail, because by default Zig uses more aggressive optimization options than Clang), similar Zig and C code translates to the exact same machine code (when using Clang to build the C code).

The same should be true for any compiled language sitting on top of LLVM btw, not just C vs Zig.

Re: Minimal x86 Kernel Zig

#42

Post by flohofwoe »

smallstepforman wrote: post #38
xx__yy wrote: post #9

Gold! I see Zig, I upvote!

Well, in the real world we need at least polymorphism and operator overloading, but that is against the core Zig philosophy, so serious GameDev ignores it (which ironically one would think is the biggest core market for low level systems programming). Hence why new GameDev development still chooses C++, and Andrew’s project fails to gain a significant boost in users.

> in the real world we need at least polymorphism and operator overloading

Maybe in your real-world ;)

Building your game code around classes with virtual methods has been a bad idea since at least the early 2000s (but both static and dynamic polymorphism is something that Zig can do just fine when needed), and the only important use case for operator overloading in game-dev is vector/matrix math, where Zig is going down a different road (using builting vector types, which maybe one day will be extended with a builtin matrix type - there is some interest in using Zig for GPU code, and at least this use cases will require proper vector/matrix primitives - but not operator overloading).

Re: Minimal x86 Kernel Zig

#43

Post by lelanthran »

kunley wrote: post #28

Why to spread confusion and call it bare metal when it's run under QEMU? Then it's not bare metal at all. In order to be run on bare metal it's needing another bootloader which the documentation only barely mentions. More on the naming: why to call it kernel?

> In order to be run on bare metal it's needing another bootloader which the documentation only barely mentions.

Maybe it's an in-group vs out-group thing: those in the group (i.e. have attempted this in the past) don't care about what the first stage bootloader is; you'll just use some existing bootloader (I used grub).

If you're in the out-group, you feel cheated that you still need a bootloader.

Re: Minimal x86 Kernel Zig

#44

Post by lelanthran »

6r17 wrote: post #16
drnick1 wrote: post #12

What's the point of doing this in "Zig" instead of C, the traditional choice for this kind of thing?

What's the point writing another kernel in C ???

Considering that we are talking about experimental toys which have lower odds of seeing production than of you winning a national lottery jackpot, the point of writing it in C would be the same as the point of writing it in anything else - IOW, the kernel is the objective, not the language used to write it.

.

Re: Minimal x86 Kernel Zig

#45

Post by mghackerlady »

lelanthran wrote: post #44
6r17 wrote: post #16

Earlier quoted context omitted.

What's the point writing another kernel in C ???

Considering that we are talking about experimental toys which have lower odds of seeing production than of you winning a national lottery jackpot, the point of writing it in C would be the same as the point of writing it in anything else - IOW, the kernel is the objective, not the language used to write it. .

Yeah, but even if I'm doing something for fun I do want to be a bit unique with it. Anyone who's interested enough in osdev to build something for baremetal has at least attempted a unix-like kernel in C

Re: Minimal x86 Kernel Zig

#46

Post by mghackerlady »

asQuirreL wrote: post #32
xx__yy wrote: post #11

Earlier quoted context omitted.

I'm not that cluey, but from the README it sounds like it can be compiled for a bunch of arches

It can be (cross-)compiled on whatever architectures the Zig compiler is available for, but the source contains inline x86 assembly, so you're not going to be able to build this for ARM or RISC-V.

For how short it is, it would be trivially easy to translate the instructions into whatever flavor of CPU made in the past 25 years or so

Re: Minimal x86 Kernel Zig

#47

Post by mghackerlady »

smallstepforman wrote: post #38
xx__yy wrote: post #9

Gold! I see Zig, I upvote!

Well, in the real world we need at least polymorphism and operator overloading, but that is against the core Zig philosophy, so serious GameDev ignores it (which ironically one would think is the biggest core market for low level systems programming). Hence why new GameDev development still chooses C++, and Andrew’s project fails to gain a significant boost in users.

>polymorphism and operator overloading

Gee, this new C language and UNIX operating system sure seem cool but someone ought to tell those poor people at bell labs that they'll never catch on without them

Re: Minimal x86 Kernel Zig

#48

Post by eddd-ddde »

kunley wrote: post #28

Why to spread confusion and call it bare metal when it's run under QEMU? Then it's not bare metal at all. In order to be run on bare metal it's needing another bootloader which the documentation only barely mentions. More on the naming: why to call it kernel?

You still need a bootloader to run the Linux kernel.

Re: Minimal x86 Kernel Zig

#50

Post by toast0 »

kunley wrote: post #28

Why to spread confusion and call it bare metal when it's run under QEMU? Then it's not bare metal at all. In order to be run on bare metal it's needing another bootloader which the documentation only barely mentions. More on the naming: why to call it kernel?

Almost every OS needs a bootloader; but not every OS needs to develop one. Certainly there's some exceptions where there's not really separation between the two functions, but it's not common and most hobby OSes have the distinction unless they're single sector OSes.

The booloader and the kernel are separate stages; they're both interesting, but pick the part that interests you and work on that. With the multiboot standard and existing loaders like ipxe and grub, if you want to write a kernel, there's no need to write your own bootloader.

Otoh, if you want to write your own bootloader, you can do that too, there's plenty of existing kernels to boot.

And yeah, this kernel does nothing. But it would be a reasonable start to a kernel that does things, although you would need to write all the things.

Bare metal in qemu is a little fishy, but it's easier to take a screenshot of qemu than to take a screenshot of a full computer. I would expect this to run on a full computer as long as it supports BIOS booting, and then it would be a bare metal boot and halt kernel.

Post reply on HN