Skip to main content Skip to local navigation

Is Assembler the Latin of Programming Languages?

Is Assembler the Latin of Programming Languages?

How bad and outdated is Assembler?  For many of us, Assembler is the Latin of programming languages.  Below, I talk about my changing perspective on this.

In preparation for the embedded systems course I'll be helping to teach at the INSA in Strasbourg I'm reviewing my PIC-based teaching material, mostly based on the PIC32.  This is because the course at INSA focuses on applying theory using the PIC16F84A, a predecessor to the PIC32MX chips I've often used.  This PIC16 continues to be used because it has a small instruction set, is bread-boardable and is well documented online and in easily-accessible books like Easy PIC'n.  Lessons learned on it can easily be applied to other PIC chips, as well as other architectures (ATMEGA, SAMD, Kinetis, etc.).

Furthermore, I'm planning a book on C programming in embedded systems and want to write it from a hardware debugging perspective, as opposed to the shot-in-the-dark "hello world" perspective.  This is going to mean having to look at disassembly listings and mixing C and Assembler.

The debugger's program memory view while simulating the Microchip ATMEGA328.

The debugger's program memory view shows us the "disassembled" C code while simulating the Microchip ATMEGA328.

For the longest time I avoided using or teaching Assembler directly. It can be gouge-your-eyes-out frustrating.  It's hard to read, hard to maintain and changes from one processor to the next, even in the same chip families.  To many of us, Assembler was the Latin of programming languages. 

That said, I've recently had a change of heart.  There are two main reasons.  First, in order to teach programming from an inductive (self-learning) perspective the teacher should provide tools to the student that permit self-discovery.  Yes, while it's easy to  printf your way through the code, it's an awkward and imprecise way to actually see what's going on inside the chip when it executes your program.

Second, there is an applied, real-world reason for students to learn Assembler: jobs.  The Information Security community uses Assembler on a regular basis to analyze malware and to search for vulnerabilities in programming code.  There are also some really good free / open source (radare2, cutter, built-in diassembler in MPLAB X and MCUXpresso, Visual Studio), low-cost (hopper, Binary Ninja) and high-end tools (IDA Pro) that can help students (and me!) explore Assembler and the relationship between the original C source code and the resulting Assembler.

Plus, there is fresh material being produced on Assembler and code analysis that is way more appealing than the stodgy old Assembler texts that I had to learn with in the 1990s.  Billy Ellis' book is perhaps the easiest-to-read, beginner-friendly book I've ever seen that relates to Assembler. Given that many people in the InfoSec community are focusing on ARM due to its large presence in both embedded and mobile computing, it gives some incentive to specifically learn ARM-flavoured assembler debugging tools.  Azeria Labs' materials on ARM assembler material is freely (or cheaply) available and well done.

So, with that in mind, I'm going to update my Mixed-C-and-Assembler for PIC32 material for use with 8bit PICs and ATMEGAs.