I began learning computer programming with Logo [1], then BASIC, then C, Lisp, etc. However, somewhere along the way, growing dissatisfied with not knowing exa

I began learning computer programming with Logo [1], then BASIC, then C, Lisp, etc. However, somewhere along the way, growing dissatisfied with not knowing exactly what's going on under the hood, I began descending down the stack. That journey led me to learning about the CPU, using assemblers, as well as loading instructions in hexadecimal format into a memory by pushing buttons on a 8086 trainer kit. At one point, I also designed my own Mano Machine in VHDL which I then synthesised and tested on a Xilinx CPLD kit [2]. The last one was the most fun. It was very rewarding to see the abstract concepts presented in books come alive in the form of a working machine that could fetch, decode, and execute instructions from a memory. The memory was designed in VHDL too and implemented on the same Xilinx CPLD kit. Loading instructions into the memory required me to push DIP switches (one switch for each bit). A far cry from the comfort of Emacs running atop a modern operating system! Those two adventures lied on opposite ends of a spectrum. There was the luxury of high level languages and tooling at one end. On the other end, there was the hands-on ritual of loading each bit of instruction, accomplished through the deliberate act of manipulating DIP switches. Such a laborious experience prompts a profound awareness that ultimately all software executes on physical matter. Nestled in between these two extremes, there was a sweet spot involving assemblers. The first assembler I stumbled upon was the "A" command of DEBUG.EXE [2] of MS-DOS. The features were very minimalist and the tool was a bit more than an assembler. This humble debugger allowed me to peek into interrupt vector tables, inspect the content of ROM, learn how MS-DOS boots from scratch, etc. I later did come across GNU as, TASM, NASM, etc. which made me appreciate the number of bookkeeping problems a proper assembler solves. No more recalculating all the offsets for the jump and call instructions after every refactoring of the program! These days, I work very high up in the stack where there are numerous layers of technology between what I type and what the physical machine executes. But I do fondly remember the days when armed with an assembler, some knowledge of the CPU and the computer architecture, we could plunge into the depths of the system, unravelling its intricacies to our heart's content. [1] https://susam.net/blog/fd-100.html https://susam.net/blog/fd-100.html [2] https://github.com/susam/mano-cpu https://github.com/susam/mano-cpu [3] https://susam.net/blog/programming-with-dos-debugger.html https://susam.net/blog/programming-with-dos-debugger.html