TITLE: An Experience Rewriting a Piece of Code as as Teaching Tool
AUTHOR: Eugene Wallingford
DATE: December 31, 2021 12:13 PM
DESC: 
-----
BODY:
 Over the last four or five offerings of my compiler course, I have
 been making progress in how I teach code generation, with teams
 becoming increasingly successful at producing a working code
 generator.  In the 2019 offering, students asked a few new questions
 about some low-level mechanical issues in the run-time system.  So I
 whipped up a simple one the night before class, both to refamiliarize
 myself with the issues and to serve as a potential example.  It was
 not a great piece of software, but it was good enough for a quick
 in-class demo and as a seed for discussion.

 Jump ahead to 2021.  As I mentioned in
<a href="http://www.cs.uni.edu/~wallingf/blog/archives/monthly/2021-12.html#e2021-12-28T17_31_53.htm">
   my previous post</a>,
 this fall's group had a lot more questions about assembly language,
 the run-time stack, activation records, and the like.  When I pulled
 out my demo run-time system from last time, I found that it didn't
 help them as much as it had the previous group.  The messiness of the
 code got in the way.  Students couldn't see the bigger picture from
 the explanatory comments, and the code itself seemed opaque to them.

 Working with a couple of students in particular, I began to refine the
 code.  First, I commented the higher-level structure of generator more
 clearly.  I then used those comments to reorganize the code bit, with
 the goal of improving the instructional presentation rather than the
 code's efficiency or compactness.  I chose to leave some comments in
 rather than to factor out functions, because the students found the
 linear presentation easier to follow.

 Finally, I refined some sections of the code and rewrote others
 entirely, to make them clearer.  At this point, I did extract a helper
 function or two in an attempty not to obscure the story the program
 was telling with low-level details.

 I worked through two iterations of this process: comment, reorganize,
 rewrite.  At the end, I had a piece of code that is pretty good, and
 one that is on the student's path to a full code generator.

 Of course, I could have designed my software up front and proceeded
 more carefully as I wrote this code.  I mean, professionals and
 academics understand compiler construction pretty well.  The result
 might well have been a better example of what the run-time generator
 should look like when students are done.

 But I don't think that would have been as helpful to most members of
 my class.  This process was much more like how my students program,
 and how many of us program, frankly, when we are first learning a
 new domain.  Following this process, and working in direct response
 to questions students had as we discussed the code, gave me insights
 into some of the challenges they encounter in my course, including
 tracking register usage and seeing how the calling and return sequences
 interact.  I teach these ideas in class, but my students were seeing
 that material as too abstract.  They couldn't make the leap to code
 quite as easily as I had hoped; they were working concretely from the
 start.

 In the end, I ended up with both a piece of code I like and a better
 handle on how my students approach the compiler project.  In terms of
 outcomes assessment, this experience gives me some concrete ideas for
 improving the prerequisite courses students take before my course,
 such as computer organization.  More immediately, it helps me improve
 the instruction in my own course.  I have some ideas about how I can
 reorganize my code generator units and how I might simplify some of
 my pedagogical material.  This may lead to a bigger redesign of the
 course in a coming semester.

 I must admit: I had a lot of fun writing this code -- and revising
 and improving it!  One bit of good news from the experience is that
 the advice I give in class is pretty good.  If they follow my practical
 suggestions for writing their code, they can be successful.  What
 needs improvement now is finding ways for students to have the relevant
 bits of advice at hand when they need them.  Concrete advice that
 gets separated from concrete practice tends to get lost in the wind.

 Finally, this experience reminded me first hand that the compiler
 project is indeed a challenge.  It's fun, but it's a challenge,
 especially for undergrads attempting to write their first large piece
 of software as part of a team.  There may be ways I can better help
 them to succeed.
-----