Matthew-McRaven
commented
2 years ago For (1,2): I've implemented something like that in the next major version of the terminal application. I track memory+register changes with respect to time, targeted at enabling backwards stepping. It should be extensible to generating memory traces.
Another upcoming feature will be unit tests. You will be able to specify the the ending values of memory addresses and registers via a configuration file passed to the terminal application. This still only gives you information about final results, but in a much more detailed way than is currently available.
Do you think these two upcoming features enable the scenarios you want?
fstonedahl
A few enhancement requests:
1) Would it be fairly easy to add an option for the Pep9Term application to dump out the contents of memory to a separate file after the program completes running?
This would give us a broader range of options when trying to write autograders to check assignments or exercises. (e.g., right now a student assigned to write a Pep9 function that multiplies two numbers could simply write a program that multiplies two numbers, without properly using a function and call stack, and the program input/output would still be exactly correct. Having access to the computer's memory (especially the runtime stack) would allow us to check whether students are using the stack appropriately.
2) Perhaps even more convenient would be a log of memory changes over the course of the program -- e.g. instrumenting an extra logging/print feature whenever STWA or STBA or DECI (or anything else that changes a value in memory) gets called, and output those in a log file like this:
mem-address new-value 001A 4B FB8E 09 ...
Something like this would allow checking for whether the students were putting the correct values in the correct places on the runtime stack during function calls and returns.
It could also be useful for having students write some simple programs early on whose task was to modify memory at certain locations, rather than just writing to stdout.
3) Any other ideas that you might have that could be easily outputted as text, and would give a better sense about how the program executed, and not just what the final results were?