The issue to get rid of the llvm-objcopy build dependency is https://github.com/ziglang/zig/issues/2826. This appears to be the only thing that is currently required to be installed besides Zig itself.
I tried to get Zig running on a Game Boy Advance a while ago, but never really got to a point I was happy with. Great to see someone else working on it!
It's cool that you got the built-in linker to work. When I tried, I got a bunch of "unsupported architecture" errors and had to use GNU ld. Have things gotten better recently or is this an ARM-vs-Thumb thing?
I was excited to be able to use packed structs to represent the different IO registers -- at last, no more OR-ing the wrong flag into the wrong register! -- but unfortunately those don't quite work right on ARMv4T yet: https://github.com/ziglang/zig/issues/2767
Hmm that's certainly an interesting project. But I have to wonder if writing "defer file.close()" everywhere is really superior to RAII. Isn't defer also kind of hidden control flow? At that point I feel like RAII simply offers more, first of all you don't have to write what you want to defer everywhere, and second of all you can actually move resources around and still rely on it.
Also the integer overflow section struck me as kinda odd - what if I want wrapping behavior? That's not exactly a super uncommon scenario.
Wrapping is not a good default, and actually it's not that common a scenario.
When you want arithmetic to wrap, you should use some way to explicitly denote that you want it to wrap. (I think it could look like an operation with a modulo reduction or mask applied to it.)
defer is way more transparent than RAII, because your code is right there in the function call, not hidden in a pile of classes that might change underneath.
This is so cool! I'm really impressed with what I've seen out of Zig so far. I need to come up with a project to try it out with. It seems like a great successor to C
Yep. Zig is shaping up to be the low-level programming language I've been waiting for to replace C++ for me. It just needs to mature and stabilize a bit before it's production-quality.
Do you have a public repo of your Advent code? I started out trying to use Zig but couldn’t find documentation on how to complete even basic tasks (like passing a filename as a command line arg, then opening and reading a file line by line), so I gave up. Maybe seeing a repo of good Zig code accomplishing these tasks would get me going.
Zig looks neat; a nice middle ground, not as preachy as Rust -- I took a stroll through the documentation but didn't get a sense from it how suitable it would be for baremetal or OS programming... Specifically about its standard library..
* How dependent on libc is Zig, if at all?
* What kind of runtime expectations does Zig have? Does it need a malloc, for example?
* How big is its standard library?
* Is it possible to write code without its standard library?
Zig was started with that exact use case at the forefront of its design.
- Zig has no hard dependency on libc, it's the user's choice whether he wants to link it or not. It ships musl libc and can build/link it for most (all?) supported targets.
- Most of Zig's standard library works on freestanding targets. No runtime needed. There are no implicit allocators, so the user must use an allocator shipped with the standard library or implement their own.
- Standard library is still in its early days but already provides a lot of functionality out of the box, from containers to io.
- Using the standard library is optional. When it is used, only what is used gets included. The standard library is built from source every time (though there is caching) and its semantic analysis basically does LTO in the codegen stage so you end up with pretty slim binaries.
I don't get the first statement: no hard dependency on libc and ships with musl libc. Does Zig need a libc, so they ship musl libc? Or is it fully self hosting?
What is the state of GBA homebrew? I've been curious about learning how to make games with it, but I haven't had much luck finding information about the toolchains. I know for original Game Boy/Color, there is a C compiler, but it's not recommended over assembly. Is the GBA the same way?
The impression I've gotten is that the GBA is powerful enough that you can write most of your programs in C, but some performance-critical stuff (like if you're trying to draw pixels directly instead of using the sprite/tile hardware) is best written in assembly. If you're interested in learning more, I would highly recommend this tutorial: https://www.coranac.com/tonc/text/toc.htm
GBA is very well documented (gbatek). The DS seems to be as well, but it's much harder to work with. GBA is much easier, but still powerful enough to do non trivial things without having to do them all in assembly. Emulator support is superb. Hardware adapters that allow you to load ROMs have been around forever.
I'd say it's one of the best systems to get into on-the-metal Homebrew.
There’s more potential complexity if you want to do complex things and maybe 3D is hard (I’ve never done it) but the basics are about as straightforward.
What are the advantages of this other than showing the language is competent enough that you can write a compiler for itself? Would it be better to keep a compiler written in a highly portable language such as c? Genuinely curious.
I think it is usually considered a right of passage of a new programming language to prove that it is mature enough to self-host.
Personally, I value that aspect highly because it means if I choose to work with a language that I can understand, read, and possibly contribute to the compiler if needed.
Readit News
It's cool that you got the built-in linker to work. When I tried, I got a bunch of "unsupported architecture" errors and had to use GNU ld. Have things gotten better recently or is this an ARM-vs-Thumb thing?
I was excited to be able to use packed structs to represent the different IO registers -- at last, no more OR-ing the wrong flag into the wrong register! -- but unfortunately those don't quite work right on ARMv4T yet: https://github.com/ziglang/zig/issues/2767
Also the integer overflow section struck me as kinda odd - what if I want wrapping behavior? That's not exactly a super uncommon scenario.
When you want arithmetic to wrap, you should use some way to explicitly denote that you want it to wrap. (I think it could look like an operation with a modulo reduction or mask applied to it.)
defer is way more transparent than RAII, because your code is right there in the function call, not hidden in a pile of classes that might change underneath.
https://www.youtube.com/watch?v=Z4oYSByyRak
(good watch)
https://www.youtube.com/watch?v=Gv2I7qTux7g
A lot has changed since then, and a lot has changed since that Localhost talk. To catch up:
* (the older talk happened here)
* 0.3.0 release notes - https://ziglang.org/download/0.3.0/release-notes.html
* 0.4.0 release notes - https://ziglang.org/download/0.4.0/release-notes.html
* (the newer talk happened here)
* 0.5.0 release notes - https://ziglang.org/download/0.5.0/release-notes.html
https://duckduckgo.com/?q=site%3Anews.ycombinator.com+zig+la...
- Zig has no hard dependency on libc, it's the user's choice whether he wants to link it or not. It ships musl libc and can build/link it for most (all?) supported targets.
- Most of Zig's standard library works on freestanding targets. No runtime needed. There are no implicit allocators, so the user must use an allocator shipped with the standard library or implement their own.
- Standard library is still in its early days but already provides a lot of functionality out of the box, from containers to io.
- Using the standard library is optional. When it is used, only what is used gets included. The standard library is built from source every time (though there is caching) and its semantic analysis basically does LTO in the codegen stage so you end up with pretty slim binaries.
Here's a couple of examples:
- https://github.com/andrewrk/clashos
- https://github.com/AndreaOrru/zen
* How dependent on libc is Zig, if at all?
* What kind of runtime expectations does Zig have? Does it need a malloc, for example?
* How big is its standard library?
* Is it possible to write code without its standard library?
The impression I've gotten is that the GBA is powerful enough that you can write most of your programs in C, but some performance-critical stuff (like if you're trying to draw pixels directly instead of using the sprite/tile hardware) is best written in assembly. If you're interested in learning more, I would highly recommend this tutorial: https://www.coranac.com/tonc/text/toc.htm
I'd say it's one of the best systems to get into on-the-metal Homebrew.
There’s more potential complexity if you want to do complex things and maybe 3D is hard (I’ve never done it) but the basics are about as straightforward.
https://github.com/pspdev/psptoolchain
[1] https://github.com/ziglang/zig/projects/2
Personally, I value that aspect highly because it means if I choose to work with a language that I can understand, read, and possibly contribute to the compiler if needed.