1 / 15

Chapter 9 Subprogram Control

Chapter 9 Subprogram Control. Consider program as a tree- Each parent calls (transfers control to) child Parent resumes when child completes Copy rule – consider child code as copied into parent Subprogram used to Separate program into logical units

orinda
Download Presentation

Chapter 9 Subprogram Control

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Chapter 9 Subprogram Control • Consider program as a tree- • Each parent calls (transfers control to) child • Parent resumes when child completes • Copy rule – consider child code as copied into parent • Subprogram used to • Separate program into logical units • Execute functions with different parameters

  2. Recursion • Must maintain storage for multiple copies of data • Code is reentrant – stored separately • Storage for return address and data • Indirect recursion • We do not know the number of times that our code or data will be copied • PL/1 – specific statement – is recursive • Non-recursive subprogram does not need stack implementation

  3. Execution structure • Child is explicitly called (exceptions are not) • Entrance at top or elsewhere • FORTRAN, coroutines (resume) • Scheduled subprogram call can delay transfer of control • Coroutines have multiple activation records active at one time but single thread of control – their execution can be traced • Tasks have multiple activation records active at one time and conceptually allow multiple threads of control

  4. Implementation of non-recursive routines • For execution efficiency • Code and data may be joined, with code directly referencing data address • Return address stored in no-op at top of subroutine code • Last statement of subroutine is branch to first address, indirectly • For reliability, may require that code be stored separately (non self modifying code) • Cost in storage of all (but smaller) activation records during program’s lifetime

  5. Implementation for recursive routines • Activation records (frames) on stack contain • Caller’s return address (next CIP) • Parameters • Local variables • Return value for functions and temps • Ptr to parent activation record (static chain ptr) • Ptr to caller’s activation record (dynamic chain ptr) • Register contains PC (Current Instruction Ptr) • Register contains base address of activation record (current environment pointer) • Register contains stack pointer

  6. Storage map in general • System and program code • Static variables • Activation records – grow dynamically --- available storage ---- • Heap storage • Note deallocation of stack storage when module completes

  7. Pascal forward declaration • Module can generally call each other (indirect recursion) if signature (prototype) is known to them • Pascal uses forward declaration • P. 356 – 10 out of 13 compilers handled a conforming program incorrectly

  8. Binding of name to data object • Reference environment for a module includes local, nonlocal and global declarations • Static or dynamic binding of name to data object • Scope of a declaration is the reference environment in which that declaration is valid • Scope is static if compiler can determine the declaration’s reference environment (containing module) • Static scope associated with block structured programming

  9. Aliases • Two names for the same data object in the (at least overlapping) same referencing environment • Ex: global variable passed as reference parameter with different name in subroutine

  10. Implementation • Static scope- compiler stores in code segment the address of the name’s data object, if known, else the offset from the appropriate module’s activation record plus the degree of nesting of that module to follow the static chain) • Activation record will store values of local data objects but also a static chain ptr • Dynamic scope – either search for the name through the dynamic chain (implies that names are stored on activation record) or update a central name table

  11. Retention and deletion of environments • Are modules history sensitive. Should they be? • Static variables are retained • Automatic variables are deleted • Heap data objects are retained until explicitly destroyed or garbage is collected, but external access paths may be lost from the stack • Parameters association should be deleted between calls • Initial assignment of values to static variables

  12. Parameter transmission • Association of actual and formal parameter • Positional correspondence • Named correspondence • Type checking • Methods for transmission • Does program specify implementation? • Call by reference (var; &I) • Call by value or copy (C default) • Call by value-result (copy in/copy out) • Call by name (text substitution) • Call by result (function return) • Does program specify semantics • Ada’s in/out compared with C’s const

  13. Example (p. 383) Q (int i, int *j) { i = i + 10; *j = *j + 10; printf (…) } P() {int a = 2; int b = 3; Q( a, &b); printf (…) try Q(&a, &a); also for value/result; Discuss Q( a+b, &b) if reference or value/result is used Call by name

  14. Example (p. 387) R( int *i, int *j) {*i = *i + 1; *j = *j + 1; } P() {int c[4] = {6,7,8, 0}; int m = 2; R (&m, & c[m]); Print all of c}

  15. Exception handling (from chapt 11) User defined Bad_Data_Value : exception; exception when Bad_Data_Value => … when others => … end; //block p.438 Exception propagation – dynamic chain

More Related