3 ms·

I teach C. It's an increasingly terrible way of learning "how a computer works". You would be much better off learning a little assembler. The problem is most

I teach C. It's an increasingly terrible way of learning "how a computer works". You would be much better off learning a little assembler. The problem is most of the pain of learning C comes from undefined behaviour, which isn't how "computers work". The fact that depending on optimisation level writing past the end of an array might write to memory, or might not, is (mostly) a unique feature of C. Similarly sometimes a signed integer will overflow "cleanly", but then sometimes undefined behaviour will kick in and you'll get weird results. This (ironically) makes checking for overflow when adding integers in C annoyingly complicated. With assembler if you write through a pointer, you write to that memory location, regardless of if you "should" be right now. You do multiplication or addition and you get well-defined 2s-complement wrap-around.

dvlsg 8y ago
When I was learning assembly, one of my favorite things to see was what assembly got generated (more or less) from really, really simple higher level application code (C, C++, etc). Code consisting of really simple arithmetic, loops, function calls, object creation, etc.
T-hawk 8y ago
> You do multiplication or addition and you get well-defined 2s-complement wrap-around. You get that, if that's what your CPU implements. Of course that's what all commonly used processors nowadays like x86 do. But C was meant to run on weirder ISAs as well. The specs of C allow so much undefined behavior in order to let C just emit the instructions for the multiply or memory access, and C deliberately says "not my problem" for whatever this architecture happens to do with edge-cases like overflow. Using assembly instead of C cuts past the abstraction of the architecture, for both good and bad. You get defined behavior but lose portability. Practically speaking, yes, x86 assembly probably is a better way to learn without getting distracted by forty-year-old hardware oddities.

dvlsg 8y ago

When I was learning assembly, one of my favorite things to see was what assembly got generated (more or less) from really, really simple higher level application code (C, C++, etc). Code consisting of really simple arithmetic, loops, function calls, object creation, etc.

T-hawk 8y ago

> You do multiplication or addition and you get well-defined 2s-complement wrap-around. You get that, if that's what your CPU implements. Of course that's what all commonly used processors nowadays like x86 do. But C was meant to run on weirder ISAs as well. The specs of C allow so much undefined behavior in order to let C just emit the instructions for the multiply or memory access, and C deliberately says "not my problem" for whatever this architecture happens to do with edge-cases like overflow. Using assembly instead of C cuts past the abstraction of the architecture, for both good and bad. You get defined behavior but lose portability. Practically speaking, yes, x86 assembly probably is a better way to learn without getting distracted by forty-year-old hardware oddities.