chapter8.ppt clean code Boundary ppt Coding guide

Copyright © 2009 Elsevier
Chapter 8 :: Subroutines and
Control Abstraction
Programming Language Pragmatics
Michael L. Scott

Review Of Stack Layout
• Stack recap: Each routine, as called, gets a new
frame put on the top of the stack
– Contains arguments, return values, book-keeping info, local
variables, and temporaries
• Stack pointer: the address of either:
– last used location at the top of the stack
– First unused location
• Frame pointer: address within the frame
– Objects in the frame are accessed via offset from the
frame pointer
– Variable size things are towards top of the frame, since
can’t be preset, with dope in fixed size part

• If no variable-size objects, then everything has
fixed offset from stack pointer
– In this case, frame pointer isn’t needed at all
– Frees up a register for use
• Static and dynamic links maintained on stack:
– Static store context for scope purposes
– Dynamic store saved value of the frame pointer, so that
it returns to correct calling method

Calling Sequences

Calling Sequences
• The calling sequence (discussed in Ch. 3) is the
code a caller executes to set up a new subroutine
• Responsibilities:
– On the way in: Pass parameters, save return address,
change program counter, change stack pointer, save
registers that might be overwritten, changing frame
pointer to new frame, and initializing code for new
objects in the new frame
– On the way out: passing return parameters/values,
executing finalization code for local objects,
deallocating the stack frame, restoring registers, and
restoring the PC

Calling Sequences
• Note: some of these things must be done by
caller! They differ from call to call.
• Others, however, can be done by either caller or
by prolog/epilog of callee.
• In general, space is saved if work is mostly done
by callee:
– Anything done in callee appears only once in the target
program
– Anything done by caller has to appear before and after
every call in the final compiled code

Calling Sequences
• Perhaps trickiest bit is who saves registers.
– Ideally, save only those that are in use in the caller and
which would be overwritten in callee.
– This is almost impossible to do perfectly.
• Simplest solution is either to save all registers in
use (from caller) or save all registers that will be
overwritten (from callee).
– However, this is usually a bit unnecessary – want to
avoid extra overhead in general.

Calling Sequences
• A balance exists on many processors (MIPS and
x86, among others):
– Two sets: caller responsibility and callee responsibility.
– Callee can assume that there is nothing of value in any
of the caller saved register set.
– Caller can assume no callee will destroy contents in any
of the callee-saves set.
– Compiler will then use callee-saves registers for local
variables and other long-lived ones if possible, and
caller-saves set for transient values, which won’t be
needed across calls.

Calling Sequences: RISC architecture
• It is worth noting something about RISC
architecture:
– Heavily optimized to support simple instructions, so
that every operation takes one clock cycle
– Advantage is that pipelining is much easier in this setup
– Each command also requires less transistors of
hardware space
• In contrast, CISC architecture:
– Supports more complex operations: mult as well as add
– Advantage is that code size is much smaller, so less
RAM needed
– In addition, less complexity in compiler

Calling Sequences (C on MIPS)
• Why RISC Matters to us:
– In general, RISC architecture forces more work to save
registers
• As an example, for C on MIPS, caller needs to:
– saves into the temporaries and locals area any caller-saves
registers whose values will be needed after the call
– puts up to 4 small arguments into registers $4-$7 (a0-a3)
• it depends on the types of the parameters and the order in which
they appear in the argument list
– puts the rest of the arguments into the arg build area at the
top of the stack frame
– does jal, which puts return address into register ra and
branches
• note that jal, like all branches, has a delay slot

• In prolog, Callee
– subtracts framesize from sp
– saves callee-saves registers used anywhere inside callee
– copies sp to fp
• In epilog, Callee
– puts return value into registers (mem if large)
– copies fp into sp (see below for rationale)
– restores saved registers using sp as base
– adds to sp to deallocate frame
– does jra

• After call, Caller
– moves return value from register to wherever
it's needed (if appropriate)
– restores caller-saves registers lazily over time,
as their values are needed
• All arguments have space in the stack,
whether passed in registers or not
• The subroutine just begins with some of the
arguments already cached in registers, and
'stale' values in memory

• This is a normal state of affairs (especially
in RISC); optimizing compilers keep things
in registers whenever possible, flushing to
memory only when they run out of
registers, or when code may attempt to
access the data through a pointer or from an
inner scope

• Many parts of the calling sequence,
prologue, and/or epilogue can be omitted in
common cases
– particularly LEAF routines (those that don't
call other routines)
• leaving things out saves time
• simple leaf routines don't use the stack - don't even
use memory – and are exceptionally fast

Inline expansion
• In some languages, programmers can actually flag routines
that should be expanded inline –stack overhead is avoided.
• Example (in C++ or C99):
inline int max(int a,int b)
{ return a > b ? a : b}
• Ada does something similar, but keyword is:
pragma inline(max);
• Note that both of these are just suggestions to the compiler
– can’t be enforced, and may be done to other (not
suggested) functions as well.
• Note also that this can’t always be done – recursion is an
obvious case with issues.

Parameter Passing
• Parameter passing mechanisms have three
basic implementations
– value
– reference (aliasing)
– closure/name
• Many languages (e.g., Pascal, Ada,
Modula) provide different modes
• Others have a single set of rules (e.g. C,
Fortran, ML, Lisp)

Parameter Passing
• C/C++: functions
– parameters passed by value (C)
– parameters passed by reference can be
simulated with pointers (C)
void proc(int* x,int y){*x = *x+y }
…
proc(&a,b);
– or directly passed by reference (C++)
void proc(int& x, int y) {x = x + y
}
proc(a,b);

