Assembly Nights
ratfactor.com
ratfactor.com
Then I decided to try Nim, I found it very ergonomic and lets you write compact code that expresses the main logic without too much syntax noise. But I got blocked by some issues making it work for a UEFI target.
Then I tried Zig and got as far as parsing ACPI tables and writing an AML bytecode parser. Zig is nice and I like its optionals support and error handling approach. But I was put off by its noisy syntax (e.g. !?*[*]u8 to represent an error union of an optional pointer to a many-pointer of uint8). Also having to prepare and weave allocoators throughout most of the code that needs to dynamically allocate (which is most of the code) gets in the way of the main logic. Even little things like string concatenation or formatting becomes a chore. In the end I realized that Zig is not for me.
So I got back to Nim and resolved the issues that were blocking me. I'm now on my journey to write a complete kernel in Nim (so far I have access to UEFI services and ACPI table parsing and on my way to get interrups working). The code is pleasant to write and read. Also the language and the stdlib documentation is great (Zig's stdlib documentation is almost non-existent.)
Overall, I found that systems programming is very satisfying, and you can depend on specs that rarely change (some are over 20 and 30 years old and still work the same way today) and is quite a welcome change from web dev where it depends on tech de jour.
Edit: Here are the github repo links:
- C kernel: https://github.com/khaledh/bitflow
- Zig "kernel": https://github.com/khaledh/axiom-zig
- Nim "kernel": https://github.com/khaledh/axiom
I didn't avoid malloc. I provided a simple bump pointer based heap to get things going. Later I'll have to separate things into a UEFI bootloader and a proper kernel image, each with its own allocator (the bootloader will use UEFI memory allocation services, and the kernel will have its own heap).
Unfortunately, this does not work for writing the blog about the project. Hopefully this will change soon, once I write an editor and filesystem...
I think that programming in assembly language is compelling because it is "rightsized" for the human brain. You spend a lot of time solving small, manageable puzzles about the best way to do achieve small victories like trying to squeeze every last cycle or byte out of some small section of code. And then you sit back and laugh because after all that struggle you managed to compute something that would take an insignificant amount of effort to do in a high level language. But it works on this very limited device, and that's a thrill.
[1] https://www.youtube.com/watch?v=yl8vPW5hydQ [2] http://skilldrick.github.io/easy6502/
Official "Discovery boards" from ST include a programmer and debug connection for under $10, and cheap dev boards are plentiful. Open source C compiler SDCC, and free tools from ST.
There is also a very good Forth [0]. Even if Forth is not your thing the site has a lot of good information on STM8.
Now we have too many distracting mediums that are only a click away.
Internet has made many things easier, but the real cost of it is yet to be determined.
When the author talked about reading the entire GNU Screen manual I did think “this sounds like stressful overkill” for a personal project, but I see their point about focusing on process rather than goal.
Does it ever really matter than personal projects don’t get finished?
taps temple
For example, translating one assembly to another with the same architecture might fit the description because most of the time you are just doing "translation". Of course I'm not an assembly professional so I might be underestimating the difficulty here.
Another good example is carpentry. As long as you finish step X you can leave it there. There is no need to burn candles to finish all steps at once.
A bad example is algorithm design. Unless it's second nature to you, it's really difficult to decompose it into steps (because maybe they are wrong steps), and even if you can, picking up from where you left off last night might actually be more difficult than starting over from the beginning.
The other evening I did a small amount of work on a compiler I’m making and for ages all I could think was “compilers! So cool! Making those basic blocks! Yeah!”.
It would be cool if I had a dream where I intuitively understood whatever I was designing, but my dreams aren’t that insightful…
I'm not sure how into systems programming you are, but there is globs of interesting assembly worth optimizing in various kernels. Interrupt routines, optimized memcpy, filesystem encryption, etc. are all great places where a small speed boost will have very large impacts on the overall platform performance.
I confirm that its one of the most satisfactory ways to add some numbers using a modern computer.
* Intel AVX Programming Reference [0] - comprehensive but not very useful as "where do I even start"
* Godbolt[1] to look at code samples produced by compilers. This is good to see how the instructions work together.
* A random discussion that has *some* concepts behind the YMM registers[2]
* Stack Overflow, for example [3]
[0] https://www.intel.com/content/dam/develop/external/us/en/doc...[1] A sample code that generates some AVX2 code: https://godbolt.org/z/Kr1sojov6
[2] https://community.intel.com/t5/Intel-ISA-Extensions/Software...
I had been struggling with the same thing, but these are some great sources. Thanks :)
https://github.com/skx/math-compiler
I had far too much fun writing it, even though it is completely pointless!
Kudos to Dave for a great read, he's inspired me to dust off my own EeePC!..
I haven't figured out how to get gdb hooked so I'm just debugging with a print integer routine. That's annoying.
And writing to and reading from the bios video service (int 10h) in my text editor bootloader is not the most fun. Randomly characters get overridden and it could be my code or register state I haven't reset but it's pretty hard to get right and understand the bios APIs.
I'm getting ready to give up than write anything about my bootloaders since their behavior is not always deterministic in more complex programs (boot4.asm is the complex text editor and sometimes when hitting backspace on the last column in a line the cursor sometimes freaks out trying to find the end of the previous line.)
As an owner of one these ASUS EeePC netbooks I used links (a different text-only browser) in VGA textmode in NetBSD for many years. For the small screen size, the terminal font is easy on the eyes. Lynx is one of the worst text-only browsers, IMHO. For me, staying in textmode prevents distraction. However I am reading from the www in textmode all the time. A large, complex, Javascript-enabled, advertising-sponsored, graphical browser is not necessary. No idea what "modern Web surfing" means but it does not sound like it is worth the time if all it produces is distraction.
What are you using then? I didn't like the "bloatedness" of the modern web. So I often use browser "reader mode". But I would happily try something different.