2 ms·
I mean, if that's going to be your justification for learning C, then shouldn't you be learning how to create 16 bit adders from flip-flops, learning about the
by saberience 4y ago
I mean, if that's going to be your justification for learning C, then shouldn't you be learning how to create 16 bit adders from flip-flops, learning about the importance of mux and demux chips, and then building an ALU and FPU in verilog and testing them in a simulator?
I would argue that assembly language and hence C has been shaped that way it has because of the underlying structures of the processor and the way binary numbers are manipulated and stored. C and for that matter assembly, becomes quite trivial if you know enough to make your own simple CPU with decoder, instruction set, memory, ALU, FPU, etc.
- musicale 4y agoI tend to think (agree with you?) that understanding computer architecture will make you a better system designer and developer. That's probably why many CS programs (and systems concentrations in particular) require a computer architecture course. Verilog is of course C-like (much as VHDL is Ada-like.)
- MisterSandman 4y agoThis comment is far from reality. It's difficult to measure what a "good" programmer is, but regardless of decision I am confident that it will have no correlation with whether you learned Verilog or what a D Flip Flop is.
- musicale 4y agoMissing the forest for the trees. Computer architecture courses often expose you to things like: caches, memory and storage hierarchies, I/O, software/hardware interface, parallelism, Amdahl's law, pipelining, vector processing, prefetching, speculation, synchronization, clocking, interrupts, vector processing, data encoding, stream processing, virtual memory, general virtualization, isolation etc., etc.. If you care about execution time, responsiveness, efficiency, or reliability, these things matter. If you're doing systems programming, they are essential.
- delusional 4y agoI actually agree that moving in that direction is useful. I happen to have started from a quite high level (C# and VB.net), but I've been steadily moving down the stack towards embedded devices. I've been surprised many times by how many problems we've created for ourselves, and how much easier they become once you simplify.