Parameter Passing
• Passing by reference really gives two advantages:
– Allows callee to change something and have it persist
– Saves space/time copying
• Unfortunately, the second isn’t really good in many
cases – leads to buggy code, where changes are made
that should not be allowed
– Hence, use of read only parameters: READONLY in
Modula
– In C/C++, use const the same way
• Does lead to some confusion with novices:
– Pragmatic issue: Does the implementation pass by value or
reference?
– Semantic issues: Is the callee allowed to change the
variable, and do these changes persist?

Parameter Passing
• In a language with a reference model of variables
(Lisp, Clu), pass by reference (sharing) is the
obvious approach
– You also saw this in Python – hence tons of discussion on
if a list makes a deep or shallow copy
• Some languages mix this up: Java, for example, does
call-by-value for built-in types, but call-by-reference
for user defined classes (all of which are references
anyway)
• C# also various – main different from Java is that
users can also make their own structs, which are
essentially “built-in” types

Parameter Passing
• Ada goes for semantics: who can do what
– In: callee reads only
– Out: callee writes and can then read (formal not
initialized); actual values is modified
– In out: callee reads and writes; actual modified
• Ada in/out is always implemented as
– value/result for scalars, and either
– value/result or reference for structured objects

Parameter Passing
• The last option is closures: a reference to a subroutine,
together with its referencing environment
• Goal: whenever that function is called, want access to
its referencing environment
– So even if called in a very different context, still get the
information you need to run it correctly
• Example: a function that takes a function as input and
then applies it to list might look like:
– Declare the function apply_to_A(f, A)
– Then write a function later
– Then call the function on some list

Parameter Passing
Figure 8.3 Parameter passing modes.

Parameter Passing
• A few final issues are addressed in the book, and must
be considered when using/designing a language:
– Variable number of arguments – some allow, some don’t, and
there is complexity in how to support it
• C example: int printf(char *format, …) {
• You then have to get at these and parse them somehow
• Java and C# also do this, but enforce more type safety
– Function returns
• Value of a function can be the value of its return or the value of its
body (in more functional languages where expressions and statements
are the same)
• Care is needed when scope is an issue – don’t return locals
• Return usually ends function, which is no always desirable

Generic Subroutines and Modules
• Generic modules or classes are particularly
valuable for creating containers: data abstractions
that hold a collection of objects
– Example: OS needs queues that can hold processes,
memory descriptors, file buffers, etc.
– Often incorporates generics (you’d call them templates)
or polymorphism

• Generic subroutines (methods) are needed in
generic modules (classes), and may also be useful
in their own right
– For example, a min function that works on anything
• These vary even more across languages – the
book gives a nice overview

• Implementation various:
– C++ and Ada make them static, so takes place at
compile time, and makes separate copies for all
possibilities
– Java 5, in contrast, guarantees that all instances will
share the same code at run time – objects of class T are
treated as instances of the standard base Object that
Java supports

Exception Handling
• What is an exception?
– a hardware-detected run-time error or
unusual condition detected by software
• Examples
– arithmetic overflow
– end-of-file on input
– wrong type for input data
– user-defined conditions, not necessarily
errors

Exception Handling
• Generally, we need the language to “unwind the
stack” when exceptions happen
• Basically, 3 options:
– Invent a value that can be used by caller when the real
one can’t be returned.
• NO! Not good in general
– Return an explicit status value to caller, which must be
inspected after every call.
• Clunky and annoying. Also a source of common bugs, since
many programmers forget or choose not to do this.
– Relay on the caller to pass a closure for error handling.
• Also clutters, and only works in more functional languages.

Exception Handling
• What is an exception handler?
– code executed when exception occurs
– may need a different handler for each type of
exception
• Why design in exception handling facilities?
– allow user to explicitly handle errors in a uniform
manner
– allow user to handle errors without having to
check these conditions
– explicitly in the program everywhere they might
occur

Exception Handling
• Examples:
– Try in C++
• If the exception is not handled in the calling routine,
it is handed back up the dynamic chain.
– If not handled in the main routine, then a predefined
outermost handler usually just kills the program.
• Usually 3 goals:
– Compensate if possible in order to continue execution.
– Declare a local handler to clean up local resources and then
reraise execution in order to pass along up the chain, where
hopefully recovery can happen.
– Print some sort of error if recovery is not possible.

Exception Handling
• Defining is a mix:
– In C++ or Lisp, all are programmer defined
– In PHP, set_error_handler can be used to turn
semantic errors into ordinary exceptions
– In Ada, exception is a built-in type, and so you can easily
make your own:
• declare empty_queue : exception;
– In Modula-3, exceptions are just another object, like constants or
variables
• Most languages allow a throw or raise in an if to
raise an exception

Coroutines
• Coroutines are execution contexts that exist
concurrently, but that execute one at a time,
and that transfer control to each other
explicitly, by name
• Coroutines can be used to implement
– iterators (Section 6.5.3)
– threads (to be discussed in Chapter 12)
• Because they are concurrent (i.e.,
simultaneously started but not completed),
coroutines cannot share a single stack

Coroutines
Figure 8.6 A cactus stack. Each branch to the side represents the creation of a coroutine ( A, B, C, and D). The static nesting
of blocks is shown at right. Static links are shown with arrows. Dynamic links are indicated simply by vertical arrangement: each
routine has called the one above it. (Coroutine B, for example, was created by the main program, M. B in turn called subroutine
S and created coroutine D.)

chapter8.ppt clean code Boundary ppt Coding guide

Recommended

More Related Content

Similar to chapter8.ppt clean code Boundary ppt Coding guide (20)

Recently uploaded (20)

chapter8.ppt clean code Boundary ppt Coding guide