2 ms·
I agree. I simply think, the assembly model will be replaced. There will eventually be a new, "better," set of principles. For reasoning about library gluing
by urthor 4y ago
I agree.
I simply think, the assembly model will be replaced.
There will eventually be a new, "better," set of principles. For reasoning about library gluing.
> Knowledge of the underlying machine is irrelevant.
> As you look back on your assembly experience later, you'll realize this is false.
Better to clarify: truly deep knowledge of the underlying machine is irrelevant.
At this point, I'd say I'm immensely richer from "thinking" about assembly. Nowhere else would I have truly learnt about CPU cycle times to copy data from register to register to call stack, and back. The concept of "time to copy data" is highly present in networking and other fields.
Important to know that "C" and other high level languages abstract over it.
I'm not entirely sure my knowledge of JTAG debugging/Rust borrow checker is ever going to be substantially useful. The time/benefit equation of doing all that work was... less than ideal.
In hindsight, maybe an afternoon of assembly copying data from place to place, seems like "all" the big picture learning I needed?
Then again. Maybe I invested far more time than undergraduate courses spend on the topic, regardless.
- inimino 4y agoOn the JTAG points, I (sadly) don't have enough hardware hobbies under my belt to appreciate that pain. On the Rust borrow checker front, I too share this same sunk cost and the have the same lingering regret. Uniqueness types have been done before and better, but it's interesting for systems programming, and already better than C++. Just don't do applications work in it, unless you would pick C or C++ for the same job.