CS225, Fall 2006, Friday Oct 20, Day 24 Hit
reload!
(Re) Read 2.3, C++ functions, ReRead
6.3 to p. 261,
procedure with no parameters, Continue to p.267. Errata
p. 267 in pictures of stack for program on p. 266: (a): all
values are input to main by now, so the values should be the same as on
p. 264 (only "upside down": i=1, value=13, numPts=12. ) Note there were
already corrected errata 264 & 267, correcting n & value to 13,
and correcting retAddr(p.267) to 0046.
HW Day 24, Due Mon
Day 25
<>Please hand in the Listing from each
program. And draw those arrows from each Branch to its target!
A. Reconsider your program that got two numbers and found the
sum. Rewrite the procedure so that it has the two
numbers as pass-by-value parameters, adds them, and outputs the
sum. (void sum(num1, num2)) The main program
now gets the two numbers from input and calls the procedure, just
once. What is the total length of the stack
frame (call frame) of your procedure?
(Guess what will be next? Rewriting sum as a function: int
sum(num1, num2))
Textbook p. 320, #16 (void putNext(int age))
- - - - - - -
Program 7, Multiplication Assigned Friday Day 24, Due
Friday. Day 28, Oct. 27.
Program specification:
The program should get 2 numbers from Batch input and
multiply them, then output the result.
The algorithm should be the shift-and-add algorithm (multiplication).
Write the program to work for input numbers > 0 and <
25510. You do not need to check that the result
is out of range (though it could print out as a negative number.
Why?).
You may write it with or without a function/procedure. You may
use global variables (direct addressing) or local (stack-relative),
your choice.
Create a suitable set of test data pairs, and submit the results from
these as well as the listing.
= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
= = = = = = =
Notes: No, exams aren't finished.
(leftover) Buffer: A place which
holds data that is to pass
from one part of the computer to another.
("Waiting room")
FIFO storage. Solves problems of different rates of
input and uptake.
E.g. Keyboard buffer stores keystrokes as they come in; they are
fetched by the program asking for them (as
between keyboard and Pep Step Trace).
If the program is really
slow, you can outtype the buffer . Buffer
needed between internet connection and computer, computer and printer,
etc.
PEP "Terminal IO" buffer: Input Dog<Enter>
---> <LF> g o D ---> to program
Chari fetches one character. Each Chari gets the next character
from the buffer. The last character is always <LF>.
If the buffer is empty, Chari prompts with a _ to get more input.
So in a program that reads characters in a loop:
Your input, if you did character x
<Enter> loads the buffer with
---><LF> x--->, and you get x
on the first loop, and <LF> on the second loop.
Program 5; any surprises? Like, it's done??
How to multiply whole
numbers? (Algorithms ready? on board next time.)
HW C due today. Put code on board:
Write a procedure
that gets 2 numbers from (batch) input, adds them, and outputs
the sum. And a main program that just calls the
procedure, twice in a row (with a carriage return between the two
calls).
Exercise in addressing modes. Code.
Procedures, continuing:
Who does what? Calling
program
Procedure
(Compiler manages all this for us in C++. )
STACK FRAME:
Top: Local
variables (all done by procedure)
Return
address (CALL, in
calling program, puts it on stack, RETn, in procedure, pops.)
Base
(FBCF)
= = = = = = = = = =
Next: Pass-by-value parameters: copies of
values go
on the stack where? Below the return address. (other side
of
(handout) Pasteable Example
Warford's convention. Store the parameter values first,
move the stack pointer after. (So stores are at SP minus
something).
Calling
requires
-- Push actual parameter values (pass-by-value; copy the
values to new memory locations on the stack)
-- Push the return address (CALL)
-- Push storage for the local
variables ("allocate" them).
This chunk is the stack frame for the procedure. SP moves
to top of all this stuff.
Inside the procedure Actual parameters and local variables are
referenced by their offsets from SP. "Formal" parameter is the
same location as the pushed parameter value, referenced now as
offset from the top of the stack frame.
Returning requires
-- Pop ("deallocate") local variables
(just move SP. ADDSP, or part of RETn)
-- Pop return address into PC
(RET), or part of RETn)
-- Pop actual parameter values (just move
SP) They may have been changed inside the procedure but
are not used again.
STACK FRAME:
Top: Local
variables (all done by procedure)
Return
address (CALL, in
calling program, puts it on stack, RETn, in procedure, pops.)
Parameters
(pass-by-value)
Base
(FBCF)
All of stack frame is addressible
in the procedure by offsets from the Top.
Make a Symbol for each Parameter's offset,
remembering it's on the other side of the Return address.
Another example: void PrintBar( int
n) by value, local int j. No return value.
(Procedure prints a row of n
stars, counted loop on j) Fig 2.15, p. 47, Fig. 6.23 p.
265-6
Leaks?
A Procedure is supposed to encapsulate its work; not affect
anything outside. Nothing outside should affect inside of
procedure except passed parameters and global variables, useable
by anything.
What "leakiness" has Warford left in with his protocol?*
At board: Start program #16, p. 320
= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
=
What "leakiness" has Warford left in with his protocol?*
* --Flags are not necessarily left the same. RETn doesn't
alter flags, but we don't have a way of clearing or setting flags
directly.
* --A and X registers are (probably) changed. Design
choice: You can push
A, X register values onto stack for safekeeping, restore them
afterward.
We have so
few, safer to assume Register is not what it was. (Especially
since we are using A
for all our pushes).
(Registers can also be used explicitly to pass
parameters, especially if you have lots of registers and a way to keep
track. Not suitable for this ISA.)
This page belongs to Sally Sievers who is solely
responsible
for its content. Please see our statement
of responsibility.