(retLabel should have been LretLabel in the
call macro.)
A macro is basically textual substitution -- there is no "function call". Macros in assemblers are very similar to macros in C or C++. They take parameters, and these are just textually substituted. To see this, let's look at the gauss subroutine in its various forms: first, as a macro assembler source file, then as a ``pure'' assembly language file where all of the macros are expanded, then finally as ``machine code'', where addresses are assigned to every instruction and datum, and the instructions are replaced with their numeric machine-code form. You may want to click on the above three links using your middle mouse button (if you are using Netscape Navigator) or shift-left-click (if using Microsoft Internet Explorer) to view those files in separate windows so you can compare them side-by-side.
Next, we went over how to call subroutines by using self-modifying code to create, at run-time, a ``return'' instruction. This is done by replacing the memory at the ``return'' position in the called code with an unconditional jump. The example main routine which calls gauss takes as input a number M, and repeatedly calls gauss with parameters 0, 1, ..., M-1, storing the results in an ``array'' starting at address 0x0300.
The process of indexing an array is very similar in construction to ``return'' instructions. Here, instead of each caller placing the appropriate ``goto'' in a ``return'' position in a called program, the array indexing code will construct an instruction to clear the appropriate array element immediately prior to using it. Similarly, it will construct an instruction to copy the result of the subroutine call to the appropriate array element immediately prior to getting to that instruction.
The listing of the main program is available in
macro assembler,
pure assember, and
machine language formats.
(retLabel should have been LretLabel in the
call macro.)
To gain a clearer understanding of how this works, I recommend that you hand simulate the execution of the computer through a couple of iterations of the loop in the caller to see what instructions are being synthesized and used.
We will go over this in more detail during the next lecture.
The source code for the oic one-instruction computer simulator is available for those of you would like to run it on other machines. There shouldn't be any machine dependencies.
bsy+www@cs.ucsd.edu, last updated
