If you actually start writing big stuff in assembly, esp a macro-assembler, you'd quickly realize it is more verbose, but not fundamentally that different from higher level programming. You basically need to get a hang of how to build abstractions with procedures and macros and you'd be good to go. Reading assembly effectively is often much harder than writing it.
Yeah, that's what I realized during this, too. You need to be much more explicit, but the way any given function works isn't fundamentally different. "strlen" will always iterate through a string searching for a NULL byte whether it's in C, Rust, Assembly, or whatever other language. I think it can feel almost more straightforward than other languages, since you're laying out exactly what the CPU needs to do, in what exact order.
> "strlen" will always iterate through a string searching for a NULL byte whether it's in C, Rust, Assembly
Not all languages use NULL terminated strings. I think Rust actually stores the string length alongside a pointer to the start of the string data. You can do the same in C, but you'd have to do it manually using a struct. In assembly you could do the same thing since you get to decide basically everything.
https://www.youtube.com/watch?v=y8PLpDgZc0E
Pascal stores the length of the string next to the string, but the other thing of note is with the advent of Unicode, strlen is strlen, but often not actually the number you need/want.
Arguably a POSIX assembly programmer would also naturally keep strings along with their size, either explicitly or known implicitly, more similar to Pascal, not null-terminated, as that's how syscalls expect it. Null-terminated would chiefly be a libc-ism.
I argue that strlen is actually still quite often the number you need+want, because possibly the main use case for it is determining how many bytes long a string is.
It is, it just isn't always any more. When printing the string to the screen, the multibyte sequences need to be accounted for, like an emoji that's 2 bytes but only renders as one character too the screen.
Agreed. And super cool project. After seeing Matt Godbolts Advent of Compiler Optimisations in December I decided to do AoC in assembly. Was the most fun I had in years even though I didn't finish all days!
And super educational. Since then I've been pondering which problems require dropping down to the assembly level. E.g. implementing a JIT compiler, a coroutine runtime, etc.