15-213: Introduction to Computer Systems

Written Assignment 6
This written homework covers code optimization, design & debugging, linking.

Directions
Complete the question(s) on the following pages with single paragraph answers. These questions
are not meant to be particularly long! Once you are done, submit this assignment on Canvas.

Below is an example question and answer.

Q: Please describe the benefit of 2s-complement signed integers versus other approaches (such
as 1s-complement or signed-magnitude).

A: For both 1s-complement and signed-magnitude representations of signed integers, we end up

representing both -0 and +0, which gets inconvenient when the computer wants to test for a
zero result. Additionally, in both of these representations, implementing addition/subtraction is
complicated. With 2s-complement, the hardware for addition / subtraction is the same for both
signed and unsigned inputs.

Grading
Each assignment will be graded in two parts:

1. Does this work indicate any effort? (e.g. it’s not copied from a homework for another
class or from the book)
2. Three peers will provide short, constructive feedback.

Due Date
This assignment is due on July 12th, 11:59 PM EST. Remember to convert this time to the
timezone you currently reside in.
Question 1
What are the two optimization blockers introduced in class, why is it difficult for the compiler to
optimize them, and what are the possible remedies?

blockers procedure calls and

aliasing
The two optimization are
memory .

Reasons and remedies showed

are as
follows .

Procedure calls :

analysis are within procedures

(
reason : most optimization es
some

within
files ) It is hard for the optimizer to decide whether
.
a

procedure has side effect returns

different result for or same

arguments Thus compilers have weak optimization for procedure

.

calls
g. cannot automatically
.
e. call outside
of loop move a a
.

remedies :

use inline
functions ( will be substituted at the
place I
mind the code
manually
's
implementation
Memory aliasing :

to the same
reason : there are
possibilities that two
pointers refer
memory other
location .
In this case .

updating one will affect values

which behavior Thus the
in the ,

changes the program .

,

compiler
intermediate
cannot
directly do
load 1 store .
optimizations such as
reducing
remedies :

restricted
keyword
in
arguments to
specify that the
'
use '

procedure aliases
's
arguments are not .

the code variables to hold the

manually
e. use
improve .

g.
intermediate result .
Question 2
Each of the following subproblems contains two modules. For each problem, identify the
multiply-defined symbols for both modules, explain how the linker would resolve the references
to these multiply-defined symbols. Use the 3 Linker’s Symbol Rules to justify your answer.

Module 1 Module 2

a int main() int main = 0;

{ int x;
} int y;

b int x = 1; void x;
int main; void main()
{
int x = 1;
}

c double y = 1.0; int x;

void main() int y;
{ int main;
int p = 0;
}

d int x; int y;
double y; double x;
double z = 1.0; int z;

e int main; double main;

int x; long y;
double p; void x()
long y() {
{ int p = 0;
double x = 0; }
}
Module 1

the
multiply defined symbols
are main ✗
y
: , .

main : not allowed because of multiple strong symbols 1

procedure ,
and
defined in a c.

references refer to strong symbol

✗ : will ✗ in b because it's a .

Other
symbols ( in d and the
global variable ✗ in e) are

weak
symbols .

y references
: will
refer to y in because it's strong symbol a a

initialized
I
global variables y d is weak symbol ,
in a .

Module 2

multiply defined symbols

the main
y
are :
✗ , .
,

main : not allowed because

of multiple strong symbols oproced are

and initialized variables )

global
✗
references will refer to the procedure in
: ✗ e because it's
the
only strong symbol
y reference will be
:

arbitrary of y in an one a. c. d. e. because

all
of them weak
references
are
.
Question 3
You have encountered a bug in your cache simulator, where the number of hits, misses,
evictions are all accurate, but dirty_bytes_in_cache and dirty_bytes_evicted are incorrect. You
are considering using the scientific debugging method to solve this problem by yourself. Based
on your knowledge of implementing the cache simulator, can you think of a possible hypothesis
as to the defect (specific to this problem) and predict the expected behavior of the program
under new conditions? In general, what are the steps you should take to proceed to figure out
the bug in accordance with scientific debugging?

Hypothesis es :

bits not set

dirty correctly
writes
are on
i.

subsequent operations overwriting dirty bytes

2. are

New conditions and

expected behaviors
could trace without writes
try the
program
1 we on a
running
.
.

and
if the dirty bytes in cache and dirty bytes evicted
see -
. -
-
-

trace with writes and set

being also 0 .
We can use a .

bits set
if dirty
to are
watch points see
correctly
2 .
we could use
grind
Val to check
for memory overflows C Which

may
cause
dirty bit over write ) . or set watch
point in
gdb
dirty bit overwritten
is
why
the
to check when and .

Generally ,
steps to
figure
out the
bug using scientific debugging
are as
follows :

Prediction
→ ↳
hypothesis experiment
I sobers ration d
& conclusion