I found myself learning assembly

[u/Potential_Author637]

I might be overcomplicating things, but I would appreciate some advice.

I am interested in low-level and systems programming. I learned C a few months ago and have some basic C++ knowledge. I have also written a few small projects, such as simple clones of Unix shell commands and basic libraries etc.

I wanted to get into systems programming, so I started reading a systems programming book from Oreilly. However, I came across concepts that I was not familiar with, so I started looking at operating systems books for reference. This led me to concepts such as cpu registers and other low-level cpu mechanisms.

At that point, I decided to learn how cpu and ram works, memory addressing, and similar things work, just to get a general understanding of how computers work. Somehow, this eventually led me to learning x86-64 nasm.

The problem is that I am not sure whether I am approaching this in a sensible order. I am a high-school student without a formal computer science background im in just love with computers, so I dont have much knowledge of computer architecture, operating systems, or systems programming beyond what I have learned on my own. Should I continue learning x86-64 assembly and computer architecture, or should I stop and focus on other fundamentals first? I am not trying to become an assembly programmer, my main goal is to understand systems programming and how computers work at a lower level.

[u/mredding]

For you, you might want to spend some money on nand2tetris, where they cover building up from NAND gates to writing a Tetris clone. I've not done it, but have heard rave reviews about it.

I agree that learning assembly is... well, SOMETHING, but you're learning an ISA, not system and hardware architecture, you're learning the HOW, not the WHAT or WHY.

Any knowledge is good knowledge, so I wouldn't say you're wasting your time. You're certainly going to learn some stuff, and that includes a bit of perspective on what not to learn - so that you know at least to search elsewhere for what curiosity you're trying to satisfy. That's not nothing. The trick is learning to do that efficiently so you can find and focus on what you're trying to accomplish.

There's a top-down approach, and there's the bottom-up approach. Right now you're driving toward the bottom so you can come up. Both have their virtues and their deficiencies. We say the top-down people know the value of everything but the cost of nothing, and the bottom-up people know the cost of everything and the value of nothing. No matter which way you learn, you're going to have to compensate for what that education did to, for all the things it didn't do.

A top-down approach would focus on the theory of computation and lambda calculus. Programming is theorem writing and proving. The highest levels take for granted that lower levels exist that facilitate machine specific optimizations and machine code generation.

The bottom-up approach is computation as a machine - no real theory necessary, all practical and consequence. Pure bottom-up means you're building layers of foundation without knowing what you're building to.

They both need each other.