29.01.2015 Views

Embedded Software for SoC - Grupo de Mecatrônica EESC/USP

Embedded Software for SoC - Grupo de Mecatrônica EESC/USP

Embedded Software for SoC - Grupo de Mecatrônica EESC/USP

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

Energy-Aware Parameter Passing 503<br />

3.2. Global variables<br />

In this subsection, we show that global variables present a difficulty <strong>for</strong> on<strong>de</strong>mand<br />

parameter-passing. Consi<strong>de</strong>r the following subroutine fragment,<br />

assuming that it is called using foo(c[in<strong>de</strong>x]), where c is an array and in<strong>de</strong>x<br />

is a global variable:<br />

foo(int x) {<br />

int y;<br />

}<br />

if (…){<br />

in<strong>de</strong>x++;<br />

y=x+1;<br />

} else {<br />

}<br />

It can be seen from this co<strong>de</strong> fragment that a normal parameter-passing<br />

mechanism (CBR or CBV) and our on-<strong>de</strong>mand parameter-passing strategy<br />

might generate different results <strong>de</strong>pending on which value of the global variable<br />

in<strong>de</strong>x is used. In on-<strong>de</strong>mand parameter evaluation, the actual parameter<br />

is computed just be<strong>for</strong>e the variable x is accessed in statement y = x + 1. Since<br />

computing the value of c[in<strong>de</strong>x] involves in<strong>de</strong>x which is modified within the<br />

subroutine (using statement in<strong>de</strong>x++) be<strong>for</strong>e the parameter computation is<br />

done, the value of in<strong>de</strong>x used in on-<strong>de</strong>mand parameter-passing will be different<br />

from that used in CBR or CBV. This problem is called the global<br />

variable problem and can be addressed at least in three different ways:<br />

The value of in<strong>de</strong>x can be saved be<strong>for</strong>e the subroutine starts itsexecution.<br />

Then, in evaluating the actual parameter (just be<strong>for</strong>e y = x + 1), this saved<br />

value (instead of the current value of in<strong>de</strong>x) is used. In fact, this is the<br />

strategy adopted by some functional languages that use lazy evaluation [5].<br />

These languages record the entire execution environment of the actual<br />

parameter in a data structure (called closure) and pass this data structure<br />

to the subroutine. When the subroutine needs to access the <strong>for</strong>mal parameter,<br />

the corresponding actual parameter is computed using this closure.<br />

While this strategy might be acceptable from the per<strong>for</strong>mance perspective,<br />

it is not very useful from the energy viewpoint. This is because<br />

copying the execution environment in a data structure itself is a very<br />

energy-costly process (in some cases, it might even be costlier than computing<br />

the value of the actual parameter itself).<br />

During compilation, the compiler can analyze the co<strong>de</strong> and <strong>de</strong>tect whether

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!