Component graph and conditions #4
Description
A possible use of this interpreter might be to abstract students' code from CMSC 430 to an appropriate level that it can be (roughly) compared with (potentially multiple versions of) the instructor's solution. In doing so, we could quickly identify whether students are roughly on the right path, once they have completed enough of the project. We could also use it to flag significantly different solutions, simply so we can follow up.
I think one way to go about this might be to divide the assembly into components. This lets us skip over trying to analyze students' Racket code. The component can be built by a linear analysis of the instructions. I think we could convert all the control flow operations into two varieties: (1) a jump-if-like instruction that can only test conditions from flags (e.g., if CF && OF, or something of that nature), which always jumps to a label (and so new labels would be generated to separate the components), and (2) the typical Call and Ret system (because these cannot be perfectly simulated through other instructions, since they do not modify the flags).
After separating the assembly into components, each component could be analyzed for register usage. A list of registers written to and read from could serve as a sort of condition that connects the components. Registers themselves could be abstracted for the most part into "caller-saved" and "callee-saved", allowing us to ignore arbitrary choices students may make (e.g., r10 vs r11).
I've no idea how practical this will be, but I think it should not be too much trouble to implement at least at a basic level, so it may be worth implementing regardless.