The Procedure Abstraction

1. The Procedure Abstraction

2. Procedure Abstraction • Part of compile time vs. run time • a.k.a. static versus dynamic • Most issues arise with “procedures” • Issues: • Compile-time versus run-time behavior • Finding storage for everything • Mapping names to addresses • Generating code to compute addresses • Interfaces with other programs and the OS • Efficiency of implementation

3. Procedure Abstractions • Control Abstraction: • Well defined entries & exits • Mechanism to return control to caller • Parameter passing • Clean Name Space • Writing to locally visible names • Local names mask identical non-locals • Local names cannot be seen outside • External Interface • Access by procedure name & parameters • Protection for both caller & callee

4. The Procedure ... Procedures are key to building large systems • Require system-wide agreement on: • memory layout & protection, • resource allocation • code for calling sequences • target architecture and O/S • Establish a private context • private storage for each invocation • Encapsulate control flow, data abstractions

5. The Procedure ... Procedures allow separate compilation: • Separate compilation allows us to build non-trivial programs • Keeps compile times reasonable • Lets multiple programmers collaborate A procedure linkage convention: • Each proc. has a valid run-timeenvironment • A caller’s environment is restored on return • Compiler must generate code to ensure this

6. Procedure Abstraction A procedure is an abstract software structure • Underlying hardware understands: • bits, bytes • integers, reals, addresses • Underlying hardware does not understand: • Entries and exits • Interfaces • Call and return mechanisms • might be able to save context at call • Name space

7. Procedure Abstraction Procedures have well-defined control flow

8. Procedure Abstraction Procedures have well-defined control flow int p(a,b,c) int a, b, c; { int d; d = q(c,b); ... } … s = p(10,t,u); …

9. Procedure Abstraction Procedures have well-defined control flow int p(a,b,c) int a, b, c; { int d; d = q(c,b); ... } int q(x,y) int x,y; { return x + y; } … s = p(10,t,u); …

10. Procedure Abstraction Procedures have well-defined control flow int p(a,b,c) int a, b, c; { int d; d = q(c,b); ... } int q(x,y) int x,y; { return x + y; } … s = p(10,t,u); …

11. Procedure Abstraction Procedures have well-defined control-flow int p(a,b,c) int a, b, c; { int d; d = q(c,b); ... } int q(x,y) int x,y; { return x + y; } … s = p(10,t,u); …

12. Procedure Abstraction Procedures have well-defined control-flow • Most languages allow recursion !!! int p(a,b,c) int a, b, c; { int d; d = q(c,b); ... } int q(x,y) int x,y; { return x + y; } … s = p(10,t,u); …

13. Procedure Abstraction • Needs code to: • save & restore return address • map actual to formal parameters • create storage for locals (and parameters) Compiler includes code to do this at run time int p(a,b,c) int a, b, c; { int d; d = q(c,b); ... } int q(x,y) int x,y; { return x + y; } … s = p(10,t,u); …

14. Procedure Abstraction • Must preserve p’s state while q executes • recursion causes the real problem here • keep a stack of activations Compiler includes code to do this at run time Compiler emits code that causes all this to happen at run time int p(a,b,c) int a, b, c; { int d; d = q(c,b); ... } int q(x,y) int x,y; { return x + y; } … s = p(10,t,u); …

15. Procedure Abstraction Each procedure call creates its own activation • Any name can be declared locally • Local names mask identical non-local names • Local names can’t be seen outside procedure • Nested procedures are “inside” • Such rules are called “lexical scoping”

16. Procedure Abstraction Why introduce lexical scoping? • Gives compile-time mechanism for binding “free” variables • Gives rules for naming & resolves conflicts How can the compiler track of all these names? • At point p, which declaration of x is current? • At run-time, where is x found? • At change of scopes, how is x deleted ? • Symbol Tables !!!

17. Variable Locations Locals/Parameters (i.e. “automatics”) Kept in activation record or in a register • Kept in activation record or in a register • Thus, lifetime matches procedure’s lifetime Global • One or more named global data areas • One per variable Static • keep as global, but add identifying prefix • ex. proc.mystaticvar or file.mystaticproc

