Stack Frames. Remind Ourselves why stack-frames are required. Appreciate their role in register-based processors

Transcription

1 Objectives:- Remind Ourselves why stack-frames are required Appreciate their role in register-based processors See how this adapts to a stack-based system (like the J5) Understand how machine can support this requirement Look at how poor design can make life difficult Slide 1

2 Stack-Frames why do we need them? Variables - Variables can be created and deleted dynamically - We have to keep variables in memory - How do we manage their storage effectively? Arrays - arrays are variables too - But they can contain many separate data items s or 100,000 s - Again the question is how do we manage their storage in memory? Program Structure - Procedures and Nested calls - Recursion procedures which call themselves - Multiple instances multiple calls to a procedure can co-exist - Interrupts Slide 2

3 Stack-Frames How do they help? Variables - Variables can be added to, or removed from a stack - The stack resides in memory, but it can be located anywhere Arrays - The stack can hold a few, or many thousands of bytes just as easily Program Structure - The Stack-Frame can preserve the context of each procedure - Recursive calls to procedures cause the preservation of the previous state - Multiple instances same argument each call has its own state on stack So we think stack-frames are a good idea, but how do they work? Slide 3

4 A simple stack-frame Assume for the moment that we have a new, third allocation stack in out J5 design When a procedure is called, typically, the first thing that happens is that variables are declared, and created on the stack. Suppose a routine fred has three variables, A, B, and X, where X is an array of 4 bytes. When we call the procedure fred, the thirds stack is used to hold the variables as a temporary store:- A B X[0] X[1] X[2] X[3] New Stack Frame for Fred Before Call to FRED During Call to FRED Slide 4

5 A simple stack-frame Handling Recursion - Suppose FRED is written such that FRED can call itself Not as silly as it sounds if its done properly! Each New Call will create a new stack-frame on the allocation stack, so that we might observe the following:- Before Call Slide 5 1 st Call 1 st recursion 2 nd recursion

6 A simple stack-frame Handling Procedure Nesting Procedure Nesting is similar to recursion, except each procedure calls a different lower-level procedure as it progresses down the hierarchy. Suppose we have the following simple nested program structure. MAIN INPUT PROCESS MULTIPLY And suppose that each procedure has the following variables:- MAIN X,Y,Z INPUT A[3] PROCESS I,J MULTIPLY N,M,T Slide 6

7 Example of Procedure Nesting X Y Z A[0] A[1] A[2] X Y Z X Y Z 1. Before MAIN 2. Call to MAIN 3. Call INPUT 4. Return From INPUT I j X Y Z N M T I j X Y Z I j X Y Z X Y Z 5. Call to PROCESS 6. Call to MULTIPLY 7. Return From MULTIPLY 8. Return From PROCESS Slide 7

8 How Do we access variables? Out Stack architecture has to place data on the data stack to do computations The Variables are in the memory How do we load variables onto the stack? - USE INDIRECT ADDRESSING If we know the top-of-frame address, then we can work out the address of a variable in memory. For example, if Top-Of-Frame was 1000h at point 8 on the previous slide, then Variable X is at address 1000h (frame + 00h) Variable Y is at address 1001h (frame + 01h) Variable Z is at address 1002h (frame + 02h) Slide 8

9 How Do we program the access to variables? Writing J5 code to do this is easy if we know the top-of-frame address LSET 1000h - the top-of-frame address SSET 02h - we want variable 2, i.e. (X is 0, Y is 1, Z is 2) ADD - Calculate the full address - load from that address But in reality, the top-of-frame could be anywhere, and worse it keeps changing for each new procedure call. What can we do? - to manage a frame stack in memory, our J5 architecture needs a pointer - Suppose we call this TOF - Then we should be able to push TOF onto the stack e.g. PUSH TOF Slide 9

10 So we could just write PUSH TOF SSET 02h ADD Or we could have an indirect load instruction: (TOF)+02h But this deviates away from our stack-based model, it is starting to look very much like a register-based machine, such as the The has an instruction:- MOVE (A7)+02h,D2 move the content pointed to by register A7, plus 2, into register D2 We know the implications of adding complexity, so we will not go down that route. Slide 10

11 The HLL VIEWPOINT In high-level languages, there is more to the issue of variables than we have discussed so far. Consider the following:- Local Variables - Locals are created at the start of a procedure, and destroyed before return - Locals can only be accessed by the procedure that creates them Global variables - Global variables are usually created before starting the main procedure - Globals are accessible by any procedure at any time. So we have a requirement to access two parts of the frame-stack, one part for globals, and one part four our current procedure. Slide 11

12 The HLL VIEWPOINT the two-level stack Local Base Register LBR NOT USED Local Variables Currently in use GBR Global Base Register Global variables Access to globals or locals is simply achieved by pushing GBR or LBR onto the stack and calculating the required offset address. Access a Global Push GBR Sset 06h ADD Access a Local Push LBR Sset 03h ADD Slide 12

13 A note on more advanced stack frames You may notice that when a new frame is pushed on the stack we preserve its previous state, which could is typically the stack-frame from a higher routine which calls our routine. In some circumstances it is desirable to have access to the calling frame, this can be supported. Consider the following example :- NOTE- in the J5 we can access the preceding frame(s) thus:- Old value of LBR GET-KEY Old LBR INPUT OLD LBR MAIN OLD LBR Note :- We could work our way down the hierarchy multiple levels if required. PUSH LBR Will get us the previous LBR value from memory onto stack. While PUSH LBR Takes us down three levels, and so-on. However we need to ensure that local 0 contains the old LBR for each new call Slide 13

14 KEEPING TRACK OF STACKS In our J5 machine we now have three stacks :- Data Stack (top three or four registers on chip) Program Stack (top few registers on chip) Frame Stack (entirely in main memory) The frame stack is addressed via LBR and GBR, but the Data and Program stacks also extend into main memory, so how do we know 'where' these stacks are in that memory?. The answer is to have Stack Pointer Registers:- DSP Data Stack Pointer RSP Return Stack Pointer LBR & GBR Frame stack pointers DSP & RSP are automatically managed (just like PC). We normally do not have to do anything to these registers, except perhaps initialise them to valid locations on reset/power-up. Slide 14

15 Conclusions Stack-Frames are a fundamental part of HLL s Support for Local and Global Variables is required We need to take into account nesting and recursion The J5 can do most of what is required with just two registers Slide 15