Answer not available!
No additional registers visible to the programmer are needed. All intermediate results, including those needed for up-level addressing, can be computed on the stack top.
Part B: What minimum set of addressing modes must be available on the load and store instructions if they are to be useful. Justify each such addressing mode.
We need the following tools, at minimum:
- Push the address of a variable on the stack.
- Perform arithmetic on an address on the stack top in order to select array and record elements.
- Push or pop data using an address popped from the stack. Push therefore leaves the stack pointer unchanged (it replaces the address with the contents of that address) while pop removes two items from the stack, the data stored and the address where it is stored).
The first of these, pushing the address of a variable, may involve one of the following:
- Push the value of the stack pointer itself onto the stack. Adding an appropriate constant to this allows us to compute the address of any local variable. Additional stack-pointer relative modes would, of course, allow for more efficient code.
- Push a constant onto the stack. This allows us to address any static (or global) variable. Additional direct addressing modes would, of course, allow for more efficient code.
All other addressing modes can be built from these!
Part C: Are any special registers or addressing modes required in order for this machine to support a heap for dynamic storage allocation? Explain.
No. The primitive modes outlined above are so primitive that they trivially allow variables to hold pointers to arbitrary memory locations.
Part D: Are any special registers or addressing modes required if we extend our interest from the realm of block structured languages to object oriented languages such as C++ and Java? Explain.
Yes. The modes discussed above focus only on access to variables. Nothing was said about access to code, and most naive computer architects seem to assume that all program addresses can be hard-coded into the jump and call instructions, with only the return instruction taking an address from the stack. Object oriented languages require that there be indirect call instruction in order to implement polymorphic classes. At minimum, this instruction should pop the destination address from the stack top before pushing the return address and transferring control.
First, we could use a preemptive scheduler to transfer control between the threads. Second, we could use a cooperative model, where the threads themselves are responsible for arranging the transfer of control between threads. (Classical MacOS and Windows were cooperative, while the newer versions of these are preemptive! Outside the PC world, preemptive implementations dominate classical operating systems, but the implementation of threads in languages like Java and Ada is frequently purely cooperative, with the operating system seeing the entire multithreaded application as just one thread.)