18. Placement Classic Organization • Better utilization if stack & heap grow toward each other • Very old result (Knuth) • Code & data separate or interleaved • Uses address space, not allocated memory S t a c k S G t l a & o t b i a c l H e a p C o d e high 0 Single Logical Address Space • Code, static, & global data have known size • Use symbolic labels in the code • Heap & stack both grow & shrink over time • This is a virtualaddress space - interface with O/S to grow it

19. The “Big Picture” The Big Picture virtual address spaces Compiler’s view S t a c k S G t l a & o t b i a c l S G t l a & o t b i a c l S G t l a & o t b i a c l H e a p S G t l a & o t b i a c l S t a c k S t a c k S t a c k C o d e H e a p C o d e H e a p C o d e C o d e H e a p ... OS’s view ... 0 high Physical address space_ Hardware’s view

20. Activation Records Need a data area per invocation • We call such an activation record (AR) • Compiler can also store control data here • One AR per procedure instance • AR can be derived from the symbol table

21. Translating Local Names How does a compiler find an instance of x ? • Name is translated into a static coordinate • < level,offset > pair • “offset”isuniquewithin that scope • “level”is nesting level of the procedure • emitted code will use static coordinate: • to generate addresses • to generate references

22. Variable-Length Data Arrays • If size is fixed at compile time, store in fixed-length data area • If size is variable, store descriptor in fixed length area, with pointer to variable length area • Variable-length data area is assigned at the end of the fixed length area for block in which it is allocated B0: { int a, b … assign value to a B1: { intv(a),b,x B2: { intx,y(8) …. } a b v b x x y(8) v(a) Variable-length data Includes variable length data for all blocks in the procedure …

23. AR Basics Space for parameters to the current routine parameters Saved register contents register save area If function, space for return value return value Address to resume caller return address addressability Help with non-local access ARP caller’s ARP To restore caller’s AR on a return local variables Space for local values & variables One AR for each invocation of a procedure

24. AR Details How does the compiler find the variables? • At known offsets from AR pointer (ARP) • The static coordinate leads to a “loadAI” • Level specifies ARP, offset is the constant Variable-length data • put below local variables • Leave a pointer to it at an offset from ARP • Otherwise, put on the heap

25. Parameter Passing Call-by-reference: • passes a pointer to actual parameter • Requires slot in the AR (for address of parameter) • Multiple names with the same address? Call-by-value: • passes a copy of its value at time of call • Arrays passed by reference, not value • Each name gets a unique location • Requires slot in the AR

26. Procedure Linkages How do procedure calls actually work? • At compile time, callee may not be available • Calls may be in other compilation units • May not know system call from user call • All calls must use the same protocol Must use a standard sequence of operations • Divides responsibility between caller & callee • Enforces control & data abstractions ... Usually a system-wide agreement

27. Procedure Linkages Standard procedure linkage Procedure has • standard prolog • standard epilog Each call involves a • pre-call sequence • post-return sequence Exact code depends on the number & type of the actual parameters procedure p prolog procedure q prolog pre-call post-return epilog epilog

28. Procedure Linkages Pre-call Sequence • Sets up callee’s basic AR • Helps preserve its own environment The Details • Allocate space for the callee’s AR • not space for local variables (yet) • store each parameter’s value (or address) • Save return address, caller’s ARPin callee’s AR • Save any caller-save registers into caller’s AR • Jump to address of callee’s prolog code

29. Procedure Linkages Post-return Sequence • Finish restoring caller’s environment • Place any value back where it belongs The Details • Copy return value from callee’s AR • Free the callee’s AR • Restore any caller-save registers • Restore by-reference parameters to registers • Copy back call-by-value/result parameters • Continue execution after the call

30. Procedure Linkages Prolog Code • Finish setting up the callee’s environment • Preserve parts of the caller’s environment that will be disturbed The Details • Preserve any callee-save registers • Allocate space for local data • Easiest scenario is to extend the AR • Find any static data areas referenced in the callee • Handle any local variable initializations

31. Procedure Linkages Epilog Code • Wind up the business of the callee • Start restoring the caller’s environment The Details • return value is set by the “return” IR code • Restore callee-save registers • Free space for local data • Load return address from AR • Restore caller’s ARP • Jump to the return address