Run time vs compile time
Download
1 / 14

Run time vs. Compile time - PowerPoint PPT Presentation


  • 92 Views
  • Uploaded on

Run time vs. Compile time. The compiler must generate code to handle issues that arise at run time Representation of various data types Procedure linkage Storage organization. Data representation. Fundamental types are supported directly by machine operations Enumerated types? Booleans?

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Run time vs. Compile time' - briar


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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Run time vs compile time
Run time vs. Compile time

  • The compiler must generate code to handle issues that arise at run time

    • Representation of various data types

    • Procedure linkage

    • Storage organization


Data representation
Data representation

  • Fundamental types are supported directly by machine operations

  • Enumerated types?

  • Booleans?

  • Arrays?

  • Strings?

  • Records?

    • packed

    • unpacked


Control abstraction
Control abstraction

  • A procedure is a control abstraction

    • it associates a name with a chunk of code

    • that piece of code is regarded in terms of its purpose and not of its implementation.

  • Big issue #1: Allow separate compilation

    • Without it we can't build large systems

    • Saves compile time

    • Saves development time

    • We must establish conventions on memory layout, calling sequences, procedure entries and exits, interfaces, etc.


Control abstraction1
Control abstraction

  • Procedures must have a well defined call mechanism

  • In Algol-like languages:

    • a call creates an instance (activation) of the procedure

    • on exit, control returns to the call site, to the point right after the call.

  • Use a call graph to see set of potential calls


Control abstraction2
Control abstraction

  • Generated code must be able to

    • preserve current state

      • save variables that cannot be saved in registers

      • save specific register values

    • establish procedure environment on entry

      • map actual to formal parameters

      • create storage for locals

    • restore previous state on exit

  • This can be modeled with a stack

    • Allocate a memory block for each activation

    • Maintain a stack of such blocks

    • This mechanism can handle recursion


Name space
Name space

  • A procedure creates its own name space

    • It can declare local variables

    • Local declarations may hide non-local ones

    • Local names cannot be seen from outside.

  • The scope of a variable is the area in which it is active

  • Scope rules determine how declarations are mapped to names.


Storage allocation
Storage allocation

  • Static allocation

    • object is allocated address during compile time

    • location is retained during execution

  • Stack allocation

    • objects are allocated in LIFO order

  • Heap allocation

    • objects may be allocated and deallocated at any time.


Static allocation
Static allocation

  • Objects that are allocated statically include:

    • globals

    • explicitly declared static variables

    • instructions

    • string literals

    • compiler-generated tables used during run time.


Stack allocation
Stack allocation

  • Follows stack model for procedure activation

  • A procedure's memory block associated with an activation of the procedure is called an activation record or stack frame

  • The stack frame is pushed on the stack when the procedure is called and popped (and destroyed) when the procedure terminates

  • What can we determine at compile time?

    • We cannot determine the address of the stack frame

    • But we can determine the size of the stack frame and the offsets of various objects within a frame


Heap allocation
Heap allocation

  • Used for dynamically allocated/resized objects

  • Managed by special algorithms

  • General model

    • maintain list of free blocks

    • allocate block of appropriate size

    • handle fragmentation

    • handle garbage collection


Scope rules
Scope rules

  • Static scoping

    • determined at compile time

    • Algol languages: resolve conflicts by using "closest nested scope" rule

    • We must come up with a mechanism to access enclosing scopes (later)


Scope rules1
Scope rules

  • Dynamic scoping

    • depends on flow of control at run time

    • resolve conflicts using "most recently executed" rule

    • type checking deferred until run time

    • complicates program

    • any advantages?


Scope rules2
Scope rules

  • Dynamic scoping example

run 1 : a is positive

one() is called. The x in one() is bound to the

most recent declaration which is the global

one. The global x is given the value of 1 and

the program prints 1 in the end.

procedure main

x, a: int;

procedure one()

begin

x := 1;

end

procedure two()

begin

x:int;

one();

end

begin

x := 2;

read(a);

if a>0 then one() else two();

print(x);

end.

run 2 : a is negative

two() is called. It declares a local x. Then it

calls one(). The x in one() is bound to the

most recent declaration which is the local

declaration in two(). That local x is given the

value of 1. one() exits. two() exits and the

local x dies. The global x is still 2. The

program prints 2 in the end.


Scope rules3
Scope rules

  • Dynamic scoping -- why bother?

    • It allows us to customize procedures.

      • Consider a procedure print_integer that can print its argument in base 8, 10 or 16. Furthermore, we usually want to print it in base 10. We can use a global variable (such as x in the example) which is set to 10. Then, if we want a different base, we can declare a local x, set it to 8 or 16, and call print_integer. Once we exit the current scope, the local x dies and we are back to the default value.

    • Is there another way to do this?

      • Yes, we could have passed x as a parameter

      • Yes, we could have made x a statically allocated variable (e.g. global), initialized it to 10 and, if necessary, reset its value right before and after a call to print_integer

        • bad idea: we might forget to restore it after the call.