|
Administrator
|
I've been killing quite a few birds with one stone and thought others might consider something like it.
Here are issues that I am trying to address or points I am trying to get across:
1) The little bit of assembly programming that the students do in ECS-04 leaves many of them poorly prepared to write some of the VM code.
2) Gain an awareness of more a more primitive means of writing/calling ASM subroutines. This has a two-fold purpose. First, it gives the students a firm idea of most of the housekeeping mechanics that the VM code will eventually have to deal with and it lets them see the way that you often write code in real microcontrollers, especially the more brain-dead and/or resource-starved ones.
3) Gain an awareness of the tradeoff between hardware complexity and execution performance.
4) Gain an awareness of the tradeoff between code abstraction and execution performance.
5) Gain some familiarity with the notion of bootstrap code that calls a main subroutine that then implements the high level logic and calls other subroutines as appropriate.
So what I did was the following (after ECS-04, so I called it ECS-04B):
I presented to the class a strategy for implementing subroutines in ASM that is a compromise between one-depth subroutine calls (where all subroutines use a shared set of scratchpad memory) and the full up stack-oriented approach used by the VM translator. In this compromise, each subroutine has it's own scratchpad, so subroutines can call other subroutines without any problem. But the subroutines are not re-entrant and so a given subroutine can only be in the current call chain at most once.
I organized the scratch pad so that the first entry was the return address and subsequent entries are the arguments and return values (sharing the same space). So this gets across the basic idea of dealing with the return address as well as parameter passing as well as how a coherent naming convention can let the code leverage the variable assignment feature of the assembler.
Next the students implemented thirteen functions:
1-bit shift/rotates
SLL: Shift Logical Left
SLR: Shift Logical Right
SAR: Shift Arithmetic Right
ROTL: Rotate Left
ROTR: Rotate Right
N-bit unidirectional shifts/rotates
SLLN: Shift Logical Left
SLRN: Shift Logical Right
SARN: Shift Arithmetic Right
ROTLN: Rotate Left
ROTRN: Rotate Right
N-bit bidirectional shifts/rotates (N>0 means move to right)
SLN: Shift Logical
SAN: Shift Arithmetic
ROTN: Rotate
I then prepared an ASM file that has a subroutine called MAIN and that walks through and calls each of the thirteen subroutines in turn, passing data into it from a fixed array of memory (initialized by the test script) and writing the return values to a different array of memory (output by the test script). I also have a small bootstrap code fragment that sets a "running" flag, calls MAIN, and then clears the running flag before going into an infinite loop.
The test script then monitored the running flag to know when to stop simulation, while the infinite loop lets the program be run without the test script.
Looking ahead, for Project 13 I put out a number of extra credit ideas for students to expand the hardware, the software tools (assembler, VM translator, compiler), or the OS libraries. One of those will be to redo the subroutines after implementing a barrel shifter within the ALU.
|
Locked
