How do you wow second-year students into saying "bare-metal programming is cool!"?

Question

Next semester I will be TAing a computer organization/assembly language course. I will be full-fledgedly (co-)teaching the lab. The first lab will take place before the first lecture, so me and the other TA will partly be responsible for preparing the students to not resent this class they're forced to take. At this point, the students have taken an intro class with Python and a class on OO concepts in Java, and they might be taking a language-agnostic algorithms class at the same time. The professor's standard way of motivating the concept on the first day is showing how going through an array column by column is slower than row by row even though they give the same result using the same approach.

Therefore, I have to motivate on two fronts: why is assembly programming (or even C) interesting/relevant, and why is computer organization interesting/relevant. The latter may seem obvious if you're already in the know, but it sure didn't for me before I took this very course.

Here are some of the points that I already intend to include in my opening spiel (everything that starts with a backslash is spurious):

"If you go into data science: the information in this course will explain why certain programs are slow, which is important if you're churning a lot of data.
\You will learn how to write faster programs in general.
You will understand how computers actually work, no magic [I don't have to mention that they won't learn everything].
\This class might make you interested in systems-level programming, even considering a career.
Do you ever feel awed at those other guys with their cool Arduino or Raspberry Pi projects? This class will teach you how to do what they do."

What are some other motivators that I can include?

EDIT: Just to be clear: I have no control over the lab, and definitely none over the lecture. I won't even be present for the professor's lecture. What I have control over is what I explain as I explain the pre-baked labs, which in the first three weeks include an introduction to ssh, C, certain binary algorithms, and pointers. Aside from the ssh, these are supposed to segue everyone into asm.

Answer 1

First, just a disambiguation: are you teaching Assembly language or C? Cos, they are not same as your question seems to suggest. C is a high-level procedural clean code language with tremendous abilities to speak to the bare metal similar to but not as Assembler pls. It may help you bridge to assembly but it is not assembly. Let that be clear to your students.

Never taught machine programming/ASM. But your question touches something in me: the need to wow! the student; I have same predilection with students. So I felt obliged & did some talking with friends in the know and some research.

Here’s the widow’s mite I pieced together. Hope it helps: You can add the following to your first lab “sales pitch’:

1. Let the first lab be a NO CODE, no Technical stuff class. Just getting familiar with selves and ASM in a general way with nothing too technical and thus “intimidating” or “off-putting”. The class should be (pardon my cliché): sugar and spice and all things nice. Toward this:

2. Add to your spiel, a history of Assembly telling them of Kathleen Booth & others etc. Make it interesting. Search & find some spectacular successes and exploits using ASM and also some disasters of sloppy ASM. Apart from sparking interest and discussion, the last part will have the additional pedagogic value of sensitising the students to their power as oracles speaking to the small dumb “god” in the machine. Also it will put them on notice of the enormous responsibilities their heightened power as bare metal oracles imposes on them to avoid sloppy code (not only for ASM but programming generally).

3. Let the students see how the higher level languages with their swagger and leaky algorithms are actually, mostly dependent on ASM and C. Let them see that a lot of our higher level constructs e.g. macro were borrowed from Assembler.

4. As @Buffy I. rightly pointed out, talk alone can’t win a non-committal or skeptical mind. To give them something interesting: show them some good things (e.g. games) made in Assembler and display for them on slide (s) the assembly code snippets that made such things. In this regard I found some of these online and hope they may help or stimulate some interesting ideas: https://spectrum.ieee.org/geek-life/reviews/three-computer-games-that-make-assembly-language-fun.amp.html

https://www.quora.com/What-are-some-cool-assembly-language-projects-I-can-do?top_ans=21546329

https://brianslam.wordpress.com/2014/04/06/assembly-is-fun-sort-of/

https://news.ycombinator.com/item?id=16710543

This one is a Compendium of Assembly Coding Practices from Coding Project. It may help illuminate your teaching: https://www.codeproject.com/Articles/1116188/40-Basic-Practices-in-Assembly-Language-Programmin

Answer 2

You may not win if you just use words. Instead, give them interesting but challenging exercises to do.

One of the most fun exercises I ever did was to produce a Quine in assembly language. But, instead of producing a textual version of itself, as most Quines do, it produces a running copy in memory and then executes (branches to) that copy. The copy seems to act as if the program is moving through memory. As such, the program is called an Animal. This was once a standard exercise at Dartmouth, and I learned it from faculty and students there.

A more elaborate version will erase the old copy as it creates the new.

The book XINU (XINU Is Not Unix) by Douglas Comer has some interesting things. One of which is a microkernel for an OS.

Unfortunately, this is also one of the skills needed by machine level hackers.

To run such a program you need to assure that the OS won't get in your way, however, so you might need to do this on a simulator.

You can also do interesting things with race conditions and such that are harder to teach in higher level languages.

Answer 3

Forth is very interesting language which can run on bare metal, and also be as high level as you want (I've see a compiler/interpreter of subset of Pascal implemented in 11 pages) and will stretch brain of your students. I know it did mine :-)

And is trivial to code some definitions in Assembly if you want.

Code is incredibly compact, ideal (and still used) for embedded systems.

Answer 4

I may be late to game, but you should target four "wow"s:

• "wow, how small .exe file is!"
• "wow, how fast this program is compared to Python!"
• "wow, and THAT is how it's done!"
• "wow, I'm a hacker now!"

For first one, you should compare compiled sizes of some Go, C++, C and assembler programs which all do a same thing. (Mandelbrot fractal generator in Asm is 61 bytes! Check https://github.com/leto/asmutils/blob/master/src/bonus/mandelbrot.asm, it is runnable)

For second you should show implementation of some number crunching algorithm (beware GPU computing -- try to find example, which can't be sped up with GPUs or optimized by SIMD)

For third one, I like to explain the MBR (even though it is no longer popular). You can put a small command line in 512 bytes of MBR, and load it as floppy in QEMU or from USB on real hardware. It often looks like miracle that you can run code without OS. (http://www.osdever.net/tutorials/view/hello-world-boot-loader)

For fourth one, show how to disassemble code in a disassembler, edit some string, save and run it with new string. Patching binaries no longer will look like mystery.

Answer 5

I would argue the best way to do this is have some demonstrations prepared: things they can build with the tools you're teaching that "look" flashy and exciting. Show some cool programs written in C, demonstrate some sort of Arduino-based program that looks interesting (a relatively simple one I've seen waters plants), something in assembly that looks interesting, and so forth.

Make them say, "I want to build that!" before you give them the tools to build it or things like it.