1 / 46

Subprogram Control

Subprogram Control. Chapter 7. 7.1.Subprogram Sequence Control Simple subprogram call-return. Assumptions Subprograms cannot be recursive. Explicit call statements are required. Not in exception handlers . Subprograms must execute completely at each call .

iman
Download Presentation

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. Subprogram Control Chapter 7

  2. 7.1.Subprogram Sequence ControlSimple subprogram call-return Assumptions • Subprograms cannot be recursive. • Explicit call statements are required. • Not in exception handlers. • Subprograms must execute completely at each call . • Not like a coroutine which continues execution from the point of its last termination each time it is called.

  3. Immediate transfer of control at point of call. • Not like a scheduled subprogram call, execution of the subprogram may be deferred until some later time. • Single execution sequence. • Not like tasks which may execute concurrently so that several are in execution at once.

  4. Functions calls • subprograms that return values directly. • procedure or subroutine calls • operate only through side effects on shared data. Are identical in the sequence-control structures they require.

  5. Implementation • Subprogram definition, activation. • An activation • code segment: executable code, constants. • Activation record: local data, parameters, … • code segment is invariant, each activation uses it. • Activation record is created and destroyed, and constantly changing.

  6. We must talk of: • execution of S during activation R of the subprogram. • CIP: Current-Instruction Pointer. • some point in code segment • CEP: Current-Environment Pointer. • To the activation record being used, the referencing environment.

  7. How a program is executed? • An activation record for the main program (just one) • CEP points to it. • CIP points to the first instruction of it. • Interpreter goes to work … • when a call is reached … • return point (ip,ep) stored in the activation record of the called subprogram. (p.290, fig.7.1.)

  8. One important property of the copy-rule view of subprograms: at most one activation of any subprogram is in use at any point during program execution. • FORTRAN, COBOL. • static allocation, code segment extension . • CIP is enough. • P.292, fig. 7.2.

  9. Recursive Subprograms • The recursive call creates a second activation of the subprogram during the lifetime of the first activation. • CEP and CIP • Pascal and C : use stack always • PL/1: just for recursive subprograms.

  10. The dynamic chain of pointers. • Ep values : a linked list , links the activation records on the central stack in order of their dynamic creation. • CEP: the top A.R. • ep value of CEPs return point: the 2nd A.R. • … • last ep: the main program.

  11. 7.2. Attributes of Data Control • Accessibility of data at different points during program execution. • X:=Y+2*Z • Y may be a local or nonlocal variable • we must know scope rules for declarations: • if Y is a formal parameter, parameter transmission • if Y is a parameterless subprogram,mechanisms for returning results.

  12. Names and Referencing Environments • Two ways that a data object can be made available as an operand for an operation: • Direct transmission. • Is used for data control within expressions. • Data object is allocated storage temporarily during its lifetime, without any name. • Like 2*Z in X:=Y+2*Z. • Referencing through a named data object. • Most data controls outside of expressions . • A name ; or a name of a larger data object with a selection operation.

  13. Program elements that may be named • Variable names. * • Formal parameter names. * • Subprogram names. * • Names for defined types. • Names for defined constants. • Statement labels (names for statements). • Exception names. • Names for primitive operations, e.g., + , * ,SQRT. • Names for literal constants, e.g., 17, 3.25.

  14. Name: • simple name: designating an entire data structure. • composite name: a name for a component of a data structure. (a name and a selection) • a[3].class[2].room

  15. Associations and Referencing Environments • Association: binding of identifiers(simple names) to particular data objects and subprograms. During execution: • 1. at the beginning of execution of the main program, associations are made(variables and subprograms).

  16. 2. During execution of main program, it invokes referencing operations, to determine the particular data object or subprogram associated with an identifier. • A:=B+FN(C) • 3. when each subprogram is called, a new set of associations is created.

  17. 4. It invokes referencing operations too. • 5. When the subprogram return, its associations are destroyed. • 6. The main program continues ...

  18. Referencing Environments • For each program or subprogram: A set of identifier associations available for use in referencing during execution. • Invariant during one activation. • Set up when the subprogram activation is created.

  19. Referencing environment components • Local referencing environment. • Created on entry to a subprogram. • Nonlocal referencing environment. • Not Created on entry to a subprogram. • Global referencing environment. • A part of n.l.e., main program. • Predefined referencing environment. • Defined directly in the language definition.

  20. Visibility : an association for an identifier is said to be visible within a subprogram if it is part of the referencing environment for that subprogram. • Hidden if redefined. • dynamic scope: dynamic scope of an association consists of the set of subprogram activations within which it is visible.

  21. Referencing operation: an operation with the signature ref-op: id*referencing-environment -> data object or subprogram • Local, nonlocal, and global references. • If the association is local ...

  22. Aliases for data objects • More than one name for a data object • parameters • in several link lists • aliasing makes understanding a program difficult. • Optimization harder. P.300 fig. 7.4.

  23. Dynamic Scope • The Dynamic scope of an association for an identifier, is the set of subprogram activations in which the association is visible during execution. • A Dynamic scope rule defines the dynamic scope of each association in terms of the dynamic course of program execution. • For example you can define it according to the dynamic chain of subprogram activations.

  24. Static Scope • The static scope of a declaration is that part of the program text where a use of the identifier is a reference to that particular declaration of the id. • A static scope rule is a rule for determining the static scope of a declaration. • For example the rule used in Pascal.

  25. You can make no use of static scope rules. • LISP, SNOBOL4 • The importance of static scope. • Static type checking: faster and more reliable. • Reading a program easier. • Ada, C, FORTRAN, Pascal

  26. Block structure • In a block-structured language, each program or subprogram is organized as a set of nested blocks. • Introducing a new local referencing environment. P.304, fig. 7.5.

  27. Static scope rules p.304, 305 • 1. Head of each block. • 2. Immediately enclosed the first block. …up too the predefined language env., and then an error. • 3. Inner ones encapsulate dcl.s • 4. Named block can be referenced. Every reference to a name ,associated to a unique dcl.

  28. Local data and local referencing environment • Local environment consists of • ids in the head of Q (but not Q), • variable names, • formal parameter names, • subprogram names. • Retention and deletion • p.306,307…, fig. 7.6,7,8,9

  29. P.310 • some points about retention/deletion : • absence of recursion=> implementation is the same • having both • static and automatic in PL/1 • a subprogram name: retained • a formal parameter name: deleted • recursive subprogram calls=> deleted (often)

  30. Deletion, Retention • Retention • history sensitive • more storage space • Deletion • less storage space

  31. 7.3. Shared Data in Subprograms • Sharing of data objects : • direct sharing through parameter transmission • through nonlocal environments • explicit common environments and implicit nonlocal environments • dynamic scope • static scope • inheritance

  32. Parameter and Parameter Transmission • When we use parameters and when we use nonlocal reference? • Parameters for • data • subprograms • statement labels p.313, a table of different kinds of actual parameters

  33. Establishing the correspondence • positional (pairing) • by explicit name • in Ada: Sub(Y=>B, X=>27);

  34. Methods for Transmitting Parameters • Call by name • call by reference • call by value • call by value-result • call by constant value • call by result

  35. Call by name • the actual parameter is to be substituted everywhere for the formal parameter in the body of the called program before execution of the subprogram begins. • If we have call Sub(X) • Actual parameter X, as a simple parameterless subprogram. • Solve the ambiguity if X is already a variable known to Sub.

  36. Call by reference • A pointer to the location of the data object is made available to the subprogram. • The data object, doesn’t change position.

  37. Call by value • Upon invoking a subprogram, the value is passed (r-value ). • the formal parameter contains the value that is used. • No alias.

  38. Call by value-result • The formal par. Is a local var. of the same type as the actual par. • Like call by value, but the result is copied in the actual par. at the end.

  39. Call by constant value • No change in the value of the formal par. Is allowed during prog. Execution. • If transmitted to another subprogram it must be by constant value too. • Just an input.

  40. Call by result • The formal par. Is a local var. with no initial value. • The result is copied in the actual par. at the end.

  41. FORTRAN: only call by ref. • Pascal : both (var keyword) • C: only call by value. • By pointers… sub(&I) ... sub(int *x)

  42. Transmission Semantics • Rather than mode of transmission, role of the parameter. • in, out, in out • In Ada: • elementary data types • in: constant value • out, in out: value-result • composite data types : by reference

  43. Explicit function values • An extra implicit out parameter from the subprogram. • In C: return 2*x • In Pascal: fn:=2*x

  44. Implementation of parameter transmission • In activation record. • Each formal par. P is a local data object. • P • a local data object of type T (type of actual par.). • a pointer to a data object of type T .

  45. Various actions • at the point of call : actual par.s evaluated. • at the point of entry and exit: • prologue: complete the transmission. • epilogue: copy the result values (in transmissions by result or value-result). • Compiler: • transmission of par.s. • static type checking.

  46. Parameter-Transmission examples P.320

More Related