Today, I went to a workshop on low-level programming at Bradfield CS, a nontraditional computer science school located in downtown San Francisco.

The instructors, Oz and Myles, are sharp people with a great commitment to computer science education through small-group instruction. Both have years of experience in the software field and clearly know their stuff1.

The workshop was from 10:00 AM to 3:00 PM, and included 5 participants (aside from Oz and Myles). For the first hour, we briefly covered CPU architecture, the MIPS instruction set and why RISC is the future rather than CSIC. For the next hour and a half, we did some MIPS exercises as a group. During the remaining time, we paired up and did some more MIPS exercises.

A single workshop is not enough to become a great assembly programmer, of course, but it highlighted some important ideas about assembly programming and why it's important.

For example, it is well-known that iOS does not support the JVM. This is due to Apple's policy of allowing only "examined" code to be run. Without learning assembly, however, it's hard to understand why this "examination" requirement precludes JVM support.

The reason is this:

A program's memory is laid out in sections:

The text segment contains program instructions. To run the program, a program counter (PC) is loaded with different addresses, which are the locations of different instructions to be executed. We imagine the program counter to be a pointer to the different addresses.

The JVM, however, does just-in-time (JIT) compilation, which involves compiling bytecode to instructions stored on the heap and "jumping" the PC out of the text segment to the heap where instructions are stored.

If the PC can jump out of the text segment to the heap, then a program could run arbitrary code (e.g. code downloaded from the internet), not just the code in its code segment (which, at least in theory, could be examined by Apple). Since Apple has promised users that its apps would only run examined code, iOS cannot support the JVM (or any JIT compiler that works this way) without a policy change.

This becomes clear only if we delve into the low-level programming that most programmers today have no experience with. As a functional programmer, I'm very glad to have gone to this workshop and learned to see things a bit from the low-level perspective.



Those who are interested in increasing their computer science knowledge through mentorship and hands-on learning should definitely check out Bradfield.