To: spin-comp@thistle.cs.washington.edu
Date: Thu, 30 May 1996 09:56:51 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

test

To: eggers@yakima (Susan Eggers)
cc: spin-comp@tweetie-bird.cs.washington.edu
Subject: Re: automating 
Date: Thu, 30 May 1996 10:00:36 PDT
From: Wilson Hsieh <whsieh@tweetie-bird.cs.washington.edu>


I may be somewhat conservative here, but I think this is
the "natural" progression of research.  The technical issues
with automation are often the hardest, and require that the
pre-automation technical details be worked out first.
 - Wilson

From: ausland@tiffany (Joel Auslander)
To: spin-comp@cs
Subject: quals presentation
Date: Mon, 03 Jun 96 11:50:03 -0800


My quals presentation will be on Wednesday, June 5 at 4pm, in 422
Sieg. The title is "Binding Time Analysis for Dynamic
Compilation". Everyone's welcome.

	-Joel


Date: Mon, 1 Jul 1996 15:16:41 -0700
From: chambers@klamath (Craig Chambers)
To: spin-comp@thistle.cs.washington.edu, grant@cs.washington.edu
Subject: Re: algorithm for eager stitching

Since Susan's not in today, let's cancel today's meeting, with the expectation
of a make-up meeting in the next day or so.

-- Craig

To: spin-comp@thistle.cs.washington.edu
Subject: new eager stitching writeup
Date: Tue, 02 Jul 1996 16:22:03 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

I updated my writeup slightly, fixing a few minor errors.  I merely replaced
the one in the discussion archive:

http://www.cs.washington.edu/research/projects/unisw/DynComp/www/Internal/Discu
ssion/eager-stitching.txt

--Brian


Date: Wed, 3 Jul 1996 17:15:29 -0700
From: eggers@yakima (Susan Eggers)
To: spin-comp@yakima
Subject: Scott's issue tracker

I have documentation on it, should you need to use it.  It
checks for good dual issue and instruction alignment in statically-
compiled code: an ATOM tool.

Susan

Date: Thu, 4 Jul 1996 10:16:03 -0700 (PDT)
From: mock@cs.washington.edu (Markus U. Mock)
To: spin-comp@pintail
Subject: KeepConst Annotations

X-keep_const

Here is an updated version of the keepConst annotations. I've also
included some musings for an annotation for function specialization
and memoization fo results.

	-- Markus
===============================================================
	       New Annotations for Runtime Compilation
		

1. Annotations
==============

There are two basic annotations, one to specify constants coming into a
dynamic region and one to specify the variables to be kept constant.

1.1. Syntactic form:
 
A. keepConst(<var-list> [<cache-spec>]) [<stitch-spec>]
where
<var-list> ::= list of variables (possibly empty)
<cache-spec> ::= :cache | :cache1 | :unchecked | :replicate
<stitch-spec> ::= eager | lazy | looplazy

Defaults: keepConst(<var-list> :cache) looplazy

[NB unchecked was called shareConst in the previous draft]


keepConst annotations are only allowed inside of dynamic regions. The
following annotation can be used to "turn keepConst off":

B. unkeepConst(<var-list>)

which is also only allowed inside of a dynamic region.


C. keepConst(<var-list> [:cache | :cache1 | :unchecked] {
	/* the dynamic region */
}

Default: cache

The keepConst(<varlist) {} annotation can be nested.


1.2 Intended Use of New Annotations

A. keepConst

keepConst is used to tell the dynamic compilation system that the
variables specified in the list of variables are to be kept constant
from that point on downstream to the end of the dynamic region or
until killed by "unkeepConst". For that purpose at merge points new
versions will be generated as necessary. For the caching of these
versions the following alternatives policies are provided:

a) cache 
   An infinite number of versions will be cached. 
   The cache will be checked for the needed version. If present, it
   will be used, otherwise the new version will be produced and cached
   along with versions already in the cache, growing the cache by one.

b) cache1
   Exactly one version will be cached.
   Like a) except that a new version replaces the old version in the
   cache maintaining the cache size at 1.


c) unchecked [was called shareConst before]

   Exactly one version will be cached, but no check will be done to
   ascertain that the cached version is the correct one. 
   The programmer asserts that the value of the variable will never
   change, if this is not actually the case, the results will likely
   be incorrect (the cached version will be used w/o a check and will
   likely have an incorrect value).

d) replicate

   No caching will take place. Each time a new version will be
   produced, even for values encountered before. This obviates the
   possibly expensive cache check and will be useful for loop
   unrolling where each iteration value will be produced only once
   (e.g. in simple counting loops).


B. unkeepConst

unkeepConst is used to tell the compiler to not keep a variable
constant anymore from the point of the unkeepConst annotation. This
will be useful to further divide a dynamic region.



C.  keepConst(<var-list> [:cache | :cache1 | :unchecked] {
	/* the dynamic region */
}


The keepConst annotation with a block is used to mark the beginning and
extent of a dynamic region. It is also used to specify the set of
variables that are assumed to be constant throughout the region, given
in the variable list. The <cache-spec> is used to specify how to deal
with multiple versions, analogous to the keys in our previous dynamic
compilation design. Using "cache" specifies an infinite size cache of
versions, "cache1" a cache of size 1 (i.e. a new version will replace
an existing old one). At the start of the region a check of the cache
needs to be made when using cache or cache1. Cache1 will be useful if
the incoming values exhibit temporal locality, i.e. the same set of
values enters the region for some time then changes and then stays the
same again for some time. If that is not the case, "cache" should be
used, which is also the default. "unchecked" is like cache1 except
that no cache check is done. The programmer asserts that the variable
will only have one value and won't change.

For variables in <var-list> that are actually changed in the region,
the behavior is like putting a keepConst inside the region,
i.e. multiple versions will be created and cached using the specified
cache policies.



Nesting:
-------

keepConst's with regions can be nested. For example

keepConst(x) {
   ... /* R1 region */
   keepConst(y) {
      ... /* R2 nested region */
   }
   ... /* R1 */
}


In region R1 only x will be kept constant (assuming no other keepConst
annotations within R1, in R2 all variables of surrounding regions
(here R1) will be kept constant and the variables declared for region
R2. In this case, both x and y are kept constant inside R2.



2. IR-level annotations
=======================

2.1 Computation of IR level annotations
----------------------------------------

The annotations at the programming language level are converted to
annotations at the IR level in the following way:

1. Annotations are propagated along non-backedges only
2. Propagation is done according to these rules: 

(:C L are the caching and laziness specifications, i.e 
	C \in {cache, cache1, replicate, unchecked}
	L \in {eager, lazy, looplazy}
	
   keepConst(<x1, .. xn> :C) L:		Out = In + {(x1,C,L), .. (xn,C,L)}
   unkeepConst(<x1, .. xn> :C) L:	Out = In - {(x1,C,L), .. (xn,C,L)}
   keepConst(<x1, .. xn> :C){}:		Out = {(x1,C,eager) .. (xn,C,eager)}
  
   other:				Out = In



At Merges: Out = U In(p) for all predecessors p
U is ordinary set union. 

Call the information computed by these rules  Kconst(p) for program
point p.




For a (dynamic) merge point m, additionally the overall caching and laziness
policies C(m) and L(m) are computed as follows:

L({(x1,C1,L1), .. (xn, Cn, Ln)}) = min(L1, .. Ln) where min is the
minimum of the following order: lazy < looplazy < eager

C({(x1,C1,L1), .. (xn, Cn, Ln)}) = min(C1, .. Cn)
where min is the minimum of the following order:
replicate < cache < cache1 < unchecked

Making different annotations for the same variable ((x,C,L) , (x,C',L') where (C,L) != (C',L')) is not allowed and flagged as an error.

 



2.2 Laziness annotations at the IR level
----------------------------------------
For lazy stitching we must compute which dynamic branches we want to
treat lazily and which eagerly. In the previous section we have
computed annotations for dynamic merge points based on the programmer
annotations for the variables. From these (dynamic) merge point
annotations we compute which dynamic branches are treated lazily. 

1. All dynamic merges annotated as looplazy are changed to
     eager iff they are not loop head merges
     lazy iff they are loop head merges

2. For each dynamic merge M annotated lazy:
     compute the earliest post-dominating edges E of M and mark them
     as lazy

3. For each dynamic branch D:
      If any outgoing edge of D is marked lazy mark D as a lazy
      otherwise as eager


When edge E post-dominates edge E' (or node p) we are sure that when
we follow edge E we are guaranteed to traverse E' (pass thru p) later.

[An vertex v' post-dominates a vertex v in a graph G iff v dominates
v' in G' where G' is obtained from G by reversing the edges. The
dominates-relation for edges is obtained by introducing a new vertex
v12 for each edge (v1,v2) and replacing it in the graph with edges
(v1,v) and (v, v2). An edge (v1,v2) dominates (v3,v4) iff in the new
graph v12 dominates v34.


Example:

	d1?
      l/  \
      d2?   B1
     / \    |  /
    B2 B3   d3? 
     \ /  l/  \______>
      -----
M:

If M is annotated as lazy the left edge of d1 and d3 each
post-dominate M and hence are annotated as lazy. d1 and d3 will be
stitched lazily, d2 eagerly.





3. BTA
======

The BTA needs the following modifications for the new annotations:


1. Initial set

C(p0) = set of variables annotated as constant in the
keepConst(<var-list>){} region annotation


2. Flow functions

Each flow function is modified (f(ins) denotes the previously used
flow function for instruction ins):

Cflow [[ins]] cs = f(ins) U Kconst(p) i.e. the set of variables to be
kept constant at the program point are always considered constant at
point p.

3. Merge function

Mconstant(cs1, cs2) = cs1 U cs2 if cn1 and cn2 are mutually exclusive
                   	(static merge)
                     (cs1 \intersection cs2) U Kconst(p) otherwise

i.e. static merges (based on the unmodified reachability analysis) are
treated in the same way as before. For dynamic merges all inferred
constants based on variables annotated to be kept constant are
forgotten, only the variables in Kconst(p) are considered constant on
top of the "traditional" run time constants.

Example:

Assume the programmer has annotated keepConst(x,y)
(SSA form)

	if (d)		; d dynamic condition
	   t1 = x * y
           {x, y, t1}	set of constants
	else
	   t2 = x + y
	   {x, y, t2}	set of constants
M:

At M the merge is a dynamic merge, hence the rule is:

	({x, y, t1 } \intersect {x, y, t2}) U {x,y} 
	= {x, y}



For the loop unrolling example in the paper this works out as follows:

	keepConst(p)

	p1 = 1st
  -->M:				{p1,p3}	
 |	p2 = Phi(p1,p3)
 |	t = (p2 != NULL)
 |	
 |	t?
 |	| \---------->
 |	|  
 |	...
 |  p3 = p2->next
 |	|
 |	|
 -------

M is a non-static merge. For loop unrolling this loop head merge was
therefore marked as a constant merge to be able to derive the loop
induction variable as run time constant. Using the keepConst
annotation for variable p (the induction variable) achieves the same
effect here, by unioning in {p} at M again.
Hence, no special marking for the loop head merge as a constant merge
is necessary, it is sufficient to use keepConst on the variable "along
which" the loop is to be unrolled.


Multi-way loop unrolling is achieved in the same way by annotating the
induction variable along which to unroll. 
Example:

	pc = 0
	keepConst(pc)
	while (1) {
M:
	   op = codes[pc]
	   switch(op) {
	      case ADD: 
	         ...
                 pc++
                 break
              case GOTO:
                 pc = codes[pc+1]
                 break
             ...
	   }
	}


The keepConst(pc) annotation will keep pc constant at the merge point
M and hence in all cases of the switch, which in turn will allow
codes[pc+1] to be derived as a constant.



----------------------------------------------------------------
4. Support for dynamic compilation of function calls


In the present framework, results of function calls cannot be treated
as run time constants and functions will not be specialized for certain
arguments. The following is a proposal for adding some support for
procedure specialization and memoization of results short of
inter-procedural analysis.

4.1 Call site annotations

Form: a = [sefree,idempotent] f(<arg-list>) [specialize on <key-list>]

Intended use: 

sefree (side effect free): 

asserts that the function f (at this call
site) has no side effects that the programmer is interested
in. Example: a call to random, will change the state of the random
number generator but we might not care.

idempotent:

asserts that f (at the call site) is idempotent, i.e. for the same
arguments it will return the same results. Idempotent subsumes sefree.
Example: sin(x)
Special case: all arguments are run time constants at the call
site. Then "a" becomes a run time constant too, and the function f
will be called only once during setup and the result will be cached.


specialize on <keylist>:

is used to specify that the function f is to be specialized at the
call site. It is to be specialized only in the arguments given in
<key-list> which must be a subset of the argument actuals given in
<arg-list>.

Example: a = idempotent f(x,y) specialize on (x)


What happens at run time?

		sefree		idempotent


specialize	specialized	
		versions of f
		are created 
		compiling f assuming
		the arguments 
		being specialized
		on are constant	
				like sefree, additionally
				if all arguments are used for
				specialization, the result can
				be cached and f needs to be called
				only once for each argument tuple.
			

don't 
specialize	---		if all arguments are rtc:
				call f only once during setup and
				cache the result



4.2 Callee Annotation

Another annotation is useful to specialize f independent of the call
site. It is then important to specify which arguments are interesting
for specialization.

Form:
 
	specialize [idempotent, sfree] f(x1,..,xn) on (<key-list>) 
where <key-list> is a subset of the argument list.

Intended Use:

Here the intended use is to create as many specialized versions of f
where specialization is done exactly on the arguments listed in the
key. Additionally, f can be asserted to be side-effect free or
idempotent.


If there are both callee and call-site annotations for f, the call
site annotation overrides the callee annotation and a specialized
version for the particular call site is created independent of the
other specialized version(s) for f.


Implementation:
--------------

BTA:

All cases leave the set of computed run time constants unaffected
except for
a = idempotent f(x1, .. xn)
where all x1, .. xn are rtc's. The BTA is changed to make "a" a derived
rtc then.


(static) compile time:

Each specialized function becomes an implicit dynamic region and gets
compiled as such. For each call site a different template will be
produced. If all arguments are run time constants, now function call
will need to be compiled. A general version of f will be kept, called
as setup and the result will be used as the value of the runtime
constant function result.

Runtime:

At the call site, the produced template gets stitched with the
appropriate run time constants (the arguments to specialize on). A
cache for versions of f is checked first, to find out if the required
version has already been produced before.


There seems to be no other magic involved. Hence, these annotations
would be implementable and useful, enlarging the range of programs
that can be profitably compiled, even without doing inter-procedural
analysis.



================================================================
Design of New Annotations
As of $Date: 1996/07/03 22:08:03 $

Date: Fri, 5 Jul 1996 16:13:14 -0700
From: chambers@klamath (Craig Chambers)
To: spin-comp@cs
Subject: summer meetings

Since we just have 4 people here this summer, I propose that we not have
weekly individual meetings and instead have a single weekly (or more often if
needed) meeting of the 4 of us to go over compiler algorithms, discuss
designs, and plan implementation strategy.  Basically, a weekly "group"
meeting where we actually get work done.  Can people make Mondays at 11am?
Starting on the 8th?

-- Craig

Date: Fri, 5 Jul 1996 16:50:04 -0700
From: eggers@yakima (Susan Eggers)
To: spin-comp@cs, chambers@klamath
Subject: Re: summer meetings


I cannot make Mondays at that time, and would rather not make
Mondays at all.  But Tuesdays through Thursdays are pretty clear.

Susan

Date: Fri, 5 Jul 1996 17:21:40 -0700
From: chambers@klamath (Craig Chambers)
To: spin-comp@cs
Subject: Re: summer meetings

FYI, the kind of meetings I have in mind are those only active implementors 
would be part of.  Not for passive interested parties.  In lieu of 
individual weekly meetings (or aggregated together).

If we want a more general "heads-up" meeting, e.g. every few weeks, we can
add that, too.  Maybe one combined w/ a full SPIN meeting?

-- Craig

Date: Thu, 18 Jul 1996 01:32:27 -0700 (PDT)
From: "Markus U. Mock" <mock@cs.washington.edu>
To: spin-comp@cs.washington.edu
Subject: New Annotations update

Here's an updated version. I am still working on the function
specialization part, so it's not included here (should be independent of
the other stuff)



	-- Markus 

===========================================================
	       New Annotations for Runtime Compilation
		

1. Annotations
==============

There are two basic annotations, one to specify constants coming into a
dynamic region and one to specify the variables to be kept constant.


1.1. Syntactic form:
 
A. keepConst(<var-list> [<cache-spec>]) [<stitch-spec>]
where
<var-list> ::= list of variables (possibly empty)
<cache-spec> ::= :cache | :cache1 | :unchecked | :replicate
<stitch-spec> ::= eager | lazy | looplazy

Defaults: keepConst(<var-list> :cache) looplazy

[NB unchecked was called shareConst in the previous draft]


keepConst annotations are only allowed inside of dynamic regions. The
following annotation can be used to "turn keepConst off":

B. unkeepConst(<var-list>)

which is also only allowed inside of a dynamic region.


C. dynamicRegion isConst (<var-list> [:cache | :cache1 | :unchecked]) {
	/* the dynamic region */
}

Default: cache

The dynamicRegion isConst() {} annotation can be nested.
The variable list in isConst lists the variables that are assumed to
be constant at the beginning of the region. 

D. isConst(<var-list>  [:cache | :cache1 | :unchecked]) 

Default: unchecked

isConst can be used anywhere inside the dynamic region. When used inside the
dynamic region the default caching behavior is "unchecked".



1.2 Intended Use of New Annotations

A. keepConst

keepConst is used to tell the dynamic compilation system that the
variables specified in the list of variables are to be kept constant
from that point on downstream to the end of the dynamic region or
until killed by "unkeepConst". For that purpose at merge points new
versions will be generated as necessary. For the caching of these
versions the following alternatives policies are provided:

a) cache 
   An infinite number of versions will be cached. 
   The cache will be checked for the needed version. If present, it
   will be used, otherwise the new version will be produced and cached
   along with versions already in the cache, growing the cache by one.

b) cache1
   Exactly one version will be cached.
   Like a) except that a new version replaces the old version in the
   cache maintaining the cache size at 1.


c) unchecked [was called shareConst before]

   Exactly one version will be cached, but no check will be done to
   ascertain that the cached version is the correct one. 
   The programmer asserts that the value of the variable will never
   change, if this is not actually the case, the results will likely
   be incorrect (the cached version will be used w/o a check and will
   likely have an incorrect value).
   NB Note that "exactly one" refers to the current context, i.e. for
   each context one version will be cached.


d) replicate

   No cache probing will take place. Each time a new version will be
   produced, even for values encountered before. This obviates the
   possibly expensive cache check and will be useful for loop
   unrolling where each iteration value will be produced only once
   (e.g. in simple counting loops).


For one particular variable only one caching policy is allowed. How
different cache policies for different variables can be mixed and
matched is explained in section 2.1.  
What will be used as cache keys and where cache checks will be done is
explained in section 3. 



B. unkeepConst

unkeepConst is used to tell the compiler to not keep a variable
constant anymore from the point of the unkeepConst annotation. This
will be useful to further divide a dynamic region.


C. isConst(<var-list> [:cache | :cache1 | :unchecked]

Default: unchecked

isConst inside a dynamic region is used as a hint to the BTA that the
listed variables are constant at that point. In the BTA the variable
will keep its property as runtime constant until it possibly loses that
property at some dynamic merge. No attempt is made to keep the
variable constant, i.e. no specialization is done. Essentially the BTA
treats such a variable like a derived rtc just that the "derivation"
is  by means of the programmer annotation isConst. 

The caching policies "cache" and "cache1" can be used to insert a
cache check and cache multiple versions. In the default case
"unchecked" it is the programmer's responsibility to make sure that
the variable always has the same value at that point (in the same
context). 

Example:

	dynamicRegion isConst(x) {
	   y = ...
I:	   isConst(y)
           z = y + x + 3;
	   .. some uses of x, y, z ..
P:	   y = y + d /* d some dynamic variable */
		
M:	   x = x + d

	}


y is treated as a constant from point I to point P where it loses its
constancy in the BTA. So z is also a (derived) constant as both y,
x and 3 are rtc.
At M x retains its constancy by specialization, 

The programmer must assure (as y is unchecked) y'v value is the same
at point I for the same context. Here the context is the value of x,
i.e. y = f(x) for some function f. 


NB. keepConst and isConst cannot be used at the same time on the same
variable.




D.  dynamicRegion [is_const(<var-list> [:cache | :cache1 |:unchecked]) {

	/* the dynamic region */
}

Default: cache



The dynamicRegion annotation is used to mark the beginning and
extent of a dynamic region. It is also used to specify the set of
variables that are assumed to be constant throughout the region, given
in the variable list isConst(<var-list>).
 
The caching specification is used to specify how to deal with multiple
versions (of the dynamic region), analogous to the keys in our
previous dynamic compilation design. Using "cache" specifies an
infinite size cache of versions, "cache1" a cache of size 1 (i.e. a
new version will replace an existing old one). At the start of the
region a check of the cache needs to be made when using cache or
cache1. Cache1 will be useful if the incoming values exhibit temporal
locality, i.e. the same set of values enters the region for some time
then changes and then stays the same again for some time. If that is
not the case, "cache" should be used, which is also the
default. "unchecked" is like cache1 except that no cache check is
done. The programmer asserts that the variable will only have one
value and won't change.

The variables listed in isConst() are the initial runtime constants
assumed to be constant throughout the region. If their value is
actually changed inside the region, the outcome is undefined.




Nesting:
-------

dynamicRegion annotations can be nested.
For example:

dynamicRegion isconst() {
   keepConst(x);
   ... /* R1 region */
   dynamicRegion isConst() {
   keepConst(y);
      ... /* R2 nested region */
   }
   ... /* R1 */
}


In region R1 only x will be kept constant (assuming no other keepConst
annotations within R1), in R2 all variables of surrounding regions
(here R1) will be kept constant and the variables declared for region
R2. In this case, both x and y are kept constant inside R2.

In the case where y is invariant with respect to x at the start of
region R2 (i.e. y = f(x), f a function) caching of y would be
superfluous. In this case, however, using the isConst annotation will
achieve the same effect inside R2 while obviating the need for caching
on y. A better way to write the annotations then is:

dynamicRegion isConst() {
   keepConst(x);
   ... /* R1 region */
   dynamicRegion isConst(y:unchecked) {
      ... /* R2 nested region */
   }
   ... /* R1 */
}




2. IR-level annotations
=======================

2.1 Computation of IR level annotations
----------------------------------------

The keepConst and isConst annotations at the programming language
level are converted to annotations at the IR level in the following
way:


1. (Annotations are propagated along non-backedges only
2. Propagation is done according to these rules: 

A. for keepConst

(:C L are the caching and laziness specifications, i.e 
	C \in {cache, cache1, replicate, unchecked}
	L \in {eager, lazy, looplazy}


   keepConst(<x1, .. xn> :C) L:		Out = In + {(x1,C,L),.. (xn,C,L)}
   unkeepConst(<x1, .. xn> :C) L:	Out = In - {(x1,C,L), .. (xn,C,L)}
  
   other:				Out = In

The "+" denotes set union, with the constraint that foreach variable
x, at most one element (x,C,L) can be in any set. Making different
annotations for the same variable ((x,C,L) , (x,C',L') where (C,L) !=
(C',L')) is not allowed and flagged as an error. 


At Merges: Out = + In(p) for all predecessors p


Call the information computed by these rules  Kconst(p) for program
point p.




For a (dynamic) merge point m, additionally the overall caching and laziness
policies C(m) and L(m) are computed as follows:

L({(x1,C1,L1), .. (xn, Cn, Ln)}) = min(L1, .. Ln) where min is the
minimum of the following order: lazy < looplazy < eager

C({(x1,C1,L1), .. (xn, Cn, Ln)}) = min(C1, .. Cn)
where min is the minimum of the following order:
replicate < cache < cache1 < unchecked


B. for isConst

   dynamicRegion isConst(<x1, .. xn> :C)  {}  
            	  	Out = {(x1,C,looplazy) .. (xn,C,looplazy)}

 
   isConst(<x1, .. xn> :C)
			Out = In + {(x1,C,looplazy) .. (xn,C,looplazy)}

Again "+" is constrained set union as described above.

any other point P:

   Out = {(x,C,L)| x \in rtc(P) and (x,C,L) \in In}

(rtc(M) set of runtime constants at M) i.e. a isConst(x) annotation is
killed at a program point where the the variable x loses its
constancy ("implicit end of that isConst").

	



2.2 Laziness annotations at the IR level
---------------------------------------- For lazy stitching we must
compute which dynamic branches we want to treat lazily and which
eagerly. In the previous section we have computed annotations for
dynamic merge points based on the programmer annotations for the
variables. From these (dynamic) merge point annotations we compute
which dynamic branches are treated lazily.

1. All dynamic merges annotated as looplazy are changed to
     eager iff they are not loop head merges
     lazy iff they are loop head merges

2. For each dynamic merge M annotated lazy:
     compute the earliest post-dominating edges E of M and mark them
     as lazy

3. For each dynamic branch D:
      If any outgoing edge of D is marked lazy mark D as a lazy
      otherwise as eager


When edge E post-dominates edge E' (or node p) we are sure that when
we follow edge E we are guaranteed to traverse E' (pass thru p) later.

[An vertex v' post-dominates a vertex v in a graph G iff v dominates
v' in G' where G' is obtained from G by reversing the edges. The
dominates-relation for edges is obtained by introducing a new vertex
v12 for each edge (v1,v2) and replacing it in the graph with edges
(v1,v) and (v, v2). An edge (v1,v2) dominates (v3,v4) iff in the new
graph v12 dominates v34.


Example:

	d1?
      l/  \
      d2?   B1
     / \    |  /
    B2 B3   d3? 
     \ /  l/  \______>
      -----
M:

If M is annotated as lazy the left edge of d1 and d3 each the earliest
edges that post-dominate M and hence are annotated as lazy. d1 and d3
will be stitched lazily, d2 eagerly.



3. Caching Issues
================

3.1 Lookup Points

A cache lookup needs to be done at the following points:

1. At the start of a dynamic region (assuming the isConst list is non-empty)
2. At each keepConst / isConst with a caching annotation other than unchecked
3. At each "interesting merge", i.e. a merge M where a variable x \in
Kconst(M) has more than one reaching definition. These are the merges
where splitting will be done.

3.2 Cache Keys

Each keepConst / isConst adds the variables in the list to the current
context. An unkeepConst, end of region or implicit end of isConst
removes the corresponding variable(s):

dynamicRegion isConst(x1, .. xn)
KeyOut = 	{x1, .. xn}

isConst(x1, .. xn:C) 
KeyOut =  	KeyIn 			if C == unchecked
		KeyIn U {x1, .., xn}  	otherwise

keepConst(x1, .. xn:C)
KeyOut =  	KeyIn 			if C == unchecked or replicate
		KeyIn U {x1, .., xn}  	otherwise


unkeepConst(x1, .. xn)
KeyOut = 	KeyIn - {x1, .. xn}

implicit end of isConst(x):
KeyOut =	KeyIn - {x}




4. BTA
======

The BTA needs the following modifications for the new annotations:


1. Initial set

C(p0) = set of variables annotated as constant in the
isConst(<var-list>) {} region annotation.


2. Flow functions

Each flow function is modified (f(ins) denotes the previously used
flow function for instruction ins):

Cflow [[ins]] cs = f(ins) U Kconst(p) i.e. the set of variables to be
kept constant at the program point are always considered constant at
point p.

isConst(x) is treated as a pseudo-instruction with the following flow
function:

Cflow [[isConst(x)]] cs = cs U {x}


3. Merge function

Mconstant(cs1, cs2) = cs1 U cs2 if cn1 and cn2 are mutually exclusive
                   	(static merge)
                     (cs1 \intersection cs2) U Kconst(p) otherwise

i.e. static merges (based on the unmodified reachability analysis) are
treated in the same way as before. For dynamic merges all inferred
constants based on variables annotated to be kept constant are
forgotten, only the variables in Kconst(p) are considered constant on

Example:

Assume the programmer has annotated keepConst(x,y)
(SSA form)

	if (d)		; d dynamic condition
	   t1 = x * y
           {x, y, t1}	set of constants
	else
	   t2 = x + y
	   {x, y, t2}	set of constants
M:

At M the merge is a dynamic merge, hence the rule is:

	({x, y, t1 } \intersect {x, y, t2}) U {x,y} 
	= {x, y}



For the loop unrolling example in the paper this works out as follows:

	keepConst(p)

	p1 = 1st
  -->M:				{p1,p3}	
 |	p2 = Phi(p1,p3)
 |	t = (p2 != NULL)
 |	
 |	t?
 |	| \---------->
 |	|  
 |	...
 |  p3 = p2->next
 |	|
 |	|
 -------

M is a non-static merge. For loop unrolling this loop head merge was
therefore marked as a constant merge to be able to derive the loop
induction variable as run time constant. Using the keepConst
annotation for variable p (the induction variable) achieves the same
effect here, by unioning in {p} at M again.
Hence, no special marking for the loop head merge as a constant merge
is necessary, it is sufficient to use keepConst on the variable "along
which" the loop is to be unrolled.


Multi-way loop unrolling is achieved in the same way by annotating the
induction variable along which to unroll. 
Example:

	pc = 0
	keepConst(pc)
	while (1) {
M:
	   op = codes[pc]
	   switch(op) {
	      case ADD: 
	         ...
                 pc++
                 break
              case BRANCH:
		 if (testreg)
                    pc = codes[pc+1]
		 else
		    pc = codes[pc+2]
                 break
             ...
	   }
	}


The keepConst(pc) annotation will keep pc constant at the merge point
M and hence in all cases of the switch, which in turn will allow
codes[pc+1] to be derived as a constant.





================================================================
Design of New Annotations
As of $Date: 1996/07/18 08:29:42 $



To: spin-comp@thistle.cs.washington.edu
Subject: SPIN machines
Date: Wed, 24 Jul 1996 13:31:44 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

We have been asked to stay off the SPIN servers: chiffon, lace, satin, silk,
velvet.  Our logins will soon be disabled on those machines.

We should still be able to use wally and any of the following SPIN machines
(correct me if I'm wrong, Przemek):
Alpo
Calico
Canvas
Chintz
Cotton
Denim
Flannel
Khaki
Linen
Scaup
Spandex
Wigeon
Wool

--Brian


Date: Thu, 15 Aug 1996 08:53:14 -0700
From: chambers@hoh
To: spin-comp@cs
Subject: gone this morning

I had forgotten to let you all know that I'll be out this morning to attend
a friend's wedding, so I'll miss today's group meeting.  I'll be back in
early afternoon.

-- Craig

Date: Thu, 15 Aug 1996 09:56:35 -0700
From: eggers@yakima (Susan Eggers)
To: spin-comp@cs, chambers@hoh
Subject: Re: gone this morning


Why don't we meet when Craig gets back and is free.  3p.

Susan

Date: Thu, 15 Aug 1996 12:56:18 -0700
From: chambers@klamath (Craig Chambers)
To: spin-comp@cs, chambers@hoh, eggers@yakima
Subject: Re: gone this morning

3pm works for me.

-- craig

Date: Wed, 21 Aug 1996 17:43:28 -0700
From: Charles Garrett <garrett@cs.washington.edu>
To: spin-comp@cs.washington.edu
Subject: compiling mm_alpha.C of the multiflow compiler

I played with this file to see why it breaks the gcc compiler.
It appears that one function requires an enormous stack frame
which the compiler can't handle. If you change the lines:

EXTERN RES_REQ MM_Alpha_Skew_Res_Req(
    CHAR *name,
    INT  instance
    )
{
    RES_CLASS args[MAX_ISSUE_VEC + MAX_SKEW][MAX_RCS];

to:

STATIC RES_CLASS args[MAX_ISSUE_VEC + MAX_SKEW][MAX_RCS];

EXTERN RES_REQ MM_Alpha_Skew_Res_Req(
    CHAR *name,
    INT  instance
    )
{

the stack frame is greatly reduced and the compiler is happy.

--
Charlie

Date: Wed, 21 Aug 1996 18:12:34 -0700
From: Charles Garrett <garrett@cs.washington.edu>
To: spin-comp@cs.washington.edu
Subject: compiling testhash.C

We can perform the same fix in the testhash.C program
and get rid of our reliance on the old version of gcc.

The testhash.C file doesn't compile because two functions
have the local argument:

	CHAR *saved_keys[5000];

We can replace this with a single static global variable:

	STATIC CHAR *saved_keys[5000];

--
Charlie

To: Charles Garrett <garrett@cs.washington.edu>
cc: spin-comp@cs.washington.edu
Subject: Re: mm_alpha.C, testhash.C 
Date: Thu, 22 Aug 1996 10:13:40 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

I added Charlie's fixes and checked them into to CVS.  To get the new
versions, cvs update:
./mflow/pmakefile
./mflow/mm/mm_alpha.C
./mflow/util/testhash.C

Thanks, Charlie!
--Brian


Date: Thu, 22 Aug 1996 11:28:52 -0700
From: Charles Garrett <garrett@cs.washington.edu>
To: spin-comp
Subject: Fletcher's directories are readable

David Becker has changed the permissions on Fletcher's directories so
that the matthai:rtcg group has all permissions now.

--
Charlie

To: mock@thistle.cs.washington.edu
cc: spin-comp@thistle.cs.washington.edu
Subject: we have command-line options!
Date: Thu, 22 Aug 1996 14:53:36 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

I put in a dummy option: P2DYC_hello.  New options can be listed in
phase1/main.C in the alphabetically ordered listing.  The name you
specify is both the name of the option and the name of a global variable
that is set automatically.  Cool.

The command-line options can either be specified on the scc command
line or in .ccrc.

Files to update:

./phase1/main.C
./phase1/pmakefile
./p2dep/p2dep.H
./p2dep/p2dep.C
./p2dep/pmakefile
./phase2/csi.C
./phase2/p2_comp_script.csi
./phase2/pmakefile
./p2dyc/p2dyc.H
./p2dyc/p2dyc.C

--Brian


Date: Fri, 23 Aug 1996 13:21:45 -0700
From: Charles Garrett <garrett@cs.washington.edu>
To: spin-comp
Subject: source code for scc

Does anyone know where the source code for scc is located?

Scc is the program that sets up options and calls the Multiflow
C compiler. I am having trouble debugging the C compiler
because I can't set up all of the input files that it wants.

I didn't see the source code in the /projects/trace1/mflow/usr/vssad
directory.

Thanks,

--
Charlie

Date: Fri, 27 Sep 1996 16:07:50 -0700
From: chambers@klamath (Craig Chambers)
To: spin-comp@cs
Subject: meetings

Susan and I are out of town a lot in the next couple of weeks.  And I'm 
freaking out preparing for 143.  And I have a conflict for the designated
590 DC meeting time.


So: let's have a quick meeting sometime next Monday or Tuesday, just to 
touch base and report on progress.  We won't meet the following week.  Then
we need to schedule a recurring meeting time to start the following week.

When are people free next M & T to meet?

-- Craig

Date: Fri, 27 Sep 1996 16:17:19 -0700
From: eggers@yakima (Susan Eggers)
To: spin-comp@cs, chambers@klamath
Subject: Re: meetings


I'm out of town both Monday and Tuesday,
but I could hold a meeting the following
week when Craig is gone at our normal time
on Thursday.

Susan

Date: Fri, 27 Sep 1996 16:47:57 -0700
From: chambers@klamath (Craig Chambers)
To: spin-comp@cs, eggers@yakima
Subject: Re: meetings

I'll actually be back from my trips on Thurs (Oct 10), but I assume I'll be
swamped w/ 143 catch-up, so I may have to miss a Thurs meeting.

-- Craig

Date: Mon, 30 Sep 1996 11:09:36 -0700
From: chambers@klamath (Craig Chambers)
To: spin-comp@cs
Subject: Re: meetings

OK, based on everyone's schedules, let's meet 10:30-11am Tuesday morn.
See you all then.

-- Craig

Date: Sat, 5 Oct 1996 13:44:47 -0700
From: eggers@yakima (Susan Eggers)
To: spin-comp@cs, chambers@klamath
Subject: Re: meetings


Just to remind you, I'll be at an DARPA meeting this Tuesday.

Susan

Date: Wed, 9 Oct 1996 16:40:16 -0700
From: eggers@yakima (Susan Eggers)
To: spin-comp@yakima
Subject: thursday meeting

are we meeting tomorrow?

susan

Date: Wed, 09 Oct 1996 17:00:55 -0700
From: Charles Garrett <garrett@cs.washington.edu>
To: Susan Eggers <eggers@yakima>
Subject: Re: thursday meeting

Susan Eggers wrote:
> 
> are we meeting tomorrow?
> 
> susan

I can meet. I have modest progess to report on the 64-bit front.

--
Charlie

Date: Wed, 9 Oct 1996 21:45:03 -0700
From: eggers@yakima (Susan Eggers)
To: eggers@yakima, garrett@cs.washington.edu
Subject: Re: thursday meeting
Cc: spin-comp@june


I'd like to get some update on the status or nonstatus of a PLDI
paper Craig tells me may or may not have materialized while I was
gone.
Did you all meet on Tuesday?

Susan

Date: Thu, 10 Oct 1996 12:23:43 -0700
From: eggers@yakima (Susan Eggers)
To: spin-comp@yakima
Subject: annotation paper

Craig says that Markus is writing a quals paper that might serve
as a template, so to speak.  So let's not give up the ghost on
a PLDI submission just yet.  

When Markus gets back from OOPLSLA, let's meet briefly to nail
down a game plan and find out the status of his quals paper.
For next Thursday's meeting come having already thought about
an outline.  And I"ll talk to Matthai today (and Brian too?)
about using the annotations in programs, meaning finding programs
that need our flexibility.  

Susan

To: spin-comp@thistle.cs.washington.edu
Subject: PLDI `97 home page
Date: Tue, 22 Oct 1996 11:42:56 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

http://www.cs.wustl.edu/~cytron/pldi97/call.html

Date: Tue, 22 Oct 1996 19:49:54 -0700
From: eggers@yakima (Susan Eggers)
To: spin-comp@yakima
Subject: I updated the mailing list

Turns out there was more out of date than just those two names.
spin-comp is for our meeting group (matthai,brian,markus,charlie,
craig,susan) and spin-compALL for the larger community.

Susan

Date: Thu, 24 Oct 1996 10:45:50 -0700
From: eggers@yakima (Susan Eggers)
To: spin-comp@yakima
Subject: comments

Just a reminder to leave enough space (double space) so we can make
comments between lines.

Susan

Date: Wed, 30 Oct 1996 11:01:21 -0800
From: eggers@yakima (Susan Eggers)
To: spin-comp@yakima
Subject: tomorrow's meeting

Dear paper writers --

Do we have to have our usual DC meeting tomorrow, or will you be
writing away.  If the latter, I would prefer to cancel, and just
drive by on my way to the airport to pick up the paper.

I already know that Charlie will probably have little/nothing to
report, since he's been tied up with the OSDI demo.

Susan

To: eggers@yakima (Susan Eggers)
cc: spin-comp@thistle.cs.washington.edu
Subject: Re: tomorrow's meeting 
Date: Wed, 30 Oct 1996 11:05:47 PST
From: Brian Grant <grant@thistle.cs.washington.edu>

>> If the latter, I would prefer to cancel, and just
>> drive by on my way to the airport to pick up the paper.

Might as well cancel.  I'm not sure how much of the paper will be ready
before you leave, but we'll give you what we have done.  Our more realistic
target for a draft (not just pieces like we handed you on Monday) is Friday.

--Brian


Date: Sun, 3 Nov 1996 12:32:40 -0800
From: eggers@yakima (Susan Eggers)
To: spin-comp@yakima
Subject: what's the status on the paper?


Date: Sun, 3 Nov 1996 12:41:15 -0800
From: eggers@yakima (Susan Eggers)
To: spin-comp@yakima
Subject: \PLDI deadline

Ours is firm -- Nov. 8.

Susan

To: eggers@yakima (Susan Eggers)
cc: spin-comp@thistle.cs.washington.edu
Subject: Re: \PLDI deadline 
Date: Sun, 03 Nov 1996 12:43:41 PST
From: Brian Grant <grant@thistle.cs.washington.edu>

>> Ours is firm -- Nov. 8.

We're getting there.  We're working on essentially the third draft now, even
though it will be the first one with all of the figures, cross references, and
citations.

--Brian


Date: Wed, 06 Nov 1996 16:16:38 -0800
From: Charles Garrett <garrett@cs.washington.edu>
To: chambers
Subject: Meeting tomorrow

Craig,

    Obviously you are very busy with paper deadlines. Are you
going to have time for the DyC meeting tomorrow? 

    I will summarize what I've been working on lately in
case there is no meeting.

    I have been working on making the Multiflow compiler
produce object files that will link with normal Alpha
libraries. I think I have successfully changed the calling
convention (since I can't link yet, I don't know for sure.)
As part of that change, I figured out how to make Multiflow 
discriminate between argument passing registers and return value
registers. It used to assume that any temporary register could
be used for both functions. For the time being, I am going
to make the compiler think that all temporary registers are
caller-saved. That will make it safe to call library routines
compiled by the DEC compiler.

    Now I am working on getting the Multiflow compiled object
files to link with DEC libraries. The difficulty is that the
Multiflow compiler and assembler assumed a 32-bit address space
and some of their instruction sequences won't work in a 64-bit
address space. I believe that it can be made to work by using
the DEC assembler instead and changing some of the assembly 
language code emitted by Multiflow. I should know whether this
approach will work in a couple of days.

--
Charlie

Date: Thu, 7 Nov 1996 12:42:09 -0800
From: eggers@yakima (Susan Eggers)
To: spin-comp@yakima
Subject: CA

I'm staying in CA until Sunday.  I'll see you next week.

susan

Date: Mon, 11 Nov 1996 10:32:48 -0800
From: eggers@yakima (Susan Eggers)
To: spin-comp@yakima
Subject: DC meeting

I got back in town yesterday, but am leaving again on Wednesday,
and will be gone almost continuously until after Thanksgiving.
If at possible (I realize that Craig in particular is pretty busy
these days), I'd like to meet as a group some time Tuesday or
Wednesday.  And then unless we cover the topics in the general
meeting, talk to Matthai and Brian separately.

Any takers?

Susan

Date: Mon, 11 Nov 1996 10:39:35 -0800
From: chambers@klamath (Craig Chambers)
To: spin-comp@yakima, eggers@yakima
Subject: Re: DC meeting

I can meet at noon tomorrow, after my other meetings of the morning.

-- Craig

Date: Mon, 11 Nov 1996 12:33:29 -0800
From: eggers@yakima (Susan Eggers)
To: spin-comp@yakima, eggers@yakima, chambers@klamath
Subject: Re: DC meeting


Noon is fine iwth Matthai and me.

Susan

Date: Mon, 11 Nov 1996 13:54:17 -0800 (PST)
From: "Markus U. Mock" <mock@cs.washington.edu>
To: Susan Eggers <eggers@yakima.cs.washington.edu>
cc: spin-comp@yakima.cs.washington.edu, chambers@klamath.cs.washington.edu
Subject: Re: DC meeting

works for me too.




	-- Markus 


On Mon, 11 Nov 1996, Susan Eggers wrote:

   
   Noon is fine iwth Matthai and me.
   
   Susan
   


Date: Mon, 11 Nov 1996 23:57:23 -0800
From: garrett@cs.washington.edu
To: spin-comp@yakima.cs.washington.edu
Subject: Re: DC meeting

> On Mon, 11 Nov 1996, Susan Eggers wrote:
> 
> 
>    Noon is fine iwth Matthai and me.
> 

I can make it as well.

--
Charlie

To: spin-comp@thistle.cs.washington.edu
Subject: paper outline
Date: Wed, 13 Nov 1996 17:45:05 PST
From: Brian Grant <grant@thistle.cs.washington.edu>

Here is the outline as it currently stands.  The sections are pretty firm,
but the specific points we want to make are not yet completely worked out.

--Brian


Title?

-- Introduction
	-- DC is good
		-- Some success on applications
		-- Run-time PE is one popular approach to DC
	-- What's missing in previous run-time PE work
		-- polyvariant division
		-- control over specialization
		-- intraprocedural, direct-style, per-program-point
		   specialization
	-- Our system provides all that
	-- Paper outline

-- Title?  Annotations
	-- Declarative annotations
		-- vs. imperative program construction
		-- We have intraprocedural and interprocedural annotations
	-- Intraprocedural annotations
		-- Introduction of makeStatic and makeDynamic
			-- Dynamic-to-static promotion
				-- At annotation
				-- At a dynamic assignment
			-- Dynamic regions
				-- Scope of annotations
		-- The annotations are intraprocedural
			-- Imperative constructs
				-- Assignments
				-- Decisions
				-- Loops
			-- Handle arbitrary control flow:
			   break, continue, goto
		-- Permits direct-style per-program-point specialization
			-- Nested and overlapping regions
			-- vs. systems that only do interprocedural and
			   function-scale specialization, requiring
				-- Tail recursion
				-- CPS
		-- Stack-based interpreter example from PLDI paper
	-- Interprocedural annotations
		-- Introduce specialize [constant] and inline annotations
		-- Separate compilation
	-- Cost vs. benefit
		-- Default behavior of makeStatic: full power of PE
		   intraprocedurally (polyvariant specialization and division)
		-- Policies and function annotations for control

-- Harnessing the Power of PE
	-- Polyvariant specialization
		-- Multi-way LU
			-- JavaVM?
			-- Others?
		-- Nested-region example
			-- Graphics example?
	-- Polyvariant division
		-- Call-site-specific function specialization
		   Good example?  Call used outside a loop where we
		   want to specialize on many arguments and another
		   inside a loop where we want to specialize on fewer
		   arguments.
		-- "Online-like" specialization
		   Polyvariant division compensates for advantage of
		   on-line PE over off-line: more accurate information.
		        /* How do we avoid bringing up policies if
		           promoteStatic is the default behavior? */
			makeStatic(x : polyvariant);
			if (s1) {
				x = s2;	
				...x...
			} else {
				x = d1;
				...x...
			}
			...x...
		   On-line PE will know whether x should be static or
		   dynamic after the merge.  Monovariant division
		   makes x dynamic.  Polyvariant division makes x
		   static on the true path and dynamic on the false path.
		-- Conditional specialization
		   We can turn this around to do conditional
		   specialization.  In addition to continuing to
		   specialize on paths where a variable remains
		   static, we can also make a variable static on
		   certain paths.
			if (s1) {
				x = d1;
				makeStatic(x);
				...x...
			} else {
				x = d2;
				...x...
			}
			...x...

-- Controlling PE
	-- Cost vs. benefit
		-- Specialization has a run-time cost
		-- Speedup times number of times executed must
		   outweigh cost
		-- Particularly high costs:
			-- Run-time loop unrolling
			-- Run-time function inlining
	-- Mononvariant vs. polyvariant
		-- monovariant, polyvariant, promoteStatic
		-- makeStatic default is promoteStatic
		-- Default for compile-time and derived constants is monovariant
	-- Function specialization
		-- Specialization: specialize
		-- Inlining: inline
			-- Termination?
		-- Memoization: specialize constant
			-- Performance/safety tradeoff
	-- Cacheing
		-- space
			-- cache: unlimited copies
			-- cache1: limited to one
			-- cache(n): could specify arbitrary limit
		-- checks
			-- replicate for loops
			-- unchecked for run-time constants
			-- Performance/safety tradeoff
		-- what policy has precedence
			-- what to check
			-- how many versions to cache
	-- Pointer transitivity
		-- transitive, intransitive
		-- makeStatic, makeDynamic: *, ->
		-- Usability issue
		-- Need this to make dereferences static
		-- Performance/safety tradeoff
	-- Eager/lazy specialization
		-- we permit unsafe (e.g., trapping) operations to be static
			-- Division, tan(), pointer dereferences
		-- eager, loopLazy, polyLazy, lazy
		-- use of policies
			-- in loops
			-- precedence
		-- makeEager, makeLazy: while, for, if, switch, ?:,
		   ||, &&
		-- Performance/safety tradeoff
		-- Termination
	-- Conditional specialization in policies
		-- Polyvariant division: split on different policies
		   (except polyvariant vs. promoteStatic)
		-- Conditional unrolling example

-- Implementation
	-- Use stuff from PLDI
	-- Add something about aliasing:
		makeStatic(x : promoteStatic);
		p = &x; /* must kill x here without alias analysis */
	-- Add something about cache policies
		-- cache: making data executable
		-- cache1: flushing the instruction cache
		-- cache(n): replacement policies

-- Related Work
	-- Static PE
		How much of the following do we want to say?
                ** PE: static, source-to-source translation, functional
                   languages, higher-order functions, self
		   application, fully automatic given root
		   static/dynamic division, interprocedural
                ** Us: dynamic, compiler, C, rely on annotations to
                   direct specialization, intraprocedural

		-- Craig's off-line, on-line, run-time chart
			-- Off-line: (division), (specialization), (execution)
			-- On-line: (division, specialization), (execution)
			-- Run-time: (division), (specialization, execution)
		-- Specialization has no run-time cost in static PE
		   other than impact on instruction-cache locality
		-- Run-time PE does dynamic-to-static promotion
			-- Eliminates need for "the trick"
			-- Can specialize on variables of unbounded variation
		-- Different concerns wrt. termination because
		   specialization and execution can be interleaved;
			-- Laziness ensures termination
			-- Can require eager specialization
			   (unrolling, inlining) be statically bound
			-- Or, can always just stop specialization
			   arbitrarily and begin again if needed
		-- Function annotations
			-- We have a static unfolding strategy (cf. Sestoft's
			   Automatic Call Unfolding paper p. 489) 
			-- Separate compilation difficult with
			   interprocedural analysis 
			-- Filters
				-- Control over unfold/residualize/generalize
				-- Similar to function annotations
	-- Runtime PE
		-- No polyvariant division
			-- Fabius supports two-stage divisions in
			   which a function may be specialized on all
			   its arguments, a particular subset of its
			   arguments, or none of its arguments,
			   depending on which arguments are static at
			   the call site.
		-- Interprocedural, function-scale specialization
		-- Little control: only what functions on what arguments
	-- `C
		-- Declarative systems can perform powerful specializations
			-- Multi-way LU
			-- Generate arbitrary code graphs
		-- The declarative systems have the following
		   advantages over imperative systems. 
			-- They can be directly applicable to existing
			   programs. 
			-- They are easier to apply in new programs.
				-- Don't need to learn new language
				-- Provides lots of functionality
				   automatically 
					-- Identification of static values
					   from a small root set
					-- Identification of dynamic code
					-- Creation of generating extension
					-- Cacheing multiple versions
					-- Respecialization as needed
					-- Easily specified
					   conditional specialization
			-- They facilitate debugging by preserving the
			   semantics of annotated statically compilable programs.
			-- They do not obfuscate the control flow of
			   dynamically compiled code, which inhibits
			   global optimization in imperative systems. 

-- Conclusion


Date: Thu, 14 Nov 1996 09:49:29 -0800
From: chambers@klamath (Craig Chambers)
To: spin-comp@cs
Subject: Re: pepm extension?

A short extension...

----- Begin Included Message -----

From Charles.Consel@swann.irisa.fr  Thu Nov 14 04:39:42 1996
Delivery-Date: Thu, 14 Nov 1996 04:39:47 PST
Date: Thu, 14 Nov 1996 13:39:28 +0100
From: Charles Consel <Charles.Consel@irisa.fr>
To: chambers@cs.washington.edu
CC: charles.consel@irisa.fr
Subject: Re: pepm extension?


Hi Craig,

The paper you outlined seems quite interesting.

The *firm* extension is thursday night, 21 nov so that I can dispatch
the papers before on friday.

Charles



----- End Included Message -----


Date: Thu, 14 Nov 1996 09:55:47 -0800
From: chambers@klamath (Craig Chambers)
To: chambers@cs.washington.edu, mock@cs.washington.edu
Subject: Re: DC meeting on Thursday
Cc: spin-comp@cs

Ag, I didn't we were meeting, since Susan's gone and you all are paper-writing.
Can we go on that plan?

-- Craig

Date: Thu, 14 Nov 1996 09:59:33 -0800
From: chambers@klamath (Craig Chambers)
To: spin-comp@cs
Subject: pepm extension?

FYI, this is what I sent Charles.

----- Begin Included Message -----

From chambers Wed Nov 13 10:02:58 1996
To: charles.consel@irisa.fr
Subject: pepm extension?

Hi, Charles.  We're working hard on a PEPM submission about a revised and
rethought annotation language to control dynamic compilation, which gives us 
a lot of power and a lot of control with little additional programmer
intervention.  The annotation language draws from a number of sophisticated
PE ideas (e.g. polyvariant division), and in the end I think we can express
all of `C's examples but in a nice declarative style that's still executable
if you ignore the annotations (unlike `C!).

However, the deadline is fast approaching, and we're worried about getting
the paper in shape in time.  Can we get an extension to the Nov. 18 deadline?
Ideally a week, but we'll take whatever you can offer.

Thanks a lot for your consideration.

-- Craig Chambers


----- End Included Message -----


Date: Thu, 14 Nov 1996 17:45:42 -0800
From: Charles Garrett <garrett@cs.washington.edu>
To: cutler@gatekeeper.equator.com
Subject: Multiflow bug or optimization?

Ben,

    I don't know if you've been keeping track of our work here,
so let me briefly describe what I am doing before I ask you about
a possible bug. I have been working on making Multiflow produce
64-bit code for the Alpha. So far I have gotten it to produce 
correct 64-bit code for about 10 small programs and I am currently
attempting to make Multiflow use the standard Alpha calling 
conventions and produce code that will link with the standard
libraries.

    While working on the calling convention part, I ran into
the following problem. In this example procedure:

	int funny(int** p) {
	    if (*p) {
		return **p;
	    }
	    return 3;
	}

the compiler produces code that dereferences **p before the
test of *p. At first I assumed that this was caused by our
changes to the compiler, but I checked it with our baseline
version of Multiflow and it did the same thing.

    I was able to think of a possible explanation for this,
which is that the compiler knows that if the branch is not 
taken then *p will be 0 and if it also knows that address 0
will always be mapped in the address space, then it is alright
to dereference *p without worrying about a segmentation fault.
And if the branch is taken, then *p will be dereferenced 
anyway so it won't hurt to do it before the branch. It turns
out that address 0 is mapped in the 32-bit executables produced
by Multiflow, so executing the load before the branch doesn't
cause any problems in them. However, in 64-bit executables produced
by the Alpha linker, address 0 is not mapped and I don't know how
to force it to be mapped.

    So do you know if this behavior is a bug or a legal
optimization? Thanks for your help.

--
Charlie

From: cutler@equator.com
Date: Fri, 15 Nov 96 14:30:22    
Subject: RE: Multiflow bug or optimization? 
To: cutler@equator.com, Charles Garrett <garrett@cs.washington.edu>
Cc: spin-comp@cs.washington.edu, jlo@cs.washington.edu

Without trying this myself, my quess is that the second load (**p) is a 
dismissible load (i.e., speculative load).  Probably the alpha compiler 
just emits this as a normal (rather than dismissible) load operation.

Try using the option: -mP3OPT_allow_dismiss=FALSE and see if it still 
happens.  Also, has the branch been eliminated or is the branching 
structure still present?  The optimizer might also be doing this.

-Ben

--- On Thu, 14 Nov 1996 17:45:42 -0800  Charles Garrett 
<garrett@cs.washington.edu> wrote:
Ben,

    I don't know if you've been keeping track of our work here,
so let me briefly describe what I am doing before I ask you about
a possible bug. I have been working on making Multiflow produce
64-bit code for the Alpha. So far I have gotten it to produce 
correct 64-bit code for about 10 small programs and I am currently
attempting to make Multiflow use the standard Alpha calling 
conventions and produce code that will link with the standard
libraries.

    While working on the calling convention part, I ran into
the following problem. In this example procedure:

	int funny(int** p) {
	    if (*p) {
		return **p;
	    }
	    return 3;
	}

the compiler produces code that dereferences **p before the
test of *p. At first I assumed that this was caused by our
changes to the compiler, but I checked it with our baseline
version of Multiflow and it did the same thing.

    I was able to think of a possible explanation for this,
which is that the compiler knows that if the branch is not 
taken then *p will be 0 and if it also knows that address 0
will always be mapped in the address space, then it is alright
to dereference *p without worrying about a segmentation fault.
And if the branch is taken, then *p will be dereferenced 
anyway so it won't hurt to do it before the branch. It turns
out that address 0 is mapped in the 32-bit executables produced
by Multiflow, so executing the load before the branch doesn't
cause any problems in them. However, in 64-bit executables produced
by the Alpha linker, address 0 is not mapped and I don't know how
to force it to be mapped.

    So do you know if this behavior is a bug or a legal
optimization? Thanks for your help.

--
Charlie


-----------------End of Original Message-----------------

Date: Fri, 15 Nov 1996 18:47:41 -0800
From: Charles Garrett <garrett@cs.washington.edu>
To: cutler@equator.com
Subject: Re: Multiflow bug or optimization?

cutler@equator.com wrote:
> 
> Without trying this myself, my quess is that the second load (**p) is a
> dismissible load (i.e., speculative load).  Probably the alpha compiler
> just emits this as a normal (rather than dismissible) load operation.
> 
> Try using the option: -mP3OPT_allow_dismiss=FALSE and see if it still
> happens.  Also, has the branch been eliminated or is the branching
> structure still present?  The optimizer might also be doing this.
> 
> -Ben
> 

Ben,

    Thanks for your response. I looked through the compiler for
related options and learned a few things. The P3OPT_allow_dismiss
option is no longer there, but there are some options which 
determine how the runtime handles exceptions that are raised by
speculative loads. It looks like the alpha version of Multiflow
lets the speculative loads raise a signal and then in the signal
handler they determine if it is ok to continue execution. I
should be able to borrow this code and create a new runtime for
64-bit code.

    It is a relief to know that this behavior is due to a legal
optimization, since I want to touch the trace scheduler as little
as possible. Thanks again for your help.

--
Charlie

Date: Wed, 20 Nov 1996 17:07:26 -0800
From: chambers@klamath (Craig Chambers)
To: grant@thistle.cs.washington.edu
Subject: Re: paper?
Cc: spin-comp@cs

> From grant@thistle.cs.washington.edu  Wed Nov 20 17:03:17 1996
> Delivery-Date: Wed, 20 Nov 1996 17:03:20 PST
> X-Mailer: exmh version 1.5.3 12/28/94
> To: chambers@klamath (Craig Chambers)
> Subject: Re: paper? 
> Mime-Version: 1.0
> Content-Type> : > text/plain> ; > charset="us-ascii"> 
> Date: Wed, 20 Nov 1996 17:03:11 PST
> From: Brian Grant <grant@thistle.cs.washington.edu>
> 
> >> We need to send the paper electronically to France tomorrow morning, 
> >> so that Charles gets it sometime Thursday afternoon.
> >> How can this happen?  Is this going to happen?
> 
> Well, we agreed to send it whatever we could get together, so something will
> be sent.
> 
> Would you like a hardcopy to read tonight?  When are you leaving?  We're just
> about to paste a second draft together.  We didn't think the first draft
> was suitable for reviewing.
> 
> --Brian
> 
> 
We're never obligated to send in a paper, just because we asked for an
extension.  Or are you saying that we all internally agreed to send something?
I don't want to send something that's not good.

I'm leaving around 6.  Please get me a 2-sided hardcopy to read tonight.

Tomorrow at our (quick) meeting we'll do a thumbs-up/-down decision and do some
fast email if that's what's decided.

-- Craig

To: spin-comp@thistle.cs.washington.edu
Subject: paper sent out
Date: Thu, 21 Nov 1996 21:03:47 PST
From: Brian Grant <grant@thistle.cs.washington.edu>

The final version is ~grant/Misc/rtcg/pepm97/paper.submitted.ps.

--Brian and Markus


Date: Tue, 7 Jan 1997 11:35:15 -0800
From: chambers@klamath (Craig Chambers)
To: spin-comp@cs
Subject: Tempo paper

Here's a recent paper from Consel.

----- Begin Included Message -----

....

I enclosed a paper we wrote on run-time specialization. Unlike the
POPL paper which were limited to a small language and only focused on
semantic and correctness aspects, this one talks about the
implementation details of our approach. Plus, it gives experimental
results of the run-time specializer on a series of programs
(scientific and graphics). Interestingly, we compare execution time of
run-time specialized code to compile-time specialized one. This is
interesting because the latter strategy gives us the "ideal" speedup
since a convential compiler treats the specialized program and has
unlimited time to optimize it. We found that run-time specialized code
achieves on average 80% of the speedup obtained by compile-time
specialization. This indicates that the specialized code is rather
good quality. Also, amortization is pretty low between 3 and 87. We
would very much like to get your feedback on this paper. Maybe Susan
would be interested to take a look as well.

Best regards,

Charles

----------------------------------------------------------------------------
Charles Consel              | University of Rennes / Irisa 
 consel@irisa.fr            | Campus Universitaire de Beaulieu
 Phone: (33) 02 99 84 74 10 | 35042 Rennes Cedex
 Fax:   (33) 02 99 84 71 71 | France
----------------------------------------------------------------------------
  URL: http://www.irisa.fr/EXTERNE/projet/lande/consel/consel.html & index.html
----------------------------------------------------------------------------


%!PS-Adobe-2.0
%%Creator: dvipsk 5.55a Copyright 1986, 1994 Radical Eye Software
%%Title: paper.dvi
%%Pages: 19
%%PageOrder: Ascend
%%BoundingBox: 0 0 596 842
%%EndComments
%DVIPSCommandLine: /usr/local/lib/texmf/bin/sunos4.1/dvips -o paper.ps
%+ paper.dvi
%DVIPSParameters: dpi=300, compressed, comments removed
%DVIPSSource:  TeX output 1996.12.11:0947
%%BeginProcSet: texc.pro
/TeXDict 250 dict def TeXDict begin /N{def}def /B{bind def}N /S{exch}N
/X{S N}B /TR{translate}N /isls false N /vsize 11 72 mul N /hsize 8.5 72
mul N /landplus90{false}def /@rigin{isls{[0 landplus90{1 -1}{-1 1}
ifelse 0 0 0]concat}if 72 Resolution div 72 VResolution div neg scale
isls{landplus90{VResolution 72 div vsize mul 0 exch}{Resolution -72 div
hsize mul 0}ifelse TR}if Resolution VResolution vsize -72 div 1 add mul
TR matrix currentmatrix dup dup 4 get round 4 exch put dup dup 5 get
round 5 exch put setmatrix}N /@landscape{/isls true N}B /@manualfeed{
statusdict /manualfeed true put}B /@copies{/#copies X}B /FMat[1 0 0 -1 0
0]N /FBB[0 0 0 0]N /nn 0 N /IE 0 N /ctr 0 N /df-tail{/nn 8 dict N nn
begin /FontType 3 N /FontMatrix fntrx N /FontBBox FBB N string /base X
array /BitMaps X /BuildChar{CharBuilder}N /Encoding IE N end dup{/foo
setfont}2 array copy cvx N load 0 nn put /ctr 0 N[}B /df{/sf 1 N /fntrx
FMat N df-tail}B /dfs{div /sf X /fntrx[sf 0 0 sf neg 0 0]N df-tail}B /E{
pop nn dup definefont setfont}B /ch-width{ch-data dup length 5 sub get}
B /ch-height{ch-data dup length 4 sub get}B /ch-xoff{128 ch-data dup
length 3 sub get sub}B /ch-yoff{ch-data dup length 2 sub get 127 sub}B
/ch-dx{ch-data dup length 1 sub get}B /ch-image{ch-data dup type
/stringtype ne{ctr get /ctr ctr 1 add N}if}B /id 0 N /rw 0 N /rc 0 N /gp
0 N /cp 0 N /G 0 N /sf 0 N /CharBuilder{save 3 1 roll S dup /base get 2
index get S /BitMaps get S get /ch-data X pop /ctr 0 N ch-dx 0 ch-xoff
ch-yoff ch-height sub ch-xoff ch-width add ch-yoff setcachedevice
ch-width ch-height true[1 0 0 -1 -.1 ch-xoff sub ch-yoff .1 add]/id
ch-image N /rw ch-width 7 add 8 idiv string N /rc 0 N /gp 0 N /cp 0 N{
rc 0 ne{rc 1 sub /rc X rw}{G}ifelse}imagemask restore}B /G{{id gp get
/gp gp 1 add N dup 18 mod S 18 idiv pl S get exec}loop}B /adv{cp add /cp
X}B /chg{rw cp id gp 4 index getinterval putinterval dup gp add /gp X
adv}B /nd{/cp 0 N rw exit}B /lsh{rw cp 2 copy get dup 0 eq{pop 1}{dup
255 eq{pop 254}{dup dup add 255 and S 1 and or}ifelse}ifelse put 1 adv}
B /rsh{rw cp 2 copy get dup 0 eq{pop 128}{dup 255 eq{pop 127}{dup 2 idiv
S 128 and or}ifelse}ifelse put 1 adv}B /clr{rw cp 2 index string
putinterval adv}B /set{rw cp fillstr 0 4 index getinterval putinterval
adv}B /fillstr 18 string 0 1 17{2 copy 255 put pop}for N /pl[{adv 1 chg}
{adv 1 chg nd}{1 add chg}{1 add chg nd}{adv lsh}{adv lsh nd}{adv rsh}{
adv rsh nd}{1 add adv}{/rc X nd}{1 add set}{1 add clr}{adv 2 chg}{adv 2
chg nd}{pop nd}]dup{bind pop}forall N /D{/cc X dup type /stringtype ne{]
}if nn /base get cc ctr put nn /BitMaps get S ctr S sf 1 ne{dup dup
length 1 sub dup 2 index S get sf div put}if put /ctr ctr 1 add N}B /I{
cc 1 add D}B /bop{userdict /bop-hook known{bop-hook}if /SI save N @rigin
0 0 moveto /V matrix currentmatrix dup 1 get dup mul exch 0 get dup mul
add .99 lt{/QV}{/RV}ifelse load def pop pop}N /eop{SI restore showpage
userdict /eop-hook known{eop-hook}if}N /@start{userdict /start-hook
known{start-hook}if pop /VResolution X /Resolution X 1000 div /DVImag X
/IE 256 array N 0 1 255{IE S 1 string dup 0 3 index put cvn put}for
65781.76 div /vsize X 65781.76 div /hsize X}N /p{show}N /RMat[1 0 0 -1 0
0]N /BDot 260 string N /rulex 0 N /ruley 0 N /v{/ruley X /rulex X V}B /V
{}B /RV statusdict begin /product where{pop product dup length 7 ge{0 7
getinterval dup(Display)eq exch 0 4 getinterval(NeXT)eq or}{pop false}
ifelse}{false}ifelse end{{gsave TR -.1 -.1 TR 1 1 scale rulex ruley
false RMat{BDot}imagemask grestore}}{{gsave TR -.1 -.1 TR rulex ruley
scale 1 1 false RMat{BDot}imagemask grestore}}ifelse B /QV{gsave
transform round exch round exch itransform moveto rulex 0 rlineto 0
ruley neg rlineto rulex neg 0 rlineto fill grestore}B /a{moveto}B /delta
0 N /tail{dup /delta X 0 rmoveto}B /M{S p delta add tail}B /b{S p tail}
B /c{-4 M}B /d{-3 M}B /e{-2 M}B /f{-1 M}B /g{0 M}B /h{1 M}B /i{2 M}B /j{
3 M}B /k{4 M}B /w{0 rmoveto}B /l{p -4 w}B /m{p -3 w}B /n{p -2 w}B /o{p
-1 w}B /q{p 1 w}B /r{p 2 w}B /s{p 3 w}B /t{p 4 w}B /x{0 S rmoveto}B /y{
3 2 roll p a}B /bos{/SS save N}B /eos{SS restore}B end
%%EndProcSet
TeXDict begin 39158280 55380996 1000 300 300 (paper.dvi)
@start /Fa 2 104 df<EB1F80EB7C00EA01F05B1203AD5B1207001FC7FC12FC121FEA07
C012037FAD12017FEA007CEB1F8011297D9E18>102 D<12FC121FEA07C012037FAD1201
7FEA007CEB1F80EB7C00EA01F05B1203AD5B1207001FC7FC12FC11297D9E18>I
E /Fb 3 122 df<137C130C1318A41330EA07B0EA0C701210EA30601260A3EAC0C013C8
A21241EA62D0EA3C700E147E9311>100 D<EA31E0EA5A70124CEA9C60EA98001218A25A
A45AA20C0D7F8C0F>114 D<EA3818124CA2EA8C3012981218A2EA3060A313E0EA11C012
0E1200138012E1EAE3001246123C0D137F8C11>121 D E /Fc 1
4 df<1203A4EAE31CEA7338EA1FE0EA0780A2EA1FE0EA7338EAE31CEA0300A40E107E90
13>3 D E /Fd 2 61 df<126012F0A2126004047D830B>58 D<140E143C14F0EB03C0EB
0F00133C13F0EA03C0000FC7FC123C12F0A2123C120FEA03C0EA00F0133C130FEB03C0EB
00F0143C140E17167D931E>60 D E /Fe 4 104 df<1230127812F0126005047D830B>
46 D<EB7C4038018280EA03011206A2000C1300A290C7FC120EEA0FC0EA07F86C7EEA00
7C130EA213061220485AA2EA60085BEAD860EA87C012177D9614>83
D<1207EA1880EA30401260EA4080EAFF0012C0A35AEAC0401380EA4300123C0A0E7B8D10
>101 D<EA01C8EA02381206EA0C1813301218A3EA3060A3EA10E0EA19C0120E1200A2EA
618012E1EAC300127C0D147E8D10>103 D E /Ff 5 55 df<121FEA3180EA60C0EA4040
EAC060A8EA4040EA60C0EA3180EA1F000B107F8F0F>48 D<120C123C12CC120CACEAFF80
09107E8F0F>I<121FEA6180EA40C0EA806012C01200A213C0EA0180EA030012065AEA10
201220EA7FC012FF0B107F8F0F>I<121FEA2180EA60C0A2120013801201EA0F00EA0080
1340136012C0A2EA8040EA6080EA1F000B107F8F0F>I<EA0780EA1840EA30C012601300
5A12CFEAF080EAE040EAC060A31240EA60C0EA3080EA1F000B107F8F0F>54
D E /Fg 6 117 df<0007B512803800E003EC0100A3EA01C0A21440A248485A138113FF
1381D80701C7FCA390C8FC120EA45AEAFFC019177F9616>70 D<3907FE1FF83900E00380
A43901C00700A43803800EA2EBFFFEEB800E48485AA4000E5BA4485B38FF83FE1D177F96
1D>72 D<EA07FEEA00E0A4EA01C0A4EA0380A4EA0700A4120EA45AEAFFC00F177E960F>
I<EB3E10EBC1A0380100E0000213601206481340A2000E1300120FEA07E013FCEA01FEEA
003FEB07801303A2EA200138400300A2EA60061304EAD818EA87E014177E9615>83
D<EA383CEA44C6EA47021246EA8E06120CA25B1218144013181480EA3008EB0F00120E7F
8D15>110 D<1203A21206A4EAFFC0EA0C00A35AA45A1380A2EA3100A2121E0A147F930D>
116 D E /Fh 4 52 df<120FEA30C0EA6060A2EA4020EAC030A9EA4020EA6060A2EA30C0
EA0F000C137E9211>48 D<120C121C12EC120CAFEAFFC00A137D9211>I<121FEA60C013
60EAF07013301260EA0070A2136013C012011380EA02005AEA08101210EA2020EA7FE012
FF0C137E9211>I<EA0FC0EA3070EA7038A31200133013E0EA0FC0EA007013381318131C
126012F01318EAE038EA6070EA1FC00E137F9211>I E /Fi 12 122
df<126012F0A2126004047C830C>58 D<EC0380EC0F00143C14F0EB03C0010FC7FC133C
13F0EA03C0000FC8FC123C12F0A2123C120FEA03C0EA00F0133C130FEB03C0EB00F0143C
140FEC038019187D9520>60 D<12E01278121EEA0780EA01E0EA0078131EEB0780EB01E0
EB0078141EEC0780A2EC1E001478EB01E0EB0780011EC7FC1378EA01E0EA0780001EC8FC
127812E019187D9520>62 D<48B512F038003C00013813301520A35BA214101500495AA2
1460EBFFE03801C040A448485A91C7FCA348C8FCA45AEAFFF01C1C7E9B1B>70
D<3A01FFC3FF803A003C00780001381370A4495BA449485AA390B5FC3901C00380A44848
48C7FCA43807000EA448131E39FFE1FFC0211C7E9B23>72 D<3803FFC038003C001338A4
5BA45BA4485AA4485AA448C7FCA45AEAFFF0121C7E9B12>I<EB0FC1EB3033EBC00E3801
800613005A00061304A2140012077FEA03F013FFC613C0EB3FE0EB03F0130014701430A2
12201420006013601440148038700100EACC06EA83F8181C7E9B19>83
D<EA0FC01201A2485AA448C7FCA4EA0E3E13C3380F0380120E121E121CA338380700A313
0E00701320A2131C144038E00C8038600700131D7E9C18>104 D<EA381F384E61803846
81C0EA4701128F128E120EA2381C0380A3EB070000381310A2130E142038700640383003
8014127E9119>110 D<13C01201A3EA0380A4EAFFF0EA0700A3120EA45AA4EA3820A213
40A2EA1880EA0F000C1A80990F>116 D<380787803808C8403810F0C03820F1E0EBE3C0
3840E1803800E000A2485AA43863808012F3EB810012E5EA84C6EA787813127E9118>
120 D<001C13C0EA27011247A238870380A2120EA2381C0700A4EA180EA3EA1C1EEA0C3C
EA07DCEA001C1318EA6038EAF0305B485AEA4180003EC7FC121A7E9114>I
E /Fj 74 123 df<EB3FC03801F0303803C0380007137CEA0F80A2143891C7FCA4B512FC
A2380F807CAE397FE1FF80A2191D809C1B>12 D<EB3FFC3801F07CEA03C01207EA0F80A7
B512FCA2380F807CAE397FF3FF80A2191D809C1B>I<EA781EEAFC3FA200FE1380A2EA7A
1EEA0200A238040100A2EA0802A2EA300CEA4010110E7E9C19>34
D<903801C070A3010313F04A5AA3EB0781EC01C0A3EB0F03B71280A326003C0FC7FCEB38
0EA5EB781EB71280A32601E078C7FCEBC070A3000313F0495AA3EA0781EB01C0A321257D
9C28>I<133C13E3EA01C100037F1381120713C101C3C7FC13C213C413C83903F001FF13
E0EC00306D1360000114C0487E3904FC0180001CEB0300EA387E38783F06EB1F8C00F813
D8EB0FF0D8FC071306387C01F8397E07FE1C391FFE3FF83907F007F0201D7E9C25>38
D<13201340EA0180120313001206120E5AA2123C1238A21278A312F85AA97E1278A31238
A2123C121CA27E12067E13801201EA004013200B297C9E13>40 D<7E1240123012381218
7E120E7EA213801203A213C0A313E01201A9120313C0A31380A212071300A2120E120C5A
1238123012405A0B297D9E13>I<EA01C0487E6C5AEA41C138F1C780EAF9CFEAFDDF383E
BE00EA07F0A2EA3EBE38FDDF80EAF9CFEAF1C73841C100EA01C0487E6C5A11127D9E18>
I<EB0380AEB612FCA33900038000AE1E1F7D9925>I<127812FCA212FEA2127A1202A212
04A21208A212301240070E7D850D>I<EAFFE0A40B047F8A10>I<127812FCA4127806067D
850D>I<EB0180130313071400A25B130EA2131E131CA2133C133813781370A213F05BA2
12015B12035BA2120790C7FCA25A120E121E121CA2123C1238A212781270A212F05AA211
297D9E18>I<EA03F8EA0F1EEA1C07003C1380EA3803007813C0A300F813E0AC007813C0
A200381380EA3C07001C1300EA0F1EEA03F8131B7E9A18>I<1360EA01E0120F12FF12F3
1203B3A2387FFF80A2111B7D9A18>I<EA07F8EA1FFE38383F8038780FC0EAFC0714E013
03A21278EA000714C0A2EB0F80EB1F00131E13385B5B38018060EA03001206000813E038
1FFFC05A5AB5FCA2131B7E9A18>I<EA03F8EA1FFEEA3C1FEB0F80387C07C0127E127C12
3838000F80A2EB1E005BEA03F8EA001EEB0F80EB07C0A214E01230127812FCA214C03878
0F80EB1F00EA1FFEEA07F8131B7E9A18>I<EB018013031307130F131F133F136F13CF13
8F1201EA030F1206120C12181230126012C0B512F8A238000F80A63801FFF8A2151B7F9A
18>I<38180180381FFF005B5B5B13C00018C7FCA4EA19F8EA1E0E38180F80EA10070000
13C014E0A3127812F8A214C012F038600F8038381F00EA1FFEEA07F0131B7E9A18>I<13
7EEA03FF38078180380F03C0EA1E07123CEB038048C7FCA212F813F8EAFB0E38FA0780EA
FC0314C000F813E0A41278A214C0123CEB0780381E0F00EA07FEEA03F8131B7E9A18>I<
1260387FFFE0A214C01480A238E00300EAC0065B5BC65AA25B13E0A212015B1203A41207
A66C5A131C7D9B18>I<EA03F8EA0FFE381E0F80EA3807EB03C01278A2127E387F8380EB
C700EA3FFE6C5A6C7E3807FF80121D38387FC038781FE0EAF00713031301A3007813C0EB
0380EA3E07381FFE00EA03F8131B7E9A18>I<EA03F8EA0FFEEA1E0F383C07801278EB03
C012F8A214E0A4EA78071238EA3C0BEA0E1BEA03E3EA000314C0A2EA3807007C13801400
EA780FEA383CEA1FF8EA0FE0131B7E9A18>I<127812FCA412781200A6127812FCA41278
06127D910D>I<127812FCA412781200A6127012F812FCA3127C1204A21208A312101220
1240061A7D910D>I<B612FCA3C9FCA7B612FCA31E0D7D9025>61
D<EB0380A2497EA3497EA2497E131BA2EB31F8A2EB61FC1360EBE0FEEBC07EA248487E90
B5FC481480EB001FA20006EB0FC0A2000E14E0000C130739FFC07FFEA21F1C7E9B24>65
D<B512F814FF390FC01F80EC0FC0140715E0A515C0EC0F80EC3F00EBFFFE9038C00F80EC
07C015E0140315F0A5EC07E0A2EC1FC0B6120014FC1C1C7E9B22>I<90381FE0209038FF
F8E03803F80F3807C003380F800148C7FC123E1560127E127C00FC1400A8007C1460127E
123E15C07E390F8001803907C003003803F80E3800FFFCEB1FE01B1C7D9B22>I<B512F8
14FF390FC01FC0EC07E0EC01F015F8140015FC157CA2157EA8157CA315F8A2EC01F0EC07
E0EC1FC0B6120014F81F1C7E9B25>I<B6FCA2380FC01F1407801580A2EBC181A3EC8000
13C313FFA213C313C1A21560A29038C000E015C0A21401A21403EC0F80B6FCA21B1C7E9B
1F>I<90380FF00890387FFE383901FC07F83807E001390F80007848C7FC481438123E00
7E1418127C00FC1400A6EC7FFFA2007CEB01F8127E123E123F7EEA0F80EA07E03801FC07
39007FFE7890380FF818201C7D9B26>71 D<39FFFC3FFFA2390FC003F0AA90B5FCA2EBC0
03AC39FFFC3FFFA2201C7E9B25>I<B5FCA2EA07E0B3A6B5FCA2101C7F9B12>I<B5FCA2EA
0FC0AF1403A31407A21406140E141E147EB512FEA2181C7E9B1D>76
D<D8FFC0EB03FF6D5B000F15F0D80DF0130DA3D80CF81319A2017C1331A26D1361A26D13
C1A390380F8181A2903807C301A2EB03E6A2EB01FCA3EB00F8A23AFFC0701FFFA2281C7E
9B2D>I<39FFE003FFA2390FF000307FEA0DFCEA0CFE137E7FEB1F8014C0EB0FE0EB07F0
1303EB01F814FCEB00FE147F143FEC1FB015F0140F1407140314011400A2D8FFC0137015
30201C7E9B25>I<EB3FE03801F07C3803C01E390F800F80391F0007C0001E1303003E14
E0007E14F0007C1301A200FC14F8A8007C14F0007E1303A2003E14E0003F13076C14C039
0F800F803903C01E003801F07C38003FE01D1C7D9B24>I<B512F814FE390FC03F80140F
EC07C015E0A515C0A2EC0F80EC3F00EBFFFC01C0C7FCABEAFFFCA21B1C7E9B21>I<B512
F014FE380FC03FEC0F806E7E81A55D4A5A023EC7FCEBFFF0EBC07C80143F6E7EA6ED8180
A2EC0FC13AFFFC07C300EC01FE211C7E9B24>82 D<3807F820381FFEE0EA3C07EA7801EA
700012F01460A26C130012FEEAFFE0EA7FFE6C7E1480000F13C06C13E0EA007FEB03F013
01130012C0A214E07E38F001C0EAFC0338EFFF00EA83FC141C7D9B1B>I<007FB512E0A2
38781F81007013800060146000E0147000C01430A400001400B03807FFFEA21C1C7E9B21
>I<3AFFFC01FF80A23A0FC00018006C6C5BA26D1370000314606D13E000015C7F000049
5AA2D97E03C7FCA2EB7F07EB3F06148EEB1F8C14CCEB0FD8A2EB07F0A36D5AA26D5AA221
1C7F9B24>86 D<397FFE1FFEA23907F001803803F8036C6C48C7FC000013066D5AEB7F1C
6D5A14B0EB1FE0130FA26D7E6D7E1307497EEB0CFEEB187EEB387F496C7EEB601F01C07F
00016D7E496C7EEA03003AFFF03FFF80A2211C7F9B24>88 D<387FFFFCA2387E01F8EA78
03007013F038E007E0A238C00FC0131F148038003F005B137E5BA2485A0003130613F0EA
07E0120FEBC00EEA1F80141CEA3F0048133C007E13FCB5FCA2171C7D9B1D>90
D<12FEA312E0B3B112FEA307297C9E0D>I<EA0401EA1806EA2008A2485AA2485AA2EABC
2F38FE3F80A2EA7E1FA2383C0F00110E7B9C19>I<12FEA3120EB3B112FEA307297F9E0D>
I<EA0FF8EA1C1E383E0F80130714C0121C1200137FEA07E7EA1F07123C127C12F8A3EA78
0B383E13F8EA0FE115127F9117>97 D<B4FCA2121FA9EB3F80EBE1E0EB8070EB0078143C
A2143EA6143CA21478EB8070381EC1E0381C3F00171D7F9C1B>I<EA03FCEA0E0EEA1C1F
123C1278130E00F8C7FCA61278EB0180123C381C0300EA0E0EEA03F811127E9115>I<EB
0FF0A21301A9EA01F9EA0F07EA1C03EA3C011278A212F8A61278A2123CEA1C03380F0FFE
EA03F9171D7E9C1B>I<EA01FCEA0F07381C0380383C01C0127814E012F8A2B5FC00F8C7
FCA31278007C1360123C6C13C0380F03803801FC0013127F9116>I<137F3801E3803803
C7C0EA0787120FEB8380EB8000A5EAFFF8A2EA0F80AEEA7FF8A2121D809C0F>I<3803F8
F0380E0F38121E381C0730003C1380A4001C1300EA1E0FEA0E0EEA1BF80010C7FC1218A2
EA1FFF14C06C13E04813F0387801F838F00078A300701370007813F0381E03C03807FF00
151B7F9118>I<B4FCA2121FA9EB0FC0EB31E0EB40F0EB80F8A21300AB38FFE7FFA2181D
7F9C1B>I<121E123FA4121EC7FCA6B4FCA2121FAEEAFFE0A20B1E7F9D0E>I<137813FCA4
13781300A6EA03FCA2EA007CB2127012F8137813F0EA70E0EA1F800E26839D0F>I<B4FC
A2121FA9EB0FF8A2EB0380EB0700130C5B137013F87F13BC133E7F7F1480EB07C0EB03E0
38FFC7FCA2161D7F9C19>I<B4FCA2121FB3A7EAFFE0A20B1D7F9C0E>I<39FF0FC07E9038
31E18F3A1F40F20780D980FC13C0A2EB00F8AB3AFFE7FF3FF8A225127F9128>I<38FF0F
C0EB31E0381F40F0EB80F8A21300AB38FFE7FFA218127F911B>I<EA01FC380F0780381C
01C0003C13E0387800F0A200F813F8A6007813F0A2383C01E0381E03C0380F07803801FC
0015127F9118>I<38FF3F80EBE1E0381F80F0EB0078147C143C143EA6143C147C1478EB
80F0EBC1E0EB3F0090C7FCA6EAFFE0A2171A7F911B>I<3803F060380F0CE0EA1E07EA3C
03127C127812F8A61278127C123CEA1C07EA0E0FEA03F3EA0003A6EB1FFCA2161A7E9119
>I<EAFE3E1347381E8F80A3381F070090C7FCAAEAFFF0A211127F9114>I<EA1FD8EA3078
EA601812E0A2EAF000EAFF80EA7FE013F0EA1FF8EA07FCEA007CEAC01CA212E01318EAF8
30EACFC00E127E9113>I<1203A45AA25AA2EA3FFC12FFEA1F00A9130CA4EA0F08EA0798
EA03F00E1A7F9913>I<38FF07F8A2EA1F00AC1301120F380786FFEA01F818127F911B>I<
38FFC1FCA2381F0060EB80E0000F13C013C03807C180A23803E300A2EA01F6A213FE6C5A
A21378A2133016127F9119>I<39FF8FF8FEA2391F03E030A201831370000FEBF0601386
D807C613C0EBCEF8EBEC790003EB7D80EBF83D0001EB3F00A2497E0000131EEBE00EA21F
127F9122>I<38FFC7FCA2381F8180EA0F833807C700EA03EEEA01FC5B1200137C13FEEA
01DFEA039F38070F80380607C0380C03E038FF07FCA216127F9119>I<38FFC1FCA2381F
0060EB80E0000F13C013C03807C180A23803E300A2EA01F713F6EA00FE5BA21378A21330
A21370EA706012F85BEAF9800073C7FC123E161A7F9119>I<383FFF80383C1F00EA303F
133E485A13FC5BEA01F01203485AEBC180EA0F81121F1303003E1300EA7E07EA7C0FB5FC
11127F9115>I E /Fk 44 123 df<EA03C0487E120FEA1EF0EA1C70A3EBF7E013E7121D
381FC7006C5A130E121FEA3F1EEA7F9CEAF3BCEAE3F812E1EBF1C012E0EAF1F9EA7FFF38
3F9F80381F0F0013197F9816>38 D<13E01201EA07C013005A121E5A123812781270A312
F05AA77E1270A312781238123C7E7E7E13C0EA01E012000B217A9C16>40
D<12E07E127C121C121E7EEA0780120313C01201A313E01200A7120113C0A31203138012
07EA0F00121E121C127C12F05A0B217C9C16>I<EA01C0A4EA71C738F9CF80387FFF00EA
1FFCEA07F0A2EA1FFCEA7FFF38F9CF803871C700EA01C0A411127E9516>I<EA01C0A8B5
1280A33801C000A811137E9516>I<1238127C127EA2123E120E121E123C127C12F81260
070B798416>I<B51280A311037E8D16>I<EA03E0EA0FF8487EEA1E3CEA380EEA780FEA70
07A238E00380A8EAF00700701300A2EA780FEA3C1E6C5AEA1FFC6C5AEA03E011197E9816
>48 D<EA018012031207A2121F127F12FF12731203AEEA7FF813FC13F80E197C9816>I<
EA07E0EA1FF8EA7FFEEA783FEAF00FEB07801303A21200A2130714005B131E5B5B5BEA03
E0EA078048C7FC381E0380123CEA7FFFB5FC7E11197E9816>I<EA07E0EA1FFCEA7FFEEA
781F7F7F12005BA2133EEA07FC5B7FEA001E130714801303A212F013071400EAF81FEA7F
FE6C5AEA07E011197E9816>I<127012F8A312701200A8127012F8A312700512789116>
58 D<1238127CA312381200A81238127CA3123C121C123C123812F812F0126006187991
16>I<EB03801307131FEB3E0013FCEA03F0485AEA1F80003EC7FC12FC12F012FC123E6C
7EEA07E06C7EEA00FC133EEB1F801307130311157E9616>I<EA7FFFB51280A2C8FCA5B5
1280A26C1300110B7E9116>I<EA7FF8EAFFFE6C7EEA1C0FEB0780EB03C01301A214E013
00A8EB01C0A21303EB0780130F387FFF00485AEA7FF81319809816>68
D<387F1FC038FFBFE0387F1FC0381C0700A7EA1FFFA3EA1C07A9387F1FC038FFBFE0387F
1FC013197F9816>72 D<EA1FFC487E487EEA780F38F00780EAE003AEEAF007A238780F00
EA7FFF6C5A6C5A11197E9816>79 D<EA07E3EA1FFF127FEA781F487E487EA290C7FC7E12
78EA7F80EA1FF0EA07FCC67E130FEB07801303A212E0A2EAF00738F80F00EAFFFE5BEAC7
F011197E9816>83 D<EAFFF0A3EAE000B3A8EAFFF0A30C20789C16>91
D<EAFFF0A3EA0070B3A8EAFFF0A30C207F9C16>93 D<120C121E123C1278127012F012E0
A312F012F812781230070D789B16>96 D<EA1FE0EA7FF87FEA783CEA301EEA000EA2EA03
FE121FEA7E0E12F012E0A2EAF01EEAF83E387FFFE0EA3FE7EA0F8313127E9116>I<127E
12FE127E120EA4133EEBFF80000F13C0EB83E01301380E00F0A21470A414F0000F13E013
01EB83C013FF000E1300EA063C1419809816>I<EA03F8EA0FFE121FEA3C1EEA780CEA70
0012F05AA47EEA70071278EA3E0FEA1FFEEA0FFCEA03F010127D9116>I<133F5B7F1307
A4EA03C7EA0FF7EA3FFFEA3C1F487E487EA212E0A412F05BEA781FEA7C3F383FFFE0381F
F7F03807C7E014197F9816>I<EA07E0EA0FF8EA1FFCEA3C3EEA780EEA700FEAF007B5FC
A3EAE0007EEA70071278EA3E1FEA1FFEEA0FFCEA03F010127D9116>I<131FEB7F8013FF
EA01E7EBC30013C0A2EA7FFFB5FCA2EA01C0ACEA3FFE487E6C5A11197F9816>I<3803E3
C0380FFFE05A381E3CC0383C1E00EA380EA3EA3C1E6C5AEA1FFC5BEA3BE00038C7FCA2EA
1FFC13FF4813C0EA780338F001E0EAE000A3EAF001387C07C0383FFF80380FFE00EA03F8
131C7F9116>I<127E12FE127E120EA4133C13FF000F138013871303A2120EA9387FC7F0
38FFE7F8387FC7F01519809816>I<EA0180EA03C0A2EA0180C7FCA4EA7FC0A31201ACEA
7FFFB5FC7E101A7D9916>I<EAFFC0A31201B3B51280A311197E9816>108
D<38F9C38038FFEFC0EBFFE0EA3E7CEA3C78EA3870AA38FE7CF8A31512809116>I<EA7E
3CEAFEFF007F1380EA0F871303A2120EA9387FC7F038FFE7F8387FC7F01512809116>I<
EA03E0EA0FF8487EEA3C1E487EEA700738E00380A5EAF00700701300EA780FEA3C1EEA1F
FC6C5AEA03E011127E9116>I<EA7E3E38FEFF80007F13C0380F83E01301380E00F0A214
70A414F0000F13E01301EB83C013FF000E1300133C90C7FCA6EA7FC0487E6C5A141B8091
16>I<38FF0FC0EB3FE0137F3807F040EBE0005B5BA290C7FCA7EAFFFCA313127F9116>
114 D<EA0FECEA3FFC127FEAF03CEAE01CA2EAF000EA7F80EA1FF0EA07FCEA003EEAE00E
A212F0EAF81EEAFFFC13F8EAC7E00F127D9116>I<12035AA4EA7FFFB5FCA20007C7FCA7
5BEB0380A2130713873803FF005BEA00F811177F9616>I<387E1F80EAFE3FEA7E1FEA0E
03AA1307EA0F0FEBFFF06C13F83803E3F01512809116>I<387F1FC000FF13E0007F13C0
381C0700EA1E0FEA0E0EA36C5AA4EA03B8A3EA01F0A26C5A13127F9116>I<387F1FC013
3F131F380F1C00EA073CEA03B813F012016C5A12017FEA03B8EA073C131CEA0E0E387F1F
C038FF3FE0387F1FC013127F9116>120 D<387F1FC038FF9FE0387F1FC0381C0700120E
130EA212075BA2EA039CA21398EA01B8A2EA00F0A35BA3485A1279127BEA7F806CC7FC12
3C131B7F9116>I<383FFFC05AA238700780EB0F00131EC65A13F8485A485A485A48C7FC
381E01C0123C1278B5FCA312127F9116>I E /Fl 8 119 df<380FFF80380180C0146038
030030A21410A200061330A3142048136014C01480EB0300EA1806EAFFF814117E9019>
68 D<EA01F9EA0607EA0803EA1002A213001218EA0F80EA03F0EA00381308A21240A213
10EAE060EA9F8010117D9013>83 D<12781218A25AA31237EA78C0EA60401360A2EAC0C0
A3EA4180EA6300123C0B117E900E>98 D<13781318A21330A31207EA18E0EA30601260A2
EAC0C0A213C81241EA62D0EA3C700D117E9010>100 D<EA0780EA184012301260EA7F80
EAC000A3EA4020EA20C0EA1F000B0B7E8A0F>I<1204120C1200A5127012581298A21230
A212601264A21268123006127E910B>105 D<EA73C0EA9C20EA9860130012185AA45AA2
0B0B7E8A0E>114 D<EA38601248EA8C2012981218EA3040A31380EA1100120E0B0B7E8A
10>118 D E /Fm 4 104 df<5CEC0080A215401520B612FCA2C8122015401580A2EC0100
1E0C7E8D23>33 D<1460A28080A2B512FE80C7EA0180EC00F0153C1570EC01C0EC0380B5
EAFE005CC712185CA25CA21E147E9123>41 D<137813C0EA0180EA0300AB12065A12F012
0C7E7EABEA0180EA00C013780D217E9812>102 D<12F0120C7E7EABEA0180EA00C01378
13C0EA0180EA0300AB12065A12F00D217E9812>I E /Fn 45 123
df<EA01801207EA0F00121E5A12381278127012F05AA77E127012781238123C7E7EEA07
80120109197B9612>40 D<12C012F012787E7E120E120F7E13801203A7120713005A120E
121E5A5A5A12C009197D9612>I<1207A3EAE738EAFFF8EA7FF0EA1FC0A2EA7FF0EAFFF8
EAE738EA0700A30D0E7E9012>I<EA0380A6EAFFFEA3EA0380A60F0F7F9112>I<1230127C
A2123C120C121C123812F012E006097A8312>I<126012F0A212600404798312>46
D<131813381378137013F013E0A2120113C01203138012071300A25A120E121E121C123C
1238A21278127012F05AA20D1A7E9612>I<EA07C0EA0FE0EA1C70EA3838EA701CA2EAE0
0EA7131EEA701CA2EA3838EA1C70EA0FE0EA07C00F147F9312>I<12035A5A5AB4FC12F7
1207ACEA7FF0A20C147E9312>I<EA0F80EA3FE0EA70F0EAF078EAE038A2124012001378
137013F0EA01E0EA03C0EA0780EA0F00121EEA38381270EAFFF8A20D147E9312>I<EA0F
E0EA3FF0EA783CEA701CA21200133C1378EA07F0A2EA003C131C130EA212E0A2131CEAF8
3CEA3FF0EA0FC00F147F9312>I<13F01201EA0370A21206120E120C121C1238A2127012
E0EAFFFEA2EA0070A4EA03FEA20F147F9312>I<EA7FF0A2EA7000A6EA7F8013E0EA60F0
EA00781338124012E0A21370EA70F0EA3FC0EA1F000D147E9312>I<EA07C0EA1FF0EA3C
78EA783CEA701CA3EA3838EA0FE0EA07C0EA3C78EA701CEAE00EA4EA701CEA783CEA1FF0
EA0FE00F147F9312>56 D<EA07C0EA1FF0EA7878EA703CEAE01C131EA312F0EA783EEA3F
FEEA0FCEEA000E131E131CEA703C1378EA78F0EA3FE0EA0F800F147F9312>I<12301278
A212301200A612301278A2123812181238123012F012C005137A8D12>59
D<1310133813F8EA01F0EA03E0EA0F80EA1F00123E12F85A7E123E7EEA0F80EA03E0EA01
F0EA00F8133813100D137E9312>I<EAFFFEA3C7FCA3EAFFFEA30F097F8E12>I<124012E0
12F8127C7EEA0F80EA07C0EA03E0EA00F8137813F8EA03E0EA07C0EA0F80EA3E005A5A12
E012400D137E9312>I<EAFFC013F0EA38781338131CA2131E130EA7131CA213381378EA
FFF013C00F147F9312>68 D<EA1F30EA3FF0127012E01370A2EAF000A2127FEA3FE0EA0F
F012001378133812E0A2EAF0781370EAFFE0EACF800D147E9312>83
D<EAFFC0A2EAE000B3A4EAFFC0A20A1A7A9612>91 D<EAFFC0A21201B3A412FFA20A1A7F
9612>93 D<EA3F80EA7FE0EA70F0EA20701200EA0FF0123FEA787012F012E0A2EAF0F0EA
7FFEEA1F3E0F0E7E8D12>97 D<12FCA2121CA4EA1DF0EA1FF8131EEA1E0EEA1C0F1307A4
130FEA1E0EEA1F1C13F8EA1DE01014809312>I<EA07F0EA1FF8EA3838EA7010EAF0005A
A47EEA7038EA3878EA1FF0EA07E00D0E7E8D12>I<EA01F8A2EA0038A4EA07B8EA1FF8EA
38781270EAF03812E0A412F0EA7078EA78F8EA1FFFEA0FBF10147F9312>I<EA0780EA1F
E0EA38F0EA7078EAF03812E0EAFFF8A2EAE0007EEA7038EA3878EA1FF0EA07C00D0E7E8D
12>I<137EEA01FFEA03C713821380A2EAFFFEA2EA0380AAEA7FFCA21014809312>I<EA0F
9EEA1FFFEA38E7EA7070A4EA38E0EA3FC0EA7F80EA7000EA3FE013F8EA7FFCEAF01EEAE0
0EA3EAF01EEA783CEA3FF8EA0FE010167F8D12>I<12FCA2121CA413F0EA1FF8131C121E
121CA838FF9F80A21114809312>I<1206120FA21206C7FCA3B4FCA21207AAEAFFF8A20D
157D9412>I<12FCA2121CA4EA1FFFA2EA1C785BEA1DE0EA1FC07FA2EA1EF0EA1C787FA2
38FF3F80A21114809312>107 D<EAFF80A21203B0EAFFFEA20F147F9312>I<EAFB8EB512
80EA3EFBEA3CF3EA38E3A838FEFBE0A2130E818D12>I<EAFCF0B47EEA1F1C121E121CA8
38FF9F80A2110E808D12>I<EA0F80EA3FE01238EA7070EAE038A5EAF078EA7070EA38E0
123FEA0F800D0E7E8D12>I<EAFDF0EAFFF8EA1F1EEA1E0EEA1C0F1307A4130FEA1E0EEA
1F1C13F8EA1DE0EA1C00A5EAFF80A21015808D12>I<EAFE7C13FEEA0FCE13841300120E
A7EAFFF0A20F0E7F8D12>114 D<EA1FF0127FEAE07012C0EAE000B4FCEA3FE0EA0FF0EA
0078EAE018A2EAF038EAFFF0EADFC00D0E7E8D12>I<120EA4EAFFF8A2EA0E00A71338A2
1378EA07F0EA03C00D127F9112>I<EAFCFCA2EA1C1CA9133C380FFF80EA07DF110E808D
12>I<EAFEFEA2EA3838EA3C78EA1C70A3EA0EE0A3EA06C01207A2EA03800F0E7F8D12>I<
EAFEFEA2EA701CA2EA3018EA3838EA3BB8EA3FF8A2EA3AB81238EA1CF0A30F0E7F8D12>
I<EA7FFCA2EA70381370EA00E0EA01C0EA0380EA0700120EEA1C1C12381270EAFFFCA20E
0E7F8D12>122 D E /Fo 68 125 df<903801FDC0EB070F130C011C138014031338A2EC
0700A313703807FFFE3800700EA3495AA45CEA01C0A31471A2EA038014721432141C91C7
FC90C8FC5A120612C612E412CC12701A25819C18>13 D<903901FC0FEE9039070E307E01
0C136091380CE07C90391C00C01C140113381638A2EC0380A20003B612F03A0070038070
A2EC070016E013E0A391380E01C0A2EA01C0A2ED0388141CA20180149000031401ED00E0
4A13001300A248133038C63060EAE63838CC3180D8781FC8FC2725819C25>15
D<1218123CA31204A21208A21210122012401280060C779C0D>39
D<13031306130813181330136013C0A2EA0180EA0300A21206A25AA2121C1218A2123812
30A21270A21260A412E0A51260A51220123012107EA2102A7B9E11>I<1310A21308130C
13041306A51307A51306A4130EA2130CA2131C1318A213381330A21360A213C0A2EA0180
EA0300A212065A5A121012605A102A809E11>I<13305BA338184180383C4700EA0ECEEA
07B8EA01E0485AEA0EF0EA39B8EA711EEAC10C0003C7FCA312061112799E15>I<EB01C0
5CA3130391C7FCA35B1306A3B612C0A2D8000CC7FCA2131C1318A313381330A313701360
1A1A7B9620>I<12181238127812381208A21210A212201240A21280050C7D830D>I<EAFF
C0A30A037D890F>I<1230127812F0126005047C830D>I<14031407140E140C141C141814
381430147014E014C013011480130314005B1306130E5B1318133813301370136013E05B
1201485A90C7FC5A1206120E120C121C121812385A126012E05AA218297F9E15>I<137C
13C6EA0303A21206120E120C121CA2EA18071238A3EA700EA4EA601C12E0131813381330
A2EA606013C0EA3180EA1E00101B7B9A15>I<13021304130C131C137CEA03B8EA0038A3
1370A413E0A4EA01C0A4EA0380A41207EAFFF00F1B7C9A15>I<137C1386EA0103380201
80EA044114C01208A338108380A238110700EA0E06C65A5B5B13C048C7FC12061208485A
EA2002A2EA7E0CEA47FCEA83F8EA80F0121B7C9A15>I<EB01801303A4EB0700A2130613
0EA2130C131C1318133813305BA213C6138EEA010E1203EA061C120C1208123FEA60F8EA
803FEA0038A25BA45B136011237E9A15>52 D<EB80603801FFC014005B90C7FC1202A45A
13F8EA070CEA040EEA08061200A3130EA21270130CEAE01CEA40185B5B6C5A001FC7FC13
1B7C9A15>I<131FEB708013C1EA0183EA03030006C7FC120E120C121CA2EA39F0EA3A18
EA3C0C1278A21270A2EA601C12E0A213181338EA60305B5BEA3180001FC7FC111B7B9A15
>I<137C13C6EA03031207120EA2121CA213071238A3130FEA180E131EEA0C6EEA078CEA
001CA2133813301370EAE06013C0EA8180EA8300127C101B7B9A15>57
D<1203EA0780A2EA0300C7FCAA12181238127812381208A25AA25A5AA25A091A7D910D>
59 D<000FB512E04814F0C9FCA8B612806C14001C0C7C8F20>61
D<1418A214381478A214B8A2EB0138A213021304A2497EA21310133013201340EB7FFCEB
801CA2EA01001202A248131E000C130E001C131EB4EBFFC01A1C7E9B1F>65
D<3801FFFE39003C078090383803C01401A313701403A2EC078001E01300140E143CEBFF
F83801C01C80140FA2EA0380A43807001E141C143C5C380E01E0B512801A1C7D9B1D>I<
903803F02090381C0C6090387002C0EBE00338018001EA0700EC0080120E121E5A15005A
A35AA41404A300705B5C7E001813606C1380D80703C7FCEA01FC1B1C7A9B1E>I<3801FF
FE39003C078090383801C0A2EC00E0A24913F01570A215F05BA43901C001E0A315C03803
80031580140715003807000E5C5C5C380E01C0B5C7FC1C1C7D9B1F>I<48B512E038003C
00013813601540A35BA214201500495AA214C013FF3801C080A43803810113801402A248
485AA2140C5C000E1378B55A1B1C7D9B1C>I<903803F02090381C0C6090387002C0EBE0
0338018001EA0700EC0080120E121E5A15005AA35AA2903801FFC09038001E00141CA312
705C7E12186C13F838070310EA01FC1B1C7A9B20>71 D<3801FFC038003C001338A45BA4
5BA4485AA4485AA448C7FCA45AEAFFE0121C7E9B10>73 D<3801FFE038003C001338A45B
A45BA4485AA438038008A31410EA07001430146014E0380E03C0B5FC151C7D9B1A>76
D<D801FEEB07F8D8003E1480012EEB0F001517A21527014E132E154EA2158E90388E011C
A21402A23901070438A21408141000025C1420A2144000045C14801400120C381C060139
FF861FFC251C7D9B25>I<3901FC03FE39001C0070013C1360012E1340A301471380A3EB
43809038838100A2138114C1380101C2A2EB00E2A2000213E41474A3481338A3000C1318
001C1310EAFF801F1C7D9B1F>I<EB07F0EB1C1CEB700E3801C0073903800380EA07005A
000E14C05A123CA25AA348EB0780A3EC0F00A2141E141C0070133C5C0078137000385B38
1C0380D80E0FC7FCEA03F81A1C7A9B20>I<3801FFFC38003C079038380380EC01C0A3EB
7003A31580EBE0071500140E14383801FFE001C0C7FCA3485AA448C8FCA45AEAFFE01A1C
7D9B1C>I<3801FFF838003C0EEB3807EC0380A3EB7007A3EC0F00EBE00E5C1470EBFFC0
EA01C014601470A2EA0380A4380700F01540A2158048EB790038FFE01E1A1C7D9B1E>82
D<EB1F84EB604CEBC03838018018EA0300A200061310A214001207A213E0EA03FC6CB4FC
38007F80EB07C013011300A31220A23860018014005BEA7006EACC18EA83F0161C7D9B17
>I<001FB512C0381C070138300E0000201480126012405B1280A2000014005BA45BA45B
A4485AA41203EA7FFE1A1C799B1E>I<397FF0FF80390F001C00000E13181410A3485BA4
485BA4485BA44848C7FCA31302A25BEA60086C5AEA1860EA0F80191C779B1F>I<39FF80
3FC0391C000F0014045CA25CA25C5C121E000E5B130191C7FC1302A25B130C1308EA0F10
12075B5BA25BA290C8FC1206A21A1C779B1F>I<3AFF83FF0FF03A3C007001C000381580
02F013001502EB0170001C5C13025D13045D13085D01105BA201205B13400271C7FC1380
1472EA1D001474121E1438121C143012181420241C779B29>I<3901FF81FE39001E00F0
011C1360011E1380EB0E011500EB0F026D5A5C1490EB03A014C01301A28013021304497E
EB10701320EB60381340EB803C3801001C12020006131E121E39FF80FFC01F1C7E9B1F>
I<EB3F80EB7F001360A35BA4485AA448C7FCA41206A45AA45AA45AA45AA45AA212FEA211
297E9E0D>91 D<EB3F80EB7F001303A31306A45BA45BA45BA45BA45BA4485AA448C7FCA4
1206A212FEA21129819E0D>93 D<EA03CCEA063C120CEA181CEA383812301270A2EAE070
A413E212C0A2EA61E4EA6264EA3C380F127B9115>97 D<123F1207A2120EA45AA4EA39C0
EA3E60EA3830A2EA7038A4EAE070A3136013E0EAC0C012C1EA6180EA6300123C0D1D7B9C
13>I<EA01F0EA0708120CEA181CEA3838EA30001270A25AA513081310EA6020EA30C0EA
1F000E127B9113>I<EB1F801303A2EB0700A4130EA4EA03DCEA063C120CEA181CEA3838
12301270A2485AA413E212C0A2EA61E4EA6264EA3C38111D7B9C15>I<EA01E0EA071012
0CEA1808EA381012701360EA7F80EAE000A51308EA60101320EA30C0EA1F000D127B9113
>I<EB03C0EB0670130CEB1C601400A25BA53803FF8038007000A55BA5485AA5485AA390
C7FCA25A12C612E65A12781425819C0D>I<13F3EA018FEA030FEA0607EA0E0E120C121C
A2EA381CA413381230A2EA187813F0EA0F701200A213E0A2EAC0C012E1EAC300127E101A
7D9113>I<EA0FC01201A2485AA448C7FCA4EA0E78138CEA0F0E120E121CA4485AA35B00
701380A21370EB7100EAE032EA601C111D7D9C15>I<EA01801203EA0100C7FCA7121C12
261247A2128EA2120E5AA35AA21271A31272A2123C091C7C9B0D>I<1306130E13061300
A713F0EA01181202A2EA0438A21200A21370A413E0A4EA01C0A4EA0380A2EAC30012E712
CE12780F24819B0D>I<EA0FC01201A2485AA448C7FCA4EA0E0F1311EB23801343381C83
001380001DC7FC121EEA3F80EA39C0EA38E0A2EA70E2A313E4EAE064EA6038111D7D9C13
>I<EA1F801203A2EA0700A4120EA45AA45AA45AA412E4A412681238091D7C9C0B>I<393C
1E078039266318C0394683A0E0384703C0008E1380A2120EA2391C0701C0A3EC0380D838
0E1388A2EC0708151039701C032039300C01C01D127C9122>I<EA3C3CEA2646EA4687EA
4707128EA2120EA2EA1C0EA35B00381340A21338148038701900EA300E12127C9117>I<
EA01E0EA0718EA0C0C12181238EA300E1270A2EAE01CA31318133813301360EA60C0EA31
80EA1E000F127B9115>I<EA07873804D9803808E0C0A23811C0E0A21201A2380381C0A3
1480EA070314005B1306EA0E8C137090C7FCA25AA4123CB47E131A7F9115>I<EA3C3CEA
26C2EA4687EA4707EA8E061300120EA25AA45AA45A123010127C9112>114
D<EA01F0EA0608120C131CEA1818EA1C00121F13C0EA0FF01207EA00781338EA603012E0
12C0EA8060EA60C0EA1F000E127D9111>I<13C01201A3EA0380A4EAFFE0EA0700A3120E
A45AA4EA3840A31380EA1900120E0B1A7D990E>I<EA1E03EA27071247A2EA870EA2120E
A2485AA438383880A21218EB3900EA1C59EA078E11127C9116>I<EA1E06EA270E124713
06EA8702A2120EA2EA1C04A3130812181238EA18101320EA0C40EA07800F127C9113>I<
381E0183382703871247148338870701A2120EA2381C0E02A31404EA180C131C1408001C
1310380C26303807C3C018127C911C>I<EA070EEA19913810E38012203841C30013C012
01A2485AA4EA07021267EAE70412CBEA8B08EA70F011127D9113>I<EA1E03EA27071247
A2EA870EA2120EA2EA1C1CA4EA3838A21218A2EA1C70EA07F0EA0070A213E0EAE0C012E1
EA8180EA4700123C101A7C9114>I<EA0382EA07C2EA0FECEA0838EA1008EA0010132013
401380EA010012025AEA08081210EA3830EA67F0EA43E0EA81C00F127D9111>I<B512C0
12017C8B15>I<B712F825017B8B2A>I E /Fp 43 123 df<EAFFFCA40E047F8C13>45
D<1238127C12FEA3127C123807077C8610>I<13181378EA01F812FFA21201B3A7387FFF
E0A213207C9F1C>49 D<EA03FCEA0FFF383C1FC0387007E0007C13F0EAFE0314F8A21301
127CEA3803120014F0A2EB07E014C0EB0F80EB1F00133E13385BEBE018EA01C0EA0380EA
0700000E1338380FFFF05A5A5AB5FCA215207D9F1C>I<13FE3807FFC0380F07E0381E03
F0123FEB81F8A3EA1F0314F0120014E0EB07C0EB1F803801FE007F380007C0EB01F014F8
EB00FCA2003C13FE127EB4FCA314FCEA7E01007813F8381E07F0380FFFC03801FE001720
7E9F1C>I<14E013011303A21307130F131FA21337137713E7EA01C71387EA0307120712
0E120C12181238127012E0B512FEA2380007E0A7EBFFFEA217207E9F1C>I<0010132038
1E01E0381FFFC0148014005B13F8EA1BC00018C7FCA4EA19FCEA1FFF381E0FC0381807E0
1303000013F0A214F8A21238127C12FEA200FC13F0A2387007E0003013C0381C1F80380F
FF00EA03F815207D9F1C>I<1238127C12FEA3127C12381200A81238127C12FEA3127C12
3807167C9510>58 D<1470A214F8A3497EA2497EA3EB06FF80010E7FEB0C3FA201187F14
1F01387FEB300FA201607F140701E07F90B5FCA239018001FCA200038090C7FCA2000614
7FA23AFFE00FFFF8A225227EA12A>65 D<D903FE138090381FFF819038FF01E33901F800
3FD803E0131F4848130F48481307121F48C71203A2481401127EA200FE91C7FCA8127EED
0180127F7E15036C6C1400120F6C6C1306D803F05B6C6C13386CB413F090381FFFC0D903
FEC7FC21227DA128>67 D<B67E15F03907F003FCEC007E81ED1F80ED0FC0ED07E0A216F0
1503A316F8A916F0A3ED07E0A2ED0FC0ED1F80ED3F00157EEC03FCB612F0158025227EA1
2B>I<B612FCA23807F000153C151C150C150EA215061418A3150014381478EBFFF8A2EB
F07814381418A21503A214001506A3150EA2151E153EEC01FCB6FCA220227EA125>I<B6
12F8A23807F001EC007815381518151CA2150CA21418A21500A214381478EBFFF8A2EBF0
7814381418A491C7FCA8B512E0A21E227EA123>I<B512E0A2D807F0C7FCB31518A41538
A21570A215F014011407B6FCA21D227EA122>76 D<EB07FC90383FFF809038FC07E03903
F001F848486C7E4848137E48487FA248C7EA1F80A24815C0007E140FA200FE15E0A9007E
15C0007F141FA26C15806D133F001F15006C6C137E6C6C5B6C6C485A3900FC07E090383F
FF80D907FCC7FC23227DA12A>79 D<B6FC15E03907F007F0EC01FC1400157EA2157FA515
7EA215FC1401EC07F090B512E0150001F0C7FCADB57EA220227EA126>I<B512FEECFFC0
3907F007F0EC01F86E7E157E157FA6157E5D4A5AEC07F090B512C05D9038F00FE06E7E6E
7E6E7EA81606EC00FEEDFF0CB538803FF8ED0FF027227EA12A>82
D<3801FC043807FF8C381F03FC383C007C007C133C0078131CA200F8130CA27E1400B4FC
13E06CB4FC14C06C13F06C13F86C13FC000313FEEA003FEB03FFEB007F143FA200C0131F
A36C131EA26C133C12FCB413F838C7FFE00080138018227DA11F>I<007FB61280A2397E
03F80F00781407007014030060140100E015C0A200C01400A400001500B3A20003B512F8
A222227EA127>I<EA07FC381FFF80383F07C0EB03E0130114F0121E1200A2133FEA03FD
EA1FC1EA3F01127E12FCA4EA7E02EB0CF8381FF87F3807E03F18167E951B>97
D<B4FCA2121FABEB0FE0EB3FF8EBF07CEB801EEB001FEC0F80A215C0A81580141F018013
00EBC03E381EE07C381C3FF838180FC01A237EA21F>I<EBFF80000713E0380F83F0EA1F
03123E127E387C01E090C7FC12FCA6127C127EA2003E13306C1360380FC0E03807FF8038
00FE0014167E9519>I<EB01FEA2EB003EABEA01FC3807FFBE380F81FE381F007E003E13
3E127E127C12FCA8127CA26C137E001E13FE380F83BE3907FF3FC0EA01FC1A237EA21F>
I<13FE3807FF80380F87C0381E01E0003E13F0EA7C0014F812FCA2B5FCA200FCC7FCA312
7CA2127E003E13186C1330380FC0703803FFC0C6130015167E951A>I<EB3F80EBFFC038
01E3E0EA03C71207EA0F87EB83C0EB8000A6EAFFFCA2EA0F80B2EA7FF8A213237FA211>
I<3803FC1E380FFF7F381F0F8F383E07CF383C03C0007C13E0A5003C13C0EA3E07381F0F
80EBFF00EA13FC0030C7FCA21238383FFF806C13F06C13F84813FCEA380048133E00F013
1EA40078133C007C137C383F01F8380FFFE00001130018217E951C>I<B4FCA2121FABEB
07E0EB1FF8EB307CEB403CEB803EA21300AE39FFE1FFC0A21A237EA21F>I<121C123F5A
A37E121CC7FCA7B4FCA2121FB2EAFFE0A20B247EA310>I<1338137C13FEA3137C133813
00A7EA03FEA2EA003EB3A5127812FC133C137CEA78F8EA7FE0EA1F800F2E83A311>I<B4
FCA2121FABECFF80A2EC38001460495A495A49C7FC130E5B137E13FF13CFEB0F806D7E6D
7E1301806D7E147C143C39FFE0FFC0A21A237EA21E>I<B4FCA2121FB3ADEAFFE0A20B23
7EA210>I<3AFF07F007F090391FFC1FFC3A1F303E303E01401340496C487EA201001300
AE3BFFE0FFE0FFE0A22B167E9530>I<38FF07E0EB1FF8381F307CEB403CEB803EA21300
AE39FFE1FFC0A21A167E951F>I<13FE3807FFC0380F83E0381E00F0003E13F848137CA3
00FC137EA7007C137CA26C13F8381F01F0380F83E03807FFC03800FE0017167E951C>I<
38FF0FE0EB3FF8381FF07CEB803E497E1580A2EC0FC0A8EC1F80A29038803F00EBC03EEB
E0FCEB3FF8EB0FC090C8FCA8EAFFE0A21A207E951F>I<EAFE1FEB3FC0381E67E013C713
87A2381F83C090C7FCADEAFFF0A213167E9517>114 D<EA0FF3EA3FFFEA781FEA6007EA
E003A212F000FCC7FCEA7FE013F8EA3FFEEA0FFF120138000F80EAC007130312E0A238F0
0700EAFC0EEAEFFCEAC7F011167E9516>I<487EA41203A21207A2120F123FB5FCA2EA0F
80ABEB8180A5EB8300EA07C3EA03FEEA00F811207F9F16>I<38FF01FEA2381F003EAF14
7E14FE380F81BE3907FF3FC0EA01FC1A167E951F>I<39FFE01FE0A2390F800600A2EBC0
0E0007130CEBE01C00031318A26C6C5AA26C6C5AA2EB7CC0A2137F6D5AA26DC7FCA2130E
A21B167F951E>I<3AFFE7FF07F8A23A1F007800C0D80F80EB0180147CA23A07C07E0300
14DE01E05B0003EBDF06EBE18FD801F15B01F3138C9038FB079C000014D8EBFE03017E13
F0A2EB7C01013C5BEB380001185B25167F9528>I<39FFE01FE0A2390F800600A2EBC00E
0007130CEBE01C00031318A26C6C5AA26C6C5AA2EB7CC0A2137F6D5AA26DC7FCA2130EA2
130CA25B1278EAFC3813305BEA69C0EA7F80001FC8FC1B207F951E>121
D<387FFFF0A2387C03E0387007C0EA600F38E01F8000C01300133E137EC65A5B485A0003
1330EA07E013C0380F8070121F383F0060003E13E0EA7C03B5FCA214167E9519>I
E /Fq 5 104 df<B61280A219027D8A20>0 D<00C013606C13E0387001C038380380381C
0700EA0E0E6C5AEA03B8EA01F06C5AA2487EEA03B8EA071CEA0E0E487E38380380387001
C038E000E048136013147A9320>2 D<EA07E0EA1FF8EA3FFCEA7FFEA2B5FCA6EA7FFEA2
EA3FFCEA1FF8EA07E010107E9115>15 D<133C13E0EA01C013801203AD13005A121C12F0
121C12077E1380AD120113C0EA00E0133C0E297D9E15>102 D<12F0121C12077E1380AD
120113C0EA00E0133C13E0EA01C013801203AD13005A121C12F00E297D9E15>I
E /Fr 53 122 df<EA60C0EAF1E0A21270EA1020A2EA2040A2EA4080A20B0A7F9612>34
D<120112021204120C1218A21230A212701260A312E0AA1260A312701230A21218A2120C
12041202120108227D980E>40 D<12801240122012301218A2120CA2120E1206A31207AA
1206A3120E120CA21218A2123012201240128008227E980E>I<126012F0A212701210A2
1220A21240A2040A7D830A>44 D<EAFF80A2090280870C>I<126012F0A2126004047D83
0A>I<1318A213381330A213701360A213E013C012011380A212031300A25A1206A2120E
120CA2121C121812381230A212701260A212E05AA20D217E9812>I<EA07C0EA1830EA30
18EA701CEA600CA2EAE00EA9EA600CA2EA701CEA3018EA1C70EA07C00F157F9412>I<12
035AB4FC1207B1EA7FF00C157E9412>I<EA0F80EA30E0EA4070EA8030EAC03812E01240
12001370A2136013C0EA0180EA03001206EA0C081208EA1018EA3FF0127F12FF0D157E94
12>I<EA0FE0EA3030EA6018EA701CA21200131813381360EA07E0EA00301318130C130E
A212E0A2EAC00CEA4018EA3030EA0FE00F157F9412>I<1330A2137013F0120113701202
12041208121812101220124012C0EAFFFEEA0070A5EA03FE0F157F9412>I<EA2030EA3F
E013C0EA24001220A4EA2F80EA30E0EA2070EA00301338A2124012E0A2EA8030EA4060EA
20C0EA1F000D157E9412>I<EA01F0EA0608EA080CEA181C1230EA7000126012E0EAE3E0
EAEC30EAF018130CEAE00EA31260A2EA300C1318EA1830EA07C00F157F9412>I<1240EA
7FFE13FC13F8EAC008EA80101320EA00401380A2EA0100A25A12021206A2120EA512040F
167E9512>I<EA07E0EA1830EA2018EA600CA21270EA7818EA3E10EA1F60EA0FC013F0EA
18F8EA607C131EEAC00E1306A21304EA600CEA3830EA0FE00F157F9412>I<EA07C0EA18
30EA30181260EAE00CA2130EA3EA601E1230EA186EEA0F8EEA000E130C131CEA7018A2EA
6030EA20C0EA1F800F157F9412>I<126012F0A212601200A6126012F0A212701210A212
20A21240A204147D8D0A>59 D<B512FCA2C8FCA6B512FCA2160A7E8C1B>61
D<13101338A3135CA3138EA3EA0107A200031380EA0203A23807FFC0EA0401A2380800E0
A21218003813F038FE03FE17177F961A>65 D<EBFC1038038330380E00B0481370481330
123000701310126012E01400A51410126012700030132012386C13406C138038038300EA
00FC14177E9619>67 D<B512E0EA1C00146014201410A3EB0400A3130CEA1FFCEA1C0C13
041408A2130014181410A2143014F0B5FC15177F9618>69 D<B512E0EA1C001460142014
10A3EB0400A3130CEA1FFCEA1C0C1304A390C7FCA6EAFFC014177F9617>I<EAFFE0EA0E
00B3A3EAFFE00B177F960D>73 D<00FC13FE001E1338001F13101217EA1380EA11C0A2EA
10E013701338A2131C130E130F1307EB0390EB01D0A2EB00F014701430123800FE131017
177F961A>78 D<EAFFFE381C0380EB00C014601470A4146014C0EB0380381FFE00001CC7
FCAAB47E14177F9618>80 D<EAFFFC381C0380EB00C014E01470A414E014C0EB0380381F
FE00381C0780EB01C0EB00E0A514E1A2147238FF803C18177F961A>82
D<EA0FC4EA302CEA601CEA400CEAC004A3EAE0001270127FEA3FE0EA0FF8EA01FCEA001C
130E13061280A3EAC004EAE008EAD810EA87E00F177E9614>I<387FFFF8386038180040
1308A200801304A300001300AF3807FFC016177F9619>I<B5128038F0070012C0130EEA
801E131C5BEA007813705BA2485A485AA2380700805A120EEA1C01003C13001238485A13
0FB5FC11177E9616>90 D<EA2040A2EA4080A2EA8100A2EAE1C0EAF1E0A2EA60C00B0A7B
9612>92 D<EA1FC0EA38601330EA10381200EA03F8EA1E3812301270EAE039A21379EA70
FFEA1F1E100E7F8D12>97 D<12FC121CA813F8EA1F06EA1C031480130114C0A414801303
1400EA1B0EEA10F81217809614>I<EA07F0EA18381230EA7010EA600012E0A41260EA70
081230EA1830EA07C00D0E7F8D10>I<137E130EA8EA07CEEA1C3EEA300E1270126012E0
A412601270EA301EEA182E3807CFC012177F9614>I<EA0FC0EA1860EA3030EA7038EAE0
18EAFFF8EAE000A31260EA7008EA3010EA1830EA07C00D0E7F8D10>I<EA03E0EA067012
0EEA1C201300A5EAFF80EA1C00ACEAFF800C1780960B>I<EA0F9EEA18E3EA3060EA7070
A3EA3060EA18C0EA2F80EA20001260EA3FE013F813FCEA600EEAC006A3EA600CEA3838EA
0FE010157F8D12>I<12FC121CA8137CEA1D8EEA1E07121CAA38FF9FE01317809614>I<12
18123CA212181200A5127C121CAC12FF081780960A>I<12FC121CB3A3EAFF8009178096
0A>108 D<38FC7C1F391D8E6380391E0781C0001C1301AA39FF9FE7F81D0E808D1E>I<EA
FC7CEA1D8EEA1E07121CAA38FF9FE0130E808D14>I<EA07C0EA1830EA3018EA600CA2EA
E00EA5EA701CEA3018EA1830EA07C00F0E7F8D12>I<EAFCF8EA1F0EEA1C031480130114
C0A414801303EB0700EA1F0EEA1CF890C7FCA5B47E1214808D14>I<EAFCF0EA1D38121E
EA1C101300A9EAFF800D0E808D0E>114 D<EA1F40EA60C0EAC040A2EAE000B4FCEA7F80
EA1FC0EA01E0EA8060A212C0EAE0C0EA9F000B0E7F8D0E>I<1208A31218A21238EAFF80
EA3800A71340A4EA1C80EA0F000A147F930E>I<EAFC3FEA1C07AA5BEA0E173803E7E013
0E808D14>I<EAFE1FEA3C0E130CEA1C08A2EA0E10A2EA0720A2EA03C0A3EA0180A2100E
7F8D13>I<38FCFE7C383838381410381C3C20A2134C380E4E40A2138638078780A21303
00031300A2160E7F8D19>I<EAFE3FEA3C18EA1C10EA0E20EA074013C0EA0380EA01C0EA
02E0EA04F0EA0870EA1838EA383CEAFC7F100E7F8D13>I<EAFE1FEA3C0E130CEA1C08A2
EA0E10A2EA0720A2EA03C0A3EA0180A21300A212E2A212A4127810147F8D13>I
E /Fs 1 4 df<120CA2EA8C40EAEDC0EA7F80EA0C00EA7F80EAEDC0EA8C40EA0C00A20A
0B7D8B10>3 D E /Ft 86 128 df<EB7E1F3901C1B180390303E3C0000713C3000EEBC1
80903801C000A6B512FC380E01C0B0387F87FC1A1D809C18>11 D<137E3801C180EA0301
380703C0120EEB018090C7FCA5B512C0EA0E01B0387F87F8151D809C17>I<EB7FC0EA01
C1EA03031207EA0E01A7B5FCEA0E01B0387FCFF8151D809C17>I<90383F07E03901C09C
18380380F0D80701133C000E13E00100131892C7FCA5B612FC390E00E01CB03A7FC7FCFF
80211D809C23>I<90383F07FC3901C0DC1C390381F03CEA0701000EEBE01C1300A6B612
FC390E00E01CB03A7FC7FCFF80211D809C23>I<12FC121CB0EAFF8009127F910C>I<121C
A2123C1238127012C012800607779C15>19 D<EAC0C0EA6180EA3F00120C0A047B9915>
I<EA6060EAF0F0EAF8F8EA6868EA0808A3EA1010A2EA2020EA4040EA80800D0C7F9C15>
34 D<000F14C038188001393060038038703807396027FF0038E01006140E5C14181438
14301470386020E000705BEA30416C485A390F0303C0390007062090380E0C1090380C1C
08EB1C18903838380413301370136013E0EA01C013800003EB18083807001C0006EB0C10
000EEB0620000CEB03C01E217E9E23>37 D<13E0EA0190EA0308A21207A35BA25BA23903
403FE09038800F0014061404EA05C000095B3810E010123038607020137838E038406D5A
130E90380F0020EA700739300D8040391830E180390FC03F001B1D7E9C20>I<126012F0
12F812681208A31210A2122012401280050C7C9C0C>I<13401380EA0100120212065AA2
5AA25AA212701260A312E0AC1260A312701230A27EA27EA27E12027EEA008013400A2A7D
9E10>I<7E12407E7E12187EA27EA27EA213801201A313C0AC1380A312031300A21206A2
5AA25A12105A5A5A0A2A7E9E10>I<1306ADB612E0A2D80006C7FCAD1B1C7E9720>43
D<126012F0A212701210A41220A212401280040C7C830C>I<EAFFE0A20B0280890E>I<12
6012F0A2126004047C830C>I<1303A213071306A2130E130C131C1318A213381330A213
701360A213E013C0A21201138012031300A25A1206A2120E120CA2121C1218A212381230
12701260A212E05AA210297E9E15>I<EA07E0EA0C30EA1818EA300CEA700EEA6006A2EA
E007ADEA6006EA700EA2EA300CEA1818EA0C30EA07E0101B7E9A15>I<12035A123F12C7
1207B3A3EA0F80EAFFF80D1B7C9A15>I<EA07E0EA1838EA201CEA400E12F0EAF80F1307
A21270EA000F130EA2131CA213381370136013C0EA0180EA0300EA0601120C1218EA1002
EA3FFE127F12FF101B7E9A15>I<EA07E0EA1838EA201C1278131E130EEA381E1200131C
A213381360EA07E0EA0038131C131E130E130FA2127012F8A2130EEA701EEA401CEA3038
EA0FE0101B7E9A15>I<130CA2131C133CA2135C139C1201131C12021206120412081210
12301220124012C0B512C038001C00A73801FFC0121B7F9A15>I<EA300CEA3FF813F013
C0EA2000A6EA23E0EA2C38EA301C1220EA000EA2130FA2126012F0A2130E1280EA401CEA
2018EA1870EA07C0101B7E9A15>I<13F0EA030CEA0404EA080EEA181E1230130CEA7000
126012E0EAE3E0EAE438EAE80C12F01306EAE007A41260A21270EA3006130CEA1818EA0C
30EA03E0101B7E9A15>I<1240387FFF801400A2EA4002485AA25B485AA25B5BA213C0A2
485AA21203A41207A66CC7FC111C7E9B15>I<EA07E0EA0838EA100C1220EA6006A31270
EA780CEA3E08EA3F90EA1FE0EA07F013F8EA18FCEA307EEA601E130FEAC0071303A31302
EA6006EA3004EA1818EA07E0101B7E9A15>I<EA07E0EA0C30EA1818EA300C1260EAE00E
1306A21307A4EA600F12301317EA1C27EA07C7EA00071306130E1230EA780C13181270EA
2030EA30E0EA0F80101B7E9A15>I<126012F0A212601200AA126012F0A2126004127C91
0C>I<126012F0A212601200AA126012F0A212701210A41220A212401280041A7C910C>I<
007FB512C0B612E0C9FCA8B612E06C14C01B0C7E8F20>61 D<1306A3130FA3EB1780A2EB
37C01323A2EB43E01341A2EB80F0A338010078EBFFF8EB007800027FA3487FA2000C131F
121E39FF80FFF01C1C7F9B1F>65 D<B512C0380F00F01438143C141C141EA4141C143C14
78EB01F0EBFFE0EB0078143C141E140E140FA5141EA2143C1478B512E0181C7E9B1D>I<
90381FC080EBE0313803800B38070007000E1303481301123C003813001278127000F014
00A80070148012781238003CEB0100121C6C13026C5B6C6C5A3800E030EB1FC0191C7E9B
1E>I<B512C0380F00F0143C140E80A2EC038015C01401A215E0A815C0A2140315801407
1500140E5C1470B512C01B1C7E9B20>I<B512FC380F003C140C1404A214061402A21302
1400A3130613FE13061302A3140113001402A31406A2140C143CB512FC181C7E9B1C>I<
B512F8380F007814181408A2140C1404A213021400A3130613FE13061302A490C7FCA77F
EAFFF8161C7E9B1B>I<90381FC080EBE0313803800B38070007000E1303481301123C00
3813001278127000F01400A6ECFFF0EC0F800070130712781238123C121C7E7E3803800B
3800E031EB1FC01C1C7E9B21>I<39FFF3FFC0390F003C00ACEBFFFCEB003CAD39FFF3FF
C01A1C7E9B1F>I<EAFFF0EA0F00B3A8EAFFF00C1C7F9B0F>I<EA1FFFEA00F81378B31270
12F8A21370EA70F0EA21C0EA1F80101C7F9B15>I<39FFF03FE0390F000F00140C14085C
5C5C5C49C7FC13025B130E131F132FEB27801347EB83C0EB01E0A26D7E80147880A28014
1F158039FFF07FF01C1C7E9B20>I<EAFFF8EA0F8090C7FCB01408A31418A21410143014
70EB01F0B5FC151C7E9B1A>I<B46CEBFF80000FECF800A2390BC00178A33809E002A238
08F004A3EB7808A3EB3C10A3EB1E20A3EB0F40A2EB0780A3EB0300121C3AFF8307FF8021
1C7E9B26>I<B4EB7FC0390F800E001404EA0BC0EA09E0A2EA08F013F81378133CA2131E
130FA2EB078414C41303EB01E4A2EB00F4147CA2143CA2141C140C121C38FF80041A1C7E
9B1F>I<EB3F803801E0F03803803848487E000E7F487F48EB0380A2007814C000701301
00F014E0A80078EB03C0A200381480003C1307001C14006C130E6C5B6C6C5A3801E0F038
003F801B1C7E9B20>I<B51280380F00E01478143C141C141EA5141C143C147814E0EBFF
8090C7FCACEAFFF0171C7E9B1C>I<B5FC380F01E0EB007880141C141EA4141C143C5CEB
01E001FFC7FCEB03C0EB00E0801478A61510A21438EC1C2039FFF007C01C1C7E9B1F>82
D<3807E080EA1C19EA3007EA7003EA6001EAE000A36C1300A2127CEA7FC0EA3FF8EA1FFE
EA07FFC61380130FEB03C0A213011280A300C01380EB030012F0EACC0EEA83F8121C7E9B
17>I<007FB512C038700F010060130000401440A200C014201280A300001400B1497E38
03FFFC1B1C7F9B1E>I<39FFF07FC0390F000E001404B3A26C5BEA03805C6C6C5A380060
C0011FC7FC1A1C7E9B1F>I<39FFE00FF0391F0003C06CEB018015006D5A00071302A26C
6C5AA213E000015BA26C6C5AA3EB7820A2EB7C60EB3C40A26D5AA2131F6DC7FCA21306A3
1C1C7F9B1F>I<3AFFE0FFE0FF3A1F001F003C001E011E13186C011F1310A33A07803F80
201427A2D803C0EBC0401443A2D801E0EBE0801481A2D800F0EBE1009038F100F1A20179
13F2017A137AA2017E137E013C133CA301181318A3281C7F9B2B>I<387FFFF0EA7C0100
7013E0386003C0A238400780130F1400131E12005B137C13785BA2485A1203EBC010EA07
80A2EA0F00481330001E13205A14604813E0EAF803B5FC141C7E9B19>90
D<12FEA212C0B3B312FEA207297C9E0C>I<EA0808EA1010EA2020EA4040A2EA8080A3EA
B0B0EAF8F8EA7878EA30300D0C7A9C15>I<12FEA21206B3B312FEA20729809E0C>I<EA1F
C0EA3070EA78387F12301200A2EA01FCEA0F1C12381270126000E01340A3EA603C38304E
80381F870012127E9115>97 D<12FC121CAA137CEA1D86EA1E03381C018014C0130014E0
A614C013011480381E0300EA1906EA10F8131D7F9C17>I<EA07E0EA0C30EA18781230EA
7030EA600012E0A61260EA70041230EA1808EA0C30EA07C00E127E9112>I<133F1307AA
EA03E7EA0C17EA180F487E1270126012E0A61260127012306C5AEA0C373807C7E0131D7E
9C17>I<EA03E0EA0C30EA1818EA300CEA700EEA600612E0EAFFFEEAE000A41260EA7002
1230EA1804EA0C18EA03E00F127F9112>I<13F8EA018CEA071E1206EA0E0C1300A6EAFF
E0EA0E00B0EA7FE00F1D809C0D>I<3803C380380C3CC0381C388038181800EA381CA4EA
1818EA1C38EA0C30EA13C00010C7FC12307EEA1FF813FF1480EA3003386001C0EAC000A3
3860018038300300EA1C0EEA07F8121B7F9115>I<12FC121CAA137C1387EA1D03001E13
80121CAD38FF9FF0141D7F9C17>I<1218123CA21218C7FCA712FC121CB0EAFF80091D7F
9C0C>I<13C0EA01E0A2EA00C01300A7EA0FE01200B3A21260EAF0C012F1EA6180EA3E00
0B25839C0D>I<12FC121CAAEB3FC0EB0F00130C13085B5B5B13E0121DEA1E70EA1C7813
38133C131C7F130F148038FF9FE0131D7F9C16>I<12FC121CB3A9EAFF80091D7F9C0C>I<
39FC7E07E0391C838838391D019018001EEBE01C001C13C0AD3AFF8FF8FF8021127F9124
>I<EAFC7CEA1C87EA1D03001E1380121CAD38FF9FF014127F9117>I<EA03F0EA0E1CEA18
06487E00701380EA600100E013C0A600601380EA700300301300EA1806EA0E1CEA03F012
127F9115>I<EAFC7CEA1D86EA1E03381C018014C0130014E0A6EB01C0A21480381E0300
EA1D06EA1CF890C7FCA7B47E131A7F9117>I<EA03C1EA0C33EA180BEA300FEA7007A212
E0A612601270EA300F1218EA0C37EA07C7EA0007A7EB3FE0131A7E9116>I<EAFCE0EA1D
30EA1E78A2EA1C301300ACEAFFC00D127F9110>I<EA1F90EA3070EA4030EAC010A212E0
EAF800EA7F80EA3FE0EA0FF0EA00F8EA8038131812C0A2EAE010EAD060EA8FC00D127F91
10>I<1204A4120CA2121C123CEAFFE0EA1C00A91310A5120CEA0E20EA03C00C1A7F9910>
I<38FC1F80EA1C03AD1307120CEA0E1B3803E3F014127F9117>I<38FF07E0383C038038
1C0100A2EA0E02A26C5AA3EA0388A213D8EA01D0A2EA00E0A3134013127F9116>I<39FF
3FCFE0393C0F0380381C07011500130B000E1382A21311000713C4A213203803A0E8A2EB
C06800011370A2EB8030000013201B127F911E>I<387F8FF0380F03801400EA0702EA03
84EA01C813D8EA00F01370137813F8139CEA010E1202EA060738040380381E07C038FF0F
F81512809116>I<38FF07E0383C0380381C0100A2EA0E02A26C5AA3EA0388A213D8EA01
D0A2EA00E0A31340A25BA212F000F1C7FC12F31266123C131A7F9116>I<EA7FFCEA7038
1260EA407013F013E0EA41C012031380EA0700EA0F04120E121CEA3C0CEA380812701338
EAFFF80E127F9112>I<B512F01401808B15>I<EA6060EAF0F0A2EA60600C047C9C15>
127 D E /Fu 44 123 df<B5FCA610067F9016>45 D<130E131E137EEA07FE12FFA212F8
1200B3AB387FFFFEA317277BA622>49 D<EBFF80000713F04813FC381E03FE393800FF80
007C133F00FE14C06C131F15E0140FA2127E003C131FC7FC15C0A2EC3F801500147E5C5C
495A495AEB078049C7FC131E4913E013705B3901C001C0EA0380EA0600000FB5FC5A5A5A
B61280A31B277DA622>I<EB7F803803FFF04813FC380F80FE381F007FEA3F80EC3F80A3
121F1300C7EA7F00A2147E5C495AEB07F0EBFFC0A2EB01F8EB007E801580EC1FC0A215E0
A2123C127EB4FCA215C0143F481480007CEB7F00003F13FE6CB45A000713F0C613801B27
7DA622>I<140E141E143E147E14FEA213011303EB077E130EA2131C1338137013E0A2EA
01C0EA0380EA0700120EA25A5A5A5AB612F8A3C7EAFE00A890387FFFF8A31D277EA622>
I<00181303381F801FEBFFFE5C5C5C14C091C7FC001CC8FCA7EB7FC0381DFFF8381F80FC
381E003F121CC7EA1F8015C0A215E0A21218127C12FEA315C05A0078EB3F80A26CEB7F00
381F01FE6CB45A000313F0C613801B277DA622>I<EB07F8EB3FFE90B5FC3901FC078039
03F00FC03807C01FEA0F80121F130048EB0F8091C7FC127EA3EAFE02EB1FF0EB3FFCEB60
3EEB801F00FF14809038000FC0A24814E0A4127EA4123E003F14C07EEC1F80D80F801300
3807E07E6CB45A6C5B38003FC01B277DA622>I<EC0780A24A7EA34A7EA24A7EA3EC77F8
A2ECF7FC14E3A2903801C1FEA201037F1480A249486C7EA24980010E133FA2496D7EA201
3FB57EA39039700007F8A201F080491303A248486D7EA2000381D8FFFE013F13FCA32E29
7EA833>65 D<B612F815FF16C03A03F8001FE0ED0FF0ED07F8150316FCA21501A3150316
F8A2ED07F0150FED1FC0EDFF8090B5EAFE00EDFFC09039F8000FF0ED03F8ED01FC16FE15
00A216FFA616FE1501ED03FC1507ED1FF8B712E016C0EDFE0028297DA830>I<91387FE0
03903907FFFC07011FEBFF0F90397FF00F9F9039FF0001FFD801FC7F4848147F4848143F
4848141F485A160F485A1607127FA290C9FC5AA97E7F1607123FA26C7E160E6C7E6C6C14
1C6C6C143C6C6C14786CB4EB01F090397FF007C0011FB512800107EBFE009038007FF028
297CA831>I<B612FCEDFF8016E03A03FC001FF8ED03FCED00FE167FEE3F80EE1FC0A2EE
0FE0A2EE07F0A417F8AA17F0A3EE0FE0A217C0161FEE3F80EE7F005EED03FCED1FF8B75A
168003FCC7FC2D297EA834>I<B712E0A33903FC001FED07F01501A215001670A3913801
C0781638A302031300A2140F90B5FCA3EBFC0F1403A20201130EA3161C91C7FCA3163C16
38167816F815011503151FB712F0A327297EA82C>I<B712C0A33903FC003FED0FE01503
1501A21500A316F0913801C070A316001403A2140F90B5FCA3EBFC0F1403A21401A491C8
FCA9B512FCA324297EA82A>I<B512FCA33801FE00B3B1B512FCA316297FA819>73
D<ECFFC0010F13FC90383F807F9039FE001FC0D801F8EB07E048486D7E48486D7E000F81
48486D7EA24848147FA2007F168090C8123FA34816C0AA6C16806D147FA2003F1600A26C
6C14FEA26C6C495A6C6C495A6C6C495A6C6C495A6C6C495A90263FC0FFC7FC90380FFFFC
010013C02A297CA833>79 D<B612F815FF16C03A03FC003FE0ED07F0ED03F816FC150116
FEA716FC150316F8ED07F0ED3FE090B61280EDFE0001FCC8FCB0B512F0A327297EA82E>
I<B612E015FE6F7E3A03FC003FE0ED0FF06F7E6F7E150182A65E4B5A1507ED0FE0ED3FC0
90B500FEC7FCA29039FC00FF80ED3FE06F7E150F821507A8170EA2ED03FC171EB539F001
FE3C9238007FF8EE0FE02F297EA832>82 D<01FF13C0000313E1000F13F9381F80FF383F
003F003E130F481307A200FC1303A214017EA26C90C7FC13C0EA7FFCEBFFE06C13F86C13
FE80000714806C14C0C6FC010F13E0EB007FEC1FF0140F140700E01303A46C14E0A26C13
076C14C0B4EB0F80EBE01F00E3B5120000E113FC38C01FF01C297CA825>I<007FB71280
A39039807F807FD87C00140F00781507A20070150300F016C0A2481501A5C791C7FCB3A4
90B612C0A32A287EA72F>I<B500E0B539E01FFFC0A32803FC0003FCC7EA7000A26D6E14
F0000102015DA26D6E13016C60A26D6C486D485AA26E48EBC007013F023F91C7FCA2DAE0
0F6D5A011FD90E1F130EA26D6C486C6C5AA217F8902707F838075BA2DAFC78EBFC780103
D970031370A2DAFEF0EBFEF00101D9E0015BA26D6C486C6C5AA36E486D5AA36EC76CC8FC
A3021E141EA242297FA845>87 D<3803FF80000F13F0381F01FC383F80FE147F801580EA
1F00C7FCA4EB3FFF3801FC3FEA0FE0EA1F80EA3F00127E5AA4145F007EEBDFC0393F839F
FC381FFE0F3803F8031E1B7E9A21>97 D<EAFFE0A3120FACEBE1FE9038E7FF809038FE07
E09038F803F09038F001F89038E000FCA2157EA2157FA8157EA315FCA29038F001F89038
F803F090389C0FE090380FFF80390E01FC00202A7EA925>I<EB3FF03801FFFC3803F03E
380FC07FEA1F80EA3F00A248133E007E90C7FCA212FEA7127EA2127F6CEB03801380001F
EB0700380FE00E3803F83C3801FFF838003FC0191B7E9A1E>I<EC7FF0A31407ACEB3F87
3801FFF73807F03F380FC00F381F8007EA3F00A2127EA312FEA8127EA27EA2381F800F38
0FC01F3907E07FFF3801FFE738007F87202A7EA925>I<EB3FC03801FFF03807E07C4848
7E48487ED83F001380140F5A007E14C012FE1407A2B6FCA248C8FCA4127E127F6CEB01C0
1380001F1303390FC007803903F01F003800FFFCEB3FE01A1B7E9A1F>I<EB07F8EB3FFC
EB7E3E3801FC7FEA03F813F01207143E1400A7B512C0A33807F000B3A3387FFF80A3182A
7EA915>I<90387F80F03901FFE3F83907C0FE1C390F807C7C381F003E151048EB3F00A6
6C133EA26C6C5A6C6C5A3805FFE0380C7F8048C8FC121CA2121E381FFFF814FF6C14C06C
14E06C14F0120F383E000748EB01F8481300A4007CEB01F0A2003FEB07E0390FC01F806C
B5120038007FF01E287E9A22>I<EAFFE0A3120FAC147E9038E1FF809038E30FC001E413
E0EBE80701F813F013F0A213E0B039FFFE3FFFA3202A7DA925>I<1207EA1FC013E0123F
A3121F13C0EA0700C7FCA7EAFFE0A3120FB3A3EAFFFEA30F2B7EAA12>I<EAFFE0A3120F
ACEC3FF8A3EC0F80EC1F00143E14785CEBE1E0EBE3C013EF13FF8080A2EBF3F8EBC3FCEB
C1FE13C080EC7F80143F15C0EC1FE039FFFC7FFCA31E2A7EA923>107
D<EAFFE0A3120FB3B2EAFFFEA30F2A7EA912>I<26FFC07FEB1FC0903AC1FFC07FF0903A
C307E0C1F8D80FC49038F101FC9039C803F20001D801FE7F01D05BA201E05BB03CFFFE3F
FF8FFFE0A3331B7D9A3A>I<38FFC07E9038C1FF809038C30FC0D80FC413E0EBC80701D8
13F013D0A213E0B039FFFE3FFFA3201B7D9A25>I<EB3FE03801FFFC3803F07E390FC01F
80391F800FC0393F0007E0A2007EEB03F0A300FE14F8A8007E14F0A26CEB07E0A2391F80
0FC0390FC01F803907F07F003801FFFC38003FE01D1B7E9A22>I<38FFE1FE9038E7FF80
9038FE0FE0390FF803F09038F001F801E013FC140015FEA2157FA8157E15FEA215FC1401
01F013F89038F803F09038FC0FE09038EFFF809038E1FC0001E0C7FCA9EAFFFEA320277E
9A25>I<38FFC3E0EBC7F8EBCC7C380FD8FE13D0A213F0EBE07C1400B0B5FCA3171B7E9A
1B>114 D<3803FE30380FFFF0EA3E03EA7800127000F01370A27E00FE1300EAFFE06CB4
FC14C06C13E06C13F0000713F8C6FCEB07FC130000E0137C143C7E14387E6C137038FF01
E038E7FFC000C11300161B7E9A1B>I<1370A413F0A312011203A21207381FFFE0B5FCA2
3807F000AD1470A7000313E03801F8C0EA00FFEB3F0014267FA51A>I<39FFE07FF0A300
0F1307B2140FA2000713173903F067FF3801FFC738007F87201B7D9A25>I<39FFFE07FF
A33907F000E0A2EBF801000314C0A23901FC0380A2EBFE07000014006D5AEB7F0EA2EB3F
9CA214FC6D5AA26D5AA36D5AA26D5AA2201B7F9A23>I<3BFFFC7FFC1FFCA33B0FE00FE0
01C02607F007EB0380A201F8EBF0070003160015F82601FC0F130EA29039FE1FFC1E0000
011C131C15FE9039FF387E3C017F1438EC787F6D486C5AA29138E01FF0011F5CA26D486C
5AA36D486C5AA22E1B7F9A31>I<39FFFC1FFEA33907F00780D803F813006C6C5AEBFE1E
00005BEB7F78EB3FF85C6D5A130F6D7E80130F497EEB3DFEEB38FFEB787F9038F03F80D8
01E013C03903C01FE0EB800F39FFF03FFFA3201B7F9A23>I<39FFFE07FFA33907F000E0
A2EBF801000314C0A23901FC0380A2EBFE07000014006D5AEB7F0EA2EB3F9CA214FC6D5A
A26D5AA213075CA26D5AA25CA21307003890C7FC127CEAFE0EA25B5BEA7C70EA3FE0EA0F
8020277F9A23>I<003FB5FCA21301003C13FE383803FCEA780714F838700FF0EB1FE0A2
38003FC0EB7F80A2EBFF00485A1407EA03FCEA07F8A2380FF00FEA1FE0003F130EEBC01E
387F803E00FF13FE13FFA2181B7E9A1E>I E /Fv 63 128 df<EBFC7C380183C6380707
8E00061304000E1300A6B512F0380E0700AE387F0FF0171A809916>11
D<13FCEA0182EA0703EA0607EA0E0290C7FCA5B5FCEA0E07AE387F0FE0131A809915>I<
12FC121CAEEAFF800910808F0A>16 D<000E130300315B3830800E3860E01E38E05FFCEB
401814385C146014E0EB41C038608180EA3083D83107C7FCEA0E0E38000C0790381C1880
01381340EB3030903870702013E013C01201EA038013005A000EEB3040000C1318001C14
800018EB07001B1E7E9B20>37 D<1380EA010012025A120C120812185AA35AA412E0AA12
60A47EA37E1208120C12047E7EEA008009267D9B0F>40 D<7E12407E7E12181208120C7E
A37EA41380AA1300A41206A35A1208121812105A5A5A09267E9B0F>I<126012F0A21270
1210A31220A212401280040B7D830B>44 D<EAFFC0A20A0280880D>I<126012F0A21260
04047D830B>I<130CA2131C1318A213381330A213701360A213E013C0A212011380A212
0313005A1206A2120E120CA2121C1218A212381230A212701260A212E05AA20E257E9B13
>I<EA0780EA1860EA3030A2EA6018A2EAE01CACEA6018A2EA7038EA3030EA1860EA0780
0E187E9713>I<12035AB4FC1207B3A2EAFFF00C187D9713>I<EA0F80EA1060EA2030EA40
38EA803CEAC01C12E01240EA003C1338A21370136013C0EA018013001202EA0404120812
10EA3008EA3FF8127F12FF0E187E9713>I<EA0F80EA10E0EA2070EA6078EA70381220EA
00781370A2136013C0EA0F80EA00E013701338133CA212E0A212C0EA40381370EA30E0EA
0F800E187E9713>I<1330A2137013F0A2EA0170120312021204120C1208121012301220
124012C0B5FCEA0070A6EA07FF10187F9713>I<EA3018EA3FF013E013C0EA2000A5EA27
C0EA3860EA2030EA00381318131CA2124012E0A2EA8018EA40381330EA30E0EA0F800E18
7E9713>I<EA01E0EA0610EA0C18EA1838123013001270126012E0EAE7C0EAE860EAF030
131812E0131CA31260A2EA701812301330EA1860EA07C00E187E9713>I<1240EA7FFE13
FCA2EA4008EA8010A21320EA0040A213801201A213005AA45AA612020F197E9813>I<EA
0780EA1860EA3030EA20181260A3EA7010EA3C30EA3E60EA0F80EA07C0EA19F0EA30F8EA
6038EA401CEAC00CA4EA6008EA2010EA1860EA0FC00E187E9713>I<EA0780EA1860EA30
301270EA601812E0A2131CA31260133C1230EA185CEA0F9CEA001C1318A21338EA703013
60EA6040EA2180EA1F000E187E9713>I<126012F0A212601200A8126012F0A212600410
7D8F0B>I<B61280A2C9FCA6B61280A2190A7E8D1E>61 D<130CA3131EA2133F1327A2EB
4380A3EB81C0A348C67EA213FF38020070A20006137800041338A2487FA2001C131EB4EB
FFC01A1A7F991D>65 D<B5FC380E01C0EB00E014701478A514F014E0EB03C0380FFF8038
0E01E0EB00701478143CA51438147814F0EB01E0B51280161A7E991B>I<EB3F023801C0
C63803002E000E131E48130E14065A007813021270A200F01300A600701302A212780038
13047E14087E000313303801C0C038003F00171A7E991C>I<EB3F023801C0C63803002E
000E131E48130E14065A007813021270A200F090C7FCA5903801FFC03970000E00A21278
12387EA27E000313163801C06638003F821A1A7E991E>71 D<38FFE7FF380E0070AB380F
FFF0380E0070AC38FFE7FF181A7E991D>I<EAFFE0EA0E00B3A6EAFFE00B1A7F990E>I<39
FFE07F80390E001E00141814105C5C5C49C7FC13025B5B131C132E134E1387380F038012
0E6D7E6D7EA21470A28080143E39FFE0FF80191A7E991E>75 D<EAFFF0000EC7FCB01420
A314601440A214C01303B5FC131A7E9918>I<B4EB03FC000F14C0A2380B8005A33809C0
09A33808E011A3EB7021A2EB3841A3EB1C81A3EB0F01A31306121C39FF861FFC1E1A7E99
23>I<EAFFFC380E0780EB01C06D7E80A55C495AEB0780D80FFCC7FCEA0E067F6D7E80A3
80A31580EB00F0EC710038FFE03E191A7E991C>82 D<EA0FC2EA1836EA200EEA600612C0
1302A3EAE0001270127EEA3FE0EA1FF8EA07FCEA003E130E130713031280A3EAC0021306
EAE004EAD818EA87E0101A7E9915>I<007FB5FC38701C0700401301A200C01480008013
00A300001400B13803FFE0191A7F991C>I<38FFE1FF380E00381410B20006132012076C
1340EA01803800C180EB3E00181A7E991D>I<EA3F80EA70C013E0EA20701200A2EA07F0
EA1C701230127012E01371A213F1EA71FBEA1E3C10107E8F13>97
D<12FC121CA913F8EA1F0EEA1E07381C0380130114C0A6EB03801400EA1E07EA1B0CEA10
F0121A7F9915>I<EA07F8EA0C1C1238EA3008EA70005AA61270EA3004EA3808EA0C18EA
07E00E107F8F11>I<137E130EA9EA03CEEA0C3EEA380E1230127012E0A612601270EA38
1EEA1C2E3807CFC0121A7F9915>I<EA07C0EA1C30EA30181270EA600C12E0EAFFFCEAE0
00A41260EA3004EA3808EA0C18EA07E00E107F8F11>I<EA01F0EA0318EA0738EA0E1013
00A6EAFFC0EA0E00AEEA7FE00D1A80990C>I<EA0FCEEA1873EA3030EA7038A4EA3030EA
1860EA2FC0EA200012601270EA3FF013FCEA1FFEEA600FEAC003A4EA6006EA381CEA07E0
10187F8F13>I<12FC121CA913F8EA1D0CEA1E0EA2121CAB38FF9FC0121A7F9915>I<1218
123CA21218C7FCA612FC121CAEEAFF80091A80990A>I<EA0180EA03C0A2EA0180C7FCA6
EA0FC01201B21241EAE180EAE300127E0A2182990C>I<12FC121CA9EB3F80EB1E001318
13105B5BEA1DC0EA1FE0121C1370137813387F131E131F38FF3FC0121A7F9914>I<12FC
121CB3A6EAFF80091A80990A>I<38FC7C1F391D8E6380391E0781C0A2001C1301AB39FF
9FE7F81D107F8F20>I<EAFCF8EA1D0CEA1E0EA2121CAB38FF9FC012107F8F15>I<EA07E0
EA1C38EA300CEA700EEA6006EAE007A6EA6006EA700EEA381CEA1C38EA07E010107F8F13
>I<EAFCF8EA1F0EEA1E07381C0380A2EB01C0A6EB03801400EA1E07EA1F0CEA1CF090C7
FCA6B47E12177F8F15>I<EA03C2EA0C26EA381EEA300E127012E0A61270A2EA381EEA1C
2EEA07CEEA000EA6EB7FC012177F8F14>I<EAFCE0EA1D70121E1320EA1C00ABEAFFC00C
107F8F0F>I<EA1F20EA60E0EA402012C0A2EAF000127FEA3FC0EA1FE0EA00F0EA807013
3012C01320EAF040EA8F800C107F8F0F>I<1204A3120CA2121C123CEAFFC0EA1C00A813
20A5EA0E40EA03800B177F960F>I<EAFC7EEA1C0EAC131EEA0C2E3807CFC012107F8F15>
I<38FF1F80383C0600EA1C04A2EA1E0CEA0E08A26C5AA21390EA03A0A2EA01C0A36C5A11
107F8F14>I<39FF3F9F80393C0E070000381306381C16041317001E130C380E23081488
000F13983807419014D03803C1E01380A200015BEB004019107F8F1C>I<38FF3F80383C
1C00EA1C18EA0E106C5A13606C5A12017F1203EA0270487E1208EA181CEA381E38FC3FC0
12107F8F14>I<38FF1F80383C0600EA1C04A2EA1E0CEA0E08A26C5AA21390EA03A0A2EA
01C0A36C5AA248C7FCA212E112E212E4127811177F8F14>I<EA7FF8EA6070124013E0EA
41C0A2EA0380EA0700A2EA0E08121CA2EA381012701330EAFFF00D107F8F11>I<B712F8
2501808926>124 D<EA6180EAF3C0A2EA61800A047C9913>127 D
E /Fw 32 120 df<127812FCA4127806067D850C>46 D<EA07F0EA1E3C487EEA380EEA78
0FA300F81380AB00781300A2EA380EEA3C1E6C5AEA07F011187E9716>48
D<13C0120312FFA21203B2EA7FFEA20F187D9716>I<EA0FF0EA3FFCEA787EEAFC1F1480
130FA21278EA001F1400131E5B5B13705BEA0180380301801206120CEA1003383FFF005A
B5FCA211187E9716>I<EA07F0EA1FFCEA383E127C7FA3EA383FEA003E133C5BEA07F0EA
003C7F131F1480127812FCA2140012F8EA703EEA3FFCEA0FF011187E9716>I<1306130E
131E133E137E13DEEA019E131E12031206120C12181230126012C0B512E0A238001E00A5
3801FFE0A213187F9716>I<EA3006EA3FFCA213F05B13800030C7FCA3EA37F0EA381CEA
301EC67EA21480127012F8A31400EA601FEA383EEA1FF8EA07E011187E9716>I<13F8EA
07FEEA0F06EA1E0F485AA2EA780E90C7FC12F8EAF9F0EAFA1CEAFC0E130F00F81380A412
78A21400123CEA1E1EEA0FFCEA03F011187E9716>I<1260387FFFC0A214801400EAE006
12C05B5BC65A5BA213E012015B1203A31207A66C5A12197E9816>I<EA07F0EA1FFCEA38
1EEA300FEA7007A21278EA7E06EA7F8EEA3FF8121F6C7E487EEA38FF38703F80EAE00F13
071303A21400EA7007EA3C0EEA1FFCEA07F011187E9716>I<EA07E0EA1FF8EA3C1CEA78
1E7F12F8A21480A4EA781F1238EA1C2FEA07CFEA000F14001238EA7C1F131EEA783CEA30
78EA1FF0EA0FC011187E9716>I<1303497EA3497EA2EB1BE0A3EB31F0A2EB60F8A2EBE0
FCEBC07CA248487EEBFFFE487FEB001FA20006EB0F80A2000E14C039FFC07FFCA21E1A7F
9921>65 D<B512E014F8380F807C80143FA5143E147E14F813FFEB803E80EC0F8015C0A5
1580141FEC3F00B512FE14F01A1A7E991F>I<90381FE0209038FFFCE03803F80F3807C0
03381F800190C7FC123E007E1460127C00FC1400A6ECFFFCA2007CEB03E0127E123E7E13
80EA07C03803F8073800FFFC90381FF0601E1A7E9923>71 D<39FFF80FF8A2390F800380
EC0700140C5C5C14E0EB81C0EB83801387138FEB9FC0EBB3E0EBE3F013C1EB80F8147C80
A280EC0F80EC07C0A239FFF81FFCA21E1A7E9923>75 D<3807F040381FFDC0EA3C0FEA78
03EA700112F01300A26C1300B4FCEA7FF86CB4FC6C13806C13C0000113E0EA000FEB03F0
1301EAC000A36C13E0EAF00138FC03C038EFFF803883FE00141A7E9919>83
D<007FB51280A238781F07007013030060130100E014C000C01300A300001400AF3807FF
FCA21A1A7E991F>I<EA0FF0EA1C3CEA3E1E130E130F121C120013FFEA0FCFEA3E0F127C
12F8A31317387C27E0EA1FC313117F9015>97 D<12FEA2121EA7137F381FC3C0EB00E000
1E13F01478A2147CA51478A214F0001F13E0381D83C038187F00161A7F9919>I<EA03FC
EA0F0EEA1C1F123C1278130E00F8C7FCA51278A2383C0180381C0300EA0F06EA03FC1111
7F9014>I<EB0FE0A21301A7EA03F9EA0F07EA1C03EA3C011278A212F8A51278A2123CEA
1C03380F0DFCEA03F9161A7F9919>I<EA03F0EA0E1C487EEA3C071278148012F8A2B5FC
00F8C7FCA21278A2383C0180381C0300EA0E06EA03FC11117F9014>I<12FEA2121EA713
1FEB63C01381381F01E0A2121EAA38FFCFFCA2161A7F9919>104
D<121C123EA4121CC7FCA4127EA2121EADEAFF80A2091B7F9A0D>I<39FE1F01F0903863
C63C391E81C81C391F01F01EA2001E13E0AA3AFFCFFCFFC0A222117F9025>109
D<EA03F8EA0E0E383C0780EA3803007813C0A200F813E0A6007813C0EA7C07003C138038
0E0E00EA03F813117F9016>111 D<EAFE7F38FFC3C0381F01E0381E00F014F81478147C
A5147814F814F0381F01E0EB83C0381E7F0090C7FCA5EAFFC0A216187F9019>I<EAFC78
139CEA1D3EA2121E131C1300A9EAFFC0A20F117F9012>114 D<EA1FB0EA2070EA403012
C0A2EAF000EAFF80EA7FE0EA3FF81207EA003CEAC00CA212E01308EAF830EACFE00E117F
9011>I<1206A4120EA2121EEA3FF012FFEA1E00A81318A5EA0F30EA03E00D187F9711>I<
38FE0FE0A2EA1E01AB1303A2380F05FCEA03F916117F9019>I<39FF1FE1F8A2393C0780
60001E14C014C0381F0DC1000F148014E1390798E300A2EBB8F73803F076147E3801E03C
A33800C0181D117F9020>119 D E /Fx 15 116 df<123C127E127FA3123F1207120F12
0E123E12FC12F812E0080D77851A>44 D<127812FCA41278060676851A>46
D<137E3801FF804813C03807C3E0EA0F00381E0FF0EA3C3FEA387F387879F8EA70F038F0
E07812E1EBC038A6EBE07800F013703870F0F0387879E0EA387F383C3FC0381E0F00380F
00383807C1F8EA03FF6C13E038007F80151E7E9D1A>64 D<EA1FF0EA3FFC487EEA781F38
300780EA0003A213FF1207121FEA3F83EA7C0312F012E0A3EAF007EA7C1F383FFFFCEA1F
FDEA07F016157D941A>97 D<3801FF80000713C04813E0EA1F01383C00C0481300127012
F05AA57E1270007813707E381F01F0380FFFE06C13C00001130014157D941A>99
D<EA01FCEA07FF481380381F07C0383C01E0EA7800007013F000F013705AB512F0A300E0
C7FC7E1270007813707E381F01F0380FFFE06C13C00001130014157D941A>101
D<EB0FF0EB1FF8133FEB7878EBF030EBE000A4387FFFF0B5FCA23800E000AF383FFF8048
13C06C1380151E7F9D1A>I<12FEA3120EA6133FEBFF80000F13C0EBE1E013801300A212
0EAB38FFE3FE13E713E3171E7F9D1A>104 D<13C0487EA26C5A90C7FCA6EA7FE0A31200
AF387FFF80B512C06C1380121F7C9E1A>I<130C131EA2130C1300A6EA0FFEA3EA000EB3
A5131EEAF01C137CEAFFF8EA7FF0EA3FC00F2A7E9E1A>I<EAFFE0A31200B3A6B512E0A3
131E7D9D1A>108 D<EAFE3FEBFF80B512C0380FE1E013801300A2120EAB38FFE3FE13E7
13E317157F941A>110 D<EA01F0EA07FCEA1FFF383E0F80EA3C07387803C0EA700138E0
00E0A6EAF001007013C0EA7803383C0780EA3E0F381FFF00EA07FCEA01F013157D941A>
I<387F87F038FF9FFCEA7FBF3803FC3CEBF018EBE000A25BA25BA9EA7FFFB5FC7E16157E
941A>114 D<380FFB80EA3FFF5AEAF80FEAE003A300F8C7FCEA7FC0EA3FFCEA0FFF3800
7F80EB07C0EA600112E012F0130338FC0F80B512005BEAE7F812157C941A>I
E /Fy 50 128 df<120E120FEA01C0EA00E0A31201EA7F80EA80000B097A7F16>24
D<132013401380EA01005A12061204120CA25AA25AA312701260A312E0AE1260A3127012
30A37EA27EA2120412067E7EEA0080134013200B327CA413>40 D<7E12407E7E12187E12
041206A27EA2EA0180A313C01200A313E0AE13C0A312011380A3EA0300A21206A2120412
0C5A12105A5A5A0B327DA413>I<497EB0B612FEA23900018000B01F227D9C26>43
D<127012F812FCA212741204A41208A21210A212201240060F7C840E>I<127012F8A312
7005057C840E>46 D<EA01F0EA060C487E487E00381380A2387001C0A300F013E0AE0070
13C0A338380380A200181300EA0C06EA071CEA01F013207E9F18>48
D<13801203120F12F31203B3A8EA07C0EAFFFE0F207C9F18>I<EA03F0EA0C1EEA100700
201380384003C0A200F013E0EAF801A3EA2003120014C0A2EB07801400130E5B13185B5B
5B485A90C7FC000213205A5A00181360481340383FFFC05AB5FC13207E9F18>I<EA03F8
EA0C1EEA300700201380007813C0A21303EA380712001480A2EB0F00130E1338EA03F0EA
001E7FEB078014C0130314E0A21220127012F8A200F013C0EA4007148038300F00EA0C1E
EA03F013207E9F18>I<13021306130EA2131E133E132E134E13CE138EEA010EA2120212
0612041208121812101220A212401280B512F838000E00A7131F3801FFF015207F9F18>
I<00101380381E0700EA1FFF5B13F8EA13E00010C7FCA6EA11F8EA160EEA180738100380
1200EB01C0A214E0A3127012F0A200E013C0EA4003148000201300EA1006EA0C1CEA03F0
13207E9F18>I<137EEA01C138030080380601C0EA0C03121C3838018090C7FC12781270
A212F013F8EAF30EEAF40738F80380A2EB01C012F014E0A31270A3007813C01238EB0380
121C380C0700EA060CEA01F813207E9F18>I<12401260387FFFE014C0A23840008038C0
0100128013025B12005B5BA25BA21360A213E05BA21201A41203A86C5A13227DA118>I<
EA01F8EA040EEA180338300180382000C01260A3127038780180123E383F0300EA1FC6EA
0FF812037FEA067F38183F80EA300F382007C0386001E0EAC000A21460A31440006013C0
6C138038180100EA0E06EA03F813207E9F18>I<EA01F0EA060CEA1C06EA180300381380
1270EB01C012F0A314E0A3127013031238A2EA1C05EA0E19EA03E1EA000114C0A2130314
801230387807001306EA700CEA20186C5AEA0FC013207E9F18>I<127012F8A312701200
AB127012F8A3127005157C940E>I<B512F8380F800E0007EB0780EC03C015E0140115F0
A515E01403EC07C0EC0F80EC3E00EBFFFE9038800780EC03C0EC01E015F0140015F8A6EC
01F0A2EC03E0EC07C0000FEB0F00B512FC1D227EA123>66 D<90380FE010903838183090
38E006703801C00139078000F048C71270120E001E14305AA2007C14101278A200F81400
A812781510127C123CA26C1420120E000F14406C6C13803901C001003800E002EB380CEB
0FF01C227DA123>I<B512F0380F801E00071307EC03C01401EC00E015F01578A2157C15
3CA3153EA9153CA2157C1578A215F015E01401EC03C0EC0700000F131EB512F81F227EA1
25>I<B612C0380F80070007130114001540A215601520A314201500A3146014E013FF13
8014601420A491C7FCA9487EEAFFFE1B227EA120>70 D<39FFFC3FFF390FC003F0390780
01E0AE90B5FCEB8001AF390FC003F039FFFC3FFF20227EA125>72
D<3803FFF038001F007FB3A6127012F8A2130EEA701EEA401CEA3070EA0FC014227EA119
>74 D<EAFFFEEA0FC06C5AB3A21580A41401A215005CA2140F000F133FB6FC19227EA11E
>76 D<39FF8007FF3907C000F81570D805E01320EA04F0A21378137C133C7F131F7FEB07
80A2EB03C0EB01E0A2EB00F014F81478143C143E141E140FA2EC07A0EC03E0A21401A214
00000E1460121FD8FFE0132020227EA125>78 D<B512F0380F803C0007130FEC078015C0
140315E0A615C014071580EC0F00143CEBFFF00180C7FCAE487EEAFFFC1B227EA121>80
D<B512E0380F803C0007130E6E7E81140381A55D14075D020EC7FC143CEBFFE0EB807080
80141E140E140FA481A31680EC07C0EDC100390FC001E339FFFC007C21227EA124>82
D<39FFFC07FF390FC000F86C4813701520B3A5000314407F000114806C7EEC0100EB3002
EB1C0CEB07F020227EA125>85 D<EA0FE0EA1838EA3C0C130EEA18071200A313FFEA07C7
EA1E07123C1278127000F01308A3130FEA7817383C2390380FC1E015157E9418>97
D<120E12FE121E120EAB131FEB61C0EB8060380F0030000E1338143C141C141EA7141C14
3C1438000F1370380C8060EB41C038083F0017237FA21B>I<EA01FEEA0703380C078012
1C383803000078C7FC127012F0A712700078134012386C1380380C0100EA0706EA01F812
157E9416>I<14E0130F13011300ABEA01F8EA0704EA0C02EA1C01EA38001278127012F0
A7127012781238EA1801EA0C0238070CF03801F0FE17237EA21B>I<EA01FCEA0707380C
0380381C01C01238007813E0EA700012F0B5FC00F0C7FCA512700078132012386C13406C
138038070300EA00FC13157F9416>I<133C13C6EA018F1203130FEA0700A9EAFFF8EA07
00B21380EA7FF8102380A20F>I<120E12FE121E120EABEB1F80EB60C0EB80E0380F0070
A2120EAF38FFE7FF18237FA21B>104 D<121C121E123E121E121CC7FCA8120E12FE121E
120EB1EAFFC00A227FA10E>I<120E12FE121E120EABEB03FCEB01F014C01480EB02005B
5B5B133813F8EA0F1CEA0E1E130E7F1480EB03C0130114E0EB00F014F838FFE3FE17237F
A21A>107 D<120E12FE121E120EB3ADEAFFE00B237FA20E>I<390E1FC07F3AFE60E18380
3A1E807201C03A0F003C00E0A2000E1338AF3AFFE3FF8FFE27157F942A>I<380E1F8038
FE60C0381E80E0380F0070A2120EAF38FFE7FF18157F941B>I<EA01FCEA0707380C0180
381800C0003813E0481370A200F01378A700701370007813F0003813E0381C01C0380E03
8038070700EA01FC15157F9418>I<EA0E1F38FE61C0380E8060380F0070000E1338143C
141C141EA7143CA21438000F1370380E80E0EB41C0EB3F0090C7FCA9EAFFE0171F7F941B
>I<EA0E3CEAFE46EA1E8FEA0F0F13061300120EAD120FEAFFF010157F9413>114
D<EA0F88EA3078EA601812C01308A212E0EAF000EA7F80EA3FE0EA0FF0EA01F8EA003CEA
801C130CA212C01308EAE018EAD030EA8FC00E157E9413>I<1202A41206A3120E121E12
3EEAFFF8EA0E00AB1304A6EA07081203EA01F00E1F7F9E13>I<000E137038FE07F0EA1E
00000E1370AD14F0A238060170380382783800FC7F18157F941B>I<38FFC1FE381E0078
000E13301420A26C1340A238038080A33801C100A2EA00E2A31374A21338A3131017157F
941A>I<39FF8FF8FF391E01E03C001CEBC018120EECE010A239070260201470A2390384
30401438A23901C81880141CA23900F00D00140FA2EB6006A320157F9423>I<38FF83FE
381F01F0380E00C06C1380380381001383EA01C2EA00E41378A21338133C134E138EEA01
87EB0380380201C0000413E0EA0C00383E01F038FF03FE17157F941A>I<EA7070EAF8F8
A3EA70700D057BA118>127 D E /Fz 3 104 df<13C0A500C013C0EAF0C33838C700EA0E
DCEA03F0EA00C0EA03F0EA0EDCEA38C738F0C3C0EAC0C000001300A512157D9619>3
D<130F1338137013E0EA01C0B1EA0380EA0700121E12F0121E1207EA0380EA01C0B1EA00
E013701338130F10317CA419>102 D<12F0121E1207EA0380EA01C0B1EA00E013701338
130F1338137013E0EA01C0B1EA0380EA0700121E12F010317CA419>I
E /FA 27 123 df<127812FCA212FEA2127A1202A51204A31208A212101220A212400714
7A8512>44 D<B51280A311037F9016>I<127812FCA412781200B3127812FCA41278061F
7A9E12>58 D<1403A34A7EA24A7EA3EC17E01413A2EC21F0A3EC40F8A24A7E157CA29038
01007E153EA201027FA20106800104130FA249801507A2496D7E011FB5FCA29039200001
F0A201608001401300A24980167CA248C87EA25A825AD81F80EC3F80D8FFE0903803FFFC
A22E317EB032>65 D<B612E015FC3907E0003E0003EC0F80ED07C0ED03E0150116F01500
16F8A616F01501A2ED03E0ED07C0ED0F80ED1F00157C90B55A9038E0001FED0780ED03E0
ED01F0ED00F81678167CA2163EA7167CA316F8ED01F0ED03E0ED07C00007EC3F80B6EAFE
0015F827317CB02F>I<B712E0A23907E0000F00031401ED00F016701630A21610A41608
A315801600A41401A2140790B5FCA2EBE0071401A21400A31602A215001604A4160CA216
081618A216381678ED01F80007EC0FF0B7FCA227317CB02D>69 D<B51280A23807F0006C
5AB3B3A7487EB51280A211317DB017>73 D<B6FC15F03907E001FC0003EB003EED0F806F
7E6F7E150182150082A65E15015E4B5A4B5A4BC7FC153CEC01F090B5C8FC9038E001F0EC
007C151E6F7E1507826F7EAB1708A21501923800F010486C1470B56CEB3820EE0FC02D31
7CB031>82 D<90387F80203901FFE0603807C078390F001CE0001C1306003C1303003813
0100781300127000F01460A31520A27E1500127CA2127FEA3FC0EA1FF86CB47E6C13F86C
13FEC67F010F1380010013C0EC1FE01407EC03F01401140015F8A26C1478A47E157015F0
7E6C14E06CEB01C000EC130300E7EB078039C3E01E0038C0FFFC38800FF01D317CB025>
I<007FB712E0A23A7E000F800700781501007015000060166000401620A200C01630A248
1610A6C71500B3AC4A7E010FB57EA22C317EB030>I<13FE380303C0380C00E000101370
80003C133C003E131C141EA21208C7FCA3EB0FFEEBFC1EEA03E0EA0F80EA1F00123E123C
127C481404A3143EA21278007C135E6CEB8F08390F0307F03903FC03E01E1F7D9E21>97
D<EB3F80EBE06038038018380700045A001E131E001C133E123C127C14080078130012F8
A91278127CA2003C13017E14027E6C1304380380183800E060EB3F80181F7D9E1D>99
D<EC01E0143FA214031401AFEB1F81EBF0613801C01938078005380F0003120E001E1301
5AA2127C127812F8A91278A27EA2121C001E1303000E13056C130939038011F03900E061
FFEB3F8120327DB125>I<EB3F80EBE0E0380380383807003C000E7F121E001C7F123C12
7C00781480140712F8A2B6FC00F8C8FCA61278127C123C15807E000EEB0100000F1302EA
07803801C00C3800F030EB1FC0191F7E9E1D>I<1207EA0F80121FA2120FEA0700C7FCAB
EA078012FFA2120F1207B3A6EA0FC0EAFFF8A20D307EAF12>105
D<EA078012FFA2120F1207B3B3A7EA0FC0EAFFFCA20E327EB112>108
D<260780FEEB1FC03BFF83078060F0903A8C03C180783B0F9001E2003CD807A013E4DA00
F47F01C013F8A2495BB3A2486C486C133F3CFFFC1FFF83FFF0A2341F7E9E38>I<380780
FE39FF83078090388C03C0390F9001E0EA07A06E7E13C0A25BB3A2486C487E3AFFFC1FFF
80A2211F7E9E25>I<EB1FC0EBF0783801C01C38070007481480001EEB03C0001C130100
3C14E0A248EB00F0A300F814F8A8007814F0007C1301003C14E0A26CEB03C0A26CEB0780
3907800F003801C01C3800F078EB1FC01D1F7E9E21>I<380781FC38FF860790388803C0
390F9001E03907A000F001C013785B153CA2153E151E151FA9153EA2153C157C15786D13
F013A0EC01E090389803809038860F00EB81F80180C7FCAB487EEAFFFCA2202D7E9E25>
I<380783E038FF8C18EB907C120FEA07A0EBC0381400A35BB3487EEAFFFEA2161F7E9E19
>114 D<3801FC10380E0330381800F048137048133012E01410A37E6C1300127EEA3FF0
6CB4FC6C13C0000313E038003FF0EB01F813006C133CA2141C7EA27E14186C1338143000
CC136038C301C03880FE00161F7E9E1A>I<1340A513C0A31201A212031207120F381FFF
E0B5FC3803C000B01410A80001132013E000001340EB78C0EB1F00142C7FAB19>I<D807
8013F000FF131FA2000F130100071300B31401A300031302EBC0040001497E3A007030FF
80EB1FC0211F7E9E25>I<39FFF803FFA2390FE001F8D803C013E001E01380000191C7FC
6C6C5AEB7802EB7C04EB3C086D5AEB0F3014A0EB07C01303806D7E1302EB0478EB087CEB
183EEB101E497E01407F9038C007C0EB800300016D7E000780001F497E3AFFC007FFC0A2
221F7F9E23>120 D<3AFFF801FF80A23A0FC0007C006C4813386D133000031420A26C6C
5BA27F00005CA2D97801C7FCA2137CEB3C02A26D5AA2131F6D5AA2EB0790A214D0EB03E0
A26D5AA36D5AA249C8FCA31302A25B1270EAF80C13085BEA7030EA3040EA1F80212D7F9E
23>I<003FB5FC383E001E12380030133C00201378A2006013F0384001E0A2EB03C0EB07
801200EB0F00131EA25B5BA2EBF001EA01E0A2EA03C0EA07801403380F0002121E14065A
48130E147EB512FE181F7E9E1D>I E end
%%EndProlog
%%BeginSetup
%%Feature: *Resolution 300dpi
TeXDict begin
%%PaperSize: a4

%%EndSetup
%%Page: 1 1
1 0 bop 196 216 a FA(Automatic,)21 b(T)-6 b(emplate-Based)21
b(Run-Time)f(Sp)r(ecialization:)385 307 y(Implemen)n(tation)g(and)h
(Exp)r(erimen)n(tal)g(Study)1566 281 y Fz(\003)334 428
y Fy(F)l(ran\030)-22 b(cois)16 b(No)o(\177)-23 b(el,)15
b(Luk)o(e)h(Hornof,)g(Charles)h(Consel,)f(Julia)g(L.)g(La)o(w)o(all)502
486 y Fz(f)p Fx(fnoel,)23 b(hornof,)g(consel,)g(jll)p
Fz(g)p Fx(@irisa.)o(fr)611 544 y Fy(Campus)16 b(Univ)o(ersitaire)e(de)i
(Beaulieu)670 602 y(35042)i(Rennes)e(Cedex,)f(F)l(rance)678
660 y(Phone:)22 b(\(+33\))17 b(2)f(99)h(84)g(74)g(86)773
758 y(Decem)o(b)q(er)d(11,)j(1996)890 937 y Fw(Abstract)161
996 y Fv(Sp)q(ecializ)q(in)q(g)k(programs)f(with)f(resp)q(ect)g(to)g
(run-time)g(v)n(alues)h(is)f(an)g(optimization)j(strategy)d(that)g(has)
g(b)q(een)104 1042 y(sho)o(wn)13 b(to)f(drastically)k(impro)o(v)o(e)e
(co)q(de)f(p)q(erformance)g(on)g(realistic)i(programs)e(ranging)h(from)
f(op)q(erating)h(systems)f(to)104 1087 y(graphics.)23
b(Recen)o(tly)m(,)16 b(v)n(arious)g(approac)o(hes)h(to)d(sp)q(ecializi)
q(ng)k(co)q(de)d(at)f(run-time)i(ha)o(v)o(e)f(b)q(een)g(prop)q(osed.)24
b(Ho)o(w)o(ev)o(er,)104 1133 y(these)15 b(approac)o(hes)h(still)h
(su\013er)e(from)f(shortcomings)j(whic)o(h)f(limit)g(their)g
(applicabil)q(it)o(y:)24 b(they)15 b(are)f(either)i(man)o(ual,)104
1179 y(restricted)e(to)f(a)g(small)h(language,)h(or)e(to)q(o)g(exp)q
(ensiv)o(e)i(to)e(b)q(e)g(widely)i(applied.)161 1224
y(In)h(this)h(pap)q(er,)g(w)o(e)e(presen)o(t)i(new)f(tec)o(hniques)h
(to)f(implemen)o(t)i(fast)d(run-time)i(sp)q(ecializati)q(on)i(of)d(C)f
(programs)104 1270 y(based)j(on)g(co)q(de)g(templates.)31
b(Unlik)o(e)19 b(other)f(approac)o(hes,)h(ours)f(do)q(es)g(not)g
(require)h(the)e(dev)o(elopmen)o(t)j(of)d(a)g(new)104
1316 y(compiler.)32 b(T)m(emplates)18 b(are)f(compiled)j(and)e
(optimized)h(b)q(efore)f(run)f(time.)31 b(Run-time)18
b(sp)q(ecializa)q(tion)j(do)q(es)d(not)104 1361 y(require)13
b(an)o(y)g(in)o(terpretation)h(and)f(solely)h(consists)f(of)f(assem)o
(bling)i(binary)g(templates,)f(\014lling)i(holes)e(and)g(relo)q(cating)
104 1407 y(jump)c(targets.)16 b(The)9 b(simplicit)o(y)j(of)d(these)h
(op)q(erations)h(in)o(tro)q(duces)g(negligibl)q(e)h(o)o(v)o(erhead)e
(at)f(run)g(time:)16 b(sp)q(ecializati)q(on)104 1453
y(requires)h(as)f(few)g(as)g(3)g(runs)g(to)g(b)q(e)g(amortized.)28
b(As)15 b(demonstrated)j(b)o(y)e(our)g(exp)q(erimen)o(tal)j(results)e
(obtained)h(on)104 1498 y(scien)o(ti\014c)f(and)e(graphics)i(co)q(de,)f
(run-time)f(sp)q(ecialize)q(d)j(programs)d(run)h(nearly)g(\(80\045)f
(on)g(a)o(v)o(erage\))h(as)f(fast)g(as)g(the)104 1544
y(same)9 b(program)h(sp)q(ecialized)i(and)e(compiled)h(at)e(compile)i
(time:)k(run-time)10 b(sp)q(ecializati)q(on)i(can)e(impro)o(v)o(e)g(p)q
(erformance)104 1590 y(up)15 b(to)g(a)g(factor)f(of)h(10.)23
b(Th)o(us)15 b(our)g(measuremen)o(ts)h(sho)o(w)f(that)g(the)g
(additional)j(o)o(v)o(erhead)e(incurred)h(b)o(y)e(deferring)104
1635 y(optimizations)h(to)d(run)g(time,)g(as)h(adv)o(o)q(cated)g(b)o(y)
f(others,)h(ma)o(y)f(not)g(b)q(e)g(necessary)m(.)0 1772
y Fu(1)67 b(In)n(tro)r(duction)0 1862 y Ft(Run-time)10
b(sp)q(ecialization)h(allo)o(ws)g(programs)f(to)i(b)q(e)g(optimized)f
(b)o(y)g(exploiting)g(dynamic)f(information.)k(This)e(tec)o(hnique)0
1912 y(has)20 b(b)q(een)i(sho)o(wn)e(to)g(drastically)f(impro)o(v)o(e)g
(co)q(de)i(in)e(v)n(arious)h(applications)f(suc)o(h)i(as)f(op)q
(erating)g(systems)g([18)o(])g(and)0 1962 y(graphics)14
b([13)o(,)f(15].)62 2012 y(V)m(arious)h(approac)o(hes)h(aimed)e(at)i
(facilitating)d(the)j(pro)q(cess)i(of)d(sp)q(ecializing)g(\(and)g
(sometimes)f(generating\))i(co)q(de)g(at)0 2062 y(run)h(time)f(ha)o(v)o
(e)g(b)q(een)i(prop)q(osed.)25 b(These)17 b(approac)o(hes)f(range)g
(from)e(language)h(extensions)i(to)e(express)j(dynamic)c(co)q(de)0
2112 y(construction)h([5)o(],)e(to)h(automatic)e(program)g(sp)q
(ecialization)h([1,)g(10,)g(11,)g(12)o(,)h(9].)62 2161
y(Unfortunately)m(,)f(eac)o(h)i(of)e(the)i(existing)e(approac)o(hes)i
(has)f(its)g(limitations.)h(They)g(are)f(either)h(man)o(ual,)c
(restricted)16 b(to)0 2211 y(a)d(small)f(language,)g(or)h(to)q(o)h(exp)
q(ensiv)o(e)g(to)g(b)q(e)g(widely)f(applied.)k(W)m(e)c(ha)o(v)o(e)h
(dev)o(elop)q(ed)g(an)f(approac)o(h)h(that)g(lifts)e(all)h(three)0
2261 y(of)f(these)j(limitatio)o(ns.)g(In)e(a)g(previous)g(pap)q(er)h
([4)o(],)e(w)o(e)i(formally)c(de\014ned)k(this)f(approac)o(h)g(for)f(a)
h(subset)h(of)f(an)f(imp)q(erativ)o(e)0 2311 y(language)h(and)h(pro)o
(v)o(ed)g(it)f(correct.)62 2361 y(In)20 b(this)f(pap)q(er,)i(the)f(tec)
o(hniques)h(used)g(to)e(implemen)o(t)e(our)i(approac)o(h)h(are)f
(describ)q(ed.)37 b(In)20 b(con)o(trast)g(to)f(all)f(the)0
2410 y(other)i(automatic)d(approac)o(hes)k(to)e(run-time)f(sp)q
(ecialization,)i(ours)g(do)q(es)g(not)f(require)h(the)g(dev)o(elopmen)o
(t)f(of)f(a)i(new)0 2460 y(compiler.)c(W)m(e)10 b(presen)o(t)j(tec)o
(hniques)f(that)f(allo)o(w)f(us)h(to)g(compile)e(templates)i(using)g
(an)f(existing)h(C)g(compiler.)16 b(Finally)m(,)9 b(w)o(e)0
2510 y(demonstrate,)k(based)h(on)g(exp)q(erimen)o(tal)f(results,)h
(that)g(our)f(run-time)g(sp)q(ecializer)h(can)g(b)q(e)h(applied)e
(widely)m(,)f(drastically)0 2560 y(impro)o(v)o(es)g(p)q(erformance,)i
(and)f(in)o(tro)q(duces)i(v)o(ery)g(little)e(o)o(v)o(erhead.)p
0 2592 780 2 v 46 2619 a Fs(\003)64 2631 y Fr(This)g(researc)o(h)e(is)i
(supp)q(orted)e(in)i(part)f(b)o(y)h(F)m(rance)f(T)m(elecom/SEPT,)f(ARP)
m(A)k(gran)o(t)c(N00014-94-1-084)o(5)f(and)j(con)o(tract)e
(F19628-95-C-)0 2670 y(0193,)f(and)h(NSF)h(gran)o(t)e(CCR-92243375.)j
(INRIA)f(T)m(ec)o(hnical)e(Rep)q(ort)g(RR-1065)965 2795
y Ft(1)p eop
%%Page: 2 2
2 1 bop 62 42 a Ft(Our)16 b(approac)o(h)f(consists)i(of)d(the)i(follo)o
(wing)d(steps.)23 b(A)16 b(program)d(is)i(\014rst)i(analyzed)e(with)g
(resp)q(ect)i(to)e(a)g(description)0 91 y(iden)o(tifying)h(the)j
(information)c(that)i(will)g(b)q(e)h(a)o(v)n(ailable)e(for)h(sp)q
(ecialization.)29 b(This)18 b(phase)g(mainly)e(includes)i(analyses)0
141 y(of)c(aliases,)h(side-e\013ects,)i(binding-times)c(\(dep)q
(endencies\),)18 b(and)d(actions)g(\(program)e(transformations\).)20
b(The)c(result)g(of)0 191 y(this)i(phase)g(is)f(a)g(program)f(where)j
(eac)o(h)f(construct)h(is)e(asso)q(ciated)h(with)g(the)g(action)f(to)g
(tak)o(e)h(during)f(sp)q(ecialization.)0 241 y(An)e(action-annotated)f
(program)f(can)i(then)g(b)q(e)h(sp)q(ecialized)f(either)h(at)e(compile)
f(time)g(or)i(at)g(run)g(time.)k(Compile-tim)o(e)0 291
y(sp)q(ecialization)13 b(consists)h(of)e(in)o(terpreting)i(actions)f
(giv)o(en)f(some)g(sp)q(ecialization)h(v)n(alues.)k(T)m(o)c(p)q(erform)
f(run-time)g(sp)q(ecial-)0 340 y(ization,)g(the)i(action-annotated)f
(program)f(is)h(further)h(analyzed)f(to)g(determine)g(a)g(safe)h(appro)
o(ximation)c(of)j(the)h(p)q(ossible)0 390 y(sp)q(ecializations)f(it)g
(ma)o(y)f(yield.)17 b(This)c(result)i(is)e(expressed)j(as)d(a)g(tree)i
(gramma)o(r.)h(Then,)d(this)h(tree)g(grammar)d(is)i(used)h(to)0
440 y(generate)f(templates)e(automatically)e(at)j(the)g(source)i(lev)o
(el.)j(T)m(emplates)10 b(corresp)q(ond)k(to)d(the)i(computations)d
(that)i(do)g(not)0 490 y(dep)q(end)k(solely)e(on)h(sp)q(ecialization)f
(v)n(alues.)20 b(They)c(are)f(compiled)e(b)o(y)h(a)h(standard)g
(compiler.)k(V)m(arious)14 b(information)e(on)0 540 y(template)f
(delimiters)g(and)h(template)f(holes)h(is)g(collected.)18
b(Finally)m(,)10 b(a)i(run-time)f(sp)q(ecializer)i(is)e(generated;)j
(it)e(consists)h(of)0 589 y(the)g(compiled)d(templates,)i(and)g(the)g
(static)h(computations)e(in)o(tert)o(wined)h(with)g(simple)f(op)q
(erations)h(to)g(dump)f(templates,)0 639 y(\014ll)i(holes,)g(and)h
(relo)q(cate)h(jump)d(targets.)62 689 y(Our)h(approac)o(h)e(has)h(b)q
(een)h(carried)f(out)g(in)f(practice:)18 b(w)o(e)12 b(ha)o(v)o(e)g
(designed)g(and)g(implem)o(en)o(ted)e(a)i(partial)e(ev)n(aluator)h(for)
0 739 y(the)h(C)f(language)f(that)i(includes)f(b)q(oth)h(a)e
(compile-time)f(and)i(a)g(run-time)f(sp)q(ecializer)i([3)o(].)17
b(This)11 b(system,)g(named)f(T)m(emp)q(o,)0 789 y(has)19
b(b)q(een)h(successfully)g(used)g(to)f(sp)q(ecialize)g(existing,)h
(real-size)f(programs)f(in)g(areas)i(suc)o(h)f(as)g(graphics,)h(op)q
(erating)0 839 y(systems)14 b([19)o(,)f(20],)g(and)h(scien)o(ti\014c)g
(programs.)62 888 y(The)h(con)o(tributions)e(of)h(this)g(pap)q(er)g
(can)g(b)q(e)h(summarized)d(as)i(follo)o(ws.)62 975 y
Fq(\017)21 b Ft(New)10 b(tec)o(hniques)h(to)e(implemen)o(t)e(run-time)h
(sp)q(ecialization)h(are)h(presen)o(ted.)19 b(They)10
b(do)f(not)h(require)g(a)f(new)h(compiler)104 1025 y(to)k(b)q(e)g(dev)o
(elop)q(ed)h(to)e(compile)g(templates,)f(as)i(w)o(as)g(previously)g
(done.)62 1106 y Fq(\017)21 b Ft(Our)e(run-time)e(sp)q(ecialization)h
(pro)q(cess)i(is)e(fully)f(compiled:)26 b(the)19 b(op)q(erations)f
(needed)i(to)e(sp)q(ecialize)h(co)q(de)h(are)104 1155
y(simple,)10 b(and)i(no)g(in)o(terpretation)h(or)f(auxiliary)e(tables)j
(are)f(necessary)m(.)19 b(As)13 b(a)f(consequence,)i(the)f(resulting)f
(pro)q(cess)104 1205 y(is)i(drastically)f(faster)h(than)g(other)h
(automatic)d(approac)o(hes)i(for)g(a)f(language)g(suc)o(h)i(as)f(C.)62
1286 y Fq(\017)21 b Ft(An)14 b(exp)q(erimen)o(tal)f(study)i(conducted)g
(in)f(the)g(con)o(text)h(of)e(existing)h(programs)f(demonstrates)h
(that)g(our)g(strategy)104 1336 y(is)g(realistic,)f(signi\014can)o(tly)
g(impro)o(v)o(es)f(p)q(erformance,)i(and)f(in)o(tro)q(duces)i
(negligible)e(o)o(v)o(erhead)h(in)f(general.)62 1417
y Fq(\017)21 b Ft(Because)14 b(T)m(emp)q(o)d(sp)q(ecializes)j(programs)
d(b)q(oth)h(at)h(compile)d(time)i(and)g(run)h(time,)d(it)j(allo)o(ws)e
(us)i(to)f(mak)o(e)f(a)h(crucial)104 1467 y(analysis:)30
b(comparing)19 b(the)i(e\016ciency)g(of)f(statically)g(sp)q(ecialized)h
(and)f(compiled)f(programs)h(to)g(dynamically)104 1517
y(assem)o(bled)12 b(binary)g(templates.)17 b(This)c(comparison)e(sho)o
(ws)i(that)g(dynamically)d(sp)q(ecialized)j(programs)f(are)h(nearly)104
1567 y(\(80\045)f(on)h(a)o(v)o(erage\))h(as)f(e\016cien)o(t)h(as)f
(statically)g(sp)q(ecialized)h(ones.)k(These)d(measuremen)o(ts)e
(demonstrate)g(that)g(the)104 1616 y(additional)c(o)o(v)o(erhead)j
(incurred)h(b)o(y)e(deferring)h(optimizations)e(to)h(run)h(time,)e(as)i
(adv)o(o)q(cated)g(b)o(y)f(others)i([1)o(,)e(9],)g(ma)o(y)104
1666 y(not)j(pa)o(y)f(o\013.)62 1753 y(The)f(rest)g(of)f(this)g(pap)q
(er)h(is)f(organized)g(as)g(follo)o(ws.)16 b(Section)11
b(2)g(describ)q(es)j(our)d(approac)o(h)g(to)g(run-time)f(sp)q
(ecialization.)0 1802 y(Section)17 b(3)e(presen)o(ts)k(the)d(main)f
(implem)o(en)o(tation)e(tec)o(hniques)18 b(used)f(to)f(ac)o(hiev)o(e)g
(run-time)f(sp)q(ecialization.)25 b(Section)16 b(4)0
1852 y(measuremen)o(ts)9 b(the)h(e\016ciency)g(of)f(run-time)f(sp)q
(ecialization)h(on)g(scien)o(ti\014c)h(and)f(graphics)h(programs.)15
b(Section)10 b(5)f(discusses)0 1902 y(related)14 b(w)o(ork.)k(Finally)m
(,)12 b(Section)i(6)f(giv)o(es)h(concluding)g(remarks)f(and)h(outlines)
g(future)g(directions.)0 2038 y Fu(2)67 b(Our)23 b(Approac)n(h)0
2129 y Ft(W)m(e)13 b(b)q(egin)g(with)g(the)h(basic)g(concepts)h(of)d
(partial)h(ev)n(aluation)f(and)h(its)g(extension)h(to)f(p)q(erform)g
(run-time)f(sp)q(ecialization.)0 2245 y Fp(2.1)56 b(T)-5
b(emp)r(o:)22 b(A)d(P)n(artial)g(Ev)m(aluator)f(for)h(C)g(Programs)0
2321 y Ft(P)o(artial)e(ev)n(aluation)f(is)i(a)g(program)e
(transformation)g(that)i(sp)q(ecializes)h(a)f(program)e(with)i(resp)q
(ect)i(to)e(constan)o(t)g(\()p Fo(i.e.)p Ft(,)0 2371
y(kno)o(wn,)11 b(or)h Fo(static)p Ft(\))g(parts)g(of)f(its)h(input.)17
b(W)m(e)12 b(ha)o(v)o(e)f(dev)o(elop)q(ed)i(and)e(implemen)o(ted)f(a)i
(partial)e(ev)n(aluator)h(for)h(C)g(programs,)0 2421
y(named)j(T)m(emp)q(o.)21 b(T)m(emp)q(o)14 b(allo)o(ws)h(programs)f(to)
i(b)q(e)g(sp)q(ecialized)g(at)g(b)q(oth)g(compile)e(time)g(and)h(run)h
(time.)22 b(It)16 b(has)g(b)q(een)0 2471 y(used)g(to)g(e\013ectiv)o
(ely)g(sp)q(ecialize)g(existing,)g(realistic)f(applications,)g
(including)f(systems)i(co)q(de,)g(graphics)g(routines,)g(and)0
2521 y(scien)o(ti\014c)f(co)q(de.)62 2570 y(T)m(emp)q(o)f(is)i(an)f
Fo(o\017ine)h Ft(partial)e(ev)n(aluator:)21 b(it)15 b(is)g(divided)g
(in)o(to)g(an)g(analysis)g(phase)h(follo)o(w)o(ed)d(b)o(y)j(a)f
(transformation)0 2620 y(phase)j(\(sp)q(ecialization\).)29
b(The)18 b(analysis)e(phase)i(comprises)g(alias,)f(side-e\013ect,)i
(binding-time,)d(and)h(action)g(analyses.)0 2670 y(In)e(order)h(to)f
(deal)g(with)g(the)h(complexities)e(of)h(realistic)g(source)i
(programs,)d(the)h(analyses)h(are)g(\015o)o(w)e(sensitiv)o(e,)i(con)o
(text)965 2795 y(2)p eop
%%Page: 3 3
3 2 bop 0 2 848 2 v 985 2 966 2 v -1 632 2 633 v 59 69
a Fn(int)16 b(dotproduct\(i)o(nt)e(size,)i(int)h(u[],)f(int)g(v[]\))59
109 y Fm(f)94 148 y Fn(int)h(i;)94 187 y(int)g(res;)94
266 y(res)g(=)g(0;)94 345 y(for)g(\(i)g(=)g(0;)g(i)g(<)g(size;)f(i++\))
129 385 y(res)h(=)g(res)g(+)g(u[i])f(*)i(v[i];)94 464
y(return)e(res;)59 503 y Fm(g)190 612 y Ft(Figure)e(1:)j(Source)e
(program)p 846 632 V 985 632 V 1041 64 a Fn(int)h(dotproduct\()o(int)e
(size)1448 52 y Fl(S)1487 64 y Fn(,)j(int)f(u[])1646
52 y Fl(S)1685 64 y Fn(,)h(int)g(v[])1845 52 y Fl(D)1889
64 y Fn(\))1041 104 y Fm(f)1076 143 y Fn(int)g(i;)1076
182 y(int)g(res;)1076 262 y(res)1130 251 y Fl(D)1174
262 y Fn(=)1192 251 y Fl(D)1237 262 y Fn(0)1255 251 y
Fl(S)1295 262 y Fn(;)1076 342 y(for)1130 331 y Fl(D)1174
342 y Fn(\(i)1210 331 y Fl(S)1250 342 y Fn(=)1268 331
y Fl(S)1307 342 y Fn(0)1325 331 y Fl(S)1365 342 y Fn(;)g(i)1418
331 y Fl(S)1457 342 y Fn(<)1475 331 y Fl(S)1515 342 y
Fn(size)1587 331 y Fl(S)1625 342 y Fn(;)h(i)1679 331
y Fl(S)1718 342 y Fn(++)1754 331 y Fl(S)1793 342 y Fn(\))1111
383 y(res)1165 371 y Fl(D)1210 383 y Fn(=)1228 371 y
Fl(D)1273 383 y Fn(res)1327 371 y Fl(D)1371 383 y Fn(+)1389
371 y Fl(D)1434 383 y Fn(u)1452 371 y Fl(S)1492 383 y
Fn([i)1528 371 y Fl(S)1567 383 y Fn(])1585 371 y Fl(S)1624
383 y Fn(*)1642 371 y Fl(S)1682 383 y Fn(v)1700 371 y
Fl(D)1745 383 y Fn([i)1781 371 y Fl(S)1820 383 y Fn(])1838
371 y Fl(S)1878 383 y Fn(;)1076 463 y(return)1184 451
y Fl(D)1227 463 y Fn(res)1281 451 y Fl(D)1326 463 y Fn(;)1041
503 y Fm(g)1090 612 y Ft(Figure)c(2:)j(Binding-time)12
b(analyzed)i(program)p 1950 632 V 0 634 848 2 v 985 634
966 2 v 0 761 a(sensitiv)o(e,)g(and)g(use)h(sensitiv)o(e.)k(Details)14
b(of)f(these)j(analyses)e(are)h(presen)o(ted)h(elsewhere)g([3)o(].)i
(The)d(result)g(of)e(the)i(analysis)0 811 y(phase)g(is)e(a)h(program)e
(in)i(whic)o(h)g(eac)o(h)g(construct)i(is)e(asso)q(ciated)g(with)g(the)
h(action)e(to)h(tak)o(e)g(during)g(sp)q(ecialization.)k(The)0
861 y(action)c(tree)h(can)f(b)q(e)g(used)h(b)o(y)f(either)g(the)h
(compile-tim)o(e)d(or)i(run-time)e(sp)q(ecializer.)62
910 y(When)18 b(the)g(constan)o(t)g(inputs)g(are)f(kno)o(wn)g(at)h
(compile-tim)o(e,)d(the)j(compile-time)d(sp)q(ecializer)j(can)g(b)q(e)g
(used.)30 b(The)0 960 y(compile-tim)o(e)10 b(sp)q(ecializer)k(pro)q
(duces)g(a)e(program)f(in)h(the)h(source)g(language,)f(whic)o(h)g(can)h
(b)q(e)g(subsequen)o(tly)g(compiled)e(b)o(y)0 1010 y(an)o(y)j
(compiler.)k(T)m(raditionally)m(,)11 b(partial)j(ev)n(aluators)g(ha)o
(v)o(e)g(only)g(b)q(een)h(dev)o(elop)q(ed)h(to)e(handle)g(compile-time)
e(constan)o(ts.)0 1060 y(W)m(e)j(ha)o(v)o(e)f(extended)j(partial)d(ev)n
(aluation)g(to)h(allo)o(w)e(it)i(to)f(sp)q(ecialize)i(programs)e(with)h
(resp)q(ect)i(to)e(constan)o(ts)h(that)f(only)0 1110
y(b)q(ecome)f(kno)o(wn)f(at)h(run)g(time.)j(In)d(this)g(case,)g(the)h
(sp)q(ecialized)f(program)e(is)i(directly)g(pro)q(duced)i(in)d(mac)o
(hine)g(co)q(de.)62 1160 y(W)m(e)k(no)o(w)f(illustrate)g(b)q(oth)h
(compile-time)d(and)i(run-time)g(sp)q(ecialization)g(using)h(the)g(dot)
f(pro)q(duct)i(program)d(illus-)0 1209 y(trated)g(in)e(Figure)h(1.)k
(This)c(program)e(computes)i(the)g(dot)g(pro)q(duct)h(of)e(t)o(w)o(o)g
(v)o(ectors)i(of)f(length)f Fk(size)p Ft(.)0 1326 y Fp(2.2)56
b(Analysis)18 b(Phase)0 1402 y Ft(Let)j(us)f(sp)q(ecialize)h(dot)f(pro)
q(duct)h(with)f(resp)q(ect)i(to)e(the)h(length)f(of)f(the)i(v)o(ectors)
g(and)f(the)h(elemen)o(ts)f(of)f(the)i(v)o(ector)0 1452
y Fk(u)p Ft(.)33 b(T)m(o)18 b(prepare)i(this)f(sp)q(ecialization,)g
(the)h(binding-time)c(analysis)i(uses)j(earlier)e(alias)e(and)i
(side-e\013ect)i(analyses)e(to)0 1502 y(propagate)f(an)g(abstract)i
(description)e(sp)q(ecifying)h(that)f(v)n(ariables)g
Fk(size)f Ft(and)h Fk(u)g Ft(are)h(kno)o(wn/)p Fo(static)p
Ft(,)f(and)g(v)n(ariable)f Fk(v)0 1552 y Ft(is)j(unkno)o(wn/)p
Fo(dynamic)p Ft(.)36 b(As)20 b(a)f(result,)j(eac)o(h)e(program)e
(construct)k(is)d(annotated)h(b)o(y)g(binding-times,)f(as)h(sho)o(wn)f
(in)0 1601 y(Figure)12 b(2.)18 b(Static)12 b(constructs)i(\(annotated)f
Fo(S)p Ft(\))g(only)e(dep)q(end)j(on)e(a)o(v)n(ailable)e(data.)17
b(Otherwise,)d(constructs)g(are)f(dynamic)0 1651 y(\(annotated)h
Fo(D)p Ft(\).)62 1701 y(The)e(binding-time)d(annotated)j(program)d(is)j
(then)g(used)g(to)f(determine)h(whic)o(h)f(sp)q(ecialization)g(action)g
(\()p Fo(i.e.)p Ft(,)g(program)0 1751 y(transformation\))16
b(to)i(p)q(erform)f(for)g(eac)o(h)i(construct,)h(as)e(presen)o(ted)i
(in)d(Figure)h(3.)30 b(The)18 b(action)g Fo(evaluate)g
Ft(\(noted)h Fo(ev)p Ft(\))0 1801 y(indicates)d(that)f(the)h(construct)
i(only)c(dep)q(ends)j(on)f(static)g(data.)22 b(These)17
b(constructs,)g(suc)o(h)g(as)e Fk(i)22 b(=)f(0)16 b Ft(or)f
Fk(u[i])g Ft(can)g(b)q(e)0 1850 y(completely)c(ev)n(aluated)h(at)g(sp)q
(ecialization)f(time.)16 b(The)d(action)f Fo(r)n(e)n(duc)n(e)g
Ft(\(noted)g Fo(r)n(e)n(d)t Ft(\))g(is)g(assigned)h(to)e(constructs)k
(that)d(can)0 1900 y(only)h(b)q(e)h(partially)e(reduced)j(b)q(ecause)g
(of)e(their)h(dynamic)e(sub)q(comp)q(onen)o(ts)h(that)h(m)o(ust)e(b)q
(e)i(residualized.)19 b(F)m(or)13 b(example,)0 1950 y(the)20
b Fk(for)e Ft(lo)q(op)h(will)e(b)q(e)j(reduced)h(since)f(its)f(test)h
(is)g(static,)g(although)e(its)h(b)q(o)q(dy)h(will)d(b)q(e)j
(residualized.)34 b(Constructs)0 2000 y(annotated)16
b(with)f(the)h(action)g Fo(r)n(ebuild)f Ft(\(noted)h
Fo(r)n(eb)p Ft(\))f(m)o(ust)g(b)q(e)h(residualized)g(but)g(con)o(tain)f
(static)h(sub)q(comp)q(onen)o(ts)g(that)0 2050 y(can)c(b)q(e)g(ev)n
(aluated,)f(suc)o(h)i(as)f(the)g Fk(+)f Ft(op)q(erator.)18
b(The)12 b(\014nal)f(action,)g Fo(identity)h Ft(\(noted)g
Fo(id)t Ft(\),)g(indicates)g(that)g(a)f(construct)i(and)0
2100 y(all)h(of)g(its)h(sub)q(comp)q(onen)o(ts)g(are)g(dynamic.)20
b(These)c(constructs,)h(for)d(example)g Fk(return)20
b(res)p Ft(,)14 b(will)g(b)q(e)h(copied)g(v)o(erbatim)0
2149 y(in)o(to)e(the)i(residual)f(program.)0 2266 y Fp(2.3)56
b(Compile-Tim)o(e)15 b(Sp)r(ecialization)0 2342 y Ft(Since)j(the)g
(action-annotated)f(program)f(has)i(already)f(determined)g(ho)o(w)g
(eac)o(h)h(construct)h(will)d(b)q(e)i(transformed,)f(the)0
2392 y(sp)q(ecialization)g(phase)i(simply)c(tra)o(v)o(erses)k(the)g
(program)d(and)h(p)q(erforms)h(the)g(actions.)29 b(Compile-tim)o(e)15
b(sp)q(ecialization)0 2442 y(pro)q(duces)f(a)e(sp)q(ecialized)h
(program)e(written)i(in)f(the)h(source)h(language,)d(as)i(seen)g(in)f
(Figure)h(4.)k(The)c Fo(r)n(e)n(d)f Ft(lo)q(op)f(is)i(unrolled,)0
2492 y(residualizing)f(the)i Fo(r)n(eb)e Ft(assignmen)o(t)g(as)h(man)o
(y)e(times)h(as)i(the)f Fo(ev)g Ft(test)h(is)f(true.)19
b(The)13 b Fo(id)g Ft(return)h(statemen)o(t)f(is)g(repro)q(duced)0
2541 y(v)o(erbatim)f(in)i(the)g(sp)q(ecialized)h(program.)965
2795 y(3)p eop
%%Page: 4 4
4 3 bop 0 2 995 2 v 1074 2 877 2 v -1 756 2 756 v 44
185 a Fn(int)16 b(dotproduct\(i)o(nt)e(size)451 173 y
Fl(ev)501 185 y Fn(,)j(int)f(u[])660 173 y Fl(ev)710
185 y Fn(,)h(int)g(v[])870 173 y Fl(id)916 185 y Fn(\))44
224 y Fm(f)79 264 y Fn(\(int)f(i\))203 252 y Fl(ev)254
264 y Fn(;)79 305 y(\(int)g(res\))239 293 y Fl(id)285
305 y Fn(;)79 385 y(res)133 373 y Fl(id)179 385 y Fn(=)197
373 y Fl(r)q(eb)260 385 y Fn(0)278 373 y Fl(ev)328 385
y Fn(;)79 465 y(for)133 453 y Fl(r)q(ed)198 465 y Fn(\(\(i)g(=)i(0\))
340 453 y Fl(ev)390 465 y Fn(;)f(\(i)g(<)g(size\))603
453 y Fl(ev)652 465 y Fn(;)h(\(i++\))778 453 y Fl(ev)827
465 y Fn(\))114 506 y(res)168 494 y Fl(id)214 506 y Fn(=)232
494 y Fl(r)q(eb)295 506 y Fn(res)349 494 y Fl(id)395
506 y Fn(+)413 494 y Fl(r)q(eb)476 506 y Fn(\(u[i]\))584
494 y Fl(ev)632 506 y Fn(*)650 494 y Fl(r)q(eb)713 506
y Fn(v)731 494 y Fl(id)778 506 y Fn([i)814 494 y Fl(ev)864
506 y Fn(])882 494 y Fl(r)q(eb)945 506 y Fn(;)79 586
y(\(return)d(res\))292 575 y Fl(id)338 586 y Fn(;)44
626 y Fm(g)165 736 y Ft(Figure)f(3:)k(Action)13 b(annotated)h(program)p
994 756 V 1073 756 V 1300 63 a Fn(int)j(dotproduct)p
1552 63 11 2 v 9 w(5\(int)f(v[]\))1300 102 y Fm(f)1335
142 y Fn(int)h(res;)1335 221 y(res)g(=)g(0;)1335 300
y(res)g(=)g(res)g(+)g(14)g(*)g(v[1];)1335 339 y(res)g(=)g(res)g(+)g(38)
g(*)g(v[2];)1335 379 y(res)g(=)g(res)g(+)g(93)g(*)g(v[3];)1335
418 y(res)g(=)g(res)g(+)g(12)g(*)g(v[4];)1335 457 y(res)g(=)g(res)g(+)g
(39)g(*)g(v[5];)1335 536 y(return)f(res;)1300 576 y Fm(g)1099
686 y Ft(Figure)j(4:)29 b(Compile-tim)o(e)17 b(sp)q(ecialized)j
(program)1099 735 y Fr(\(w.r.t.)15 b Fn(size)10 b Fr(=)i(5,)f
Fn(u[])g Fr(=)h Fm(f)p Fr(14,)f(38,)g(93,)g(12,)f(39)p
Fm(g)p Fr(\))p 1950 756 2 756 v 0 757 995 2 v 1074 757
877 2 v 0 884 a Fp(2.4)56 b(Run-Time)16 b(Sp)r(ecialization)0
961 y Ft(The)i(action-annotated)f(program)f(can)i(also)f(b)q(e)i(used)f
(to)g(ac)o(hiev)o(e)f(run-time)g(sp)q(ecialization.)29
b(This)17 b(pro)q(cess)j(is)d(itself)0 1011 y(divided)f(in)o(to)g(t)o
(w)o(o)h(phases:)25 b(one)17 b(at)f(compile)f(time)h(and)g(one)h(at)g
(run)g(time.)25 b(A)o(t)17 b(compile)e(time,)h(the)h(co)q(de)h(fragmen)
o(ts)0 1061 y(\()p Fo(i.e.,)g(templates)p Ft(\))g(that)h(form)d(the)j
(building)e(blo)q(c)o(ks)h(of)f(the)i(p)q(ossible)f(sp)q(ecializations)
g(are)h(collected)g(and)f(compiled.)0 1110 y(F)m(urthermore,)12
b(the)h(source)h(program)d(of)h(a)g(sp)q(ecializer)h(is)f(pro)q(duced;)
i(this)e(sp)q(ecializer)i(in)o(tert)o(wines)f(static)g(computation)0
1160 y(and)e(op)q(erations)h(to)f(assem)o(ble)g(and)g(\014ll)g
(templates)f(with)i(run-time)e(v)n(alues.)17 b(A)o(t)11
b(run)h(time,)e(when)i(in)o(v)o(ok)o(ed,)f(the)h(compiled)0
1210 y(sp)q(ecializer)j(will)d(p)q(erform)h(these)i(op)q(erations)f(to)
f(construct)i(the)g(sp)q(ecialized)f(program.)i(W)m(e)e(no)o(w)f
(examine)f(eac)o(h)i(phase)0 1260 y(in)f(more)g(detail.)0
1368 y Fj(2.4.1)48 b(Sp)q(ecializatio)o(n)13 b(Grammars)0
1444 y Ft(Our)h(approac)o(h)g(to)f(run-time)g(sp)q(ecialization)g
(\014rst)h(consists)h(of)d(analyzing)h(an)g(action-annotated)g(program)
f(to)i(pro)q(duce)0 1494 y(a)i(tree)h(grammar)d(that)i(c)o
(haracterizes)i(the)f(set)g(of)f(all)f(p)q(ossible)h(sp)q
(ecializations)g(this)h(program)d(ma)o(y)g(yield.)25
b(Figure)16 b(5)0 1544 y(giv)o(es)f(the)g(sp)q(ecialization)g(gramma)o
(r)e(of)h(our)h(example.)20 b(The)15 b(\014rst)h(rule)f(de\014nes)h
(the)g(o)o(v)o(erall)e(shap)q(e)h(of)g(the)g(sp)q(ecialized)0
1594 y(pro)q(cedure.)26 b(The)16 b(non-terminal)e Fi(S)k
Ft(o)q(ccuring)e(in)g(this)g(rule)g(corresp)q(onds)h(to)f(the)h
(unrolled)e(lo)q(op.)23 b(The)16 b(second)h(rule)f(is)0
1644 y(recursiv)o(e;)g(it)f(sp)q(eci\014es)h(that)f Fi(S)j
Ft(ma)o(y)12 b(pro)q(duce)k(a)f(blo)q(c)o(k)f(con)o(taining)g(zero)h
(or)g(more)f(instances)i(of)e(the)h(lo)q(op)f(b)q(o)q(dy)m(.)21
b(The)0 1693 y(sym)o(b)q(ols)11 b Fi(I)s(nt)218 1699
y Fh(0)249 1693 y Ft(and)h Fi(I)s(nt)389 1699 y Fh(1)421
1693 y Ft(are)g(generic)i(terminals)d(that)h(represen)o(t)j(an)o(y)c
(in)o(teger)i(v)n(alue.)k(In)12 b(the)h(sp)q(ecialization)f(grammar)0
1743 y(of)j(an)h(expression,)h(a)f(generic)h(terminal)d(replaces)k(eac)
o(h)e(sub)q(expression)i(that)e(w)o(as)g(annotated)g(with)g
Fo(ev)g Ft(in)g(the)g(action)0 1793 y(tree.)j(These)13
b(generic)h(terminals)d(corresp)q(ond)j(to)e(the)h(holes)g(of)e(a)i
(template.)j(A)o(t)d(run)f(time,)f(they)i(will)e(b)q(e)i(\014lled)f
(with)g(the)0 1843 y(result)j(of)e(the)h(execution)h(of)e
Fo(ev)h Ft(expressions.)0 1951 y Fj(2.4.2)48 b(Generating)13
b(Extensions)0 2027 y Ft(F)m(rom)f(an)i(action-annotated)f(program)g
(and)g(the)i(sp)q(ecialization)e(grammar,)d(a)k(dedicated)h(sp)q
(ecializer)g(is)e(pro)q(duced.)62 2077 y(It)18 b(pro)q(duces)i
(residual)e(fragmen)o(ts)e(b)o(y)i(rewriting)g(non-terminals)e
(according)i(to)g(the)g(rules)h(of)e(the)h(sp)q(ecialization)0
2127 y(grammar,)9 b(and)j(computes)h(the)g Fo(ev)f Ft(statemen)o(ts)h
(and)f(expressions.)19 b(In)13 b(the)g(residual)f(fragmen)o(ts,)f(eac)o
(h)i(generic)h(terminal)0 2177 y(is)h(replaced)g(b)o(y)g(the)g(v)n
(alue)f(of)g(the)i(corresp)q(onding)f Fo(ev)g Ft(expression.)22
b(This)15 b(sp)q(ecializer,)g(called)f(a)h Fo(gener)n(ating)h
(extension)p Ft(,)0 2227 y(is)e(formally)d(de\014ned)k(in)e([4)o(].)62
2276 y(Figure)i(6)g(sho)o(ws)g(the)g(generating)g(extension)h(obtained)
e(for)h(our)f(example.)20 b(The)15 b(b)q(o)q(dy)g(of)f(the)h(residual)g
(pro)q(cedure)0 2326 y(\014rst)g(consists)g(of)e(the)i(non-terminal)c
Fi(F)6 b Ft(.)18 b(The)c(\014rst)h(rule)f(triggers)h(the)f(rewriting)g
(of)f Fi(F)20 b Ft(in)o(to)13 b(its)h(righ)o(t-hand)f(side.)19
b(Eac)o(h)0 2376 y(iteration)g(of)f(the)h(lo)q(op)g(adds)g(an)g(o)q
(ccurrence)i(of)e(the)g(righ)o(t-hand)f(side)i(of)e(the)i(second)g
(rule)f(instan)o(tiated)g(with)f(the)0 2426 y(appropriate)c(v)n(alues)g
(for)f Fi(I)s(nt)472 2432 y Fh(0)505 2426 y Ft(and)h
Fi(I)s(nt)647 2432 y Fh(1)666 2426 y Ft(.)62 2476 y(F)m(or)h(eac)o(h)h
(pro)q(cedure)h(to)e(b)q(e)h(sp)q(ecialized)f(at)g(run)h(time,)e(a)g
(corresp)q(onding)j(generating)e(extension)h(is)f(pro)q(duced.)23
b(A)0 2525 y(call)12 b(to)g(a)g(residual)h(pro)q(cedure)h(is)e
(represen)o(ted)j(b)o(y)e(a)f(call)g(to)g(a)g(generic)h(pro)q(cedure)i
(in)d(the)h(gramma)o(r)d(b)q(ecause)k(the)f(exact)0 2575
y(pro)q(cedure)f(can)d(only)g(b)q(e)i(determined)e(at)h(run)g(time.)15
b(The)10 b(generating)g(extension)g(then)h(includes)f(a)f(call)g(to)h
(the)g(generating)0 2625 y(extension)15 b(of)e(the)h(called)g(pro)q
(cedure)i(to)d(instan)o(tiate)h(the)h(generic)f(pro)q(cedure)i(with)e
(the)g(actual)g(sp)q(ecialization.)965 2795 y(4)p eop
%%Page: 5 5
5 4 bop 0 2 877 2 v 1045 2 907 2 v -1 823 2 824 v 111
276 a Fg(F)64 b Fm(!)59 b Fn(int)17 b(dotproduct)p 543
276 11 2 v 9 w(SSD\(int)e(u[]\))291 315 y Fm(f)327 354
y Fn(int)h(res;)327 433 y(res)g(=)i(0;)327 512 y Fg(S)r
Fn(;)327 552 y(return)d(res;)291 591 y Fm(g)111 654 y
Fg(S)56 b Fm(!)223 642 y Fs(\003)291 654 y Fn(res)17
b(=)g(res)g(+)g Fg(I)s(nt)555 659 y Ff(0)590 654 y Fn(*)g(v[)p
Fg(I)s(nt)713 659 y Ff(1)730 654 y Fn(];)133 803 y Ft(Figure)d(5:)k(Sp)
q(ecialization)13 b(grammar)p 876 823 2 824 v 1044 823
V 1147 63 a Fn(int)j(gen)p 1273 63 11 2 v 12 w(dotproduct)p
1464 63 V 9 w(SSD\(int)f(size,)h(int)h(u[]\))1147 102
y Fm(f)1182 142 y Fn(int)g(i;)1182 221 y Fg(F)c Fm(!)p
Fn(int)k(dotproduct)p 1505 221 V 9 w(SSD\(int)e(u[]\))1253
260 y Fm(f)1288 300 y Fn(int)h(res;)1288 339 y(res)g(=)i(0;)f
Fe(S)p Fn(;)g(return)e(res;)1253 379 y Fm(g)1182 457
y Fn(for)i(\(i)f(=)i(0;)f(i)g(<)g(size;)f(i++\))1182
497 y Fm(f)1217 536 y Fg(S)c Fm(!)18 b Fn(res)f(=)g(res)g(+)g
Fg(I)s(nt)1567 541 y Ff(0)1602 536 y Fn(*)g(v[)p Fg(I)s(nt)1725
541 y Ff(1)1742 536 y Fn(];)1217 576 y Fg(I)s(nt)1269
581 y Ff(0)1296 576 y Fm(\))h Fn(u[i];)1217 615 y Fg(I)s(nt)1269
620 y Ff(1)1296 615 y Fm(\))g Fn(i;)1182 655 y Fm(g)1147
694 y(g)1214 803 y Ft(Figure)c(6:)k(Generating)c(extension)p
1950 823 2 824 v 0 825 877 2 v 1045 825 907 2 v 0 879
877 2 v 1045 879 907 2 v -1 1775 2 898 v 97 1072 615
2 v 96 1321 2 249 v 122 1151 a Fn(int)j(dotproduc)o(t)p
374 1151 11 2 v 10 w(SSD\(int)e(u[]\))122 1191 y Fm(f)157
1230 y Fn(int)i(res;)157 1309 y(res)g(=)g(0;)p 711 1321
2 249 v 97 1322 615 2 v 761 1072 a Fg(t)774 1077 y Ff(1)p
97 1389 V 96 1480 2 91 v 157 1468 a Fn(res)g(=)g(res)g(+)g(<)p
Fg(H)416 1473 y Ff(0)433 1468 y Fn(>)g(*)g(v[<)p Fg(H)586
1473 y Ff(1)603 1468 y Fn(>])11 b Fr(;)p 711 1480 V 97
1482 615 2 v 761 1389 a Fg(t)774 1394 y Ff(2)p 97 1549
V 96 1679 2 131 v 157 1628 a Fn(return)16 b(res;)122
1667 y Fm(g)p 711 1679 V 97 1681 615 2 v 761 1549 a Fg(t)774
1554 y Ff(3)254 1755 y Ft(Figure)e(7:)k(T)m(emplates)p
876 1775 2 898 v 1044 1775 V 1148 940 615 2 v 1147 1187
2 249 v 1172 1018 a Fn(int)f(dotproduct)p 1424 1018 11
2 v 9 w(SSD\(int)e(u[]\))1172 1057 y Fm(f)1208 1096 y
Fn(int)h(res;)1208 1175 y(res)g(=)i(0;)p 1761 1187 2
249 v 1787 966 a Fg(t)1800 971 y Ff(1)p 1148 1189 615
2 v 1183 1254 a Fn(for)e(\()i(;)f(unknown)p 1452 1254
11 2 v 10 w(test)f(;)i(\))1183 1294 y Fm(f)p 1148 1333
615 2 v 1147 1422 2 91 v 1208 1410 a Fn(res)e(=)i(res)e(+)h(<)p
Fg(H)1466 1415 y Ff(0)1483 1410 y Fn(>)h(*)f(v[<)p Fg(H)1637
1415 y Ff(1)1653 1410 y Fn(>])g(;)p 1761 1422 V 1787
1359 a Fg(t)1800 1364 y Ff(2)p 1148 1424 615 2 v 1183
1489 a Fm(g)p 1148 1529 V 1147 1657 2 131 v 1208 1606
a Fn(return)e(res;)1172 1645 y Fm(g)p 1761 1657 V 1787
1554 a Fg(t)1800 1559 y Ff(3)p 1148 1659 615 2 v 1152
1755 a Ft(Figure)f(8:)k(Source)d(com)o(bining)c(templates)p
1950 1775 2 898 v 0 1777 877 2 v 1045 1777 907 2 v 62
1904 a(Although)17 b(the)h(generating)g(extension)g(is)f(a)g(real)g
(pro)q(cedure,)j(it)d(is)g(not)h(e\013ectiv)o(ely)g(run.)29
b(Instead,)19 b(it)e(is)g(used)h(to)0 1953 y(deriv)o(e)c(b)q(oth)g(the)
h Fo(obje)n(ct)g(templates)e Ft(and)h(the)g(run-time)f(sp)q(ecializer.)
0 2061 y Fj(Deriving)f(ob)s(ject)h(templates.)39 b Ft(First,)13
b(the)h(righ)o(t-hand)e(side)h(of)f(eac)o(h)i(gramma)o(r)c(rule)k(of)e
(the)h(generating)g(extension)0 2111 y(is)k(con)o(v)o(erted)h(in)o(to)f
(a)f(set)j(of)d Fo(sour)n(c)n(e)i(templates)p Ft(.)27
b(A)17 b(template)g([8)o(])f(is)h(a)g(fragmen)o(t)f(of)g(co)q(de)i
(parameterized)f(b)o(y)g Fo(holes)p Ft(.)0 2161 y(When)h(the)g(righ)o
(t-hand)f(side)g(of)g(a)g(sp)q(ecialization)g(grammar)e(rule)j
(includes)f(a)h(non-terminal,)e(a)h(source)i(template)d(is)0
2211 y(created)e(b)q(efore)f(and)g(after)f(this)h(non-terminal.)j
(Within)11 b(a)h(template)g(eac)o(h)h(generic)g(terminal)e(is)h
(represen)o(ted)k(b)o(y)c(a)g(hole)0 2261 y(and)i(eac)o(h)g(call)f(to)h
(a)g(generic)g(pro)q(cedure)i(is)e(represen)o(ted)j(b)o(y)c(a)h
Fo(c)n(al)r(l)g(hole)p Ft(.)62 2310 y(Figure)c(7)g(sho)o(ws)h(the)f
(templates)g(of)f(our)i(example.)k(The)c(\014rst)f(rule)h(of)e(the)i
(sp)q(ecialization)f(gramma)o(r)e(yields)i(templates)0
2360 y Fi(t)15 2366 y Fh(1)47 2360 y Ft(and)k Fi(t)143
2366 y Fh(3)162 2360 y Ft(.)k(The)c(second)h(rule)f(pro)q(duces)i
(template)d Fi(t)857 2366 y Fh(2)875 2360 y Ft(,)h(whic)o(h)f(con)o
(tains)h(holes)g Fi(H)1321 2366 y Fh(0)1353 2360 y Ft(and)g
Fi(H)1469 2366 y Fh(1)1487 2360 y Ft(.)62 2410 y(In)h(order)h(to)f
(obtain)f(the)i(ob)r(ject)g(templates)e(from)g(the)h(source)i
(templates,)d(they)i(are)f(compiled)f(using)g(an)h(existing)0
2460 y(compiler.)h(Note)11 b(that)g(this)h(compilation)c(happ)q(ens)k
(at)f(compile)e(time.)16 b(In)11 b(order)h(to)f(allo)o(w)e(the)j
(compiler)e(to)h(optimize)e(the)0 2510 y(templates)j(globally)m(,)d(w)o
(e)k(com)o(bine)e(source)j(templates)d(in)o(to)h(a)g(single)g(program)f
(that)h(expresses)j(ho)o(w)d(the)h(templates)f(can)0
2559 y(b)q(e)i(assem)o(bled)e(at)h(run)g(time.)j(Figure)d(8)g(sho)o(ws)
g(the)h(corresp)q(onding)g(source)g(co)q(de)g(for)f(our)g(example.)j
(This)d(co)q(de)h(follo)o(ws)0 2609 y(the)g(structure)i(of)d(the)h(sp)q
(ecialization)f(grammar.)i(F)m(or)e(example,)f(template)h
Fi(t)1254 2615 y Fh(2)1286 2609 y Ft(is)h(compiled)e(in)h(a)g(for)g(lo)
q(op)g(b)q(ecause)i(the)0 2659 y(sp)q(ecialization)e(ma)o(y)f
(duplicate)i(it)g(man)o(y)e(times.)965 2795 y(5)p eop
%%Page: 6 6
6 5 bop 0 14 1979 2 v 0 769 2 756 v 555 61 a Fk(int)22
b(rts)p 712 61 14 2 v 15 w(dotproduct)p 947 61 V 13 w(SSD\(int)f(size,)
f(int)i(u[]\))555 111 y Fq(f)599 161 y Fk(int)f(i;)599
261 y(dump)p 690 261 V 15 w(template\()p Fi(t)915 267
y Fh(1)932 261 y Fk(\);)599 311 y(for)g(\(i)h(=)f(0;)g(i)h(<)g(size;)e
(i++\))599 360 y Fq(f)643 410 y Fk(dump)p 734 410 V 14
w(template\()p Fi(t)958 416 y Fh(2)975 410 y Fk(\);)643
460 y(instantiate)p 888 460 V 13 w(hole\()p Fi(t)1023
466 y Fh(2)1041 460 y Fk(,)h Fi(h)1108 466 y Fh(0)1127
460 y Fk(,)g(u[i]\);)643 510 y(instantiate)p 888 510
V 13 w(hole\()p Fi(t)1023 516 y Fh(2)1041 510 y Fk(,)g
Fi(h)1108 516 y Fh(1)1127 510 y Fk(,)g(i\);)599 560 y
Fq(g)599 609 y Fk(dump)p 690 609 V 15 w(template\()p
Fi(t)915 615 y Fh(3)932 609 y Fk(\);)555 659 y Fq(g)713
749 y Ft(Figure)14 b(9:)j(Run-time)c(sp)q(ecializer)p
1977 769 2 756 v 0 771 1979 2 v 62 895 a(Once)j(this)g(program)d(is)i
(compiled,)e(w)o(e)i(need)h(to)f(b)q(e)h(able)e(to)h(lo)q(cate)g(the)h
(ob)r(ject)g(templates,)e(holes,)h(and)g(call)f(holes)0
945 y(in)g(the)g(compiled)f(program.)k(This)d(is)f(the)i(only)e(asp)q
(ect)j(of)d(our)h(approac)o(h)g(that)g(is)g(mac)o(hine)f(and)h
(compiler)f(dep)q(enden)o(t.)0 995 y(W)m(e)g(defer)i(discussion)g(of)e
(these)i(issues)g(to)f(the)g(next)h(section.)0 1103 y
Fj(Deriving)j(the)j(run-time)d(sp)q(ecializer.)39 b Ft(The)19
b(generating)g(extension,)h(whic)o(h)e(manipulates)f(grammar)e(rules,)
20 b(is)0 1153 y(also)15 b(used)h(to)g(deriv)o(e)g(the)g(run-time)f(sp)
q(ecializer,)h(whic)o(h)g(manipulates)e(ob)r(ject)i(templates.)23
b(Figure)15 b(9)h(sho)o(ws)g(the)g(run-)0 1202 y(time)d(sp)q(ecializer)
i(obtained)e(for)h(our)g(example.)j(Grammar)11 b(rules)k(of)e(the)i
(generating)f(extension)h(are)f(transformed)g(in)o(to)0
1252 y(instructions)g(that)f(cop)o(y)h(the)g(appropriate)f(ob)r(ject)h
(templates)f(\()p Fk(dump)p 1127 1252 14 2 v 15 w(template)p
Ft(\).)j(Rules)e(used)g(to)f(instan)o(tiate)g(generic)0
1302 y(terminals)g(are)i(translated)g(in)o(to)e(instructions)i(that)g
(\014ll)e(holes)i(\()p Fk(instantiate)p 1278 1302 V 13
w(hole)p Ft(\).)k(Call)13 b(holes)h(are)h(instan)o(tiated)f(in)0
1352 y(a)g(similar)d(w)o(a)o(y)m(.)0 1460 y Fj(2.4.3)48
b(Run-Time)14 b(Phase)0 1536 y Ft(Because)19 b(ev)o(erything)f(is)f
(precompiled)f(at)h(compile)f(time,)g(there)i(is)f(v)o(ery)h(little)e
(to)h(do)g(at)g(run)h(time)e(to)h(generate)h(the)0 1586
y(sp)q(ecialized)d(co)q(de.)j(W)m(e)c(simply)d(ev)n(aluate)j(the)g
(static)g(parts)h(of)e(the)h(program,)e(cop)o(ying)h(templates)g(and)h
(\014lling)e(holes)i(as)0 1636 y(directed)h(b)o(y)f(the)g(run-time)f
(sp)q(ecializer.)0 1773 y Fu(3)67 b(Impleme)o(n)n(ting)21
b(Run-Time)h(Sp)r(ecialization)0 1864 y Ft(The)17 b(approac)o(h)f
(presen)o(ted)j(in)d(Section)h(2)f(is)g(general)h(enough)f(to)h(b)q(e)g
(adapted)f(to)h(an)o(y)f(compiler)f(and)h(mac)o(hine.)24
b(Our)0 1914 y(implemen)o(tatio)o(n)9 b(w)o(as)i(done)h(with)f(b)q(oth)
g(the)h Fk(gcc)f Ft(compiler)f(and)h Fk(lcc)g Ft(compiler)f(on)h(a)g
(Sparc)h(arc)o(hitecture.)19 b(This)11 b(section)0 1964
y(addresses)17 b(sp)q(eci\014c)f(implemen)o(tation)11
b(issues.)22 b(These)16 b(issues)g(include)f(preparing)g(the)g(source)h
(templates,)e(lo)q(cating)g(the)0 2014 y(ob)r(ject)i(templates,)e(and)g
(dealing)g(with)h(in)o(terferences)i(caused)f(b)o(y)e(compiler)g
(optimizations.)k(As)d(w)o(ell,)f(w)o(e)h(discuss)h(the)0
2064 y(costs)f(in)o(v)o(olv)o(ed)e(with)g(run-time)g(sp)q
(ecialization.)k(Except)e(where)g(noted,)f(this)g(discussion)h(applies)
e(to)h(b)q(oth)g(compilers.)0 2180 y Fp(3.1)56 b(F)-5
b(rom)17 b(source)i(templates)d(to)i(ob)s(ject)h(templates)0
2256 y Ft(In)d(order)g(to)g(\014nd)g(the)g(starting)g(address)h(and)e
(ending)h(address)h(of)e(eac)o(h)h(ob)r(ject)h(template,)e(w)o(e)g(in)o
(tro)q(duce)i(an)e(explicit)0 2306 y(lab)q(el)h(b)q(efore)g(and)g
(after)h(eac)o(h)f(source)i(template.)23 b(A)16 b Fk(gcc)g
Ft(extension)h(of)e(the)i(C)f(language)f(mak)o(es)g(it)h(p)q(ossible)g
(to)g(tak)o(e)0 2356 y(the)e(address)h(of)e(these)i(lab)q(els,)f(whic)o
(h)f(are)h(then)h(stored)f(in)f(an)h(arra)o(y)m(.)j(Because)f(it)d(is)h
(imp)q(ossible)e(to)h(put)h(lab)q(els)g(outside)0 2406
y(of)h(a)f(pro)q(cedure,)j(w)o(e)f(cannot)f(use)h(lab)q(els)f(to)g
(mark)e(the)j(b)q(eginning)e(of)h(the)h(\014rst)g(template)e(or)h(the)h
(end)f(of)g(the)g(last.)22 b(In)0 2456 y(the)14 b(former)f(case,)h(it)g
(su\016ces)h(to)e(use)i(the)f(address)h(of)e(the)i(pro)q(cedure)g
(itself,)e(and)h(in)f(the)h(latter)g(case,)h(the)f(address)h(of)e(a)0
2505 y(dumm)o(y)e(pro)q(cedure,)k(put)f(just)g(after)h(the)f(pro)q
(cedure,)h(is)f(used.)62 2555 y(A)e(hole)f(in)g(a)h(template)e
(represen)o(ts)k(a)e(constan)o(t)g(v)n(alue)f(that)g(will)f(b)q(e)j
(\014lled)e(in)g(during)g(sp)q(ecialization.)17 b(W)m(e)11
b(w)o(ould)g(lik)o(e)0 2605 y(to)j(let)h(the)g(compiler)e(kno)o(w)h
(that)h(a)f(v)n(alue)g(is)g(a)g(constan)o(t)h(so)g(that)f(the)h(v)n
(alue)f(can)h(b)q(e)g(enco)q(ded)h(in)e(an)g(instruction,)h(but)0
2655 y(without)c(sp)q(ecifying)f(the)i(sp)q(eci\014c)g(v)n(alue,)f
(whic)o(h)g(w)o(ould)f(incorrectly)i(trigger)f(compiler)e
(optimizations)g(suc)o(h)i(as)g(constan)o(t)965 2795
y(6)p eop
%%Page: 7 7
7 6 bop 0 42 a Ft(folding.)20 b(This)15 b(is)g(ac)o(hiev)o(ed)g(b)o(y)g
(inserting)h(the)f(expression)i Fk(\(type\)&h)c Ft(at)i(the)h(hole)e
(lo)q(cation,)g(where)j Fk(h)e Ft(is)g(an)f(external)0
91 y(sym)o(b)q(ol)f(and)h Fk(\(type\))f Ft(is)i(a)f(cast)h(to)g(the)g
(t)o(yp)q(e)g(of)f(the)h(constan)o(t.)20 b(In)15 b(addition)e(to)i
(generating)f(the)h(desired)h(instruction,)0 141 y(the)d(compiler)f
(also)g(pro)q(duces)i(relo)q(cation)e(records)j(for)d(the)h(external)h
(sym)o(b)q(ols,)d(whic)o(h)h(are)h(used)h(to)f(compute)f(the)h
(o\013set)0 191 y(of)e(a)h(hole)f(within)g(its)h(template.)k(Similarly)
l(,)9 b(a)i(call)g(hole)h(is)f(represen)o(ted)k(b)o(y)c(the)i
(expression)g Fk(*\(\(type\)&h\)\()p Fi(:)7 b(:)f(:)m
Fk(\))p Ft(,)11 b(whic)o(h)0 241 y(pro)q(duces)k(a)f(direct)h(call.)i
(Figure)d(10)f(sho)o(ws)i(the)f(program)e(com)o(bining)g(the)i(source)i
(templates)d(for)g(our)h(example.)62 291 y(W)m(e)i(also)f(need)i(to)f
(enco)q(de)i(the)e(conditional)f(and)h(lo)q(op)f(tests)j(that)e(are)g
(used)h(at)f(sp)q(ecialization)g(time)e(to)i(com)o(bine)0
340 y(templates.)h(Similarl)o(y)m(,)8 b(external)k(sym)o(b)q(ols)e(are)
h(used)i(to)e(represen)o(t)i(constan)o(t)f(tests,)h(indicating)d(that)h
(the)h(test)h(is)e(kno)o(wn,)0 390 y(but)j(prev)o(en)o(ting)g(the)h
(compiler)d(from)g(optimizing)g(a)o(w)o(a)o(y)g(one)j(branc)o(h)f
(during)f(compilation.)p 0 462 1979 2 v 0 1956 2 1494
v 118 616 a Fk(extern)20 b(int)i(S;)118 666 y(extern)e(int)i(H0,)f(H1;)
118 716 y(int)g(dotproduct)p 428 716 14 2 v 14 w(SSD\(int)f(u[]\))118
766 y Fq(f)161 815 y Fk(static)h(void)g(*label)p 558
815 V 14 w(array[])g(=)g Fq(f)205 865 y Fk(\(void)g(*\)&dotproduct,)e
(&&)i(temp1)p 841 865 V 15 w(end,)205 915 y(&&)g(temp2)p
383 915 V 15 w(start,)g(&&)g(temp2)p 726 915 V 15 w(end,)205
965 y(&&)g(temp3)p 383 965 V 15 w(start,)g(\(void\)*)p
705 965 V 14 w(dotproduct)p Fq(g)p Fk(;)161 1064 y(int)h(res;)161
1164 y(res)g(=)f(0;)161 1214 y(temp1)p 274 1214 V 15
w(end:)161 1264 y(for)h(\()f(;)h(S==0)f(;)g(\))161 1314
y Fq(f)205 1363 y Fk(temp2)p 318 1363 V 15 w(start:)249
1413 y(res)g(=)g(res)h(+)f(\(int\)&H0)f(*)i(v[\(int\)&H1];)205
1463 y(temp2)p 318 1463 V 15 w(end:)161 1513 y Fq(g)161
1563 y Fk(temp3)p 274 1563 V 15 w(start:)161 1612 y(return)f(res;)118
1662 y Fq(g)118 1762 y Fk(int)p 208 1762 V 37 w(dotproduct\(void\))o
Fq(fg)562 1934 y Ft(Figure)14 b(10:)k(Source)c(com)o(bining)e
(templates)h(for)h Fk(gcc)p 1977 1956 2 1494 v 0 1958
1979 2 v 0 2116 a Fp(3.2)56 b(Pro)r(cessing)17 b(ob)s(ject)i(templates)
0 2192 y Ft(After)c(the)f(source)i(templates)d(ha)o(v)o(e)h(b)q(een)h
(compiled,)d(the)j Fo(template)g(c)n(ompiler)e Ft(analyses)h(the)h
(resulting)f(ob)r(ject)h(co)q(de)g(to)0 2242 y(extract)i(information)d
(for)h(the)i(run-time)e(sp)q(ecializer.)26 b(The)17 b(template)e
(compiler)g(computes)h(the)h(address)h(and)e(size)h(of)0
2292 y(eac)o(h)f(template)f(using)g(the)h(v)n(alues)g(stored)g(in)g
(the)g(lab)q(el)f(arra)o(y)m(.)22 b(The)16 b(table)g(of)f(relo)q
(cation)g(records)i(con)o(tains)f(the)g(hole)0 2342 y(addresses.)k(The)
14 b(template)f(compiler)g(then)h(determines)h(the)f(o\013set)h(of)e
(eac)o(h)i(hole)e(and)h(call)f(hole)h(within)f(a)g(template.)62
2391 y(Because)19 b(a)d(run-time)f(sp)q(ecializer)j(pro)q(duces)g(co)q
(de)f(b)o(y)f(cop)o(ying)g(the)h(ob)r(ject)g(templates,)f(some)g(branc)
o(hes)i(ma)o(y)c(b)q(e)0 2441 y(in)o(v)n(alid.)19 b(On)c(a)g(Sparc)g
(arc)o(hitecture,)i(since)e(all)f(branc)o(hes)i(are)f(relativ)o(e)g(to)
g(the)g(program)f(coun)o(ter,)h(mo)o(ving)d(a)j(blo)q(c)o(k)g(of)0
2491 y(co)q(de)f(con)o(taining)f(a)g(branc)o(h)h(outside)g(the)g(blo)q
(c)o(k)g(in)o(v)n(alidates)e(the)i(jump.)i(Therefore,)f(the)f(template)
f(compiler)f(searc)o(hes)0 2541 y(the)i(ob)r(ject)h(co)q(de)g(for)e(in)
o(ter-template)h(branc)o(hes)h(and)e(branc)o(hes)j(to)d(other)i(pro)q
(cedures)h(or)e(library)f(calls.)62 2591 y(The)j(output)g(of)f(the)h
(template)f(compiler)f(is)i(the)g(ob)r(ject)g(\014le)g(returned)h(b)o
(y)f Fk(gcc)f Ft(and)g(a)g(template)g(description)h(\014le.)0
2641 y(This)e(\014le)g(con)o(tains)f(the)i(addresses)h(and)d(sizes)i
(of)f(templates,)f(the)h(list)f(of)h(the)g(o\013sets)h(of)e(holes)h
(and)g(call)f(holes,)h(and)f(the)965 2795 y(7)p eop
%%Page: 8 8
8 7 bop 0 42 a Ft(list)13 b(of)h(branc)o(hes)h(that)f(need)h(to)e(b)q
(e)i(relo)q(cated)g(when)f(assem)o(bling)e(templates.)0
158 y Fp(3.3)56 b(Optimizing)16 b(T)-5 b(emplates)0 234
y Ft(Care)15 b(m)o(ust)e(b)q(e)h(tak)o(en)h(when)f(considering)h(what)f
(optimizations)e(to)i(p)q(erform)f(while)h(compiling)d(templates.)18
b(The)d(main)0 284 y(concern)22 b(is)f(to)f(insure)i(that)e(the)i(ob)r
(ject)f(templates)f(remain)f(in)o(tact.)39 b(V)m(arious)20
b(transformations)f(that)i(optimizing)0 334 y(compilers)9
b(p)q(erform,)h(suc)o(h)i(as)e(co)q(de)i(motion,)c(ma)o(y)h(mix)f
(instructions)j(b)q(et)o(w)o(een)h(templates.)17 b(This)10
b(w)o(ould)g(mak)o(e)f(template)0 384 y(extraction)14
b(extremely)g(di\016cult)f(or)h(imp)q(ossible.)j(The)d(t)o(yp)q(es)h
(of)e(optimizations)f(p)q(erformed)h(dep)q(end)j(on)d(the)i(compiler.)0
434 y Fk(lcc)p Ft(,)i(for)f(example,)g(only)h(p)q(erforms)f(in)o
(tra-blo)q(c)o(k)g(program)g(transformations)f([6].)27
b(Since)17 b(templates)g(only)f(consist)i(of)0 483 y(complete)13
b(blo)q(c)o(ks,)h(it)f(is)h(not)g(p)q(ossible)g(for)f(optimizations)f
(to)i(corrupt)h(templates.)62 533 y(More)20 b(p)q(o)o(w)o(erful)f
(optimizations,)e(suc)o(h)j(as)f(those)h(found)f(in)g
Fk(gcc)f Ft(when)i(optimizing)c(at)j(lev)o(el)g(2,)h(are)f(capable)h
(of)0 583 y(in)o(terfering)15 b(with)g(template)f(in)o(tegrit)o(y)m(.)
21 b(The)15 b(fact)h(that)f(lab)q(els)g(delimit)e(templates,)h(ho)o(w)o
(ev)o(er,)h(prohibits)g(a)g(n)o(um)o(b)q(er)g(of)0 633
y(in)o(ter-template)e(transformations.)62 683 y(Additional)i(in)o
(terferences)k(that)d(ma)o(y)e(o)q(ccur)j(are)g(dealt)f(with)g(in)f
(one)i(of)e(t)o(w)o(o)h(w)o(a)o(ys.)25 b(A)16 b(simple)f(solution)g(in)
o(v)o(olv)o(es)0 732 y(disabling)f(the)j(sp)q(eci\014c)g(optimization)c
(that)j(is)f(causing)h(the)g(in)o(terference.)26 b(Another)17
b(approac)o(h)e(is)h(to)g(tak)o(e)g(the)g(in)o(ter-)0
782 y(ferences)i(in)o(to)e(accoun)o(t.)25 b(F)m(or)16
b(example,)f(holes)h(should)g(only)g(b)q(e)g(referenced)j(within)d
(templates.)24 b(But)17 b(the)g(aggressiv)o(e)0 832 y(optimizer)f(of)g
Fk(gcc)h Ft(ma)o(y)e(sc)o(hedule)k(instructions)e(out)h(of)e(order)i
(to)f(b)q(etter)i(\014ll)d(the)i(pro)q(cessor)h(pip)q(eline.)27
b(Our)18 b(system)0 882 y(detects)e(this)e(case)h(and)e(ensures)j(that)
e(the)h(hole)e(reference)k(also)c(correctly)i(o)q(ccurs)g(within)e(its)
h(template.)0 998 y Fp(3.4)56 b(Cost)19 b(of)g(Run-Time)d(Sp)r
(ecialization)0 1075 y Ft(The)g(cost)h(of)e(p)q(erforming)f(run-time)g
(sp)q(ecialization)i(is)f(the)h(sum)f(of)g(the)i(cost)f(of)f(p)q
(erforming)f(the)j(static)f(calculations)0 1125 y(plus)g(the)h(cost)h
(of)d(generating)i(co)q(de.)27 b(In)16 b(the)h(dot)f(pro)q(duct)i
(example)d(\(Figure)i(9\))f(the)h(static)g(calculations)e(consist)j(of)
0 1174 y(executing)g(the)g(lo)q(op)e(and)i(calculating)e(the)i(hole)f
(v)n(alues)g Fk(u[i])f Ft(and)h Fk(i)p Ft(.)28 b(P)o(erforming)16
b(as)h(man)o(y)f(static)h(computations)0 1224 y(as)f(p)q(ossible)h(is)f
(adv)n(an)o(tageous,)g(since)h(they)g(are)g(p)q(erformed)f(once)h
(during)f(sp)q(ecialization)g(instead)h(of)f(man)o(y)e(times)h(in)0
1274 y(the)j(sp)q(ecialized)g(co)q(de.)28 b(Although)17
b(static)g(computations)f(increase)i(the)g(o)o(v)o(erall)e(run-time)g
(sp)q(ecialization)g(cost,)i(it)f(is)0 1324 y(reco)o(v)o(ered)f(when)e
(the)g(sp)q(ecialized)h(co)q(de)g(is)f(called)f(more)g(than)h(once.)62
1374 y(In)g(our)g(system,)g(on)f(the)i(other)g(hand,)e(the)i(o)o(v)o
(erhead)f(of)g(generating)g(co)q(de)h(do)q(es)f(not)g(impro)o(v)o(e)e
(the)j(co)q(de)g(qualit)o(y)e(of)0 1423 y(the)f(residual)f(program,)f
(and)h(therefore)i(m)o(ust)d(b)q(e)i(k)o(ept)g(to)f(a)g(minim)n(um)o(.)
j(This)d(o)o(v)o(erhead)h(includes)g(dumping)d(templates,)0
1473 y(instan)o(tiating)i(holes)i(and)f(call)g(holes,)g(and)h(relo)q
(cating)f(jumps.)k(In)d(practice,)g(only)f(the)h(pro)q(cedures)i(to)d
(dump)g(templates)0 1523 y(and)i(instan)o(tiate)g(holes)g(are)g
(commonly)d(used)k(\(as)f(in)g(the)g(example)f(in)h(Figure.)f(9\),)h
(since)g(the)h(need)g(to)f(instan)o(tiate)g(call)0 1573
y(holes)g(or)g(relo)q(cate)h(jumps)d(o)q(ccurs)k(rarely)m(.)62
1623 y(Dumping)c(templates)h(consists)i(of)f(cop)o(ying)f(precomputed)h
(template)f(instructions)i(in)o(to)e(the)i(appropriate)f(sp)q(ecial-)0
1672 y(ization)k(bu\013er)h(and)f(\015ushing)h(the)g(cac)o(he)g(to)f
(insure)i(its)e(coherency)m(.)33 b(The)19 b(cost)g(of)f(cop)o(ying)g
(instructions)h(is)f(simply)0 1722 y(the)h(cost)f(of)f(the)i(memory)c
(cop)o(y)j(of)g(a)f(mac)o(hine.)29 b(In)18 b(our)g(system,)g(only)f
(six)h(instructions)h(\(including)e(\015ushing\))h(are)0
1772 y(executed)e(for)d(eac)o(h)h(instruction)g(generated.)19
b(W)m(e)13 b(found)h(that)f(on)h(a)f(Sparc)h(pro)q(cessor)i(the)e(cost)
g(of)f(\015ushing)h(t)o(w)o(o)f(w)o(ords)0 1822 y(is)h(negligible.)62
1872 y(Filling)i(holes)h(simply)e(consists)j(of)f(writing)g(the)h
(precomputed)f(hole)g(v)n(alue)g(to)g(the)h(appropriate)f(lo)q(cation)g
(in)f(the)0 1922 y(sp)q(ecialization)j(bu\013er.)35 b(On)19
b(the)h(Sparc)g(arc)o(hitecture,)i(an)c(immediate)f(v)n(alue)h(is)h
(the)h(same)e(size)i(as)g(an)f(instruction)0 1971 y(\(32)d(bits\).)26
b(Therefore,)17 b(the)g(immediate)d(v)n(alue)i(is)g(divided)g(in)o(to)f
(t)o(w)o(o)h(halv)o(es,)h(and)f(then)h(eac)o(h)g(half)e(is)h(written)h
(to)f(the)0 2021 y(appropriate)e(lo)q(cation.)j(Filling)12
b(call)h(holes)h(is)g(similar,)d(but)j(since)h(the)f(call)g(hole)f(v)n
(alue)h(is)f(an)h(address)h(instead)f(of)g(data,)0 2071
y(the)j(v)n(alue)f(do)q(es)h(not)f(need)h(to)f(b)q(e)h(split.)25
b(Th)o(us,)17 b(only)e(one)i(write)f(is)h(necessary)m(.)26
b(On)17 b(a)f(Sparc)h(pro)q(cessor)h(\014lling)d(holes)0
2121 y(costs)j(11)e(instructions)i(for)e(v)n(alue)g(holes)h(and)g(8)f
(instructions)i(for)e(call)g(holes.)27 b(Finally)m(,)15
b(relo)q(cating)i(library)f(calls)g(and)0 2171 y(branc)o(hes)f(costs)g
(14)e(instructions)i(on)f(a)o(v)o(erage.)62 2220 y(Th)o(us)g(there)i
(is)d(v)o(ery)i(little)e(o)o(v)o(erhead)h(at)g(run)g(time)e(to)i
(construct)i(the)e(sp)q(ecialized)h(program.)0 2358 y
Fu(4)67 b(Exp)r(erimen)n(tal)23 b(Study)0 2449 y Ft(W)m(e)14
b(no)o(w)g(analyze)g(the)h(p)q(erformance)f(of)g(our)h(approac)o(h)f
(to)g(run-time)f(sp)q(ecialization.)19 b(In)c(con)o(trast)g(to)f
(earlier)h(systems)0 2498 y(that)h(pro)q(duce)g(sp)q(ecialized)g(co)q
(de)h(at)e(run)h(time,)e(w)o(e)i(do)f(not)g(in)o(v)o(ok)o(e)g(a)g
(compiler)f(after)i(sp)q(ecialization.)22 b(Consequen)o(tly)0
2548 y(the)15 b(n)o(um)o(b)q(er)f(of)f(times)h(the)h(sp)q(ecialized)g
(co)q(de)g(needs)g(to)g(b)q(e)f(in)o(v)o(ok)o(ed)g(to)g(amortize)f(the)
i(cost)g(of)f(sp)q(ecialization)g(is)g(quite)0 2598 y(lo)o(w.)965
2795 y(8)p eop
%%Page: 9 9
9 8 bop 62 42 a Ft(Although)19 b(limiting)e(the)j(run-time)f(o)o(v)o
(erhead)h(is)g(desirable,)h(b)o(y)e(not)h(compiling)d(after)j(sp)q
(ecialization,)g(w)o(e)g(miss)0 91 y(compiler)e(optimizations)f(that)i
(could)h(b)q(e)g(enabled)f(b)o(y)g(sp)q(ecialization.)34
b(F)m(urthermore,)21 b(the)f(compiler)e(ma)o(y)f(not)i(b)q(e)0
141 y(able)c(to)g(generate)h(highly)e(optimized)f(co)q(de)j(for)f
(templates.)21 b(When)15 b(a)g(template)f(is)h(small,)d(the)k(compiler)
e(cannot)h(tak)o(e)0 191 y(adv)n(an)o(tage)9 b(of)g(information)e(ab)q
(out)i(the)h(con)o(text)h(in)e(whic)o(h)g(it)h(will)e(o)q(ccur.)17
b(And,)11 b(although)d(holes)i(are)g(\014lled)f(b)o(y)h(immedia)o(te)0
241 y(v)n(alues)k(at)f(run)i(time,)d(the)i(compiler)f(cannot)h(tak)o(e)
g(adv)n(an)o(tage)f(of)g(sp)q(ecial)h(prop)q(erties)h(of)f(these)h
(constan)o(ts.)62 291 y(In)e(this)g(section)h(w)o(e)f(assess)h(the)g
(sp)q(eedups)h(obtained)d(b)o(y)h(run-time)f(sp)q(ecialization.)17
b(Rather)c(than)g(considering)g(run-)0 340 y(time)i(sp)q(ecialization)g
(in)h(isolation,)f(w)o(e)h(compare)g(it)f(to)h(compile-time)e(sp)q
(ecialization.)24 b(Compile-tim)o(e)13 b(sp)q(ecialization)0
390 y(can)k(b)q(e)g(seen)g(as)g(a)f(b)q(est)i(case)f(for)f(sp)q
(ecialization,)g(b)q(ecause)i(the)f(sp)q(ecialized)h(co)q(de)f(can)f(b)
q(e)i(sub)r(jected)g(to)e(a)g(compiler)0 440 y(that)e(p)q(erforms)f
(aggressiv)o(e,)g(and)g(time-consuming,)e(optimizations.)k(W)m(e)e
(\014nd)h(that)g(the)g(sp)q(eedups)h(obtained)f(are)f(close)0
490 y(to)j(those)g(ac)o(hiev)o(ed)g(b)o(y)g(compile-tim)o(e)d(sp)q
(ecialization,)j(and)f(that)h(as)g(exp)q(ected)i(the)e(break-ev)o(en)h
(p)q(oin)o(ts)e(are)i(lo)o(w.)22 b(W)m(e)0 540 y(th)o(us)17
b(conjecture)i(that)d(for)h(man)o(y)e(examples,)h(go)q(o)q(d)g(sp)q
(eedups)j(can)e(b)q(e)g(obtained)g(through)f(run-time)g(sp)q
(ecialization,)0 589 y(without)e(the)g(cost)h(of)e(in)o(v)o(oking)f(a)h
(compiler)g(at)h(run)g(time.)0 706 y Fp(4.1)56 b(Ov)n(erview)17
b(of)i(the)f(b)r(enc)n(hmarks)0 782 y Ft(W)m(e)c(ha)o(v)o(e)g
(considered)i(a)e(v)n(ariet)o(y)g(of)g(source)i(programs:)i(matrix)12
b(computations,)h(the)i(graphics)g(program)e(ppmdither)1921
767 y Fh(1)1938 782 y Ft(,)0 832 y(and)20 b(sev)o(eral)h(n)o(umerical)e
(algorithms.)35 b(Ppmdither)19 b(is)h(part)h(of)e(the)i(widely)f(a)o(v)
n(ailable)e(p)q(ortable)i(pixmap)f(library)1921 817 y
Fh(2)1938 832 y Ft(.)0 882 y(The)14 b(n)o(umerical)e(algorithms)f(are)j
(adapted)g(from)e(Gl)q(\177)-22 b(uc)o(k,)13 b(Nak)n(ashige,)f(and)h
(Z\177)-21 b(o)q(c)o(hling's)13 b(b)q(enc)o(hmarks)h(for)f(their)h(F)m
(ortran)0 932 y(partial)e(ev)n(aluator)g([7)o(].)17 b(The)c(measuremen)
o(ts)f(w)o(ere)i(obtained)e(using)h(a)f(Sun)h(SP)m(AR)o(Cstation)f(20)g
(Mo)q(del)h(70)f(with)g(96)h(MB)0 981 y(of)g(main)e(memory)g(running)i
(SunOS)h(v)o(ersion)f(4.1.4.)j(Times)d(w)o(ere)h(measured)f(using)g
(the)h(Unix)f(system)g(call)g Fk(getrusage)0 1031 y Ft(and)h(include)g
(b)q(oth)g(\\user")g(and)g(\\system")f(time.)62 1081
y(Figure)d(11)g(summarizes)e(the)i(sp)q(eedups)i(for)e(compile-tim)o(e)
d(and)j(run-time)f(sp)q(ecialization.)16 b(Run)10 b(times)f(are)h
(presen)o(ted)0 1131 y(in)15 b(microseconds.)21 b(F)m(or)15
b(eac)o(h)h(b)q(enc)o(hmark)e(w)o(e)i(giv)o(e)e(the)i(in)o(v)n(arian)o
(t)e(with)g(whic)o(h)h(the)h(program)e(is)h(sp)q(ecialized)g(and)g(the)
0 1181 y(run)e(time)f(of)h(the)g(source)i(program)c(when)j(compiled)d
(with)i Fk(gcc)21 b(-O2)p Ft(.)d(F)m(or)12 b(compile-time)e(\(CT\))k
(sp)q(ecialization)e(w)o(e)i(giv)o(e)0 1230 y(the)g(follo)o(wing)e
(information:)62 1313 y Fq(\017)21 b Ft(The)14 b(run)g(time)f(of)g(the)
i(result)f(of)g(compile-tim)o(e)d(sp)q(ecialization,)i(whic)o(h)h(is)g
(also)f(compiled)f(with)i Fk(gcc)21 b(-O2)p Ft(.)62 1396
y Fq(\017)g Ft(The)14 b(sp)q(eedup)i(of)d(the)h(compile-time)d(sp)q
(ecialized)k(program)d(as)i(compared)f(to)h(the)g(source)i(program.)0
1478 y(F)m(or)d(run-time)g(\(R)m(T\))g(sp)q(ecialization)h(w)o(e)g(giv)
o(e)f(the)i(follo)o(wing)c(information:)62 1561 y Fq(\017)21
b Ft(The)15 b(time)f(required)h(for)g(the)g(run-time)f(sp)q(ecializer)i
(to)f(generate)h(the)f(sp)q(ecialized)h(program)d(\(from)g(ob)r(ject)j
(tem-)104 1610 y(plates)e(pro)q(duced)h(b)o(y)f Fk(gcc)21
b(-O2)p Ft(\).)62 1693 y Fq(\017)g Ft(The)14 b(run)g(time)f(of)g(the)i
(resulting)f(run-time)e(sp)q(ecialization.)62 1776 y
Fq(\017)21 b Ft(The)14 b(sp)q(eedup)i(of)d(the)h(run-time)f(sp)q
(ecialized)i(program)d(as)i(compared)f(to)h(the)g(source)i(program.)62
1859 y Fq(\017)21 b Ft(The)e(break-ev)o(en)h(p)q(oin)o(t,)g(whic)o(h)e
(is)h(the)h(n)o(um)o(b)q(er)e(of)h(times)f(the)h(sp)q(ecialized)h
(program)e(m)o(ust)g(b)q(e)h(executed)i(to)104 1908 y(amortize)13
b(the)h(cost)h(of)e(sp)q(ecialization.)k(This)d(column)e(is)i(lab)q
(eled)g(\\=".)0 1991 y(Finally)m(,)c(w)o(e)j(compare)f(the)i(run)f
(time)e(of)h(the)h(run-time)f(sp)q(ecialized)h(program)f(with)g(the)h
(run)g(time)f(of)g(the)h(compile-time)0 2041 y(sp)q(ecialized)18
b(program.)25 b(T)o(ypically)m(,)15 b(run-time)h(sp)q(ecialization)g
(ac)o(hiev)o(es)i(o)o(v)o(er)f(80\045)f(of)g(the)h(sp)q(eedup)i(of)d
(compile-time)0 2090 y(sp)q(ecialization.)i(The)c(break)o(ev)o(en)h(p)q
(oin)o(ts)e(range)i(from)d(3)h(to)h(87)f(calls)h(to)g(the)g(sp)q
(ecialized)h(co)q(de.)62 2140 y(Figure)h(12)f(summarizes)e(the)j(co)q
(de)h(gro)o(wth)e(due)h(to)f(sp)q(ecialization.)22 b(F)m(or)15
b(the)h(source)g(program)e(and)h(the)h(result)h(of)0
2190 y(compile-tim)o(e)10 b(sp)q(ecialization)i(w)o(e)g(giv)o(e)g(b)q
(oth)h(the)f(n)o(um)o(b)q(er)g(of)g(lines)g(of)f(prett)o(y-prin)o(ted)j
(C)e(co)q(de)h(and)f(the)h(corresp)q(onding)0 2240 y(n)o(um)o(b)q(er)d
(of)f(kilob)o(ytes)h(of)g(mac)o(hine)f(instructions.)17
b(Since)11 b(no)f(source)i(co)q(de)f(is)f(generated)i(b)o(y)e(the)h
(run-time)e(sp)q(ecializer,)j(w)o(e)0 2290 y(simply)e(giv)o(e)h(the)i
(n)o(um)o(b)q(er)e(of)h(kilob)o(ytes)f(of)h(mac)o(hine)f(co)q(de.)18
b(W)m(e)11 b(compare)h(the)g(size)h(of)f(the)g(mac)o(hine)f(co)q(de)i
(generated)g(b)o(y)0 2340 y(compile-tim)o(e)f(and)h(run-time)g(sp)q
(ecialization)g(with)g(the)h(size)h(of)e(the)h(mac)o(hine)e(co)q(de)j
(for)e(the)h(original)e(source)j(program.)0 2389 y(Finally)c(w)o(e)i
(compare)f(the)i(size)f(of)f(the)i(mac)o(hine)d(co)q(de)j(for)e(the)h
(result)h(of)e(run-time)g(sp)q(ecialization)g(with)g(the)i(size)f(of)f
(the)0 2439 y(mac)o(hine)h(co)q(de)h(pro)q(duced)h(b)o(y)f
(compile-time)d(sp)q(ecialization.)p 0 2474 780 2 v 46
2500 a Ff(1)64 2512 y Fr(Cop)o(yrigh)o(t)c(\(C\))j(1991)e(b)o(y)h
(Christos)g(Zoulas.)k(P)o(ermission)7 b(to)i(use,)g(cop)o(y)m(,)g(mo)q
(dify)m(,)f(and)h(distribute)e(this)h(soft)o(w)o(are)h(and)f(its)i(do)q
(cumen)o(ta)o(tio)o(n)0 2552 y(for)g(an)o(y)g(purp)q(ose)f(and)h
(without)g(fee)g(is)h(hereb)o(y)e(gran)o(ted,)f(pro)o(vided)h(that)h
(the)g(ab)q(o)o(v)o(e)f(cop)o(yrigh)o(t)f(notice)i(app)q(ear)e(in)j
(all)f(copies)g(and)g(that)f(b)q(oth)0 2591 y(that)g(cop)o(yrigh)o(t)e
(notice)h(and)h(this)g(p)q(ermission)f(notice)g(app)q(ear)g(in)h(supp)q
(orting)e(do)q(cumen)o(tati)o(on.)12 b(This)e(soft)o(w)o(are)e(is)i
(pro)o(vided)e(\\as)h(is")g(without)0 2630 y(express)h(or)h(implied)f
(w)o(arran)o(t)o(y)m(.)46 2658 y Ff(2)64 2670 y Fr(Ppmdither)e(is)k(a)o
(v)n(ailable)d(b)o(y)i(ftp)g(from)f Fe(e.g.)17 b Fn(ftp.stanf)o(ord)o
(.ed)o(u/)o(cla)o(ss/)o(cs2)o(48/)o(ne)o(tpb)o(m/p)o(pm/)o(ppm)o(di)o
(the)o(r.c)o Fr(.)965 2795 y Ft(9)p eop
%%Page: 10 10
10 9 bop 0 604 2046 2 v -1 650 2 46 v 278 650 V 480 650
V 489 650 V 538 636 a Fv(Source)p 698 650 V 706 650 V
122 w(CT)12 b(Sp)q(ecializati)q(on)p 1131 650 V 1139
650 V 286 w(R)m(T)g(Sp)q(ecializati)q(on)p 1859 650 V
1868 650 V 248 w(CT/R)m(T)p 2045 650 V -1 696 V 65 682
a(Benc)o(hmark)p 278 696 V 51 w(In)o(v)n(arian)o(t)p
480 696 V 488 696 V 96 w(Time)p 698 696 V 706 696 V 132
w(Time)p 916 696 V 86 w Fw(Sp)q(eedup)p 1131 696 V 1139
696 V 57 w Fv(Generate)p 1341 696 V 87 w(Time)p 1551
696 V 87 w Fw(Sp)q(eedup)p 1765 696 V 55 w Fv(=)p 1859
696 V 1868 696 V 79 w Fw(Time)p 2045 696 V 0 697 2046
2 v -1 743 2 46 v 155 729 a Fv(p)q(o)o(w)o(er)p 278 743
V 75 w(exp=10)p 480 743 V 488 743 V 151 w(1.06)p 698
743 V 706 743 V 150 w(0.68)p 916 743 V 136 w Fw(1.56)p
1131 743 V 1139 743 V 142 w Fv(4.86)p 1341 743 V 143
w(0.81)p 1551 743 V 136 w Fw(1.31)p 1765 743 V 50 w(20)p
1859 743 V 1868 743 V 107 w(0.84)p 2045 743 V -1 789
V 278 789 V 329 775 a Fv(exp=20)p 480 789 V 488 789 V
151 w(2.00)p 698 789 V 706 789 V 150 w(1.35)p 916 789
V 136 w Fw(1.48)p 1131 789 V 1139 789 V 142 w Fv(8.21)p
1341 789 V 143 w(1.47)p 1551 789 V 136 w Fw(1.36)p 1765
789 V 50 w(16)p 1859 789 V 1868 789 V 107 w(0.92)p 2045
789 V -1 834 V 278 834 V 329 820 a Fv(exp=30)p 480 834
V 488 834 V 151 w(2.94)p 698 834 V 706 834 V 150 w(2.02)p
916 834 V 136 w Fw(1.46)p 1131 834 V 1139 834 V 123 w
Fv(11.56)p 1341 834 V 143 w(2.14)p 1551 834 V 136 w Fw(1.37)p
1765 834 V 50 w(15)p 1859 834 V 1868 834 V 107 w(0.94)p
2045 834 V 0 836 2046 2 v -1 882 2 46 v 115 868 a Fv(rom)o(b)q(erg)p
278 882 V 118 w(M=2)p 480 882 V 488 882 V 151 w(7.00)p
698 882 V 706 882 V 150 w(5.00)p 916 882 V 136 w Fw(1.40)p
1131 882 V 1139 882 V 123 w Fv(65.00)p 1341 882 V 143
w(6.00)p 1551 882 V 136 w Fw(1.17)p 1765 882 V 50 w(65)p
1859 882 V 1868 882 V 107 w(0.83)p 2045 882 V -1 927
V 25 913 a Fv(\(na)l(\177)-15 b(\020v)o(e)14 b(p)q(o)o(w)o(er\))p
278 927 V 117 w(M=4)p 480 927 V 488 927 V 132 w(24.00)p
698 927 V 706 927 V 131 w(14.00)p 916 927 V 136 w Fw(1.71)p
1131 927 V 1139 927 V 104 w Fv(203.00)p 1341 927 V 123
w(16.00)p 1551 927 V 137 w Fw(1.50)p 1765 927 V 50 w(26)p
1859 927 V 1868 927 V 107 w(0.88)p 2045 927 V -1 973
V 278 973 V 371 959 a Fv(M=6)p 480 973 V 488 973 V 132
w(66.00)p 698 973 V 706 973 V 131 w(40.00)p 916 973 V
136 w Fw(1.65)p 1131 973 V 1139 973 V 104 w Fv(527.00)p
1341 973 V 123 w(47.00)p 1551 973 V 137 w Fw(1.40)p 1765
973 V 50 w(28)p 1859 973 V 1868 973 V 107 w(0.85)p 2045
973 V -1 1019 V 278 1019 V 371 1005 a Fv(M=8)p 480 1019
V 488 1019 V 112 w(206.00)p 698 1019 V 706 1019 V 113
w(138.00)p 916 1019 V 136 w Fw(1.49)p 1131 1019 V 1139
1019 V 85 w Fv(1558.00)p 1341 1019 V 104 w(165.00)p 1551
1019 V 137 w Fw(1.25)p 1765 1019 V 50 w(38)p 1859 1019
V 1868 1019 V 107 w(0.84)p 2045 1019 V 0 1020 2046 2
v -1 1066 2 46 v 115 1052 a Fv(rom)o(b)q(erg)p 278 1066
V 118 w(M=2)p 480 1066 V 488 1066 V 151 w(7.00)p 698
1066 V 706 1066 V 150 w(5.00)p 916 1066 V 136 w Fw(1.40)p
1131 1066 V 1139 1066 V 123 w Fv(61.00)p 1341 1066 V
143 w(6.00)p 1551 1066 V 136 w Fw(1.17)p 1765 1066 V
50 w(61)p 1859 1066 V 1868 1066 V 107 w(0.83)p 2045 1066
V -1 1111 V 93 1098 a Fv(\(p)q(o)o(w)o(er)f(as)p 278
1111 V 117 w(M=4)p 480 1111 V 488 1111 V 132 w(20.00)p
698 1111 V 706 1111 V 131 w(14.00)p 916 1111 V 136 w
Fw(1.43)p 1131 1111 V 1139 1111 V 104 w Fv(191.00)p 1341
1111 V 123 w(16.00)p 1551 1111 V 137 w Fw(1.25)p 1765
1111 V 50 w(48)p 1859 1111 V 1868 1111 V 107 w(0.88)p
2045 1111 V -1 1157 V 186 1143 a Fd(<)-6 b(<)p Fv(\))p
278 1157 V 116 w(M=6)p 480 1157 V 488 1157 V 132 w(60.00)p
698 1157 V 706 1157 V 131 w(40.00)p 916 1157 V 136 w
Fw(1.50)p 1131 1157 V 1139 1157 V 104 w Fv(489.00)p 1341
1157 V 123 w(47.00)p 1551 1157 V 137 w Fw(1.28)p 1765
1157 V 50 w(38)p 1859 1157 V 1868 1157 V 107 w(0.85)p
2045 1157 V -1 1203 V 278 1203 V 371 1189 a Fv(M=8)p
480 1203 V 488 1203 V 112 w(196.00)p 698 1203 V 706 1203
V 113 w(138.00)p 916 1203 V 136 w Fw(1.42)p 1131 1203
V 1139 1203 V 85 w Fv(1375.00)p 1341 1203 V 104 w(165.00)p
1551 1203 V 137 w Fw(1.19)p 1765 1203 V 50 w(45)p 1859
1203 V 1868 1203 V 107 w(0.84)p 2045 1203 V 0 1204 2046
2 v -1 1250 2 46 v 58 1236 a Fv(cubic)14 b(spline)p 278
1250 V 114 w(n=10)p 480 1250 V 488 1250 V 132 w(11.20)p
698 1250 V 706 1250 V 150 w(6.20)p 916 1250 V 136 w Fw(1.81)p
1131 1250 V 1139 1250 V 104 w Fv(203.50)p 1341 1250 V
143 w(8.40)p 1551 1250 V 136 w Fw(1.33)p 1765 1250 V
50 w(73)p 1859 1250 V 1868 1250 V 107 w(0.74)p 2045 1250
V -1 1296 V 278 1296 V 366 1282 a Fv(n=20)p 480 1296
V 488 1296 V 132 w(23.30)p 698 1296 V 706 1296 V 131
w(14.30)p 916 1296 V 136 w Fw(1.63)p 1131 1296 V 1139
1296 V 104 w Fv(428.00)p 1341 1296 V 123 w(17.60)p 1551
1296 V 137 w Fw(1.32)p 1765 1296 V 50 w(76)p 1859 1296
V 1868 1296 V 107 w(0.81)p 2045 1296 V -1 1341 V 278
1341 V 366 1328 a Fv(n=30)p 480 1341 V 488 1341 V 132
w(35.50)p 698 1341 V 706 1341 V 131 w(20.90)p 916 1341
V 136 w Fw(1.70)p 1131 1341 V 1139 1341 V 104 w Fv(653.20)p
1341 1341 V 123 w(26.90)p 1551 1341 V 137 w Fw(1.32)p
1765 1341 V 50 w(76)p 1859 1341 V 1868 1341 V 107 w(0.78)p
2045 1341 V 0 1343 2046 2 v -1 1389 2 46 v 86 1375 a
Fv(c)o(heb)o(yshev)p 278 1389 V 132 w(n=5)p 480 1389
V 488 1389 V 132 w(68.00)p 698 1389 V 706 1389 V 131
w(12.00)p 916 1389 V 136 w Fw(5.67)p 1131 1389 V 1139
1389 V 104 w Fv(164.00)p 1341 1389 V 123 w(13.00)p 1551
1389 V 137 w Fw(5.23)p 1765 1389 V 72 w(3)p 1859 1389
V 1868 1389 V 107 w(0.92)p 2045 1389 V -1 1434 V 278
1434 V 366 1421 a Fv(n=10)p 480 1434 V 488 1434 V 112
w(246.00)p 698 1434 V 706 1434 V 132 w(28.00)p 916 1434
V 136 w Fw(8.79)p 1131 1434 V 1139 1434 V 104 w Fv(561.00)p
1341 1434 V 123 w(30.00)p 1551 1434 V 137 w Fw(8.20)p
1765 1434 V 72 w(3)p 1859 1434 V 1868 1434 V 107 w(0.93)p
2045 1434 V -1 1480 V 278 1480 V 366 1466 a Fv(n=15)p
480 1480 V 488 1480 V 112 w(520.00)p 698 1480 V 706 1480
V 132 w(49.00)p 916 1480 V 114 w Fw(10.61)p 1131 1480
V 1139 1480 V 85 w Fv(1199.00)p 1341 1480 V 123 w(54.00)p
1551 1480 V 137 w Fw(9.63)p 1765 1480 V 72 w(3)p 1859
1480 V 1868 1480 V 107 w(0.91)p 2045 1480 V -1 1526 V
278 1526 V 366 1512 a Fv(n=20)p 480 1526 V 488 1526 V
112 w(913.00)p 698 1526 V 706 1526 V 132 w(75.00)p 916
1526 V 114 w Fw(12.17)p 1131 1526 V 1139 1526 V 85 w
Fv(2110.00)p 1341 1526 V 123 w(88.00)p 1551 1526 V 114
w Fw(10.38)p 1765 1526 V 73 w(3)p 1859 1526 V 1868 1526
V 107 w(0.85)p 2045 1526 V 0 1527 2046 2 v -1 1573 2
46 v 68 1559 a Fv(dotpro)q(duct)p 278 1573 V 113 w(n=10)p
480 1573 V 488 1573 V 151 w(0.91)p 698 1573 V 706 1573
V 150 w(0.16)p 916 1573 V 136 w Fw(5.69)p 1131 1573 V
1139 1573 V 142 w Fv(4.40)p 1341 1573 V 143 w(0.27)p
1551 1573 V 136 w Fw(3.37)p 1765 1573 V 72 w(7)p 1859
1573 V 1868 1573 V 107 w(0.59)p 2045 1573 V -1 1619 V
40 1605 a Fv(\(90\045)f(zero)q(es\))p 278 1619 V 93 w(n=100)p
480 1619 V 488 1619 V 151 w(7.78)p 698 1619 V 706 1619
V 150 w(1.11)p 916 1619 V 136 w Fw(7.01)p 1131 1619 V
1139 1619 V 123 w Fv(29.64)p 1341 1619 V 143 w(1.48)p
1551 1619 V 136 w Fw(5.26)p 1765 1619 V 72 w(5)p 1859
1619 V 1868 1619 V 107 w(0.75)p 2045 1619 V -1 1664 V
278 1664 V 347 1651 a Fv(n=200)p 480 1664 V 488 1664
V 132 w(38.30)p 698 1664 V 706 1664 V 150 w(5.51)p 916
1664 V 136 w Fw(6.95)p 1131 1664 V 1139 1664 V 104 w
Fv(141.63)p 1341 1664 V 143 w(6.83)p 1551 1664 V 136
w Fw(5.61)p 1765 1664 V 72 w(5)p 1859 1664 V 1868 1664
V 107 w(0.81)p 2045 1664 V 0 1666 2046 2 v -1 1712 2
46 v 68 1698 a Fv(dotpro)q(duct)p 278 1712 V 113 w(n=10)p
480 1712 V 488 1712 V 132 w(86.50)p 698 1712 V 706 1712
V 180 w(|)p 916 1712 V 176 w(|)p 1131 1712 V 1139 1712
V 123 w(51.80)p 1341 1712 V 123 w(88.00)p 1551 1712 V
137 w Fw(0.98)p 1765 1712 V 56 w Fv(|)p 1859 1712 V 1868
1712 V 147 w(|)p 2045 1712 V -1 1757 V 52 1744 a(in)h(mat)p
165 1744 12 2 v 13 w(m)o(ult)p 278 1757 2 46 v 94 w(n=100)p
480 1757 V 488 1757 V 59 w(0)p Fd(:)p Fv(07)9 b Fc(\003)f
Fv(10)656 1728 y Ff(6)p 698 1757 V 706 1757 V 854 1744
a Fv(|)p 916 1757 V 176 w(|)p 1131 1757 V 1139 1757 V
85 w(3100.00)p 1341 1757 V 51 w(0)p Fd(:)p Fv(02)g Fc(\003)h
Fv(10)1509 1728 y Ff(6)p 1551 1757 V 1663 1744 a Fw(2.91)p
1765 1757 V 56 w Fv(|)p 1859 1757 V 1868 1757 V 147 w(|)p
2045 1757 V -1 1803 V 278 1803 V 347 1789 a(n=200)p 480
1803 V 488 1803 V 59 w(0)p Fd(:)p Fv(56)g Fc(\003)f Fv(10)656
1773 y Ff(6)p 698 1803 V 706 1803 V 854 1789 a Fv(|)p
916 1803 V 176 w(|)p 1131 1803 V 1139 1803 V 66 w(12000.00)p
1341 1803 V 51 w(0)p Fd(:)p Fv(18)g Fc(\003)h Fv(10)1509
1773 y Ff(6)p 1551 1803 V 1663 1789 a Fw(3.06)p 1765
1803 V 56 w Fv(|)p 1859 1803 V 1868 1803 V 147 w(|)p
2045 1803 V 0 1805 2046 2 v -1 1850 2 46 v 72 1837 a(dith)p
141 1837 12 2 v 15 w(dither)p 278 1850 2 46 v 94 w(4,5,9,5)p
480 1850 V 488 1850 V 150 w(2.06)p 698 1850 V 706 1850
V 150 w(0.39)p 916 1850 V 136 w Fw(5.28)p 1131 1850 V
1139 1850 V 123 w Fv(25.00)p 1341 1850 V 143 w(1.77)p
1551 1850 V 136 w Fw(1.16)p 1765 1850 V 50 w(87)p 1859
1850 V 1868 1850 V 107 w(0.22)p 2045 1850 V -1 1896 V
135 1882 a Fv(in)14 b(ppm)p 278 1896 V 93 w(4,5,9,5)p
480 1896 V 488 1896 V 58 w(3)p Fd(:)p Fv(03)9 b Fc(\003)f
Fv(10)656 1866 y Ff(6)p 698 1896 V 706 1896 V 732 1882
a Fv(1)p Fd(:)p Fv(72)h Fc(\003)g Fv(10)875 1866 y Ff(6)p
916 1896 V 1028 1882 a Fw(1.76)p 1131 1896 V 1139 1896
V 123 w Fv(25.00)p 1341 1896 V 51 w(2)p Fd(:)p Fv(68)f
Fc(\003)h Fv(10)1509 1866 y Ff(6)p 1551 1896 V 1663 1882
a Fw(1.13)p 1765 1896 V 56 w Fv(|)p 1859 1896 V 1868
1896 V 107 w Fw(0.64)p 2045 1896 V -1 1942 V 90 1928
a Fv(optimized)p 278 1942 V 95 w(4,5,9,5)p 480 1942 V
488 1942 V 180 w(|)p 698 1942 V 706 1942 V 180 w(|)p
916 1942 V 176 w(|)p 1131 1942 V 1139 1942 V 123 w(24.00)p
1341 1942 V 143 w(0.50)p 1551 1942 V 136 w Fw(4.12)p
1765 1942 V 50 w(17)p 1859 1942 V 1868 1942 V 107 w(0.78)p
2045 1942 V -1 1987 V 135 1974 a Fv(in)14 b(ppm)p 278
1987 V 93 w(4,5,9,5)p 480 1987 V 488 1987 V 180 w(|)p
698 1987 V 706 1987 V 180 w(|)p 916 1987 V 176 w(|)p
1131 1987 V 1139 1987 V 123 w(24.00)p 1341 1987 V 51
w(1)p Fd(:)p Fv(68)8 b Fc(\003)h Fv(10)1509 1958 y Ff(6)p
1551 1987 V 1663 1974 a Fw(1.81)p 1765 1987 V 56 w Fv(|)p
1859 1987 V 1868 1987 V 107 w Fw(1.03)p 2045 1987 V 0
1989 2046 2 v 271 2105 a Ft(Figure)14 b(11:)j(Comparison)12
b(of)h(the)i(run)f(times)f(of)g(sp)q(ecialized)i(and)f(unsp)q
(ecialized)g(co)q(de)954 2795 y(10)p eop
%%Page: 11 11
11 10 bop 69 43 1813 2 v 68 89 2 46 v 347 89 V 549 89
V 558 89 V 640 75 a Fv(Source)p 832 89 V 841 89 V 188
w(CT)12 b(Sp)q(ecializati)q(on)p 1333 89 V 1341 89 V
136 w(R)m(T)h(Sp)q(ecializati)q(on)p 1695 89 V 1703 89
V 65 w(R)m(T/CT)p 1880 89 V 68 134 V 134 121 a(Benc)o(hmark)p
347 134 V 51 w(In)o(v)n(arian)o(t)p 549 134 V 557 134
V 60 w(Lines)p 695 134 V 66 w(KB)p 832 134 V 841 134
V 73 w(Lines)p 979 134 V 76 w(KB)p 1135 134 V 75 w Fw(Gro)o(wth)p
1333 134 V 1341 134 V 82 w Fv(KB)p 1497 134 V 75 w Fw(Gro)o(wth)p
1695 134 V 1703 134 V 88 w(KB)p 1880 134 V 69 136 1813
2 v 68 182 2 46 v 224 168 a Fv(p)q(o)o(w)o(er)p 347 182
V 75 w(exp=10)p 549 182 V 557 182 V 109 w(13)p 695 182
V 50 w(0.040)p 832 182 V 841 182 V 108 w(16)p 979 182
V 70 w(0.040)p 1135 182 V 119 w Fw(1.00)p 1333 182 V
1341 182 V 78 w Fv(0.060)p 1497 182 V 119 w Fw(1.50)p
1695 182 V 1703 182 V 108 w(1.50)p 1880 182 V 68 227
V 347 227 V 398 214 a Fv(exp=20)p 549 227 V 557 227 V
109 w(13)p 695 227 V 50 w(0.040)p 832 227 V 841 227 V
108 w(26)p 979 227 V 70 w(0.084)p 1135 227 V 119 w Fw(2.10)p
1333 227 V 1341 227 V 78 w Fv(0.100)p 1497 227 V 119
w Fw(2.50)p 1695 227 V 1703 227 V 108 w(1.19)p 1880 227
V 68 273 V 347 273 V 398 259 a Fv(exp=30)p 549 273 V
557 273 V 109 w(13)p 695 273 V 50 w(0.040)p 832 273 V
841 273 V 108 w(36)p 979 273 V 70 w(0.120)p 1135 273
V 119 w Fw(3.00)p 1333 273 V 1341 273 V 78 w Fv(0.140)p
1497 273 V 119 w Fw(3.50)p 1695 273 V 1703 273 V 108
w(1.17)p 1880 273 V 69 275 1813 2 v 68 320 2 46 v 184
307 a Fv(rom)o(b)q(erg)p 347 320 V 118 w(M=2)p 549 320
V 557 320 V 109 w(36)p 695 320 V 50 w(0.484)p 832 320
V 841 320 V 108 w(24)p 979 320 V 70 w(0.572)p 1135 320
V 119 w Fw(1.18)p 1333 320 V 1341 320 V 78 w Fv(1.096)p
1497 320 V 119 w Fw(2.26)p 1695 320 V 1703 320 V 108
w(1.92)p 1880 320 V 68 366 V 94 352 a Fv(\(na)l(\177)-15
b(\020v)o(e)14 b(p)q(o)o(w)o(er\))p 347 366 V 117 w(M=4)p
549 366 V 557 366 V 109 w(36)p 695 366 V 50 w(0.484)p
832 366 V 841 366 V 108 w(47)p 979 366 V 70 w(1.676)p
1135 366 V 119 w Fw(3.46)p 1333 366 V 1341 366 V 78 w
Fv(3.380)p 1497 366 V 119 w Fw(6.98)p 1695 366 V 1703
366 V 108 w(2.02)p 1880 366 V 68 412 V 347 412 V 440
398 a Fv(M=6)p 549 412 V 557 412 V 109 w(36)p 695 412
V 50 w(0.484)p 832 412 V 841 412 V 89 w(110)p 979 412
V 70 w(4.924)p 1135 412 V 97 w Fw(10.17)p 1333 412 V
1341 412 V 78 w Fv(8.576)p 1497 412 V 97 w Fw(17.72)p
1695 412 V 1703 412 V 108 w(1.74)p 1880 412 V 68 457
V 347 457 V 440 444 a Fv(M=8)p 549 457 V 557 457 V 109
w(36)p 695 457 V 50 w(0.484)p 832 457 V 841 457 V 89
w(321)p 979 457 V 50 w(16.252)p 1135 457 V 98 w Fw(33.58)p
1333 457 V 1341 457 V 59 w Fv(23.164)p 1497 457 V 97
w Fw(47.86)p 1695 457 V 1703 457 V 108 w(1.43)p 1880
457 V 69 459 1813 2 v 68 505 2 46 v 184 491 a Fv(rom)o(b)q(erg)p
347 505 V 118 w(M=2)p 549 505 V 557 505 V 109 w(24)p
695 505 V 50 w(0.440)p 832 505 V 841 505 V 108 w(24)p
979 505 V 70 w(0.572)p 1135 505 V 119 w Fw(1.30)p 1333
505 V 1341 505 V 78 w Fv(1.096)p 1497 505 V 119 w Fw(2.49)p
1695 505 V 1703 505 V 108 w(1.92)p 1880 505 V 68 550
V 162 537 a Fv(\(p)q(o)o(w)o(er)f(as)p 347 550 V 117
w(M=4)p 549 550 V 557 550 V 109 w(24)p 695 550 V 50 w(0.440)p
832 550 V 841 550 V 108 w(47)p 979 550 V 70 w(1.676)p
1135 550 V 119 w Fw(3.81)p 1333 550 V 1341 550 V 78 w
Fv(3.380)p 1497 550 V 119 w Fw(7.68)p 1695 550 V 1703
550 V 108 w(2.02)p 1880 550 V 68 596 V 255 582 a Fd(<)-6
b(<)p Fv(\))p 347 596 V 116 w(M=6)p 549 596 V 557 596
V 109 w(24)p 695 596 V 50 w(0.440)p 832 596 V 841 596
V 89 w(110)p 979 596 V 70 w(4.924)p 1135 596 V 97 w Fw(11.19)p
1333 596 V 1341 596 V 78 w Fv(8.576)p 1497 596 V 97 w
Fw(19.49)p 1695 596 V 1703 596 V 108 w(1.74)p 1880 596
V 68 642 V 347 642 V 440 628 a Fv(M=8)p 549 642 V 557
642 V 109 w(24)p 695 642 V 50 w(0.440)p 832 642 V 841
642 V 89 w(321)p 979 642 V 50 w(16.252)p 1135 642 V 98
w Fw(36.94)p 1333 642 V 1341 642 V 59 w Fv(23.164)p 1497
642 V 97 w Fw(52.65)p 1695 642 V 1703 642 V 108 w(1.43)p
1880 642 V 69 643 1813 2 v 68 689 2 46 v 127 675 a Fv(cubic)14
b(spline)p 347 689 V 114 w(n=10)p 549 689 V 557 689 V
109 w(29)p 695 689 V 50 w(0.436)p 832 689 V 841 689 V
108 w(84)p 979 689 V 70 w(1.204)p 1135 689 V 119 w Fw(2.76)p
1333 689 V 1341 689 V 78 w Fv(3.396)p 1497 689 V 119
w Fw(7.79)p 1695 689 V 1703 689 V 108 w(2.82)p 1880 689
V 68 735 V 347 735 V 435 721 a Fv(n=20)p 549 735 V 557
735 V 109 w(29)p 695 735 V 50 w(0.436)p 832 735 V 841
735 V 89 w(144)p 979 735 V 70 w(2.688)p 1135 735 V 119
w Fw(6.17)p 1333 735 V 1341 735 V 78 w Fv(7.156)p 1497
735 V 97 w Fw(16.41)p 1695 735 V 1703 735 V 108 w(2.66)p
1880 735 V 68 780 V 347 780 V 435 767 a Fv(n=30)p 549
780 V 557 780 V 109 w(29)p 695 780 V 50 w(0.436)p 832
780 V 841 780 V 89 w(204)p 979 780 V 70 w(4.160)p 1135
780 V 119 w Fw(9.54)p 1333 780 V 1341 780 V 59 w Fv(10.916)p
1497 780 V 97 w Fw(25.04)p 1695 780 V 1703 780 V 108
w(2.62)p 1880 780 V 69 782 1813 2 v 68 828 2 46 v 155
814 a Fv(c)o(heb)o(yshev)p 347 828 V 132 w(n=5)p 549
828 V 557 828 V 109 w(22)p 695 828 V 50 w(0.492)p 832
828 V 841 828 V 108 w(55)p 979 828 V 70 w(0.848)p 1135
828 V 119 w Fw(1.72)p 1333 828 V 1341 828 V 78 w Fv(1.836)p
1497 828 V 119 w Fw(3.73)p 1695 828 V 1703 828 V 108
w(2.17)p 1880 828 V 68 873 V 347 873 V 435 860 a Fv(n=10)p
549 873 V 557 873 V 109 w(22)p 695 873 V 50 w(0.492)p
832 873 V 841 873 V 89 w(140)p 979 873 V 70 w(2.344)p
1135 873 V 119 w Fw(4.76)p 1333 873 V 1341 873 V 78 w
Fv(5.796)p 1497 873 V 97 w Fw(11.78)p 1695 873 V 1703
873 V 108 w(2.47)p 1880 873 V 68 919 V 347 919 V 435
905 a Fv(n=15)p 549 919 V 557 919 V 109 w(22)p 695 919
V 50 w(0.492)p 832 919 V 841 919 V 89 w(275)p 979 919
V 70 w(4.696)p 1135 919 V 119 w Fw(9.54)p 1333 919 V
1341 919 V 59 w Fv(11.956)p 1497 919 V 97 w Fw(24.30)p
1695 919 V 1703 919 V 108 w(2.55)p 1880 919 V 68 965
V 347 965 V 435 951 a Fv(n=20)p 549 965 V 557 965 V 109
w(22)p 695 965 V 50 w(0.492)p 832 965 V 841 965 V 89
w(460)p 979 965 V 70 w(7.620)p 1135 965 V 97 w Fw(15.49)p
1333 965 V 1341 965 V 59 w Fv(20.316)p 1497 965 V 97
w Fw(41.29)p 1695 965 V 1703 965 V 108 w(2.67)p 1880
965 V 69 966 1813 2 v 68 1012 2 46 v 137 998 a Fv(dotpro)q(duct)p
347 1012 V 113 w(n=10)p 549 1012 V 557 1012 V 109 w(16)p
695 1012 V 50 w(0.072)p 832 1012 V 841 1012 V 108 w(38)p
979 1012 V 70 w(0.016)p 1135 1012 V 119 w Fw(0.22)p 1333
1012 V 1341 1012 V 78 w Fv(0.052)p 1497 1012 V 119 w
Fw(0.72)p 1695 1012 V 1703 1012 V 108 w(3.25)p 1880 1012
V 68 1058 V 347 1058 V 416 1044 a Fv(n=100)p 549 1058
V 557 1058 V 109 w(16)p 695 1058 V 50 w(0.072)p 832 1058
V 841 1058 V 89 w(137)p 979 1058 V 70 w(0.192)p 1135
1058 V 119 w Fw(2.67)p 1333 1058 V 1341 1058 V 78 w Fv(0.340)p
1497 1058 V 119 w Fw(4.72)p 1695 1058 V 1703 1058 V 108
w(1.77)p 1880 1058 V 68 1103 V 347 1103 V 416 1090 a
Fv(n=500)p 549 1103 V 557 1103 V 109 w(16)p 695 1103
V 50 w(0.072)p 832 1103 V 841 1103 V 89 w(577)p 979 1103
V 70 w(1.152)p 1135 1103 V 97 w Fw(16.00)p 1333 1103
V 1341 1103 V 78 w Fv(1.620)p 1497 1103 V 97 w Fw(22.50)p
1695 1103 V 1703 1103 V 108 w(1.41)p 1880 1103 V 69 1105
1813 2 v 68 1151 2 46 v 141 1137 a Fv(dith)p 210 1137
12 2 v 15 w(dither)p 347 1151 2 46 v 94 w(4,5,9,5)p 549
1151 V 557 1151 V 108 w(27)p 695 1151 V 50 w(0.388)p
832 1151 V 841 1151 V 108 w(26)p 979 1151 V 70 w(0.288)p
1135 1151 V 119 w Fw(0.74)p 1333 1151 V 1341 1151 V 78
w Fv(0.396)p 1497 1151 V 119 w Fw(1.02)p 1695 1151 V
1703 1151 V 108 w(1.38)p 1880 1151 V 68 1196 V 159 1183
a Fv(optimized)p 347 1196 V 95 w(4,5,9,5)p 549 1196 V
557 1196 V 108 w(|)p 695 1196 V 99 w(|)p 832 1196 V 841
1196 V 108 w(|)p 979 1196 V 119 w(|)p 1135 1196 V 159
w(|)p 1333 1196 V 1341 1196 V 78 w(0.308)p 1497 1196
V 119 w Fw(0.79)p 1695 1196 V 1703 1196 V 108 w(1.07)p
1880 1196 V 69 1198 1813 2 v 317 1314 a Ft(Figure)g(12:)j(Comparison)12
b(of)h(the)i(sizes)g(of)e(sp)q(ecialized)i(and)f(unsp)q(ecialized)g(co)
q(de)62 1447 y(Co)q(de)k(gro)o(wth)f(can)g(h)o(urt)h(p)q(erformance)f
(when)h(the)f(co)q(de)i(size)f(exceeds)h(the)f(size)g(of)e(the)i(cac)o
(he.)29 b(The)18 b(size)g(of)e(the)0 1496 y(co)q(de)i(pro)q(duced)g(b)o
(y)f(the)h(compile-time)c(sp)q(ecializer)k(as)f(compared)g(to)g(the)h
(size)f(of)g(the)h(co)q(de)g(pro)q(duced)g(b)o(y)f(the)h(run-)0
1546 y(time)13 b(sp)q(ecializer)i(is)e(another)i(indicator)e(of)g(the)i
(e\016cacy)g(of)e(compiler)f(optimizations.)k(In)e(general)g(the)h(co)q
(de)g(pro)q(duced)0 1596 y(b)o(y)g(run-time)g(sp)q(ecialization)g(is)g
(one)h(and)f(a)g(half)g(to)g(three)i(times)e(larger)g(than)h(the)g(co)q
(de)g(pro)q(duced)h(b)o(y)e(compile-time)0 1646 y(sp)q(ecialization.)33
b(W)m(e)19 b(no)o(w)f(describ)q(e)j(the)f(b)q(ene\014ts)h(of)d
(compile-time)e(and)j(run-time)f(sp)q(ecialization)h(in)f(eac)o(h)i(of)
e(the)0 1696 y(examples.)f(The)d(source)i(co)q(de)e(for)g(eac)o(h)g
(program)f(is)g(a)o(v)n(ailable)f(in)h(the)i(app)q(endix.)0
1812 y Fp(4.2)56 b(Lo)r(op)18 b(unrolling)0 1889 y Ft(The)12
b(na)-5 b(\177)-16 b(\020v)o(e)12 b(in)o(teger)g(p)q(o)o(w)o(er)g
(program)f(\(App)q(endix)h(A\))g(computes)g Fi(x)1079
1873 y Fb(y)1111 1889 y Ft(using)g(a)f(lo)q(op)g(that)h(m)o(ultiplies)e
(an)i(accum)o(ulator)e(b)o(y)0 1938 y Fi(x)k Ft(rep)q(eatedly)i
Fi(y)h Ft(times.)i(Sp)q(ecialization)14 b(with)g(resp)q(ect)j(to)d(a)h
(static)g(exp)q(onen)o(t)g(simply)e(unrolls)h(this)h(lo)q(op,)e
(duplicating)0 1988 y(the)h(b)q(o)q(dy)g(unc)o(hanged.)k(Because)d(the)
f(b)q(o)q(dy)g(is)f(only)g(one)h(line)f(of)f(C)i(co)q(de,)g(the)g(lo)q
(op)e(computations)h(form)e(a)i(signi\014can)o(t)0 2038
y(o)o(v)o(erhead.)18 b(Th)o(us)d(w)o(e)f(obtain)f(non-negligeable)g(sp)
q(eedup)i(from)d(compile-time)f(sp)q(ecialization.)62
2088 y(Run-time)j(sp)q(ecialization)i(ac)o(hiev)o(es)g(sligh)o(tly)f
(less)h(sp)q(eedup.)26 b(The)16 b(fact)g(that)g(the)g(co)q(de)h(pro)q
(duced)g(at)e(run-time)g(is)0 2138 y(sligh)o(tly)10 b(larger)i
(suggests)h(that)e(the)h(compiler)f(could)g(p)q(erform)g(few)o(er)h
(optimizations)d(on)j(the)g(templates)f(of)g(the)h(run-time)0
2187 y(sp)q(ecializer)j(than)f(on)f(the)i(straigh)o(t-line)e(co)q(de)i
(pro)q(duced)g(b)o(y)e(the)i(compile-tim)o(e)d(sp)q(ecializer.)62
2237 y(Most)k(of)g(the)g(other)h(examples)e(tak)o(e)h(adv)n(an)o(tage)f
(of)g(lo)q(op)g(unrolling.)23 b(Because)18 b(they)e(are)h(more)e
(complicated,)f(the)0 2287 y(o)o(v)o(erhead)e(of)f(the)h(lo)q(op)f(op)q
(erations)h(is)g(less)g(imp)q(ortan)o(t.)k(Th)o(us)c(most)e(of)h(the)h
(sp)q(eedup)i(comes)d(from)f(other)i(impro)o(v)o(emen)o(ts)0
2337 y(due)i(to)g(sp)q(ecialization.)0 2453 y Fp(4.3)56
b(Constan)n(t)19 b(folding)0 2530 y Ft(W)m(e)e(no)o(w)f(turn)h(to)g
(the)h(scien)o(ti\014c)f(programs)f(analyzed)h(b)o(y)f(Gl)q(\177)-22
b(uc)o(k,)17 b(Nak)n(ashige,)g(and)f(Z\177)-21 b(o)q(c)o(hling)17
b([7)o(])f(for)h(their)g(F)m(ortran)0 2579 y(sp)q(ecializer.)26
b(These)18 b(are)e(Rom)o(b)q(erg)f(in)o(tegration)h(\(App)q(endix)g
(B\),)h(Cheb)o(yshev)g(appro)o(ximation)c(\(App)q(endix)k(C\))f(cubic)0
2629 y(spline)k(in)o(terp)q(olation)f(\(App)q(endix)i(D\).)e(W)m(e)h
(refer)h(the)g(reader)g(to)f(Gl)q(\177)-22 b(uc)o(k)20
b Fo(et)g(al.)37 b Ft(for)20 b(further)h(details)f(ab)q(out)g(these)954
2795 y(11)p eop
%%Page: 12 12
12 11 bop 0 42 a Ft(algorithms.)18 b(All)c(of)g(the)h(programs)e(b)q
(ene\014t)j(from)d(lo)q(op)h(unrolling.)k(F)m(urthermore,)d(eac)o(h)g
(b)q(ene\014ts)h(substan)o(tially)e(from)0 91 y(constan)o(t)g(folding.)
62 141 y(W)m(e)i(sp)q(ecialize)h(the)f(Rom)o(b)q(erg)f(in)o(tegration)g
(program)g(with)g(resp)q(ect)k(to)c(the)i(n)o(um)o(b)q(er)e(of)h
(iterations)g(to)g(use)h(in)e(the)0 191 y(appro)o(ximation.)20
b(The)c(program)e(con)o(tains)h(in)o(teger)h(p)q(o)o(w)o(er)g(and)f
(\015oating)g(p)q(oin)o(t)g(division)f(computations)g(that)i(can)f(b)q
(e)0 241 y(reduced)c(at)f(sp)q(ecialization)f(time)f(and)h(that)h(o)q
(ccur)g(in)g(a)f(doubly)g(nested)i(lo)q(op.)16 b(Sp)q(ecialization)8
b(also)h(p)q(erforms)g(sev)o(eral)h(less)0 291 y(costly)i(in)o(teger)h
(op)q(erations.)18 b(W)m(e)12 b(obtain)f(sp)q(eedups)j(b)q(oth)f(when)f
(p)q(o)o(w)o(er)h(is)f(computed)g(using)g(our)g(na)-5
b(\177)-16 b(\020v)o(e)12 b(p)q(o)o(w)o(er)g(function)0
340 y(and)i(when)h(w)o(e)g(exploit)f(the)h(fact)f(that)h(the)g(base)g
(is)f(a)g(p)q(o)o(w)o(er)h(of)f(t)o(w)o(o)g(in)g(order)h(to)f(rewrite)h
(the)g(p)q(o)o(w)o(er)g(computation)e(as)0 390 y(a)h(shift)h(op)q
(eration.)20 b(Again)14 b(w)o(e)h(obtain)f(sligh)o(tly)f(less)j(sp)q
(eedup)g(from)d(run-time)h(sp)q(ecialization.)20 b(Corresp)q(ondingly)
14 b(the)0 440 y(co)q(de)i(pro)q(duced)f(at)g(run-time)f(is)g(ab)q(out)
h(t)o(wice)g(as)g(big)f(as)g(the)i(co)q(de)f(pro)q(duced)h(after)f(sp)q
(ecialization)f(at)h(compile)e(time.)0 490 y(Sp)q(ecialization)18
b(simply)e(shifts)j(computations)e(from)g(the)j(time)d(when)i(the)g(sp)
q(ecialized)h(function)e(is)h(called)f(to)g(when)0 540
y(it)f(is)g(generated.)30 b(Run-time)16 b(sp)q(ecialization)h(p)q
(erforms)g(this)h(generation)f(at)h(run)f(time.)28 b(Th)o(us)18
b(here)g(the)g(sp)q(ecialized)0 589 y(pro)q(cedure)e(m)o(ust)d(b)q(e)h
(reused)i(a)d(n)o(um)o(b)q(er)g(of)h(times)f(to)g(get)i(an)o(y)e(b)q
(ene\014t)i(from)d(run-time)h(sp)q(ecialization.)62 639
y(The)g(cubic)g(spline)f(program)e(is)i(sp)q(ecialized)h(with)f(resp)q
(ect)i(to)e(the)h(n)o(um)o(b)q(er)f(of)f(p)q(oin)o(ts)h(\()p
Fi(n)p Ft(\))h(and)f(their)g Fi(x)p Ft(-co)q(ordinates.)0
689 y(The)h(program)e(con)o(tains)i(three)h(singly)d(nested)j(lo)q
(ops.)k(In)12 b(the)i(\014rst)f(t)o(w)o(o,)f(o)o(v)o(er)h(half)e(of)h
(the)h(computations)f(of)g(eac)o(h)h(b)q(o)q(dy)0 739
y(can)k(b)q(e)h(completely)e(ev)n(aluated)h(at)g(sp)q(ecialization)f
(time,)h(including)f(\015oating)g(p)q(oin)o(t)g(m)o(ultiplications)e
(and)j(divisions.)0 789 y(W)m(e)d(obtain)f(more)g(sp)q(eedup)j(than)e
(in)g(Rom)o(b)q(erg)e(in)o(tegration)i(b)q(ecause)i(a)d(larger)i(p)q
(ercen)o(tage)g(of)f(the)h(computations)e(are)0 839 y(static.)62
888 y(Cheb)o(yshev)20 b(appro)o(ximation)15 b(has)j(a)h(similar)c
(structure.)34 b(W)m(e)18 b(sp)q(ecialize)h(with)f(resp)q(ect)j(to)d
(the)h(degree)g Fi(n)g Ft(of)e(the)0 938 y(generated)e(p)q(olynomial)o
(.)g(In)f(addition)e(to)h(the)h(\015oating)e(p)q(oin)o(t)h(m)o
(ultiplications)e(and)i(divisions)f(that)i(can)f(b)q(e)h(p)q(erformed)0
988 y(at)f(sp)q(ecialization)g(time,)f(w)o(e)h(can)h(eliminate)d(a)i
(call)g(to)g(the)h(library)e(function)h Fk(cos)g Ft(from)f(eac)o(h)h
(unfolded)g(lo)q(op)g(iteration.)0 1038 y(Because)20
b(library)d(calls)g(are)h(v)o(ery)g(exp)q(ensiv)o(e,)i(w)o(e)e(obtain)f
(large)g(sp)q(eedups)j(from)c(b)q(oth)i(compile-tim)o(e)d(and)j
(run-time)0 1088 y(sp)q(ecialization.)g(F)m(urthermore)13
b(the)i(amortization)c(of)j(run-time)e(sp)q(ecialization)i(is)f(quite)h
(lo)o(w.)0 1204 y Fp(4.4)56 b(Strength)18 b(reduction)0
1280 y Ft(In)e(the)g(b)q(enc)o(hmarks)g(presen)o(ted)h(so)f(far,)f
(run-time)g(sp)q(ecialization)g(consisten)o(tly)h(ac)o(hiev)o(es)h(o)o
(v)o(er)e(80\045)g(of)g(the)h(sp)q(eedup)0 1330 y(obtained)e(b)o(y)g
(compile-time)d(sp)q(ecialization.)19 b(When)c(sp)q(ecialization)f
(triggers)g(compiler)f(optimizations,)f(ho)o(w)o(ev)o(er,)i(the)0
1380 y(sp)q(eedup)h(ac)o(hiev)o(ed)f(b)o(y)f(run-time)g(sp)q
(ecialization)g(is)g(m)o(uc)o(h)g(less.)18 b(Here)d(w)o(e)f(consider)g
(in)o(teger)g(m)o(ultiplication.)h(The)f(Sun)0 1430 y(SUPERSparc)g
(implemen)o(ts)d(in)o(teger)i(m)o(ultiplication)d(as)j(an)g
(instruction)g(rather)h(than)f(as)g(a)g(library)g(call.)k(Nev)o
(ertheless)0 1480 y(this)f(instruction)g(is)g(fairly)f(exp)q(ensiv)o
(e.)25 b(When)16 b(one)h(of)e(the)i(argumen)o(ts)e(is)h(a)f(constan)o
(t,)i(an)f(optimizing)d(compiler)i(can)0 1529 y(rewrite)g(the)g(m)o
(ultiplication)c(as)k(a)f(c)o(heap)q(er)i(sequence)g(of)e(shift)g(and)h
(add)f(op)q(erations)h([2)o(].)k(This)14 b(b)q(eha)o(vior)h(is)f
(exhibited)0 1579 y(b)o(y)g(the)g(dot)g(pro)q(duct)h(\(App)q(endix)f
(E\))g(and)g(dithering)g(\(App)q(endix)g(F\))g(examples.)0
1687 y Fj(4.4.1)48 b(Dot)15 b(pro)q(duct)0 1764 y Ft(As)e(sho)o(wn)f
(in)g(Figure)h(4,)f(sp)q(ecialization)f(of)h(dot)h(pro)q(duct)g(with)f
(resp)q(ect)j(to)d(a)g(v)o(ector)h(and)f(its)h(size)g(pro)q(duces)h(a)e
(sequence)0 1814 y(of)f(m)o(ultiplications)e(of)j(a)f(constan)o(t)i(b)o
(y)e(an)h(arra)o(y)g(reference.)20 b(When)12 b(sp)q(ecialization)f(is)h
(p)q(erformed)g(at)g(compile)e(time,)g(the)0 1863 y(compiler)g
(translates)i(eac)o(h)g(m)o(ultiplication)c(as)k(a)f(sequence)i(of)e
(shift)h(and)f(addition)f(instructions,)i(obtaining)e(substan)o(tial)0
1913 y(sp)q(eedups.)24 b(Because)17 b(the)f(constan)o(ts)g(are)f(not)g
(a)o(v)n(ailable)e(at)i(compile)f(time)g(when)h(run-time)f(sp)q
(ecializer)j(pro)q(duces)f(the)0 1963 y(ob)r(ject)i(templates,)f(the)h
(m)o(ultiplicatio)o(ns)d(are)j(translated)f(as)h(in)o(teger)f(m)o
(ultiplication)d(instructions.)29 b(Th)o(us)17 b(run-time)0
2013 y(sp)q(ecialization)c(sa)o(v)o(es)i(only)e(the)h(lo)q(op)f(o)o(v)o
(erhead.)62 2063 y(W)m(e)f(can)h(reduce)g(the)g(m)o(ultiplication)c
(cost)k(in)f(the)h(run-time)e(sp)q(ecialized)i(co)q(de)g(b)o(y)f
(rewriting)g(the)h(program)d(to)i(mak)o(e)0 2113 y(sp)q(ecial)i(cases)g
(explicit)f(at)g(compile)f(time.)17 b(Clearly)12 b(it)h(is)h
(infeasible)e(to)h(mak)o(e)f(a)h(sp)q(ecial)h(case)g(for)f(ev)o(ery)h
(in)o(teger.)19 b(When)0 2162 y(the)14 b(matrix)d(is)i(kno)o(wn)g(to)g
(b)q(e)h(sparse,)g(ho)o(w)o(ev)o(er,)g(w)o(e)f(can)h(ac)o(hiev)o(e)f
(signi\014can)o(t)g(sp)q(eedups)i(b)o(y)e(rewriting)h(the)f(program)f
(to)0 2212 y(test)17 b(whether)h(the)f(elemen)o(t)f(of)g(the)g(static)h
(v)o(ector)g(is)f(0.)25 b(If)16 b(so,)h(no)f(m)o(ultiplication)d(is)j
(p)q(erformed.)25 b(There)18 b(is)e(a)g(sligh)o(t)0 2262
y(o)o(v)o(erhead)11 b(for)g(the)g(test,)i(but)e(it)f(only)g(tak)o(es)i
(place)f(during)g(the)g(generation)g(of)g(the)g(sp)q(ecialized)h(pro)q
(cedure,)h(and)e(a)f(test)i(for)0 2312 y(0)i(is)g(relativ)o(ely)f
(inexp)q(ensiv)o(e.)19 b(With)14 b(this)g(optimization,)d(the)j(sp)q
(eedup)i(\(sho)o(wn)e(in)g(Figure)g(11\))f(obtained)h(b)o(y)g(run-time)
0 2362 y(sp)q(ecialization)f(approac)o(hes)i(that)f(of)f(compile-time)e
(sp)q(ecialization)i(for)h(sparse)h(matrices.)62 2411
y(Dot)f(pro)q(duct)h(is)f(used)h(in)f(matrix)e(m)o(ultiplication.)j
(Because)i(the)d(ro)o(w)g(of)g(the)h(\014rst)f(matrix)f(is)h(m)o
(ultiplied)d(b)o(y)j(ev)o(ery)0 2461 y(column)i(of)h(the)i(second)g
(matrix,)d(sp)q(ecialization)i(is)f(b)q(ene\014cial.)31
b(W)m(e)17 b(consider)i(a)e(matrix)f(of)i(size)g Fi(n)12
b Fq(\002)g Fi(n)p Ft(.)30 b(F)m(or)17 b(large)0 2511
y(matrices,)d(compile-tim)o(e)e(sp)q(ecialization)i(seems)h
(impractical.)j(Th)o(us)d(e\013ectiv)o(e)g(run-time)f(sp)q
(ecialization)g(is)g(critical)g(in)0 2561 y(this)g(application.)k
(Here,)d(the)g(cost)g(of)f(generating)g(a)g(sp)q(ecialized)i(pro)q
(cedure)g(at)e(run)h(time)e(is)h(naturally)f(amortized)g(b)o(y)0
2611 y(the)h(n)o(um)o(b)q(er)g(of)f(columns)g(in)g(the)i(second)g
(matrix.)954 2795 y(12)p eop
%%Page: 13 13
13 12 bop 0 42 a Fj(4.4.2)48 b(Ditherin)o(g)0 118 y Ft(Dithering)20
b(reduces)j(the)e(n)o(um)o(b)q(er)f(of)g(shades)i(of)e(color)g(used)h
(in)g(an)f(image.)36 b(W)m(e)20 b(sp)q(ecialize)i(with)e(resp)q(ect)j
(to)d(the)0 168 y(command-li)o(ne)10 b(inputs,)i(whic)o(h)g(are)h(the)g
(size)g(of)f(the)h(dithering)f(matrix)e(and)i(the)h(n)o(um)o(b)q(er)f
(of)f(shades)j(of)d(red,)i(green,)g(and)0 218 y(blue.)27
b(The)18 b(complete)e(ppmdither)g(program)g(consists)i(of)e(a)h(setup)h
(pro)q(cedure,)h(whic)o(h)e(initializes)f(some)g(arra)o(ys)h(used)0
268 y(in)d(the)h(dithering)f(pro)q(cess,)i(and)e(the)h(dith)p
685 268 13 2 v 15 w(dither)g(pro)q(cedure,)h(whic)o(h)e(calculates)h
(the)g(new)g(v)n(alue)f(of)g(eac)o(h)h(pixel)e(in)h(the)0
317 y(image.)24 b(Because)18 b(t)o(ypically)d(the)i(size)g(of)f(the)h
(image)d(far)i(exceeds)j(the)e(size)g(of)f(these)h(arra)o(ys,)g(w)o(e)g
(sp)q(ecialize)g(only)e(the)0 367 y(dith)p 76 367 V 15
w(dither)f(pro)q(cedure.)62 417 y(Clearly)c(w)o(e)h(cannot)g(sp)q
(ecialize)h(the)f(dithering)f(op)q(eration)h(to)g(eac)o(h)g(pixel)f(in)
g(the)i(image.)j(Th)o(us)c(w)o(e)f(do)h(not)g(unroll)e(an)o(y)0
467 y(lo)q(ops,)k(and)g(only)g(sp)q(ecialize)h(with)f(resp)q(ect)j(to)d
(the)h(command-line)d(inputs.)18 b(The)c(a)o(v)n(ailabili)o(t)o(y)c(of)
j(these)i(v)n(alues)e(triggers)0 517 y(some)d(constan)o(t)h(folding.)k
(But)c(the)g(main)d(impro)o(v)o(emen)o(t)g(comes)i(from)e(the)j
(rewriting)g(of)f(in)o(teger)g(m)o(ultiplications)e(as)i(shift)0
566 y(and)k(add)h(op)q(erations.)20 b(In)15 b(the)g(dith)p
584 566 V 15 w(dither)g(pro)q(cedure,)h(at)f(least)g(one)g(argumen)o(t)
e(of)h(ev)o(ery)i(m)o(ultipli)o(cation)c(expression)0
616 y(is)k(a)o(v)n(ailable)f(at)h(sp)q(ecialization)g(time.)24
b(The)17 b(divisions)f(required)h(ha)o(v)o(e)g(the)g(further)g(prop)q
(ert)o(y)g(that)g(in)f(eac)o(h)h(case)g(the)0 666 y(denominator)10
b(is)i(static)g(and)g(a)f(p)q(o)o(w)o(er)h(of)g(t)o(w)o(o.)k(Th)o(us)d
(a)e(compiler)f(can)j(translate)f(these)h(division)e(op)q(erations)h
(using)f(shift)0 716 y(as)j(w)o(ell.)62 766 y(The)j(sp)q(eedup)g
(obtained)f(for)g(the)g(dith)p 700 766 V 15 w(dither)g(pro)q(cedure)i
(from)d(compile-tim)o(e)e(sp)q(ecialization)j(re\015ects)i(these)f(ob-)
0 816 y(serv)n(ations.)k(Because)16 b(the)g(ppmdither)e(program)f(t)o
(ypically)g(sp)q(ends)j(at)f(least)g(half)e(the)j(time)d(in)h(this)h
(pro)q(cedure,)i(these)0 865 y(sp)q(eedups)f(translate)e(in)o(to)f
(signi\014can)o(t)h(impro)o(v)o(emen)o(t)d(of)i(the)i(en)o(tire)f
(program.)62 915 y(Run-time)e(sp)q(ecialization)h(of)g(the)h(original)e
(program)g(is,)h(ho)o(w)o(ev)o(er,)h(less)g(successful.)20
b(Some)12 b(constan)o(t)j(folding)d(tak)o(es)0 965 y(place,)g(but)h(b)q
(ecause)h(the)f(simpli\014ed)e(expressions)j(do)e(not)g(dep)q(end)i(on)
e(the)h(lo)q(op)e(indices,)i(they)g(can)g(b)q(e)g(lifted)e(out)i(of)e
(the)0 1015 y(lo)q(op)i(b)o(y)h(a)f(smart)g(compiler.)k(These)e(observ)
n(ations)f(are)g(v)o(eri\014ed)h(b)o(y)e(the)i(negligeable)e(sp)q
(eedup)j(obtained.)62 1065 y(Again)c(w)o(e)g(can)h(mo)o(v)o(e)d(the)j
(strength)g(reduction)g(optimization)d(to)i(the)h(source)g(lev)o(el.)k
(Here)d(0)e(is)g(no)g(more)f(lik)o(ely)g(than)0 1114
y(an)o(y)f(other)h(input,)g(so)g(w)o(e)f(simply)f(implemen)o(t)f(the)j
(algorithms)d(to)i(rewrite)i(division)d(b)o(y)i(a)f(p)q(o)o(w)o(er)h
(of)f(2)g(and)g(m)o(ultiplication)0 1164 y(b)o(y)i(a)g(constan)o(t)h
(in)e(the)i(source)g(program)e(itself.)17 b(With)12 b(this)g(straigh)o
(tforw)o(ard)g(rewriting)g(of)f(the)i(source)g(co)q(de,)g(w)o(e)g
(obtain)0 1214 y(a)g(sp)q(eedup)i(comparable)d(to)h(that)g(obtained)g
(b)o(y)g(compile-tim)o(e)e(sp)q(ecialization)h(of)h(the)h(original)d
(program)h(\(see)i(the)g(lines)0 1264 y(lab)q(eled)e(\\optimized")f(in)
h(the)h(tables\).)k(The)c(o)o(v)o(erhead)g(to)f(calculate)h(the)g
(sequence)h(of)e(shift)g(and)g(addition)f(instructions)0
1314 y(required)k(is)f(negligeable.)k(The)c(sp)q(ecialized)h(co)q(de)g
(is)f(applied)f(to)h(ev)o(ery)h(pixel)e(in)h(the)h(image.)h(W)m(e)e
(require)h(an)e(image)g(of)0 1363 y(only)g(17)g(pixels)h(to)g(amortize)
f(the)h(cost)h(of)e(sp)q(ecialization.)0 1501 y Fu(5)67
b(Related)23 b(W)-6 b(ork)0 1592 y Ft(This)18 b(section)h(presen)o(ts)i
(other)e(existing)f(approac)o(hes)h(that,)g(as)f(with)g(run-time)f(sp)q
(ecialization,)i(attempt)e(to)i(exploit)0 1641 y(run-time)13
b(v)n(alues.)0 1758 y Fp(5.1)56 b(Dynamic)16 b(Compilation)0
1834 y Ft(Dynamic)c(compilation)f(p)q(erforms)i(optimizations)f(at)h
(run-time)g(on)h(the)g(dynamically)d(generated)k(binary)f(co)q(de,)g
(incur-)0 1884 y(ring)h(an)g(additional)f(run-time)g(o)o(v)o(erhead)i
(in)f(an)g(attempt)f(to)i(further)g(increase)h(the)f(co)q(de)g(qualit)o
(y)m(.)k(Our)c(results)h(sho)o(w)0 1934 y(that)12 b(w)o(e)h(can)f(pro)q
(duce)h(dynamically)d(generated)j(binary)f(co)q(de)h(whic)o(h)f(is)g
(already)g(su\016cien)o(tly)g(optimized.)k(In)c(this)g(case,)0
1984 y(not)i(only)f(is)h(there)h(little)e(ro)q(om)f(left)i(for)g(impro)
o(v)o(em)o(en)o(t,)d(but)j(ac)o(hieving)g(it)f(will)f(b)q(e)j(costly)m
(.)62 2034 y(There)h(are)e(t)o(w)o(o)g(existing)g(dynamic)e
(compilation)f(systems.)19 b(The)c(\014rst,)f(prop)q(osed)h(b)o(y)f
(Auslander)h Fo(et.al.)j Ft(treats)d(the)0 2083 y(C)g(language)f([1)o
(].)21 b(This)15 b(system)g(p)q(erforms)g(instruction)g(sc)o(heduling)g
(and)g(p)q(eephole)h(optimizations)d(at)i(run)g(time.)21
b(The)0 2133 y(b)q(enc)o(hmark)15 b(suite)h(used)h(to)e(c)o
(haracterize)j(this)d(system)h(di\013ers)g(from)e(ours,)i(so)f(a)h
(direct)g(comparison)e(is)i(not)f(p)q(ossible.)0 2183
y(Nev)o(ertheless,)f(on)d(their)h(b)q(enc)o(hmarks)g(they)g(ac)o(hiev)o
(e)f(sp)q(eedups)j(b)q(et)o(w)o(een)f(1.2)d(and)i(1.8.)k(On)c(the)g
(other)g(hand,)g(their)g(high)0 2233 y(dynamic)j(compilation)f(o)o(v)o
(erhead)k(greatly)f(increases)h(their)g(break-ev)o(en)g(p)q(oin)o(ts,)f
(whic)o(h)g(range)g(from)e(700)h(to)h(30,000.)0 2283
y(These)e(\014gures)g(suggest)g(that)f(the)g(extra)g(run-time)f(in)o(v)
o(estmen)o(t)g(do)q(es)i(not)f(pa)o(y)f(o\013.)62 2332
y(The)f(other)g(dynamic)e(compilation)e(system,)j(F)m(abius,)g(treats)h
(a)f(pure,)h(\014rst-order)h(subset)g(of)d(the)i(SML)g(programmi)o(ng)0
2382 y(language)f([10)o(,)h(11,)g(12)o(,)g(9].)17 b(It)12
b(also)g(p)q(erforms)g(instruction)g(sc)o(heduling)h(and)f(p)q(eephole)
h(optimizations)d(at)i(run-time,)f(and)0 2432 y(an)k(inexp)q(ensiv)o(e)
i(form)c(of)i(register)i(allo)q(cation)d(called)h Fo(r)n(e)n(gister)g
(assignment)h Ft(is)f(b)q(eing)h(in)o(v)o(estigated.)23
b(Benc)o(hmarks)15 b(for)0 2482 y(this)10 b(system)f(are)h(also)f(giv)o
(en,)h(but)g(they)g(are)g(hard)g(to)g(in)o(terpret)g(since)h(they)f(do)
g(not)f(precisely)i(assess)g(run-time)e(generation)0
2532 y(costs.)954 2795 y(13)p eop
%%Page: 14 14
14 13 bop 0 42 a Fp(5.2)56 b(Tic)n(k)18 b(C)0 118 y Ft(Tic)o(k)12
b(C)h(is)f(a)h(language)f(whic)o(h)g(o\013ers)i(an)e(extension)i(to)e
(ANSI)h(C,)f(allo)o(wing)f(the)i(programmer)d(to)j(generate)h(co)q(de)f
(at)g(run)0 168 y(time)h([5)o(].)21 b(The)16 b(dynamic)d(co)q(de)j(is)f
(sp)q(eci\014ed)i(with)e(a)f(macro)g(mec)o(hanism)f(similar)g(to)i(the)
g(bac)o(kquote)h(\()p Fk(`)p Ft(\))f(and)g(comma)0 218
y(\()p Fk(,)p Ft(\))g(op)q(erators)h(in)e(Lisp.)21 b(This)15
b(approac)o(h)g(di\013ers)h(from)d(run-time)g(sp)q(ecialization)i(and)f
(dynamic)g(compilation)e(since)j(it)0 268 y(is)d(not)g(automatic)f(and)
h(do)q(es)h(not)f(p)q(erform)g(an)o(y)f(t)o(yp)q(e)i(of)f(sp)q
(ecialization.)17 b(Instead,)c(the)g(user)g(is)f(required)h(to)f(sp)q
(ecify)h(the)0 317 y(fragmen)o(ts)g(of)g(co)q(de)i(to)e(b)q(e)i
(generated)g(at)f(run)g(time.)62 367 y(Tic)o(k)d(C)h(o\013ers)g(y)o(et)
g(another)g(bac)o(k)o(end)g(to)f(our)h(run-time)e(sp)q(ecializer.)19
b(In)11 b(addition)g(to)g(using)g Fk(gcc)g Ft(or)g Fk(lcc)g
Ft(to)h(generate)0 417 y(the)17 b(ob)r(ject)h(templates,)e(T)m(emp)q(o)
f(is)h(also)g(capable)h(of)f(pro)q(ducing)h(the)g(appropriate)f(source)
i(templates)e(whic)o(h)h(Tic)o(k)f(C)0 467 y(con)o(v)o(erts)j(directly)
f(in)o(to)f(their)h(corresp)q(onding)h(ob)r(ject)f(templates.)30
b(W)m(e)17 b(are)h(curren)o(tly)h(p)q(erforming)d(exp)q(erimen)o(ts)i
(to)0 517 y(assess)e(the)e(adv)n(an)o(tages)f(and)h(disadv)n(an)o
(tages)g(of)f(these)i(di\013eren)o(t)g(co)q(de)g(generation)f(sc)o
(hemes.)0 654 y Fu(6)67 b(Conclusions)22 b(and)h(F)-6
b(uture)24 b(W)-6 b(ork)0 745 y Ft(W)m(e)13 b(ha)o(v)o(e)h(dev)o(elop)q
(ed)g(new)g(tec)o(hniques)h(to)e(implemen)o(t)e(e\016cien)o(t)j
(run-time)f(sp)q(ecialization)g(for)g(C)h(programs.)j(They)d(are)0
795 y(in)o(tegrated)k(in)g(a)f(partial)g(ev)n(aluator)g(called)g(T)m
(emp)q(o)g(whic)o(h)g(sp)q(ecializes)i(programs)e(at)g(b)q(oth)h
(compile)f(time)f(and)i(run)0 844 y(time.)27 b(Measuremen)o(ts)19
b(comparing)c(statically)i(sp)q(ecialized)h(programs)e(to)i
(dynamically)c(assem)o(bled)j(binary)g(co)q(de)h(on)0
894 y(scien)o(ti\014c)f(and)g(graphics)f(co)q(de)i(ha)o(v)o(e)e(sho)o
(wn)h(that)f(run-time)g(sp)q(ecialized)h(co)q(de)g(is)f(nearly)h
(\(80\045)f(on)g(a)o(v)o(erage\))g(as)h(fast)0 944 y(as)h(compile-tim)o
(e)d(sp)q(ecialized)k(co)q(de.)30 b(These)19 b(measuremen)o(ts)e
(demonstrate)h(that)f(few)h(opp)q(ortunities)g(are)g(left)g(if,)f(as)0
994 y(adv)o(o)q(cated)d(b)o(y)g(others,)h(further)g(optimizations)d
(are)i(deferred)i(to)e(run)h(time,)d(incurring)i(an)g(additional)e(o)o
(v)o(erhead.)19 b(Our)0 1044 y(approac)o(h)14 b(has)g(b)q(een)h(sho)o
(wn)f(to)g(b)q(e)h(p)q(ortable)f(and)g(\015exible)f(as)i(illustrated)e
(b)o(y)h(our)g(implemen)o(tation)d(to)i Fk(lcc)p Ft(,)g
Fk(gcc)p Ft(,)g(and)0 1094 y(Tic)o(k)h(C.)62 1143 y(W)m(e)f(are)g
(exploring)g(the)g(use)h(of)f(our)g(run-time)f(sp)q(ecializer)i(for)e
(other)i(languages)f(than)g(C.)f(Indeed,)i(man)o(y)d(compilers)0
1193 y(for)i(languages)g(suc)o(h)h(as)g(Mo)q(dule-3,)e(C++)i(and)g(Ja)o
(v)n(a)e(use)j(C)e(as)h(a)f(target)h(language.)j(A)c(promising)f(a)o(v)
o(en)o(ue)h(of)g(researc)o(h)0 1243 y(consists)h(of)e(considering)g(T)m
(emp)q(o)f(as)i(a)f Fo(b)n(ack-end)j(p)n(artial)e(evaluator)f
Ft(whic)o(h)h(can)f(treat)i(v)n(arious)e(source)h(languages,)f(once)0
1293 y(programs)j(are)h(compiled)e(in)o(to)h(C.)h(In)g(fact,)g(w)o(e)g
(ha)o(v)o(e)g(dev)o(elop)q(ed)g(an)g(o\017ine)f(compiler)f(for)i(Ja)o
(v)n(a)f(b)o(yteco)q(de)i(to)f(C)g([14)o(];)0 1343 y(w)o(e)h(are)h
(studying)f(the)g(sp)q(ecialization)g(of)f(the)i(resulting)f(C)g
(programs)f(at)h(b)q(oth)g(compile)f(time)f(and)i(run)h(time.)26
b(This)0 1392 y(strategy)15 b(amoun)o(ts)d(to)i(obtaining)e(a)i(Ja)o(v)
n(a)f(partial)g(ev)n(aluator)g(solely)g(b)o(y)h(in)o(tro)q(ducing)g(a)f
(translation)g(phase.)62 1442 y(T)m(emp)q(o)f(has)i(started)g(to)f(b)q
(e)h(used)h(b)o(y)e(researc)o(hers)j(in)d(v)n(arious)g(areas)h(suc)o(h)
g(as)f(graphics,)h(scien)o(ti\014c)g(computing,)d(and)0
1492 y(op)q(erating)j(systems.)k(In)c(the)g(near)g(future,)g(w)o(e)g
(exp)q(ect)i(to)e(collect)g(more)e(exp)q(erimen)o(tal)h(results)i(to)f
(allo)o(w)e(us)i(to)g(further)0 1542 y(ev)n(aluate)g(our)f(run-time)g
(sp)q(ecializer.)62 1592 y(Close)h(examination)e(of)h(some)g(programs)g
(has)h(rev)o(ealed)g(opp)q(ortunities)g(to)g(p)q(erform)f(sp)q
(eci\014c)j(optimizations)11 b(whic)o(h)0 1641 y(rely)i(on)g(run-time)g
(v)n(alues.)k(These)e(optimizations)c(mainly)f(concern)15
b(algebraic)e(simpli\014cations.)i(Instead)f(of)f(increasing)0
1691 y(the)j(complexit)o(y)e(of)h(the)h(run-time)e(sp)q(ecializer)i(b)o
(y)g(incorp)q(orating)f(these)h(optimizations,)e(w)o(e)h(prop)q(ose)i
(to)e(rewrite)h(the)0 1741 y(source)j(program)d(to)i(b)q(e)g(sp)q
(ecialized)g(to)g(in)o(tro)q(duce)g(op)q(erations)g(that)g(trigger)g
(optimizations.)27 b(As)18 b(w)o(e)g(ha)o(v)o(e)g(seen,)h(a)0
1791 y(program)11 b(manipulating)f(sparse)k(arra)o(ys)f(can)g(b)q(e)h
(rewritten)g(to)f(test)h(whether)g(the)g(elemen)o(ts)f(of)f(a)h(static)
g(arra)o(y)g(are)g(0.)k(If)0 1841 y(this)e(v)n(alue)f(is)h(an)g(op)q
(erand)g(of)f(suc)o(h)i(op)q(erators)g(as)f(m)o(ultiplicatio)o(n)d(or)j
(addition,)f(the)h(op)q(eration)g(do)q(es)h(not)f(need)h(to)e(b)q(e)0
1891 y(p)q(erformed.)j(Prop)q(erties)e(suc)o(h)e(as)g(sparseness)i(of)d
(arra)o(ys)h(could)g(b)q(e)g(used)h(to)e(guide)h(the)g(rewritings)g
(and)g(guaran)o(tee)g(that)0 1940 y(only)g(the)i(necessary)h
(optimizations)c(are)j(in)o(tro)q(duced,)f(th)o(us)h(minim)o(izing)10
b(the)15 b(o)o(v)o(erhead.)k(W)m(e)14 b(plan)g(to)g(explore)g(further)0
1990 y(the)g(feasibilit)o(y)f(of)g(this)h(approac)o(h.)0
2127 y Fu(References)21 2218 y Ft([1])19 b(J.)e(Auslander,)i(M.)d
(Philip)q(ose,)i(C.)e(Cham)o(b)q(ers,)h(S.J.)g(Eggers,)h(and)g(B.N.)e
(Bershad.)i({)29 b(F)m(ast,)17 b(e\013ectiv)o(e)i(dynamic)85
2268 y(compilation.)11 b({)18 b(In)c(PLDI96)f([16)o(],)g(pages)h
(149{159.)21 2351 y([2])19 b(R.)9 b(Bernstein.)i({)g(Multiplication)d
(b)o(y)h(in)o(teger)h(constan)o(ts.)h({)g Fo(Softwar)n(e|Pr)n(actic)n
(e)f(and)i(Exp)n(erienc)n(e)p Ft(,)e(16\(7\):641{652,)85
2401 y(July)k(1986.)21 2484 y([3])19 b(C.)d(Consel,)h(L.)f(Hornof,)g
(F.)g(No)o(\177)-20 b(el,)17 b(J.)f(No)o(y)o(\023)-20
b(e,)17 b(and)f(E.N.)g(V)m(olansc)o(hi.)f({)26 b(A)17
b(uniform)d(approac)o(h)j(for)f(compile-time)85 2534
y(and)g(run-time)f(sp)q(ecialization.)g({)23 b(In)16
b(O.)g(Dan)o(vy)m(,)e(R.)h(Gl)q(\177)-22 b(uc)o(k,)15
b(and)h(P)m(.)f(Thiemann,)f(editors,)j Fo(Partial)f(Evaluation,)85
2584 y(International)k(Seminar,)g(Dagstuhl)g(Castle)p
Ft(,)f(n)o(um)o(b)q(er)f(1110)g(in)g(Lecture)j(Notes)e(in)g(Computer)f
(Science,)j(pages)85 2633 y(54{72,)12 b(F)m(ebruary)j(1996.)954
2795 y(14)p eop
%%Page: 15 15
15 14 bop 21 42 a Ft([4])19 b(C.)14 b(Consel)g(and)f(F.)h(No)o(\177)-20
b(el.)13 b({)19 b(A)14 b(general)g(approac)o(h)g(for)f(run-time)g(sp)q
(ecialization)g(and)h(its)g(application)f(to)g(C.)h({)k(In)85
91 y(POPL96)c([17)o(],)f(pages)i(145{156.)21 174 y([5])k(D.R.)12
b(Engler,)i(W.C.)e(Hsieh,)i(and)g(M.F.)f(Kaasho)q(ek.)h({)k
Fk(`)p Ft(C:)13 b(A)g(language)g(for)h(high-lev)o(el,)e(e\016cien)o(t,)
i(and)f(mac)o(hine-)85 224 y(indep)q(enden)o(t)j(dynamic)c(co)q(de)i
(generation.)g({)k(In)c(POPL96)g([17)o(],)f(pages)h(131{144.)21
307 y([6])19 b(C.)14 b(W.)g(F)m(raser)h(and)f(D.)g(R.)f(Hanson.)h({)20
b(A)14 b(co)q(de)i(generation)e(in)o(terface)h(for)f(ANSI)h(C.)f({)20
b Fo(Softwar)n(e)14 b(-)h(Pr)n(actic)n(e)g(and)85 357
y(Exp)n(erienc)n(e)p Ft(,)f(21\(9\):963{988,)d(1991.)21
440 y([7])19 b(R.)13 b(Gl)q(\177)-22 b(uc)o(k,)12 b(R.)g(Nak)n(ashige,)
h(and)g(R.)f(Z\177)-21 b(oc)o(hling.)12 b({)17 b(Binding-time)11
b(analysis)i(applied)g(to)g(mathematical)d(algorithms.)85
490 y({)18 b(In)13 b(J.)g(Dole)o(\024)-20 b(zal)13 b(and)g(J.)g
(Fidler,)g(editors,)g Fo(System)i(Mo)n(del)r(ling)g(and)g(Optimization)
p Ft(,)d(pages)i(137{146.)d(Chapman)h(&)85 540 y(Hall,)h(1995.)21
623 y([8])19 b(D.)11 b(Kepp)q(el,)i(S.)e(Eggers,)i(and)e(R.)g(Henry)m
(.)g({)k(A)d(case)g(for)g(run)o(time)e(co)q(de)j(generation.)e({)k(T)m
(ec)o(hnical)c(Rep)q(ort)h(91-11-04,)85 672 y(Departmen)o(t)i(of)f
(Computer)g(Science,)i(Univ)o(ersit)o(y)f(of)f(W)m(ashington,)f
(Seattle,)i(W)-5 b(A,)14 b(1991.)21 756 y([9])19 b(P)m(.)10
b(Lee)i(and)f(M.)f(Leone.)h({)i(Optimizing)c(ML)i(with)f(run-time)g(co)
q(de)i(generation.)e({)j(In)e(PLDI96)f([16],)g(pages)h(137{148.)0
839 y([10])19 b(M.)f(Leone)g(and)f(P)m(.)g(Lee.)h({)30
b(Ligh)o(t)o(w)o(eigh)o(t)16 b(run-time)h(co)q(de)h(generation.)f({)30
b(In)17 b Fo(A)o(CM)i(SIGPLAN)f(Workshop)h(on)85 888
y(Partial)d(Evaluation)h(and)g(Semantics-Base)n(d)h(Pr)n(o)n(gr)n(am)d
(Manipulation)p Ft(.)h(T)m(ec)o(hnical)g(Rep)q(ort)f(94/9,)g(Univ)o
(ersit)o(y)h(of)85 938 y(Melb)q(ourne,)f(Australia,)d(1994.)0
1021 y([11])19 b(M.)14 b(Leone)h(and)f(P)m(.)g(Lee.)h({)k(Optimizing)12
b(ML)j(with)f(run-time)f(co)q(de)i(generation.)f({)20
b(T)m(ec)o(hnical)13 b(Rep)q(ort)i(CMU-CS-)85 1071 y(95-205,)d(Sc)o(ho)
q(ol)i(of)f(Computer)g(Science,)i(Carnegie)f(Mellon)f(Univ)o(ersit)o(y)
m(,)g(Decem)o(b)q(er)h(1995.)0 1154 y([12])19 b(M.)13
b(Leone)g(and)g(P)m(.)f(Lee.)h({)j(A)d(declarativ)o(e)g(approac)o(h)g
(to)g(run-time)e(co)q(de)j(generation.)e({)17 b(In)c(W)o(CSSS96)f([21)o
(],)g(pages)85 1204 y(8{17.)0 1287 y([13])19 b(B.N.)10
b(Lo)q(can)o(thi.)g({)i(F)m(ast)e(bitblt\(\))g(with)g(asm\(\))f(and)h
(cpp.)h({)h(In)e Fo(Eur)n(op)n(e)n(an)i(UNIX)g(Systems)f(User)g(Gr)n
(oup)h(Confer)n(enc)n(e)85 1337 y(Pr)n(o)n(c)n(e)n(e)n(dings)p
Ft(,)i(pages)g(243{259,)d(A)m(T&T)j(Bell)g(Lab)q(oratories,)g(Murra)o
(y)g(Hill,)e(Septem)o(b)q(er)i(1987.)e(EUUG.)0 1420 y([14])19
b(G.)e(Muller,)i(B.)f(Moura,)h(F.)e(Bellard,)i(and)f(C.)f(Consel.)h({)
31 b(Jit)18 b Fo(vs.)g Ft(o\017ine)f(compilers:)26 b(Limits)16
b(and)i(b)q(ene\014ts)i(of)85 1469 y(b)o(yteco)q(de)15
b(compilation.)c({)18 b(Rapp)q(ort)c(de)g(rec)o(herc)o(he,)i(Inria,)d
(Rennes,)h(F)m(rance,)g(1996.)0 1553 y([15])19 b(R.)c(Pik)o(e,)h(B.)g
(N.)g(Lo)q(can)o(thi,)g(and)f(J.F.)h(Reiser.)g({)24 b(Hardw)o(are/soft)
o(w)o(are)17 b(trade-o\013s)g(for)e(bitmap)f(graphics)j(on)e(the)85
1602 y(blit.)e({)18 b Fo(Softwar)n(e)c(-)h(Pr)n(actic)n(e)f(and)i(Exp)n
(erienc)n(e)p Ft(,)e(15\(2\):131{151,)c(1985.)0 1685
y([16])19 b Fo(Pr)n(o)n(c)n(e)n(e)n(dings)d(of)h(the)f(A)o(CM)g
(SIGPLAN)h('96)f(Confer)n(enc)n(e)g(on)h(Pr)n(o)n(gr)n(amming)f(L)n
(anguage)h(Design)g(and)g(Implemen-)85 1735 y(tation)p
Ft(.)d(A)o(CM)g(SIGPLAN)g(Notices,)g(31\(5\),)f(Ma)o(y)g(1996.)0
1818 y([17])19 b Fo(Confer)n(enc)n(e)13 b(R)n(e)n(c)n(or)n(d)f(of)g
(the)h Ft(23)585 1803 y Fb(r)q(d)632 1818 y Fo(A)o(nnual)g(A)o(CM)f
(SIGPLAN-SIGA)o(CT)g(Symp)n(osium)h(on)g(Principles)f(Of)g(Pr)n(o)n(gr)
n(am-)85 1868 y(ming)j(L)n(anguages)p Ft(,)g(St.)e(P)o(etersburg)j
(Beac)o(h,)f(FL,)e(USA,)h(Jan)o(uary)f(1996.)g(A)o(CM)h(Press.)0
1951 y([18])19 b(C.)12 b(Pu,)g(H.)g(Massalin,)f(and)h(J.)g(Ioannidis.)e
({)15 b(The)e(Syn)o(thesis)f(k)o(ernel.)g({)k Fo(Computing)d(Systems)p
Ft(,)f(1\(1\):11{32,)e(Win)o(ter)85 2001 y(1988.)0 2084
y([19])19 b(E.N.)13 b(V)m(olansc)o(hi,)f(G.)g(Muller,)h(and)g(C.)g
(Consel.)g({)k(Safe)d(op)q(erating)f(system)g(sp)q(ecialization:)k(the)
d(RPC)f(case)h(study)m(.)85 2134 y({)k(In)c(W)o(CSSS96)f([21)o(],)g
(pages)i(24{28.)0 2217 y([20])k(E.N.)13 b(V)m(olansc)o(hi,)f(G.)g
(Muller,)h(C.)g(Consel,)g(L.)f(Hornof,)h(J.)g(No)o(y)o(\023)-20
b(e,)13 b(and)g(C.)g(Pu.)g({)k(A)c(uniform)f(automatic)f(approac)o(h)85
2267 y(to)g(cop)o(y)h(elimination)c(in)j(system)g(extensions)h(via)e
(program)g(sp)q(ecialization.)g({)k(Rapp)q(ort)d(de)h(rec)o(herc)o(he)i
(2903,)c(Inria,)85 2316 y(Rennes,)15 b(F)m(rance,)f(June)g(1996.)0
2399 y([21])19 b Fo(Workshop)c(R)n(e)n(c)n(or)n(d)f(of)g(WCSSS'96)h({)f
(The)g(Inaugur)n(al)h(Workshop)g(on)f(Compiler)f(Supp)n(ort)h(for)g
(Systems)g(Softwar)n(e)p Ft(,)85 2449 y(T)m(ucson,)g(AZ,)g(USA,)f(F)m
(ebruary)i(1996.)954 2795 y(15)p eop
%%Page: 16 16
16 15 bop 62 42 a Ft(The)11 b(app)q(endices)g(con)o(tain)f(the)h(C)f
(programs)f(used)i(to)f(obtain)f(the)i(exp)q(erimen)o(tal)e(results)j
(presen)o(ted)g(in)e(Section)g(4.)17 b(T)m(o)0 91 y(sho)o(w)10
b(ho)o(w)f(the)h(programs)e(are)i(transformed)f(during)g(sp)q
(ecialization,)h(w)o(e)f(ha)o(v)o(e)h(annotated)g(the)g(programs)e
(corresp)q(onding)0 141 y(to)18 b(the)h(actions)f(automatically)d(pro)q
(duced)k(b)o(y)f(our)g(analysis)f(phase.)32 b(Constructs)19
b(whic)o(h)f(are)h(eliminated)d(from)g(the)0 191 y(residual)h(program)f
(\(those)j(annotated)e(with)h Fo(ev)f Ft(or)h Fo(r)n(e)n(d)f
Ft(actions\))g(are)h(presen)o(ted)i(in)d Fo(italics)p
Ft(,)g(while)g(those)h(whic)o(h)g(are)0 241 y(residualized)c
(\(annotated)h(with)e Fo(r)n(eb)g Ft(or)h Fo(id)g Ft(actions\))g(are)g
(presen)o(ted)i(in)e Fj(b)q(oldface)p Ft(.)0 378 y Fu(A)67
b(P)n(o)n(w)n(er)0 482 y Fj(in)o(t)14 b(p)q(o)o(w)o(er\(in)o(t)f(base,)
i Fo(int)g(exp)s Fj(\))0 532 y Fa(f)91 581 y Fj(in)o(t)f(acc;)91
681 y(acc)i(=)g(1;)91 781 y Fo(while)e(\(exp)h Fi(>)g
Fo(0\))g Fq(f)181 830 y Fj(acc)i(=)f(acc)g(*)g(base;)181
880 y Fo(exp)g(=)e(exp)i({)f(1;)91 930 y Fq(g)91 1030
y Fj(return\(acc\);)0 1080 y Fa(g)0 1203 y Fu(B)67 b(Rom)n(b)r(erg)20
b(in)n(tegration)0 1294 y Ft(W)m(e)13 b(presen)o(t)j(only)d(the)i(co)q
(de)f(using)g(the)g(user-de\014ned)i(p)q(o)o(w)o(er)f(function)e
(de\014ned)i(ab)q(o)o(v)o(e.)62 1364 y Fj(extern)g(\015oat)g
(f\(\015oat\);)62 1414 y(v)o(oid)g(rom)o(b)q(erg\(\015oat)e(r[10][10],)
j(\015oat,)f(\015oat,)h(in)o(t\);)62 1464 y(in)o(t)e(p)q(o)o(w)o
(er\(in)o(t,)f(in)o(t\);)62 1564 y(v)o(oid)i(rom)o(b)q(erg\(\015oat)e
(r[10][10],)j(\015oat)f(a,)h(\015oat)f(b,)h Fo(int)f(M)7
b Fj(\))62 1613 y Fa(f)153 1663 y Fj(in)o(t)14 b(n,)i(m,)f(i,)h(max;)
153 1713 y(\015oat)f(h,)h(s;)153 1813 y(h)f(=)h(b)g Fq(\000)g
Fj(a;)153 1862 y(r[0][0])g(=)g(\(f\(a\))f(+)h(f\(b\)\))d(*)j(h)g(/)f
(2.0;)153 1962 y Fo(for)f(\(n)h(=)g(1;)g(n)g Fi(<)p Fo(=)g(M;)g(n++\))g
Fq(f)244 2012 y Fj(h)g(=)h(\(h)f(/)h(2.0\);)244 2062
y(s)f(=)h(0.0;)244 2161 y Fo(max)f(=)f(p)n(ower\(2,)h(n)g({)g(1\);)244
2211 y(for)f(\(i)g(=)h(1;)g(i)f Fi(<)p Fo(=)h(max;)g(i++\))334
2261 y Fj(s)h(=)g(s)g(+)g(f\(a)f(+)h(\()p Fo(\(\(2.0)f(*)g(i\))f({)h
(1\))j Fj(*)e(h\)\);)244 2361 y(r[)p Fo(n)s Fj(][0])h(=)f(\(\(r[)p
Fo(n{1)6 b Fj(][0]/2.0\))15 b(+)h(h)f(*)h(s\);)244 2460
y Fo(for)e(\(m)h(=)f(1;)h(m)g Fi(<)p Fo(=)g(n;)g(m++\))334
2510 y Fj(r[)p Fo(n)s Fj(][)p Fo(m)s Fj(])i(=)f(r[)p
Fo(n)s Fj(][)p Fo(m{1)6 b Fj(])18 b(+)e Fo(\(1.0/\(p)n
(ower\(4,m\){1\)\))h Fj(*)f(\(r[)p Fo(n)s Fj(][)p Fo(m{1)6
b Fj(])17 b Fq(\000)f Fj(r[)p Fo(n{1)6 b Fj(][)p Fo(m{1)g
Fj(]\);)153 2560 y Fq(g)62 2610 y Fa(g)954 2795 y Ft(16)p
eop
%%Page: 17 17
17 16 bop 0 42 a Fu(C)67 b(Cubic)23 b(splines)g(in)n(terp)r(olation)0
157 y Fj(#de\014ne)14 b(MAX)i(500)0 257 y(v)o(oid)e(csi\()p
Fo(int)g(n)s Fj(,)j Fo(\015o)n(at)e(x[MAX])t Fj(,)h(\015oat)f(y[MAX],)j
(\015oat)d(z[MAX]\))0 306 y Fa(f)91 356 y Fj(\015oat)g(h[MAX],)h
(b[MAX],)h(u[MAX],)g(v[MAX];)91 456 y(in)o(t)d(i;)91
555 y Fo(for)g(\(i)g(=)h(0;)g(i)g Fi(<)p Fo(=)g(n{1;)g(i)f(=)h(i+1\))g
Fq(f)181 605 y Fo(h[i])g(=)f(x[i+1])h({)g(x[i];)181 655
y Fj(b[)p Fo(i)t Fj(])h(=)g Fo(\(6/h[i]\))h Fj(*)f(\(y[)p
Fo(i+1)6 b Fj(])16 b Fq(\000)g Fj(y[)p Fo(i)t Fj(]\);)91
705 y Fq(g)91 804 y Fo(u[1])e(=)h(2)g(*)g(\(h[0])g(+)g(h[1]\);)91
854 y Fj(v[1])h(=)g(b[1])g Fq(\000)g Fj(b[0];)91 954
y Fo(for)e(\(i)g(=)h(2;)g(i)g Fi(<)p Fo(=)g(n{1;)g(i)f(=)h(i+1\))g
Fq(f)181 1004 y Fo(u[i])g(=)f(2)h(*)g(\(h[i])g(+)f(h[i{1]\))h({)g
(\(h[i{1])g(*)g(h[i{1])f(/)i(u[i{1]\);)181 1054 y Fj(v[)p
Fo(i)t Fj(])h(=)f(b[)p Fo(i)t Fj(])g Fq(\000)g Fj(b[)p
Fo(i{1)6 b Fj(])16 b Fq(\000)g Fj(\()p Fo(h[i{1])k Fj(*)15
b(v[)p Fo(i{1)6 b Fj(])17 b(/)f Fo(u[i{1])t Fj(\);)91
1103 y Fq(g)91 1203 y Fj(z[)p Fo(n)s Fj(])h(=)f(0;)91
1253 y Fo(for)e(\(i)g(=)h(n{1;)h(i)e Fi(>)p Fo(=)h(1;)g(i)f(=)h(i{1\))
181 1303 y Fj(z[)p Fo(i)t Fj(])i(=)f(\(v[)p Fo(i)t Fj(])g
Fq(\000)g Fo(h[i])k Fj(*)c(z[)p Fo(i+1)6 b Fj(]\))15
b(/)h Fo(u[i])t Fj(;)91 1352 y(z[0])g(=)g(0;)0 1402 y
Fa(g)954 2795 y Ft(17)p eop
%%Page: 18 18
18 17 bop 0 42 a Fu(D)67 b(Cheb)n(yshev)23 b(appro)n(ximation)0
157 y Fj(#de\014ne)14 b(MAX)i(50)0 207 y(#de\014ne)e(PI)i
(3.14159265358979323846)0 306 y(v)o(oid)e(c)o(heb\(\015oat)g(c[MAX],)j
(in)o(t,)d(\015oat,)i(\015oat\);)0 356 y(extern)f(\015oat)g
(func\(\015oat\);)0 406 y(extern)g(double)e(cos\(double)g(x\);)0
506 y(v)o(oid)h(c)o(heb\(\015oat)g(c[MAX],)j Fo(int)e(n)s
Fj(,)i(\015oat)e(xa,)h(\015oat)f(xb\))0 555 y Fa(f)91
605 y Fj(in)o(t)f(k,)i(j;)91 655 y(\015oat)f(xm,)h(xp,)g(sm;)91
705 y(\015oat)f(f[MAX];)91 804 y(xp)g(=)h(\(xb)f(+)i(xa\))e(/)h(2;)91
854 y(xm)g(=)g(\(xb)f Fq(\000)h Fj(xa\))g(/)g(2;)91 954
y Fo(for)e(\(k)h(=)g(1;)f(k)h Fi(<)p Fo(=)g(n;)g(k++\))181
1004 y Fj(f[)p Fo(k)t Fj(])i(=)f(func\(xp)e(+)i(xm)g(*)g
Fo(c)n(os\(PI)f(*)g(\(k)g({)g(0.5\))g(/)g(n\))r Fj(\);)91
1103 y Fo(for)f(\(j)g(=)h(0;)g(j)g Fi(<)p Fo(=)g(n{1;)g(j++\))f
Fq(f)181 1153 y Fj(sm)i(=)g(0.0;)181 1203 y Fo(for)f(\(k)f(=)h(1;)g(k)g
Fi(<)p Fo(=)g(n;)g(k++\))272 1253 y Fj(sm)g(=)h(sm)g(+)g(f[)p
Fo(k)t Fj(])h(*)e Fo(c)n(os\(PI)h(*)f(j)f(*)h(\(k)g({)g(0.5\))g(/)g
(n\))r Fj(;)181 1303 y(c[)p Fo(j)6 b Fj(])17 b(=)f Fo(\(2.0)f(/)g(n\))j
Fj(*)d(sm;)91 1352 y Fq(g)91 1402 y Fj(return;)0 1452
y Fa(g)0 1625 y Fu(E)67 b(Dot)22 b(pro)r(duct)0 1740
y Fj(#de\014ne)14 b(MAX)i(500)0 1840 y(in)o(t)e(dotpro)q(duct\()p
Fo(i)o(nt)e(size)s Fj(,)k Fo(int)f(u[MAX])t Fj(,)h(in)o(t)e(v[MAX]\))0
1890 y Fa(f)91 1940 y Fj(in)o(t)g(i;)91 1989 y(in)o(t)g(res;)91
2089 y(res)h(=)h(0;)91 2189 y Fo(for)e(\(i)g(=)h(0;)g(i)g
Fi(<)g Fo(size;)f(i++\))g Fq(f)181 2239 y Fo(if)h(\(u[i]\))272
2288 y Fj(res)g(=)h(res)g(+)g Fo(u[i])j Fj(*)d(v[)p Fo(i)t
Fj(];)105 2338 y Fq(g)91 2388 y Fj(return)d(res;)0 2438
y Fa(g)954 2795 y Ft(18)p eop
%%Page: 19 19
19 18 bop 0 42 a Fu(F)68 b(Dithering)0 157 y Fj(/*)16
b(ppmdith)o(er.c)d(-)j(Ordered)e(ditherin)o(g)f(of)i(a)h(color)f(ppm)g
(\014le)g(to)g(a)h(sp)q(eci\014ed)e(n)o(um)o(b)q(er)0
207 y(**)i(of)f(primary)f(shades.)0 257 y(**)0 306 y(**)i(Cop)o(yrigh)o
(t)d(\(C\))i(1991)h(b)o(y)f(Christos)f(Zoulas.)0 356
y(**)0 406 y(**)i(P)o(ermissi)o(on)d(to)i(use,)h(cop)o(y)l(,)f(mo)q
(dify)l(,)g(and)g(distribu)o(te)e(this)h(soft)o(w)o(are)g(and)h(its)0
456 y(**)h(do)q(cumen)o(tatio)o(n)d(for)i(an)o(y)g(purp)q(ose)f(and)i
(without)d(fee)j(is)f(hereb)o(y)f(gran)o(ted,)g(pro)o(vided)0
506 y(**)i(that)e(the)h(ab)q(o)o(v)o(e)h(cop)o(yrigh)o(t)c(notice)j
(app)q(ear)g(in)g(all)f(copies)h(and)g(that)g(b)q(oth)f(that)0
555 y(**)i(cop)o(yrigh)o(t)d(notice)h(and)h(this)f(p)q(ermission)f
(notice)h(app)q(ear)h(in)g(supp)q(ortin)o(g)0 605 y(**)h(do)q(cumen)o
(tatio)o(n.)i(This)d(soft)o(w)o(are)f(is)h(pro)o(vided)e(\\as)j(is")f
(without)f(express)h(or)0 655 y(**)h(implied)c(w)o(arran)o(t)o(y)l(.)0
705 y(*/)0 804 y(#de\014ne)i(NS)i Fo(256)197 b Fj(/*)16
b(Max)g(n)o(um)o(b)q(er)e(of)h(shades)g(in)g(primary)f(*/)0
854 y(#de\014ne)g(COLOR\(r,g,b\))30 b(\(\(\(r\))14 b(*)i
Fo(dith)p 737 854 13 2 v 15 w(ng)k Fj(+)c(\(g\)\))f(*)g
Fo(dith)p 1071 854 V 16 w(nb)k Fj(+)d(\(b\)\))0 904 y(#de\014ne)e
(LEVELS\()p Fo(s)s Fj(\))95 b Fo(\(dith)p 604 904 V 15
w(dm2)15 b(*)g(\(\(s\))g({)g(1\))g(+)g(1\))0 954 y Fj(#de\014ne)f
(DITHER\(p,d,)p Fo(s)s Fj(\))h(\(\(ub)o(yte\))e(\(\()p
Fo(LEVELS\(s\))k Fj(*)f(\(p\))f(+)h(\(d\)\))e(/)i Fo(\(dith)p
1381 954 V 15 w(dm2)f(*)g(NS\))r Fj(\)\))0 1054 y(/*)h(dith)p
154 1054 15 2 v 15 w(dither\(\))o(:)16 1103 y(*)g(Dither)d(heigh)o(t)g
(scanlines)h(at)h(a)i(time)16 1153 y(*)16 1203 y(*)f(static)e(global)g
(v)m(ariables)g(used)h(in)g(function)e(dith)p 966 1203
V 15 w(dither\(\))o(:)16 1253 y(*)63 b(static)15 b(in)o(t)f
Fo(dith)p 378 1253 13 2 v 15 w(dim)s Fj(;)48 b(/*)16
b(size)f(of)g(dithering)d(matrix)j(*/)16 1303 y(*)63
b(static)15 b(in)o(t)f Fo(dith)p 378 1303 V 15 w(dm2)6
b Fj(;)32 b(/*)16 b(size)f(of)g(dithering)d(matrix)j(squared)g(*/)16
1352 y(*)63 b(static)15 b(in)o(t)f Fo(dith)p 378 1352
V 15 w(nr)t Fj(;)64 b(/*)16 b(shades)f(of)g(red)g(*/)16
1402 y(*)63 b(static)15 b(in)o(t)f Fo(dith)p 378 1402
V 15 w(ng)t Fj(;)64 b(/*)16 b(shades)f(of)g(green)g(*/)16
1452 y(*)63 b(static)15 b(in)o(t)f Fo(dith)p 378 1452
V 15 w(nb)s Fj(;)64 b(/*)16 b(shades)e(of)i(blue)e(*/)16
1502 y(*)16 1552 y(*/)0 1601 y(v)o(oid)0 1651 y(dith)p
90 1651 15 2 v 15 w(dither\(w,)g(h,)h(t,)h(i,)g(o\))0
1701 y(in)o(t)e(w,)j(h;)0 1751 y(register)d(pixel)g(*t;)0
1801 y(register)g(pixel)g(*i;)0 1851 y(register)g(pixel)g(*o;)0
1900 y Fa(f)91 1950 y Fj(in)o(t)g(y)l(,)i Fo(dm)f(=)g(\(dith)p
420 1950 13 2 v 15 w(dim)g({)g(1\))r Fj(;)91 2000 y(register)e(in)o(t)h
(x,)i(d;)91 2050 y(register)d(in)o(t)h(*m;)91 2149 y(for)h(\(y)g(=)h
(0;)g(y)h Fi(<)f Fj(h;)f(y++\))181 2199 y(for)g(\(m)h(=)g(dith)p
473 2199 15 2 v 15 w(mat[y)g(&)g Fo(dm)s Fj(],)g(x)g(=)h(w;)f(--x)g
Fi(>)p Fj(=)g(0;)g(i++\))f Fa(f)272 2249 y Fj(d)g(=)h(m[x)h(&)f
Fo(dm)s Fj(];)272 2299 y(*o++)g(=)g(t[COLOR\(DITHER\(PPM)p
1010 2299 V 16 w(GETR\(*i\),)e(d,)i Fo(dith)p 1392 2299
13 2 v 15 w(nr\))r Fj(,)684 2349 y(DITHER\(PPM)p 1009
2349 15 2 v 17 w(GETG\(*i\),)e(d,)h Fo(dith)p 1393 2349
13 2 v 16 w(ng\))r Fj(,)684 2398 y(DITHER\(PPM)p 1009
2398 15 2 v 17 w(GETB\(*i\),)f(d,)i Fo(dith)p 1390 2398
13 2 v 15 w(nb)s Fj(\)\)];)91 2448 y Fa(g)0 2498 y(g)g
Fj(/*)f(end)g(dith)p 284 2498 15 2 v 15 w(dither)f(*/)954
2795 y Ft(19)p eop
%%Trailer
end
userdict /end-hook known{end-hook}if
%%EOF


----- End Included Message -----


Date: Wed, 8 Jan 1997 18:05:36 -0800
From: chambers@klamath (Craig Chambers)
To: spin-comp@cs
Subject: affiliates

The affiliates meeting is Feb 24 and 25.  We should try to have a poster and
at least one talk on DyC.  Perhaps we can recycle much of last year's poster.
I can easily imagine a talk by Markus on annotations and a talk by maybe Brian
on the current compiler architecture (since Matthai talked last year).  What
do you all think?

-- Craig

To: chambers@klamath (Craig Chambers)
cc: spin-comp@franklin.cs.washington.edu
Subject: Re: affiliates 
Date: Thu, 09 Jan 1997 07:52:09 PST
From: Matthai Philipose <matthai@franklin.cs.washington.edu>

Sounds good to me.
		Matthai

> The affiliates meeting is Feb 24 and 25.  We should try to have a poster and
> at least one talk on DyC.  Perhaps we can recycle much of last year's poster.
> I can easily imagine a talk by Markus on annotations and a talk by maybe Brian
> on the current compiler architecture (since Matthai talked last year).  What
> do you all think?
> 
> -- Craig
> 


Date: Thu, 16 Jan 1997 11:20:39 -0800
From: chambers@klamath (Craig Chambers)
To: cecil@cs, spin-comp@cs
Subject: TIME CRITICAL MATERIAL

OK, guys, let's make up some poster titles and talk titles.  Those of you who
were tentatively signed up for talks, make up a plausible title and send it to
me.  My feeling is that we want some placeholders and rough ideas for affiliates
about what they might hear, but we can change and refine (add/drop) titles
when we really know what we're doing.

So I'm expecting responses from Markus, Brian, and Dave, at least, about 
talks.

How many posters, on what topics, for DyC?  For Cecil/Vortex?

-- Craig


----- Begin Included Message -----

From voting-faculty-request@june  Wed Jan 15 16:21:07 1997
Delivery-Date: Wed, 15 Jan 1997 16:21:19 PST
Date: Wed, 15 Jan 1997 16:20:10 -0800
From: beame@geoduck (Paul Beame)
To: faculty@cs
Subject: TIME CRITICAL MATERIAL

We need you to RESPOND ABOUT your students' TALKS and DEMOS for the
affiliates meeting THIS WEEK.

The affiliates meeting is only 5 weeks away. The web pages are nearly ready to
go. The affiliates are already starting to respond about attending but there
is one problem:  

Very few people have responded so far about either talks or demos so those
web pages don't have much content in them...

PLEASE SEND your information to Gretchen at "gretc@cs" ASAP.

Thanks,

Paul

3rd Affiliates Harasser
CSE




----- End Included Message -----


To: spin-comp@thistle.cs.washington.edu
Subject: affiliates poster/talk titles
Date: Thu, 16 Jan 1997 17:56:18 PST
From: Brian Grant <grant@thistle.cs.washington.edu>

I won't be around tomorrow to meet with everyone, so I'm proposing
some preliminary titles.  Craig said they're not binding, so we can change
them later if we want to.  Feel free to alter any of the titles before
sending them to Beame as well.

Markus's Talk: what is the title of your quals writeup, Markus?
	       The title of our PEPM submission also seems appropriate.

	Annotation-Directed Run-Time Specialization in C

My Talk:
	
	Implementing Fast Run-Time Polyvariant Specialization

One Poster:

	A Specialization-Based Approach to Dynamic Compilation

--Brian


Date: Thu, 16 Jan 1997 18:05:57 -0800
From: chambers@klamath (Craig Chambers)
To: spin-comp@thistle.cs.washington.edu, grant@cs.washington.edu
Subject: Re: affiliates poster/talk titles

Wow, those titles sound intimidating, and the talk titles don't even mention
dynamic compilation.  Remember the audience!  Moderately technical people from 
industry.  How's this for titles:

Talks:

Annotations for Directing Dynamic Compilation

Architecture of a Fast, Effective Dynamic Compiler

Poster:

Fast, Effective Dynamic Compilation


???

-- Craig

Date: Thu, 16 Jan 1997 18:13:15 -0800 (PST)
From: "Markus U. Mock" <mock@cs.washington.edu>
To: Craig Chambers <chambers@klamath.cs.washington.edu>
cc: spin-comp@thistle.cs.washington.edu, grant@cs.washington.edu
Subject: Re: affiliates poster/talk titles

   Talks:
   
   Annotations for Directing Dynamic Compilation
   
   Architecture of a Fast, Effective Dynamic Compiler
   
   Poster:
   
   Fast, Effective Dynamic Compilation
   
   
These titles are probably more appropriate for the affiliates. 
My working title for the quals is "Design and Implementation of
Annotations for Dynamic Compilation" so 
Annotations for Directing Dynamic Compilation
would be fine with me.

	-- Markus


Date: Thu, 16 Jan 1997 18:58:25 -0800
From: Charles Garrett <garrett@cs.washington.edu>
To: spin-comp
Subject: cost of an imb instruction

I figured out roughly what it costs to use the Instruction Memory
Barrier (imb) instruction on the Alpha. Since we will be doing this
for every piece of dynamically compiled code, I think it is worth
knowing.

There are two parts to the cost of an imb. First there is a constant
cost to execute the instruction itself and second there is the
cost of every cache miss you take that would have been a hit without
the imb instruction. I carried out the measurements on one of the 
SPIN Alpha's, but we can repeat them on any machine we want to know
about. I found that the constant cost of the imb instruction was
219 cycles and the cost of the added cache misses was 1.05 cycles per
instruction. This gives us a lower bound on how many cycles it will cost
us to dynamically compile an instruction. For example, if we dynamically
generate N instructions and don't cause any extra cache misses, then it
takes at least 219/N cycles per generated instruction.

Brian, do you know if Pardo measured something similar? 

I will try to measure some of the other elementary operations that we
will use in DyC, such as the cost of emitting an instruction, the cost
of filling in a hole in a template, etc. I will put this data into the
group web site. 

--
Charlie

Date: Fri, 17 Jan 1997 10:58:41 -0800
From: chambers@klamath (Craig Chambers)
To: beame@cs
Subject: Re: affiliates poster/talk titles
Cc: spin-comp@cs

Here are some talk and poster titles and presenters.

Talks:

	Annotations for Directing Dynamic Compilation
		by Markus Mock

	Architecture of a Fast, Effective Dynamic Compiler
		by Brian Grant

Poster:

	Fast, Effective Dynamic Compilation
		by Matthai Philipose, Brian Grant, Markus Mock,
		   Craig Chambers, and Susan Eggers


-- Craig

To: spin-comp@thistle.cs.washington.edu
Subject: PEPM paper accepted!!!!!
Date: Tue, 21 Jan 1997 11:24:42 PST
From: Brian Grant <grant@thistle.cs.washington.edu>


------- Forwarded Message

Received: from compose.irisa.fr (compose.irisa.fr [131.254.50.42]) by june.cs.washington.edu (8.8.3+CSE/7.2ju) with ESMTP id DAA01927 for <grant@cs.washington.edu>; Tue, 21 Jan 1997 03:37:19 -0800
Received: from drogo.irisa.fr (drogo.irisa.fr [131.254.50.37]) by compose.irisa.fr (8.7.6/8.7.3) with ESMTP id MAA03050 for <grant@cs.washington.edu>; Tue, 21 Jan 1997 12:36:16 +0100 (MET)
Date: Tue, 21 Jan 1997 12:36:15 +0100
Message-Id: <199701211136.MAA11882@drogo.irisa.fr>
From: Charles Consel <Charles.Consel@irisa.fr>
To: grant@cs.washington.edu
Subject: PEPM'97
X-UIDL: 802697050e1c2d1639a34bd7a1e2e42b



Dear Colleague,

I am pleased to inform you that your paper entitled

"Annotation-Directed Run-Time Specialization in C"

has been accepted by the program committee for presentation at the 
ACM SIGPLAN Symposium on Partial Evaluation to be held in Amsterdam, 
The Netherlands, on June 12-13, 1997.

  ****************************************************************
  * Deadline for the full, final version is  Thursday, April 3rd *
  ****************************************************************

I will send you a format specifications together with a style file 
electronically. As usual, publication by ACM is dependent upon signing
a copyright form, which will also be sent to you.

The time for your presentation at PEPM'97 is limited to 25 minutes
with 5 minutes for questions. Please feel free to contact me by
e-mail (consel@irisa.fr) with any questions you may have.

The reviews on your paper are enclosed below.

Congratulations, and thank you for sending a submission to PEPM'97!



Sincerely,

Charles Consel
PEPM'97 Program Chair

PAPER-NUMBER: 28

TITLE: Annotation-Directed Run-Time Specialization in C

AUTHORS: Grant, Mock, Philipose, Chambers and Eggers


OVERALL-RATING(0-9): 7

RELEVANCE(0-4):4  ORIGINALITY(0-4):2   CLARITY(0-4):2  SOUNDNESS(0-4):2

Comments for the authors
- -------------------------
The paper is extremely relevant to the PE community.  The ideas are
interesting and useful.  I would be much more interested in a
qualitative comparison to `C and to standard annotations and much
less about implementation details.  (None of the implementation
stuff seemed novel.)

The comparison to `C is just plain wrong in some places.  The claim
that `C is no more powerful than these annotations is incorrect.  The
annotations fix the function signatures that can be produced at runtime.
`C can build arbitrary functions.  This makes a difference when implementing
a compile-on-the-fly interpreter (aka JIT compiler).

There is nothing deep in the paper, but the idea has promise, and it
is practical.  To me, these annotations (like `C primitives) are candidates
for the target language of a partial evaluator.

As the authors noted, the paper needs serious reworking.  It is too
long and very unclear.  More motivation is need and much less detail.

PAPER-NUMBER: 28

TITLE: Annotation-Directed Run-Time Specialization in C

AUTHORS: Brian Grant, Markus Mock, Matthai Philipose, Craig Chambers, Susan Eggers


OVERALL-RATING(0-9): 6

RELEVANCE(0-4): 4  ORIGINALITY(0-4): 4  CLARITY(0-4): 4 SOUNDNESS(0-4): 3

Comments for the authors
- -------------------------

The length of your paper and your warning scared me a little bit. However,
your paper contains mainly a description of your annotations, motivation
for these annotations, and explanations to show that they can be interpreted
and/or compiled correctly, rather than theoretical material. 

The final paper and the presentation should probably target either
the annotations and the motivation, or the annotations and the implementation.

Although your project is on-going, there could be some information about
the speed-up expected from the annotations, as you can program their
effect by hand (for instance, on a small interpreter).

PAPER-NUMBER: 28

TITLE: "Annotation-Directed Run-Time Specialization in C"

AUTHORS:
  Brian Grant, Markus Mock, Matthai Philipose, Craig Chambers and Susan Eggers


OVERALL-RATING(0-9): 4

RELEVANCE(0-4): 4  ORIGINALITY(0-4): 2  CLARITY(0-4): 1  SOUNDNESS(0-4): 2

Comments for the authors
- -------------------------

Overall, I like the idea of run-time specialization, and the fact that the
design is directed with specific, realistic examples in mind (e.g. operating
system code).

The most interesting idea presented is that of "polyvariant
re-specialization", enabling already specialized code to re-specialize if
needed.

A number of different policies were presented for cache management, unrolling
loops, etc.  It is clearly probable that the policy chosen for a given
situation will indeed effect how successful its specialization is.  However,
most policies proposed are standard or obvious choices (FIFO, LRU, unroll
limit, etc.).  Also, without experimental results validating the hypotheses,
it is not possible to assess the success of the proposed policies.

Weaknesses of the paper include the fact that there is no support for
interprocedural analyses, there is no side-effect analysis nor alias
analysis, and that the implementation is not complete.




------- End of Forwarded Message



Date: Tue, 21 Jan 1997 11:45:01 -0800
From: Charles Garrett <garrett@cs.washington.edu>
To: Brian Grant <grant@thistle.cs.washington.edu>
Subject: Re: PEPM paper accepted!!!!!

Congratulations.

--
Charlie

Date: Tue, 21 Jan 1997 12:35:18 -0800
From: eggers@yakima (Susan Eggers)
To: grant@thistle.cs.washington.edu, spin-comp@thistle.cs.washington.edu
Subject: Re:  PEPM paper accepted!!!!!

Wonderful!  Congratulations.
I didn't notice a date by which the final version had to be in.  Did
Charles send that separately, or did I just miss it, reading at 2 baud?

Susan

Date: Tue, 21 Jan 1997 12:39:24 -0800 (PST)
From: Markus Mock <mock@apex.cs.washington.edu>
To: Susan Eggers <eggers@yakima>
cc: grant@thistle.cs.washington.edu, spin-comp@thistle.cs.washington.edu
Subject: Re:  PEPM paper accepted!!!!!

 Deadline for the full, final version is  Thursday, April 3rd *




	-- Markus 


To: spin-comp@cs
Subject: PEPM '97 Author Kit
Date: Wed, 29 Jan 1997 08:26:48 PST
From: Brian Grant <grant@thistle.cs.washington.edu>


------- Forwarded Message

Received: from compose.irisa.fr (compose.irisa.fr [131.254.50.42]) by june.cs.washington.edu (8.8.5+CS/7.2ju) with ESMTP id AAA28560 for <grant@cs.washington.edu>; Wed, 29 Jan 1997 00:31:29 -0800
Received: from drogo.irisa.fr (drogo.irisa.fr [131.254.50.37]) by compose.irisa.fr (8.7.6/8.7.3) with ESMTP id JAA09205; Wed, 29 Jan 1997 09:26:58 +0100 (MET)
Date: Wed, 29 Jan 1997 09:26:57 +0100
Message-Id: <199701290826.JAA29320@drogo.irisa.fr>
From: Charles Consel <Charles.Consel@irisa.fr>
To: augustss@cs.chalmers.se, alpuente@dsic.upv.es, asai@is.s.u-tokyo.ac.jp,
        beshers@cs.columbia.edu, danvy@brics.dk, debray@cs.arizona.edu,
        fn@daimi.aau.dk, heldal@cs.chalmers.se, hornof@irisa.fr,
        grant@cs.washington.edu, marinesc@cs.nyu.edu,
        Matthieu.Martel@ens-lyon.fr, melski@cs.wisc.edu, muller@irisa.fr,
        sandro@disi.unige.it, sheard@cse.ogi.edu, walidt@cse.ogi.edu
Cc: consel@irisa.fr
Subject: PEPM'97: Author Kit
X-UIDL: 0e11fa90b47c3cf53ae8be6b3cc9d57d


Please read carefully the following information sent by ACM regarding
paper format and copyright matters. Do not hesitate to contact me if
you have any questions.

Charles Consel

- ----------------------------------------------------------------------------
Charles Consel              | University of Rennes / Irisa 
 consel@irisa.fr            | Campus Universitaire de Beaulieu
 Phone: (33) 02 99 84 74 10 | 35042 Rennes Cedex
 Fax:   (33) 02 99 84 71 71 | France
- ----------------------------------------------------------------------------
  URL: http://www.irisa.fr/EXTERNE/projet/lande/consel/consel.html & index.html
- ----------------------------------------------------------------------------


January 27, 1997


Dear Author:

Enclosed please find the guidelines and pertinent information for submission 
of your paper(s) for the PEPM '97: ACM Workshop on Partial Evaluation and 
Semantics Based Program Manipulation.

Please note:  It is of particular importance that you leave sufficient space 
in the lower left corner of the first column on the first page for ACM to 
fill in the copyright information.  There is  a 14 page maximum on 
your paper.  It is possible to use one or two extra pages with the consent 
of the Program Chairs.

Please submit camera-ready copy (produced on a high-resolution output 
device)  of your manuscript on
8 1/2" x 11" paper following the format below:

2 column:

Font:                                               English Times or Times 
Roman
Point Size:                                      9 pt.
Spacing between lines:           10 pt.
Column width:                                3.33"
2 column gutter:                                .33"
Left and Right Margin:                   from edge .75"
Top margin:                                    .75"
Bottom margin                               1.00"
Copyright space on 1st page:         lower  left column 1"

The enclosed ACM copyright form must be signed and returned with your paper. 
 I caution you that ACM will not publish any paper that is not accompanied 
by a signed copyright form.  In those cases where there is more than one 
author per paper, the first-named (assumed senior) author only must sign.

The full ACM Copyright policy, revised as of November 15, 1995, is available 
via http://www.acm.org/pubs/copyright_policy.html

Please federal express or mail your paper and signed copyright form so that 
it is received by Charles Consel by Thursday, April 3, 1997 .  The paper and 
copyright form should be sent to:

                                            Charles Consel
                 University of Rennes/Irisa
                                            35042 Rennes Cedex
                                            France
                Telephone # (33) 02 99 84 74 10
                                            Fax # (33) 02 99 84 71 71
                 E-mail address:  consel@irisa.fr


Please let me know if I can be of further assistance.

Sincerely,



Maria Maritato
ACM Program Coordinator




ACM COPYRIGHT FORM


Title of Work:
Author(s):
Publication or Conference Name and Date:


A. TRANSFER OF COPYRIGHT AGREEMENT
Copyright to the above work (including without limitation, the right to 
publish the work in whole or in part in any and all forms of media, now or 
hereafter known) is hereby transferred to the ACM (for U.S. Government work, 
to the extent transferrable*) effective as of the date of this agreement on 
the understanding that the work has been accepted for publication by ACM.
However, each of the Authors retain the following rights:
1 All other proprietary rights except copyright (and the publication rights 
transferred to ACM), such as patent rights.
2 The right to reuse, without fee, in future works of the Author's own 
provided that the ACM citation and Copyright notice are included.
3 The right to post a personal copy on non-ACM servers for limited 
noncommercial distributions, provided that the ACM Copyright notice is 
attached to the personal copy and that the server prominently displays a 
general policy notice (see sample of Server Notice in Revised ACM Interim 
Copyright Policy, version 2, section 5.3) about the use of copyright works 
it contains.
4 Employers who originally own copyright may distribute copies of works of 
their employees within the employer's organization.
This Form must be signed by the Author or, in the case of a "work made for 
hire," by the employer and must be received by ACM, Inc. --See Box C-- 
before processing of the manuscript for publication can be completed. 
Authors should understand that consistent with ACM's policy of encouraging 
dissemination of information each published paper will appear with the 
following notice:
"Permission to make digital or hard copies of part or all of this work for 
personal or classroom use is granted without fee provided that copies are 
not made or distributed for profit or commercial advantage and that copies 
bear this notice and the full citation on the first page. Copyrights for 
components of this work owned by others than ACM must be honored. 
Abstracting with credit is permitted. To copy otherwise, to republish, to 
post on servers or to redistribute to lists, requires prior specific 
permission and/or a fee."
Signature_______________________ Print Name_______________________
Title, if not Author_____________________ Date________________________


B. *DECLARATION FOR U.S. GOV'T WORK
This certifies that the above author(s) wrote the paper (a) as part of work 
as U.S. government employees or, (b) as other noncopyrightable work.
Signature________________________________
Agency__________________________________
Title, if not Author__________________________
Date Signed______________________________
C. WHERE TO RETURN THIS FORM
For Proceedings papers, please return or fax this form to the Conference 
Program Chair. For other authors, please return or fax to:
ACM Copyright & Permissions
1515 Broadway, 17th Floor
New York, NY 10036
Fax: 212 869-0481
ACM revised 3/96


TO: Authors Submitting Papers for Publication by ACM
FROM: ACM Director of Publications
SUBJECT: ACM Copyright Procedures
Thank you for submitting a paper for publication by ACM, Inc. ACM's 
publications are read throughout the world, and we must deal with requests 
for reprinting, republishing, redistributing, digitizing, posting to 
servers, translating, anthologizing, and other actions.
It is the policy of ACM to own the copyrights on its technical publications 
to protect the interests of ACM, its Authors and their employers, and at the 
same time to facilitate the appropriate reuse of this material by others.
United States Copyright Law requires that the transfer of copyright of each 
contribution from the Author to ACM be confirmed in writing. It is necessary 
that Authors sign either Part A or Part B of the ACM Copyright Form and 
return it with the manuscript to the address on the Form (see Revised ACM 
Interim Copyright Policy, sections 2.1, 4.1, 4.2).
If you are employed and you prepared your paper as part of your job, the 
rights to your paper may initially rest with your employer. In that case, 
when you sign the ACM Copyright Transfer Form, we assume you are authorized 
to do so by your employer. If not, it should be signed by someone so 
authorized.
For jointly authored papers, an original signature is required from one 
(assumed senior) Author only. However, we assume all Authors have been 
advised and have consented to the terms of this Form.
Authors who are U.S. government employees and/or whose papers are not 
copyrightable as part of certain Government contract work, are not required 
to sign Part A, but all co-authors outside the Government contract are.
Part B of the Form is to be used instead of Part A only if any or all 
Authors are U.S. Government employees and they prepared the paper as part of 
their job, or the work is an uncopyrightable product of a Government 
contract.
ACM Authors have all the rights scientific authors have historically 
enjoyed, including the right to present orally the submitted or similar 
material in any form; the right to reuse in future works of the Author's own 
with notice and credit to ACM; the right to republish in any form of media 
with notice and credit to ACM, in works published by the employer or for the 
employer's internal business purposes; the right to reproduce and distribute 
for peer review in reasonable quantities (see Revised ACM Interim Copyright 
Policy, sections 3, 5.3); and all proprietary rights other than copyright.
Although it is not part of ACM's policy to grant Authors or their 
organizations the sole right to approve permissions for republishing by 
third parties, ACM always seeks the approval of its Authors, for jointly 
authored papers the first-named (assumed senior) Author only, in weighing 
such requests. This is done as a matter of professional courtesy.


------- End of Forwarded Message



Date: Thu, 30 Jan 1997 10:24:51 -0800
From: chambers@klamath (Craig Chambers)
To: spin-comp@cs
Subject: meeting delay

can we delay our meeting till 11?  thanks.

Date: Fri, 31 Jan 1997 09:01:28 -0800
From: eggers@yakima (Susan Eggers)
To: grant@cs.washington.edu, spin-comp@thistle.cs.washington.edu
Subject: Re:  PEPM `97 Paper

Why don't we talk about the paper when I visit in February?
A discussion in person would probably be more fruitful and
less time-consuming than via email.  For example, I would not
have really understood my comments in Brian's mail if I had
not already known them.

Susan

Date: Fri, 31 Jan 1997 11:16:58 -0800
From: chambers@klamath (Craig Chambers)
To: grant@cs.washington.edu, spin-comp@thistle.cs.washington.edu,
Subject: Re:  PEPM `97 Paper

That sounds good.

-- Craig


> From eggers@yakima  Fri Jan 31 09:01:33 1997
> Delivery-Date: Fri, 31 Jan 1997 09:01:40 PST
> Date: Fri, 31 Jan 1997 09:01:28 -0800
> From: eggers@yakima (Susan Eggers)
> To: grant@cs.washington.edu, spin-comp@thistle.cs.washington.edu
> Subject: Re:  PEPM `97 Paper
> 
> Why don't we talk about the paper when I visit in February?
> A discussion in person would probably be more fruitful and
> less time-consuming than via email.  For example, I would not
> have really understood my comments in Brian's mail if I had
> not already known them.
> 
> Susan
> 

Date: Fri, 31 Jan 1997 12:17:27 -0800 (PST)
From: Markus Mock <mock@apex.cs.washington.edu>
To: c112@apex.cs.washington.edu, Eric Anderson <eric@cs.washington.edu>,
cc: "Markus U. Mock" <mock@cs>
Subject: Quals Practice Talk: Today at 5pm

I'll give a practice talk today at 5pm in SIEG 226.

Title of the talk:

Design and Implementation of Annotations for Dynamic Compilation

Bring your TGIF beer and expect a bribe.


	-- Markus 



Date: Fri, 31 Jan 1997 17:04:19 -0800 (PST)
From: Markus Mock <mock@apex.cs.washington.edu>
To: quals <c112@apex.cs.washington.edu>,
Subject: practice talk in SIEG 226 NOW





	-- Markus 

====================================================================
fortune cookie says:
Living on Earth may be expensive, but it includes an annual free trip
around the Sun.


To: spin-comp@thistle.cs.washington.edu
Subject: building fixes
Date: Mon, 03 Feb 1997 10:37:03 PST
From: Brian Grant <grant@thistle.cs.washington.edu>

I installed our own version of gcc in /afs/cs/project/dyncomp/bin and changed
BCC to use that version.  I successfully linked after compiling files on
both SPIN and GWS alphas.

I also changed the temp location used for linking ccom from /tmp to /var/tmp.
Update your version of the top-level pmakefile to pick up that change.  It
will allow you to link on franklin, meitner, and noether.

--Brian


Date: Tue, 4 Feb 1997 11:18:00 -0800
From: chambers@klamath (Craig Chambers)
To: spin-comp@cs, cecil@cs, notkin@cs
Subject: Re: visit?

FYI, Charles Consel will be visiting Feb 26 (the Wednesday after affiliates).
I'll be setting things up soon.

-- Craig


----- Begin Included Message -----

From Charles.Consel@compose.irisa.fr  Tue Feb  4 03:40:55 1997
Delivery-Date: Tue, 04 Feb 1997 03:41:07 PST
Date: Tue, 4 Feb 1997 12:40:28 +0100
From: Charles Consel <Charles.Consel@irisa.fr>
To: chambers@cs.washington.edu
CC: eggers@cs.washington.edu
Subject: Re: visit?


Hi

So I'll take on your offer for the wednesday 26. Please try to
schedule the talk not before 11:00am. I'll send you an abstract and
title very soon.

I'm really delighted to come!

Charles



----- End Included Message -----


To: spin-comp@cs
Subject: major CVS commit
Date: Wed, 05 Feb 1997 12:37:49 PST
From: Brian Grant <grant@thistle.cs.washington.edu>

I just committed my version of the compiler so that Matthai and Markus could
get at some code they need.   A list of the files committed follows.  I think
everything is there, but I could have missed a few.

Some comments:

-- If your code has no dynamic regions, it works the same as the standard
   version, with a few extra nice command-line options.

-- Compiler option -mDGOPT_show_graph_use_dot=true
   will cause the CFG to be output in dot format to stderr when triggered by
   another flag, eg. -mP2DYC_show_graph_post_bta=true
   In bash, ksh, or sh, you can capture this output with "2> blah.dot".
   Then, run dot (in /projects/cecil/cecil/dot/bin) -Tps blah.dot > blah.ps.

-- There is a similar, but less-polished version of this for vnode graphs.

-- I moved the location of our call to DYC_PrepForDynComp in
   p2_comp_script.csi.  Markus: I don't think it affects the BTA, but I just
   wanted you to be aware of it.

-- The BTA is currently commented out.  If you want to run it, uncomment it.

-- dyc_ExtractBoilerplate() still doesn't work correctly.  You'll
   want to comment out the call to it in DYC_PrepForDynComp.

-- I think dyc_DiscardAnnotations works, but it hasn't been extensively
   tested.  You may want to comment it out (also in DYC_PrepForDynComp).

-- None of my unit stuff is called in the version I checked in (I inserted
   an early return).

-- This version includes the new RTCONST value_type, but it doesn't affect
   anything since no RTCONSTs are created.

If you have any problems getting it to compile, let me know.

--Brian

./mod_list
./p2dyc/pmakefile
./p2dyc/p2dyc.C
./p2dyc/dyc_assert.H
./p2dyc/dyc_graph.C
./p2dyc/dyc_graph.H
./p2dyc/dyc_list.C
./p2dyc/dyc_list.H
./p2dyc/dyc_stack.C
./p2dyc/dyc_stack.H
./p2topo/p2topo.H
./p2topo/p2topo.C
./p2topo/pmakefile
./globals/globals.H
./globals/globals.C
./p2graph/stat_bblock_1.H
./p2graph/bblock_3.H
./p2graph/bblock_3.C
./p2types/p2types.H
./p2mem/p2mem.H
./p2mem/p2mem.C
./p2dep/p2dep.H
./p2dep/p2dep.C
./p2dfo/p2dfo.C
./phase1/main.C
./dgopts/dgopts.H
./dgopts/dgopts.C
./dump_graph/dump_graph.C
./oper/oper.H
./oper/oper.C
./oper/oper.dot.C
./oper/oper.dot.H
./symtab/val_pack.H
./symtab/value.C
./cg/pmakefile
./cg/bank_disamb.C
./cg/bug_defs_uses.C
./cg/dag.C
./cg/mem_loc.C
./cg/mm_constrain.C
./cg/mop_alpha.C
./cg/spill.C
./cg/sch_node_split.C
./cg/schedule.C
./cg/schedule_vn.C
./cg/splice_copies.C
./disamb/deriv.C
./il2/arith.C
./il2/expand.C
./il2/mem.C
./p2aag/p2aag.C
./p2copy_prop/p2copy_prop.C
./p2cse/cse_build.C
./p2cse/cse_cprop.C
./p2cse/cse_fold.C
./p2cse/cse_name.C
./p2cse/cse_util.C
./p2ivs/ivs_de.C
./p2lur/reduce.C
./p2lur/tc.C
./p2lur/unroll.C
./p2red/p2red.C
./p2rmd/p2rmd.C
./p2rvd/p2rvd.C
./p4_sj/p4_sj_cross_jump.C
./p4_sj/p4_sj_instr.C
./p4_sj/p4_sj_mop.C
./phase12/ph12.C
./phase2/phase2.C
./phase2/p2_comp_script.csi
./symtab/pack.C
./vom/make_as_types.C
./vom/vom_fcg_code.C
./fcg/general_support.C
./fcg/level1_3.C
./fcg/temp_movement.C


Date: Tue, 11 Feb 1997 11:44:54 -0800
From: chambers@klamath (Craig Chambers)
To: spin-comp@cs
Subject: Consel

FYI, Consel's talk abstract and demo.

-- Craig


----- Begin Included Message -----

From Charles.Consel@compose.irisa.fr  Tue Feb 11 07:18:20 1997
Delivery-Date: Tue, 11 Feb 1997 07:18:23 PST
Date: Tue, 11 Feb 1997 16:18:01 +0100
From: Charles Consel <Charles.Consel@irisa.fr>
To: chambers@cs.washington.edu
Subject: Re: visit?


Hi Craig,

The title and abstract of my talk are included below. I confirm the
date: Feb 26. I would very much like to talk to Hank and Brian. I
will have a demo of real specialized systems code running when I come;
this code was produced by Tempo. I have a few other people I'll
certainly bug if there are around.

Charles

----------------------------------------------------------------


Title: Declarative Support for Program Specialization in Object-Oriented Languages

In a broad range of areas, designing and implementing generic software
components is commonly advocated. This strategy has many advantages
among which the most important one is reusability.

Many software engineering approaches and programming languages have
successfully addressed this concern. Results of these efforts include
the object-oriented paradigm, modules and software layers. However,
these approaches come at a price: genericity often incurs a loss
of efficiency.

In this talk, we present an approach aimed at reconciling genericity
and efficiency. To do so, we introduce some language support to allow
the programmer to declare how generic programs should be specialized
with respect to a particular usage pattern. These declarations
uniformely address the main aspects of program specialization such as
when to specialize programs, what program components to specialize,
and how to manage specialized program components.

Furthermore, we show that this declarative approach can be fully
integrated in object-oriented languages. Indeed, fundamental
object-oriented concepts provide powerful support to tackle the major
aspects of program specialization.



----- End Included Message -----


Date: Fri, 21 Feb 1997 18:37:31 -0800 (PST)
From: Markus Mock <mock@apex.cs.washington.edu>
To: spin-comp@apex.cs.washington.edu
Subject: Quals Paper and Talk online

I've put the paper and the talk slides in our (internal) group web, in 
the papers/talks section, respectively.




	-- Markus 

====================================================================

Research is what I'm doing when I don't know what I'm doing.
                -- Wernher von Braun


Date: Mon, 24 Feb 1997 17:49:42 -0800 (PST)
From: Markus Mock <mock@apex.cs.washington.edu>
To: spin-comp@apex.cs.washington.edu
Subject: Affiliates talk slides

I've put our talk slides on the internal web page.
Enjoy!


	-- Markus 

====================================================================

Research is what I'm doing when I don't know what I'm doing.
                -- Wernher von Braun


Date: Tue, 25 Feb 1997 10:28:01 -0800
From: chambers@klamath (Craig Chambers)
To: spin-comp@cs
Subject: lunch w/ Consel?

I can't take Consel to lunch tomorrow, since I teach.  Can you all?

-- Craig

Date: Tue, 25 Feb 1997 10:37:17 -0800 (PST)
From: Markus Mock <mock@apex.cs.washington.edu>
To: Craig Chambers <chambers@klamath>
cc: spin-comp@cs
Subject: Re: lunch w/ Consel?

I can.



	-- Markus 

====================================================================

Research is what I'm doing when I don't know what I'm doing.
                -- Wernher von Braun

On Tue, 25 Feb 1997, Craig Chambers wrote:

> I can't take Consel to lunch tomorrow, since I teach.  Can you all?
> 
> -- Craig
> 

Date: Tue, 25 Feb 1997 10:39:24 -0800
From: chambers@klamath (Craig Chambers)
To: mock@apex.cs.washington.edu
Subject: Re: lunch w/ Consel?
Cc: spin-comp@cs

OK, Markus, you're in charge of organizing the lunch gang.  Just come by my 
office at noon to pick him up.  The dept. will reimburse "reasonable" lunch 
expenses.

-- Craig

To: chambers@klamath (Craig Chambers)
cc: spin-comp@thistle.cs.washington.edu
Subject: Re: lunch w/ Consel? 
Date: Tue, 25 Feb 1997 11:11:34 PST
From: Brian Grant <grant@thistle.cs.washington.edu>

>> The dept. will reimburse "reasonable" lunch expenses.

For everybody, or just for Consel?

--Brian


Date: Tue, 25 Feb 1997 12:07:53 -0800
From: chambers@klamath (Craig Chambers)
To: grant@thistle.cs.washington.edu
Subject: Re: lunch w/ Consel?
Cc: spin-comp@thistle.cs.washington.edu

For everyone.  (Except faculty.)

-- Craig

To: spin-comp@cs
Subject: Thursday meeting
Date: Wed, 26 Feb 1997 20:04:47 PST
From: Brian Grant <grant@thistle.cs.washington.edu>

In case I forgot to mention it during all of the recent craziness (and
I think I did), Matthai and I will not be at this week's meeting because
we'll be moving my furniture.

--Brian

Date: Thu, 27 Feb 1997 10:36:13 -0800
From: chambers@klamath (Craig Chambers)
To: spin-comp@cs, grant@cs.washington.edu
Subject: Re: Thursday meeting

Argh!  I was expecting us to meet, and Susan was going to call.  We need to 
try to reschedule ASAP when we all (including Susan) can meet.

-- Craig

To: spin-comp@thistle.cs.washington.edu
Subject: meeting
Date: Mon, 03 Mar 1997 10:45:50 PST
From: Brian Grant <grant@thistle.cs.washington.edu>

>> Argh!  I was expecting us to meet, and Susan was going to call.  We need to 
>> try to reschedule ASAP when we all (including Susan) can meet.

Sorry about the short notice.  I intended to say something about it during
last week's meeting, but I was side-tracked.  I think I just got out "I'll
be moving..."

Anyway, I plan to be in every day this week, and except for colloquia 
today and Thursday, pretty nearly any time is fine for a meeting.

--Brian


Date: Mon, 3 Mar 1997 11:53:07 -0800
From: chambers@klamath (Craig Chambers)
To: spin-comp@thistle.cs.washington.edu
Subject: Re: meeting

Can we meet, at least a little bit (e.g. 20 mins), after the colloq today?
I just want to discuss some of Susan's thoughts a bit, have you all think 
about them, and then discuss your thoughts and our plans on Thursday.

-- Craig

Date: Mon, 3 Mar 1997 12:02:50 -0800 (PST)
From: Markus Mock <mock@apex.cs.washington.edu>
To: Craig Chambers <chambers@klamath>
cc: spin-comp@thistle.cs.washington.edu
Subject: Re: meeting

After the colloq works for me.



	-- Markus 

====================================================================

Research is what I'm doing when I don't know what I'm doing.
                -- Wernher von Braun

On Mon, 3 Mar 1997, Craig Chambers wrote:

> Can we meet, at least a little bit (e.g. 20 mins), after the colloq today?
> I just want to discuss some of Susan's thoughts a bit, have you all think 
> about them, and then discuss your thoughts and our plans on Thursday.
> 
> -- Craig
> 

To: chambers@klamath (Craig Chambers)
cc: spin-comp@thistle.cs.washington.edu
Subject: Re: meeting 
Date: Mon, 03 Mar 1997 12:05:58 PST
From: Brian Grant <grant@thistle.cs.washington.edu>

>> Can we meet, at least a little bit (e.g. 20 mins), after the colloq today?
>> I just want to discuss some of Susan's thoughts a bit, have you all think 
>> about them, and then discuss your thoughts and our plans on Thursday.

Works for me.

--Brian


To: spin-comp@franklin.cs.washington.edu
Subject: Trouble(?) in the java interpreter
Date: Tue, 04 Mar 1997 17:39:46 PST
From: Matthai Philipose <matthai@franklin.cs.washington.edu>

I was poking around the Java interpreter, when I found
what seems to be a problem that prevents unrolling
of the interpreter loop. 

When we dynamically compile a bytecode program, we 
assume that the bytecode array is unmodified during
the interpretation process. Otherwise, we could not
say that opcode (= bytecode[pc]) is static by transitivity.

Unfortunately, the Java VM writes into the bytecode
array for select opcodes (e.g. method invocation).

Check out this piece of code:
-----
case opc_invokevirtual:    //method invocation opcode in the Java VM
case opc_invokenonvirtual:
case opc_invokestatic:
		...	
	//pc points into the bytecode array as usual
	//specificially, opcode = *pc in the interpreter
  	pc[0] = fieldclass(&mb->fb) == classJavaLangObject 
				  	? opc_invokevirtualobject_quick
				      	: opc_invokevirtual_quick;
	pc[1] = mb->fb.u.offset; 
	pc[2] = mb->args_size; 
		...
-------	

This seems to mean that barring a makeStatic on every use of bytecode[pc],
we cannot unroll the interpreter loop. 

Of course, it's possible that I'm totally wrong and don't see something
obvious... I'd be delighted to be corrected! ;-)

			Matthai

To: Matthai Philipose <matthai@cs.washington.edu>
cc: spin-comp@thistle.cs.washington.edu
Subject: Re: Trouble(?) in the java interpreter 
Date: Wed, 05 Mar 1997 08:08:31 PST
From: Brian Grant <grant@thistle.cs.washington.edu>

>> Of course, it's possible that I'm totally wrong and don't see something
>> obvious... I'd be delighted to be corrected! ;-)

One possible solution is to put bytecode[pc] into the context.

--Brian


Date: Wed, 5 Mar 1997 10:45:12 -0800
From: chambers@klamath (Craig Chambers)
To: matthai@cs.washington.edu, grant@thistle.cs.washington.edu
Subject: Re: Trouble(?) in the java interpreter
Cc: spin-comp@thistle.cs.washington.edu

I know that Java overwrites some bytecode instructions w/ quick partially-
processed ones, e.g. to hard-wire the offset of some instance variable load or
the address of some called procedure.  But the reason they do this is as a 
partial weak form of dynamic compilation.  I think we could simply remove the
"optimizations," and apply DC to get much better results.

-- Craig

To: chambers@klamath (Craig Chambers)
cc: spin-comp@franklin.cs.washington.edu
Subject: Re: Trouble(?) in the java interpreter 
Date: Wed, 05 Mar 1997 11:01:19 PST
From: Matthai Philipose <matthai@franklin.cs.washington.edu>

> I know that Java overwrites some bytecode instructions w/ quick partially-
> processed ones, e.g. to hard-wire the offset of some instance variable load or
> the address of some called procedure.  But the reason they do this is as a 
> partial weak form of dynamic compilation.  I think we could simply remove the
> "optimizations," and apply DC to get much better results.
> 
> -- Craig
> 

Yup. I checked the points at which the bytecode
array is modified, and _all_ the bytecode array modifications seem
to be stuff that replaces an instruction with a more optimal
one, the first time the instruction is executed.

Having confirmed that, it seems that with a little munging,
we can undo their "optimizations" and keep the bytecode
array truly static.

Making these optimizations happen "naturally" in our framework 
brings up the point that some procedure-level annotations need 
to work.Consider the following opcode:
----------
case opc_ldc:
	        ResolveClassConstant(constant_pool, pc[1], ee, 
				     (1 << CONSTANT_Integer) | 
				     (1 << CONSTANT_Float) |
				     (1 << CONSTANT_String));
	        if (!exceptionOccurred(ee))
		    pc[0] = opc_ldc_quick;
		goto check_for_exception;
------------	
Basically, the ldc opcode is being replaced by a "quick" version,
ldc_quick, which can skip the "ResolveClassConstant(..." step.
What we want to do in this case (as pointed out by Brian) is to
memoize ResoveClassConstant(...) so it is executed in setup code.

So far, I haven't discovered any other "fundamental" problems
with the Java interpreter.
		Matthai




Date: Wed, 5 Mar 1997 11:29:15 -0800
From: eggers@yakima (Susan Eggers)
To: chambers@klamath, grant@thistle.cs.washington.edu,
Subject: Re: Trouble(?) in the java interpreter
Cc: spin-comp@thistle.cs.washington.edu

My understanding is the what Craig said -- that this is a shortcut
for method lookups for all lookups after the first.

Susan

To: spin-comp@thistle.cs.washington.edu
Subject: new version of DyC checked in
Date: Wed, 05 Mar 1997 15:42:50 PST
From: Brian Grant <grant@thistle.cs.washington.edu>

I checked in a new version of my code that successfully extracts the
boilerplate inserted by dyc2c.  There are some other fixes to my
code, too.  I also broke up p2dyc into several files, made the dump_graph
output a little nicer (allowing multi-page graphs), and un-commented-out
the BTA (so the BTA runs).

Files affected:
dgopts/dgopts.C
dgopts/dgopts.H
dump_graph/dump_graph.C
p2bta/bta.C
p2dep/p2dep.C
p2dyc/boilerplate.C
p2dyc/boilerplate.H
p2dyc/dyc_assert.C
p2dyc/dyc_graph.H
p2dyc/dyc_list.H
p2dyc/dyc_stack.H
p2dyc/p2dyc.C
p2dyc/p2dyc.H
p2dyc/pmakefile
p2dyc/setup.C
p2dyc/setup.H
p2dyc/template.C
p2dyc/template.H
p2dyc/unit.C
p2dyc/unit.H
p2graph/bblock_3.C
p2topo/p2topo.C
p2topo/p2topo.H
p3p4oc/syntax1.C
phase1/main.C
syntax/syntax1.C

--Brian


Date: Fri, 7 Mar 1997 18:18:22 -0800
From: chambers@klamath (Craig Chambers)
To: cecil@cs, cse590l@cs, cse501@cs, spin-comp@cs
Subject: PLDI'94?

I'm missing my PLDI'94 proceedings.  Did I loan it to any of you?

-- Craig

To: spin-comp@franklin.cs.washington.edu
Subject: Making interpreter dispatches static
Date: Sat, 08 Mar 1997 15:57:15 PST
From: Matthai Philipose <matthai@franklin.cs.washington.edu>

A point I hadn't thought about before.

How do we plan to ensure that the igoto that implements
the dispatch on the opcode in an interpreter is a
"static branch"? 

               The problem here is that the igoto
target is calculated by dereferencing a jump table
pointer; since the dereference does not happen at
source level, we cannot label it transitive. Since
our default is safe, the result of the dereference
(the branch direction) will be labelled dynamic.

The compiler does the lowering to load/igoto very early
on, way before the BTA. So one plausible trick of
automatically making the load transitive when a
"static" switch is lowered to load/igoto doesn't work...

Is this problem already fixed? 

   Matthai

To: Matthai Philipose <matthai@cs.washington.edu>
cc: spin-comp@thistle.cs.washington.edu
Subject: Re: Making interpreter dispatches static 
Date: Sun, 09 Mar 1997 14:07:02 PST
From: Brian Grant <grant@thistle.cs.washington.edu>

>> Is this problem already fixed? 

It probably doesn't work now, but should be hard to fix.  We can easily
figure out that what we're loading is from a jump table and that it should
be static (by name).  All computations (adds & shifts) involving the static
variable being switched upon and the value jump table could then be
derived as static.

--Brian


To: Brian Grant <grant@thistle.cs.washington.edu>
cc: spin-comp@franklin.cs.washington.edu
Subject: Re: Making interpreter dispatches static 
Date: Mon, 10 Mar 1997 09:15:40 PST
From: Matthai Philipose <matthai@franklin.cs.washington.edu>

One way to veiw this is that both kinds of transitivity annotations
may be useful (per use annotations, _and_ per data-structure/field
annotations).  We essentially need to label the jump-table datastructure 
as being static.
      Matthai

> >> Is this problem already fixed? 
> 
> It probably doesn't work now, but should be hard to fix.  We can easily
> figure out that what we're loading is from a jump table and that it should
> be static (by name).  All computations (adds & shifts) involving the static
> variable being switched upon and the value jump table could then be
> derived as static.
> 
> --Brian
> 
> 


Date: Wed, 12 Mar 1997 14:27:25 -0800 (PST)
From: Markus Mock <mock@apex.cs.washington.edu>
To: spin-comp@apex.cs.washington.edu
Subject: PEPM paper

For tomorrow's meeting it would be good if everyone of us had thought 
about what should go in the different sections, what examples we would 
like to use, what runtime actions we can use, etc.

In our last meeting talking about the structure of the paper we had come 
up with something like:

1 Informal introduction of our appraoch with examples
2 Description of our runtime actions, specialization algorithm
3 Specification of our annotations
4 Formal Definition of the BTA
5 Optimization of our specialization algorithm, units and other optimizations
6 Related Work
7 Future Work


	-- Markus 

====================================================================

Research is what I'm doing when I don't know what I'm doing.
                -- Wernher von Braun


Date: Thu, 13 Mar 1997 09:47:47 -0800
From: chambers@hoh
To: spin-comp@cs
Subject: delay meeting

I'm needed at home this morning, so can we delay our meeting till 11:30-1?
Thanks.

-- Craig

Date: Thu, 13 Mar 1997 13:24:06 -0800
From: Charles Garrett <garrett@cs.washington.edu>
To: spin-comp
Subject: Alpha cache size

I was wrong about the instruction cache size of the Alpha. It is
actually 32 bytes per line, which is 8 instructions. The entire cache
is 8 KB so there are 256 lines in the cache. The data cache has
the same size and line size.

--
Charlie

Date: Mon, 17 Mar 1997 10:11:04 -0800 (PST)
From: Markus Mock <mock@apex.cs.washington.edu>
To: spin-comp@apex.cs.washington.edu
Subject: PEPM Advance Program 

is out:

http://www.cs.kun.nl/fpl/icfp-pepm97/#pepm



	-- Markus 

====================================================================

Research is what I'm doing when I don't know what I'm doing.
                -- Wernher von Braun


Date: Wed, 19 Mar 1997 18:49:24 -0800
From: Charles Garrett <garrett@cs.washington.edu>
To: spin-comp
Subject: working perl interpreter

I won't be here for Thursday's meeting, so here is my report.

The SPEC95 version of the perl interpreter is now working on some
of its input programs. It doesn't work on all inputs however, 
indicating that there are still errors in the compiled code.

This program is 30,000 lines long so it represents a big advance
over our previous largest benchmark which was the 3000 line compress
program. Since perl is an interpreter, it gives us one example in
a class of applications where we think DyC will work well.

I feel fairly confident now that the 64-bit compiler will be
able to handle the kinds of programs that we discussed using
for the first DyC examples. 

--
Charlie

Date: Thu, 20 Mar 1997 10:30:13 -0800 (PST)
From: chambers@klamath (Craig Chambers)
To: spin-comp@june, garrett@cs.washington.edu
Subject: Re: working perl interpreter

Great!  I'm glad we're reaching a serious level of stability.

-- Craig

To: spin-comp@thistle.cs.washington.edu
Subject: we have setup/template separation!
Date: Fri, 21 Mar 1997 10:57:25 PST
From: Brian Grant <grant@thistle.cs.washington.edu>

Yeah!  Now to get those RTCONSTs working...

--Brian


Date: Tue, 25 Mar 1997 13:26:49 -0800 (PST)
From: chambers@klamath (Craig Chambers)
To: spin-comp@cs
Subject: laziness

It would be nice if we could say that our laziness policy, by default, is safe
in that no unbounded specialization will be performed.  This is true for loops,
with our looplazy default, but it's not true for recursive functions in the
presence of our function annotations.  We still need some notion of laziness
for recursive calls guarded by a dynamic conditional.  Markus, can you think
about this issue and see if there's a solution we can propose?

-- Craig

To: chambers@klamath (Craig Chambers)
cc: spin-comp@thistle.cs.washington.edu
Subject: Re: laziness 
Date: Tue, 25 Mar 1997 13:35:49 PST
From: Brian Grant <grant@thistle.cs.washington.edu>

>> We still need some notion of laziness
>> for recursive calls guarded by a dynamic conditional.

At one point, we considered making polyLazy apply to all calls, and loopLazy
apply to recursive calls guarded by dynamic conditionals.  Do we need a
version of the reachability analysis that applies to dynamic conditionals?

--Brian


To: chambers@franklin.cs.washington.edu
cc: spin-comp@franklin.cs.washington.edu
Subject: Modified version of selective specialization...
Date: Tue, 25 Mar 1997 14:00:18 PST
From: Matthai Philipose <matthai@franklin.cs.washington.edu>

Brian pointed out that the FUNCALL and RETURN opcodes don't
have the stack behavior conventionally expected of a function
call.

Not only does the pc have to be restored, the state
of whether the function returned to should be 
specialized, i.e. the "specialization mode" needs
restoration (also Brian's observation).

Below is a version with a fix for this problem.
FUNCALL is now called GOSUB.
The old RETURN opcode is now replaced by EXIT.
RETURN has new semantics.

An ugliness in the fix is in ensuring that
"specialization-mode" is restored. I can't
think of an "invisible" way to do this, except
to change the example to one Brian and I discussed
way back: make the example an interpretFunction(...)
routine instead of interpret(...), call it recursively
at GOSUBs and let the call-stack implicitly
keep track of specialization mode through the return
pc (the callee either returns to a specialzed or an unspecialized
version of the caller, depending on who invoked it).
				Matthai

ps: Craig mentioned that the current version of the BTA 
    cannot handle the conditional specialization below.
    I assume the problem is with the fact that we cannot
    "propagate annotations across backedges". Brian and
    I feel the current example may be a(nother?) good reason 
    to abandon that restriction in the BTA! 

---------------------
interpret(byteCodeT byteCodes[],
          int argList[], int numArgs) {
   int valueStack[STACK_SIZE];
   int pc = 0, vsp = 0;
   int arg, opcode;
   bool shouldSpecialize=true; /*Specialization mode*/

   /* push arguments */
   for (arg = numArgs; arg > 0; arg--)
      valueStack[vsp++] = argList[arg-1];
      
      /*DyC annotations for polyvariant
        specialization on bytecodes and pc
        at every downstream use*/
		      makeStatic(bytecodes : transitive);
      makestatic(pc);

      for (;;) {
      opcode = byteCodes[pc];
      switch (opcode)
         
	case ADD:
            valueStack[vsp-1] =
                valueStack[vsp] +		
                valueStack[vsp-1];
	            vsp--; pc++;
	            break;
         
	case NEQ:
       pp0: if (valueStack[vsp] != 0)
		               pc = byteCodes[pc+1];
            else 
               pc += 2;
       pp1: break;
         
	 case RETURN: /* Modified to restore specialization mode */
	    if(valueStack[vsp--] == true)
		{
		  shouldSpecialize=true;	
		  makeStatic(pc);
		}
	    else
		{
		  shouldSpecialize=false;
		  makeDynamic(pc);
		}

			
	 case IGOTO:
       pp2: pc = valueStack[vsp--];
	            break;
        
	 /* This is the new case added... the opcode for function invocation */
	  case GOSUB:
		/*Get the function to jump to*/
		 pc = byteCodes[pc+1]; 
		 valueStack[vsp++]=pc;
		 valueStack[vsp++]=shouldSpecialize;
	
		/*Keep track of how many times this fn has been invoked*/ 
		 incrementNumCalls(pc); 
		/*Don't specialize infrequent functions*/
		 if (NumCalls(pc) < MIN_NUM_CALLS) 
		    {
			shouldSpecialize=false;
			makeDynamic(pc);
		     }
		 else
		     {
			shouldSpecialize=true;
			makeStatic(pc);
		      }
		  break;

	/* ... */
	 
         case EXIT:  /* Return opcode now called EXIT */
            return valueStack[vsp];
      }
   }
}


To: Matthai Philipose <matthai@cs.washington.edu>
cc: spin-comp@thistle.cs.washington.edu
Subject: Re: Modified version of selective specialization... 
Date: Tue, 25 Mar 1997 14:09:07 PST
From: Brian Grant <grant@thistle.cs.washington.edu>

>>ps: Craig mentioned that the current version of the BTA 
>>    cannot handle the conditional specialization below.
>>    I assume the problem is with the fact that we cannot
>>    "propagate annotations across backedges". Brian and
>>    I feel the current example may be a(nother?) good reason 
>>    to abandon that restriction in the BTA! 

I feel that not propagating the annotations along back edges is not
intuitive as we once thought, but rather counterintuitive.  This is
certainly true (IMO) for most loops, which have their exits at the top.
The rule also yields different semantics for loops as for recursive calls,
which we should tend to avoid (also IMO).

Of course, if we change the rule and propagate annotations along back edges,
we have to be careful we don't get ourselves in trouble when performing
polyvariant division.

--Brian


Date: Wed, 26 Mar 1997 10:44:58 -0800 (PST)
From: chambers@klamath (Craig Chambers)
To: spin-comp@thistle.cs.washington.edu, grant@thistle.cs.washington.edu
Subject: Re: Treating functions -- memoizing, inlining, specializing


> From grant@thistle.cs.washington.edu  Wed Mar 26 10:27:09 1997
> Delivery-Date: Wed, 26 Mar 1997 10:27:18 PST
> X-Mailer: exmh version 1.5.3 12/28/94
> X-DiscussionList: functions
> To: spin-comp@thistle.cs.washington.edu
> Subject: Treating functions -- memoizing, inlining, specializing
> Mime-Version: 1.0
> Date: Wed, 26 Mar 1997 09:58:40 PST
> From: Brian Grant <grant@thistle.cs.washington.edu>
> 
> On the bus this morning, I thought a little bit about the idea of applying
> laziness to recursive calls.  Here are some observations and questions.
> 
> -- Calls, if they are to be specialized, are specialized lazily.

Why?  I don't think this should be true.

> -- We are only in danger of not terminating when inlining (at run time) or
>    memoizing (calling "constant" functions at specialization time).  

Only with the above assumption, which I don't think we should assume.

> -- For a function to be labelled "constant", all of the functions it calls
>    must also be constant.  We can either require this of the user, or perform
>    interprocedural analysis (really just traversing the call graph) to
>    verify that it is true.
> -- What happens if we decide to memoize a constant function with all static
>    arguments that then makes a call to another constant function, not all of
>    whose arguments are static?  Probably we should prevent this.  Perhaps a
>    function shouldn't be labelled constant if it can call a function with
>    dynamic arguments?

Actually, I think we place no requirements on a constant function other than
its external input-output interface look like a pure function w/o 
(externally-visible) side-effects.  Internally, the constant function can do
whatever it wants.

> -- It appears that we need interprocedural analysis (again, traversing the
>    call graph) to detect recursion.

Yikes.

> -- How do we detect that a recursive call is guarded by a dynamic conditional?
>    do we need interprocedural reachability analysis for dynamic conditionals?

Hmmmm.

-- Craig

Date: Wed, 26 Mar 1997 12:39:38 -0800 (PST)
From: chambers@klamath (Craig Chambers)
To: spin-comp@cs
Subject: some paper text

I've written a first draft of sections 1 & 2 of the paper, intro & example.
I haven't proofread my own writing much, but I think it's pretty interesting.
See what you think: on a sun, ~chambers/papers/pepm/97/dc.{doc,ps}.  3.25 pages
so far, w/ 11pt text font.

-- Craig

Date: Wed, 26 Mar 1997 16:06:07 -0800 (PST)
From: chambers@klamath (Craig Chambers)
To: Charles.Consel@irisa.fr, grant@cs.washington.edu
Subject: Re: Tempo's BTA and PEPM `97 deadline
Cc: spin-comp@thistle.cs.washington.edu

Actually, my understanding from Charles's visit was that Tempo did no 
polyvariant division, and did polyvariant specialization only of the entry
function, since the client program manually called the entry function
specializer explicitly for different input static values.

-- Craig

Date: Wed, 26 Mar 1997 18:00:32 -0800 (PST)
From: chambers@klamath (Craig Chambers)
To: spin-comp@cs
Subject: more paper

I've written a draft of section 3 (the run-time specializer) now.  Check it out
if you have time.  It's somewhat different from Brian's description; make sure
I haven't suppressed any important detail.  And see if it's understandable to
you....

In the same place as before.

-- Craig

Date: Thu, 27 Mar 1997 14:10:00 -0800 (PST)
From: Markus Mock <mock@apex.cs.washington.edu>
To: spin-comp@apex.cs.washington.edu
Subject: BTA Overview

Here's an overview of what the BTA needs to compute:


1. BTA Output for the GE

The BTA computes the following output for the GE 

	at each program point

	- static / dynamic division of variables
	- variables in the cache context and their policies
	- ?promotion point: if so, for which vars
	- ?discordant merge:if so, for which vars
	- edge: eager or lazy



2. BTA Components and internally computed info
	
	- compute specialization policies:
		- at each program point which variables are specialized	
	      	  and with what policy (tuple <M,P,R> for monovariantly,
		  polyvariantly and promoteStaticly specialized 
		  variables, respectively)
		  ->computed from makeStatic/makeDynamic annotations
		  and for the monovariant policy also dependent on
		  what merges are static/dynamic
		- for each edge: compute whether lazy or eager


	- compute static / dynamic division (per program point) including
		- static / dynamic division of variables
		- variables in the cache context (w/ policy)
		- ?promotion point w/ vars
		- ?discordant merge w/ vars
		- for each variable x compute its "derived set" Dx containing
	          all variables from M U P U R which may derive x

	- function specialization: (depends on above two analyses)
		- record functions annotated with specialize /constant and 
		  their argument sets in a table spec_tab
		- at each call site calling a specializied function f 
		  (f in spec_tab) select the most specific matching 
		  version

		  
		
		
		 
			
	

Date: Thu, 27 Mar 1997 17:54:52 -0800 (PST)
From: chambers@klamath (Craig Chambers)
To: spin-comp@cs
Subject: latest paper version

OK, I've written one more section, section 4 on the annotations.  Took all
afternoon to do it, erg.  See the latest draft in the standard place.  Tomorrow
morning I work on the BTA, and hopefully tomorrow afternoon on the GEGen part.

(FYI, Markus and I have done some iterating and refining of his BTA equations
that he posted, so don't take them as the final version.)

-- Craig

Date: Fri, 28 Mar 1997 16:51:49 +0100
From: Charles Consel <Charles.Consel@irisa.fr>
To: grant@cs.washington.edu
Subject: Re: Tempo's BTA and PEPM `97 deadline


> -- What kind of polyvariant division does Tempo perform?

> 	-- Multiple divisions per function?
> 		My understanding: possibly for those functions annotated as
> 		entry points

> Greg's message:
> Actually, my understanding from Charles's visit was that Tempo did no 
> polyvariant division, and did polyvariant specialization only of the entry
> function, since the client program manually called the entry function
> specializer explicitly for different input static values.


The BTA and the program specializer are polyvariant for *all*
procedures. Let me give your (my) definitions of these terms to make
this clear. The first one (polyvariant BTA) gives you multiple
abstract descriptions per procedure at analysis time. The second one
(polyvariant specialization) gives you multiple specialized versions
per procedure (abstract description) at specialization time.

> 	-- Multiple divisions per program point?
> 		My understanding: only at joins following conditionals with
> 		static tests; is this done for switch statements as well as
> 		if statements?
> 

Switchs are compiled in to ifs right now. A given program point has a
unique abstract description for a given procedure description, and a
unique "instance" for a given specialized version.

> -- What kind of polyvariant specialization does Tempo perform?
> 	-- How does Tempo pick up run-time values and use them for
> 	   specialization?
> 		My understanding: from globals or parameters of functions
> 		annotated as entry points; are the values of static globals
> 		read when an associated function (an entry point) is
> 		specialized?

Yes.


> 	-- Multiple specializations per function?
> 		My understanding: only for functions not annotated as entry
> 		points?

No. It is a full-fledged polyvariant specializer (run time and compile
time).  By the way, the polyvariant concept (BTA/SPEC) being global to
a program (not just the entry point) is the common understanding
people have in the PE community (Similix, Schism, ...).


> 	-- Multiple specializations per program point?
> 		My understanding: only simple loop unrolling, not for
> 		arbitrary control-flow merges; e.g., can a loop such as
> 		the following be reduced?
>       red         ev            ev   id  ev reb  reb      ev         ev
>    for    ((i = 0)  ; (i < size)  ; v  [i  ]    ?    (i++)   : (i+=2)  )
>       { ... }
> 		(Basically, the static update of the loop induction variable
> 		 is guarded by a dynamic conditional.)
> 

We loose here.


> 		Also, what do you do about loops with both static and dynamic
> 		exit tests (multiple loop exits)?
> 

We loose here as well. It will be assumed dynamic.

> Also, at what time next Thursday are the papers due?  Can we send the
> copyright form early and submit the final version of the paper
> electronically on April 3rd, or should that type of thing only be done as
> a last resort?

Well, just send me the copyright form for April 3rd and the paper
electronically. I was going to say that the paper size will not be
good but of course that's OK there are also europeans sending their
final versions :-)


BTW here is a tech report you might be interested in; it describes a
full-size application of TEMPO for the specialization of the SUN RPC
(compile-time specialization).

Charles

----------------------------------------------------------------------------
Charles Consel              | University of Rennes / Irisa 
 consel@irisa.fr            | Campus Universitaire de Beaulieu
 Phone: (33) 2 99 84 74 10 | 35042 Rennes Cedex
 Fax:   (33) 2 99 84 71 71 | France
----------------------------------------------------------------------------
  URL: http://www.irisa.fr/EXTERNE/projet/lande/consel/consel.html & index.html
----------------------------------------------------------------------------


%!PS-Adobe-2.0
%%Creator: dvipsk 5.55a Copyright 1986, 1994 Radical Eye Software
%%Title: PI-1094.dvi
%%Pages: 21
%%PageOrder: Ascend
%%BoundingBox: 0 0 596 842
%%DocumentFonts: Helvetica Times-Bold Times-Roman Times-Italic Courier
%%+ Courier-Bold Courier-Oblique
%%EndComments
%DVIPSCommandLine: /usr/local/lib/texmf/bin/sunos4.1/dvips -o PI-1094.ps
%+ PI-1094.dvi
%DVIPSParameters: dpi=600, compressed, comments removed
%DVIPSSource:  TeX output 1997.03.24:1100
%%BeginProcSet: texc.pro
/TeXDict 250 dict def TeXDict begin /N{def}def /B{bind def}N /S{exch}N
/X{S N}B /TR{translate}N /isls false N /vsize 11 72 mul N /hsize 8.5 72
mul N /landplus90{false}def /@rigin{isls{[0 landplus90{1 -1}{-1 1}
ifelse 0 0 0]concat}if 72 Resolution div 72 VResolution div neg scale
isls{landplus90{VResolution 72 div vsize mul 0 exch}{Resolution -72 div
hsize mul 0}ifelse TR}if Resolution VResolution vsize -72 div 1 add mul
TR matrix currentmatrix dup dup 4 get round 4 exch put dup dup 5 get
round 5 exch put setmatrix}N /@landscape{/isls true N}B /@manualfeed{
statusdict /manualfeed true put}B /@copies{/#copies X}B /FMat[1 0 0 -1 0
0]N /FBB[0 0 0 0]N /nn 0 N /IE 0 N /ctr 0 N /df-tail{/nn 8 dict N nn
begin /FontType 3 N /FontMatrix fntrx N /FontBBox FBB N string /base X
array /BitMaps X /BuildChar{CharBuilder}N /Encoding IE N end dup{/foo
setfont}2 array copy cvx N load 0 nn put /ctr 0 N[}B /df{/sf 1 N /fntrx
FMat N df-tail}B /dfs{div /sf X /fntrx[sf 0 0 sf neg 0 0]N df-tail}B /E{
pop nn dup definefont setfont}B /ch-width{ch-data dup length 5 sub get}
B /ch-height{ch-data dup length 4 sub get}B /ch-xoff{128 ch-data dup
length 3 sub get sub}B /ch-yoff{ch-data dup length 2 sub get 127 sub}B
/ch-dx{ch-data dup length 1 sub get}B /ch-image{ch-data dup type
/stringtype ne{ctr get /ctr ctr 1 add N}if}B /id 0 N /rw 0 N /rc 0 N /gp
0 N /cp 0 N /G 0 N /sf 0 N /CharBuilder{save 3 1 roll S dup /base get 2
index get S /BitMaps get S get /ch-data X pop /ctr 0 N ch-dx 0 ch-xoff
ch-yoff ch-height sub ch-xoff ch-width add ch-yoff setcachedevice
ch-width ch-height true[1 0 0 -1 -.1 ch-xoff sub ch-yoff .1 add]/id
ch-image N /rw ch-width 7 add 8 idiv string N /rc 0 N /gp 0 N /cp 0 N{
rc 0 ne{rc 1 sub /rc X rw}{G}ifelse}imagemask restore}B /G{{id gp get
/gp gp 1 add N dup 18 mod S 18 idiv pl S get exec}loop}B /adv{cp add /cp
X}B /chg{rw cp id gp 4 index getinterval putinterval dup gp add /gp X
adv}B /nd{/cp 0 N rw exit}B /lsh{rw cp 2 copy get dup 0 eq{pop 1}{dup
255 eq{pop 254}{dup dup add 255 and S 1 and or}ifelse}ifelse put 1 adv}
B /rsh{rw cp 2 copy get dup 0 eq{pop 128}{dup 255 eq{pop 127}{dup 2 idiv
S 128 and or}ifelse}ifelse put 1 adv}B /clr{rw cp 2 index string
putinterval adv}B /set{rw cp fillstr 0 4 index getinterval putinterval
adv}B /fillstr 18 string 0 1 17{2 copy 255 put pop}for N /pl[{adv 1 chg}
{adv 1 chg nd}{1 add chg}{1 add chg nd}{adv lsh}{adv lsh nd}{adv rsh}{
adv rsh nd}{1 add adv}{/rc X nd}{1 add set}{1 add clr}{adv 2 chg}{adv 2
chg nd}{pop nd}]dup{bind pop}forall N /D{/cc X dup type /stringtype ne{]
}if nn /base get cc ctr put nn /BitMaps get S ctr S sf 1 ne{dup dup
length 1 sub dup 2 index S get sf div put}if put /ctr ctr 1 add N}B /I{
cc 1 add D}B /bop{userdict /bop-hook known{bop-hook}if /SI save N @rigin
0 0 moveto /V matrix currentmatrix dup 1 get dup mul exch 0 get dup mul
add .99 lt{/QV}{/RV}ifelse load def pop pop}N /eop{SI restore showpage
userdict /eop-hook known{eop-hook}if}N /@start{userdict /start-hook
known{start-hook}if pop /VResolution X /Resolution X 1000 div /DVImag X
/IE 256 array N 0 1 255{IE S 1 string dup 0 3 index put cvn put}for
65781.76 div /vsize X 65781.76 div /hsize X}N /p{show}N /RMat[1 0 0 -1 0
0]N /BDot 260 string N /rulex 0 N /ruley 0 N /v{/ruley X /rulex X V}B /V
{}B /RV statusdict begin /product where{pop product dup length 7 ge{0 7
getinterval dup(Display)eq exch 0 4 getinterval(NeXT)eq or}{pop false}
ifelse}{false}ifelse end{{gsave TR -.1 -.1 TR 1 1 scale rulex ruley
false RMat{BDot}imagemask grestore}}{{gsave TR -.1 -.1 TR rulex ruley
scale 1 1 false RMat{BDot}imagemask grestore}}ifelse B /QV{gsave
transform round exch round exch itransform moveto rulex 0 rlineto 0
ruley neg rlineto rulex neg 0 rlineto fill grestore}B /a{moveto}B /delta
0 N /tail{dup /delta X 0 rmoveto}B /M{S p delta add tail}B /b{S p tail}
B /c{-4 M}B /d{-3 M}B /e{-2 M}B /f{-1 M}B /g{0 M}B /h{1 M}B /i{2 M}B /j{
3 M}B /k{4 M}B /w{0 rmoveto}B /l{p -4 w}B /m{p -3 w}B /n{p -2 w}B /o{p
-1 w}B /q{p 1 w}B /r{p 2 w}B /s{p 3 w}B /t{p 4 w}B /x{0 S rmoveto}B /y{
3 2 roll p a}B /bos{/SS save N}B /eos{SS restore}B end
%%EndProcSet
%%BeginFont: Helvetica
% @psencodingfile{
%   author = "S. Rahtz, P. MacKay, Alan Jeffrey, B. Horn, K. Berry",
%   version = "0.6",
%   date = "14 April 1995",
%   filename = "8r.enc",
%   email = "kb@cs.umb.edu",
%   address = "135 Center Hill Rd. // Plymouth, MA 02360",
%   codetable = "ISO/ASCII",
%   checksum = "xx",
%   docstring = "Encoding for TrueType or Type 1 fonts to be used with TeX."
% }
% 
% Idea is to have all the characters normally included in Type 1 fonts
% available for typesetting. This is effectively the characters in Adobe
% Standard Encoding + ISO Latin 1 + extra characters from Lucida.
% 
% Character code assignments were made as follows:
% 
% (1) the Windows ANSI characters are almost all in their Windows ANSI
% positions, because some Windows users cannot easily reencode the
% fonts, and it makes no difference on other systems. The only Windows
% ANSI characters not available are those that make no sense for
% typesetting -- rubout (127 decimal), nobreakspace (160), softhyphen
% (173). quotesingle and grave are moved just because it's such an
% irritation not having them in TeX positions.
% 
% (2) Remaining characters are assigned arbitrarily to the lower part
% of the range, avoiding 0, 10 and 13 in case we meet dumb software.
% 
% (3) Y&Y Lucida Bright includes some extra text characters; in the
% hopes that other PostScript fonts, perhaps created for public
% consumption, will include them, they are included starting at 0x12.
% 
% (4) Remaining positions left undefined are for use in (hopefully)
% upward-compatible revisions, if someday more characters are generally
% available.
% 
% (5) hyphen appears twice for compatibility with both ASCII and Windows.
% 
/TeXBase1Encoding [
% 0x00 (encoded characters from Adobe Standard not in Windows 3.1)
  /.notdef /dotaccent /fi /fl
  /fraction /hungarumlaut /Lslash /lslash
  /ogonek /ring /.notdef
  /breve /minus /.notdef 
% These are the only two remaining unencoded characters, so may as
% well include them.
  /Zcaron /zcaron 
% 0x10
 /caron /dotlessi 
% (unusual TeX characters available in, e.g., Lucida Bright)
 /dotlessj /ff /ffi /ffl 
 /.notdef /.notdef /.notdef /.notdef
 /.notdef /.notdef /.notdef /.notdef
 % very contentious; it's so painful not having quoteleft and quoteright
 % at 96 and 145 that we move the things normally found there down to here.
 /grave /quotesingle 
% 0x20 (ASCII begins)
 /space /exclam /quotedbl /numbersign
 /dollar /percent /ampersand /quoteright
 /parenleft /parenright /asterisk /plus /comma /hyphen /period /slash
% 0x30
 /zero /one /two /three /four /five /six /seven
 /eight /nine /colon /semicolon /less /equal /greater /question
% 0x40
 /at /A /B /C /D /E /F /G /H /I /J /K /L /M /N /O
% 0x50
 /P /Q /R /S /T /U /V /W
 /X /Y /Z /bracketleft /backslash /bracketright /asciicircum /underscore
% 0x60
 /quoteleft /a /b /c /d /e /f /g /h /i /j /k /l /m /n /o
% 0x70
 /p /q /r /s /t /u /v /w
 /x /y /z /braceleft /bar /braceright /asciitilde
 /.notdef % rubout; ASCII ends
% 0x80
 /.notdef /.notdef /quotesinglbase /florin
 /quotedblbase /ellipsis /dagger /daggerdbl
 /circumflex /perthousand /Scaron /guilsinglleft
 /OE /.notdef /.notdef /.notdef
% 0x90
 /.notdef /.notdef /.notdef /quotedblleft
 /quotedblright /bullet /endash /emdash
 /tilde /trademark /scaron /guilsinglright
 /oe /.notdef /.notdef /Ydieresis
% 0xA0
 /.notdef % nobreakspace
 /exclamdown /cent /sterling
 /currency /yen /brokenbar /section
 /dieresis /copyright /ordfeminine /guillemotleft
 /logicalnot
 /hyphen % Y&Y (also at 45); Windows' softhyphen
 /registered
 /macron
% 0xD0
 /degree /plusminus /twosuperior /threesuperior
 /acute /mu /paragraph /periodcentered
 /cedilla /onesuperior /ordmasculine /guillemotright
 /onequarter /onehalf /threequarters /questiondown
% 0xC0
 /Agrave /Aacute /Acircumflex /Atilde /Adieresis /Aring /AE /Ccedilla
 /Egrave /Eacute /Ecircumflex /Edieresis
 /Igrave /Iacute /Icircumflex /Idieresis
% 0xD0
 /Eth /Ntilde /Ograve /Oacute
 /Ocircumflex /Otilde /Odieresis /multiply
 /Oslash /Ugrave /Uacute /Ucircumflex
 /Udieresis /Yacute /Thorn /germandbls
% 0xE0
 /agrave /aacute /acircumflex /atilde
 /adieresis /aring /ae /ccedilla
 /egrave /eacute /ecircumflex /edieresis
 /igrave /iacute /icircumflex /idieresis
% 0xF0
 /eth /ntilde /ograve /oacute
 /ocircumflex /otilde /odieresis /divide
 /oslash /ugrave /uacute /ucircumflex
 /udieresis /yacute /thorn /ydieresis
] def
%%EndFont
%%BeginProcSet: texps.pro
TeXDict begin /rf{findfont dup length 1 add dict begin{1 index /FID ne 2
index /UniqueID ne and{def}{pop pop}ifelse}forall[1 index 0 6 -1 roll
exec 0 exch 5 -1 roll VResolution Resolution div mul neg 0 0]/Metrics
exch def dict begin Encoding{exch dup type /integertype ne{pop pop 1 sub
dup 0 le{pop}{[}ifelse}{FontMatrix 0 get div Metrics 0 get div def}
ifelse}forall Metrics /Metrics currentdict end def[2 index currentdict
end definefont 3 -1 roll makefont /setfont load]cvx def}def
/ObliqueSlant{dup sin S cos div neg}B /SlantFont{4 index mul add}def
/ExtendFont{3 -1 roll mul exch}def /ReEncodeFont{/Encoding exch def}def
end
%%EndProcSet
%%BeginProcSet: special.pro
TeXDict begin /SDict 200 dict N SDict begin /@SpecialDefaults{/hs 612 N
/vs 792 N /ho 0 N /vo 0 N /hsc 1 N /vsc 1 N /ang 0 N /CLIP 0 N /rwiSeen
false N /rhiSeen false N /letter{}N /note{}N /a4{}N /legal{}N}B
/@scaleunit 100 N /@hscale{@scaleunit div /hsc X}B /@vscale{@scaleunit
div /vsc X}B /@hsize{/hs X /CLIP 1 N}B /@vsize{/vs X /CLIP 1 N}B /@clip{
/CLIP 2 N}B /@hoffset{/ho X}B /@voffset{/vo X}B /@angle{/ang X}B /@rwi{
10 div /rwi X /rwiSeen true N}B /@rhi{10 div /rhi X /rhiSeen true N}B
/@llx{/llx X}B /@lly{/lly X}B /@urx{/urx X}B /@ury{/ury X}B /magscale
true def end /@MacSetUp{userdict /md known{userdict /md get type
/dicttype eq{userdict begin md length 10 add md maxlength ge{/md md dup
length 20 add dict copy def}if end md begin /letter{}N /note{}N /legal{}
N /od{txpose 1 0 mtx defaultmatrix dtransform S atan/pa X newpath
clippath mark{transform{itransform moveto}}{transform{itransform lineto}
}{6 -2 roll transform 6 -2 roll transform 6 -2 roll transform{
itransform 6 2 roll itransform 6 2 roll itransform 6 2 roll curveto}}{{
closepath}}pathforall newpath counttomark array astore /gc xdf pop ct 39
0 put 10 fz 0 fs 2 F/|______Courier fnt invertflag{PaintBlack}if}N
/txpose{pxs pys scale ppr aload pop por{noflips{pop S neg S TR pop 1 -1
scale}if xflip yflip and{pop S neg S TR 180 rotate 1 -1 scale ppr 3 get
ppr 1 get neg sub neg ppr 2 get ppr 0 get neg sub neg TR}if xflip yflip
not and{pop S neg S TR pop 180 rotate ppr 3 get ppr 1 get neg sub neg 0
TR}if yflip xflip not and{ppr 1 get neg ppr 0 get neg TR}if}{noflips{TR
pop pop 270 rotate 1 -1 scale}if xflip yflip and{TR pop pop 90 rotate 1
-1 scale ppr 3 get ppr 1 get neg sub neg ppr 2 get ppr 0 get neg sub neg
TR}if xflip yflip not and{TR pop pop 90 rotate ppr 3 get ppr 1 get neg
sub neg 0 TR}if yflip xflip not and{TR pop pop 270 rotate ppr 2 get ppr
0 get neg sub neg 0 S TR}if}ifelse scaleby96{ppr aload pop 4 -1 roll add
2 div 3 1 roll add 2 div 2 copy TR .96 dup scale neg S neg S TR}if}N /cp
{pop pop showpage pm restore}N end}if}if}N /normalscale{Resolution 72
div VResolution 72 div neg scale magscale{DVImag dup scale}if 0 setgray}
N /psfts{S 65781.76 div N}N /startTexFig{/psf$SavedState save N userdict
maxlength dict begin /magscale true def normalscale currentpoint TR
/psf$ury psfts /psf$urx psfts /psf$lly psfts /psf$llx psfts /psf$y psfts
/psf$x psfts currentpoint /psf$cy X /psf$cx X /psf$sx psf$x psf$urx
psf$llx sub div N /psf$sy psf$y psf$ury psf$lly sub div N psf$sx psf$sy
scale psf$cx psf$sx div psf$llx sub psf$cy psf$sy div psf$ury sub TR
/showpage{}N /erasepage{}N /copypage{}N /p 3 def @MacSetUp}N /doclip{
psf$llx psf$lly psf$urx psf$ury currentpoint 6 2 roll newpath 4 copy 4 2
roll moveto 6 -1 roll S lineto S lineto S lineto closepath clip newpath
moveto}N /endTexFig{end psf$SavedState restore}N /@beginspecial{SDict
begin /SpecialSave save N gsave normalscale currentpoint TR
@SpecialDefaults count /ocount X /dcount countdictstack N}N /@setspecial
{CLIP 1 eq{newpath 0 0 moveto hs 0 rlineto 0 vs rlineto hs neg 0 rlineto
closepath clip}if ho vo TR hsc vsc scale ang rotate rwiSeen{rwi urx llx
sub div rhiSeen{rhi ury lly sub div}{dup}ifelse scale llx neg lly neg TR
}{rhiSeen{rhi ury lly sub div dup scale llx neg lly neg TR}if}ifelse
CLIP 2 eq{newpath llx lly moveto urx lly lineto urx ury lineto llx ury
lineto closepath clip}if /showpage{}N /erasepage{}N /copypage{}N newpath
}N /@endspecial{count ocount sub{pop}repeat countdictstack dcount sub{
end}repeat grestore SpecialSave restore end}N /@defspecial{SDict begin}
N /@fedspecial{end}B /li{lineto}B /rl{rlineto}B /rc{rcurveto}B /np{
/SaveX currentpoint /SaveY X N 1 setlinecap newpath}N /st{stroke SaveX
SaveY moveto}N /fil{fill SaveX SaveY moveto}N /ellipse{/endangle X
/startangle X /yrad X /xrad X /savematrix matrix currentmatrix N TR xrad
yrad scale 0 0 1 startangle endangle arc savematrix setmatrix}N end
%%EndProcSet
TeXDict begin 39158280 55380996 1000 600 600 (PI-1094.dvi)
@start /Fa 2 52 df<EB0FF0EB7FFE48B57E3903E03FE0390F000FF0000E6D7E486D7E
486D7E123000706D7E126012FCB4EC7F807FA56CC7FC121CC8FCEDFF00A34A5A5D14035D
4A5A5D140F4A5A4A5A92C7FC147C5C495A495A495A495A91C8FC011EEB01805B5B491303
48481400485A485A000EC75A000FB6FC5A5A485CB6FCA321387CB72A>50
D<EB07F8EB3FFF4913C03901F80FF03903C007F848486C7E380E0001000F80381FE0006D
7FA56C5A6C5AC85A1401A25D4A5AA24A5A5DEC0F80027EC7FCEB1FFCECFF809038000FE0
6E7EEC01FC816E7EED7F80A216C0A2153F16E0A2121EEA7F80487EA416C049137F007F15
80007EC7FC0070ECFF006C495A121E390F8003F83907F00FF00001B512C06C6C90C7FCEB
0FF8233A7DB72A>I E /Fb 134[50 4[50 50 4[50 50 7[50 50
2[50 34[50 1[50 60[{TeXBase1Encoding ReEncodeFont}10
83.333336 /Courier-Oblique rf /Fc 1 16 df<EB0FE0EB7FFC497E0003EBFF804814
C04814E04814F04814F8A24814FCA3B612FEA86C14FCA36C14F8A26C14F06C14E06C14C0
6C1480C6EBFE006D5AEB0FE01F207BA42A>15 D E /Fd 11 116
df<EB1F80EB7FC0EBF0E73803C03FEA078048487EA2121E003E133E123C127CA2485BA4
485B1530A3903801F060A2EA7803010E13C0393C1CF980381FF07F3907C01E001C1B7C99
24>97 D<EB0FE0EB3FF8EBF81C3801E00E3803803E0007137EEA0F00001E137C123E003C
1300127CA25AA45AA31404140C0078131814306C13E0381E07C0380FFF00EA03F8171B7C
991E>99 D<15F8141FA2EC01F0A21403A215E0A21407A215C0A2140FEB1F8F90387FCF80
EBF0EF3803C03FEA0780390F001F00A2001E5B123E003C133E127C147E5A147CA214FC5A
ECF830A3903801F060A2EA7803010E13C0393C1CF980381FF07F3907C01E001D297CA723
>I<EB0FC0EB7FF0EBF0383803C01CEA0780EA0F005A121E003E1338481370EB07E0387F
FF8038FFFC0000F8C7FCA45AA214040078130C141800381330003C13E0381E07C0380FFF
00EA03F8161B7C991F>I<EB01F0EB07FC90381E0CE0EB3C071378EBF003EA01E0A20003
EB07C013C01207A2390F800F80A49038001F00A4143E3807807E14FE3803C3BE6CB45AEA
007C1300A25CA21238387C01F012FC495A48485A38701F80D83FFEC7FCEA0FF01B267E99
20>103 D<130E131F5BA2133E131C90C7FCA7EA03E0487EEA0C78EA187C1230A212605B
12C0A2EA01F0A3485AA2485AA2EBC180EA0F81A2381F0300A213066C5A131CEA07F06C5A
11287DA617>105 D<137CEA0FFCA2EA00F8A21201A213F0A21203A213E0A21207A213C0
A2120FA21380A2121FA21300A25AA2123EA2127EA2EA7C18A3EAF830A21320EA786013C0
EA3F80EA0F000E297EA715>108 D<3907801FC0390FE07FF03918F0E0F83930F1807CEB
FB00D860FE133C5B5B00C1147C5B1201A248485BA34A5AEA07C01660EC03E0A23A0F8007
C0C0A2EDC180913803C300D81F0013C7EC01FE000EEB00F8231B7D9929>110
D<9038F007C03901FC1FF039031E78780006EBE03C90381FC01C000CEB801E14005B0018
141F133E1200137E153E137CA213FC157C5B1578000114F0A2EC01E0EC03C03903FC0780
9038FE1F00EBE7FCEBE1F0D807E0C7FCA25BA2120FA25B121FEAFFF8A22025809922>
112 D<3807803E390FE0FF803818F3C13930F703C0EBFE073860FC0F13F8158039C1F007
0091C7FC1201A2485AA4485AA4485AA448C8FCA2120E1A1B7D991F>114
D<EB0FE0EB7FF8EBF03C3801C00E0003131E3807803EA2143C000F1318EBE0006CB4FC14
C06C13E06C13F06C13F813071301EA3C00007E1378A24813F05A387001E0EB03C0383C0F
80381FFE00EA07F8171B7C991F>I E /Fe 1 81 df<0103B7FC4916E018F8903B0007F8
0007FC4BEB00FE187F020FED3F80F01FC05DA2021F16E0A25DA2143FF03FC05DA2027FED
7F80A292C8130018FE4A4A5A604AEC07F04D5A0101ED3FC04CB4C7FC91B612FC17E0D903
FCCAFCA25CA21307A25CA2130FA25CA2131FA25CA2133FA25CA2137FA291CBFC497EB6FC
A33B397DB835>80 D E /Ff 130[45 1[45 45 1[45 1[45 45 45
45 45 1[45 45 45 45 45 1[45 45 45 45 45 45 45 1[45 45
1[45 6[45 2[45 45 45 45 1[45 45 45 1[45 4[45 45 45 45
2[45 2[45 45 1[45 8[45 45 3[45 45 45 45 45 45 1[45 38[{
TeXBase1Encoding ReEncodeFont}50 75.000000 /Courier-Bold
rf /Fg 134[50 50 72 50 55 33 39 44 1[55 50 55 83 28 55
1[28 55 50 33 44 55 44 55 50 9[100 2[66 55 2[61 78 7[78
1[66 72 72 66 72 10[50 1[50 50 50 50 1[28 25 42[55 3[{
TeXBase1Encoding ReEncodeFont}42 100.000000 /Times-Bold
rf /Fh 107[33 33 24[33 37 37 54 37 37 21 29 25 1[37 37
37 58 21 37 1[21 37 37 25 33 37 33 37 33 9[71 1[54 1[42
50 1[42 54 54 66 3[25 1[54 1[46 54 50 20[19 1[19 2[25
25 36[42 42 2[{TeXBase1Encoding ReEncodeFont}45 75.000000
/Times-Roman rf /Fi 130[45 1[45 45 45 45 1[45 45 45 45
45 1[45 45 45 45 45 1[45 45 45 45 45 45 45 45 45 45 1[45
6[45 2[45 45 45 45 1[45 45 45 1[45 4[45 45 45 45 45 1[45
2[45 45 45 45 6[45 1[45 45 45 45 45 45 45 45 45 45 45
1[45 4[45 33[{TeXBase1Encoding ReEncodeFont}59 75.000000
/Courier rf /Fj 206[29 49[{TeXBase1Encoding ReEncodeFont}1
58.333336 /Times-Roman rf /Fk 130[50 1[50 50 50 50 1[50
50 50 50 50 1[50 50 50 50 50 1[50 50 50 50 50 50 50 50
50 50 50 50 6[50 2[50 50 1[50 2[50 50 1[50 2[50 3[50
50 50 4[50 50 1[50 8[50 4[50 3[50 50 40[{TeXBase1Encoding ReEncodeFont}
45 83.333336 /Courier rf /Fl 138[40 1[40 40 4[40 40 2[40
2[40 40 3[40 32[40 17[40 46[{TeXBase1Encoding ReEncodeFont}11
66.666664 /Courier rf /Fm 107[29 29 25[33 1[48 33 33
18 26 22 33 33 33 33 52 18 2[18 33 33 22 29 33 29 33
29 16[37 6[22 2[37 2[44 1[48 6[18 33 4[33 2[33 33 1[17
1[17 4[22 8[22 20[22 9[{TeXBase1Encoding ReEncodeFont}39
66.666664 /Times-Roman rf /Fn 206[25 6[25 42[{
TeXBase1Encoding ReEncodeFont}2 50.000000 /Times-Roman
rf /Fo 75[22 61[29 33 18 26 2[33 2[48 7[29 18[41 23[22
16[22 22 40[{TeXBase1Encoding ReEncodeFont}12 66.666664
/Times-Italic rf /Fp 133[32 37 37 55 37 42 23 32 32 42
42 42 42 60 23 37 1[23 42 42 23 37 42 37 42 42 8[51 69
51 60 46 42 51 1[51 60 55 69 46 55 37 28 1[60 51 51 60
55 51 51 6[28 42 3[42 1[42 42 42 42 1[21 28 21 56 3[28
65 34[42 3[{TeXBase1Encoding ReEncodeFont}61 83.333336
/Times-Italic rf /Fq 75[28 57[37 42 42 60 42 46 28 32
37 1[46 42 46 69 23 46 1[23 46 42 28 37 46 37 46 42 12[55
46 60 1[51 65 1[78 1[65 3[65 1[55 1[60 55 60 6[28 42
42 42 42 42 42 42 42 42 42 1[21 28 45[{TeXBase1Encoding ReEncodeFont}50
83.333336 /Times-Bold rf /Fr 75[28 11[28 16[83 42 1[37
37 10[28 13[37 42 42 60 42 42 23 32 28 42 42 42 42 65
23 42 23 23 42 42 28 37 42 37 42 37 3[28 1[28 51 60 60
78 60 60 51 46 55 60 46 60 60 74 51 60 32 28 60 60 46
51 60 55 55 60 1[37 3[23 23 42 42 42 42 42 42 42 42 42
42 23 21 28 21 1[42 28 28 28 65 69 6[28 12[23 7[28 5[46
46 2[{TeXBase1Encoding ReEncodeFont}89 83.333336 /Times-Roman
rf /Fs 137[50 50 28 39 33 2[50 50 1[28 2[28 50 50 1[44
50 44 1[44 10[72 3[66 1[55 1[72 89 5[72 1[61 1[66 1[72
19[33 25 5[78 38[{TeXBase1Encoding ReEncodeFont}27 100.000000
/Times-Roman rf /Ft 75[40 57[53 1[60 1[60 66 40 47 53
66 66 60 66 100 33 66 1[33 66 60 40 53 66 53 1[60 9[120
1[86 80 66 86 1[73 93 5[47 2[73 80 86 86 1[86 8[60 60
60 60 60 60 60 60 4[30 4[40 8[40 30[{TeXBase1Encoding ReEncodeFont}47
119.999947 /Times-Bold rf /Fu 75[17 90[33 3[36 30 33
36 39 1[39 36 41 28 2[14 36 1[30 33 36 36 1[33 34[17
30[{TeXBase1Encoding ReEncodeFont}19 50.000000 /Helvetica
rf /Fv 75[22 29[37 29[33 48 33 37 18 33 22 37 37 37 37
55 15 2[15 37 1[18 37 37 33 1[37 11[48 41 44 48 3[48
4[18 2[41 2[48 44 44 6[18 37 37 37 1[37 37 37 37 37 37
18 18 4[22 22 37[33 2[{TeXBase1Encoding ReEncodeFont}47
66.666664 /Helvetica rf /Fw 165[76 3[83 90 76 83 90 1[83
97 90 104 69 2[35 90 97 76 83 90 90 1[83 19[41 35 5[83
38[{TeXBase1Encoding ReEncodeFont}22 125.000000 /Helvetica
rf end
%%EndProlog
%%BeginSetup
%%Feature: *Resolution 600dpi
TeXDict begin
%%PaperSize: a4

%%EndSetup
%%Page: 0 1
0 0 bop -364 6086 a @beginspecial 70 @llx 18 @lly 611
@urx 792 @ury 5410 @rwi @setspecial
%%BeginDocument: pub-inte.epsi
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000055555550000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000808080000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000055555550000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000015505550000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000008800888000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000055505554000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000055501555000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000008800880800000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000055500555000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000015500555400000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000008800088800000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000055500155500000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000055500055540000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000800000800000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000055500055540000000000000000000000000000000
% 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000003fc
% 000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000005550055555400000000000000000000000005dddc
% 000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000880088888800000000000000000000000ffffffc
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000055555555554000000000000000000001555555554
% 000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000007fffffffffc
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000055555555554000000000000000001dd5ddd5ddd5c
% 000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000880888088800000000000000003ffffffffffffc
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000055555555555400000000000000555555555555554
% 000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001fffffffffffffffc
% 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000155555405554000000000005ddddddddddddddddc
% 000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000888880008888000000000fffffffffffffffffc0
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000015555000155540000000155555555555555554000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001fffffffffffffffe00000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000055540000155540000015d5d5d5d5d5d5d40000000
% 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000008000000080800001fffffffffffffe000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000055540000055500001555555555555500000000000
% 000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001ffffffffffff0000000000000
% 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000155000000100001dddddddddddc00000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000008800000000000fffffffffffe000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000055500000000005555555555540000000000000000
% 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000fffffffffffc00000000000000000
% 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000555000000005ddd5ddd5dd8000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000800000000000000000000000000008800000007ffffffffff80000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000055540000000000000000000000000055500000015555555555000000000000000000000
% 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001ffffffffff0000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000555550000000000000000000000000055500000dddddddddc00000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000888888000000000000000000000000088800007ffffffffe000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000001555555000000000000000000000000055400015555555540000000000000000000000000
% 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001ffffffffe00000000000000000000000000
% 00000000000000000000000000000000000000000000000000000000000000155555554000000000000000000000000500005d5d5d5d5000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000008080808000000000000000000000000000007ffffffff8000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000055555555400000000000000000000000000015555555540000000000000000000000000000
% 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001ffffffffc00000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000055544155000000000000000000000000000ddddddddc000000000000000000000000000000
% 00000000000000000000000000000000000000000000000000000000000000888800880000000000000000000000000071fffffff0000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000155400054000000000000000000000000010155555500000000000000000000000000000000
% 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000e01fffffc00000000000000000000000000000000
% 000000000000000000000000000000000000000000000000000000000000015500000000000000000000000000000018015ddd4000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000008800000000000000000000000000001c000fffe0000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000555000000000000000000000000000005000055500000000000000000000000000000000000
% 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000180000ff800000000000000000000000000000000000
% 00000000000000000000000000000000000000000000000000000000000005550000000000000000000000000000c000005c000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000088000000880000000000000000000380000060000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000155000001554000000000000000001400000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000007000000000000000000000000000000000000000000000
% 00000000000000000000000000000000000000000000000000000000000001540001555550000000000000000100e0000000000000000000000000000000000000000000
% 00000000000000000000000000000000000000000000000000000000000000080008080808000000000000000e01b0000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000555515555555400000000000000100300000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000001c071f8000000000000000000000000000000000000000000
% 000000000000000000000000000000000000000000000000000000000000015555555555550000000000000501c188000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000088888888888880000000000018018818000000000000000000000000000000000000000000
% 000000000000000000000000000000000000000000000000000000000000005555555555550000000000004078b1f0000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000181c8c000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000055555555555540000000000401884e00000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000008880888088800000000001808bc7800000000000000000000000000000000000000000000
% 000000000000000000000000000000000000000000000000000000000000001555551001554000000000400ce66000000000000000000000000000000000000000000000
% 00000000000000000000000000000000000000000000000000000000000000000000000000000000000387c4420000000000000000000000000000000000000000000000
% 00000000000000000000000000000000000000000000000000000000000000015550000155400000000c0c44400000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000880000008880000000381862000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000500000005540000000405862000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000003819860000000000000000000000000000000000000000000000000
% 000000000000000000000000000000000000000000000000000000000000000000000000555000000c070cc0000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000800000038090700000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000015540000040818000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000381c08000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000055540000c41e0c000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000008880003881b0c000000000000000000000000000000000000000000000000000
% 00000000000000000000000000000000000000000000000000000000000000000050000555400040e0fc0000000000000000000000000000000000000000000000000000
% 00000000000000000000000000000000000000000000000000000000000000000000000000000381808c0000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000015500555400040118800000000000000000000000000000000000000000000000000000
% 00000000000000000000000000000000000000000000000000000000000000000808800888001801f0800000000000000000000000000000000000000000000000000000
% 00000000000000000000000000000000000000000000000000000000000000001555555550005040c0000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000c0404c000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000155555555001006070000000000000000000000000000000000000000000000000000000
% 000000000000000000000000000000000000000000000000000000000000000008888888800c082040000000000000000000000000000000000000000000000000000000
% 00000000000000000000000000000000000000000000000000000000000000001555555500101c3300000000000000000000000000000000000000000000000000000000
% 00000000000000000000000000000000000000000000000000000000000000000000000000601e1c00000000000000000000000000000000000000000000000000000000
% 00000000000000000000000000000000000000000000000000000000000000000155555401001b1000000000000000000000000000000000000000000000000000000000
% 00000000000000000000000000000000000000000000000000000000000000000008080007001fc000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000555400400088000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000003038080000000000000000000000000000000000000000000000000000000000
% 000000000000000000000000000000000000000000000000000000000000000000000000c0c0080000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000018088000000000000000000000000000000000000000000000000000000000000
% 00000000000000000000000000000000000000000000000000000000000000000000000408fe000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000183046000000000000000000000000000000000000000000000000000000000000
% 000000000000000000000000000000000000000000000000000000000000000000000010600c000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000c0c678000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000001045800000000000000000000000000000000000000000000000000000000000000
% 000000000000000000000000000000000000000000000000000000000000000000000e063100000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000018063600000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000060471c00000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000040e59000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000324768000000000000000000000000000000000000000000000000000000000000000
% 00000000000000000000000000000000000000000000000000000000000000000004182e8000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000c30360000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000500000000000000000000000001066100000000000000000000000000000000000000000000000000000000000000000
% 000000000000000000000000000000000000000000000000000000000000000000612c000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000001540000000000000000000000018610800000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000880000000000000000000000031c1b000000000000000000000000000000000000000000000000000000000000000000
% 000000000000000000000000000000000000000555000000000000000000000004360c000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000180208000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000015554000000000000000000000400300000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000008880000000000000000000000c38180000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000005555000000000000000000001040080000000000000000000000000000000000000000000000000000000000000000000
% 00000000000000000000000000000000000000000000000000000000000000060ce000000000000000000000000000000000000000000000000000000000000000000000
% 000000000000000000000000000000000000000155540000000000000000000c6fa000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000888800000000000000000030642000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000555500000000000000000040606000000000000000000000000000000000000000000000000000000000000000000000
% 000000000000000000000000000000000000000000000000000000000000018763c000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000155500000000000000000103e00000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000080800000000000000000c00600000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000055540000000000000001070300000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000006080100000000000000000000000000000000000000000000000000000000000000000000000
% 000000000000000000000000000000000000000005555000000000000000c19c000000000000000000000000000000000000000000000000000000000000000000000000
% 00000000000000000000000000000000000000000088880000000000000181f4000000000000000000000000000000000000000000000000000000000000000000000000
% 00000000000000000000000000000000000000000155540000000000000000c4000000000000000000000000000000000000000000000000000000000000000000000000
% 00000000000000000000000000000000000000000000000000000000000c200c000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000005555000000000000186070000000000000000000000000000000000000000000000000000000000000000000000000
% 000000000000000000000000000000000000000000088800000000000031c000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000001555400000000000434000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000001826000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000555500000000001083000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000088880000000006101000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000155540000000000621000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000030460000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000055540000000040680000000000000000000000000000000000000000000000000000000000000000000000000000
% 00000000000000000000000000000000000000000000080800000000c0318000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000015550000000100120000000000000000000000000000000000000000000000000000000000000000000000000000
% 00000000000000000000000000000000000000000000000000000006100c0000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000015554000000c60080000000000000000000000000000000000000000000000000000000000000000000000000000
% 00000000000000000000000000000000000000000000088880000018c4000000000000000000000000000000000000000000000000000000000000000000000000000000
% 000000000000000000000000000000000000000000000555500000018c000000000000000000000000000000000000000000000000000000000000000000000000000000
% 000000000000000000000000000000000000000000000000000000c0d1000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000001555400010063000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000088800030c24000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000555500040418000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000180610000000000000000000000000000000000000000000000000000000000000000000000000000000
% 000000000000000000000000000000000000000000000015554010c300000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000088880606100000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000055500003100000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000001061e00000000000000000000000000000000000000000000000000000000000000000000000000000000
% 00000000000000000000000000000000000000000000000154001f9c00000000000000000000000000000000000000000000000000000000000000000000000000000000
% 000000000000000000000000000000000000000000000000080c30c000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 000000000000000000000000000000000000000000000000501030c000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 000000000000000000000000000000000000000000000000003021e000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000041b08000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 00000000000000000000000000000000000000000000000000c0df0000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 00000000000000000000000000000000000000000000000001004e0000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000318200000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000430300000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000878100000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 000000000000000000000000000000000000000000000000100c000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000002006000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 000000000000000000000000000000000000000000000000c402000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000018f02000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 00000000000000000000000000000000000000000000000107c0000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 00000000000000000000000000000000000000000000000606f0000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 00000000000000000000000000000000000000000000000c0700000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000188300000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 000000000000000000000000000000000000000000000010c300000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 000000000000000000000000000000000000000000000060a100000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000805000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 00000000000000000000000000000000000000000000010e4800000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 000000000000000000000000000000000000000000000007a000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 000000000000000000000000000000000000000000000c02e000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000018632000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000030f18000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000041908000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 00000000000000000000000000000000000000000000c33c0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000083660000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000101c00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000018c00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 000000000000000000000000000000000000000000047c600000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 00000000000000000000000000000000000000000008c6200000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000001082000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000001082000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000006086000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 000000000000000000000000000000000000000000c4fc000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000018870000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000011000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000063300000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 00000000000000000000150000000000000000000c3400000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000008080000000000000000181c00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000155540000000000000000118c00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 000000000000000000000000000000000000000060c600000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000555554000000000000000c06200000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 00000000000000000008888880000000000000018f3000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 00000000000000000015555550000000000000011ff800000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000002260000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000001555555000000000000004330000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000808080800000000000008198000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 00000000000000000055555550000000000000100c8000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000020060000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000015540555400000000000040000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 00000000000000000088800888000000000000c6000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000055500155500000000000103000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000301800000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 000000000000000005550005550000000000043cc00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000080800008800000000000c7fc00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000155400055501000000000010000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000001108000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000555000055555400000001304000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000888000008888800000006202000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000001554000015555500000004440000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000008688000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000005550000015555550000010310000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 00000000000000000800000008080800000201a0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 00000000000000055500000555555540000400c0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 00000000000000000000000000000000000c0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000015554000155555555500188000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000008888000088888888880118000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000015555000155505555540033000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000422000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000005555400555001555540434c00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000880880088000880881818800000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 000000000000000155554155400055550100d000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000002306000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000155555550000055404180000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 000000000000000008888888000000880c0c0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 00000000000000000555555500000154101b0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000030910000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000015555540000000000600000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000808080000000043300000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 000000000000000000555554000000000e180000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000188400000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000555540000000118400000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000088888000000610400000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000155554000000418c00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 000000000000000000000000000000080f800000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 00000000000000000000555550000018c7000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 00000000000000000000080888000011e0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000005555400000330000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 000000000000000000000000000000623c000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 000000000000000000000155554000c644000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000888880008380000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 00000000000000000000005555500100c0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000031060000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000055554003000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000808046400000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000015554044c00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 000000000000000000000000000018c900000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000005550107300000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000880201a00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000001540430c00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000418000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 000000000000000000000000014080c000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 000000000000000000000000000181f000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 00000000000000000000000000011b1000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 00000000000000000000000000020e0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000004030000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 000000000000000000000000000c218000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000e00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 00000000000000000000000000118c0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000011040000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000021040000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 00000000000000000000000000418c0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 00000000000000000000000000c8f80000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000188700000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000119000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000032000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000636400000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 000000000000000000000000041cc00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000806800000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000001003000000000000003f802601c0100201c00803e0100e00cc00000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000001080000000000000003f80260160100203400c0080101300cc00000000000000000000000000000000000000000000000000000000000000
% 00000000000000000000000001c00000000000000039c0260120100202600c0080103300ec00000000000000000000000000000000000000000000000000000000000000
% 00000000000000000000000023700000000000000038c0260120100204001c0080102100ac00000000000000000000000000000000000000000000000000000000000000
% 000000000000000000000000467c0000000000000039c02601e010020400140080102100ac00000000000000000000000000000000000000000000000000000000000000
% 000000000000000000000000c640000000000000003f802601e010020400160080102100bc00000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000380000000000000003e00260120100204201e00801021009c00000000000000000000000000000000000000000000000000000000000000
% 00000000000000000000000100c0000000000000003800260120100202601200801031009c00000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000010060000000000000003800240120100203403200801013008c00000000000000000000000000000000000000000000000000000000000000
% 00000000000000000000000200000000000000000038003c01e01c020180230080100e008c00000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000044000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000044000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 000000000000000000000000c800000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000199200000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 000000000000000000000011b200000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 000000000000000000000031e400000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000006c00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000401800000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000c00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 00000000000000000000008e0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 000000000000000000000119800000000000000000103301f00f00f00cc03c00000000000000000000000000000000000000000000000000000000000000000000000000
% 000000000000000000000130800000000000000000103300400800900cc02000000000000000000000000000000000000000000000000000000000000000000000000000
% 000000000000000000000020c00000000000000000103b00400800980ec02000000000000000000000000000000000000000000000000000000000000000000000000000
% 000000000000000000000618800000000000000000102b00400800980ac02000000000000000000000000000000000000000000000000000000000000000000000000000
% 00000000000000000000040d800000000000000000102b00400f00900ac03c00000000000000000000000000000000000000000000000000000000000000000000000000
% 000000000000000000000c03000000000000000000102f00400f00f00bc03c00000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000008000000000000000000001027004008009009c02000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000010000000000000000000001027004008009809c02000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000011000000000000000000001023004008009808c02000000000000000000000000000000000000000000000000000000000000000000000000000
% 000000000000000000002200000000000000000000102300400f009808c03c00000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000047000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000045800000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 004000000000000000000ce00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000180300000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0154000000000000000110000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 008880000000000000020c000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0155400000000000000007000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000401800000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0555550000000000000441000000000000000000000003800000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0008080000000000000871000000000000000000000006800000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 055555500000000000001f000000000000000000003044800000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 000000000000000000100e000000000000000000003844800000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0555555500000000001300000000000000000000003c43800000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0088888880000000002200000000000000000000003c40000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0055555550000000000600000000000000000000003640000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000004580000000000000000000003340000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 00055555550000000048e0000000000000000000003340000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 00008808880000000080300000000000000000000031c0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 00005555555000000000000000000000000000000030c0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000010c000000000000000000000030c0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000055555550000010300000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 00000088888880000231c0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000005555555000002000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000046000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000555555500047800000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000008080800088e00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000055555550008200000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000100000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000001555550110000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000888888232000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000155550447000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000449000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000015540c59000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000008800832000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 000000000000154100e000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000001300000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 00000000000001011c0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000002060000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000004018000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 00000000000000047f0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 000000000000000cc00000000000000000000000001c00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000008300000000000000000000000003fe0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 00000000000000100c0000000000000000000000001555000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000001c00000000000000000000000003ffff80000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000700000000000000000000000001dddddc000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 00000000000000001c0000000000000000000000003ffffffe00000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000001555555550000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000003fffffffff800000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000001ddd5ddd5dd80000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000003fffffffffffc000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000001555555555555400000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000003ffffffffffffff0000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000001ddddddddddddddd800000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000003ffffffffffffffffc0000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000001555555555555555554000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000003fffffffffffffffffff00000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000001d5d5d5d5d5d5d5d5d5d58000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000003fffffffffffffffffffffc00000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000001555555555555555555555540000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000003ffffffffffffffffffffffff000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000001ddddddddddddddddddddddddd80000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000003ffffffffffffffffffffffffffc000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000001555555555555555555555555555400000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000003fffffffffffffffffffffffffffff0000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000001ddd5ddd5ddd5ddd5ddd5ddd5ddd5dd000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000003fffffffffffffffffffffffffffffff80000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000001555555555555555555555555555555554000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000003fffffffffffffffffffffffffffffffffe00000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000001ddddddddddddddddddddddddddddddddddd0000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000003ffffffffffffffffffffffffffffffffffff800000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000001555555555555555555555555555555555555540000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000003ffffffffffffffffffffffffffffffffffffffe000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000001d5d5d5d5d5d5d5d5d5d5d5d5d5d5d5d5d5d5d5d500000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000003fffffffffffffffffffffffffffffffffffffffff8000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000001555555555555555555555555555555555555555555400000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000003fffffffffffffffffffffffffffffffffffffffffffe0000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000001ddddddddddddddddddddddddddddddddddddddddddddd000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000003ffffffffffffffffffffffffffffffffffffffffffffff80000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000001555555555555555555555555555555555555555555555554000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000003ffffffffffffffffffffffffffffffffffffffffffffffffe00000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000001ddd5ddd5ddd5ddd5ddd5ddd5ddd5ddd5ddd5ddd5ddd5ddd5c00000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000003fffffffffffffffffffffffffffffffffffffffffffffffc000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000001555555555555555555555555555555555555555555555500000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000003fffffffffffffffffffffffffffffffffffffffffffff000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000001dddddddddddddddddddddddddddddddddddddddddddc0000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000003ffffffffffffffffffffffffffffffffffffffffffc00000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000001555555555555555555555555555555555555555550000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000003ffffffffffffffffffffffffffffffffffffffff00000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000001d5d5d5d5d5d5d5d5d5d5d5d5d5d5d5d5d5d5d5c000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000003fffffffffffffffffffffffffffffffffffffc0000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000001555555555555555555555555555555555555000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000003fffffffffffffffffffffffffffffffffff0000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000001dddddddddddddddddddddddddddddddddc00000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000003ffffffffffffffffffffffffffffffffc000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000001555555555555555555555555555555500000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000003ffffffffffffffffffffffffffffff000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000001ddd5ddd5ddd5ddd5ddd5ddd5ddd5d0000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000003fffffffffffffffffffffffffffe00000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000001555555555555555555555555554000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000003fffffffffffffffffffffffff80000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000001dddddddddddddddddddddddd000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000003ffffffffffffffffffffffe0000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000001555555555555555555555400000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000003ffffffffffffffffffff8000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000001d5d5d5d5d5d5d5d5d5d00000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000003fffffffffffffffffe000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000001555555555555555540000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000003fffffffffffffff800000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000001dddddddddddddd0000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000003ffffffffffffe00000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000001555555555554000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000003ffffffffff80000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000001ddd5ddd5d800000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000003ffffffff0000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000001555555400000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000003fffffc000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000001dddd80000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000003fff000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000001540000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000003c00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% e000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% b800000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 8000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% f800000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% a800000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% f800000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% b800000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% a800000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% f800000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% f800000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% a800000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% f800000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% b800000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% a800000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% f800000000000000000000000000000000000000060000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 000000000000000000000000000000000000000007f000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 000000000000000000000000000000000000000007ffc0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% b80000000000000000000000000000000000000007fffe000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% a80000000000000000000000000000000000000007fffff00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% f80000000000000000000000000000000000000007ffffffc00000e01ff001c01f8000e00000000000000000000000000000000000000000000000000000000000000000
% 000000000000000000000000000000000000000007fffff0000000e01ff001c03fc001f00000000000000000000000000000000000000000000000000000000000000000
% 000000000000000000000000000000000000000007fffe00000000e01c3801c039e001f00000000000000000000000000000000000000000000000000000000000000000
% f80000000000000000000000000000000000000007ffc000000000e01c3801c030e001f00000000000000000000000000000000000000000000000000000000000000000
% 400000000000000000000000000000000000000007f00000000000e01c3801c0380003b80000000000000000000000000000000000000000000000000000000000000000
% 000000000000000000000000000000000000000006000000000000e01c7001c03f0003b80000000000000000000000000000000000000000000000000000000000000000
% 000000000000000000000000000000000000000000000000000000e01fe001c01fc003b80000000000000000000000000000000000000000000000000000000000000000
% 000000000000000000000000000000000000000000000000000000e01ff001c003e0071c0000000000000000000000000000000000000000000000000000000000000000
% f80000000000000000000000000000000000000000000d00000000e01c7001c000e007fc0000000000000000000000000000000000000000000000000000000000000000
% 400000000000000000000000000000000000000000000ffc000000e01c7001c070e007fc0000000000000000000000000000000000000000000000000000000000000000
% 000000000000000000000000000000000000000000000555400000e01c7001c039e0070c0000000000000000000000000000000000000000000000000000000000000000
% 000000000000000000000000000000000000000000000fffff8000e01c7001c03fe00e0e0000000000000000000000000000000000000000000000000000000000000000
% 000000000000000000000000000000000000000000000ddddddc00e01c3801c01fc00e0e0000000000000000000000000000000000000000000000000000000000000000
% 000000000000000000000000000000000000000000000ffffffc000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 1800000000000000000000000000000000000000000005555500000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 700000000000000000000000000000000000000000000fffe000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% c00000000000000000000000000000000000000000000d5c0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% f80000000000000000000000000000000000000000000f000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% b800000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% a800000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% e800000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% d800000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% b800000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% a800000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% e800000000000000000a3324a0f106149093d2192501240b20c82142001dce2712418c21e0a4248680212630a40000000000000000000000000000000000000000000000
% d80000000000000000113364a0810714909212192501240920c8214200150a651241ce210114248300212639140000000000000000000000000000000000000000000000
% 000000000000000000103be7a07105139ef1d21d3de1078f3ce8217a000d4aa11e794a3ce107a0f3003de729078000000000000000000000000000000000000000000000
% 000000000000000000197ae43491a5931092523d2501240921ed214340154ae612416b212194248380212f2d940000000000000000000000000000000000000000000000
% f800000000000000000e4aa41cf0e4931e83d22521e1e78f3d273d79c01dce271079293de0e7bcf680210924e78000000000000000000000000000000000000000000000

% PROGRAMME POSTSCRIPT POUR IMPRIMER COUVERTURE PI IRISA

%Fontes avec accents

/dictlocal 20 dict def 
/Reencode { dictlocal begin
/Nouveauvect exch def
/Nomnouvellepolice exch def
/Nompolicedebase exch def
/Policedebasedict Nompolicedebase findfont def
/Nouveaudict Policedebasedict maxlength dict def

Policedebasedict
{ exch dup /FID ne
{dup /Encoding eq
{exch dup length array copy Nouveaudict 3 1 roll put }
{exch Nouveaudict 3 1 roll put } ifelse }
{ pop pop} ifelse } forall

Nouveaudict /FontName Nomnouvellepolice put

Nouveauvect aload pop
Nouveauvect length 2 idiv {Nouveaudict /Encoding get 3 1 roll put} repeat

Nomnouvellepolice Nouveaudict definefont pop end } def %dictlocal

/CMPvect [
128 /Adieresis
130 /Ccedilla
131 /Eacute
133 /Odieresis
136 /agrave
137 /acircumflex
138 /adieresis
141 /ccedilla
142 /eacute
143 /egrave
144 /ecircumflex
145 /edieresis
148 /icircumflex
149 /idieresis
153 /ocircumflex
154 /odieresis
157 /ugrave
158 /ucircumflex
159 /udieresis
229 /Acircumflex
230 /Ecircumflex
231 /Agrave
232 /Edieresis
233 /Egrave
234 /Eacute
235 /Icircumflex
236 /Idieresis
239 /Ocircumflex
243 /Ucircumflex
244 /Ugrave
] def

/Helvetica /F-Helvetica CMPvect Reencode
/Helvetica-Bold /F-Helvetica-Bold CMPvect Reencode


/pi 3.1415923 def
/strl ( ) def
/spiral {
 gsave
 /rad exch def
 /ptsize exch def
 /str exch def
 /xrad rad ptsize 4 div add def

155 rotate

str {
    % chaine
    /charcode exch def
    ( ) dup 0 charcode put placechar
    } forall
    grestore
} def

/placechar {
   /char exch def
   /angle char stringang def
   gsave
      angle 2 div neg rotate
      rad 0 translate
      -90 rotate
       char stringwidth pop 2 div neg 0 moveto
      char show
   grestore
   angle neg rotate
} def
/stringang {
   stringwidth pop
   2 xrad mul pi mul
  div 360 mul    
} def

gsave

660 190 translate
gsave
0.1 0.1 1 setrgbcolor
0 0 moveto
0 0 585 90 155 arc stroke
10 setlinewidth
0 0 580 0 110 arc stroke
grestore

0.7 setgray
/F-Helvetica-Bold findfont 90 scalefont setfont
(I   R   I   S   A) 90 590 spiral

0 setgray 
/F-Helvetica findfont [12 0 0 10 0 0] makefont setfont
(INSTITUT DE RECHERCHE EN INFORMATIQUE ET SYST\351MES AL\352ATOIRES) 
12 575  spiral
grestore

gsave
240 800 translate
0.7 setgray
newpath
0 0 moveto
0 100 lineto 233 50 lineto closepath fill
grestore

gsave
0 setgray
/F-Helvetica-Bold findfont [15 0 0 15 0 0] makefont setfont
240 500 translate 
0 0  moveto
(P) show
15 0 moveto
/F-Helvetica findfont [10 0 0 15 0 0] makefont setfont
(U  B  L  I  C  A  T  I  O  N) show
0 20 neg translate
0 0 moveto
(I  N  T  E  R  N  E) show
0 20 neg translate
/F-Helvetica findfont 15 scalefont setfont
0 0 moveto (N) show
/F-Helvetica findfont 10 scalefont setfont
11 7 moveto (o) show
0 100 neg translate
0.1 0.1 1 setrgbcolor
newpath   
0 0 moveto
0 80 lineto 200 40 lineto closepath fill    
grestore

gsave
250 30 translate
gsave
0.1 0.1 1 setrgbcolor
newpath
0 0 moveto
0 10 lineto 30 5 lineto closepath fill
grestore
35 5 translate
/F-Helvetica-Bold findfont 20 scalefont setfont
0 0 moveto
(I R I S A) show
50 neg 7.5 translate
0 0 moveto
0 10 lineto 30 5 lineto closepath fill
/F-Helvetica findfont 8 scalefont setfont
90 neg 25 neg moveto
(CAMPUS UNIVERSITAIRE DE BEAULIEU - 35042 RENNES CEDEX - FRANCE) show
gsave
160 neg 25 neg translate 90 rotate
0 0 moveto (ISSN 1166-8687) show
gsave

%%EndDocument
 @endspecial 0 605 a @beginspecial @setspecial
 gsave 150 215 neg translate 0 0 moveto /Helvetica findfont 15 scalefont
setfont (1094) show grestore
 
@endspecial
209 3689 a Fw(F)-10 b(AST)-15 b(,)35 b(OPTIMIZED)e(SUN)i(RPC)f(USING)g
(A)-6 b(UT)h(OMA)-15 b(TIC)34 b(PR)n(OGRAM)1449 3855
y(SPECIALIZA)-15 b(TION)355 4187 y(GILLES)35 b(MULLER,)f(RENA)-6
b(UD)34 b(MARLET)-15 b(,)35 b(EUGEN-NICOLAE)111 4353
y(V)-5 b(OLANSCHI,)34 b(CHARLES)g(CONSEL,)h(CAL)-14 b(T)-5
b(ON)35 b(PU)f(&)h(ASHVIN)f(GOEL)p eop
%%Page: 0 2
0 1 bop eop
%%Page: 1 3
1 2 bop 21 425 a @beginspecial 122 @llx 274 @lly 605
@urx 359 @ury 1559 @rwi @setspecial
%%BeginDocument: Logo-IRISA.epsi
% c0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% fe000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% fff00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% ffffc000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% fffffe00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% fffffff8000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% ffffffffc00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% ffffffffff0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% fffffffffff800000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% ffffffffffffc0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% ffffffffffffff000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% fffffffffffffff80000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% ffffffffffffffffe000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% ffffffffffffffffff00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% fffffffffffffffffff8000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% ffffffffffffffffffffe00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% ffffffffffffffffffffff0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% fffffffffffffffffffffffc00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% ffffffffffffffffffffffffe0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% ffffffffffffffffffffffffff800000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% fffffffffffffffffffffffffffc000000000000000000000fff00000000007ffffe0000000000003ffc000000000003fff00000000000001fff800000
% ffffffffffffffffffffffffff00000000000000000000000fff00000000007ffffff800000000003ffc00000000001ffffe0000000000003fff800000
% ffffffffffffffffffffffffe000000000000000000000000fff00000000007ffffffc00000000003ffc00000000007fffff8000000000003fff800000
% fffffffffffffffffffffff80000000000000000000000000fff00000000007ffffffe00000000003ffc0000000001fffffff000000000003fffc00000
% ffffffffffffffffffffff000000000000000000000000000fff00000000007fffffff80000000003ffc0000000003fffffff000000000007fffc00000
% ffffffffffffffffffffc0000000000000000000000000000fff00000000007fffffffc0000000003ffc0000000003fffffff000000000007fffe00000
% fffffffffffffffffff800000000000000000000000000000fff00000000007fffffffe0000000003ffc0000000007fffffff00000000000ffffe00000
% ffffffffffffffffff0000000000000000000000000000000fff00000000007fffffffe0000000003ffc000000000ffffffff00000000000ffffe00000
% ffffffffffffffffc00000000000000000000000000000000fff00000000007ffffffff0000000003ffc000000000ffff1fff00000000000fffff00000
% fffffffffffffff8000000000000000000000000000000000fff00000000007ff807fff0000000003ffc000000001fff0007f00000000001fffff00000
% fffffffffffffe00000000000000000000000000000000000fff00000000007ff801fff0000000003ffc000000001fff0001f00000000001fffff80000
% ffffffffffffc000000000000000000000000000000000000fff00000000007ff800fff8000000003ffc000000001ffe0000700000000003fffff80000
% fffffffffff00000000000000000000000000000000000000fff00000000007ff800fff8000000003ffc000000001ffe0000000000000003ffbffc0000
% fffffffffe000000000000000000000000000000000000000fff00000000007ff8007ff8000000003ffc000000001fff0000000000000007ffbffc0000
% ffffffff80000000000000000000000000000000000000000fff00000000007ff800fff8000000003ffc000000001fff8000000000000007ff9ffe0000
% fffffff000000000000000000000000000000000000000000fff00000000007ff800fff0000000003ffc000000001fffc000000000000007ff1ffe0000
% fffffe0000000000000000000000000000000000000000000fff00000000007ff800fff0000000003ffc000000001ffff00000000000000fff0fff0000
% ffff800000000000000000000000000000000000000000000fff00000000007ff801fff0000000003ffc000000000ffffe0000000000000fff0fff0000
% fff0000000000000000000000000000000000000000000000fff00000000007ff807fff0000000003ffc000000000fffff8000000000001ffe07ff0000
% fc00000000000000000000000000000000000000000000000fff00000000007fffffffe0000000003ffc0000000007fffff000000000001ffe07ff8000
% 8000000000000000000000000000000000000000000000000fff00000000007fffffffc0000000003ffc0000000007fffff800000000001ffe07ff8000
% 0000000000000000000000000000000000000000000000000fff00000000007fffffff80000000003ffc0000000003fffffc00000000003ffc03ffc000
% 0000000000000000000000000000000000000000000000000fff00000000007fffffff00000000003ffc0000000001ffffff00000000003ffc03ffc000
% 0000000000000000000000000000000000000000000000000fff00000000007ffffffe00000000003ffc00000000007fffffc0000000003ff801ffe000
% 0000000000000000000000000000000000000000000000000fff00000000007ffffffc00000000003ffc00000000001fffffe0000000007ff801ffe000
% 0000000000000000000000000000000000000000000000000fff00000000007ffffffc00000000003ffc00000000000ffffff0000000007ff801ffe000
% 00000000000003a0000000000000000000000000000000000fff00000000007ffffffe00000000003ffc000000000003fffff000000000fff000fff000
% 0000000000000155000000000000000000000000000000000fff00000000007fffffff80000000003ffc000000000000fffff800000000fff000fff000
% 00000000000002eeec0000000000000000000000000000000fff00000000007ff81fff80000000003ffc0000000000001ffff800000000fff0007ff800
% 0000000000000155554000000000000000000000000000000fff00000000007ff80fffc0000000003ffc00000000000007fff800000001fffffffff800
% 00000000000003fbfbfb80000000000000000000000000000fff00000000007ff807ffc0000000003ffc00000000000001fffc00000001fffffffffc00
% 0000000000000155555554000000000000000000000000000fff00000000007ff803ffe0000000003ffc00000000000000fffc00000003fffffffffc00
% 00000000000002eeeeeeeee00000000000000000000000000fff00000000007ff803ffe0000000003ffc000000000800007ffc00000003fffffffffe00
% 0000000000000155555555550000000000000000000000000fff00000000007ff801fff0000000003ffc000000000c00003ffc00000007fffffffffe00
% 00000000000003ffbfffbfffbc00000000000000000000000fff00000000007ff800fff0000000003ffc000000000f00007ff800000007fffffffffe00
% 0000000000000155555555555550000000000000000000000fff00000000007ff800fff8000000003ffc000000000fc0007ff800000007ffffffffff00
% 00000000000002eeeeeeeeeeeeee800000000000000000000fff00000000007ff800fff8000000003ffc000000000ff000fff80000000fffffffffff00
% 0000000000000155555555555555540000000000000000000fff00000000007ff8007ffc000000003ffc000000000fff03fff80000000fff000007ff80
% 00000000000003fbfbfbfbfbfbfbfbf000000000000000000fff00000000007ff8007ffc000000003ffc000000000ffffffff80000001fff000007ff80
% 0000000000000155555555555555555500000000000000000fff00000000007ff8003ffe000000003ffc000000000ffffffff00000001ffe000007ffc0
% 00000000000002eeeeeeeeeeeeeeeeeeee000000000000000fff00000000007ff8003ffe000000003ffc000000000fffffffe00000001ffe000003ffc0
% 0000000000000155555555555555555555500000000000000fff00000000007ff8001fff000000003ffc000000000fffffffc00000003ffe000003ffe0
% 00000000000003bfffbfffbfffbfffbfffbfc000000000000fff00000000007ff8001fff000000003ffc0000000007ffffff800000003ffc000003ffe0
% 0000000000000155555555555555555555555400000000000fff00000000007ff8000fff000000003ffc0000000001fffffe000000007ffc000001ffe0
% 00000000000002eeeeeeeeeeeeeeeeeeeeeeeee8000000000fff00000000007ff8000fff800000003ffc00000000007ffffc000000007ffc000001fff0
% 0000000000000155555555555555555555555555400000000fff00000000007ff8000fff800000003ffc000000000007fff0000000007ff8000000fff0
% 00000000000003fbfbfbfbfbfbfbfbfbfbfbfbfb0000000000000000000000000000000000000000000000000000000018000000000000000000000000
% 00000000000001555555555555555555555555400000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 00000000000002eeeeeeeeeeeeeeeeeeeeeee8000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 00000000000001555555555555555555555500000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 00000000000003ffbfffbfffbfffbfffbfc000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 00000000000001555555555555555555500000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 00000000000002eeeeeeeeeeeeeeeeee000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 00000000000001555555555555555540000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 00000000000003fbfbfbfbfbfbfbf000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 00000000000001555555555555540000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 00000000000002eeeeeeeeeeeec00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 00000000000001555555555550000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 00000000000003bfffbfffbe00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 00000000000001555555550000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 00000000000002eeeeeee00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 00000000000001555554000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 00000000000003fbfb80000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 00000000000001554000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 00000000000002ec0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 00000000000001000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
%AI3_ColorUsage: Color
%AI3_TemplateBox: 156.25 24.1875 156.25 24.1875
%AI3_TileBox: -234.25 -244.8125 546.75 293.1875
%AI3_DocumentPreview: Header
userdict /Adobe_packedarray 5 dict dup begin put
/initialize			% - initialize -
{
/packedarray where
	{
	pop
	}
	{
	Adobe_packedarray begin
	Adobe_packedarray
		{
		dup xcheck
			{
			bind
			} if
		userdict 3 1 roll put
		} forall
	end
	} ifelse
} def
/terminate			% - terminate -
{
} def
/packedarray		% arguments count packedarray array
{
array astore readonly
} def
/setpacking			% boolean setpacking -
{
pop
} def
/currentpacking		% - setpacking boolean
{
false
} def
currentdict readonly pop end
Adobe_packedarray /initialize get exec
currentpacking true setpacking
userdict /Adobe_cmykcolor 4 dict dup begin put
/initialize			% - initialize -
{
/setcmykcolor where
	{
	pop
	}
	{
	userdict /Adobe_cmykcolor_vars 2 dict dup begin put
	/_setrgbcolor
		/setrgbcolor load def
	/_currentrgbcolor
		/currentrgbcolor load def
	Adobe_cmykcolor begin
	Adobe_cmykcolor
		{
		dup xcheck
			{
			bind
			} if
		pop pop
		} forall
	end
	end
	Adobe_cmykcolor begin
	} ifelse
} def
/terminate			% - terminate -
{
currentdict Adobe_cmykcolor eq
	{
	end
	} if
} def
/setcmykcolor		% cyan magenta yellow black setcmykcolor -
{
1 sub 4 1 roll
3
	{
	3 index add neg dup 0 lt
		{
		pop 0
		} if
	3 1 roll
	} repeat
Adobe_cmykcolor_vars /_setrgbcolor get exec
pop
} def 
/currentcmykcolor	% - currentcmykcolor cyan magenta yellow black
{
Adobe_cmykcolor_vars /_currentrgbcolor get exec
3
	{
	1 sub neg 3 1 roll
	} repeat
0
} def
currentdict readonly pop end
setpacking
currentpacking true setpacking
userdict /Adobe_cshow 3 dict dup begin put
/initialize			% - initialize -
{
/cshow where
	{
	pop
	}
	{
	userdict /Adobe_cshow_vars 1 dict dup begin put
	/_cshow		% - _cshow proc
		{} def
	Adobe_cshow begin
	Adobe_cshow
		{
		dup xcheck
			{
			bind
			} if
		userdict 3 1 roll put
		} forall
	end
	end
	} ifelse
} def
/terminate			% - terminate -
{
} def
/cshow				% proc string cshow -
{
exch
Adobe_cshow_vars
	exch /_cshow
	exch put
	{
	0 0 Adobe_cshow_vars /_cshow get exec
	} forall
} def
currentdict readonly pop end
setpacking
currentpacking true setpacking
userdict /Adobe_customcolor 5 dict dup begin put
/initialize			% - initialize -
{
/setcustomcolor where
	{
	pop
	}
	{
	Adobe_customcolor begin
	Adobe_customcolor
		{
		dup xcheck
			{
			bind
			} if
		pop pop
		} forall
	end
	Adobe_customcolor begin
	} ifelse
} def
/terminate			% - terminate -
{
currentdict Adobe_customcolor eq
	{
	end
	} if
} def
/findcmykcustomcolor	% cyan magenta yellow black name findcmykcustomcolor object
{
5 packedarray
}  def
/setcustomcolor		% object tint setcustomcolor -
{
exch
aload pop pop
4
	{
	4 index mul 4 1 roll
	} repeat
5 -1 roll pop
setcmykcolor
} def
/setoverprint		% boolean setoverprint -
{
pop
} def
currentdict readonly pop end
setpacking
currentpacking true setpacking
userdict /Adobe_IllustratorA_AI3 61 dict dup begin put
% initialization
/initialize				% - initialize -
{
% 47 vars, but leave slack of 10 entries for custom Postscript fragments
userdict /Adobe_IllustratorA_AI3_vars 57 dict dup begin put
% paint operands
/_lp /none def
/_pf {} def
/_ps {} def
/_psf {} def
/_pss {} def
/_pjsf {} def
/_pjss {} def
/_pola 0 def
/_doClip 0 def
% paint operators
/cf	currentflat def	% - cf flatness
% typography operands
/_tm matrix def
/_renderStart [/e0 /r0 /a0 /o0 /e1 /r1 /a1 /i0] def 
/_renderEnd [null null null null /i1 /i1 /i1 /i1] def
/_render -1 def
/_rise 0 def
/_ax 0 def			% x character spacing	(_ax, _ay, _cx, _cy follows awidthshow naming convention)
/_ay 0 def			% y character spacing
/_cx 0 def			% x word spacing
/_cy 0 def			% y word spacing
/_leading [0 0] def
/_ctm matrix def
/_mtx matrix def
/_sp 16#020 def
/_hyphen (-) def
/_fScl 0 def
/_cnt 0 def
/_hs 1 def
/_nativeEncoding 0 def
/_useNativeEncoding 0 def
/_tempEncode 0 def
/_pntr 0 def
/_tDict 2 dict def
% typography operators
/Tx {} def
/Tj {} def
% compound path operators
/CRender {} def
% printing
/_AI3_savepage {} def
% color operands
/_gf null def
/_cf 4 array def
/_if null def
/_of false def
/_fc {} def
/_gs null def
/_cs 4 array def
/_is null def
/_os false def
/_sc {} def
/_i null def
Adobe_IllustratorA_AI3 begin
Adobe_IllustratorA_AI3
	{
	dup xcheck
		{
		bind
		} if
	pop pop
	} forall
end
end
Adobe_IllustratorA_AI3 begin
Adobe_IllustratorA_AI3_vars begin
newpath
} def
/terminate				% - terminate -
{
end
end
} def
% definition operators
/_					% - _ null
null def
/ddef				% key value ddef -
{
Adobe_IllustratorA_AI3_vars 3 1 roll put
} def
/xput				% key value literal xput -
{
dup load dup length exch maxlength eq
	{
	dup dup load dup
	length 2 mul dict copy def
	} if
load begin def end
} def
/npop				% integer npop -
{
	{
	pop
	} repeat
} def
% marking operators
/sw					% ax ay string sw x y 
{
dup length exch stringwidth
exch 5 -1 roll 3 index 1 sub mul add
4 1 roll 3 1 roll 1 sub mul add
} def
/swj				% cx cy fillchar ax ay string swj x y
{
dup 4 1 roll
dup length exch stringwidth 
exch 5 -1 roll 3 index 1 sub mul add
4 1 roll 3 1 roll 1 sub mul add 
6 2 roll /_cnt 0 ddef
{1 index eq {/_cnt _cnt 1 add ddef} if} forall pop
exch _cnt mul exch _cnt mul 2 index add 4 1 roll 2 index add 4 1 roll pop pop
} def
/ss					% ax ay string matrix ss -
{
4 1 roll
	{				% matrix ax ay char 0 0 {proc} -
	2 npop 
	(0) exch 2 copy 0 exch put pop
	gsave
	false charpath currentpoint
	4 index setmatrix
	stroke
	grestore
	moveto
	2 copy rmoveto
	} exch cshow
3 npop
} def
/jss				% cx cy fillchar ax ay string matrix jss -
{
4 1 roll
	{				% cx cy fillchar matrix ax ay char 0 0 {proc} -   
	2 npop 
	(0) exch 2 copy 0 exch put 
	gsave
	_sp eq 
		{
		exch 6 index 6 index 6 index 5 -1 roll widthshow  
		currentpoint
		}
		{
		false charpath currentpoint
		4 index setmatrix stroke
		}ifelse
	grestore
	moveto
	2 copy rmoveto
	} exch cshow
6 npop
} def
% path operators
/sp					% ax ay string sp -
{
	{
	2 npop (0) exch
	2 copy 0 exch put pop
	false charpath
	2 copy rmoveto
	} exch cshow
2 npop
} def
/jsp					% cx cy fillchar ax ay string jsp -
{
	{					% cx cy fillchar ax ay char 0 0 {proc} -
	2 npop 
	(0) exch 2 copy 0 exch put 
	_sp eq 
		{
		exch 5 index 5 index 5 index 5 -1 roll widthshow  
		}
		{
		false charpath
		}ifelse
	2 copy rmoveto
	} exch cshow
5 npop
} def
% path construction operators
/pl				% x y pl x y
{
transform
0.25 sub round 0.25 add exch
0.25 sub round 0.25 add exch
itransform
} def
/setstrokeadjust where
	{
	pop true setstrokeadjust
	/c				% x1 y1 x2 y2 x3 y3 c -
	{
	curveto
	} def
	/C
	/c load def
	/v				% x2 y2 x3 y3 v -
	{
	currentpoint 6 2 roll curveto
	} def
	/V
	/v load def
	/y				% x1 y1 x2 y2 y -
	{
	2 copy curveto
	} def
	/Y
	/y load def
	/l				% x y l -
	{
	lineto
	} def
	/L
	/l load def
	/m				% x y m -
	{
	moveto
	} def
	}
	{%else
	/c
	{
	pl curveto
	} def
	/C
	/c load def
	/v
	{
	currentpoint 6 2 roll pl curveto
	} def
	/V
	/v load def
	/y
	{
	pl 2 copy curveto
	} def
	/Y
	/y load def
	/l
	{
	pl lineto
	} def
	/L
	/l load def
	/m
	{
	pl moveto
	} def
	}ifelse
% graphic state operators
/d					% array phase d -
{
setdash
} def
/cf	{} def			% - cf flatness
/i					% flatness i -
{
dup 0 eq
	{
	pop cf
	} if
setflat
} def
/j					% linejoin j -
{
setlinejoin
} def
/J					% linecap J -
{
setlinecap
} def
/M					% miterlimit M -
{
setmiterlimit
} def
/w					% linewidth w -
{
setlinewidth
} def
% path painting operators
/H					% - H -
{} def
/h					% - h -
{
closepath
} def
/N					% - N -
{
_pola 0 eq 
	{
	_doClip 1 eq {clip /_doClip 0 ddef} if 
	newpath
	} 
	{
	/CRender {N} ddef
	}ifelse
} def
/n					% - n -
{N} def
/F					% - F -
{
_pola 0 eq 
	{
	_doClip 1 eq 
		{
		gsave _pf grestore clip newpath /_lp /none ddef _fc 
		/_doClip 0 ddef
		}
		{
		_pf
		}ifelse
	} 
	{
	/CRender {F} ddef
	}ifelse
} def
/f					% - f -
{
closepath
F
} def
/S					% - S -
{
_pola 0 eq 
	{
	_doClip 1 eq 
		{
		gsave _ps grestore clip newpath /_lp /none ddef _sc 
		/_doClip 0 ddef
		}
		{
		_ps
		}ifelse
	} 
	{
	/CRender {S} ddef
	}ifelse
} def
/s					% - s -
{
closepath
S
} def
/B					% - B -
{
_pola 0 eq 
	{
	_doClip 1 eq 	% F clears _doClip
	gsave F grestore 
		{
		gsave S grestore clip newpath /_lp /none ddef _sc
		/_doClip 0 ddef
		} 
		{
		S
		}ifelse
	}
	{
	/CRender {B} ddef
	}ifelse
} def
/b					% - b -
{
closepath
B
} def
/W					% - W -
{
/_doClip 1 ddef
} def
/*					% - [string] * -
{
count 0 ne 
	{
	dup type (stringtype) eq {pop} if
	} if 
_pola 0 eq {newpath} if
} def
% group operators
/u					% - u -
{} def
/U					% - U -
{} def
/q					% - q -
{
_pola 0 eq {gsave} if
} def
/Q					% - Q -
{
_pola 0 eq {grestore} if
} def
/*u					% - *u -
{
_pola 1 add /_pola exch ddef
} def
/*U					% - *U -
{
_pola 1 sub /_pola exch ddef 
_pola 0 eq {CRender} if
} def
/D					% polarized D -
{pop} def
/*w					% - *w -
{} def
/*W					% - *W -
{} def
% place operators
/`					% matrix llx lly urx ury string ` -
{
/_i save ddef
6 1 roll 4 npop
concat pop
userdict begin
/showpage {} def
0 setgray
0 setlinecap
1 setlinewidth
0 setlinejoin
10 setmiterlimit
[] 0 setdash
newpath
0 setgray
false setoverprint
} def
/~					% - ~ -
{
end
_i restore
} def
% color operators
/O					% flag O -
{
0 ne
/_of exch ddef
/_lp /none ddef
} def
/R					% flag R -
{
0 ne
/_os exch ddef
/_lp /none ddef
} def
/g					% gray g -
{
/_gf exch ddef
/_fc
{ 
_lp /fill ne
	{
	_of setoverprint
	_gf setgray
	/_lp /fill ddef
	} if
} ddef
/_pf
{
_fc
fill
} ddef
/_psf
{
_fc
ashow
} ddef
/_pjsf
{
_fc
awidthshow
} ddef
/_lp /none ddef
} def
/G					% gray G -
{
/_gs exch ddef
/_sc
{
_lp /stroke ne
	{
	_os setoverprint
	_gs setgray
	/_lp /stroke ddef
	} if
} ddef
/_ps
{
_sc
stroke
} ddef
/_pss
{
_sc
ss
} ddef
/_pjss
{
_sc
jss
} ddef
/_lp /none ddef
} def
/k					% cyan magenta yellow black k -
{
_cf astore pop
/_fc
{
_lp /fill ne
	{
	_of setoverprint
	_cf aload pop setcmykcolor
	/_lp /fill ddef
	} if
} ddef
/_pf
{
_fc
fill
} ddef
/_psf
{
_fc
ashow
} ddef
/_pjsf
{
_fc
awidthshow
} ddef
/_lp /none ddef
} def
/K					% cyan magenta yellow black K -
{
_cs astore pop
/_sc
{
_lp /stroke ne
	{
	_os setoverprint
	_cs aload pop setcmykcolor
	/_lp /stroke ddef
	} if
} ddef
/_ps
{
_sc
stroke
} ddef
/_pss
{
_sc
ss
} ddef
/_pjss
{
_sc
jss
} ddef
/_lp /none ddef
} def
/x					% cyan magenta yellow black name gray x -
{
/_gf exch ddef
findcmykcustomcolor
/_if exch ddef
/_fc
{ 
_lp /fill ne
	{
	_of setoverprint
	_if _gf 1 exch sub setcustomcolor
	/_lp /fill ddef
	} if
} ddef
/_pf
{
_fc
fill
} ddef
/_psf
{
_fc
ashow
} ddef
/_pjsf
{
_fc
awidthshow
} ddef
/_lp /none ddef
} def
/X					% cyan magenta yellow black name gray X -
{
/_gs exch ddef
findcmykcustomcolor
/_is exch ddef
/_sc
{
_lp /stroke ne
	{
	_os setoverprint
	_is _gs 1 exch sub setcustomcolor
	/_lp /stroke ddef
	} if
} ddef
/_ps
{
_sc
stroke
} ddef
/_pss
{
_sc
ss
} ddef
/_pjss
{
_sc
jss
} ddef
/_lp /none ddef
} def
% locked object operator
/A					% value A -
{
pop
} def
currentdict readonly pop end
setpacking
% annotate page operator
/annotatepage
{
} def
%orig: [1 0 0 -1 -234.25 neg 293.1875] concat
[1 0 0 1 -234.25 neg 293.1875] concat
Adobe_cmykcolor /initialize get exec
Adobe_cshow /initialize get exec
Adobe_customcolor /initialize get exec
Adobe_IllustratorA_AI3 /initialize get exec
/_AI3_savepage save def
0 A
*u
0 O
0 g
0 i 0 J 0 j 1 w 4 M []0 d
%AI3_Note:
0 D
95.5746 0 m
84.27 0 L
84.27 45.3515 L
95.5746 45.3515 L
95.5746 0 l
f
*U
*u
157.6667 45.3515 m
166.9763 45.3515 172.4957 39.1007 172.4957 32.3179 c
172.4957 27.3306 169.9022 23.6067 164.7154 21.2128 c
169.3703 18.8854 170.7667 13.2996 177.1505 0 c
164.7154 0 L
159.8611 9.7087 158.0656 18.4199 151.9478 18.4199 c
148.6894 18.4199 L
148.6894 0 L
137.3848 0 L
137.3848 45.3515 L
157.6667 45.3515 l
f
1 D
148.6894 26.7321 m
154.6743 26.7321 L
157.7996 26.7321 160.8585 28.0621 160.8585 31.9189 c
160.8585 35.3103 158.6641 37.0393 154.4083 37.0393 c
148.6894 37.0393 L
148.6894 26.7321 l
f
*U
*u
0 D
221.2261 0 m
209.9215 0 L
209.9215 45.3515 L
221.2261 45.3515 L
221.2261 0 l
f
*U
*u
291.3664 33.5814 m
284.7831 36.5073 280.8598 37.6378 277.0029 37.6378 c
272.9465 37.6378 270.3531 36.1748 270.3531 33.9139 c
270.3531 27.0646 293.4278 28.993 293.4278 13.1666 c
293.4278 4.4553 286.1131 -0.5985 276.0054 -0.5985 c
268.0922 -0.5985 264.1688 1.4629 259.647 3.7904 c
259.647 13.5655 L
266.1637 9.2432 270.1536 7.7137 275.1409 7.7137 c
279.4633 7.7137 281.7907 9.2432 281.7907 11.9031 c
281.7907 19.3509 258.716 16.6244 258.716 32.9164 c
258.716 40.7631 265.4988 45.95 276.0054 45.95 c
281.0592 45.95 285.6476 44.886 291.3664 42.4256 C
291.3664 33.5814 l
f
*U
*u
372.0407 0 m
359.8717 0 L
356.1478 8.9772 L
335.8659 8.9772 L
332.4746 0 L
320.505 0 L
338.7918 45.3515 L
351.8919 45.3515 L
372.0407 0 l
f
1 D
345.5081 34.5124 m
338.8583 16.8904 L
352.8229 16.8904 L
345.5081 34.5124 l
f
*U
u
u
1 0.6 0 0.03 (PANTONE 286 CV) 0 x
0 D
-58.021 19.875 m
-58.021 -19.8125 l
52.5415 0 l
-58.021 19.875 l
f
U
u
0 g
-111.8554 65.2232 m
-111.8554 25.5357 l
-1.2929 45.3482 l
-111.8554 65.2232 l
f
U
U
_AI3_savepage restore
gsave annotatepage grestore showpage
Adobe_IllustratorA_AI3 /terminate get exec
Adobe_customcolor /terminate get exec
Adobe_cshow /terminate get exec
Adobe_cmykcolor /terminate get exec
Adobe_packedarray /terminate get exec
%%EndDocument
 @endspecial 1981 188 a Fv(I)p Fu(NSTITUT)15 b(DE)f Fv(R)p
Fu(ECHERCHE)h(EN)30 b Fv(I)p Fu(NFORMA)-6 b(TIQUE)15
b(ET)g Fv(S)p Fu(YST)3368 178 y(\036)3359 188 y(EMES)k
Fv(A)p Fu(L)3598 178 y(\264)3590 188 y(EA)-6 b(T)n(OIRES)2226
267 y Fv(Campus)19 b(de)f(Beaulieu)g(\226)g(35042)g(Rennes)h(Cede)n(x)f
(\226)h(F)m(r)o(ance)2258 346 y(T)2306 345 y(\264)2299
346 y(el.)k(:)g(\(33\))c(02)f(99)g(84)h(71)f(00)g(\226)h(F)m(ax)f(:)23
b(\(33\))18 b(02)h(99)f(84)g(71)h(71)3327 425 y(http://www)l(.ir)q
(isa.fr)235 1332 y Ft(F)m(ast,)29 b(Optimized)i(Sun)g(RPC)g(Using)f(A)
-6 b(utomatic)30 b(Pr)n(ogram)f(Specialization)73 1686
y Fs(Gilles)24 b(Muller)l(,)g(Renaud)h(Marlet,)f(Eugen-Nicolae)h(V)-13
b(olanschi,)24 b(Charles)h(Consel,)f(Calton)h(Pu)g(&)g(Ashvin)1853
1802 y(Goel)1507 2056 y Fr(Th)5 b(\036)-33 b(eme)20 b(2)g(\227)h(G)5
b(\264)-33 b(enie)20 b(logiciel)1606 2156 y(et)h(calcul)f(symbolique)
1408 2327 y(Projet)g(\(a)n(v)n(ant-projet\))d(COMPOSE)994
2581 y(Publication)i(interne)h(n)15 b(\011)h(1094)j(\227)h(21)g(mars)g
(1997)f(\227)i(19)f(pages)0 3081 y Fq(Abstract:)87 b
Fr(F)o(ast)30 b(remote)f(procedure)e(call)j(\(RPC\))g(is)h(a)f(major)e
(concern)g(for)h(distrib)n(uted)g(systems.)53 b(Man)o(y)28
b(studies)i(aimed)f(at)0 3180 y(ef)n(\002cient)21 b(RPC)j(consist)e(in)
f(either)h(ne)n(w)f(implementations)f(of)i(the)g(RPC)h(paradigm)d(or)h
(manual)g(optimization)f(of)i(critical)g(sections)0 3280
y(of)g(the)g(code.)29 b(This)22 b(paper)f(presents)g(an)h(e)o
(xperiment)e(that)i(achie)n(v)o(es)f Fp(automatic)g Fr(optimization)f
(of)h(an)h Fp(e)n(xisting)o(,)h(commer)m(cial)e Fr(RPC)0
3379 y(implementation,)16 b(namely)h(the)h(Sun)f(RPC.)i(The)f
(optimized)e(Sun)i(RPC)h(is)g(obtained)e(by)g(using)g(an)h(automatic)f
(program)f(specializer)-5 b(.)0 3479 y(It)26 b(runs)g(up)f(to)h(1.5)f
(times)i(f)o(aster)f(than)f(the)h(original)f(Sun)h(RPC.)h(Close)f(e)o
(xamination)e(of)i(the)g(specialized)f(code)g(does)h(not)f(re)n(v)o
(eal)0 3579 y(further)16 b(optimizations)g(opportunities)f(which)i(w)o
(ould)g(lead)g(to)h(signi\002cant)f(impro)o(v)o(ements)d(without)j
(major)g(manual)f(restructuring.)125 3750 y(The)22 b(contrib)n(utions)f
(of)h(this)h(w)o(ork)f(are:)30 b(\(1\))22 b(the)h(optimized)e(code)h
(is)i(safely)e(produced)e(by)j(an)f(automatic)g(tool)g(and)g(thus)h
(does)0 3849 y(not)k(entail)g(an)o(y)g(additional)f(maintenance;)j
(\(2\))d(to)i(the)f(best)h(of)f(our)f(kno)n(wledge)f(this)j(is)g(the)f
(\002rst)h(successful)f(specialization)g(of)0 3949 y(mature,)j
(commercial,)e(representati)n(v)o(e)f(system)i(code;)j(and)c(\(3\))g
(the)g(optimized)g(Sun)g(RPC)i(runs)e(signi\002cantly)g(f)o(aster)g
(than)h(the)0 4049 y(original)19 b(code.)125 4233 y(The)g(Sun)h(RPC)i
(e)o(xperiment)c(\002les,)j(including)d(the)j(specialized)e
(implementation,)f(are)i(publicly)f(a)n(v)n(ailable)3296
4203 y(*)3361 4233 y(.)0 4452 y Fq(K)n(ey-w)o(ords:)55
b Fr(partial)21 b(e)n(v)n(aluation,)e(RPC)k(protocol,)d(Sun)h(RPC,)i
(distrib)n(uted)d(systems,)i(generic)f(systems,)h(automatic)e
(optimisati-)0 4551 y(zation)3483 5030 y Fo(\(R)t(\264)-26
b(esum)t(\264)g(e)17 b(:)k(tsvp\))78 5235 y Fn(*)120
5259 y Fm(A)-5 b(v)n(ailable)20 b(upon)d(request)i(to)e(the)h(authors)g
(at)f Fl(muller@irisa.fr)1676 6100 y @beginspecial 203
@llx 292 @lly 517 @urx 432 @ury 283 @rwi @setspecial
%%BeginDocument: Logo-CNRS.epsi
% 00000000000000000000000000000000088000000000000000000000000000000000000000000000
% 00000000000000000000000000000000000000000000000000000000000000000000000000000000
% 000000000000000000000000000000000a8000000000000000000000000000000000000000000000
% 00000000000000000000000000000000000000000000000000000000000000000000000000000000
% 00000000000000000000000000000000088000000000000000000000000000000000000000000000
% 00000000000000000000000000000000000000000000000000000000000000000000000000000000
% 000000000000000000000000000000002a8000000000000000000000000000000000000000000000
% 00000000000000000000000000000000000000000000000000000000000000000000000000000000
% 000000100000000000000000000000000a8000000000000000000000000000000000000000000000
% 00000018000000000000000000000000000000000000000000000000000000000000000000000000
% 000002a80000000000000000000000002a0000000000000000000000000000000000000000000000
% 00001ffe000000000000000000000000000000000000000000000000000000000000000000000000
% 0003bbbb800000000180000000000000880000000000000000000000000000000000000000000000
% 000fffffc00000000380000000000000000000000000000000000000000000000000000000000000
% 000aaaaaa00000000280000000000000aa0000000000000000000000000000000000000000000000
% 003ffffff00000000fe0000000000000000000000000000000000000000000000000000000000000
% 00bbbbbbb00000001ba0000000000000880000000000000000000000000000000000000000000000
% 03ffffffe00000003ff0000000000000000000000000000000000000000000000000000000000000
% 02aeaaae800000002aa8000000000000a80000000000000000000000000000000000000000000000
% 07ffffff80000000fffc000000000000000000000000000000000000000000000000000000000000
% 03bbbbbb00000001bbb8000000000000880000000000000000000000000000000000000000000000
% 0ffffffe00ff0003fffe000000000000000000000000000000000000000000000000000000000000
% 0aaaa00800aa0000aaa00000002a8002a80000000000000000000000000000000000000000000000
% 1fffc01001ff8000fff0000000000000000000000000000000000000000000000000000000000000
% 3bbb800003bb8001bbb00000000a8002880000000000000000000000000000000000000000000000
% 7ffe000003ffc001fff0000000000000000000000000000000000000000000000000000000000000
% 2aa8000002aaa000aaa00000002a0002a00000000000000000000000000000000000000000000000
% 7ffc000007ffe003ffe0000000000000000000000000000000000000000000000000000000000000
% 3bb8000003bbb003bba0000000880008800000000000000000000000000000000000000000000000
% 7ff000000ffff803ffe0000000000000000000000000000000000000000000000000000000000000
% aaa000000aaaa802aa80000000aa000aa00000000000000000000000000000000000000000000000
% fff000001ffffc07ffc0000000000000000000000000000000000000000000000000000000000000
% bbb000001bbbb803bb800000008a000a800000000000000000000000000000000000000000000000
% fff000003ffffe07ff80000000000000000000000000000000000000000000000000000000000000
% aaa000002aaeaa0eaa80000000a8002a800000000000000000000000000000000000000000000000
% fff000007fffff8fff80000000000000000000000000000000000000000000000000000000000000
% bbb000003bbbbb8bbb80000000880008800000000000000000000000000000000000000000000000
% fff000007fffffdfff00000000000000000000000000000000000000000000000000000000000000
% aaa00000aaaaaa8aaa00000002a8002a800000000000000000000000000000000000000000000000
% 7ff00000ffffffffff00000000000000000000000000000000000000000000000000000000000000
% 3bb80001bbb3bbbbbb0000000288000a000000000000000000000000000000000000000000000000
% 7ffc0001fff7fffffe00000000000000000000000000000000000000000000000000000000000000
% 2aa80002aaa2aaaaaa00000002a00000000000000000000000000000000000000000000000000000
% 7ffe0003ffe1fffffe00000000000000000000000000000000000000000000000000000000000000
% 3bbb8003bb81bbbbba00000008800000000000000000000000000000000000000000000000000000
% 1fffc00fffc0fffffc00000000000040000000000000000000000000000000000000000000000000
% 0aaaa80aaa802aaaa8000000000000200000000a8aa2828aa2a82aa020a0002aa282a0a0a0202a00
% 0fffffffff807ffffc0000000000007000000020c410c011908c0820180038232104303000700800
% 03bbbbbbbb003bbbb80000000003bbb8000000200010a01180800820080028230108083800300800
% 07fffffffe003ffff8000000007ffffc0000004044006001808408000c0038030108081800700800
% 02aeaaaeaa000aaea800000000aeaaae000000800020200080880800020008020008080800880800
% 01fffffffc000ffff800000003ffffff000000c007e0380180f80fc007004c0301180c0e00980800
% 00bbbbbbb8000bbbb000000003bbbbbb800000800020180180b80800038088030118080301980800
% 003ffffff00007fffff000000fffffffe000004004000c01809808000180fe030108080301fc0800
% 000aaaaaa00002aaaaaa80000aaaaaaaa00000200000020080880800008082020008080080080800
% 0007ffff800003ffffffc0001fffffff80000030c4100601808e082000c1070301043001820e0820
% 0003bbbb800001bbbbbbb0003bbbbbbb0000000b8ba3820383a32ba0280383838383a0a0830b2ba0
% 00001fe0000001fffffff8007ffffffe000000000000000000000000000000000000000000000000
% 00000000000002aaaaaaa8002aaaaaa8000000000000000000000000000000000000000000000000
% 00000000000003fffffffc007ffe0078000000000000000000000000000000000000000000000000
% 00000000000003bbbbbbba00bbb80030000000000000000000000000000000000000000000000000
% 00000000000003ffffffff00fff00060000000000000000000000000000000000000000000000000
% 00000000000002aaaaaaaa00aaa0000002a800000000000000000000000000000000000000000000
% 00000000000007ffffffff00ffe00000000000000000000000000000000000000000000000000000
% 00000000000003bbbbbbbb00bba00000008800000000000000000000000000000000000000000000
% 00000000000007ff800fff00ffe00000000000000000000000000000000000000000000000000000
% 0000000000000aae8006aa80aaa0000002a800000000000000000000000000000000000000000000
% 0000000000000fff000fff00fff00000000000000000000000000000000000000000000000000000
% 0000000000000bbb000bbb00bbb80000008000bb0bb80b801000ba1bb03b3ab9bb3b803b39b3ba00
% 0000000000000fffffffff00fffc0000000000218208020038002304108308204108c08310408200
% 0000000000000aaaaaaaaa002aaa00000aa000208208020028002000008008200008008000008200
% 0000000000001ffffffffe007fffc000000000204200020038002104010108204008410110408000
% 0000000000001bbbbbbbba003bbbb0000a8000202200020008002300230008200208830000008000
% 0000000000003ffffffffe003ffff8000000002063f002004c003e07e3000fe07e0f83001fc0fc00
% 0000000000002aaaaaaaa8000aaaa8000aa000202200020088002a0022000820020a820000008000
% 0000000000003ffffffff80007fffc000000002042000200fe002604010008204009810010408000
% 0000000000003bbbbbbbb00003bbba00088000208200020082002300018108200008818110008000
% 0000000000007fffffffe00001fffe0000000021820802090700238410c308204108e0c310408200
% 0000000000002aaaaaaaa000002aaa002a8000aa0aa80aaa8280a88aa02a2aa8aa2a202a28a2aa00
% 0000000000007ffffffff000003fff00000000000000000000000000000000000000000000000000
% 0000000000003bbbbbbbb800000bbb80088000000000000000000000000000000000000000000000
% 000000000000fff001fffc000007ff80000000000000000000000000000000000000000000000000
% 000000000000aaa000aea8000006aa802a8000000000000000000000000000000000000000000000
% 000000000000fff000fffe000003ff80000000000000000000000000000000000000000000000000
% 000000000000bbb0003bba000003bb80080000000000000000000000000000000000000000000000
% 000000000001ffe0003fff000003ff80000000000000000000000000000000000000000000000000
% 000000000000aaa0002aaa000002aa80aa0000000000000000000000000000000000000000000000
% 000000000001ffe0001fff800007ff80000000000000000000000000000000000000000000000000
% 000000000001bb80001bbb80000bbb008a0000000000000000000000000000000000000000000000
% 000000000003ffc0000fffffffffff00000000000000000000000000000000000000000000000000
% 00000000000aaaa00002aaaaaaaaaa00a800002a0aa28aa2828aa2aaa282a0a8a2a8000000000000
% 00000000000fffe00007fffffffffe000000006210610410c0119084010430200104000000000000
% 000000000003bb800003bbbbbbbbba008800000330210010a0118080010818200100000000000000
% 000000000007ff800003fffffffffc00000000602021040060018084010808200100000000000000
% 000000000002aa000000aaaaaaaaa802a80000282000002020008080200808200008000000000000
% 000000000001fe000000fffffffff8000000003c600107e038018087e1180c2001f8000000000000
% 000000000000b80000003bbbbbbba0028800000a2001002008018080211808200108000000000000
% 000000000000f80000003fffffff800000000007200104000c018084010808200100000000000000
% 000000000000200000000aaeaaae0002a00000822020000002008080000808208000000000000000
% 0000000000002000000001ffffc00000000000c21861041006018084010430308104000000000000
% 000000000000000000000000000000088000003a0b839bb3820383bb0383a01b03b8000000000000
% 000000000000000000000000000000000000000000000000000000000000e0000000000000000000
% 0000000000000000000000000000000aa000000000000000000000000000a0000000000000000000
% 0000000000000000000000000000000000000000000000000000000000003c000000000000000000
% 000000000000000000000a80008a000a800000000000000000000000000000000000000000000000
% 00000000000000000000000000000000000000000000000000000000000000000000000000000000
% 000000000000000000000aa000a8000a800000000000000000000000000000000000000000000000
% 00000000000000000000000000000000000000000000000000000000000000000000000000000000
% 00000000000000000000088000880008800000000000000000000000000000000000000000000000
% 00000000000000000000000000000000000000000000000000000000000000000000000000000000
% 000000000000000000002a8002a8002a800000000000000000000000000000000000000000000000
% 00000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000008800088000a800000000000000000000000000000000000000000000000
% 00000000000000000000000000000000000000000000000000000000000000000000000000000000
% 000000000000000000002a8002a0002a000000000000000000000000000000000000000000000000
% 00000000000000000000000000000000000000000000000000000000000000000000000000000000
% 00000000000000000000080008800000000000000000000000000000000000000000000000000000
% 00000000000000000000000000000000000000000000000000000000000000000000000000000000
% 00000000000000000000aa000aa00000000000000000000000000000000000000000000000000000
% 00000000000000000000000000000000000000000000000000000000000000000000000000000000
% 000000000000000000008a000a800000000000000000000000000000000000000000000000000000
% 00000000000000000000000000000000000000000000000000000000000000000000000000000000
% 00000000000000000000aa000a800000000000000000000000000000000000000000000000000000
% 00000000000000000000000000000000000000000000000000000000000000000000000000000000
% 00000000000000000000000008800000000000000000000000000000000000000000000000000000
% 00000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000000000000000000000002a800000000000000000000000000000000000000000000000000000
% 00000000000000000000000000000000000000000000000000000000000000000000000000000000
% 00000000000000000000000008000000000000000000000000000000000000000000000000000000
% 00000000000000000000000000000000000000000000000000000000000000000000000000000000
% 000000000000000000000000aa000000000000000000000000000000000000000000000000000000
% 00000000000000000000000000000000000000000000000000000000000000000000000000000000
% 00000000000000000000000088000000000000000000000000000000000000000000000000000000
% 00000000000000000000000000000000000000000000000000000000000000000000000000000000
% 000000000000000000000000aa000000000000000000000000000000000000000000000000000000
% 00000000000000000000000000000000000000000000000000000000000000000000000000000000
% 00000000000000000000000088000000000000000000000000000000000000000000000000000000
% 00000000000000000000000000000000000000000000000000000000000000000000000000000000
% 000000000000000000000002a8000000000000000000000000000000000000000000000000000000
% 00000000000000000000000000000000000000000000000000000000000000000000000000000000
% 00000000000000000000000088000000000000000000000000000000000000000000000000000000














%AI3_ColorUsage: Color





%AI3_TemplateBox: 306 396 306 396

%AI3_TileBox: 18 6 570 736

%AI3_DocumentPreview: Macintosh_ColorPic








userdict /Adobe_packedarray 5 dict dup begin put

/initialize			% - initialize -

{

/packedarray where

	{

	pop

	}

	{

	Adobe_packedarray begin

	Adobe_packedarray

		{

		dup xcheck

			{

			bind

			} if

		userdict 3 1 roll put

		} forall

	end

	} ifelse

} def

/terminate			% - terminate -

{

} def

/packedarray		% arguments count packedarray array

{

array astore readonly

} def

/setpacking			% boolean setpacking -

{

pop

} def

/currentpacking		% - setpacking boolean

{

false

} def

currentdict readonly pop end


Adobe_packedarray /initialize get exec






currentpacking true setpacking

userdict /Adobe_cmykcolor 4 dict dup begin put

/initialize			% - initialize -

{

/setcmykcolor where

	{

	pop

	}

	{

	userdict /Adobe_cmykcolor_vars 2 dict dup begin put

	/_setrgbcolor

		/setrgbcolor load def

	/_currentrgbcolor

		/currentrgbcolor load def

	Adobe_cmykcolor begin

	Adobe_cmykcolor

		{

		dup xcheck

			{

			bind

			} if

		pop pop

		} forall

	end

	end

	Adobe_cmykcolor begin

	} ifelse

} def

/terminate			% - terminate -

{

currentdict Adobe_cmykcolor eq

	{

	end

	} if

} def

/setcmykcolor		% cyan magenta yellow black setcmykcolor -

{

1 sub 4 1 roll

3

	{

	3 index add neg dup 0 lt

		{

		pop 0

		} if

	3 1 roll

	} repeat

Adobe_cmykcolor_vars /_setrgbcolor get exec

pop

} def 

/currentcmykcolor	% - currentcmykcolor cyan magenta yellow black

{

Adobe_cmykcolor_vars /_currentrgbcolor get exec

3

	{

	1 sub neg 3 1 roll

	} repeat

0

} def

currentdict readonly pop end

setpacking







currentpacking true setpacking

userdict /Adobe_cshow 3 dict dup begin put

/initialize			% - initialize -

{

/cshow where

	{

	pop

	}

	{

	userdict /Adobe_cshow_vars 1 dict dup begin put

	/_cshow		% - _cshow proc

		{} def

	Adobe_cshow begin

	Adobe_cshow

		{

		dup xcheck

			{

			bind

			} if

		userdict 3 1 roll put

		} forall

	end

	end

	} ifelse

} def

/terminate			% - terminate -

{

} def

/cshow				% proc string cshow -

{

exch

Adobe_cshow_vars

	exch /_cshow

	exch put

	{

	0 0 Adobe_cshow_vars /_cshow get exec

	} forall

} def

currentdict readonly pop end

setpacking







currentpacking true setpacking

userdict /Adobe_customcolor 5 dict dup begin put

/initialize			% - initialize -

{

/setcustomcolor where

	{

	pop

	}

	{

	Adobe_customcolor begin

	Adobe_customcolor

		{

		dup xcheck

			{

			bind

			} if

		pop pop

		} forall

	end

	Adobe_customcolor begin

	} ifelse

} def

/terminate			% - terminate -

{

currentdict Adobe_customcolor eq

	{

	end

	} if

} def

/findcmykcustomcolor	% cyan magenta yellow black name findcmykcustomcolor object

{

5 packedarray

}  def

/setcustomcolor		% object tint setcustomcolor -

{

exch

aload pop pop

4

	{

	4 index mul 4 1 roll

	} repeat

5 -1 roll pop

setcmykcolor

} def

/setoverprint		% boolean setoverprint -

{

pop

} def

currentdict readonly pop end

setpacking







currentpacking true setpacking

userdict /Adobe_typography_AI3 47 dict dup begin put

/initialize			% - initialize -

{

/TZ

 where

	{

	pop

	}

	{

	Adobe_typography_AI3 begin

	Adobe_typography_AI3

		{

		dup xcheck

			{

			bind

			} if

		pop pop

		} forall

	end

	Adobe_typography_AI3 begin

	} ifelse

} def

/terminate			% - terminate -

{

currentdict Adobe_typography_AI3 eq

	{

	end

	} if

} def

% [ number value stream [ array for encoding modification ] modifyEncoding ==> [ modified array ]

/modifyEncoding

{

	/_tempEncode exch ddef

	

	% pointer for sequential encodings

	/_pntr 0 ddef

	

	{

		% get bottom object

		counttomark -1 roll

		% is it a mark ?

		dup type dup /marktype eq 		

		{

			% exit

			pop pop exit

		}

		{

			% ... object ... type ....

			% insert if a nametype

			/nametype eq

			{

				% insert the name at _pntr and increment pointer

				_tempEncode /_pntr dup load dup 3 1 roll 1 add ddef 3 -1 roll

				put

			}

			{

				% reset _pntr if it's a number

				/_pntr exch ddef					

			}

			ifelse

		}

		ifelse

	}

	loop	

	

	% return the modified encoding

	_tempEncode

}

def

/TE	% Set std platform encoding 	% (encoding pairs) TE -

{

	StandardEncoding 256 array copy modifyEncoding 

	/_nativeEncoding exch def

} def

% re-define font

% expected arguments

% for 'normal fonts : 

% [ /_Helvetica-Bold/Helvetica-Bold direction fontScript defaultEncoding TZ

%
% for cartographic, pictographic, and expert fonts :

% [ ... number value stream ... /_Symbol/Symbol 

%	direction fontScript defaultEncoding TZ

% for blended fonts w/ default encoding :

% [ /_AdobeSans_20ULig1XCond-Bold/AdobeSans 

%	direction fontScript defaultEncoding [ w0 w1 ... wn ] TZ

% for blended fonts w/ special encoding :

% [ ... number value stream ... /_AdobeSans_20ULig1XCond/AdobeSans 

%	direction fontScript defaultEncoding [ w0 w1 ... wn ] TZ

/TZ		

{

	% set weight vector (if present)

	dup type /arraytype eq {/_wv exch def} {/_wv 0 def} ifelse 

	% platform dependent coding flag

	/_useNativeEncoding exch def

	% pop fontScript & direction

	pop pop

	

	% create a new dictionary with length

	% equal to original dictionary length + 2

	% copy all the key/value pairs except FID

	% call makeblended font with the weight values if _wv is an array

	findfont _wv type /arraytype eq {_wv makeblendedfont} if dup length 2 add dict

	

	begin

	

		% copy all the values but the FID

		% into the new dictionary

		mark exch

		{

			1 index /FID ne { def } if cleartomark mark

		}

		forall

		% discard last mark

		pop

		

		% define FontName

		/FontName exch def

		

		% if no re-encoding stream is present

		% then if the base encoding vector of the font

		% is the same as StandardEncoding

		% and the use platform encoding flag is true

		% then install AI platform encoding

		% else leave the base encoding in effect

		counttomark 0 eq

		{

			1 _useNativeEncoding eq

			{

				/Encoding _nativeEncoding def

			}

			if

			% clean up

			cleartomark

		}

		{	

			% custom encoding to be done

			% start off with a copy of the font's standard encoding

			/Encoding load 256 array copy 

			modifyEncoding /Encoding exch def

		}

		ifelse		

		FontName currentdict

	end

	

	% register the new font

	definefont pop

}

def

% text painting operators

/tr					% string tr ax ay string 

{

_ax _ay 3 2 roll

} def

/trj				% string trj cx cy fillchar ax ay string 

{

_cx _cy _sp _ax _ay 6 5 roll

} def

/a0

{

/Tx	% text							% textString Tx -

	{

	dup 

	currentpoint 3 2 roll

	tr _psf

	newpath moveto

	tr _ctm _pss

	} ddef

/Tj	% justified text				% textString Tj -

	{

	dup

	currentpoint 3 2 roll

	trj _pjsf

	newpath moveto

	trj _ctm _pjss

	} ddef

	

} def

/a1

{

/Tx	% text							% textString Tx -

	{

	dup currentpoint 4 2 roll gsave

	dup currentpoint 3 2 roll

	tr _psf

	newpath moveto

	tr _ctm _pss

	grestore 3 1 roll moveto tr sp

	} ddef

/Tj	% justified text				% textString Tj -

	{

	dup currentpoint 4 2 roll gsave

	dup currentpoint 3 2 roll

	trj _pjsf

	newpath moveto

	trj _ctm _pjss

	grestore 3 1 roll moveto tr sp

	} ddef

	

} def

/e0

{

/Tx	% text							% textString Tx -

	{

	tr _psf

	} ddef

/Tj	% justified text				% textString Tj -

	{

	trj _pjsf

	} ddef

} def

/e1

{

/Tx	% text							% textString Tx -

	{

	dup currentpoint 4 2 roll gsave 

	tr _psf  

	grestore 3 1 roll moveto tr sp 

	} ddef

/Tj	% justified text				% textString Tj -

	{

	dup currentpoint 4 2 roll gsave 

	trj _pjsf

	grestore 3 1 roll moveto tr sp 

	} ddef

} def

/i0

{

/Tx	% text							% textString Tx -

	{

	tr sp

	} ddef

/Tj	% justified text				% textString Tj -

	{

	trj jsp

	} ddef

} def

/i1

{

W N

} def

/o0

{

/Tx	% text							% textString Tx -

	{

	tr sw rmoveto

	} ddef

/Tj	% justified text				% textString Tj -

	{

	trj swj rmoveto

	} ddef

} def

/r0

{

/Tx	% text							% textString Tx -

	{

	tr _ctm _pss

	} ddef

/Tj	% justified text				% textString Tj -

	{

	trj _ctm _pjss

	} ddef

} def

/r1

{

/Tx	% text							% textString Tx -

	{

	dup currentpoint 4 2 roll currentpoint gsave newpath moveto

	tr _ctm _pss 

	grestore 3 1 roll moveto tr sp 

	} ddef

/Tj	% justified text				% textString Tj -

	{

	dup currentpoint 4 2 roll currentpoint gsave newpath moveto

	trj _ctm _pjss

	grestore 3 1 roll moveto tr sp 

	} ddef

} def

% font operators

% Binding

/To	% begin text 					% bindType To -

{

	pop _ctm currentmatrix pop

} def

/TO	% end text					% TO -

{

	Te _ctm setmatrix newpath

} def

% Text paths

/Tp	% begin text path				% a b c d tx ty startPt Tp -

{

	pop _tm astore pop _ctm setmatrix 

	_tDict begin /W {} def /h {} def

} def

/TP	% end text path					% TP -

{

	end

	iTm 0 0 moveto

} def

% Render mode & matrix operators

/Tr	% begin render					% render Tr - 

{

	_render 3 le {currentpoint newpath moveto} if

	dup 8 eq {pop 0} {dup 9 eq {pop 1} if} ifelse

	dup /_render exch ddef

	_renderStart exch get load exec

} def

/iTm % internal set text matrix		% - iTm -	(uses _tm as implicit argument)

{

_ctm setmatrix _tm concat 0 _rise translate _hs 1 scale

} def

/Tm % set text matrix				% a b c d tx ty Tm -

{

_tm astore pop iTm 0 0 moveto

} def

/Td % translate text matrix 		% tx ty Td -

{

_mtx translate _tm _tm concatmatrix pop iTm 0 0 moveto

} def

/Te	% end render					% - Te -

{

	_render -1 eq {} {_renderEnd _render get dup null ne {load exec} {pop} ifelse} ifelse

	/_render -1 ddef

} def

% Attributes

/Ta	% set alignment					% alignment Ta -

{

pop

} def

/Tf	% set font name and size		% fontname size Tf -

{

dup 1000 div /_fScl exch ddef

exch findfont exch scalefont setfont

} def

/Tl	% set leading					% leading paragraphLeading Tl -

{

pop

0 exch _leading astore pop

} def

/Tt	% set user tracking				% userTracking Tt -

{

pop

} def

/TW % set word spacing				% minSpace optSpace maxSpace TW -

{

3 npop

} def

/Tw	% set computed word spacing		% wordSpace Tw

{

/_cx exch ddef

} def

/TC % set character spacing			% minSpace optSpace maxSpace TC -

{

3 npop

} def

/Tc	% set computed char spacing 	% charSpace Tc -

{

/_ax exch ddef

} def

/Ts % set super/subscripting (rise)	% rise Ts -

{

/_rise exch ddef

currentpoint

iTm

moveto

} def

/Ti	% set indentation				% firstStartIndent otherStartIndent stopIndent Ti -

{

3 npop

} def

/Tz % set horizontal scaling		% scalePercent Tz -

{

100 div /_hs exch ddef

iTm

} def

/TA % set pairwise kerning			% autoKern TA -

									%	autoKern = 0 -> no pair kerning

									%			 = 1 -> automatic pair kerning

{

pop

} def

/Tq % set hanging quotes			% hangingQuotes Tq -

									%	hangingQuotes 	= 0 -> no hanging quotes

									%			 		= 1 -> hanging quotes

{

pop

} def

% Text Bodies

/TX {pop} def

%/Tx	% non-justified text			% textString Tx -

%/Tj	% justified text				% textString Tj -

/Tk	% kern							% autoKern kernValue Tk -

									%  	autoKern = 0 -> manual kern, = 1 -> auto kern

									%	kernValue = kern value in em/1000 space

{

exch pop _fScl mul neg 0 rmoveto

} def

/TK	% non-printing kern				% autoKern kernValue TK -

{

2 npop

} def

/T* % carriage return & line feed	% - T* -

{

_leading aload pop neg Td

} def

/T*- % carriage return & negative line feed	% - T*- -

{

_leading aload pop Td

} def

/T-	% print a discretionary hyphen	% - T- -

{

_hyphen Tx

} def

/T+	% discretionary hyphen hyphen	% - T+ -

{} def

/TR	% reset pattern matrix 			% a b c d tx ty TR -

{

_ctm currentmatrix pop 	

_tm astore pop 

iTm 0 0 moveto 

} def

/TS	% special chars					% textString justified TS -

{

0 eq {Tx} {Tj} ifelse

} def

currentdict readonly pop end

setpacking







currentpacking true setpacking

userdict /Adobe_IllustratorA_AI3 61 dict dup begin put

% initialization

/initialize				% - initialize -

{

% 47 vars, but leave slack of 10 entries for custom Postscript fragments

userdict /Adobe_IllustratorA_AI3_vars 57 dict dup begin put

% paint operands

/_lp /none def

/_pf {} def

/_ps {} def

/_psf {} def

/_pss {} def

/_pjsf {} def

/_pjss {} def

/_pola 0 def

/_doClip 0 def

% paint operators

/cf	currentflat def	% - cf flatness

% typography operands

/_tm matrix def

/_renderStart [/e0 /r0 /a0 /o0 /e1 /r1 /a1 /i0] def 

/_renderEnd [null null null null /i1 /i1 /i1 /i1] def

/_render -1 def

/_rise 0 def

/_ax 0 def			% x character spacing	(_ax, _ay, _cx, _cy follows awidthshow naming convention)

/_ay 0 def			% y character spacing

/_cx 0 def			% x word spacing

/_cy 0 def			% y word spacing

/_leading [0 0] def

/_ctm matrix def

/_mtx matrix def

/_sp 16#020 def

/_hyphen (-) def

/_fScl 0 def

/_cnt 0 def

/_hs 1 def

/_nativeEncoding 0 def

/_useNativeEncoding 0 def

/_tempEncode 0 def

/_pntr 0 def

/_tDict 2 dict def

% typography operators

/Tx {} def

/Tj {} def

% compound path operators

/CRender {} def

% printing

/_AI3_savepage {} def

% color operands

/_gf null def

/_cf 4 array def

/_if null def

/_of false def

/_fc {} def

/_gs null def

/_cs 4 array def

/_is null def

/_os false def

/_sc {} def

/_i null def

Adobe_IllustratorA_AI3 begin

Adobe_IllustratorA_AI3

	{

	dup xcheck

		{

		bind

		} if

	pop pop

	} forall

end

end

Adobe_IllustratorA_AI3 begin

Adobe_IllustratorA_AI3_vars begin

newpath

} def

/terminate				% - terminate -

{

end

end

} def

% definition operators

/_					% - _ null

null def

/ddef				% key value ddef -

{

Adobe_IllustratorA_AI3_vars 3 1 roll put

} def

/xput				% key value literal xput -

{

dup load dup length exch maxlength eq

	{

	dup dup load dup

	length 2 mul dict copy def

	} if

load begin def end

} def

/npop				% integer npop -

{

	{

	pop

	} repeat

} def

% marking operators

/sw					% ax ay string sw x y 

{

dup length exch stringwidth

exch 5 -1 roll 3 index 1 sub mul add

4 1 roll 3 1 roll 1 sub mul add

} def

/swj				% cx cy fillchar ax ay string swj x y

{

dup 4 1 roll

dup length exch stringwidth 

exch 5 -1 roll 3 index 1 sub mul add

4 1 roll 3 1 roll 1 sub mul add 

6 2 roll /_cnt 0 ddef

{1 index eq {/_cnt _cnt 1 add ddef} if} forall pop

exch _cnt mul exch _cnt mul 2 index add 4 1 roll 2 index add 4 1 roll pop pop

} def

/ss					% ax ay string matrix ss -

{

4 1 roll

	{				% matrix ax ay char 0 0 {proc} -

	2 npop 

	(0) exch 2 copy 0 exch put pop

	gsave

	false charpath currentpoint

	4 index setmatrix

	stroke

	grestore

	moveto

	2 copy rmoveto

	} exch cshow

3 npop

} def

/jss				% cx cy fillchar ax ay string matrix jss -

{

4 1 roll

	{				% cx cy fillchar matrix ax ay char 0 0 {proc} -   

	2 npop 

	(0) exch 2 copy 0 exch put 

	gsave

	_sp eq 

		{

		exch 6 index 6 index 6 index 5 -1 roll widthshow  

		currentpoint

		}

		{

		false charpath currentpoint

		4 index setmatrix stroke

		}ifelse

	grestore

	moveto

	2 copy rmoveto

	} exch cshow

6 npop

} def

% path operators

/sp					% ax ay string sp -

{

	{

	2 npop (0) exch

	2 copy 0 exch put pop

	false charpath

	2 copy rmoveto

	} exch cshow

2 npop

} def

/jsp					% cx cy fillchar ax ay string jsp -

{

	{					% cx cy fillchar ax ay char 0 0 {proc} -

	2 npop 

	(0) exch 2 copy 0 exch put 

	_sp eq 

		{

		exch 5 index 5 index 5 index 5 -1 roll widthshow  

		}

		{

		false charpath

		}ifelse

	2 copy rmoveto

	} exch cshow

5 npop

} def

% path construction operators

/pl				% x y pl x y

{

transform

0.25 sub round 0.25 add exch

0.25 sub round 0.25 add exch

itransform

} def

/setstrokeadjust where

	{

	pop true setstrokeadjust

	/c				% x1 y1 x2 y2 x3 y3 c -

	{

	curveto

	} def

	/C

	/c load def

	/v				% x2 y2 x3 y3 v -

	{

	currentpoint 6 2 roll curveto

	} def

	/V

	/v load def

	/y				% x1 y1 x2 y2 y -

	{

	2 copy curveto

	} def

	/Y

	/y load def

	/l				% x y l -

	{

	lineto

	} def

	/L

	/l load def

	/m				% x y m -

	{

	moveto

	} def

	}

	{%else

	/c

	{

	pl curveto

	} def

	/C

	/c load def

	/v

	{

	currentpoint 6 2 roll pl curveto

	} def

	/V

	/v load def

	/y

	{

	pl 2 copy curveto

	} def

	/Y

	/y load def

	/l

	{

	pl lineto

	} def

	/L

	/l load def

	/m

	{

	pl moveto

	} def

	}ifelse

% graphic state operators

/d					% array phase d -

{

setdash

} def

/cf	{} def			% - cf flatness

/i					% flatness i -

{

dup 0 eq

	{

	pop cf

	} if

setflat

} def

/j					% linejoin j -

{

setlinejoin

} def

/J					% linecap J -

{

setlinecap

} def

/M					% miterlimit M -

{

setmiterlimit

} def

/w					% linewidth w -

{

setlinewidth

} def

% path painting operators

/H					% - H -

{} def

/h					% - h -

{

closepath

} def

/N					% - N -

{

_pola 0 eq 

	{

	_doClip 1 eq {clip /_doClip 0 ddef} if 

	newpath

	} 

	{

	/CRender {N} ddef

	}ifelse

} def

/n					% - n -

{N} def

/F					% - F -

{

_pola 0 eq 

	{

	_doClip 1 eq 

		{

		gsave _pf grestore clip newpath /_lp /none ddef _fc 

		/_doClip 0 ddef

		}

		{

		_pf

		}ifelse

	} 

	{

	/CRender {F} ddef

	}ifelse

} def

/f					% - f -

{

closepath

F

} def

/S					% - S -

{

_pola 0 eq 

	{

	_doClip 1 eq 

		{

		gsave _ps grestore clip newpath /_lp /none ddef _sc 

		/_doClip 0 ddef

		}

		{

		_ps

		}ifelse

	} 

	{

	/CRender {S} ddef

	}ifelse

} def

/s					% - s -

{

closepath

S

} def

/B					% - B -

{

_pola 0 eq 

	{

	_doClip 1 eq 	% F clears _doClip

	gsave F grestore 

		{

		gsave S grestore clip newpath /_lp /none ddef _sc

		/_doClip 0 ddef

		} 

		{

		S

		}ifelse

	}

	{

	/CRender {B} ddef

	}ifelse

} def

/b					% - b -

{

closepath

B

} def

/W					% - W -

{

/_doClip 1 ddef

} def

/*					% - [string] * -

{

count 0 ne 

	{

	dup type (stringtype) eq {pop} if

	} if 

_pola 0 eq {newpath} if

} def

% group operators

/u					% - u -

{} def

/U					% - U -

{} def

/q					% - q -

{

_pola 0 eq {gsave} if

} def

/Q					% - Q -

{

_pola 0 eq {grestore} if

} def

/*u					% - *u -

{

_pola 1 add /_pola exch ddef

} def

/*U					% - *U -

{

_pola 1 sub /_pola exch ddef 

_pola 0 eq {CRender} if

} def

/D					% polarized D -

{pop} def

/*w					% - *w -

{} def

/*W					% - *W -

{} def

% place operators

/`					% matrix llx lly urx ury string ` -

{

/_i save ddef

6 1 roll 4 npop

concat pop

userdict begin

/showpage {} def

0 setgray

0 setlinecap

1 setlinewidth

0 setlinejoin

10 setmiterlimit

[] 0 setdash

newpath

0 setgray

false setoverprint

} def

/~					% - ~ -

{

end

_i restore

} def

% color operators

/O					% flag O -

{

0 ne

/_of exch ddef

/_lp /none ddef

} def

/R					% flag R -

{

0 ne

/_os exch ddef

/_lp /none ddef

} def

/g					% gray g -

{

/_gf exch ddef

/_fc

{ 

_lp /fill ne

	{

	_of setoverprint

	_gf setgray

	/_lp /fill ddef

	} if

} ddef

/_pf

{

_fc

fill

} ddef

/_psf

{

_fc

ashow

} ddef

/_pjsf

{

_fc

awidthshow

} ddef

/_lp /none ddef

} def

/G					% gray G -

{

/_gs exch ddef

/_sc

{

_lp /stroke ne

	{

	_os setoverprint

	_gs setgray

	/_lp /stroke ddef

	} if

} ddef

/_ps

{

_sc

stroke

} ddef

/_pss

{

_sc

ss

} ddef

/_pjss

{

_sc

jss

} ddef

/_lp /none ddef

} def

/k					% cyan magenta yellow black k -

{

_cf astore pop

/_fc

{

_lp /fill ne

	{

	_of setoverprint

	_cf aload pop setcmykcolor

	/_lp /fill ddef

	} if

} ddef

/_pf

{

_fc

fill

} ddef

/_psf

{

_fc

ashow

} ddef

/_pjsf

{

_fc

awidthshow

} ddef

/_lp /none ddef

} def

/K					% cyan magenta yellow black K -

{

_cs astore pop

/_sc

{

_lp /stroke ne

	{

	_os setoverprint

	_cs aload pop setcmykcolor

	/_lp /stroke ddef

	} if

} ddef

/_ps

{

_sc

stroke

} ddef

/_pss

{

_sc

ss

} ddef

/_pjss

{

_sc

jss

} ddef

/_lp /none ddef

} def

/x					% cyan magenta yellow black name gray x -

{

/_gf exch ddef

findcmykcustomcolor

/_if exch ddef

/_fc

{ 

_lp /fill ne

	{

	_of setoverprint

	_if _gf 1 exch sub setcustomcolor

	/_lp /fill ddef

	} if

} ddef

/_pf

{

_fc

fill

} ddef

/_psf

{

_fc

ashow

} ddef

/_pjsf

{

_fc

awidthshow

} ddef

/_lp /none ddef

} def

/X					% cyan magenta yellow black name gray X -

{

/_gs exch ddef

findcmykcustomcolor

/_is exch ddef

/_sc

{

_lp /stroke ne

	{

	_os setoverprint

	_is _gs 1 exch sub setcustomcolor

	/_lp /stroke ddef

	} if

} ddef

/_ps

{

_sc

stroke

} ddef

/_pss

{

_sc

ss

} ddef

/_pjss

{

_sc

jss

} ddef

/_lp /none ddef

} def

% locked object operator

/A					% value A -

{

pop

} def

currentdict readonly pop end

setpacking

% annotate page operator

/annotatepage

{

} def





Adobe_cmykcolor /initialize get exec

Adobe_cshow /initialize get exec

Adobe_customcolor /initialize get exec

Adobe_typography_AI3 /initialize get exec

Adobe_IllustratorA_AI3 /initialize get exec

[

39/quotesingle 96/grave 128/Adieresis/Aring/Ccedilla/Eacute/Ntilde/Odieresis

/Udieresis/aacute/agrave/acircumflex/adieresis/atilde/aring/ccedilla/eacute

/egrave/ecircumflex/edieresis/iacute/igrave/icircumflex/idieresis/ntilde

/oacute/ograve/ocircumflex/odieresis/otilde/uacute/ugrave/ucircumflex

/udieresis/dagger/degree/cent/sterling/section/bullet/paragraph/germandbls

/registered/copyright/trademark/acute/dieresis/.notdef/AE/Oslash

/.notdef/plusminus/.notdef/.notdef/yen/mu/.notdef/.notdef

/.notdef/.notdef/.notdef/ordfeminine/ordmasculine/.notdef/ae/oslash

/questiondown/exclamdown/logicalnot/.notdef/florin/.notdef/.notdef

/guillemotleft/guillemotright/ellipsis/.notdef/Agrave/Atilde/Otilde/OE/oe

/endash/emdash/quotedblleft/quotedblright/quoteleft/quoteright/divide

/.notdef/ydieresis/Ydieresis/fraction/currency/guilsinglleft/guilsinglright

/fi/fl/daggerdbl/periodcentered/quotesinglbase/quotedblbase/perthousand

/Acircumflex/Ecircumflex/Aacute/Edieresis/Egrave/Iacute/Icircumflex

/Idieresis/Igrave/Oacute/Ocircumflex/.notdef/Ograve/Uacute/Ucircumflex

/Ugrave/dotlessi/circumflex/tilde/macron/breve/dotaccent/ring/cedilla

/hungarumlaut/ogonek/caron

TE

%AI3_BeginEncoding: _Times-Roman Times-Roman

[/_Times-Roman/Times-Roman 0 0 1 TZ

%AI3_EndEncoding TrueType


0 A

*u

0 O

1 0.56 0 0.185 (PANTONE 294 CV) 0 x

0 i 0 J 0 j 1 w 4 M []0 d

%AI3_Note:

0 D

311.9948 362.7864 m

318.8874 361.016 323.9879 354.7607 323.9813 347.3161 c

323.9739 338.8644 317.8698 332.2909 306.601 332.2835 C

291.1218 332.3001 L

287.2528 332.3001 283.8982 334.5012 282.241 337.7194 C

277.9594 344.7335 L

273.4987 351.5419 l

263.5211 351.5419 l

260.5865 341.4469 260.2482 341.4469 v

262.8308 341.4469 l

253.3086 332.056 l

246.3967 341.4469 l

248.9792 341.4469 L

249.3176 341.4469 L

258.2387 375.4882 l

247.2529 392.8824 l

244.8568 386.2877 240.0482 373.6205 226.8169 373.6205 c

213.5857 373.6205 202.8595 384.347 202.8595 397.5777 c

202.8595 410.809 213.5857 421.5354 226.8169 421.5354 C

229.8318 421.5984 L

229.8318 424.1808 l

239.2226 415.9638 l

229.8318 407.747 l

229.8318 410.3296 L

226.8169 410.3552 L

219.7606 410.3552 214.0398 404.6347 214.0398 397.5777 c

214.0398 390.5212 219.7606 384.8007 226.8169 384.8007 C

228.68 384.8649 L

231.267 385.1129 232.8838 387.2266 233.7933 390.0072 c

243.2137 410.7036 l

250.022 410.7036 l

261.995 392.1569 l

267.6294 410.7036 L

267.9679 410.7036 L

265.3854 410.7036 l

274.9072 419.8594 l

281.8194 410.7036 l

279.237 410.7036 L

279.3679 410.4687 L

270.9163 378.775 L

277.9799 378.6823 L

285.3307 378.6823 291.2895 372.723 291.2895 365.3725 c

291.2895 360.9657 289.148 357.0591 285.8486 354.6369 C

291.3457 345.1969 L

292.0455 343.0902 293.1331 342.3782 295.3385 342.3782 C

308.2443 342.3737 L

311.1848 342.3737 313.3335 344.6104 313.3335 347.5508 c

313.3335 349.2053 312.5785 350.6839 311.394 351.6603 C

309.4096 352.6925 L

303.2635 354.9154 298.871 360.8029 298.871 367.7161 c

298.871 376.5368 306.0219 383.6877 314.8428 383.6877 C

324.4435 383.705 L

324.4435 386.2877 l

333.834 378.0706 l

324.4435 369.8539 l

324.4435 372.9059 L

314.8261 372.8217 L

311.8859 372.8217 309.5022 370.438 309.5022 367.498 c

309.5022 365.2005 310.9577 363.2429 312.9966 362.4966 c

F

1 D

278.1976 362.7964 m

279.484 362.7964 280.5269 363.8392 280.5269 365.1253 c

280.5269 366.4119 279.484 367.4546 278.1976 367.4546 C

267.7639 367.2715 L

266.5837 362.8107 L

278.1976 362.7964 L

f

*U

u

u

0.8 g

0 D

324.0387 391.6872 m

334.9603 432.0677 l

341.9151 432.0677 l

330.9986 391.6872 l

324.0387 391.6872 l

f

U

u

303.3856 387.6963 m

309.6113 410.7036 l

316.5663 410.7036 l

310.345 387.6963 l

303.3856 387.6963 l

f

U

u

296.7532 290.6489 m

306.7355 327.5073 l

313.6904 327.5073 l

303.7128 290.6489 l

296.7532 290.6489 l

f

U

u

282.1094 308.9899 m

287.1617 327.5366 l

294.1167 327.5366 l

289.0692 308.9899 l

282.1094 308.9899 l

f

U

u

323.5166 316.4734 m

337.9598 370.2354 l

344.9146 370.2354 l

330.4764 316.4734 l

323.5166 316.4734 l

f

U

U

0 To

1.4757 0 0 1.4757 354.5956 375.2894 0 Tp

TP

0 Tr

0.2 g

/_Times-Roman 12 Tf

0 Ts

100 Tz

0 Tt

0 TA

0 0 5 TC

100 100 200 TW

0 0 0 Ti

0 Ta

0 Tq

14.8678 0 Tl

0 Tc

0 Tw

(CENTRE NATIONAL ) Tx

(\r) TX 

T*

(DE LA RECHERCHE) Tx

(\r) TX 

T*

(SCIENTIFIQUE) Tx 

(\r) TX 

TO


gsave annotatepage grestore showpage


Adobe_IllustratorA_AI3 /terminate get exec

Adobe_typography_AI3 /terminate get exec

Adobe_customcolor /terminate get exec

Adobe_cshow /terminate get exec

Adobe_cmykcolor /terminate get exec

Adobe_packedarray /terminate get exec


%%EndDocument
 @endspecial 336 w @beginspecial 62 @llx 14 @lly 552
@urx 140 @ury 566 @rwi @setspecial
%%BeginDocument: Logo-INRIA.epsi
% 0000000000000000000000000000000007c00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 3f800000000000000000000000ffffffff800000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 3ffffe00000000000000003ffffffffffe000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 3ffffffffffffffffffffffffffffffff8000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 3fffffffffffffffffffffffffffffffc0300000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 3fffffffffffffffffffffffffffffff00f00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 3ffffffffffffffffffffffffffffffe03e00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 3ffffffffffffffffffffffffffffff80fe00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 3fffffffffffffffffffffffffffffe03fc00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 3fffffffffffffffffffffffffffff80ffc00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 3ffffffffffffffffffffffffffffe03ff800000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 3ffffffffffffffffffffffffffff807ff800000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 3fffffffffffffffffffffffffffe01fff800000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 3fffffffffffe000003fffffffffc07fff000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 3ffffffffffe00000003ffffffff01ffff000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 3fffffffffe000000000fffffffc07fffe000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 3fffffffff00000000001ffffff81ffffe000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 3ffffffffc000000000007ffffe03ffffc000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 3fffffffe0000038000003ffffc0fffffc000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 3fffffff80000ffffe0000ffff01fffff8000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 3ffffffe0007fffffff0007ffe03fffff8000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 3ffffff001fffffffffc001ff80ffffff0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 3fffffc007ffffffffff000ff01ffffff0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 3fffff801fffffffffffc007c03fffffe0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 3ffffe00fffffffffffff00380ffffffe0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 1ffffc07fffffffffffff80101ffffffe0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 1ffff81ffffffffffffffc0007ffffffc0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 1fffe07ffffffffffffffe000fffffffc0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 1fffe1ffffffffffffffff001fffffff80000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 1fffffffffffffffffffff803fffffff80000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 1fffffffffffffffffffff003fffffff00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 1fffffffffff7ffffffffe001fffffff00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 1ffffffffffe0ffffffffc001ffffffe00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 1ffffffffff807fffffff8000ffffffe00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 1ffffffffff007ffffffe0100ffffffe00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 1ffffffffff007ffffffc03007fffffc00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 1fffffffffe00fffffff807807fffffc00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 1fffffffffc01fffffff01f807fffffc00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 1fffffffffc03ffffffe03f807fffff800000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 1ffffffffffffffffff807f803fffff800000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 1ffffffffffffffffff01ffc03fffff800000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 1fffffffffffffffffe03ffc03fffff800000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 1fffffffffffffffffc07ffc03fffff000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 1fffffffffffffffff00fffc03fffff000000001ffffe00000001fff00000001fffc00000001fffffffffe0000000000007ffff8000000000000fff80000
% 1ffffffffffffffffe01fffc03fffff000000000ffff800000000fff80000000ffe000000000ffffffffff8000000000003fffe0000000000000fffc0000
% 1ffffffffffffffffc03fff807ffffe0000000003ffe0000000003ff800000007fc0000000003fffffffffe000000000000fff800000000000003ffe0000
% 1ffffffffffffffff80ffff807ffffe0000000003ffc0000000003ffc00000003f80000000003fffffffffe000000000000fff000000000000007ffe0000
% 1fffffffc7fffffff01ffff807ffffe0000000003ffc0000000003ffe00000003f80000000003ffffffffff000000000000fff000000000000007ffe0000
% 1fffffffc7ffffffe03ffff007ffffc0000000007ff80000000003ffe00000003f00000000003ffc0001fff800000000001ffe00000000000000fffe0000
% 1fffffff83ffffffc07ffff007ffffc0000000007ff80000000003fff00000007f00000000007ff80000fffc00000000001ffe00000000000000fffe0000
% 1fffffff03ffffff80fffff00fffffc0000000007ff80000000003fff80000007f00000000007ff800007ffc00000000001ffe00000000000001fffe0000
% 1ffffffe03fffffe01ffffe00fffffc0000000007ff00000000003fff80000007e00000000007ff800003ffc00000000001ffc00000000000003ffff0000
% 1ffffffc03fffffc03ffffe00fffff8000000000fff00000000007fffc0000007e00000000007ff800003ffc00000000003ffc00000000000003ffff0000
% 1ffffffc07fffff807ffffc01fffff8000000000fff00000000007fffc000000fe0000000000fff000003ffc00000000003ffc00000000000007ffff0000
% 1ffffff807fffff00fffffc01fffff8000000000fff00000000007fffe000000fe0000000000fff000003ffc00000000003ffc0000000000000ff7ff0000
% 1ffffff80fffffe01fffffc03fffff0000000000ffe00000000007ffff000000fc0000000000fff000003ffc00000000003ff80000000000000fe7ff0000
% 1ffffff01fffffc03fffff803fffff0000000001ffe0000000000fefff000001fc0000000001ffe000003ffc00000000007ff80000000000001fc7ff0000
% 1fffffe01fffff807fffff807fffff0000000001ffe0000000000fefff800001fc0000000001ffe000003ffc00000000007ff80000000000003fc3ff8000
% 1fffffc03ffffe01ffffff00fffffe0000000001ffe0000000000fe7ff800001f80000000001ffe000007ff800000000007ff80000000000003f83ff8000
% 3fffffc07ffffe03fffffe00fffffe0000000001ffc0000000001fc7ffc00001f80000000001ffe000007ff800000000007ff00000000000007f03ff8000
% 3fffff80fffff807fffffc01fffffe0000000003ffc0000000001fc3ffe00003f80000000003ffc000007ff00000000000fff0000000000000ff03ff8000
% 3fffff80fffff80ffffffc03fffffe0000000003ffc0000000001fc1ffe00003f80000000003ffc00000fff00000000000fff0000000000001fe03ff8000
% 3fffff01ffffe01ffffff807fffffc0000000003ff80000000001f81fff00003f00000000003ffc00001ffe00000000000ffe0000000000001fc03ffc000
% 3ffffe03ffffc03ffffff00ffffffc0000000007ff80000000003f80fff00007f00000000003ffc00003ffe00000000001ffe0000000000003f801ffc000
% 3ffffe03ffff807fffffc01ffffffc0000000007ff80000000003f80fff80007f00000000007ff80000fff800000000001ffe0000000000007f801ffc000
% 3ffffc07ffff007fffff803ffffff80000000007ff80000000003f807ffc0007f00000000007ff80001fff000000000001ffe0000000000007f001ffc000
% 3ffffc0fffff00ffffff007ffffff80000000007ff00000000003f007ffc0007e00000000007ff9f03fffc000000000001ffc000000000000fe001ffc000
% 3ffff80ffffc03fffffe00fffffff8000000000fff00000000007f003ffe000fe0000000000fff3ffffff8000000000003ffc000000000001fe001ffc000
% 3ffff01ffff803fffff003fffffff0000000000fff00000000007f001ffe000fe0000000000fff3ffffff0000000000003ffc000000000001fc001ffe000
% 3ffff01ffff007ffffe007fffffff0000000000fff00000000007f001fff000fc0000000000fff1fffff00000000000003ffc000000000003f8000ffe000
% 3ffff03fffe00fffff801ffffffff0000000000ffe00000000007e000fff800fc0000000000fff1ffff800000000000003ff8000000000007f8000ffe000
% 3fffe03fffc01ffffe007fffffffe0000000001ffe0000000000fe000fff801fc0000000001ffe0fffe000000000000007ff800000000000ff0000ffe000
% 3fffc07fffc03ffffc00ffffffffe0000000001ffe0000000000fe0007ffc01fc0000000001ffe07ffe000000000000007ff800000000000fe0000ffe000
% 3fffc0ffff807ffff003ffffffffe0000000001ffc0000000000fe0003ffc01f80000000001ffe03fff000000000000007ff000000000001ffffffffe000
% 3fff80fffe00ffffe00fffffffffc0000000003ffc0000000001fc0003ffe03f80000000001ffe03fff80000000000000fff000000000003fffffffff000
% 3fff81fffe01ffffe03fffffffffc0000000003ffc0000000001fc0001ffe03f80000000003ffc00fffc0000000000000fff000000000007fffffefff000
% 3fff03fffc03ffffe03fffffffffc0000000003ffc0000000001fc0001fff03f80000000003ffc00fffe0000000000000fff000000000007fffffefff000
% 3fff03fff007ffffe03fffffffff80000000003ff80000000001f80000fff83f00000000003ffc007fff0000000000000ffe00000000000ffffffc7ff000
% 7ffe07ffe00fffffe03fffffffff80000000007ff80000000003f80000fff87f00000000003ff8003fff0000000000001ffe00000000001ffffff87ff000
% 7ffe07ffc00fffffe03fffffffff80000000007ff80000000003f800007ffc7f00000000007ff8001fff8000000000001ffe00000000003fe000087ff800
% 7ffc0fffc01fffffe03fffffffff80000000007ff80000000003f800003ffc7f00000000007ff8001fffc000000000001ffe00000000003fc000007ff800
% 7ffc1fff803fffffe03fffffffff00000000007ff00000000003f000003ffe7e00000000007ff0000fffe000000000001ffc00000000007f8000007ff800
% 7ff81fff007fffffe03fffffffff0000000000fff00000000007f000001ffffe0000000000fff00007ffe000000000003ffc0000000000ff0000003ff800
% 7ff83ffe00ffffffe03fffffffff0000000000fff00000000007f000001ffffe0000000000fff00003fff000000000003ffc0000000000ff0000003ff800
% 7ff03ffc01ffffffe03ffffffffe0000000000fff00000000007e000000ffffc0000000000fff00003fff800000000003ffc0000000001fe0000003ff800
% 7fe07ff803ffffffe03ffffffffe0000000000ffe0000000000fe0000007fffc0000000000ffe00001fff800000000003ff80000000003fc0000003ffc00
% 7fe07ff007ffffffe03ffffffffe0000000001ffe0000000000fe0000007fffc0000000001ffe00000fffc00000000007ff80000000003f80000003ffc00
% 7fc07fe00ffffffff03ffffffffc0000000001ffe0000000000fe0000003fffc0000000001ffe00000fffe00000000007ff80000000007f80000003ffc00
% 7fc0ffc01ffffffff01ffffffffc0000000001ffc0000000000fc0000003fff80000000001ffe000007ffe00000000007ff0000000000ff00000001ffc00
% 7fc0ffc03ffffffff01ffffffffc0000000003ffc0000000001fc0000001fff80000000003ffc000003fff0000000000fff0000000000fe00000001ffc00
% 7f81ff807ffffffff01ffffffff80000000003ffc0000000001fc0000000fff80000000003ffc000001fff8000000000fff0000000001fe00000001ffe00
% 7f81ff007ffffffff81ffffffff80000000003ffc0000000001fc0000000fff80000000003ffc000000fffc000000000fff0000000003fc00000001ffe00
% 7f03fe00fffffffff80ffffffff80000000003ff80000000001f800000007ff00000000003ffc0000007ffe000000000ffe0000000007f800000001ffe00
% 7f03fc01fffffffff80ffffffff00000000007ff80000000003f800000007ff00000000007ff80000001fff000000001ffe000000000ff800000001ffe00
% 7e03f803fffffffff80ffffffff0000000000fff80000000007f800000003ff00000000007ffc0000000fff800000003ffe000000000ff000000001fff00
% 7e07f807fffffffffc0ffffffff0000000000fffc0000000007fc00000001fe0000000000fffc00000007ffe00000003fff000000003ff000000001fff00
% 7c07f00ffffffffffc07ffffffe0000000007fffe000000003fff00000001fe0000000007ffff00000003fffc000001ffff80000001fff800000007fffc0
% fc0fe01ffffffffffc07ffffffe000000000fffff000000007fff80000000fc000000000fffff00000000ffffff0003ffffc0000003fff80000000ffffe0
% f80fc03ffffffffffe07ffffffc00000000000000000000000000000000000000000000000000000000001ffffe000000000000000000000000000000000
% f81f803ffffffffffe03ffffffc00000000000000000000000000000000000000000000000000000000000ffffc000000000000000000000000000000000
% f81f007fffffffffff03ffffff8000000000000000000000000000000000000000000000000000000000000fff8000000000000000000000000000000000
% f03e00ffffffffffff03ffffff80000000000000000000000000000000000000000000000000000000000000380000000000000000000000000000000000
% f03e01ffffffffffff81ffffff00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% f03c01ffffffffffff80ffffff00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% e07803ffffffffffffc0fffffe00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% e07007ffffffffffffc07ffffe00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% e0f00fffffffffffffe07ffffe00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% c0e00fffffffffffffe03ffffc00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% c1c01ffffffffffffff03ffffc00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 81803ffffffffffffff01ffff800000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 83007ffffffffffffff81ffff800000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0300fffffffffffffff80ffff000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0000fffffffffffffffc07fff000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0001fffffffffffffffe07ffe000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0003fffffffffffffffe03ffe000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0003ffffffffffffffff01ffc000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 0007ffffffffffffffff80ffc000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 000fffffffffffffffffc07f8000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 000fffffffffffffffffe07f8000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 001fffffffffffffffffe03f8000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 003ffffffffffffffffff81f0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 003ffffffffffffffffffc0f0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 007ffffffffffffffffffe020000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 00ffffffffffffffffffff000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 01ffffffffffffffffffffc00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 01ffffffc00000007fffffe00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
% 03ff800000000000000007e00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
%AI3_ColorUsage: Black&White
%AI3_TemplateBox: 297 50 297 50
%AI3_TileBox: -123.5 -239 717.5 339
%AI3_DocumentPreview: Macintosh_Pic
userdict /Adobe_packedarray 5 dict dup begin put
/initialize			% - initialize -
{
/packedarray where
	{
	pop
	}
	{
	Adobe_packedarray begin
	Adobe_packedarray
		{
		dup xcheck
			{
			bind
			} if
		userdict 3 1 roll put
		} forall
	end
	} ifelse
} def
/terminate			% - terminate -
{
} def
/packedarray		% arguments count packedarray array
{
array astore readonly
} def
/setpacking			% boolean setpacking -
{
pop
} def
/currentpacking		% - setpacking boolean
{
false
} def
currentdict readonly pop end
Adobe_packedarray /initialize get exec
currentpacking true setpacking
userdict /Adobe_cmykcolor 4 dict dup begin put
/initialize			% - initialize -
{
/setcmykcolor where
	{
	pop
	}
	{
	userdict /Adobe_cmykcolor_vars 2 dict dup begin put
	/_setrgbcolor
		/setrgbcolor load def
	/_currentrgbcolor
		/currentrgbcolor load def
	Adobe_cmykcolor begin
	Adobe_cmykcolor
		{
		dup xcheck
			{
			bind
			} if
		pop pop
		} forall
	end
	end
	Adobe_cmykcolor begin
	} ifelse
} def
/terminate			% - terminate -
{
currentdict Adobe_cmykcolor eq
	{
	end
	} if
} def
/setcmykcolor		% cyan magenta yellow black setcmykcolor -
{
1 sub 4 1 roll
3
	{
	3 index add neg dup 0 lt
		{
		pop 0
		} if
	3 1 roll
	} repeat
Adobe_cmykcolor_vars /_setrgbcolor get exec
pop
} def 
/currentcmykcolor	% - currentcmykcolor cyan magenta yellow black
{
Adobe_cmykcolor_vars /_currentrgbcolor get exec
3
	{
	1 sub neg 3 1 roll
	} repeat
0
} def
currentdict readonly pop end
setpacking
currentpacking true setpacking
userdict /Adobe_cshow 3 dict dup begin put
/initialize			% - initialize -
{
/cshow where
	{
	pop
	}
	{
	userdict /Adobe_cshow_vars 1 dict dup begin put
	/_cshow		% - _cshow proc
		{} def
	Adobe_cshow begin
	Adobe_cshow
		{
		dup xcheck
			{
			bind
			} if
		userdict 3 1 roll put
		} forall
	end
	end
	} ifelse
} def
/terminate			% - terminate -
{
} def
/cshow				% proc string cshow -
{
exch
Adobe_cshow_vars
	exch /_cshow
	exch put
	{
	0 0 Adobe_cshow_vars /_cshow get exec
	} forall
} def
currentdict readonly pop end
setpacking
currentpacking true setpacking
userdict /Adobe_customcolor 5 dict dup begin put
/initialize			% - initialize -
{
/setcustomcolor where
	{
	pop
	}
	{
	Adobe_customcolor begin
	Adobe_customcolor
		{
		dup xcheck
			{
			bind
			} if
		pop pop
		} forall
	end
	Adobe_customcolor begin
	} ifelse
} def
/terminate			% - terminate -
{
currentdict Adobe_customcolor eq
	{
	end
	} if
} def
/findcmykcustomcolor	% cyan magenta yellow black name findcmykcustomcolor object
{
5 packedarray
}  def
/setcustomcolor		% object tint setcustomcolor -
{
exch
aload pop pop
4
	{
	4 index mul 4 1 roll
	} repeat
5 -1 roll pop
setcmykcolor
} def
/setoverprint		% boolean setoverprint -
{
pop
} def
currentdict readonly pop end
setpacking
currentpacking true setpacking
userdict /Adobe_IllustratorA_AI3 61 dict dup begin put
% initialization
/initialize				% - initialize -
{
% 47 vars, but leave slack of 10 entries for custom Postscript fragments
userdict /Adobe_IllustratorA_AI3_vars 57 dict dup begin put
% paint operands
/_lp /none def
/_pf {} def
/_ps {} def
/_psf {} def
/_pss {} def
/_pjsf {} def
/_pjss {} def
/_pola 0 def
/_doClip 0 def
% paint operators
/cf	currentflat def	% - cf flatness
% typography operands
/_tm matrix def
/_renderStart [/e0 /r0 /a0 /o0 /e1 /r1 /a1 /i0] def 
/_renderEnd [null null null null /i1 /i1 /i1 /i1] def
/_render -1 def
/_rise 0 def
/_ax 0 def			% x character spacing	(_ax, _ay, _cx, _cy follows awidthshow naming convention)
/_ay 0 def			% y character spacing
/_cx 0 def			% x word spacing
/_cy 0 def			% y word spacing
/_leading [0 0] def
/_ctm matrix def
/_mtx matrix def
/_sp 16#020 def
/_hyphen (-) def
/_fScl 0 def
/_cnt 0 def
/_hs 1 def
/_nativeEncoding 0 def
/_useNativeEncoding 0 def
/_tempEncode 0 def
/_pntr 0 def
/_tDict 2 dict def
% typography operators
/Tx {} def
/Tj {} def
% compound path operators
/CRender {} def
% printing
/_AI3_savepage {} def
% color operands
/_gf null def
/_cf 4 array def
/_if null def
/_of false def
/_fc {} def
/_gs null def
/_cs 4 array def
/_is null def
/_os false def
/_sc {} def
/_i null def
Adobe_IllustratorA_AI3 begin
Adobe_IllustratorA_AI3
	{
	dup xcheck
		{
		bind
		} if
	pop pop
	} forall
end
end
Adobe_IllustratorA_AI3 begin
Adobe_IllustratorA_AI3_vars begin
newpath
} def
/terminate				% - terminate -
{
end
end
} def
% definition operators
/_					% - _ null
null def
/ddef				% key value ddef -
{
Adobe_IllustratorA_AI3_vars 3 1 roll put
} def
/xput				% key value literal xput -
{
dup load dup length exch maxlength eq
	{
	dup dup load dup
	length 2 mul dict copy def
	} if
load begin def end
} def
/npop				% integer npop -
{
	{
	pop
	} repeat
} def
% marking operators
/sw					% ax ay string sw x y 
{
dup length exch stringwidth
exch 5 -1 roll 3 index 1 sub mul add
4 1 roll 3 1 roll 1 sub mul add
} def
/swj				% cx cy fillchar ax ay string swj x y
{
dup 4 1 roll
dup length exch stringwidth 
exch 5 -1 roll 3 index 1 sub mul add
4 1 roll 3 1 roll 1 sub mul add 
6 2 roll /_cnt 0 ddef
{1 index eq {/_cnt _cnt 1 add ddef} if} forall pop
exch _cnt mul exch _cnt mul 2 index add 4 1 roll 2 index add 4 1 roll pop pop
} def
/ss					% ax ay string matrix ss -
{
4 1 roll
	{				% matrix ax ay char 0 0 {proc} -
	2 npop 
	(0) exch 2 copy 0 exch put pop
	gsave
	false charpath currentpoint
	4 index setmatrix
	stroke
	grestore
	moveto
	2 copy rmoveto
	} exch cshow
3 npop
} def
/jss				% cx cy fillchar ax ay string matrix jss -
{
4 1 roll
	{				% cx cy fillchar matrix ax ay char 0 0 {proc} -   
	2 npop 
	(0) exch 2 copy 0 exch put 
	gsave
	_sp eq 
		{
		exch 6 index 6 index 6 index 5 -1 roll widthshow  
		currentpoint
		}
		{
		false charpath currentpoint
		4 index setmatrix stroke
		}ifelse
	grestore
	moveto
	2 copy rmoveto
	} exch cshow
6 npop
} def
% path operators
/sp					% ax ay string sp -
{
	{
	2 npop (0) exch
	2 copy 0 exch put pop
	false charpath
	2 copy rmoveto
	} exch cshow
2 npop
} def
/jsp					% cx cy fillchar ax ay string jsp -
{
	{					% cx cy fillchar ax ay char 0 0 {proc} -
	2 npop 
	(0) exch 2 copy 0 exch put 
	_sp eq 
		{
		exch 5 index 5 index 5 index 5 -1 roll widthshow  
		}
		{
		false charpath
		}ifelse
	2 copy rmoveto
	} exch cshow
5 npop
} def
% path construction operators
/pl				% x y pl x y
{
transform
0.25 sub round 0.25 add exch
0.25 sub round 0.25 add exch
itransform
} def
/setstrokeadjust where
	{
	pop true setstrokeadjust
	/c				% x1 y1 x2 y2 x3 y3 c -
	{
	curveto
	} def
	/C
	/c load def
	/v				% x2 y2 x3 y3 v -
	{
	currentpoint 6 2 roll curveto
	} def
	/V
	/v load def
	/y				% x1 y1 x2 y2 y -
	{
	2 copy curveto
	} def
	/Y
	/y load def
	/l				% x y l -
	{
	lineto
	} def
	/L
	/l load def
	/m				% x y m -
	{
	moveto
	} def
	}
	{%else
	/c
	{
	pl curveto
	} def
	/C
	/c load def
	/v
	{
	currentpoint 6 2 roll pl curveto
	} def
	/V
	/v load def
	/y
	{
	pl 2 copy curveto
	} def
	/Y
	/y load def
	/l
	{
	pl lineto
	} def
	/L
	/l load def
	/m
	{
	pl moveto
	} def
	}ifelse
% graphic state operators
/d					% array phase d -
{
setdash
} def
/cf	{} def			% - cf flatness
/i					% flatness i -
{
dup 0 eq
	{
	pop cf
	} if
setflat
} def
/j					% linejoin j -
{
setlinejoin
} def
/J					% linecap J -
{
setlinecap
} def
/M					% miterlimit M -
{
setmiterlimit
} def
/w					% linewidth w -
{
setlinewidth
} def
% path painting operators
/H					% - H -
{} def
/h					% - h -
{
closepath
} def
/N					% - N -
{
_pola 0 eq 
	{
	_doClip 1 eq {clip /_doClip 0 ddef} if 
	newpath
	} 
	{
	/CRender {N} ddef
	}ifelse
} def
/n					% - n -
{N} def
/F					% - F -
{
_pola 0 eq 
	{
	_doClip 1 eq 
		{
		gsave _pf grestore clip newpath /_lp /none ddef _fc 
		/_doClip 0 ddef
		}
		{
		_pf
		}ifelse
	} 
	{
	/CRender {F} ddef
	}ifelse
} def
/f					% - f -
{
closepath
F
} def
/S					% - S -
{
_pola 0 eq 
	{
	_doClip 1 eq 
		{
		gsave _ps grestore clip newpath /_lp /none ddef _sc 
		/_doClip 0 ddef
		}
		{
		_ps
		}ifelse
	} 
	{
	/CRender {S} ddef
	}ifelse
} def
/s					% - s -
{
closepath
S
} def
/B					% - B -
{
_pola 0 eq 
	{
	_doClip 1 eq 	% F clears _doClip
	gsave F grestore 
		{
		gsave S grestore clip newpath /_lp /none ddef _sc
		/_doClip 0 ddef
		} 
		{
		S
		}ifelse
	}
	{
	/CRender {B} ddef
	}ifelse
} def
/b					% - b -
{
closepath
B
} def
/W					% - W -
{
/_doClip 1 ddef
} def
/*					% - [string] * -
{
count 0 ne 
	{
	dup type (stringtype) eq {pop} if
	} if 
_pola 0 eq {newpath} if
} def
% group operators
/u					% - u -
{} def
/U					% - U -
{} def
/q					% - q -
{
_pola 0 eq {gsave} if
} def
/Q					% - Q -
{
_pola 0 eq {grestore} if
} def
/*u					% - *u -
{
_pola 1 add /_pola exch ddef
} def
/*U					% - *U -
{
_pola 1 sub /_pola exch ddef 
_pola 0 eq {CRender} if
} def
/D					% polarized D -
{pop} def
/*w					% - *w -
{} def
/*W					% - *W -
{} def
% place operators
/`					% matrix llx lly urx ury string ` -
{
/_i save ddef
6 1 roll 4 npop
concat pop
userdict begin
/showpage {} def
0 setgray
0 setlinecap
1 setlinewidth
0 setlinejoin
10 setmiterlimit
[] 0 setdash
newpath
0 setgray
false setoverprint
} def
/~					% - ~ -
{
end
_i restore
} def
% color operators
/O					% flag O -
{
0 ne
/_of exch ddef
/_lp /none ddef
} def
/R					% flag R -
{
0 ne
/_os exch ddef
/_lp /none ddef
} def
/g					% gray g -
{
/_gf exch ddef
/_fc
{ 
_lp /fill ne
	{
	_of setoverprint
	_gf setgray
	/_lp /fill ddef
	} if
} ddef
/_pf
{
_fc
fill
} ddef
/_psf
{
_fc
ashow
} ddef
/_pjsf
{
_fc
awidthshow
} ddef
/_lp /none ddef
} def
/G					% gray G -
{
/_gs exch ddef
/_sc
{
_lp /stroke ne
	{
	_os setoverprint
	_gs setgray
	/_lp /stroke ddef
	} if
} ddef
/_ps
{
_sc
stroke
} ddef
/_pss
{
_sc
ss
} ddef
/_pjss
{
_sc
jss
} ddef
/_lp /none ddef
} def
/k					% cyan magenta yellow black k -
{
_cf astore pop
/_fc
{
_lp /fill ne
	{
	_of setoverprint
	_cf aload pop setcmykcolor
	/_lp /fill ddef
	} if
} ddef
/_pf
{
_fc
fill
} ddef
/_psf
{
_fc
ashow
} ddef
/_pjsf
{
_fc
awidthshow
} ddef
/_lp /none ddef
} def
/K					% cyan magenta yellow black K -
{
_cs astore pop
/_sc
{
_lp /stroke ne
	{
	_os setoverprint
	_cs aload pop setcmykcolor
	/_lp /stroke ddef
	} if
} ddef
/_ps
{
_sc
stroke
} ddef
/_pss
{
_sc
ss
} ddef
/_pjss
{
_sc
jss
} ddef
/_lp /none ddef
} def
/x					% cyan magenta yellow black name gray x -
{
/_gf exch ddef
findcmykcustomcolor
/_if exch ddef
/_fc
{ 
_lp /fill ne
	{
	_of setoverprint
	_if _gf 1 exch sub setcustomcolor
	/_lp /fill ddef
	} if
} ddef
/_pf
{
_fc
fill
} ddef
/_psf
{
_fc
ashow
} ddef
/_pjsf
{
_fc
awidthshow
} ddef
/_lp /none ddef
} def
/X					% cyan magenta yellow black name gray X -
{
/_gs exch ddef
findcmykcustomcolor
/_is exch ddef
/_sc
{
_lp /stroke ne
	{
	_os setoverprint
	_is _gs 1 exch sub setcustomcolor
	/_lp /stroke ddef
	} if
} ddef
/_ps
{
_sc
stroke
} ddef
/_pss
{
_sc
ss
} ddef
/_pjss
{
_sc
jss
} ddef
/_lp /none ddef
} def
% locked object operator
/A					% value A -
{
pop
} def
currentdict readonly pop end
setpacking
% annotate page operator
/annotatepage
{
} def
Adobe_cmykcolor /initialize get exec
Adobe_cshow /initialize get exec
Adobe_customcolor /initialize get exec
Adobe_IllustratorA_AI3 /initialize get exec
0 A
0 i 0 J 0 j 1 w 4 M []0 d
%AI3_Note:
0 D
-351 0 m
945 0 L
(N) *
u
u
0 O
0 g
0.6 w
224.1251 92.5499 m
224.5739 93.5999 224.2739 95.8499 220.9751 95.9999 C
221.3501 97.1999 L
240.7003 97.1999 L
240.2503 95.9999 L
237.914 95.8664 236.2741 94.7999 235.3003 92.5499 C
235.374 92.5499 222.8694 46.7216 222.8489 46.6494 c
222.1364 44.1369 224.2739 42.9744 225.8115 43.1994 C
225.774 43.1994 225.549 41.9994 y
206.2269 41.9994 l
206.6488 43.1994 l
208.1488 43.1994 210.6238 44.3994 211.5238 46.4994 c
224.0864 92.5124 l
F
330.94 97.1999 m
317.1399 97.1999 L
316.8399 95.9999 l
317.6649 95.9999 l
316.8399 95.9999 L
317.6649 95.9999 L
F
317.1399 97.1999 m
331.6 97.1999 l
331.15 95.9999 l
330.4 95.9999 l
328.675 95.7749 327.025 95.0249 326.275 92.5499 C
312.8873 43.6119 L
312.6127 41.9638 310.9898 41.9994 Y
306.3248 41.9994 l
281.1995 84.2998 281.162 84.4873 v
270.9677 48.6016 270.8494 46.6494 v
270.6994 44.1744 272.0494 43.1994 274.3744 43.1994 C
274.1495 41.9994 l
259.7493 41.9994 259.5618 42.0744 v
260.0652 43.1994 259.8993 43.1994 v
261.3993 43.1994 264.0993 44.3994 264.5494 46.6494 c
276.8495 91.9499 L
277.1495 94.2749 275.2328 95.9999 272.8744 95.9999 C
273.2644 97.1999 L
283.187 97.1999 L
284.6923 97.0745 285.7653 97.4423 287.8896 93.4499 C
310.1721 56.3245 L
320.1399 92.5499 L
320.4999 94.8749 318.8021 95.9999 317.6649 95.9999 c
F
537.7021 46.6494 m
537.7771 43.9494 535.9771 43.1994 534.4021 43.1994 C
534.1021 41.9994 L
552.7023 41.9994 L
553.0748 43.1994 L
549.6273 43.1994 549.3273 45.3744 548.8022 46.6494 C
540.1022 95.3999 L
539.7272 96.9749 538.0021 97.1999 536.8771 97.1999 C
526.077 97.1999 l
525.702 95.9999 L
527.502 95.9999 529.002 94.5749 527.652 92.5499 C
494.9475 46.6494 l
493.8225 45.5244 492.4903 43.4703 488.4266 43.1994 C
487.9766 41.9994 L
502.9018 41.9994 L
503.3373 43.1994 L
502.4973 42.9594 500.6893 44.4369 502.2677 46.6494 C
502.2661 46.6494 513.1019 61.7246 Y
524.127 61.7246 l
525.852 61.7246 528.627 61.7246 530.3396 60.7495 c
534.2059 66.1582 l
537.7021 46.6494 L
f
1 g
534.0646 66.9746 m
F
534.2146 65.9996 m
F
534.0571 66.9746 m
516.8894 66.9746 L
530.63 86.2474 L
530.6521 86.1748 534.0496 66.9746 534.0571 66.9746 c
f
0 g
458.1275 92.5499 m
458.5763 93.5999 458.2763 95.8499 454.9775 95.9999 C
455.3525 97.1999 L
474.7027 97.1999 L
474.2527 95.9999 L
471.9164 95.8664 470.2764 94.7999 469.3026 92.5499 C
469.3764 92.5499 456.8718 46.7216 456.8513 46.6494 c
456.1388 44.1369 458.2763 42.9744 459.8138 43.1994 C
459.7763 43.1994 459.5513 41.9994 y
440.2293 41.9994 l
440.6511 43.1994 l
442.1512 43.1994 444.6262 44.3994 445.5262 46.4994 c
458.0888 92.5124 l
F
399.4007 97.1999 m
365.5754 97.1849 L
365.2004 95.9849 L
367.5254 95.9999 368.7254 94.2749 368.2354 92.5499 C
355.6753 46.5594 L
354.8128 44.6244 353.8003 43.1994 350.8752 43.1844 C
350.5752 41.9844 L
369.7004 41.9844 L
370.0004 43.2594 L
369.4004 43.2594 L
367.8254 43.7244 366.4754 44.9244 367.0379 46.7844 C
379.6755 92.5349 L
394.0007 92.5199 394.0007 92.5349 V
398.6507 92.6249 401.1107 88.2598 400.7507 85.2598 C
400.7507 80.3247 397.6757 75.7497 393.2507 74.3097 C
388.3006 72.4497 381.3255 72.9747 377.8755 73.9497 C
376.0005 71.4597 L
379.6005 68.0996 382.1506 65.1746 386.1256 58.9495 C
393.3257 46.6494 404.8008 38.2943 417.4009 38.4593 C
420.4384 38.6243 424.5926 38.6629 426.2885 42.2244 c
426.6635 43.0119 425.6885 42.4494 425.951 42.6219 C
410.9508 40.9493 408.7008 46.7994 399.7007 59.0995 C
396.8507 63.4496 393.8507 67.9496 391.9756 68.6846 C
397.7507 69.8996 403.7508 71.3997 408.4008 76.2597 C
412.4509 81.2248 413.5009 85.9498 411.4008 90.6598 C
407.5758 98.0999 400.4507 96.9749 399.4007 97.1999 c
F
U
U
1 w
948 698 m
948 -598 L
(N) *
842 698 m
842 -598 L
(N) *
-351 -48 m
945 -48 L
(N) *
-351 92 m
945 92 L
(N) *
-351 45.125 m
945 45.125 L
(N) *
0 O
0 g
0.258 w
80.7297 56.7368 m
84.192 63.1358 87.7402 68.819 91.7645 75.0836 c
94.4705 79.296 99.1647 85.2336 100.6191 88.1399 c
100.7978 88.4971 100.2885 88.8163 100.3728 89.0906 c
100.5351 89.6188 100.7703 90.0013 100.45 90.6977 c
99.7316 92.2603 99.0866 92.6473 97.988 93.5539 c
98.1502 93.42 96.3861 92.8385 96.8086 93.2387 c
94.5411 90.7388 l
92.7504 88.2223 l
91.5459 87.0077 l
90.3928 84.681 l
89.8209 83.8616 l
88.4433 82.2397 l
87.346 80.0647 l
87.0787 79.5762 86.7027 79.1024 86.1763 78.0343 c
84.4752 75.8991 l
84.2919 75.5527 83.9877 74.9778 v
83.8354 74.6902 83.6025 74.3682 83.4481 73.9583 c
83.3364 73.6617 82.5365 73.1329 82.4757 72.3789 c
82.4457 72.0075 81.711 70.571 81.4558 70.0502 c
81.2428 69.6156 80.4645 68.3873 79.8984 67.3457 c
79.3236 66.2879 80.0052 67.6885 79.4378 66.6499 c
78.6584 65.2231 78.1947 64.0265 78.1575 63.9535 c
74.0231 56.3573 73.5494 55.4297 v
71.7388 51.8836 65.2718 38.7731 62.7558 29.4599 c
62.7378 29.3934 62.3221 29.4378 62.0639 29.4378 C
64.7385 65.7493 66.074 102.1634 64.6438 138.571 C
64.8163 138.571 64.9874 138.5802 65.1595 138.5664 c
89.0923 136.6402 112.7731 135.9906 136.6228 136.6041 c
157.8158 137.1493 178.8765 139.7858 200.0929 139.603 C
200.0929 139.2805 199.9639 139.0225 199.8349 138.9903 c
199.026 138.788 196.148 137.519 192.5262 135.7818 C
190.8502 134.9779 189.9952 134.5528 190.9134 135.0011 C
190.3213 134.712 189.3289 134.0267 188.7152 133.7214 C
187.8345 133.2833 187.0657 133.0889 186.1653 132.6288 C
185.2681 132.1703 185.1274 131.9681 184.3712 131.5741 C
184.0454 131.4044 183.8497 131.6213 183.5266 131.451 C
183.1505 131.2528 182.9056 130.9255 182.5352 130.7275 C
182.3138 130.6093 179.1628 128.6956 178.9429 128.5772 C
178.1507 128.2283 179.6371 128.8526 178.7493 128.3571 C
178.0063 127.9424 178.187 128.4353 177.4944 128.0338 C
176.9744 127.7325 176.3421 127.049 175.8592 126.7592 C
175.3778 126.4702 175.6907 126.833 175.2537 126.5589 C
174.0233 125.7874 173.3541 125.3644 173.0181 125.13 C
172.2698 124.6829 172.4748 124.8744 169.9756 123.4372 C
169.2498 122.9394 165.8008 120.6402 164.8244 119.9383 C
164.0898 119.4564 166.4711 120.8494 165.9396 120.4671 C
165.0052 119.9951 164.4204 119.5442 163.5837 118.9668 C
163.0937 118.6286 161.4388 117.2623 160.9392 116.9338 C
159.6747 116.1023 158.6318 115.3074 157.2652 114.5772 C
156.6189 115.4439 155.186 117.0674 154.3983 117.7744 c
156.1492 116.203 149.5395 121.3631 147.2475 122.6298 c
145.0396 123.8501 152.4249 119.0933 152.4315 119.2951 c
151.5119 119.4476 148.8518 121.601 v
149.7205 120.8978 149.5238 121.1961 147.8725 122.2334 c
147.5309 122.448 143.9316 124.0263 143.5675 124.2036 c
142.8101 124.5725 143.0676 124.269 142.2794 124.5853 c
141.814 124.7721 141.8597 124.8211 141.3854 124.9908 c
141.0147 125.1234 142.8344 124.3479 142.459 124.4705 c
142.1905 124.5583 139.0811 125.8939 138.1641 126.1546 c
142.5064 124.9203 140.718 125.3221 134.9771 126.8163 c
133.517 127.1964 128.8516 127.6126 128.207 127.7505 c
127.7531 127.8477 128.0724 127.4234 127.6173 127.5101 c
127.0272 127.6225 127.7264 127.3394 127.1363 127.4356 c
126.4549 127.5466 126.5482 127.6473 125.8702 127.7388 c
125.5146 127.7868 125.9338 127.8323 125.5799 127.8754 c
124.9387 127.9535 126.6929 127.4081 126.0596 127.4717 c
125.2477 127.5533 125.3625 127.4805 124.8794 127.5198 c
124.4519 127.5546 125.4093 127.4775 124.9074 127.5338 c
123.7011 127.6694 123.6804 127.315 121.9183 127.3289 c
121.2999 127.3338 120.6047 127.3353 120.2424 127.3362 c
119.5299 127.3379 117.0278 127.0787 116.3735 127.0753 c
115.6694 127.0715 115.8747 126.7656 115.2989 126.7571 c
113.5021 126.7308 112.6188 126.6102 113.5026 126.8069 c
111.9304 126.4569 112.334 126.5097 110.295 125.8692 c
109.6645 125.6711 107.2135 125.2841 106.1796 125.0329 c
109.448 125.827 103.6016 124.1231 103.3162 124.0877 c
102.7205 124.0138 101.1294 123.237 100.5488 123.07 c
99.3262 122.7182 99.2156 122.7041 98.811 122.4908 c
98.0074 122.0669 98.0046 122.0588 97.0583 121.7039 c
96.6269 121.5421 95.9328 121.2574 95.4888 121.1125 c
94.8506 120.9043 94.0996 120.3879 93.49 120.1007 c
92.6349 119.6979 93.1526 119.8661 92.1498 119.4263 c
91.6508 119.2074 90.8397 119.0644 90.1314 118.6744 c
89.757 118.4683 89.3849 118.1396 89.014 117.9521 c
88.736 117.8116 87.9029 117.268 87.626 117.1438 c
86.6643 116.7125 86.4935 116.4343 85.6791 115.981 C
84.0393 115.0682 82.6957 113.8035 80.8613 112.5055 C
80.8977 111.6102 80.7687 111.4812 81.4137 110.9652 c
81.7769 110.6746 82.4457 110.7072 84.1792 111.2371 C
95.4746 117.5441 107.7174 120.7682 120.3781 121.4101 c
131.4951 121.9738 144.0109 119.5372 151.0733 110.1912 C
146.0363 106.1035 141.1489 102.4735 136.2218 98.3052 c
135.8516 97.9921 135.353 97.2911 134.984 96.9762 c
134.697 96.7313 134.0016 96.468 133.4812 96.0198 c
133.227 95.8008 133.3599 95.5813 133.1062 95.3613 c
132.5778 94.9031 131.7728 94.6052 131.1378 93.9796 c
130.679 93.5276 130.4667 93.3165 129.8757 92.7861 c
129.6261 92.5621 129.2478 91.9505 128.9989 91.7251 c
128.5256 91.2967 128.0535 90.8658 127.5826 90.4321 c
127.3206 90.1909 126.672 89.8198 126.4108 89.5768 c
125.7001 88.9157 125.5083 88.8932 124.8037 88.2184 c
124.6074 88.0305 123.9686 87.6413 123.6979 87.3567 c
123.1513 86.782 122.587 86.0338 122.1293 85.7259 c
121.2621 85.1427 121.2108 84.8677 120.5252 84.2484 c
120.0943 83.8592 119.9328 83.7405 119.4783 83.4329 c
119.1976 83.243 118.9527 83.0303 118.7935 82.7475 c
118.5988 82.4015 117.9093 82.3818 117.6491 82.0841 c
116.4891 80.7567 114.7338 79.048 113.6133 77.8345 c
113.388 77.5905 113.1684 77.6112 112.9555 77.3838 c
112.4902 76.8867 112.3316 76.6009 111.5348 75.8122 c
111.2581 75.5382 110.6313 75.1682 110.4222 74.9557 c
109.6401 74.161 109.6744 73.895 109.4202 73.6689 c
108.9896 73.286 108.4134 72.9104 107.9405 72.546 c
107.4103 72.1375 106.9995 71.4537 106.5831 70.9244 c
106.1667 70.395 105.7822 70.4368 105.1915 69.7132 c
104.4792 68.8406 104.0161 68.3015 103.622 67.8429 c
103.2997 67.4679 103.01 67.3299 102.7036 66.9505 c
102.4751 66.6675 102.2785 66.34 101.9696 66.1446 c
100.5351 65.2365 100.1894 64.589 99.1618 63.5468 c
98.9358 63.3177 98.356 63.3751 97.7259 62.4592 c
97.2682 61.7938 95.488 59.7927 95.0238 59.296 c
94.6458 58.8916 95.6455 59.7545 94.6999 58.7212 c
94.1041 58.0703 94.0282 57.9328 93.4373 57.2774 c
93.1483 56.957 92.4725 56.5071 92.1837 56.1859 c
91.6801 55.6259 91.3862 55.2339 90.9286 54.6327 c
90.7017 54.3346 90.5603 54.8278 89.4553 53.0173 c
88.9481 52.1863 88.4963 51.4739 87.2122 50.5996 c
86.5619 50.1569 86.8193 49.2809 85.971 48.8758 c
84.877 48.3535 85.3462 48.7523 85.214 48.3473 c
85.2736 48.5302 82.9494 46.4429 82.4404 44.7932 C
82.1036 44.4055 81.3585 43.5997 80.9811 43.1499 C
80.6488 42.754 80.3015 42.5919 79.9403 42.1477 C
79.4727 41.5727 79.2454 40.8466 78.75 40.2367 C
78.3699 39.7687 78.2416 39.68 77.8528 39.2011 C
77.393 38.6348 76.6715 38.0638 76.2097 37.4951 C
75.762 36.9436 75.316 36.0072 74.8766 35.4662 C
73.9866 34.3703 73.4158 34.2107 72.3314 32.4468 C
70.6645 30.3736 69.3051 28.6549 68.6428 27.7608 C
68.3848 28.1477 68.2558 28.2767 Y
72.2548 39.2417 79.0138 53.3341 80.7297 56.7368 C
f
1 g
113.6601 107.8593 m
113.275 107.9928 112.8211 108.0582 112.3828 108.1651 c
111.6619 108.3411 111.0102 108.367 110.4158 108.2754 C
107.353 107.803 105.8079 104.2092 104.1176 101.9353 C
104.4218 101.581 104.7683 101.3217 105.1405 101.136 c
105.5953 100.9089 105.8772 101.2189 106.3322 101.0028 c
107.0845 100.6453 108.1165 100.3873 108.7384 100.8657 c
109.0392 101.0971 109.9952 100.8353 110.3307 100.9405 c
111.7961 101.4 111.3386 101.9055 113.0747 102.6332 c
114.1795 103.0962 114.9535 104.7733 114.618 106.8239 c
114.5206 107.4195 114.1416 107.6923 113.6601 107.8593 c
f
0 g
153.6532 105.8052 m
157.6887 98.0474 154.9163 88.7388 149.9745 81.5996 c
144.6018 73.838 136.6091 70.3401 128.8854 66.3315 C
127.4438 58.2161 129.2197 50.0597 131.8536 42.3816 c
135.8513 30.7278 142.4029 21.5446 152.8227 14.3916 c
152.9922 14.2752 152.8792 13.7859 152.8792 13.4419 C
124.8941 15.7318 97.0878 16.4313 68.7663 13.2325 c
68.5998 13.2136 68.3946 13.4675 68.5365 13.685 c
76.0601 25.2094 83.1108 35.2492 91.9794 45.4443 c
111.3514 67.714 130.6813 88.2953 153.6532 105.8052 C
f
179.5079 75.8638 m
182.936 87.3584 185.258 97.4203 189.052 107.5914 C
192.4819 116.6411 200.3831 133.0886 202.0601 135.9265 c
202.1322 136.0484 201.6871 136.5571 201.8989 136.249 C
186.6332 130.1905 172.7144 121.1105 159.8452 110.9652 C
160.4788 110.0258 161.1381 109.0413 161.5797 108.0231 c
161.8127 107.4859 162.42 105.9762 162.2068 106.3849 c
162.0381 106.7082 162.5941 105.6519 162.7485 105.0153 c
162.8515 104.5907 163.0723 103.647 163.1538 103.2167 c
163.2825 102.5373 163.6435 101.4646 163.7243 100.7754 c
163.83 99.8753 164.0637 99.2192 163.9356 98.3217 c
163.7151 96.7753 163.9815 96.9982 163.9709 95.8737 c
163.9617 94.914 163.8259 96.0088 163.7935 95.2294 c
163.7719 94.7097 163.8259 93.1345 163.6307 92.6614 c
163.3866 92.0697 163.8318 92.2376 163.0558 90.5894 c
162.6264 89.6772 162.6171 89.5905 162.3052 88.7738 c
162.1399 88.3409 162.0994 87.8851 161.9275 87.407 c
161.6611 86.6666 160.8221 85.1645 160.796 84.8851 c
160.7358 84.2397 160.7358 84.6267 159.7432 83.1018 c
159.057 82.0478 158.4138 81.0147 157.3076 79.9496 c
157.0008 79.6542 157.0123 79.1756 156.7305 78.8613 C
156.7305 78.8613 L
156.2608 78.3371 155.5759 78.0477 154.6488 76.8161 C
154.3497 76.5124 154.3054 75.9559 153.9998 75.6623 C
153.3375 75.026 152.9183 75.0582 152.2273 74.4666 C
151.5539 73.89 151.0609 73.4037 150.0133 72.1722 C
148.9053 71.303 147.2949 70.7057 146.5005 70.156 C
146.3244 69.9232 145.8135 69.5511 144.88 68.999 C
144.5114 68.781 144.0769 68.5349 143.5711 68.2581 C
143.2734 68.0953 142.951 67.6638 142.6028 67.4793 C
140.87 66.8248 138.9485 65.852 136.2383 64.5255 C
136.1942 64.0071 136.1591 63.4908 136.133 62.9762 c
136.1044 62.4152 135.9573 61.8563 135.9496 61.2987 c
135.9448 60.9549 135.9439 60.4826 135.9469 60.1398 c
135.9515 59.623 136.0939 59.2361 136.1159 58.7209 c
136.1361 58.2464 136.1637 57.3854 136.1985 56.9116 c
136.274 55.8827 136.5155 54.7209 136.6576 53.6896 c
136.6932 53.431 136.4729 53.4303 136.5126 53.1714 c
136.6617 52.1985 136.9769 51.8379 137.1369 51.0811 c
137.2292 50.6443 137.0977 50.0755 137.2959 49.1807 c
137.3933 48.7413 137.4952 48.5626 137.6015 48.1288 c
137.8041 47.3024 138.0229 46.2281 138.2577 45.4208 c
138.3569 45.0798 138.4589 44.7405 138.5638 44.4027 c
138.697 43.9732 138.964 43.9332 139.1064 43.5087 c
139.3712 42.7194 139.3936 42.3253 139.6895 41.5517 c
139.9866 40.7749 140.3663 39.8867 140.7561 38.4689 c
140.843 38.1532 141.2752 37.9973 141.4092 37.6986 c
141.9199 36.5602 142.1723 35.3717 143.172 34.0651 c
143.3491 33.8337 143.1819 33.4222 143.3153 33.1693 c
143.4962 32.8265 143.677 32.8751 143.8594 32.5392 c
144.49 31.3784 144.7536 30.7638 145.4991 29.5836 c
145.6707 29.3119 146.0423 28.1477 146.4051 28.003 c
146.8068 27.8428 146.8822 27.5428 147.1253 27.191 c
147.5149 26.627 148.1254 25.393 148.5778 24.8894 c
150.0021 23.304 151.1264 21.4864 153.8299 19.1691 c
154.2194 18.8352 154.5906 18.4749 154.984 18.1326 c
155.5624 17.6293 156.5548 16.7753 156.7859 17.1802 c
167.346 35.6833 173.6768 55.5466 179.5079 75.8638 c
F
1 w
144 698 m
144 -598 L
(N) *
77 698 m
77 -598 L
(N) *
gsave annotatepage grestore showpage
Adobe_IllustratorA_AI3 /terminate get exec
Adobe_customcolor /terminate get exec
Adobe_cshow /terminate get exec
Adobe_cmykcolor /terminate get exec
Adobe_packedarray /terminate get exec

%%EndDocument
 @endspecial 587 6179 a Fv(Centre)i(National)f(de)g(la)g(Recherche)h
(Scienti\002que)100 b(Institut)20 b(National)e(de)g(Recherche)h(en)f
(Inf)n(or)r(matique)388 6258 y(\()p Fu(URA)g Fv(227\))h(Univ)n(ersit)
948 6257 y(\264)941 6258 y(e)g(de)f(Rennes)g(1)h(\226)f(Insa)h(de)f
(Rennes)100 b(et)19 b(en)f(A)n(utomatique)h(\226)g(unit)2737
6257 y(\264)2730 6258 y(e)f(de)h(recherche)f(de)h(Rennes)p
eop
%%Page: 2 4
2 3 bop 173 688 a Ft(Optimisation)30 b(du)h(RPC)f(Sun)1552
687 y(\036)1542 688 y(a)f(l'aide)i(de)f(la)g(sp)2339
687 y(\264)2332 688 y(ecialisation)g(automatique)g(de)1626
838 y(pr)n(ogrammes)0 1092 y Fq(R)65 1091 y(\264)60 1092
y(esum)249 1091 y(\264)244 1092 y(e)25 b(:)69 b Fr(La)25
b(rapidit)5 b(\264)-33 b(e)23 b(des)i(appels)g(de)f(proc)5
b(\264)-33 b(edure)27 b(\036)-33 b(a)25 b(distance)f(\(RPC\))i(est)f
(un)f(soucis)h(majeur)e(dans)i(les)g(syst)5 b(\036)-33
b(emes)25 b(distrib)n(u)5 b(\264)-33 b(es.)0 1192 y(La)30
b(plupart)e(des)35 b(\264)-33 b(etudes)29 b(qui)h(visent)k(\036)-33
b(a)30 b(produire)e(des)i(RPC)h(ef)n(\002caces)e(consistent)h(soit)g
(en)f(de)h(nouv)o(elles)e(impl)5 b(\264)-33 b(ementations)28
b(du)0 1291 y(paradigme)14 b(RPC,)j(soit)f(en)f(des)h(optimisations)f
(manuelles)g(des)h(sections)f(critiques)g(du)h(code.)22
b(Ce)17 b(rapport)d(pr)5 b(\264)-33 b(esente)15 b(une)g(e)o(xp)5
b(\264)-33 b(erience)0 1391 y(d'optimisation)26 b Fp(automatique)f
Fr(d'une)i(impl)5 b(\264)-33 b(ementation)25 b(RPC)k(d)5
b(\264)-33 b(ej)5 b(\036)-33 b(a)28 b Fp(e)n(xistante)g
Fr(et)g Fp(commer)m(ciale)p Fr(,)h(le)f(RPC)i(de)d(Sun.)48
b(La)28 b(v)o(ersion)0 1490 y(optimis)5 b(\264)-33 b(ee)20
b(du)g(RPC)i(de)e(Sun)h(est)g(produite)e(par)h(un)g(sp)5
b(\264)-33 b(ecialiseur)20 b(automatique)f(de)h(programmes.)k(Son)c(e)o
(x)5 b(\264)-33 b(ecution)18 b(est)k(jusqu')5 b(\036)-33
b(a)19 b(1,5)0 1590 y(fois)g(fois)g(plus)f(rapide)g(que)h(le)g(RPC)h
(de)f(Sun)f(d'origine.)23 b(En)18 b(e)o(xaminant)f(le)i(code)g(sp)5
b(\264)-33 b(ecialis)5 b(\264)-33 b(e,)19 b(on)f(ne)h(trouv)o(e)e(pas)i
(d'opportunit)5 b(\264)-33 b(es)16 b(de)0 1690 y(sp)5
b(\264)-33 b(ecialisation)20 b(additionnelle)e(qui)i(apporterait)e(une)
i(am)5 b(\264)-33 b(elioration)18 b(signi\002cati)n(v)o(e)i(sans)g
(restructuration)e(majeure)h(du)h(code.)125 1861 y(Les)j(contrib)n
(utions)f(contenues)g(dans)h(ces)h(tra)n(v)n(aux)f(sont)g(:)33
b(\(1\))22 b(le)i(code)f(optimis)5 b(\264)-33 b(e)23
b(est)h(produit)e(de)i(mani)5 b(\036)-33 b(ere)22 b(s)7
b(\210)-35 b(ure)24 b(par)f(un)g(outil)0 1960 y(automatique,)28
b(ce)g(qui)g(n'entra)n(\210)-26 b(\021ne)26 b(aucun)h(co)7
b(\210)-35 b(ut)28 b(de)g(maintenance)e(additionnel)h(;)32
b(\(2\))h(\036)-33 b(a)29 b(notre)e(connaissance,)h(il)h(s'agit)f(l)5
b(\036)-33 b(a)29 b(de)f(la)0 2060 y(premi)5 b(\036)-33
b(ere)18 b(e)o(xp)5 b(\264)-33 b(erience)18 b(r)5 b(\264)-33
b(eussie)20 b(de)f(sp)5 b(\264)-33 b(ecialisation)19
b(d'un)g(code)g(syst)5 b(\036)-33 b(eme)19 b(commercial,)f(m)7
b(\210)-35 b(ur)19 b(et)h(repr)5 b(\264)-33 b(esentatif)19
b(;)h(\(3\))f(le)h(RPC)h(de)f(Sun)0 2160 y(optimis)5
b(\264)-33 b(e)20 b(est)h(signi\002cati)n(v)o(ement)d(plus)i(rapide)f
(que)h(le)h(code)e(d'origine.)125 2331 y(Les)25 b(\002chiers)f(utilis)5
b(\264)-33 b(es)26 b(dans)e(cette)h(e)o(xp)5 b(\264)-33
b(erience,)23 b(y)i(compris)f(les)h(\002chiers)g(de)f(l'impl)5
b(\264)-33 b(ementation)22 b(sp)5 b(\264)-33 b(ecialis)5
b(\264)-33 b(ee,)26 b(sont)f(publique-)0 2444 y(ment)20
b(disponibles)567 2414 y(**)673 2444 y(.)0 2662 y Fq(Mots-cl)273
2661 y(\264)268 2662 y(e)h(:)61 b Fr(\264)-33 b(e)n(v)n(aluation)19
b(partielle,)i(protocole)f(RPC,)j(RPC)f(de)g(Sun,)f(syst)5
b(\036)-33 b(emes)21 b(distrib)n(u)5 b(\264)-33 b(es,)22
b(syst)5 b(\036)-33 b(emes)21 b(g)5 b(\264)-33 b(en)5
b(\264)-33 b(eriques,)20 b(optimisation)0 2762 y(automatique)53
5235 y Fn(**)120 5259 y Fm(Contacter)f(pour)f(cela)g(les)g(auteurs)k
(\036)-26 b(a)17 b(l'adresse)i Fl(muller@irisa.fr)p eop
%%Page: 3 5
3 4 bop 0 352 a Fp(F)-6 b(ast,)20 b(Optimized)g(Sun)f(RPC)i(Using)f(A)n
(utomatic)f(Pr)l(o)o(gr)o(am)h(Specialization)1623 b
Fr(3)p 0 406 3900 8 v 0 688 a Ft(1)119 b(Intr)n(oduction)0
945 y Fr(Specialization)21 b(is)h(a)g(well)h(kno)n(wn)d(technique)g
(for)h(impro)o(ving)e(the)j(performance)d(of)i(operating)f(systems)i
([3)o(,)g(11)o(,)g(23)o(,)g(27)o(].)30 b(Ho)n(we-)0 1045
y(v)o(er)m(,)22 b(only)h(recently)e(ha)n(v)o(e)i(programming)c(tools)k
(be)o(gun)f(to)h(be)g(used)f(to)h(help)g(system)g(programmers)d
(perform)h(specialization.)32 b(T)-7 b(o)0 1145 y(the)19
b(best)g(of)g(our)g(kno)n(wledge,)d(this)k(paper)e(reports)g(the)h
(\002rst)h(successful)f(specialization)f(of)h(a)g(signi\002cant)g(OS)h
(component)c(\(the)j(Sun)0 1244 y(RPC\))24 b(using)f(a)g(partial)g(e)n
(v)n(aluator)-5 b(.)32 b(This)23 b(w)o(ork)g(is)h(signi\002cant)e(for)h
(a)g(combination)e(of)i(three)f(main)h(reasons:)31 b(\(1\))22
b(automatic)g(opti-)0 1344 y(mization)d(of)g(e)o(xisting)g(system)h
(code)f(using)g(a)h(partial)f(e)n(v)n(aluator)f(preserv)o(es)h(the)h
(original)e(source)h(code)g(\(2\))g(specialization)g(applies)0
1443 y(to)i(mature,)f(commercial,)f(representati)n(v)o(e)g(system)i
(code,)f(and)h(\(3\))f(the)h(specialized)f(Sun)h(RPC)h(e)o(xhibits)e
(signi\002cant)g(performance)0 1543 y(gains.)k(W)-7 b(e)22
b(elaborate)d(each)h(reason)f(in)h(turn.)125 1714 y(First,)j(partial-e)
n(v)n(aluation)d(based)i(specialization)g(is)h(qualitati)n(v)o(ely)e
(dif)n(ferent)g(from)g(manual)h(specialization)f(done)h(in)h(the)f
(past)0 1814 y([27)o(,)h(23)o(,)h(3)o(,)g(11)o(].)34
b(Manual)22 b(specialization)g(requires)g(the)i(system)f(programmer)d
(to)j(identify)f(e)n(v)o(ery)g(occurrence)f(of)i(the)g(in)m(v)n
(ariants)0 1913 y(to)30 b(be)f(e)o(xploited)f(and)h(to)g(write)h(the)g
(specialized)f(code)f(e)o(xploiting)g(these)i(in)m(v)n(ariants.)51
b(Although)28 b(this)i(approach)d(may)i(lead)g(to)0 2013
y(signi\002cant)c(performance)d(gains,)k(the)g(manual)e(specialization)
g(process)h(is)i(error)n(-prone)22 b(and)j(results)h(in)f(code)g(that)g
(is)i(e)o(xpensi)n(v)o(e)0 2113 y(to)h(maintain.)48 b(In)28
b(contrast,)h(a)f(partial)g(e)n(v)n(aluator)e(preserv)o(es)h(the)h
(source)g(code,)h(and)e(generates)g(automatically)g(the)h(specialized)0
2212 y(code)g(guided)f(by)h(the)h(declarations)e(of)h(in)m(v)n(ariants)
f(speci\002ed)i(by)f(system)h(programmers.)47 b(Since)28
b(we)h(are)g(specializing)e(mature)0 2312 y(commercial)e(code,)i(the)g
(preserv)n(ation)e(of)h(original)f(code)h(and)g(semantics)h(also)g
(preserv)o(es)e(safety)i(and)f(maintainability)-5 b(.)42
b(In)26 b(our)0 2412 y(vie)n(w)-5 b(,)19 b(tools)h(such)g(as)h(partial)
f(e)n(v)n(aluators)e(may)i(help)g(the)g(industry)e(to)j(address)e(the)h
(operating)e(system)j(code)e(comple)o(xity)f(concerns)0
2511 y(pointed)h(out)h(by)f(an)i(industry)d(panel)i(at)h(OSDI'96.)125
2682 y(Second,)30 b(we)g(specialize)f(mature,)h(commercial)e(code)h
(\(Sun)f(RPC\))j(that)e(we)h(belie)n(v)o(e)e(to)i(be)f(representati)n
(v)o(e)e(of)i(production)0 2782 y(quality)d(code.)46
b(Sun)27 b(RPC)i(is)f(one)f(layer)f(in)i(the)f(communication)e(stack,)k
(and)d(RPC)j(itself)f(is)g(di)n(vided)e(into)h(micro-layers,)g(each)0
2882 y(concerned)22 b(with)j(a)g(reasonably)e(small)i(task,)h(e.g.,)f
(managing)d(the)j(underlying)d(transport)h(protocol)g(such)h(as)h(TCP)h
(or)e(UDP)-9 b(.)25 b(The)0 2981 y(RPC)d(code)d(has)i(been)e(ported)g
(to)h(a)h(v)n(ariety)e(of)h(softw)o(are)g(and)f(hardw)o(are)g
(foundations,)f(while)i(preserving)e(its)j(layered)e(structure.)125
3152 y(Third,)25 b(we)g(obtain)g(signi\002cant)f(performance)f(gains)h
(using)h(partial-e)n(v)n(aluation)d(based)j(specialization.)39
b(In)25 b(our)f(e)o(xperiment,)0 3252 y(the)d(optimized)f(Sun)h(RPC)h
(runs)f(up)g(to)g(1.5)f(times)i(f)o(aster)f(than)g(the)g(original)f
(Sun)h(RPC.)h(In)f(addition,)e(the)j(specialized)e(marshaling)0
3352 y(process)i(runs)h(up)f(to)h(3.75)f(times)h(f)o(aster)g(than)g
(the)g(original)f(one.)32 b(Close)24 b(e)o(xamination)c(of)j(the)g
(specialized)f(code)g(does)h(not)f(re)n(v)o(eal)0 3451
y(further)16 b(optimizations)g(opportunities)f(which)i(w)o(ould)g(lead)
g(to)h(signi\002cant)f(impro)o(v)o(ements)d(without)j(major)g(manual)f
(restructuring.)125 3622 y(Our)26 b(partial-e)n(v)n(aluation)d(based)j
(specialization)g(e)o(xperiment)e(sho)n(ws)j(the)f(promise)g(of)g
(direct)g(industrial)g(rele)n(v)n(ance)f(to)h(com-)0
3722 y(mercial)20 b(systems)g(code.)125 3893 y(The)k(rest)h(of)f(the)h
(paper)f(is)h(or)o(ganized)d(as)j(follo)n(ws.)38 b(Section)25
b(2)f(presents)h(Sun)f(RPC)i(protocol)d(and)h(the)h(optimization)e
(issues.)0 3993 y(Section)h(3)h(e)o(xamines)e(opportunities)g(for)g
(Specialization)h(in)h(the)f(Sun)h(RPC.)g(Section)g(4)f(gi)n(v)o(es)g
(an)h(o)o(v)o(ervie)n(w)d(of)i(the)h(partial)f(e)n(v)n(a-)0
4092 y(luator)e(T)-6 b(empo)21 b(and)h(sho)n(ws)g(its)i(rele)n(v)n
(ance)c(for)i(Sun)g(RPC)i(specialization.)31 b(Section)22
b(5)g(describes)g(the)g(performance)e(e)o(xperiments.)0
4192 y(Section)27 b(6)h(discusses)g(our)f(e)o(xperience)e(with)j
(partial-e)n(v)n(aluation)c(based)k(specialization)e(of)i(Sun)f(RPC.)i
(Section)e(7)g(summarizes)0 4292 y(related)20 b(w)o(ork)f(and)h
(Section)g(8)g(concludes)f(the)h(paper)-5 b(.)0 4643
y Ft(2)119 b(The)31 b(Sun)g(RPC)f(and)h(the)f(Optimization)h(Issues)0
4900 y Fr(The)21 b(Sun)g(RPC)h(\(Remote)f(Procedure)e(Call\))j
(protocol)d(w)o(as)j(introduced)d(in)i(1984)f(to)h(support)f(the)h
(implementation)e(of)h(distrib)n(uted)0 5000 y(services.)k(This)16
b(protocol)e(has)j(become)d(a)j Fp(de)f(facto)g Fr(standard)f(in)h
(distrib)n(uted)f(service)h(design)g(and)f(implementation,)g(e.g.,)h
(NFS)h([22)n(])0 5100 y(and)25 b(NIS)g([29)o(].)39 b(Since)25
b(lar)o(ge)g(netw)o(orks)f(are)h(often)f(heterogeneous,)f(support)h
(for)g(communicating)e(machine)i(independent)f(data)0
5731 y Fm(PI)17 b(n)c(\011)g(1094)p eop
%%Page: 4 6
4 5 bop 0 352 a Fr(4)549 b Fp(Gilles)21 b(Muller)-9 b(,)20
b(Renaud)e(Marlet,)j(Eug)o(en-Nicolae)d(V)-9 b(olansc)o(hi,)18
b(Charles)j(Consel,)f(Calton)g(Pu)g(&)g(Ashvin)g(Goel)p
0 406 3900 8 v 0 688 a Fr(in)m(v)n(olv)o(es)j(encoding)f(and)i
(decoding.)36 b(Such)24 b(en)m(vironments)d(\(e.g.,)k(PVM)g([14)n(])g
(for)f(a)g(message)h(passing)f(model)f(and)h(Stardust)g([5)o(])0
788 y(for)c(a)g(Distrib)n(uted)g(Shared)f(Memory)g(model\))g(often)g
(rely)h(on)g(Sun)g(XDR.)h(The)e(tw)o(o)i(main)f(functionalities)e(of)i
(the)h(Sun)e(RPC)j(are:)104 1025 y(1.)41 b(A)29 b(stub)g(generator)f
(\()p Fk(rpcgen)p Fr(\))f(that)j(produces)d(the)i(client)h(and)e(serv)o
(er)g(stub)i(functions.)50 b(The)29 b(stub)g(functions)f(translate)208
1125 y(procedure)22 b(call)k(parameters)e(into)h(a)h(machine)e
(independent)e(message)j(format)f(called)h(XDR,)h(and)f(XDR)h(messages)
f(back)208 1225 y(into)19 b(procedure)f(parameters.)24
b(The)c(translation)f(of)h(parameters)f(into)h(messages)g(in)g(kno)n
(wn)f(as)i Fp(mar)o(shaling)p Fr(.)104 1391 y(2.)41 b(The)19
b(management)f(of)i(message)g(e)o(xchange)e(through)g(the)j(netw)o
(ork.)125 1628 y(Concretely)-5 b(,)14 b(the)i(Sun)f(RPC)i(code)e
(consists)h(of)f(a)h(set)h(of)e(micro-layers,)f(each)h(one)g(de)n(v)n
(oted)g(to)g(a)h(small)g(task.)24 b(F)o(or)15 b(e)o(xample,)g(there)0
1728 y(are)24 b(micro-layers)e(to)i(write)g(data)g(during)e
(marshaling,)h(to)i(read)e(data)h(during)e(unmarshaling)g(and)h(to)h
(manage)f(speci\002c)h(transport)0 1828 y(protocols)19
b(such)h(as)h(TCP)g(or)f(UDP)-9 b(.)21 b(Each)f(micro-layer)e(has)j(a)g
(generic)e(function,)f(b)n(ut)j(it)g(may)f(ha)n(v)o(e)f(se)n(v)o(eral)h
(implementations.)k(As)0 1927 y(such,)c(the)g(micro-layer)e(or)o
(ganization)f(of)j(RPC)h(code)f(is)h(f)o(airly)f(representati)n(v)o(e)e
(of)i(modular)e(production)g(system)i(softw)o(are.)0
2220 y Fq(A)h(Simple)g(Example)0 2447 y Fr(W)-7 b(e)21
b(consider)f(a)g(simple)h(e)o(xample)e(to)h(illustrates)h(the)f
(micro-layer)e(or)o(ganization)f(of)j(Sun)g(RPC)i(code.)j(The)20
b(function)e Fk(rmin)j Fr(sends)0 2546 y(tw)o(o)f(inte)o(gers)g(to)g(a)
h(remote)e(serv)o(er)m(,)g(which)h(returns)f(their)h(minimum.)125
2718 y(The)26 b(client)h(uses)g Fk(rpcgen)f Fr(\(the)h(RPC)h(stub)f
(compiler\))e(to)i(compile)f(a)h(procedure)d(interf)o(ace)i
(speci\002cation)g(for)g Fk(rmin)h Fr(into)0 2817 y(an)c(assortment)g
(of)g(source)g(\002les.)35 b(These)24 b(\002les)g(implement)e(both)h
(the)g(call)h(on)f(the)g(client')-5 b(s)24 b(side)g(and)f(the)g
(dispatch)g(of)g(procedures)0 2917 y(on)f(the)h(serv)o(er')-5
b(s)23 b(side.)33 b(T)-7 b(o)23 b(emphasize)f(the)g(actual)h(code)f(e)o
(x)o(ecuted,)g(instead)g(of)h(including)e(all)i(the)g(\002les)h
(generated)d(by)h Fk(rpcgen)p Fr(,)0 3016 y(Figure)e(1)g(sho)n(ws)g(an)
g(abstract)g(e)o(x)o(ecution)e(trace)i(of)g(a)h(call)f(to)h
Fk(rmin)p Fr(.)2022 2986 y Fj(1)0 3309 y Fq(P)n(erf)n(ormance)e(of)h
(RPC)0 3536 y Fr(Communication)f(using)h(the)i(RPC)g(paradigm)d(is)j
(at)g(the)f(root)g(of)g(man)o(y)f(distrib)n(uted)g(systems.)28
b(As)22 b(such,)f(the)g(performance)d(of)j(this)0 3636
y(component)g(is)j(critical.)35 b(As)24 b(a)g(result,)g(a)g(lot)f(of)g
(research)g(has)h(been)e(carried)h(out)g(on)g(the)g(optimization)f(of)h
(this)h(paradigm)d([32)o(,)j(6)o(,)0 3735 y(17)o(,)c(36)o(,)h(15)o(,)f
(26)o(].)25 b(Man)o(y)19 b(studies)h(ha)n(v)o(e)g(been)f(carried)g
(out,)g(b)n(ut)h(the)o(y)f(often)h(result)g(in)g(using)f(ne)n(w)h
(protocols)e(that)j(are)e(incompatible)0 3835 y(with)h(an)g(e)o
(xisting)f(standard)f(such)i(as)h(the)e(Sun)h(RPC.)h(The)e(problem)g
(in)h(reimplementing)d(a)j(protocol)e(that)i(is)h(speci\002ed)e(only)g
(by)h(its)0 3935 y(implementation)e(is)j(that)f(features)g(\(and)f(e)n
(v)o(en)g(b)n(ugs\))h(may)g(be)g(lost,)g(resulting)g(in)g(incompatible)
e(implementation.)0 4227 y Fq(Optimizing)i(Existing)g(Code)0
4454 y Fr(An)h(alternati)n(v)o(e)e(to)i(reimplementing)d(a)j(system)g
(component)d(for)i(performance)e(reasons)i(is)i(to)f(directly)f(deri)n
(v)o(e)f(an)i(optimized)e(v)o(er)n(-)0 4554 y(sion)f(from)f(the)g(e)o
(xisting)g(code.)24 b(An)18 b(adv)n(antage)e(of)h(starting)h(with)g(e)o
(xisting)f(code)g(is)h(that)g(the)g(deri)n(v)o(ed)e(v)o(ersion)h
(remains)g(compatible)0 4654 y(with)30 b(e)o(xisting)f(standards.)53
b(Another)29 b(adv)n(antage)f(is)j(that)f(the)f(systematic)h(deri)n(v)n
(ation)e(process)i(can)g(be)f(repeated)g(for)g(dif)n(ferent)0
4753 y(machines)19 b(and)h(systems.)125 4924 y(The)h(question)f(that)i
(naturally)e(arises)i(at)g(this)g(point)f(is:)29 b(are)22
b(there)f(important)f(opportunities)f(for)i(deri)n(ving)f
(signi\002cantly)g(opti-)0 5024 y(mized)g(v)o(ersions)f(of)h(e)o
(xisting)f(system)i(components?)p 0 5095 1560 4 v 90
5151 a Fn(1)120 5174 y Fm(F)o(or)d(clarity)l(,)i(we)f(omit)g(some)f
(clutter)i(in)f(code)h(listings:)25 b(declarations,)d
(\223uninteresting\224)h(ar)o(guments)d(and)f(statements,)h(error)f
(handling,)i(casts,)e(and)g(a)f(le)n(v)o(el)j(of)0 5253
y(function)e(call.)3782 5731 y(Irisa)p eop
%%Page: 5 7
5 6 bop 0 352 a Fp(F)-6 b(ast,)20 b(Optimized)g(Sun)f(RPC)i(Using)f(A)n
(utomatic)f(Pr)l(o)o(gr)o(am)h(Specialization)1623 b
Fr(5)p 0 406 3900 8 v 0 609 3900 4 v 0 2817 4 2209 v
262 772 a Fi(arg.int1)43 b(=)i(...)986 b(//)18 b Fh(Set)g(\002rst)g(ar)
o(gument)262 863 y Fi(arg.int2)43 b(=)i(...)986 b(//)18
b Fh(Set)g(second)i(ar)o(gument)262 955 y Fi(rmin\(&arg\))1164
b(//)18 b Fh(RPC)g(User)h(interf)o(ace)g(generated)h(by)g
Fi(rpcgen)352 1046 y(clnt_call\(argsp\))804 b(//)18 b
Fh(Generic)h(procedure)i(call)d(\(macro\))441 1137 y
Fi(clntupd_call\(argsp\))580 b(//)18 b Fh(UDP)g(generic)i(procedure)g
(call)1876 1229 y Fi(//)e Fh(Write)g(procedure)i(identi\002er)531
1320 y Fi(XDR_PUTLONG\(&proc\))535 b(//)108 b Fh(Generic)19
b(marshaling)h(to)f(memory)-5 b(,)19 b(stream...)f(\(macro\))621
1411 y Fi(xdrmem_putlong\(lp\))445 b(//)108 b Fh(Write)18
b(in)g(output)i(b)o(uf)n(fer)f(and)h(check)f(o)o(v)o(er\003o)n(w)710
1503 y Fi(htonl\(*lp\))716 b(//)108 b Fh(Choice)19 b(between)h(big)f
(and)h(little)d(endian)j(\(macro\))531 1594 y Fi(xdr_pair\(argsp\))670
b(//)18 b Fh(Stub)h(function)h(generated)g(by)f Fi(rpcgen)1876
1685 y(//)108 b Fh(Write)18 b(\002rst)g(ar)o(gument)621
1777 y Fi(xdr_int\(&argsp->int1\))310 b(//)197 b Fh(Machine)21
b(dependent)f(switch)f(on)h(inte)o(ger)f(size)710 1868
y Fi(xdr_long\(intp\))536 b(//)197 b Fh(Generic)20 b(encoding)g(or)f
(decoding)800 1959 y Fi(XDR_PUTLONG\(lp\))401 b(//)197
b Fh(Generic)20 b(marshaling)f(to)g(memory)-5 b(,)20
b(stream...)e(\(macro\))890 2051 y Fi(xdrmem_putlong\(lp\))176
b(//)197 b Fh(Write)18 b(in)h(output)h(b)o(uf)n(fer)f(and)g(check)h(o)o
(v)o(er\003o)n(w)979 2142 y Fi(htonl\(*lp\))447 b(//)197
b Fh(Choice)20 b(between)f(big)h(and)f(little)f(endian)i(\(macro\))1876
2233 y Fi(//)108 b Fh(Write)18 b(second)i(ar)o(gument)621
2325 y Fi(xdr_int\(&argsp->int2\))310 b(//)197 b Fh(Machine)21
b(dependent)f(switch)f(on)h(inte)o(ger)f(size)710 2416
y Fi(xdr_long\(intp\))536 b(//)197 b Fh(Generic)20 b(encoding)g(or)f
(decoding)800 2507 y Fi(XDR_PUTLONG\(lp\))401 b(//)197
b Fh(Generic)20 b(marshaling)f(to)g(memory)-5 b(,)20
b(stream...)e(\(macro\))890 2599 y Fi(xdrmem_putlong\(lp\))176
b(//)197 b Fh(Write)18 b(in)h(output)h(b)o(uf)n(fer)f(and)g(check)h(o)o
(v)o(er\003o)n(w)979 2690 y Fi(htonl\(*lp\))447 b(//)197
b Fh(Choice)20 b(between)f(big)h(and)f(little)f(endian)i(\(macro\))p
3897 2817 V 0 2820 3900 4 v 788 2968 a Fr(Figure)g(1:)25
b(Abstract)20 b(trace)g(of)g(the)h(encoding)d(part)h(of)h(a)h(remote)e
(call)i(to)f Fk(rmin)125 3235 y Fr(In)k(f)o(act,)j(e)o(xisting)d
(system)i(components)d(are)i(kno)n(wn)f(to)h(be)g(generic)f(and)h
(structured)f(in)h(layers)g(and)g(modules.)39 b(This)25
b(results)0 3335 y(in)d(v)n(arious)f(forms)g(of)h(interpretation)e
(which)i(are)g(important)e(sources)i(of)f(o)o(v)o(erhead)f(as)j(sho)n
(wn,)e(for)h(e)o(xample,)e(in)j(the)f(HP-UX)g(\002le)0
3435 y(systems)f([27)o(].)27 b(In)20 b(the)h(Sun)g(RPC,)h(this)f
(genericity)e(tak)o(es)i(the)g(form)f(of)g(se)n(v)o(eral)g(layers)h(of)
g(functions)e(which)h(interpret)g(descriptors)0 3534
y(\(i.e.,)25 b(data)g(structures\))e(to)i(determine)e(the)i(parameters)
e(of)i(the)f(communication)e(process:)34 b(choice)24
b(of)g(protocol)f(\(TCP)i(or)g(UDP\),)0 3634 y(whether)19
b(to)i(encode)d(or)i(decode,)f(b)n(uf)n(fer)g(management,)f(.)12
b(.)g(.)125 3805 y(Importantly)-5 b(,)24 b(most)i(of)g(these)g
(parameters)f(are)h(kno)n(wn)f(for)g(an)o(y)g(gi)n(v)o(en)g(remote)g
(procedure)f(call.)43 b(This)26 b(information)e(can)i(be)0
3905 y(e)o(xploited)e(to)i(generate)f(specialized)g(code)g(where)h
(these)g(interpretations)e(are)i(eliminated.)41 b(The)25
b(resulting)g(code)g(is)i(tailored)e(for)0 4004 y(speci\002c)20
b(situations.)125 4175 y(Let)32 b(us)g(no)n(w)g(e)o(xamine)e(forms)h
(of)h(these)g(interpretations)e(in)j(the)f(Sun)f(RPC)j(code)d(and)g(ho)
n(w)h(the)o(y)f(can)h(be)g(optimized)f(via)0 4275 y(specialization.)0
4627 y Ft(3)119 b(Opportunities)32 b(f)m(or)d(Specialization)j(in)e
(the)h(Sun)g(RPC)0 4884 y Fr(The)c(Sun)g(RPC)i(relies)f(on)f(v)n
(arious)f(data)h(structures)g(such)g(as)h Fk(CLIENT)f
Fr(or)g Fk(XDR)p Fr(.)g(Some)g(\002elds)h(of)f(those)g(data)g
(structures)g(ha)n(v)o(e)0 4983 y(v)n(alues)j(that)g(can)g(be)g(a)n(v)n
(ailable)g(before)f(e)o(x)o(ecution)f(actually)h(tak)o(es)i(place;)k
(the)o(y)29 b(do)h(not)g(depend)e(on)i(the)g(run-time)f(ar)o(guments)0
5083 y(of)f(the)g(RPC.)i(The)e(v)n(alues)g(of)g(those)g(\002elds)h(are)
f(either)g(repeatedly)f(interpreted)f(or)i(propagated)e(throughout)f
(the)j(layers)g(of)h(the)0 5183 y(encoding/decoding)13
b(process.)24 b(Because)18 b(these)g(v)n(alues)g(can)g(be)g(a)n(v)n
(ailable)f(before)g(e)o(x)o(ecution,)f(the)o(y)h(may)h(be)g(the)g
(source)f(of)h(optimi-)0 5731 y Fm(PI)f(n)c(\011)g(1094)p
eop
%%Page: 6 8
6 7 bop 0 352 a Fr(6)549 b Fp(Gilles)21 b(Muller)-9 b(,)20
b(Renaud)e(Marlet,)j(Eug)o(en-Nicolae)d(V)-9 b(olansc)o(hi,)18
b(Charles)j(Consel,)f(Calton)g(Pu)g(&)g(Ashvin)g(Goel)p
0 406 3900 8 v 0 688 a Fr(zations:)k(the)19 b(computations)e(depending)
g(only)h(on)h(kno)n(wn)e(\(or)h Fp(static)p Fr(\))i(v)n(alues)e(can)h
(be)g(performed)d(during)i(a)h(specialization)f(phase.)0
788 y(The)i(specialized)f(program)g(only)g(consists)i(of)e(the)i
(computations)d(depending)f(on)j(the)g(unkno)n(wn)e(\(or)i
Fp(dynamic)p Fr(\))e(v)n(alues.)125 959 y(W)-7 b(e)20
b(no)n(w)f(describe)g(typical)g(specialization)g(opportunities)e(in)j
(the)f(Sun)h(RPC.)h(W)-7 b(e)20 b(illustrate)g(these)g(opportunities)d
(with)j(actual)0 1059 y(code)25 b(e)o(xcerpts)g(annotated)f(to)i(sho)n
(w)f(static)i(and)e(dynamic)g(computations.)39 b(In)26
b(the)g(follo)n(wing)e(\002gures,)i(dynamic)f(computations)0
1158 y(correspond)18 b(to)i(code)f(fragments)g(printed)g(in)i(bold)e(f)
o(ace;)h(static)h(computations)d(are)i(printed)f(in)i(Roman.)0
1467 y Fg(3.1)99 b(Eliminating)25 b(Encoding/Decoding)h(Dispatch)0
1695 y Fr(W)-7 b(e)20 b(\002rst)f(e)o(xamine)f(an)g(opportunity)e(for)i
(specialization)g(that)h(illustrates)g(a)g(form)f(of)g(interpretation.)
k(The)d(function)e(e)o(xhibiting)f(that)0 1794 y(is)22
b Fk(xdr_long)p Fr(,)e(gi)n(v)o(en)f(in)i(Figure)f(2.)27
b(This)21 b(function)e(is)j(capable)e(of)g(both)g(encoding)f(and)h
(decoding)f(long)h(inte)o(gers.)26 b(It)21 b(selects)h(the)0
1894 y(appropriate)17 b(operation)g(to)i(perform)e(based)i(on)f(the)i
(\002eld)f Fk(x_op)g Fr(of)f(its)j(ar)o(gument)16 b Fk(xdrs)p
Fr(.)25 b(This)19 b(form)f(of)h(interpretation)e(is)j(used)e(in)0
1993 y(similar)i(functions)f(for)h(other)f(data)h(types.)125
2165 y(In)d(f)o(act,)i(the)f(\002eld)g Fk(x_op)g Fr(is)g(kno)n(wn)f
(from)g(the)h(e)o(x)o(ecution)e(conte)o(xt)g(\(i.e.,)i(encoding)e(or)i
(decoding)e(process\).)23 b(This)18 b(information,)0
2264 y(contained)j(in)i(the)g Fk(xdrs)g Fr(structure,)g(can)g(be)f
(propagated)f(interprocedurally)e(do)n(wn)j(to)h(the)g(function)e
Fk(xdr_long)p Fr(.)33 b(As)23 b(a)h(result,)0 2364 y(the)e(dispatch)f
(on)g Fk(xdrs->x_op)f Fr(is)j(totally)e(eliminated;)h(the)f
(specialized)h(v)o(ersion)e(of)h(this)i(function)c(is)k(reduced)d(to)i
(only)f(one)g(of)0 2463 y(the)f(return)f(constructs.)24
b(In)c(this)h(case,)f(the)h(specialized)e Fk(xdr_long\(\))p
Fr(,)g(being)g(small)i(enough,)d(disappears)h(after)h(inlining.)p
0 2584 3900 4 v 0 3880 4 1296 v 484 2748 a Fi(bool_t)44
b Ff(xdr_long\(xdrs,lp\))580 b Fi(//)37 b Fh(Encode)20
b(or)f(decode)h(a)f(long)g(inte)o(ger)574 2839 y Ff(XDR)44
b(*xdrs;)1120 b Fi(//)127 b(XDR)18 b Fh(operation)i(handle)574
2931 y Ff(long)44 b(*lp;)1165 b Fi(//)127 b Fh(pointer)19
b(to)g(data)g(to)g(be)g(read)g(or)g(written)484 3022
y Ff({)574 3113 y Fi(if\()44 b(xdrs->x_op)f(==)i(XDR_ENCODE)e(\))224
b(//)37 b Fh(If)18 b(in)h(encoding)i(mode)843 3205 y
Ff(return)44 b(XDR_PUTLONG\(xdrs,lp\);)d Fi(//)127 b
Fh(Write)17 b(a)i(long)h(int)e(into)h(b)o(uf)n(fer)574
3296 y Fi(if\()44 b(xdrs->x_op)f(==)i(XDR_DECODE)e(\))224
b(//)37 b Fh(If)18 b(in)h(decoding)i(mode)843 3387 y
Ff(return)44 b(XDR_GETLONG\(xdrs,lp\);)d Fi(//)127 b
Fh(Read)19 b(a)g(long)g(int)g(from)g(b)o(uf)n(fer)574
3479 y Fi(if\()44 b(xdrs->x_op)f(==)i(XDR_FREE)e(\))314
b(//)37 b Fh(If)18 b(in)h(\223free)g(memory\224)h(mode)843
3570 y Ff(return)44 b(TRUE;)761 b Fi(//)127 b Fh(Nothing)19
b(to)g(be)g(done)h(for)f(long)h(int)574 3661 y Ff(return)44
b(FALSE;)985 b Fi(//)37 b Fh(Return)19 b(f)o(ailure)g(if)f(nothing)i
(matched)484 3753 y Ff(})p 3897 3880 V 0 3883 3900 4
v 926 4031 a Fr(Figure)f(2:)26 b(Reading)19 b(or)h(writing)g(of)g(a)g
(long)g(inte)o(ger:)k Fk(xdr)p 2651 4031 25 4 v 29 w(long\(\))0
4368 y Fg(3.2)99 b(Eliminating)25 b(Buffer)h(Ov)o(er\003o)o(w)f
(Checking)0 4595 y Fr(Another)30 b(form)g(of)g(interpretation)f
(appears)h(when)h(b)n(uf)n(fers)f(are)h(check)o(ed)e(for)i(o)o(v)o
(er\003o)n(w)-5 b(.)55 b(This)31 b(situation)f(applies)h(to)g(function)
0 4695 y Fk(xdrmem_putlong)17 b Fr(displayed)g(in)j(Figure)e(3.)24
b(More)19 b(speci\002cally)-5 b(,)18 b(as)h(parameter)f(marshaling)f
(proceeds,)h(the)h(remaining)e(space)0 4794 y(in)31 b(the)f(b)n(uf)n
(fer)f(is)j(maintained)d(in)h(the)h(\002eld)g Fk(x_handy)p
Fr(.)55 b(Similar)30 b(to)h(the)g(\002rst)g(e)o(xample,)g
Fk(xdrs->x_handy)e Fr(is)i(\002rst)h(initia-)0 4894 y(lized)g(\(i.e.,)j
(gi)n(v)o(en)c(a)h(static)h(v)n(alue\),)h(and)e(then)f(decremented)f
(by)i(static)h(v)n(alues)f(and)f(tested)i(se)n(v)o(eral)e(times)i
(\(for)e(each)h(call)g(to)0 4994 y Fk(xdrmem_putlong)18
b Fr(and)i(related)g(functions\).)k(Since)d(the)f(entire)g(process)g
(in)m(v)n(olv)o(es)g(static)h(v)n(alues,)f(the)g(whole)g(b)n(uf)n(fer)f
(o)o(v)o(er\003o)n(w)0 5093 y(checking)i(can)h(be)g(performed)e(during)
h(a)h(specialization)g(phase,)g(before)f(actually)h(running)e(the)j
(program.)29 b(Only)22 b(the)g(b)n(uf)n(fer)f(cop)o(y)0
5193 y(remains)f(in)g(the)g(specialized)g(v)o(ersion)f(\(unless)h(a)g
(b)n(uf)n(fer)f(o)o(v)o(er\003o)n(w)f(is)k(disco)o(v)o(ered\).)3782
5731 y Fm(Irisa)p eop
%%Page: 7 9
7 8 bop 0 352 a Fp(F)-6 b(ast,)20 b(Optimized)g(Sun)f(RPC)i(Using)f(A)n
(utomatic)f(Pr)l(o)o(gr)o(am)h(Specialization)1623 b
Fr(7)p 0 406 3900 8 v 125 688 a(This)16 b(second)g(e)o(xample)f(is)i
(important)e(not)h(only)g(because)g(of)g(the)g(immediate)g(performance)
d(gain,)j(b)n(ut)h(also)g(because)f(in)g(contrast)0 788
y(with)27 b(a)g(manual,)g(unw)o(arranted)e(deletion)h(of)g(the)h(b)n
(uf)n(fer)f(o)o(v)o(er\003o)n(w)f(checking,)h(the)h(elimination)f
(described)f(here)h(is)i(strictly)f(and)0 888 y(systematically)20
b(deri)n(v)o(ed)e(from)h(the)i(original)e(program.)p
0 1008 3900 4 v 0 2121 4 1113 v 406 1172 a Fi(bool_t)44
b Ff(xdrmem_putlong\(xdrs,lp\))534 b Fi(//)37 b Fh(Cop)o(y)20
b(long)f(int)g(into)g(output)g(b)o(uf)n(fer)496 1263
y Ff(XDR)44 b(*xdrs;)1344 b Fi(//)127 b(XDR)18 b Fh(operation)i(handle)
496 1355 y Ff(long)44 b(*lp;)1389 b Fi(//)127 b Fh(pointer)19
b(to)g(data)g(to)g(be)g(written)406 1446 y Ff({)496 1537
y Fi(if\(\(xdrs->x_handy)42 b(-=)i(sizeof\(long\)\))f(<)h(0\))h(//)37
b Fh(Decrement)19 b(space)h(left)e(in)h(b)o(uf)n(fer)585
1629 y Fi(return)44 b(FALSE;)1120 b(//)127 b Fh(Return)19
b(f)o(ailure)g(on)g(o)o(v)o(er\003o)n(w)496 1720 y Ff
(*\(xdrs->x_private\))41 b(=)k(htonl\(*lp\);)357 b Fi(//)37
b Fh(Cop)o(y)20 b(to)f(b)o(uf)n(fer)496 1811 y Ff(xdrs->x_private)42
b(+=)i(sizeof\(long\);)357 b Fi(//)37 b Fh(Point)18 b(to)h(ne)o(xt)g
(cop)o(y)i(location)e(in)g(b)o(uf)n(fer)496 1903 y Fi(return)43
b(TRUE;)1255 b(//)37 b Fh(Return)19 b(success)406 1994
y Ff(})p 3897 2121 V 0 2124 3900 4 v 1006 2272 a Fr(Figure)g(3:)26
b(Writing)20 b(a)g(long)g(inte)o(ger:)k Fk(xdrmem)p 2422
2272 25 4 v 29 w(putlong\(\))0 2610 y Fg(3.3)99 b(Pr)n(opagating)25
b(Exit)g(Status)0 2837 y Fr(The)20 b(third)f(e)o(xample)g(uses)i(the)f
(results)h(from)e(the)h(pre)n(vious)f(e)o(xamples.)125
3008 y(The)c(return)g(v)n(alue)h(of)g(the)g(procedure)e
Fk(xdr_pair)h Fr(\(sho)n(wn)g(in)h(Figure)g(4\))g(depends)f(on)g(the)i
(return)e(v)n(alue)g(of)h Fk(xdr_int)p Fr(,)g(which)0
3107 y(in)h(turn)e(depends)h(on)g(the)g(return)f(v)n(alue)h(of)g
Fk(xdr_putlong)p Fr(.)23 b(W)-7 b(e)17 b(ha)n(v)o(e)f(seen)h(that)f
Fk(xdr_int)g Fr(and)g Fk(xdr_putlong)f Fr(ha)n(v)o(e)h(a)h(static)0
3207 y(return)25 b(v)n(alue.)43 b(Thus)26 b(the)g(return)f(v)n(alue)h
(of)g Fk(xdr_pair)f Fr(is)j(static)f(as)g(well.)44 b(If)26
b(we)h(specialize)f(the)g(caller)h(of)f Fk(xdr_pair)f
Fr(\(i.e.,)0 3307 y Fk(clntudp_call)p Fr(\))16 b(as)i(well)h(to)f(this)
g(return)f(v)n(alue,)g Fk(xdr_pair)g Fr(needs)g(no)h(longer)e(return)h
(a)h(v)n(alue:)23 b(the)18 b(type)f(of)h(the)g(function)e(can)0
3406 y(be)j(turned)e(in)i Fk(void)p Fr(.)24 b(The)19
b(specialized)f(procedure,)e(with)j(the)g(specialized)f(calls)i(to)f
Fk(xdr_int)f Fr(and)g Fk(xdr_putlong)g Fr(inlined,)g(is)0
3506 y(sho)n(wn)g(in)i(Figure)e(5.)25 b(The)19 b(actual)g(result)g(v)n
(alue,)f(which)h(is)h(al)o(w)o(ays)f Fk(TRUE)g Fr(independently)d(of)j
(dynamic)f Fk(objp)h Fr(ar)o(gument)e(\(writing)0 3606
y(the)j(tw)o(o)h(inte)o(gers)e(ne)n(v)o(er)g(o)o(v)o(er\003o)n(ws)f
(the)j(b)n(uf)n(fer\),)d(is)j(used)f(to)g(reduce)f(an)h(e)o(xtra)g
(test)h(in)f Fk(clntudp_call)f Fr(\(not)g(sho)n(wn\).)p
0 3726 3900 4 v 0 4839 4 1113 v 623 3890 a Fi(bool_t)44
b Ff(xdr_pair\(xdrs,)e(objp\))447 b Fi(//)37 b Fh(Encode)20
b(ar)o(guments)g(of)f Fi(rmin)623 3981 y Ff({)712 4073
y Fi(if)45 b(\(!)p Ff(xdr_int\(xdrs,)d(&objp->int1\))p
Fi(\))h({)h(//)37 b Fh(Encode)20 b(\002rst)e(ar)o(gument)802
4164 y Fi(return)44 b(\(FALSE\);)805 b(//)127 b Fh(Possibly)19
b(propagate)h(f)o(ailure)712 4255 y Fi(})712 4347 y(if)45
b(\(!)p Ff(xdr_int\(xdrs,)d(&objp->int2\))p Fi(\))h({)h(//)37
b Fh(Encode)20 b(second)g(ar)o(gument)802 4438 y Fi(return)44
b(\(FALSE\);)805 b(//)127 b Fh(Possibly)19 b(propagate)h(f)o(ailure)712
4529 y Fi(})712 4621 y(return)44 b(\(TRUE\);)940 b(//)37
b Fh(Return)20 b(success)f(status)623 4712 y Ff(})p 3897
4839 V 0 4842 3900 4 v 961 4990 a Fr(Figure)g(4:)25 b(Encoding)18
b(routine)h Fk(xdr)p 2038 4990 25 4 v 30 w(pair\(\))g
Fr(used)h(in)h Fk(rmin\(\))0 5731 y Fm(PI)c(n)c(\011)g(1094)p
eop
%%Page: 8 10
8 9 bop 0 352 a Fr(8)549 b Fp(Gilles)21 b(Muller)-9 b(,)20
b(Renaud)e(Marlet,)j(Eug)o(en-Nicolae)d(V)-9 b(olansc)o(hi,)18
b(Charles)j(Consel,)f(Calton)g(Pu)g(&)g(Ashvin)g(Goel)p
0 406 3900 8 v 0 609 3900 4 v 0 1630 4 1022 v 578 772
a Fi(void)45 b(xdr_pair\(xdrs,objp\))490 b(//)37 b Fh(Encode)19
b(ar)o(guments)h(of)f Fi(rmin)578 863 y({)2148 955 y(//)37
b Fh(Ov)o(er\003o)n(w)18 b(checking)j(eliminated)668
1046 y Fi(*\(xdrs->x_private\))42 b(=)j(objp->int1;)e(//)37
b Fh(Inlined)19 b(specialized)h(call)668 1137 y Fi(xdrs->x_private)42
b(+=)j(4u;)493 b(//)126 b Fh(for)19 b(writing)g(the)g(\002rst)e(ar)o
(gument)668 1229 y Fi(*\(xdrs->x_private\))42 b(=)j(objp->int2;)e(//)37
b Fh(Inlined)19 b(specialized)h(call)668 1320 y Fi(xdrs->x_private)42
b(+=)j(4u;)493 b(//)126 b Fh(for)19 b(writing)g(the)g(second)h(ar)o
(gument)2148 1411 y Fi(//)37 b Fh(Return)19 b(code)g(eliminated)578
1503 y Fi(})p 3897 1630 V 0 1633 3900 4 v 1055 1781 a
Fr(Figure)g(5:)26 b(Specialized)19 b(encoding)f(routine)h
Fk(xdr)p 2522 1781 25 4 v 29 w(pair\(\))0 2048 y Fg(3.4)99
b(Assessment)0 2275 y Fr(The)23 b(purpose)e(of)i(the)g(encoding)f(is)i
(to)f(cop)o(y)f(the)h(ar)o(guments)f(into)g(the)i(output)e(b)n(uf)n
(fer)-5 b(.)32 b(T)-7 b(o)24 b(perform)d(this)j(task,)g(the)f(minimal)f
(code)0 2375 y(that)h(we)f(can)h(e)o(xpect)e(\(using)h(the)g(approach)e
(of)i(a)h(separate)f(output)f(b)n(uf)n(fer\))g(is)j(basically)e(what)g
(is)i(sho)n(wn)d(in)i(Figure)f(5.)31 b(The)22 b(same)0
2474 y(situation)j(applies)h(for)f(decoding,)g(e)o(xcept)f(that)i
(additional)e(dynamic)h(tests)i(must)e(be)h(performed)d(to)j(ensure)f
(the)h(soundness)e(and)0 2574 y(authenticity)19 b(of)h(the)g(serv)o(er)
f(reply)-5 b(.)125 2745 y(W)e(e)22 b(ha)n(v)o(e)e(seen)h(that)g(a)h
(systematic)f(approach)d(to)j(specializing)g(system)g(code)f(can)h
(achie)n(v)o(e)f(signi\002cant)g(code)g(simpli\002cations.)0
2845 y(W)-7 b(e)21 b(no)n(w)f(discuss)h(ho)n(w)e(this)i(process)f(is)h
(automated)d(using)i(a)h(partial)f(e)n(v)n(aluator)e(for)i(C)h
(programs,)d(named)h(T)-6 b(empo.)0 3197 y Ft(4)119 b(A)-6
b(utomatic)30 b(Specialization)i(Using)e(the)g(T)-11
b(empo)30 b(P)o(artial)f(Ev)o(aluator)0 3454 y Fr(It)19
b(is)h(not)f(feasible)g(to)g(manually)f(specialize)h(RPC)h(for)f(each)g
(remote)f(function,)f(as)j(the)f(process)g(is)h(long,)e(tedious,)g(and)
h(error)n(-prone.)0 3553 y(Ho)n(we)n(v)o(er)m(,)f(since)i(the)h
(process)e(is)j(systematic,)e(it)g(can)g(be)h(automated.)i(Ultimately)
-5 b(,)19 b(it)i(should)e(be)h(as)h(automatic)f(as)g
Fk(rpcgen)p Fr(.)125 3724 y(T)-6 b(empo)25 b(is)i(a)g(program)e
(transformation)f(system)i(based)g(on)g Fp(partial)g(e)o(valuation)f
Fr([7)o(,)i(18)o(].)44 b(T)-6 b(empo)25 b(tak)o(es)i(a)g(source)f
(program)0 3824 y Fe(P)53 3836 y Fd(g)r(ener)r(ic)300
3824 y Fr(written)17 b(in)g(C)h(together)e(with)i(a)f(kno)n(wn)f
(subset)h(of)g(its)i(inputs,)e(and)f(produces)g(a)i(specialized)e(C)j
(source)d(program)f Fe(P)3667 3836 y Fd(special)3879
3824 y Fr(,)0 3924 y(simpli\002ed)31 b(with)g(respect)g(to)g(the)g(kno)
n(wn)f(inputs.)57 b(Although)29 b(T)-6 b(empo)30 b(supports)g(both)g
(compile-time)g(and)g(run-time)g(program)0 4023 y(specialization,)19
b(in)h(the)h(RPC)g(e)o(xperiments)e(reported)f(in)i(this)h(paper)e(we)i
(only)e(use)i(compile-time)d(specialization.)125 4194
y(T)-6 b(empo)17 b(uses)j(a)f(description)f(of)h(the)g(inputs)f
(\(which)g(inputs)h(are)g(static)h(and)e(which)h(inputs)f(are)h
(dynamic\))e(to)i(analyze)g Fe(P)3651 4206 y Fd(g)r(ener)r(ic)3879
4194 y Fr(,)0 4294 y(di)n(viding)j(it)i(into)f Fp(static)h
Fr(and)f Fp(dynamic)g Fr(parts.)35 b(Then)23 b(the)g(static)i(part)e
(of)g Fe(P)2213 4306 y Fd(g)r(ener)r(ic)2466 4294 y Fr(is)h(e)n(v)n
(aluated)e(using)i(concrete)e(v)n(alues)h(for)g(each)0
4394 y(kno)n(wn)15 b(input,)i(while)f(the)h(dynamic)e(part)h(is)i
Fp(r)m(esidualized)e Fr(\(copied\))f(into)h(the)h(output)f(specialized)
g(program.)21 b(The)c(result)f Fe(P)3615 4406 y Fd(special)3845
4394 y Fr(is)0 4493 y(typically)i(simpler)g(than)g Fe(P)793
4505 y Fd(g)r(ener)r(ic)1041 4493 y Fr(since)h(the)g(static)g(part)g
(has)g(been)f(pre-computed)d(and)j(only)g(the)h(dynamic)e(part)h(will)i
(be)e(e)o(x)o(ecuted)0 4593 y(at)j(runtime.)125 4764
y(The)j(binary)g(di)n(vision)h(of)g(program)e(components)g(\(a.k.a.)39
b Fp(binding)24 b(time)p Fr(\))h(into)g(static)h(and)f(dynamic)f(parts)
h(turned)f(out)h(to)h(be)0 4864 y(insuf)n(\002cient)h(for)h(C)h
(programs)d(in)i(operating)f(systems.)49 b(The)28 b(main)f
(re\002nements)g(introduced)f(in)j(T)-6 b(empo)27 b(to)h(transform)e
(system)0 4963 y(programming)17 b(code)i(include:)3782
5731 y Fm(Irisa)p eop
%%Page: 9 11
9 10 bop 0 352 a Fp(F)-6 b(ast,)20 b(Optimized)g(Sun)f(RPC)i(Using)f(A)
n(utomatic)f(Pr)l(o)o(gr)o(am)h(Specialization)1623 b
Fr(9)p 0 406 3900 8 v 125 688 a Fc(\017)41 b Fp(partially-static)27
b(structur)m(es)p Fr(:)42 b(Figure)28 b(3)h(sho)n(ws)f(that)h(some)f
(\002elds)h(of)f(the)h Fk(xdrs)f Fr(structure)g(are)g(static)h(while)g
(others)f(are)208 788 y(dynamic.)57 b(Ef)n(fecti)n(v)o(e)29
b(specialization)i(requires)f(that)i(we)g(be)f(able)g(to)h(access)g
(the)f(static)h(\002elds)g(at)g(specialization)f(time.)208
888 y(W)m(ithout)23 b(such)h(a)h(functionality)d(the)j(whole)f
(structure)f(must)h(conserv)n(ati)n(v)o(ely)e(be)i(considered)f
(dynamic)g(and)g(the)i(repeated)208 987 y(b)n(uf)n(fer)18
b(o)o(v)o(er\003o)n(w)h(checking)f(cannot)h(be)h(eliminated.)125
1153 y Fc(\017)41 b Fp(\003ow)24 b(sensitivity:)35 b
Fr(Possible)26 b(errors)e(occurring)e(in)j(the)g(decoding)e(of)i(input)
f(b)n(uf)n(fer)g(introduces)f(dynamic)g(conditions)h(after)208
1253 y(which)32 b(static)h(information)d(is)k(lost;)39
b(ho)n(we)n(v)o(er)31 b(each)h(branch)f(of)i(corresponding)c
(conditionals)i(still)j(can)e(e)o(xploit)g(static)208
1352 y(information.)f(F)o(or)23 b(that,)h(binding)d(time)j(of)f(v)n
(ariables)f(\(i.e.,)h(static)h(or)f(dynamic\))f(must)h(not)g(be)g(a)h
(global)e(property;)h(it)h(must)208 1452 y(depend)18
b(on)i(the)g(program)e(point)i(considered.)125 1618 y
Fc(\017)41 b Fp(conte)n(xt)26 b(sensitivity:)39 b Fr(The)27
b(inte)o(ger)f(encoding)f(function)g(is)j(usually)f(called)g(with)g
(dynamic)f(data,)i(representing)d(the)i(RPC)208 1718
y(ar)o(guments.)41 b(Ho)n(we)n(v)o(er)m(,)26 b(there)g(is)h(one)f
(encoding)f(of)h(a)h(static)g(inte)o(ger)e(in)i(each)f(remote)f
(procedure)f(call:)39 b(the)26 b(marshaling)208 1817
y(of)f(the)h(procedure)d(identi\002er)-5 b(.)41 b(It)26
b(is)g(useful)f(to)h(dif)n(ferentiate)e(between)h(the)g(tw)o(o)h(call)g
(conte)o(xts,)g(in)g(order)e(not)h(to)h(lose)g(this)208
1917 y(opportunity)c(for)j(specialization.)40 b(Ef)n(fecti)n(v)o(e)24
b(specialization)g(requires)h(that)g(calls)i(to)e(the)h(same)g
(functions)e(with)h(dif)n(ferent)208 2017 y(binding)18
b(time)i(conte)o(xt)f(refer)h(to)g(dif)n(ferent)f(binding-time)e
(instances)j(of)g(this)h(function)e(de\002nition.)125
2183 y Fc(\017)41 b Fp(static)25 b(r)m(eturns:)35 b Fr(As)26
b(seen)f(with)g(e)o(xample)f(in)h(section)g(3.3,)g(the)g(computation)e
(at)j(specialization)e(time)h(of)g(e)o(xit)g(status)g(tests)208
2282 y(relies)17 b(on)f(the)h(ability)g(to)g(statically)g(kno)n(w)f
(the)h(return)e(v)n(alue)i(of)f(a)i(function)d(call)i(e)n(v)o(en)f
(though)f(its)j(ar)o(guments)d(and)h(its)i(actions)208
2382 y(on)23 b(input/output)d(b)n(uf)n(fers)j(are)g(dynamic.)33
b(More)23 b(generally)-5 b(,)22 b(the)h(return)f(v)n(alue)h(of)g(a)h
(function)e(may)h(be)g(static)h(e)n(v)o(en)e(though)208
2482 y(its)i(ar)o(guments)c(and)j(side-ef)n(fects)f(are)h(dynamic.)32
b(Thus)22 b(we)h(can)g(use)g(the)g(return)f(v)n(alue)h(of)f(a)i
(function)d(call)i(e)n(v)o(en)f(when)h(the)208 2581 y(call)d(must)g(be)
h(residualized.)0 2819 y(T)-6 b(empo)25 b(also)i(relies)g(on)f(se)n(v)o
(eral)g(other)f(programming)e(language)i(analyses,)i(such)f(as)h
(pointer)f(alias)h(and)f(dependenc)o(y)d(analysis.)0
2918 y(It)j(goes)f(be)o(yond)e(con)m(v)o(entional)f(constant)j
(propagation)d(and)j(folding,)g(in)h(the)f(sense)h(that)f(it)i(is)f
(not)f(limited)g(to)h(e)o(xploiting)d(scalar)0 3018 y(v)n(alues)29
b Fp(intr)o(a-pr)l(ocedur)o(ally)p Fr(.)50 b(T)-6 b(empo)29
b(not)g(only)f(deals)i(with)g(aliases)g(and)f(partially-static)g(data)g
(structures,)i(it)f(also)g(propagate)0 3118 y(them)e
Fp(inter)n(-pr)l(ocedur)o(ally)p Fr(.)48 b(These)29 b(features)f(are)g
(critical)h(when)f(tackling)f(system)i(code.)49 b(In)28
b(f)o(act,)j(T)-6 b(empo)27 b(has)i(been)f(tar)o(geted)0
3217 y(to)n(w)o(ards)20 b(system)g(softw)o(are;)g(e)o(xperiments)e
(such)i(as)h(the)f(Sun)g(RPC)i(specialization)d(ha)n(v)o(e)h(dri)n(v)o
(en)f(its)i(design)e(and)h(implementation.)0 3317 y(Concretely)-5
b(,)18 b(T)-6 b(empo)20 b(is)h(able)f(to)g(achie)n(v)o(e)f(the)h
(specialization)g(described)e(in)j(Section)f(3.)0 3669
y Ft(5)119 b(P)n(erf)m(ormance)30 b(Experiments)0 3926
y Fr(Ha)n(ving)23 b(e)o(xplained)f(the)h(forms)g(of)g(specialization)g
(that)h(T)-6 b(empo)22 b(performs)g(on)h(the)h(RPC)h(code,)f(we)g(no)n
(w)f(turn)g(to)g(the)h(assessment)0 4025 y(of)c(the)g(resulting)f
(optimized)g(RPC.)0 4318 y Fq(The)k(test)f(pr)o(ogram.)80
b Fr(W)-7 b(e)23 b(ha)n(v)o(e)f(specialized)f(both)g(the)h(client)g
(and)f(the)h(serv)o(er)f(code)g(of)g(the)h(1984)f(cop)o(yrighted)e(v)o
(ersion)h(of)i(Sun)0 4417 y(RPC.)27 b(The)e(unspecialized)f(RPC)j(code)
d(is)j(about)d(1500)g(lines)i(long)f(\(without)f(comments\))g(on)h(the)
g(client)h(side)g(and)e(1700)h(on)g(the)0 4517 y(serv)o(er)d(side.)31
b(The)22 b(test)i(program,)c(which)i(utilizes)h(remote)e(procedure)f
(calls,)k(emulates)e(the)g(beha)n(vior)f(of)h(parallel)g(programs)e
(that)0 4617 y(e)o(xchange)k(lar)o(ge)h(chunks)h(of)g(structured)e
(data.)44 b(This)26 b(is)h(a)g(benchmark)d(representati)n(v)o(e)g(of)i
(applications)f(that)h(use)h(a)g(netw)o(ork)e(of)0 4716
y(w)o(orkstations)19 b(as)i(lar)o(ge)e(scale)i(multiprocessors.)0
5009 y Fq(Platf)n(orms)e(f)n(or)h(measur)o(ements.)82
b Fr(Measurements)19 b(ha)n(v)o(e)g(been)h(done)f(on)h(tw)o(o)g(kinds)g
(of)g(platforms:)0 5731 y Fm(PI)d(n)c(\011)g(1094)p eop
%%Page: 10 12
10 11 bop 0 352 a Fr(10)507 b Fp(Gilles)21 b(Muller)-9
b(,)20 b(Renaud)e(Marlet,)j(Eug)o(en-Nicolae)d(V)-9 b(olansc)o(hi,)18
b(Charles)j(Consel,)f(Calton)g(Pu)g(&)g(Ashvin)g(Goel)p
0 406 3900 8 v 125 688 a Fc(\017)41 b Fr(T)-7 b(w)o(o)29
b(Sun)f(IPX)i(4/50)e(w)o(orkstations)g(running)e(SunOS)13
b(4.1.4)28 b(with)h(32)13 b(MB)29 b(of)g(memory)e(connected)g(with)i(a)
g(100)13 b(Mbits/s)208 788 y(A)-9 b(TM)24 b(link.)40
b(A)-9 b(TM)25 b(cards)f(are)h(model)g(ESA-200)e(from)h(F)o(ore)h
(Systems.)40 b(This)25 b(platform)e(is)j(3)f(years)g(old)g(and)g(quite)
f(inef)n(\002-)208 888 y(cient)f(compared)e(to)j(up)f(to)h(date)f
(products,)g(both)g(in)g(term)h(of)f(CPU,)h(netw)o(ork)e(latenc)o(y)h
(and)g(bandwidth)f(\(i.e.,)h(155)g(Mbits)h(/)208 987
y(622)19 b(Mbits\).)125 1151 y Fc(\017)41 b Fr(T)-7 b(w)o(o)30
b(recent)f(166)13 b(MHz)30 b(Pentium)f(PC)i(machines)e(running)f(Linux)
h(with)h(96)13 b(MB)31 b(of)f(memory)e(and)i(a)g(100)12
b(Mbits/s)31 b(F)o(ast-)208 1250 y(Ethernet)19 b(netw)o(ork)g
(connection.)j(There)e(were)g(no)g(other)f(machines)g(on)h(this)h(netw)
o(ork)e(during)f(e)o(xperiments.)0 1482 y(Our)j(specialization)g(is)h
(tested)g(on)f(dif)n(ferent)f(en)m(vironments)f(in)j(order)e(to)i
(check)e(that)i(the)g(results)f(we)h(obtain)f(are)g(not)h(speci\002c)f
(to)h(a)0 1582 y(particular)d(platform.)k(All)e(programs)d(ha)n(v)o(e)i
(been)g(compiled)e(using)i Fk(gcc)g Fr(v)o(ersion)f(2.7.2,)g(with)h
(the)g(option)f Fk(-O2)p Fr(.)0 1873 y Fq(Benchmarks.)83
b Fr(T)-7 b(o)25 b(e)n(v)n(aluate)e(the)h(ef)n(\002cienc)o(y)f(of)h
(specialization,)g(we)g(ha)n(v)o(e)g(made)f(tw)o(o)i(kinds)e(of)h
(measurements:)32 b(\(i\))24 b(a)h(micro-)0 1973 y(benchmark)18
b(of)i(the)g(client)g(marshaling)f(process,)g(and)h(\(ii\))g(an)g
(application)f(le)n(v)o(el)h(benchmark)d(which)j(measures)f(the)i
(elapsed)e(total)0 2073 y(time)25 b(of)f(a)h(complete)e(RPC)j(call)f
(\(round-trip\).)34 b(The)24 b(client)g(test)i(program)c(loops)i(on)g
(a)h(simple)f(RPC)i(which)e(sends)g(and)g(recei)n(v)o(es)0
2172 y(an)e(array)f(of)h(inte)o(gers.)29 b(The)21 b(intent)h(of)g(this)
g(second)f(e)o(xperiment)f(is)j(to)f(tak)o(e)g(into)g(account)e
(architectural)h(features)g(such)h(as)g(cache,)0 2272
y(memory)i(and)g(netw)o(ork)g(bandwidth)g(that)h(af)n(fect)g(global)f
(performance)f(signi\002cantly)-5 b(.)39 b(Performance)23
b(comparisons)g(for)i(the)g(tw)o(o)0 2371 y(platforms)h(and)i(the)f(tw)
o(o)h(e)o(xperiments)e(are)i(sho)n(wn)e(Figure)h(6.)48
b(The)27 b(marshaling)f(and)h(round-trip)e(benchmark)g(numbers)i
(result)0 2471 y(from)19 b(the)h(mean)g(of)g(10000)e(iterations.)125
2642 y(Not)23 b(surprisingly)-5 b(,)21 b(the)j(PC/Linux)f(platform)e
(is)j(al)o(w)o(ays)g(f)o(aster)g(than)e(the)i(IPX/SunOs')-5
b(s)23 b(one.)34 b(This)23 b(is)h(partly)f(due)f(to)i(a)f(f)o(aster)0
2742 y(CPU,)j(b)n(ut)g(also)g(to)f(the)h(f)o(act)f(that)h(the)f(F)o
(ast-Ethernet)f(cards)i(ha)n(v)o(e)f(a)g(higher)g(bandwidth)e(and)i(a)h
(smaller)f(latenc)o(y)g(than)g(our)g(A)-9 b(TM)0 2841
y(cards.)48 b(A)28 b(consequence)e(of)i(instruction)e(elimination)h(by)
h(the)f(specialization)h(process)f(is)i(that)f(the)g(gap)f(between)g
(platforms)g(is)0 2941 y(lo)n(wered)19 b(on)h(the)g(specialized)g(code)
f(\(see)i(marshaling)d(comparisons)h(in)h(Figure)g(6-1)f(and)h(6-2\).)0
3232 y Fq(Marshalling)o(.)82 b Fr(Detailed)24 b(micro-benchmark)c
(results)k(are)g(sho)n(wn)g(in)g(T)-7 b(able)24 b(1.)36
b(The)24 b(specialized)g(client)g(stub)g(code)f(runs)h(up)f(to)0
3332 y(3.7)c(f)o(aster)i(than)e(the)h(non-specialized)e(one)i(on)f(the)
h(IPX/SunOS,)g(and)f(3.3)h(on)f(the)i(PC/Linux.)j(Intuiti)n(v)o(ely)-5
b(,)18 b(one)h(w)o(ould)g(e)o(xpect)h(the)0 3432 y(speedup)e(to)h
(increase)f(with)h(array)g(size,)g(since)g(more)g(instructions)f(are)g
(being)h(e)o(x)o(ecuted.)j(Ho)n(we)n(v)o(er)m(,)17 b(on)i(the)g(Sun)g
(IPX)g(the)g(speedup)0 3531 y(decreases)26 b(with)g(the)g(size)h(of)f
(the)g(array)f(of)h(inte)o(gers)f(\(see)h(Figure)f(6-5\).)42
b(The)26 b(e)o(xplanation)d(is)k(that)g(program)c(e)o(x)o(ecution)h
(time)j(is)0 3631 y(dominated)g(by)h(memory)g(accesses.)51
b(When)29 b(the)g(array)f(size)i(gro)n(ws,)g(most)f(of)f(the)h
(marshaling)f(time)h(is)h(spent)e(in)h(cop)o(ying)f(the)0
3730 y(inte)o(ger)18 b(array)h(ar)o(gument)e(into)i(the)h(output)e(b)n
(uf)n(fer)-5 b(.)24 b(Ev)o(en)19 b(though)e(specialization)i(decreases)
g(the)h(number)d(of)j(instructions)e(used)h(to)0 3830
y(encode)g(an)i(inte)o(ger)m(,)e(the)i(number)e(of)h(memory)f(mo)o(v)o
(es)h(remains)g(constant)g(between)g(the)h(specialized)f(and)g
(non-specialized)e(code.)0 3930 y(Therefore,)k(the)i(instruction)f(sa)n
(vings)g(becomes)g(comparati)n(v)o(ely)e(smaller)j(as)h(the)e(array)g
(size)i(gro)n(ws.)35 b(F)o(or)23 b(the)h(PC,)h(this)f(beha)n(vior)0
4029 y(does)c(not)g(appear;)f(the)h(speedup)f(curv)o(e)g(only)g(bends.)
p 452 4148 2996 4 v 450 4247 4 100 v 467 4247 V 519 4217
a(Array)g(Size)p 924 4247 V 924 4247 V 483 w(IPX/SunOs)p
2169 4247 V 2186 4247 V 2185 4247 V 909 w(PC/Linux)p
3429 4247 V 3446 4247 V 926 4251 2522 4 v 450 4347 4
100 v 467 4347 V 924 4347 V 976 4317 a(Original)p 1301
4347 V 98 w(Specialized)p 1783 4347 V 98 w(Speedup)p
2169 4347 V 2186 4347 V 115 w(Original)p 2561 4347 V
98 w(Specialized)p 3044 4347 V 98 w(Speedup)p 3429 4347
V 3446 4347 V 452 4350 2996 4 v 452 4367 V 450 4466 4
100 v 467 4466 V 519 4436 a Fp(20)p 924 4466 V 418 w
Fr(0.047)p 1301 4466 V 240 w(0.017)p 1783 4466 V 266
w Fq(2.75)p 2169 4466 V 2186 4466 V 230 w Fr(0.071)p
2561 4466 V 240 w(0.063)p 3044 4466 V 266 w Fq(1.20)p
3429 4466 V 3446 4466 V 452 4470 2996 4 v 450 4569 4
100 v 467 4569 V 519 4539 a Fp(100)p 924 4569 V 396 w
Fr(0.20)p 1301 4569 V 262 w(0.057)p 1783 4569 V 266 w
Fq(3.50)p 2169 4569 V 2186 4569 V 250 w Fr(0.11)p 2561
4569 V 262 w(0.069)p 3044 4569 V 266 w Fq(1.60)p 3429
4569 V 3446 4569 V 452 4573 2996 4 v 450 4672 4 100 v
467 4672 V 519 4642 a Fp(250)p 924 4672 V 396 w Fr(0.49)p
1301 4672 V 283 w(0.13)p 1783 4672 V 287 w Fq(3.75)p
2169 4672 V 2186 4672 V 250 w Fr(0.17)p 2561 4672 V 283
w(0.08)p 3044 4672 V 287 w Fq(2.10)p 3429 4672 V 3446
4672 V 452 4676 2996 4 v 450 4775 4 100 v 467 4775 V
519 4745 a Fp(500)p 924 4775 V 396 w Fr(0.99)p 1301 4775
V 283 w(0.30)p 1783 4775 V 287 w Fq(3.30)p 2169 4775
V 2186 4775 V 250 w Fr(0.29)p 2561 4775 V 283 w(0.11)p
3044 4775 V 287 w Fq(2.60)p 3429 4775 V 3446 4775 V 452
4779 2996 4 v 450 4878 4 100 v 467 4878 V 519 4848 a
Fp(1000)p 924 4878 V 354 w Fr(1.96)p 1301 4878 V 283
w(0.62)p 1783 4878 V 287 w Fq(3.15)p 2169 4878 V 2186
4878 V 250 w Fr(0.51)p 2561 4878 V 283 w(0.17)p 3044
4878 V 287 w Fq(3.00)p 3429 4878 V 3446 4878 V 452 4881
2996 4 v 450 4981 4 100 v 467 4981 V 519 4951 a Fp(2000)p
924 4981 V 354 w Fr(3.93)p 1301 4981 V 283 w(1.38)p 1783
4981 V 287 w Fq(2.85)p 2169 4981 V 2186 4981 V 250 w
Fr(0.97)p 2561 4981 V 283 w(0.29)p 3044 4981 V 287 w
Fq(3.35)p 3429 4981 V 3446 4981 V 452 4984 2996 4 v 1185
5215 a Fr(T)-7 b(able)20 b(1:)26 b(Client)21 b(marshaling)d
(performance)f(in)k(ms)3782 5731 y Fm(Irisa)p eop
%%Page: 11 13
11 12 bop 0 352 a Fp(F)-6 b(ast,)20 b(Optimized)g(Sun)f(RPC)i(Using)f
(A)n(utomatic)f(Pr)l(o)o(gr)o(am)h(Specialization)1582
b Fr(11)p 0 406 3900 8 v 0 610 3900 4 v 0 5089 4 4479
v 220 4898 a @beginspecial -31 @llx -603 @lly 511 @urx
238 @ury 4150 @rwi 5025 @rhi @setspecial
%%BeginDocument: output.eps
1 setlinecap 1 setlinejoin
0.700 setlinewidth
0.00 setgray

/Jrnd { exch cvi exch cvi dup 3 1 roll idiv mul } def
/JDEdict 8 dict def
JDEdict /mtrx matrix put
/JDE {
  JDEdict begin
  /yrad exch def
  /xrad exch def
  /savematrix mtrx currentmatrix def
  xrad yrad scale
  0 0 1 0 360 arc
  savematrix setmatrix
  end
} def
/JSTR {
  gsave 1 eq { gsave 1 setgray fill grestore } if
    exch neg exch neg translate 
    clip                        
    rotate                      
    4 dict begin
      pathbbox  /&top exch def
                /&right exch def
                /&bottom exch def
                &right sub /&width exch def
      newpath
      currentlinewidth mul round dup               
      &bottom exch Jrnd exch &top             
      4 -1 roll currentlinewidth mul setlinewidth  
      { &right exch moveto &width 0 rlineto stroke } for    
    end
  grestore
  newpath
} bind def
 gsave /Times-Roman findfont 9.000000 scalefont setfont
0.000000 0.000000 translate
0.700000 setlinewidth  gsave newpath 0.000000 0.000000 moveto 216.000000 0.000000 lineto stroke
newpath 2.160000 0.000000 moveto 2.160000 -5.000000 lineto stroke
newpath 10.800000 0.000000 moveto 10.800000 -5.000000 lineto stroke
newpath 27.000000 0.000000 moveto 27.000000 -5.000000 lineto stroke
newpath 54.000000 0.000000 moveto 54.000000 -5.000000 lineto stroke
newpath 108.000000 0.000000 moveto 108.000000 -5.000000 lineto stroke
newpath 216.000000 0.000000 moveto 216.000000 -5.000000 lineto stroke
/Times-Roman findfont 7.000000 scalefont setfont
gsave 2.160000 -8.000000 translate 0.000000 rotate
0 -4.200000 translate (20) dup stringwidth pop 2 div neg 0 moveto
show
grestore
gsave 10.800000 -8.000000 translate 0.000000 rotate
0 -4.200000 translate (100) dup stringwidth pop 2 div neg 0 moveto
show
grestore
gsave 27.000000 -8.000000 translate 0.000000 rotate
0 -4.200000 translate (250) dup stringwidth pop 2 div neg 0 moveto
show
grestore
gsave 54.000000 -8.000000 translate 0.000000 rotate
0 -4.200000 translate (500) dup stringwidth pop 2 div neg 0 moveto
show
grestore
gsave 108.000000 -8.000000 translate 0.000000 rotate
0 -4.200000 translate (1000) dup stringwidth pop 2 div neg 0 moveto
show
grestore
gsave 216.000000 -8.000000 translate 0.000000 rotate
0 -4.200000 translate (2000) dup stringwidth pop 2 div neg 0 moveto
show
grestore
/Times-Bold findfont 10.000000 scalefont setfont
gsave 108.000000 -20.200001 translate 0.000000 rotate
0 -6.000000 translate (Array Size \(4-Byte Integers\)) dup stringwidth pop 2 div neg 0 moveto
show
grestore
 grestore 
0.700000 setlinewidth  gsave newpath 0.000000 0.000000 moveto 0.000000 216.000000 lineto stroke
newpath 0.000000 0.000000 moveto -5.000000 0.000000 lineto stroke
newpath 0.000000 5.400000 moveto -2.000000 5.400000 lineto stroke
newpath 0.000000 10.800000 moveto -2.000000 10.800000 lineto stroke
newpath 0.000000 16.200001 moveto -2.000000 16.200001 lineto stroke
newpath 0.000000 21.600000 moveto -2.000000 21.600000 lineto stroke
newpath 0.000000 27.000000 moveto -2.000000 27.000000 lineto stroke
newpath 0.000000 32.400002 moveto -2.000000 32.400002 lineto stroke
newpath 0.000000 37.800003 moveto -2.000000 37.800003 lineto stroke
newpath 0.000000 43.200005 moveto -2.000000 43.200005 lineto stroke
newpath 0.000000 48.600006 moveto -2.000000 48.600006 lineto stroke
newpath 0.000000 54.000000 moveto -5.000000 54.000000 lineto stroke
newpath 0.000000 59.400002 moveto -2.000000 59.400002 lineto stroke
newpath 0.000000 64.800003 moveto -2.000000 64.800003 lineto stroke
newpath 0.000000 70.200005 moveto -2.000000 70.200005 lineto stroke
newpath 0.000000 75.600006 moveto -2.000000 75.600006 lineto stroke
newpath 0.000000 81.000008 moveto -2.000000 81.000008 lineto stroke
newpath 0.000000 86.400009 moveto -2.000000 86.400009 lineto stroke
newpath 0.000000 91.800011 moveto -2.000000 91.800011 lineto stroke
newpath 0.000000 97.200012 moveto -2.000000 97.200012 lineto stroke
newpath 0.000000 102.600014 moveto -2.000000 102.600014 lineto stroke
newpath 0.000000 108.000000 moveto -5.000000 108.000000 lineto stroke
newpath 0.000000 113.399994 moveto -2.000000 113.399994 lineto stroke
newpath 0.000000 118.799988 moveto -2.000000 118.799988 lineto stroke
newpath 0.000000 124.199982 moveto -2.000000 124.199982 lineto stroke
newpath 0.000000 129.599976 moveto -2.000000 129.599976 lineto stroke
newpath 0.000000 134.999969 moveto -2.000000 134.999969 lineto stroke
newpath 0.000000 140.399963 moveto -2.000000 140.399963 lineto stroke
newpath 0.000000 145.799957 moveto -2.000000 145.799957 lineto stroke
newpath 0.000000 151.199951 moveto -2.000000 151.199951 lineto stroke
newpath 0.000000 156.599960 moveto -2.000000 156.599960 lineto stroke
newpath 0.000000 162.000000 moveto -5.000000 162.000000 lineto stroke
newpath 0.000000 167.399994 moveto -2.000000 167.399994 lineto stroke
newpath 0.000000 172.799988 moveto -2.000000 172.799988 lineto stroke
newpath 0.000000 178.199982 moveto -2.000000 178.199982 lineto stroke
newpath 0.000000 183.599976 moveto -2.000000 183.599976 lineto stroke
newpath 0.000000 188.999969 moveto -2.000000 188.999969 lineto stroke
newpath 0.000000 194.399963 moveto -2.000000 194.399963 lineto stroke
newpath 0.000000 199.799957 moveto -2.000000 199.799957 lineto stroke
newpath 0.000000 205.199951 moveto -2.000000 205.199951 lineto stroke
newpath 0.000000 210.599960 moveto -2.000000 210.599960 lineto stroke
newpath 0.000000 216.000000 moveto -5.000000 216.000000 lineto stroke
/Times-Roman findfont 9.000000 scalefont setfont
gsave -8.000000 0.000000 translate 0.000000 rotate
0 -2.700000 translate (0) dup stringwidth pop neg 0 moveto
show
grestore
gsave -8.000000 54.000000 translate 0.000000 rotate
0 -2.700000 translate (1) dup stringwidth pop neg 0 moveto
show
grestore
gsave -8.000000 108.000000 translate 0.000000 rotate
0 -2.700000 translate (2) dup stringwidth pop neg 0 moveto
show
grestore
gsave -8.000000 162.000000 translate 0.000000 rotate
0 -2.700000 translate (3) dup stringwidth pop neg 0 moveto
show
grestore
gsave -8.000000 216.000000 translate 0.000000 rotate
0 -2.700000 translate (4) dup stringwidth pop neg 0 moveto
show
grestore
/Times-Bold findfont 10.000000 scalefont setfont
gsave -20.320000 108.000000 translate 90.000000 rotate
0 0.000000 translate (\(1\) Client Marshalling Time in ms - Original Code) dup stringwidth pop 2 div neg 0 moveto
show
grestore
 grestore 
 gsave 
 gsave 0.700000 setlinewidth  [] 0 setdash
2.160000 3.877200 moveto   10.800000 5.841720 lineto
  27.000000 9.498060 lineto
  54.000000 15.668099 lineto
  108.000000 27.998999 lineto
  216.000000 52.860600 lineto
stroke
0.700000 setlinewidth  [] 0 setdash
 gsave  2.160000 3.877200 translate 0.000000 rotate
newpath 2.000000 2.000000 JDE
gsave  fill grestore
stroke
 grestore  gsave  10.800000 5.841720 translate 0.000000 rotate
newpath 2.000000 2.000000 JDE
gsave  fill grestore
stroke
 grestore  gsave  27.000000 9.498060 translate 0.000000 rotate
newpath 2.000000 2.000000 JDE
gsave  fill grestore
stroke
 grestore  gsave  54.000000 15.668099 translate 0.000000 rotate
newpath 2.000000 2.000000 JDE
gsave  fill grestore
stroke
 grestore  gsave  108.000000 27.998999 translate 0.000000 rotate
newpath 2.000000 2.000000 JDE
gsave  fill grestore
stroke
 grestore  gsave  216.000000 52.860600 translate 0.000000 rotate
newpath 2.000000 2.000000 JDE
gsave  fill grestore
stroke
 grestore  grestore 
 gsave 0.700000 setlinewidth  [] 0 setdash
2.160000 2.538000 moveto   10.800000 10.962000 lineto
  27.000000 26.622000 lineto
  54.000000 53.406002 lineto
  108.000000 105.786003 lineto
  216.000000 211.680008 lineto
stroke
0.700000 setlinewidth  [] 0 setdash
 gsave  2.160000 2.538000 translate 0.000000 rotate
 newpath -2.000000 -2.000000 moveto  2.000000 -2.000000 lineto
  2.000000 2.000000 lineto
  -2.000000 2.000000 lineto
closepath gsave  fill grestore
stroke
 grestore  gsave  10.800000 10.962000 translate 0.000000 rotate
 newpath -2.000000 -2.000000 moveto  2.000000 -2.000000 lineto
  2.000000 2.000000 lineto
  -2.000000 2.000000 lineto
closepath gsave  fill grestore
stroke
 grestore  gsave  27.000000 26.622000 translate 0.000000 rotate
 newpath -2.000000 -2.000000 moveto  2.000000 -2.000000 lineto
  2.000000 2.000000 lineto
  -2.000000 2.000000 lineto
closepath gsave  fill grestore
stroke
 grestore  gsave  54.000000 53.406002 translate 0.000000 rotate
 newpath -2.000000 -2.000000 moveto  2.000000 -2.000000 lineto
  2.000000 2.000000 lineto
  -2.000000 2.000000 lineto
closepath gsave  fill grestore
stroke
 grestore  gsave  108.000000 105.786003 translate 0.000000 rotate
 newpath -2.000000 -2.000000 moveto  2.000000 -2.000000 lineto
  2.000000 2.000000 lineto
  -2.000000 2.000000 lineto
closepath gsave  fill grestore
stroke
 grestore  gsave  216.000000 211.680008 translate 0.000000 rotate
 newpath -2.000000 -2.000000 moveto  2.000000 -2.000000 lineto
  2.000000 2.000000 lineto
  -2.000000 2.000000 lineto
closepath gsave  fill grestore
stroke
 grestore  grestore 
 grestore 
 gsave 10.800000 189.000000 translate 0.000000 rotate
 gsave 0.700000 setlinewidth  [] 0 setdash
0.000000 -2.700000 moveto   24.000000 -2.700000 lineto
stroke
0.700000 setlinewidth  [] 0 setdash
 gsave  12.000000 -2.700000 translate 0.000000 rotate
newpath 2.000000 2.000000 JDE
gsave  fill grestore
stroke
 grestore  grestore 
/Times-Roman findfont 9.000000 scalefont setfont
gsave 28.000000 0.000000 translate 0.000000 rotate
0 -5.400000 translate (PC/Linux) dup stringwidth pop pop 0 0 moveto
show
grestore
 gsave 0.700000 setlinewidth  [] 0 setdash
0.000000 -13.500001 moveto   24.000000 -13.500001 lineto
stroke
0.700000 setlinewidth  [] 0 setdash
 gsave  12.000000 -13.500001 translate 0.000000 rotate
 newpath -2.000000 -2.000000 moveto  2.000000 -2.000000 lineto
  2.000000 2.000000 lineto
  -2.000000 2.000000 lineto
closepath gsave  fill grestore
stroke
 grestore  grestore 
gsave 28.000000 -10.800000 translate 0.000000 rotate
0 -5.400000 translate (IPX/Sunos) dup stringwidth pop pop 0 0 moveto
show
grestore
 grestore 
-0.000000 -0.000000 translate
288.000000 0.000000 translate
0.700000 setlinewidth  gsave newpath 0.000000 0.000000 moveto 216.000000 0.000000 lineto stroke
newpath 2.160000 0.000000 moveto 2.160000 -5.000000 lineto stroke
newpath 10.800000 0.000000 moveto 10.800000 -5.000000 lineto stroke
newpath 27.000000 0.000000 moveto 27.000000 -5.000000 lineto stroke
newpath 54.000000 0.000000 moveto 54.000000 -5.000000 lineto stroke
newpath 108.000000 0.000000 moveto 108.000000 -5.000000 lineto stroke
newpath 216.000000 0.000000 moveto 216.000000 -5.000000 lineto stroke
/Times-Roman findfont 7.000000 scalefont setfont
gsave 2.160000 -8.000000 translate 0.000000 rotate
0 -4.200000 translate (20) dup stringwidth pop 2 div neg 0 moveto
show
grestore
gsave 10.800000 -8.000000 translate 0.000000 rotate
0 -4.200000 translate (100) dup stringwidth pop 2 div neg 0 moveto
show
grestore
gsave 27.000000 -8.000000 translate 0.000000 rotate
0 -4.200000 translate (250) dup stringwidth pop 2 div neg 0 moveto
show
grestore
gsave 54.000000 -8.000000 translate 0.000000 rotate
0 -4.200000 translate (500) dup stringwidth pop 2 div neg 0 moveto
show
grestore
gsave 108.000000 -8.000000 translate 0.000000 rotate
0 -4.200000 translate (1000) dup stringwidth pop 2 div neg 0 moveto
show
grestore
gsave 216.000000 -8.000000 translate 0.000000 rotate
0 -4.200000 translate (2000) dup stringwidth pop 2 div neg 0 moveto
show
grestore
/Times-Bold findfont 10.000000 scalefont setfont
gsave 108.000000 -20.200001 translate 0.000000 rotate
0 -6.000000 translate (Array Size \(4-Byte Integers\)) dup stringwidth pop 2 div neg 0 moveto
show
grestore
 grestore 
0.700000 setlinewidth  gsave newpath 0.000000 0.000000 moveto 0.000000 216.000000 lineto stroke
newpath 0.000000 0.000000 moveto -5.000000 0.000000 lineto stroke
newpath 0.000000 5.400000 moveto -2.000000 5.400000 lineto stroke
newpath 0.000000 10.800000 moveto -2.000000 10.800000 lineto stroke
newpath 0.000000 16.200001 moveto -2.000000 16.200001 lineto stroke
newpath 0.000000 21.600000 moveto -2.000000 21.600000 lineto stroke
newpath 0.000000 27.000000 moveto -2.000000 27.000000 lineto stroke
newpath 0.000000 32.400002 moveto -2.000000 32.400002 lineto stroke
newpath 0.000000 37.800003 moveto -2.000000 37.800003 lineto stroke
newpath 0.000000 43.200005 moveto -2.000000 43.200005 lineto stroke
newpath 0.000000 48.600006 moveto -2.000000 48.600006 lineto stroke
newpath 0.000000 54.000000 moveto -5.000000 54.000000 lineto stroke
newpath 0.000000 59.400002 moveto -2.000000 59.400002 lineto stroke
newpath 0.000000 64.800003 moveto -2.000000 64.800003 lineto stroke
newpath 0.000000 70.200005 moveto -2.000000 70.200005 lineto stroke
newpath 0.000000 75.600006 moveto -2.000000 75.600006 lineto stroke
newpath 0.000000 81.000008 moveto -2.000000 81.000008 lineto stroke
newpath 0.000000 86.400009 moveto -2.000000 86.400009 lineto stroke
newpath 0.000000 91.800011 moveto -2.000000 91.800011 lineto stroke
newpath 0.000000 97.200012 moveto -2.000000 97.200012 lineto stroke
newpath 0.000000 102.600014 moveto -2.000000 102.600014 lineto stroke
newpath 0.000000 108.000000 moveto -5.000000 108.000000 lineto stroke
newpath 0.000000 113.399994 moveto -2.000000 113.399994 lineto stroke
newpath 0.000000 118.799988 moveto -2.000000 118.799988 lineto stroke
newpath 0.000000 124.199982 moveto -2.000000 124.199982 lineto stroke
newpath 0.000000 129.599976 moveto -2.000000 129.599976 lineto stroke
newpath 0.000000 134.999969 moveto -2.000000 134.999969 lineto stroke
newpath 0.000000 140.399963 moveto -2.000000 140.399963 lineto stroke
newpath 0.000000 145.799957 moveto -2.000000 145.799957 lineto stroke
newpath 0.000000 151.199951 moveto -2.000000 151.199951 lineto stroke
newpath 0.000000 156.599960 moveto -2.000000 156.599960 lineto stroke
newpath 0.000000 162.000000 moveto -5.000000 162.000000 lineto stroke
newpath 0.000000 167.399994 moveto -2.000000 167.399994 lineto stroke
newpath 0.000000 172.799988 moveto -2.000000 172.799988 lineto stroke
newpath 0.000000 178.199982 moveto -2.000000 178.199982 lineto stroke
newpath 0.000000 183.599976 moveto -2.000000 183.599976 lineto stroke
newpath 0.000000 188.999969 moveto -2.000000 188.999969 lineto stroke
newpath 0.000000 194.399963 moveto -2.000000 194.399963 lineto stroke
newpath 0.000000 199.799957 moveto -2.000000 199.799957 lineto stroke
newpath 0.000000 205.199951 moveto -2.000000 205.199951 lineto stroke
newpath 0.000000 210.599960 moveto -2.000000 210.599960 lineto stroke
newpath 0.000000 216.000000 moveto -5.000000 216.000000 lineto stroke
/Times-Roman findfont 9.000000 scalefont setfont
gsave -8.000000 0.000000 translate 0.000000 rotate
0 -2.700000 translate (0) dup stringwidth pop neg 0 moveto
show
grestore
gsave -8.000000 54.000000 translate 0.000000 rotate
0 -2.700000 translate (1) dup stringwidth pop neg 0 moveto
show
grestore
gsave -8.000000 108.000000 translate 0.000000 rotate
0 -2.700000 translate (2) dup stringwidth pop neg 0 moveto
show
grestore
gsave -8.000000 162.000000 translate 0.000000 rotate
0 -2.700000 translate (3) dup stringwidth pop neg 0 moveto
show
grestore
gsave -8.000000 216.000000 translate 0.000000 rotate
0 -2.700000 translate (4) dup stringwidth pop neg 0 moveto
show
grestore
/Times-Bold findfont 10.000000 scalefont setfont
gsave -20.320000 108.000000 translate 90.000000 rotate
0 0.000000 translate (\(2\) Client Marshalling Time in ms - Specialized Code) dup stringwidth pop 2 div neg 0 moveto
show
grestore
 grestore 
 gsave 
 gsave 0.700000 setlinewidth  [] 0 setdash
2.160000 3.414960 moveto   10.800000 3.744900 lineto
  27.000000 4.345380 lineto
  54.000000 5.938380 lineto
  108.000000 9.367920 lineto
  216.000000 15.630300 lineto
stroke
0.700000 setlinewidth  [] 0 setdash
 gsave  2.160000 3.414960 translate 0.000000 rotate
newpath 2.000000 2.000000 JDE
gsave  fill grestore
stroke
 grestore  gsave  10.800000 3.744900 translate 0.000000 rotate
newpath 2.000000 2.000000 JDE
gsave  fill grestore
stroke
 grestore  gsave  27.000000 4.345380 translate 0.000000 rotate
newpath 2.000000 2.000000 JDE
gsave  fill grestore
stroke
 grestore  gsave  54.000000 5.938380 translate 0.000000 rotate
newpath 2.000000 2.000000 JDE
gsave  fill grestore
stroke
 grestore  gsave  108.000000 9.367920 translate 0.000000 rotate
newpath 2.000000 2.000000 JDE
gsave  fill grestore
stroke
 grestore  gsave  216.000000 15.630300 translate 0.000000 rotate
newpath 2.000000 2.000000 JDE
gsave  fill grestore
stroke
 grestore  grestore 
 gsave 0.700000 setlinewidth  [] 0 setdash
2.160000 0.918000 moveto   10.800000 3.078000 lineto
  27.000000 7.236000 lineto
  54.000000 17.388000 lineto
  108.000000 33.695999 lineto
  216.000000 74.627998 lineto
stroke
0.700000 setlinewidth  [] 0 setdash
 gsave  2.160000 0.918000 translate 0.000000 rotate
 newpath -2.000000 -2.000000 moveto  2.000000 -2.000000 lineto
  2.000000 2.000000 lineto
  -2.000000 2.000000 lineto
closepath gsave  fill grestore
stroke
 grestore  gsave  10.800000 3.078000 translate 0.000000 rotate
 newpath -2.000000 -2.000000 moveto  2.000000 -2.000000 lineto
  2.000000 2.000000 lineto
  -2.000000 2.000000 lineto
closepath gsave  fill grestore
stroke
 grestore  gsave  27.000000 7.236000 translate 0.000000 rotate
 newpath -2.000000 -2.000000 moveto  2.000000 -2.000000 lineto
  2.000000 2.000000 lineto
  -2.000000 2.000000 lineto
closepath gsave  fill grestore
stroke
 grestore  gsave  54.000000 17.388000 translate 0.000000 rotate
 newpath -2.000000 -2.000000 moveto  2.000000 -2.000000 lineto
  2.000000 2.000000 lineto
  -2.000000 2.000000 lineto
closepath gsave  fill grestore
stroke
 grestore  gsave  108.000000 33.695999 translate 0.000000 rotate
 newpath -2.000000 -2.000000 moveto  2.000000 -2.000000 lineto
  2.000000 2.000000 lineto
  -2.000000 2.000000 lineto
closepath gsave  fill grestore
stroke
 grestore  gsave  216.000000 74.627998 translate 0.000000 rotate
 newpath -2.000000 -2.000000 moveto  2.000000 -2.000000 lineto
  2.000000 2.000000 lineto
  -2.000000 2.000000 lineto
closepath gsave  fill grestore
stroke
 grestore  grestore 
 grestore 
 gsave 10.800000 189.000000 translate 0.000000 rotate
 gsave 0.700000 setlinewidth  [] 0 setdash
0.000000 -2.700000 moveto   24.000000 -2.700000 lineto
stroke
0.700000 setlinewidth  [] 0 setdash
 gsave  12.000000 -2.700000 translate 0.000000 rotate
newpath 2.000000 2.000000 JDE
gsave  fill grestore
stroke
 grestore  grestore 
/Times-Roman findfont 9.000000 scalefont setfont
gsave 28.000000 0.000000 translate 0.000000 rotate
0 -5.400000 translate (PC/Linux) dup stringwidth pop pop 0 0 moveto
show
grestore
 gsave 0.700000 setlinewidth  [] 0 setdash
0.000000 -13.500001 moveto   24.000000 -13.500001 lineto
stroke
0.700000 setlinewidth  [] 0 setdash
 gsave  12.000000 -13.500001 translate 0.000000 rotate
 newpath -2.000000 -2.000000 moveto  2.000000 -2.000000 lineto
  2.000000 2.000000 lineto
  -2.000000 2.000000 lineto
closepath gsave  fill grestore
stroke
 grestore  grestore 
gsave 28.000000 -10.800000 translate 0.000000 rotate
0 -5.400000 translate (IPX/Sunos) dup stringwidth pop pop 0 0 moveto
show
grestore
 grestore 
-288.000000 -0.000000 translate
0.000000 -288.000000 translate
0.700000 setlinewidth  gsave newpath 0.000000 0.000000 moveto 216.000000 0.000000 lineto stroke
newpath 2.160000 0.000000 moveto 2.160000 -5.000000 lineto stroke
newpath 10.800000 0.000000 moveto 10.800000 -5.000000 lineto stroke
newpath 27.000000 0.000000 moveto 27.000000 -5.000000 lineto stroke
newpath 54.000000 0.000000 moveto 54.000000 -5.000000 lineto stroke
newpath 108.000000 0.000000 moveto 108.000000 -5.000000 lineto stroke
newpath 216.000000 0.000000 moveto 216.000000 -5.000000 lineto stroke
/Times-Roman findfont 7.000000 scalefont setfont
gsave 2.160000 -8.000000 translate 0.000000 rotate
0 -4.200000 translate (20) dup stringwidth pop 2 div neg 0 moveto
show
grestore
gsave 10.800000 -8.000000 translate 0.000000 rotate
0 -4.200000 translate (100) dup stringwidth pop 2 div neg 0 moveto
show
grestore
gsave 27.000000 -8.000000 translate 0.000000 rotate
0 -4.200000 translate (250) dup stringwidth pop 2 div neg 0 moveto
show
grestore
gsave 54.000000 -8.000000 translate 0.000000 rotate
0 -4.200000 translate (500) dup stringwidth pop 2 div neg 0 moveto
show
grestore
gsave 108.000000 -8.000000 translate 0.000000 rotate
0 -4.200000 translate (1000) dup stringwidth pop 2 div neg 0 moveto
show
grestore
gsave 216.000000 -8.000000 translate 0.000000 rotate
0 -4.200000 translate (2000) dup stringwidth pop 2 div neg 0 moveto
show
grestore
/Times-Bold findfont 10.000000 scalefont setfont
gsave 108.000000 -20.200001 translate 0.000000 rotate
0 -6.000000 translate (Array Size \(4-Byte Integers\)) dup stringwidth pop 2 div neg 0 moveto
show
grestore
 grestore 
0.700000 setlinewidth  gsave newpath 0.000000 0.000000 moveto 0.000000 216.000000 lineto stroke
newpath 0.000000 0.000000 moveto -5.000000 0.000000 lineto stroke
newpath 0.000000 8.640000 moveto -2.000000 8.640000 lineto stroke
newpath 0.000000 17.280001 moveto -2.000000 17.280001 lineto stroke
newpath 0.000000 25.920002 moveto -2.000000 25.920002 lineto stroke
newpath 0.000000 34.560001 moveto -2.000000 34.560001 lineto stroke
newpath 0.000000 43.200001 moveto -5.000000 43.200001 lineto stroke
newpath 0.000000 51.840004 moveto -2.000000 51.840004 lineto stroke
newpath 0.000000 60.480003 moveto -2.000000 60.480003 lineto stroke
newpath 0.000000 69.120003 moveto -2.000000 69.120003 lineto stroke
newpath 0.000000 77.760002 moveto -2.000000 77.760002 lineto stroke
newpath 0.000000 86.400002 moveto -5.000000 86.400002 lineto stroke
newpath 0.000000 95.040001 moveto -2.000000 95.040001 lineto stroke
newpath 0.000000 103.680008 moveto -2.000000 103.680008 lineto stroke
newpath 0.000000 112.320007 moveto -2.000000 112.320007 lineto stroke
newpath 0.000000 120.960007 moveto -2.000000 120.960007 lineto stroke
newpath 0.000000 129.600006 moveto -5.000000 129.600006 lineto stroke
newpath 0.000000 138.240005 moveto -2.000000 138.240005 lineto stroke
newpath 0.000000 146.880005 moveto -2.000000 146.880005 lineto stroke
newpath 0.000000 155.520004 moveto -2.000000 155.520004 lineto stroke
newpath 0.000000 164.160004 moveto -2.000000 164.160004 lineto stroke
newpath 0.000000 172.800003 moveto -5.000000 172.800003 lineto stroke
newpath 0.000000 181.440002 moveto -2.000000 181.440002 lineto stroke
newpath 0.000000 190.080002 moveto -2.000000 190.080002 lineto stroke
newpath 0.000000 198.720001 moveto -2.000000 198.720001 lineto stroke
newpath 0.000000 207.360016 moveto -2.000000 207.360016 lineto stroke
newpath 0.000000 216.000015 moveto -5.000000 216.000015 lineto stroke
/Times-Roman findfont 9.000000 scalefont setfont
gsave -8.000000 0.000000 translate 0.000000 rotate
0 -2.700000 translate (0) dup stringwidth pop neg 0 moveto
show
grestore
gsave -8.000000 43.200001 translate 0.000000 rotate
0 -2.700000 translate (5) dup stringwidth pop neg 0 moveto
show
grestore
gsave -8.000000 86.400002 translate 0.000000 rotate
0 -2.700000 translate (10) dup stringwidth pop neg 0 moveto
show
grestore
gsave -8.000000 129.600006 translate 0.000000 rotate
0 -2.700000 translate (15) dup stringwidth pop neg 0 moveto
show
grestore
gsave -8.000000 172.800003 translate 0.000000 rotate
0 -2.700000 translate (20) dup stringwidth pop neg 0 moveto
show
grestore
gsave -8.000000 216.000015 translate 0.000000 rotate
0 -2.700000 translate (25) dup stringwidth pop neg 0 moveto
show
grestore
/Times-Bold findfont 10.000000 scalefont setfont
gsave -24.639999 108.000000 translate 90.000000 rotate
0 0.000000 translate (\(3\) RPC Round Trip Time in ms - Original Code) dup stringwidth pop 2 div neg 0 moveto
show
grestore
 grestore 
 gsave 
 gsave 0.700000 setlinewidth  [] 0 setdash
2.160000 6.038669 moveto   10.800000 8.635162 lineto
  27.000000 13.718246 lineto
  54.000000 22.699699 lineto
  108.000000 36.814003 lineto
  216.000000 65.763359 lineto
stroke
0.700000 setlinewidth  [] 0 setdash
 gsave  2.160000 6.038669 translate 0.000000 rotate
newpath 2.000000 2.000000 JDE
gsave  fill grestore
stroke
 grestore  gsave  10.800000 8.635162 translate 0.000000 rotate
newpath 2.000000 2.000000 JDE
gsave  fill grestore
stroke
 grestore  gsave  27.000000 13.718246 translate 0.000000 rotate
newpath 2.000000 2.000000 JDE
gsave  fill grestore
stroke
 grestore  gsave  54.000000 22.699699 translate 0.000000 rotate
newpath 2.000000 2.000000 JDE
gsave  fill grestore
stroke
 grestore  gsave  108.000000 36.814003 translate 0.000000 rotate
newpath 2.000000 2.000000 JDE
gsave  fill grestore
stroke
 grestore  gsave  216.000000 65.763359 translate 0.000000 rotate
newpath 2.000000 2.000000 JDE
gsave  fill grestore
stroke
 grestore  grestore 
 gsave 0.700000 setlinewidth  [] 0 setdash
2.160000 20.079359 moveto   10.800000 28.684801 lineto
  27.000000 43.416004 lineto
  54.000000 67.953598 lineto
  108.000000 117.331207 lineto
  216.000000 218.073608 lineto
stroke
0.700000 setlinewidth  [] 0 setdash
 gsave  2.160000 20.079359 translate 0.000000 rotate
 newpath -2.000000 -2.000000 moveto  2.000000 -2.000000 lineto
  2.000000 2.000000 lineto
  -2.000000 2.000000 lineto
closepath gsave  fill grestore
stroke
 grestore  gsave  10.800000 28.684801 translate 0.000000 rotate
 newpath -2.000000 -2.000000 moveto  2.000000 -2.000000 lineto
  2.000000 2.000000 lineto
  -2.000000 2.000000 lineto
closepath gsave  fill grestore
stroke
 grestore  gsave  27.000000 43.416004 translate 0.000000 rotate
 newpath -2.000000 -2.000000 moveto  2.000000 -2.000000 lineto
  2.000000 2.000000 lineto
  -2.000000 2.000000 lineto
closepath gsave  fill grestore
stroke
 grestore  gsave  54.000000 67.953598 translate 0.000000 rotate
 newpath -2.000000 -2.000000 moveto  2.000000 -2.000000 lineto
  2.000000 2.000000 lineto
  -2.000000 2.000000 lineto
closepath gsave  fill grestore
stroke
 grestore  gsave  108.000000 117.331207 translate 0.000000 rotate
 newpath -2.000000 -2.000000 moveto  2.000000 -2.000000 lineto
  2.000000 2.000000 lineto
  -2.000000 2.000000 lineto
closepath gsave  fill grestore
stroke
 grestore  gsave  216.000000 218.073608 translate 0.000000 rotate
 newpath -2.000000 -2.000000 moveto  2.000000 -2.000000 lineto
  2.000000 2.000000 lineto
  -2.000000 2.000000 lineto
closepath gsave  fill grestore
stroke
 grestore  grestore 
 grestore 
 gsave 10.800000 207.360016 translate 0.000000 rotate
 gsave 0.700000 setlinewidth  [] 0 setdash
0.000000 -2.700000 moveto   24.000000 -2.700000 lineto
stroke
0.700000 setlinewidth  [] 0 setdash
 gsave  12.000000 -2.700000 translate 0.000000 rotate
newpath 2.000000 2.000000 JDE
gsave  fill grestore
stroke
 grestore  grestore 
/Times-Roman findfont 9.000000 scalefont setfont
gsave 28.000000 0.000000 translate 0.000000 rotate
0 -5.400000 translate (PC/Linux - Ethernet 100Mbits) dup stringwidth pop pop 0 0 moveto
show
grestore
 gsave 0.700000 setlinewidth  [] 0 setdash
0.000000 -13.500001 moveto   24.000000 -13.500001 lineto
stroke
0.700000 setlinewidth  [] 0 setdash
 gsave  12.000000 -13.500001 translate 0.000000 rotate
 newpath -2.000000 -2.000000 moveto  2.000000 -2.000000 lineto
  2.000000 2.000000 lineto
  -2.000000 2.000000 lineto
closepath gsave  fill grestore
stroke
 grestore  grestore 
gsave 28.000000 -10.800000 translate 0.000000 rotate
0 -5.400000 translate (IPX/Sunos - ATM 100Mbits) dup stringwidth pop pop 0 0 moveto
show
grestore
 grestore 
-0.000000 288.000000 translate
288.000000 -288.000000 translate
0.700000 setlinewidth  gsave newpath 0.000000 0.000000 moveto 216.000000 0.000000 lineto stroke
newpath 2.160000 0.000000 moveto 2.160000 -5.000000 lineto stroke
newpath 10.800000 0.000000 moveto 10.800000 -5.000000 lineto stroke
newpath 27.000000 0.000000 moveto 27.000000 -5.000000 lineto stroke
newpath 54.000000 0.000000 moveto 54.000000 -5.000000 lineto stroke
newpath 108.000000 0.000000 moveto 108.000000 -5.000000 lineto stroke
newpath 216.000000 0.000000 moveto 216.000000 -5.000000 lineto stroke
/Times-Roman findfont 7.000000 scalefont setfont
gsave 2.160000 -8.000000 translate 0.000000 rotate
0 -4.200000 translate (20) dup stringwidth pop 2 div neg 0 moveto
show
grestore
gsave 10.800000 -8.000000 translate 0.000000 rotate
0 -4.200000 translate (100) dup stringwidth pop 2 div neg 0 moveto
show
grestore
gsave 27.000000 -8.000000 translate 0.000000 rotate
0 -4.200000 translate (250) dup stringwidth pop 2 div neg 0 moveto
show
grestore
gsave 54.000000 -8.000000 translate 0.000000 rotate
0 -4.200000 translate (500) dup stringwidth pop 2 div neg 0 moveto
show
grestore
gsave 108.000000 -8.000000 translate 0.000000 rotate
0 -4.200000 translate (1000) dup stringwidth pop 2 div neg 0 moveto
show
grestore
gsave 216.000000 -8.000000 translate 0.000000 rotate
0 -4.200000 translate (2000) dup stringwidth pop 2 div neg 0 moveto
show
grestore
/Times-Bold findfont 10.000000 scalefont setfont
gsave 108.000000 -20.200001 translate 0.000000 rotate
0 -6.000000 translate (Array Size \(4-Byte Integers\)) dup stringwidth pop 2 div neg 0 moveto
show
grestore
 grestore 
0.700000 setlinewidth  gsave newpath 0.000000 0.000000 moveto 0.000000 216.000000 lineto stroke
newpath 0.000000 0.000000 moveto -5.000000 0.000000 lineto stroke
newpath 0.000000 8.640000 moveto -2.000000 8.640000 lineto stroke
newpath 0.000000 17.280001 moveto -2.000000 17.280001 lineto stroke
newpath 0.000000 25.920002 moveto -2.000000 25.920002 lineto stroke
newpath 0.000000 34.560001 moveto -2.000000 34.560001 lineto stroke
newpath 0.000000 43.200001 moveto -5.000000 43.200001 lineto stroke
newpath 0.000000 51.840004 moveto -2.000000 51.840004 lineto stroke
newpath 0.000000 60.480003 moveto -2.000000 60.480003 lineto stroke
newpath 0.000000 69.120003 moveto -2.000000 69.120003 lineto stroke
newpath 0.000000 77.760002 moveto -2.000000 77.760002 lineto stroke
newpath 0.000000 86.400002 moveto -5.000000 86.400002 lineto stroke
newpath 0.000000 95.040001 moveto -2.000000 95.040001 lineto stroke
newpath 0.000000 103.680008 moveto -2.000000 103.680008 lineto stroke
newpath 0.000000 112.320007 moveto -2.000000 112.320007 lineto stroke
newpath 0.000000 120.960007 moveto -2.000000 120.960007 lineto stroke
newpath 0.000000 129.600006 moveto -5.000000 129.600006 lineto stroke
newpath 0.000000 138.240005 moveto -2.000000 138.240005 lineto stroke
newpath 0.000000 146.880005 moveto -2.000000 146.880005 lineto stroke
newpath 0.000000 155.520004 moveto -2.000000 155.520004 lineto stroke
newpath 0.000000 164.160004 moveto -2.000000 164.160004 lineto stroke
newpath 0.000000 172.800003 moveto -5.000000 172.800003 lineto stroke
newpath 0.000000 181.440002 moveto -2.000000 181.440002 lineto stroke
newpath 0.000000 190.080002 moveto -2.000000 190.080002 lineto stroke
newpath 0.000000 198.720001 moveto -2.000000 198.720001 lineto stroke
newpath 0.000000 207.360016 moveto -2.000000 207.360016 lineto stroke
newpath 0.000000 216.000015 moveto -5.000000 216.000015 lineto stroke
/Times-Roman findfont 9.000000 scalefont setfont
gsave -8.000000 0.000000 translate 0.000000 rotate
0 -2.700000 translate (0) dup stringwidth pop neg 0 moveto
show
grestore
gsave -8.000000 43.200001 translate 0.000000 rotate
0 -2.700000 translate (5) dup stringwidth pop neg 0 moveto
show
grestore
gsave -8.000000 86.400002 translate 0.000000 rotate
0 -2.700000 translate (10) dup stringwidth pop neg 0 moveto
show
grestore
gsave -8.000000 129.600006 translate 0.000000 rotate
0 -2.700000 translate (15) dup stringwidth pop neg 0 moveto
show
grestore
gsave -8.000000 172.800003 translate 0.000000 rotate
0 -2.700000 translate (20) dup stringwidth pop neg 0 moveto
show
grestore
gsave -8.000000 216.000015 translate 0.000000 rotate
0 -2.700000 translate (25) dup stringwidth pop neg 0 moveto
show
grestore
/Times-Bold findfont 10.000000 scalefont setfont
gsave -24.639999 108.000000 translate 90.000000 rotate
0 0.000000 translate (\(4\) RPC Round Trip Time in ms - Specialized Code) dup stringwidth pop 2 div neg 0 moveto
show
grestore
 grestore 
 gsave 
 gsave 0.700000 setlinewidth  [] 0 setdash
2.160000 5.755105 moveto   10.800000 7.589376 lineto
  27.000000 10.819009 lineto
  54.000000 17.412193 lineto
  108.000000 32.292866 lineto
  216.000000 49.076065 lineto
stroke
0.700000 setlinewidth  [] 0 setdash
 gsave  2.160000 5.755105 translate 0.000000 rotate
newpath 2.000000 2.000000 JDE
gsave  fill grestore
stroke
 grestore  gsave  10.800000 7.589376 translate 0.000000 rotate
newpath 2.000000 2.000000 JDE
gsave  fill grestore
stroke
 grestore  gsave  27.000000 10.819009 translate 0.000000 rotate
newpath 2.000000 2.000000 JDE
gsave  fill grestore
stroke
 grestore  gsave  54.000000 17.412193 translate 0.000000 rotate
newpath 2.000000 2.000000 JDE
gsave  fill grestore
stroke
 grestore  gsave  108.000000 32.292866 translate 0.000000 rotate
newpath 2.000000 2.000000 JDE
gsave  fill grestore
stroke
 grestore  gsave  216.000000 49.076065 translate 0.000000 rotate
newpath 2.000000 2.000000 JDE
gsave  fill grestore
stroke
 grestore  grestore 
 gsave 0.700000 setlinewidth  [] 0 setdash
2.160000 18.480961 moveto   10.800000 23.742720 lineto
  27.000000 31.104000 lineto
  54.000000 45.187202 lineto
  108.000000 76.204803 lineto
  216.000000 141.264008 lineto
stroke
0.700000 setlinewidth  [] 0 setdash
 gsave  2.160000 18.480961 translate 0.000000 rotate
 newpath -2.000000 -2.000000 moveto  2.000000 -2.000000 lineto
  2.000000 2.000000 lineto
  -2.000000 2.000000 lineto
closepath gsave  fill grestore
stroke
 grestore  gsave  10.800000 23.742720 translate 0.000000 rotate
 newpath -2.000000 -2.000000 moveto  2.000000 -2.000000 lineto
  2.000000 2.000000 lineto
  -2.000000 2.000000 lineto
closepath gsave  fill grestore
stroke
 grestore  gsave  27.000000 31.104000 translate 0.000000 rotate
 newpath -2.000000 -2.000000 moveto  2.000000 -2.000000 lineto
  2.000000 2.000000 lineto
  -2.000000 2.000000 lineto
closepath gsave  fill grestore
stroke
 grestore  gsave  54.000000 45.187202 translate 0.000000 rotate
 newpath -2.000000 -2.000000 moveto  2.000000 -2.000000 lineto
  2.000000 2.000000 lineto
  -2.000000 2.000000 lineto
closepath gsave  fill grestore
stroke
 grestore  gsave  108.000000 76.204803 translate 0.000000 rotate
 newpath -2.000000 -2.000000 moveto  2.000000 -2.000000 lineto
  2.000000 2.000000 lineto
  -2.000000 2.000000 lineto
closepath gsave  fill grestore
stroke
 grestore  gsave  216.000000 141.264008 translate 0.000000 rotate
 newpath -2.000000 -2.000000 moveto  2.000000 -2.000000 lineto
  2.000000 2.000000 lineto
  -2.000000 2.000000 lineto
closepath gsave  fill grestore
stroke
 grestore  grestore 
 grestore 
 gsave 10.800000 207.360016 translate 0.000000 rotate
 gsave 0.700000 setlinewidth  [] 0 setdash
0.000000 -2.700000 moveto   24.000000 -2.700000 lineto
stroke
0.700000 setlinewidth  [] 0 setdash
 gsave  12.000000 -2.700000 translate 0.000000 rotate
newpath 2.000000 2.000000 JDE
gsave  fill grestore
stroke
 grestore  grestore 
/Times-Roman findfont 9.000000 scalefont setfont
gsave 28.000000 0.000000 translate 0.000000 rotate
0 -5.400000 translate (PC/Linux - Ethernet 100Mbits) dup stringwidth pop pop 0 0 moveto
show
grestore
 gsave 0.700000 setlinewidth  [] 0 setdash
0.000000 -13.500001 moveto   24.000000 -13.500001 lineto
stroke
0.700000 setlinewidth  [] 0 setdash
 gsave  12.000000 -13.500001 translate 0.000000 rotate
 newpath -2.000000 -2.000000 moveto  2.000000 -2.000000 lineto
  2.000000 2.000000 lineto
  -2.000000 2.000000 lineto
closepath gsave  fill grestore
stroke
 grestore  grestore 
gsave 28.000000 -10.800000 translate 0.000000 rotate
0 -5.400000 translate (IPX/Sunos - ATM 100Mbits) dup stringwidth pop pop 0 0 moveto
show
grestore
 grestore 
-288.000000 288.000000 translate
0.000000 -576.000000 translate
0.700000 setlinewidth  gsave newpath 0.000000 0.000000 moveto 216.000000 0.000000 lineto stroke
newpath 2.160000 0.000000 moveto 2.160000 -5.000000 lineto stroke
newpath 10.800000 0.000000 moveto 10.800000 -5.000000 lineto stroke
newpath 27.000000 0.000000 moveto 27.000000 -5.000000 lineto stroke
newpath 54.000000 0.000000 moveto 54.000000 -5.000000 lineto stroke
newpath 108.000000 0.000000 moveto 108.000000 -5.000000 lineto stroke
newpath 216.000000 0.000000 moveto 216.000000 -5.000000 lineto stroke
/Times-Roman findfont 7.000000 scalefont setfont
gsave 2.160000 -8.000000 translate 0.000000 rotate
0 -4.200000 translate (20) dup stringwidth pop 2 div neg 0 moveto
show
grestore
gsave 10.800000 -8.000000 translate 0.000000 rotate
0 -4.200000 translate (100) dup stringwidth pop 2 div neg 0 moveto
show
grestore
gsave 27.000000 -8.000000 translate 0.000000 rotate
0 -4.200000 translate (250) dup stringwidth pop 2 div neg 0 moveto
show
grestore
gsave 54.000000 -8.000000 translate 0.000000 rotate
0 -4.200000 translate (500) dup stringwidth pop 2 div neg 0 moveto
show
grestore
gsave 108.000000 -8.000000 translate 0.000000 rotate
0 -4.200000 translate (1000) dup stringwidth pop 2 div neg 0 moveto
show
grestore
gsave 216.000000 -8.000000 translate 0.000000 rotate
0 -4.200000 translate (2000) dup stringwidth pop 2 div neg 0 moveto
show
grestore
/Times-Bold findfont 10.000000 scalefont setfont
gsave 108.000000 -20.200001 translate 0.000000 rotate
0 -6.000000 translate (Array Size \(4-Byte Integers\)) dup stringwidth pop 2 div neg 0 moveto
show
grestore
 grestore 
0.700000 setlinewidth  gsave newpath 0.000000 0.000000 moveto 0.000000 216.000000 lineto stroke
newpath 0.000000 0.000000 moveto -5.000000 0.000000 lineto stroke
newpath 0.000000 7.200002 moveto -2.000000 7.200002 lineto stroke
newpath 0.000000 14.400003 moveto -2.000000 14.400003 lineto stroke
newpath 0.000000 21.600006 moveto -2.000000 21.600006 lineto stroke
newpath 0.000000 28.800007 moveto -2.000000 28.800007 lineto stroke
newpath 0.000000 36.000008 moveto -2.000000 36.000008 lineto stroke
newpath 0.000000 43.200012 moveto -2.000000 43.200012 lineto stroke
newpath 0.000000 50.400013 moveto -2.000000 50.400013 lineto stroke
newpath 0.000000 57.600014 moveto -2.000000 57.600014 lineto stroke
newpath 0.000000 64.800018 moveto -2.000000 64.800018 lineto stroke
newpath 0.000000 72.000000 moveto -5.000000 72.000000 lineto stroke
newpath 0.000000 79.199997 moveto -2.000000 79.199997 lineto stroke
newpath 0.000000 86.399986 moveto -2.000000 86.399986 lineto stroke
newpath 0.000000 93.599976 moveto -2.000000 93.599976 lineto stroke
newpath 0.000000 100.799973 moveto -2.000000 100.799973 lineto stroke
newpath 0.000000 107.999969 moveto -2.000000 107.999969 lineto stroke
newpath 0.000000 115.199959 moveto -2.000000 115.199959 lineto stroke
newpath 0.000000 122.399948 moveto -2.000000 122.399948 lineto stroke
newpath 0.000000 129.599945 moveto -2.000000 129.599945 lineto stroke
newpath 0.000000 136.799942 moveto -2.000000 136.799942 lineto stroke
newpath 0.000000 144.000000 moveto -5.000000 144.000000 lineto stroke
newpath 0.000000 151.199997 moveto -2.000000 151.199997 lineto stroke
newpath 0.000000 158.399994 moveto -2.000000 158.399994 lineto stroke
newpath 0.000000 165.599976 moveto -2.000000 165.599976 lineto stroke
newpath 0.000000 172.799973 moveto -2.000000 172.799973 lineto stroke
newpath 0.000000 179.999969 moveto -2.000000 179.999969 lineto stroke
newpath 0.000000 187.199951 moveto -2.000000 187.199951 lineto stroke
newpath 0.000000 194.399948 moveto -2.000000 194.399948 lineto stroke
newpath 0.000000 201.599945 moveto -2.000000 201.599945 lineto stroke
newpath 0.000000 208.799942 moveto -2.000000 208.799942 lineto stroke
newpath 0.000000 216.000000 moveto -5.000000 216.000000 lineto stroke
/Times-Roman findfont 9.000000 scalefont setfont
gsave -8.000000 0.000000 translate 0.000000 rotate
0 -2.700000 translate (1) dup stringwidth pop neg 0 moveto
show
grestore
gsave -8.000000 72.000000 translate 0.000000 rotate
0 -2.700000 translate (2) dup stringwidth pop neg 0 moveto
show
grestore
gsave -8.000000 144.000000 translate 0.000000 rotate
0 -2.700000 translate (3) dup stringwidth pop neg 0 moveto
show
grestore
gsave -8.000000 216.000000 translate 0.000000 rotate
0 -2.700000 translate (4) dup stringwidth pop neg 0 moveto
show
grestore
/Times-Bold findfont 10.000000 scalefont setfont
gsave -20.320000 108.000000 translate 90.000000 rotate
0 0.000000 translate ( \(5\) Speedup Ratio for Client Marshalling) dup stringwidth pop 2 div neg 0 moveto
show
grestore
 grestore 
 gsave 
 gsave 0.700000 setlinewidth  [] 0 setdash
2.160000 9.360000 moveto   10.800000 39.599998 lineto
  27.000000 84.960007 lineto
  54.000000 117.360008 lineto
  108.000000 142.559998 lineto
  216.000000 170.639984 lineto
stroke
0.700000 setlinewidth  [] 0 setdash
 gsave  2.160000 9.360000 translate 0.000000 rotate
newpath 2.000000 2.000000 JDE
gsave  fill grestore
stroke
 grestore  gsave  10.800000 39.599998 translate 0.000000 rotate
newpath 2.000000 2.000000 JDE
gsave  fill grestore
stroke
 grestore  gsave  27.000000 84.960007 translate 0.000000 rotate
newpath 2.000000 2.000000 JDE
gsave  fill grestore
stroke
 grestore  gsave  54.000000 117.360008 translate 0.000000 rotate
newpath 2.000000 2.000000 JDE
gsave  fill grestore
stroke
 grestore  gsave  108.000000 142.559998 translate 0.000000 rotate
newpath 2.000000 2.000000 JDE
gsave  fill grestore
stroke
 grestore  gsave  216.000000 170.639984 translate 0.000000 rotate
newpath 2.000000 2.000000 JDE
gsave  fill grestore
stroke
 grestore  grestore 
 gsave 0.700000 setlinewidth  [] 0 setdash
2.160000 126.720001 moveto   10.800000 184.319992 lineto
  27.000000 192.240005 lineto
  54.000000 159.839996 lineto
  108.000000 153.360016 lineto
  216.000000 132.479996 lineto
stroke
0.700000 setlinewidth  [] 0 setdash
 gsave  2.160000 126.720001 translate 0.000000 rotate
 newpath -2.000000 -2.000000 moveto  2.000000 -2.000000 lineto
  2.000000 2.000000 lineto
  -2.000000 2.000000 lineto
closepath gsave  fill grestore
stroke
 grestore  gsave  10.800000 184.319992 translate 0.000000 rotate
 newpath -2.000000 -2.000000 moveto  2.000000 -2.000000 lineto
  2.000000 2.000000 lineto
  -2.000000 2.000000 lineto
closepath gsave  fill grestore
stroke
 grestore  gsave  27.000000 192.240005 translate 0.000000 rotate
 newpath -2.000000 -2.000000 moveto  2.000000 -2.000000 lineto
  2.000000 2.000000 lineto
  -2.000000 2.000000 lineto
closepath gsave  fill grestore
stroke
 grestore  gsave  54.000000 159.839996 translate 0.000000 rotate
 newpath -2.000000 -2.000000 moveto  2.000000 -2.000000 lineto
  2.000000 2.000000 lineto
  -2.000000 2.000000 lineto
closepath gsave  fill grestore
stroke
 grestore  gsave  108.000000 153.360016 translate 0.000000 rotate
 newpath -2.000000 -2.000000 moveto  2.000000 -2.000000 lineto
  2.000000 2.000000 lineto
  -2.000000 2.000000 lineto
closepath gsave  fill grestore
stroke
 grestore  gsave  216.000000 132.479996 translate 0.000000 rotate
 newpath -2.000000 -2.000000 moveto  2.000000 -2.000000 lineto
  2.000000 2.000000 lineto
  -2.000000 2.000000 lineto
closepath gsave  fill grestore
stroke
 grestore  grestore 
 grestore 
 gsave 54.000000 201.599991 translate 0.000000 rotate
 gsave 0.700000 setlinewidth  [] 0 setdash
0.000000 -2.700000 moveto   24.000000 -2.700000 lineto
stroke
0.700000 setlinewidth  [] 0 setdash
 gsave  12.000000 -2.700000 translate 0.000000 rotate
newpath 2.000000 2.000000 JDE
gsave  fill grestore
stroke
 grestore  grestore 
/Times-Roman findfont 9.000000 scalefont setfont
gsave 28.000000 0.000000 translate 0.000000 rotate
0 -5.400000 translate (PC/Linux) dup stringwidth pop pop 0 0 moveto
show
grestore
 gsave 0.700000 setlinewidth  [] 0 setdash
0.000000 -13.500001 moveto   24.000000 -13.500001 lineto
stroke
0.700000 setlinewidth  [] 0 setdash
 gsave  12.000000 -13.500001 translate 0.000000 rotate
 newpath -2.000000 -2.000000 moveto  2.000000 -2.000000 lineto
  2.000000 2.000000 lineto
  -2.000000 2.000000 lineto
closepath gsave  fill grestore
stroke
 grestore  grestore 
gsave 28.000000 -10.800000 translate 0.000000 rotate
0 -5.400000 translate (IPX/Sunos) dup stringwidth pop pop 0 0 moveto
show
grestore
 grestore 
-0.000000 576.000000 translate
288.000000 -576.000000 translate
0.700000 setlinewidth  gsave newpath 0.000000 0.000000 moveto 216.000000 0.000000 lineto stroke
newpath 2.160000 0.000000 moveto 2.160000 -5.000000 lineto stroke
newpath 10.800000 0.000000 moveto 10.800000 -5.000000 lineto stroke
newpath 27.000000 0.000000 moveto 27.000000 -5.000000 lineto stroke
newpath 54.000000 0.000000 moveto 54.000000 -5.000000 lineto stroke
newpath 108.000000 0.000000 moveto 108.000000 -5.000000 lineto stroke
newpath 216.000000 0.000000 moveto 216.000000 -5.000000 lineto stroke
/Times-Roman findfont 7.000000 scalefont setfont
gsave 2.160000 -8.000000 translate 0.000000 rotate
0 -4.200000 translate (20) dup stringwidth pop 2 div neg 0 moveto
show
grestore
gsave 10.800000 -8.000000 translate 0.000000 rotate
0 -4.200000 translate (100) dup stringwidth pop 2 div neg 0 moveto
show
grestore
gsave 27.000000 -8.000000 translate 0.000000 rotate
0 -4.200000 translate (250) dup stringwidth pop 2 div neg 0 moveto
show
grestore
gsave 54.000000 -8.000000 translate 0.000000 rotate
0 -4.200000 translate (500) dup stringwidth pop 2 div neg 0 moveto
show
grestore
gsave 108.000000 -8.000000 translate 0.000000 rotate
0 -4.200000 translate (1000) dup stringwidth pop 2 div neg 0 moveto
show
grestore
gsave 216.000000 -8.000000 translate 0.000000 rotate
0 -4.200000 translate (2000) dup stringwidth pop 2 div neg 0 moveto
show
grestore
/Times-Bold findfont 10.000000 scalefont setfont
gsave 108.000000 -20.200001 translate 0.000000 rotate
0 -6.000000 translate (Array Size \(4-Byte Integers\)) dup stringwidth pop 2 div neg 0 moveto
show
grestore
 grestore 
0.700000 setlinewidth  gsave newpath 0.000000 0.000000 moveto 0.000000 216.000000 lineto stroke
newpath 0.000000 0.000000 moveto -5.000000 0.000000 lineto stroke
newpath 0.000000 27.000010 moveto -2.000000 27.000010 lineto stroke
newpath 0.000000 54.000019 moveto -5.000000 54.000019 lineto stroke
newpath 0.000000 81.000031 moveto -2.000000 81.000031 lineto stroke
newpath 0.000000 108.000038 moveto -5.000000 108.000038 lineto stroke
newpath 0.000000 135.000046 moveto -2.000000 135.000046 lineto stroke
newpath 0.000000 162.000061 moveto -5.000000 162.000061 lineto stroke
newpath 0.000000 189.000061 moveto -2.000000 189.000061 lineto stroke
/Times-Roman findfont 9.000000 scalefont setfont
gsave -8.000000 0.000000 translate 0.000000 rotate
0 -2.700000 translate (1.0) dup stringwidth pop neg 0 moveto
show
grestore
gsave -8.000000 54.000019 translate 0.000000 rotate
0 -2.700000 translate (1.2) dup stringwidth pop neg 0 moveto
show
grestore
gsave -8.000000 108.000038 translate 0.000000 rotate
0 -2.700000 translate (1.4) dup stringwidth pop neg 0 moveto
show
grestore
gsave -8.000000 162.000061 translate 0.000000 rotate
0 -2.700000 translate (1.6) dup stringwidth pop neg 0 moveto
show
grestore
/Times-Bold findfont 10.000000 scalefont setfont
gsave -28.959999 108.000000 translate 90.000000 rotate
0 0.000000 translate (\(6\) Speedup Ratio for RPC Round Trip Time) dup stringwidth pop 2 div neg 0 moveto
show
grestore
 grestore 
 gsave 
 gsave 0.700000 setlinewidth  [] 0 setdash
2.160000 10.799991 moveto   10.800000 35.100002 lineto
  27.000000 70.200005 lineto
  54.000000 81.000000 lineto
  108.000000 91.800018 lineto
  216.000000 91.800018 lineto
stroke
0.700000 setlinewidth  [] 0 setdash
 gsave  2.160000 10.799991 translate 0.000000 rotate
newpath 2.000000 2.000000 JDE
gsave  fill grestore
stroke
 grestore  gsave  10.800000 35.100002 translate 0.000000 rotate
newpath 2.000000 2.000000 JDE
gsave  fill grestore
stroke
 grestore  gsave  27.000000 70.200005 translate 0.000000 rotate
newpath 2.000000 2.000000 JDE
gsave  fill grestore
stroke
 grestore  gsave  54.000000 81.000000 translate 0.000000 rotate
newpath 2.000000 2.000000 JDE
gsave  fill grestore
stroke
 grestore  gsave  108.000000 91.800018 translate 0.000000 rotate
newpath 2.000000 2.000000 JDE
gsave  fill grestore
stroke
 grestore  gsave  216.000000 91.800018 translate 0.000000 rotate
newpath 2.000000 2.000000 JDE
gsave  fill grestore
stroke
 grestore  grestore 
 gsave 0.700000 setlinewidth  [] 0 setdash
2.160000 21.600014 moveto   10.800000 54.000019 lineto
  27.000000 105.300011 lineto
  54.000000 135.000015 lineto
  108.000000 143.100006 lineto
  216.000000 145.800003 lineto
stroke
0.700000 setlinewidth  [] 0 setdash
 gsave  2.160000 21.600014 translate 0.000000 rotate
 newpath -2.000000 -2.000000 moveto  2.000000 -2.000000 lineto
  2.000000 2.000000 lineto
  -2.000000 2.000000 lineto
closepath gsave  fill grestore
stroke
 grestore  gsave  10.800000 54.000019 translate 0.000000 rotate
 newpath -2.000000 -2.000000 moveto  2.000000 -2.000000 lineto
  2.000000 2.000000 lineto
  -2.000000 2.000000 lineto
closepath gsave  fill grestore
stroke
 grestore  gsave  27.000000 105.300011 translate 0.000000 rotate
 newpath -2.000000 -2.000000 moveto  2.000000 -2.000000 lineto
  2.000000 2.000000 lineto
  -2.000000 2.000000 lineto
closepath gsave  fill grestore
stroke
 grestore  gsave  54.000000 135.000015 translate 0.000000 rotate
 newpath -2.000000 -2.000000 moveto  2.000000 -2.000000 lineto
  2.000000 2.000000 lineto
  -2.000000 2.000000 lineto
closepath gsave  fill grestore
stroke
 grestore  gsave  108.000000 143.100006 translate 0.000000 rotate
 newpath -2.000000 -2.000000 moveto  2.000000 -2.000000 lineto
  2.000000 2.000000 lineto
  -2.000000 2.000000 lineto
closepath gsave  fill grestore
stroke
 grestore  gsave  216.000000 145.800003 translate 0.000000 rotate
 newpath -2.000000 -2.000000 moveto  2.000000 -2.000000 lineto
  2.000000 2.000000 lineto
  -2.000000 2.000000 lineto
closepath gsave  fill grestore
stroke
 grestore  grestore 
 grestore 
 gsave 10.800000 189.000031 translate 0.000000 rotate
 gsave 0.700000 setlinewidth  [] 0 setdash
0.000000 -2.700000 moveto   24.000000 -2.700000 lineto
stroke
0.700000 setlinewidth  [] 0 setdash
 gsave  12.000000 -2.700000 translate 0.000000 rotate
newpath 2.000000 2.000000 JDE
gsave  fill grestore
stroke
 grestore  grestore 
/Times-Roman findfont 9.000000 scalefont setfont
gsave 28.000000 0.000000 translate 0.000000 rotate
0 -5.400000 translate (PC/Linux - Ethernet 100Mbits) dup stringwidth pop pop 0 0 moveto
show
grestore
 gsave 0.700000 setlinewidth  [] 0 setdash
0.000000 -13.500001 moveto   24.000000 -13.500001 lineto
stroke
0.700000 setlinewidth  [] 0 setdash
 gsave  12.000000 -13.500001 translate 0.000000 rotate
 newpath -2.000000 -2.000000 moveto  2.000000 -2.000000 lineto
  2.000000 2.000000 lineto
  -2.000000 2.000000 lineto
closepath gsave  fill grestore
stroke
 grestore  grestore 
gsave 28.000000 -10.800000 translate 0.000000 rotate
0 -5.400000 translate (IPX/Sunos - ATM 100Mbits) dup stringwidth pop pop 0 0 moveto
show
grestore
 grestore 
-288.000000 576.000000 translate
 grestore 
%%EndDocument
 @endspecial 3897 5089 V 0 5092 3900 4 v 763 5240 a(Figure)20
b(6:)25 b(Performance)18 b(Comparison)h(between)g(IPX/SunOS)h(and)g
(PC/Linux)0 5731 y Fm(PI)d(n)c(\011)g(1094)p eop
%%Page: 12 14
12 13 bop 0 352 a Fr(12)507 b Fp(Gilles)21 b(Muller)-9
b(,)20 b(Renaud)e(Marlet,)j(Eug)o(en-Nicolae)d(V)-9 b(olansc)o(hi,)18
b(Charles)j(Consel,)f(Calton)g(Pu)g(&)g(Ashvin)g(Goel)p
0 406 3900 8 v 452 609 2996 4 v 450 708 4 100 v 467 708
V 519 678 a Fr(Array)f(Size)p 924 708 V 924 708 V 483
w(IPX/SunOs)p 2169 708 V 2186 708 V 2185 708 V 909 w(PC/Linux)p
3429 708 V 3446 708 V 926 712 2522 4 v 450 808 4 100
v 467 808 V 924 808 V 976 778 a(Original)p 1301 808 V
98 w(Specialized)p 1783 808 V 98 w(Speedup)p 2169 808
V 2186 808 V 115 w(Original)p 2561 808 V 98 w(Specialized)p
3044 808 V 98 w(Speedup)p 3429 808 V 3446 808 V 452 811
2996 4 v 452 828 V 450 927 4 100 v 467 927 V 519 898
a Fp(20)p 924 927 V 438 w Fr(2.32)p 1301 927 V 283 w(2.13)p
1783 927 V 287 w Fq(1.10)p 2169 927 V 2186 927 V 250
w Fr(0.69)p 2561 927 V 283 w(0.66)p 3044 927 V 287 w
Fq(1.05)p 3429 927 V 3446 927 V 452 931 2996 4 v 450
1030 4 100 v 467 1030 V 519 1000 a Fp(100)p 924 1030
V 396 w Fr(3.32)p 1301 1030 V 283 w(2.74)p 1783 1030
V 287 w Fq(1.20)p 2169 1030 V 2186 1030 V 250 w Fr(0.99)p
2561 1030 V 283 w(0.87)p 3044 1030 V 287 w Fq(1.15)p
3429 1030 V 3446 1030 V 452 1034 2996 4 v 450 1133 4
100 v 467 1133 V 519 1103 a Fp(250)p 924 1133 V 396 w
Fr(5.02)p 1301 1133 V 283 w(3.60)p 1783 1133 V 287 w
Fq(1.40)p 2169 1133 V 2186 1133 V 250 w Fr(1.58)p 2561
1133 V 283 w(1.25)p 3044 1133 V 287 w Fq(1.25)p 3429
1133 V 3446 1133 V 452 1137 2996 4 v 450 1236 4 100 v
467 1236 V 519 1206 a Fp(500)p 924 1236 V 396 w Fr(7.86)p
1301 1236 V 283 w(5.23)p 1783 1236 V 287 w Fq(1.50)p
2169 1236 V 2186 1236 V 250 w Fr(2.62)p 2561 1236 V 283
w(2.01)p 3044 1236 V 287 w Fq(1.30)p 3429 1236 V 3446
1236 V 452 1240 2996 4 v 450 1339 4 100 v 467 1339 V
519 1309 a Fp(1000)p 924 1339 V 334 w Fr(13.58)p 1301
1339 V 261 w(8.82)p 1783 1339 V 287 w Fq(1.55)p 2169
1339 V 2186 1339 V 250 w Fr(4.26)p 2561 1339 V 283 w(3.17)p
3044 1339 V 287 w Fq(1.35)p 3429 1339 V 3446 1339 V 452
1343 2996 4 v 450 1442 4 100 v 467 1442 V 519 1412 a
Fp(2000)p 924 1442 V 334 w Fr(25.24)p 1301 1442 V 240
w(16.35)p 1783 1442 V 266 w Fq(1.55)p 2169 1442 V 2186
1442 V 250 w Fr(7.61)p 2561 1442 V 283 w(5.68)p 3044
1442 V 287 w Fq(1.35)p 3429 1442 V 3446 1442 V 452 1445
2996 4 v 1303 1676 a Fr(T)-7 b(able)20 b(2:)25 b(Round)20
b(trip)g(performance)d(in)j(ms)p 368 1797 3165 4 v 366
1897 4 100 v 383 1897 V 434 1867 a(Module)p 1234 1897
V 1251 1897 V 608 w(Generic)p 1613 1897 V 1630 1897 V
1629 1897 V 618 w(Specialized)f(\(array)g(size\))p 3514
1897 V 3531 1897 V 1631 1900 1902 4 v 366 1997 4 100
v 383 1997 V 1234 1997 V 1251 1997 V 1613 1997 V 1630
1997 V 1743 1967 a(20)p 1937 1997 V 203 w(100)p 2244
1997 V 181 w(250)p 2551 1997 V 181 w(500)p 2858 1997
V 160 w(1000)p 3165 1997 V 160 w(2000)p 3514 1997 V 3531
1997 V 368 2000 3165 4 v 368 2016 V 366 2116 4 100 v
383 2116 V 434 2086 a(client)h(code)p 1234 2116 V 1251
2116 V 533 w(20004)p 1613 2116 V 1630 2116 V 1629 2116
V 1020 w(-)p 3514 2116 V 3531 2116 V 368 2119 3165 4
v 366 2219 4 100 v 383 2219 V 434 2189 a(specialized)g(client)g(code)p
1234 2219 V 1251 2219 V 1613 2219 V 1630 2219 V 494 w(24340)p
1937 2219 V 97 w(27540)p 2244 2219 V 97 w(33540)p 2551
2219 V 97 w(43540)p 2858 2219 V 98 w(63540)p 3165 2219
V 97 w(111348)p 3514 2219 V 3531 2219 V 368 2222 3165
4 v 1188 2453 a(T)-7 b(able)20 b(3:)25 b(Size)c(of)f(the)g(SunOS)g
(binaries)g(\(in)g(bytes\))0 2720 y Fq(Round-trip)27
b(RPC.)82 b Fr(The)27 b(application)e(le)n(v)o(el)h(benchmark)e
(results)k(are)e(detailed)g(in)h(T)-7 b(able)27 b(2.)45
b(The)26 b(specialized)h(code)f(runs)g(up)0 2820 y(to)31
b(1.55)f(f)o(aster)i(than)e(the)i(non-specialized)c(one)j(on)g(the)g
(IPX/SunOS,)g(and)f(1.35)g(on)h(the)g(PC/Linux.)58 b(Similar)31
b(to)g(the)h(micro-)0 2919 y(benchmark,)26 b(the)h(speedup)e(decreases)
i(with)g(the)g(size)h(of)e(the)h(data)g(due)f(to)i(memory)d(accesses.)
46 b(In)26 b(addition)g(to)h(these)g(memory)0 3019 y(accesses,)d(the)f
(RPC)i(includes)d(a)h(call)h(to)f Fk(bzero)f Fr(to)h(initialize)h(the)e
(input)h(b)n(uf)n(fer)e(on)i(both)f(the)h(client)g(and)f(serv)o(er)g
(sides)i(\(hence)e(it)0 3119 y(does)g(not)g(appear)f(in)i(the)f
(marshaling)f(micro-benchmark.\))27 b(These)c(initializations)f
(further)f(increase)h(memory)e(access)j(o)o(v)o(erhead)0
3218 y(as)e(the)f(data)g(size)h(gro)n(ws.)0 3511 y Fq(Code)i(size.)83
b Fr(As)25 b(sho)n(wn)d(in)i(T)-7 b(able)23 b(3,)h(the)g(specialized)f
(code)g(is)h(al)o(w)o(ays)g(lar)o(ger)e(than)h(the)g(original)g(one.)34
b(The)23 b(reason)g(is)h(that)g(the)0 3610 y(def)o(ault)e(specialized)g
(code)g(unrolls)g(the)g(array)g(encoding/decoding)c(loops)k(completely)
-5 b(.)31 b(It)23 b(should)e(noticed)h(that)g(the)h(specialized)0
3710 y(code)c(is)i(also)g(lar)o(ger)e(for)g(small)i(array)e(size.)26
b(This)20 b(due)f(to)i(the)f(f)o(act)g(that)g(the)g(specialized)g(code)
f(also)i(contains)e(some)h(unspecialized)0 3810 y(generic)f(functions)g
(because)g(of)h(error)f(handling.)125 3981 y(While)j(loop)f(unrolling)g
(increases)g(code)h(sizes,)h(it)g(also)g(af)n(fects)e(cache)h(locality)
-5 b(.)30 b(An)22 b(additional)f(e)o(xperiment)f(w)o(as)j(conducted)0
4080 y(on)h(the)g(PC)h(to)f(measure)g(this)h(ef)n(fect.)36
b(Since)24 b(completely)f(unrolling)f(lar)o(ge)h(loops)h(may)f(e)o
(xceed)g(the)h(instruction)f(cache)h(capacity)-5 b(,)0
4180 y(we)25 b(only)e(partially)h(unrolled)e(the)i(loop)g(to)g(adjust)g
(its)i(body)d(to)h(the)g(cache)g(size.)38 b(This)24 b(transformation)e
(w)o(as)j(done)e(manually)-5 b(.)36 b(As)0 4280 y(sho)n(wn)19
b(in)i(T)-7 b(able)20 b(4,)g(the)g(resulting)g(code)f(e)o(xhibit)g(a)i
(lo)n(wer)e(deterioration)f(of)i(performance)e(as)j(the)f(number)e(of)i
(elements)g(gro)n(ws.)125 4451 y(In)f(the)i(future,)d(such)i(strate)o
(gy)g(to)g(control)f(loop)g(unrolling)g(is)i(planned)d(to)j(be)f
(introduced)e(in)i(T)-6 b(empo.)0 4803 y Ft(6)119 b(Discussion)0
5060 y Fr(In)27 b(this)g(section)f(we)i(discuss)f(our)f(e)o(xperience)f
(in)h(using)h(T)-6 b(empo)26 b(for)g(specialization)g(\(Section)g
(6.1\),)h(the)g(lessons)g(learned)f(from)0 5159 y(w)o(orking)j(with)h
(e)o(xisting)g(commercial)f(code)h(\(Section)g(6.2\),)h(and)f(the)h
(rele)n(v)n(ance)d(of)j(this)g(kind)e(of)h(specialization)g(for)g
(general)0 5259 y(system)20 b(code)g(\(Section)f(6.3.\))3782
5731 y Fm(Irisa)p eop
%%Page: 13 15
13 14 bop 0 352 a Fp(F)-6 b(ast,)20 b(Optimized)g(Sun)f(RPC)i(Using)f
(A)n(utomatic)f(Pr)l(o)o(gr)o(am)h(Specialization)1582
b Fr(13)p 0 406 3900 8 v 609 609 2682 4 v 607 708 4 100
v 624 708 V 676 678 a(Array)19 b(Size)p 1081 708 V 1081
708 V 984 w(PC/Linux)p 3273 708 V 3290 708 V 1083 712
2209 4 v 607 808 4 100 v 624 808 V 1081 808 V 1133 778
a(Original)p 1457 808 V 1474 808 V 114 w(Specialized)p
1956 808 V 99 w(Speedup)p 2342 808 V 2359 808 V 114 w(250-unrolled)p
2887 808 V 95 w(Speedup)p 3273 808 V 3290 808 V 609 811
2682 4 v 609 828 V 607 927 4 100 v 624 927 V 676 898
a Fp(500)p 1081 927 V 396 w Fr(0.29)p 1457 927 V 1474
927 V 299 w(0.11)p 1956 927 V 287 w Fq(2.65)p 2342 927
V 2359 927 V 306 w Fr(0.108)p 2887 927 V 289 w Fq(2.70)p
3273 927 V 3290 927 V 609 931 2682 4 v 607 1030 4 100
v 624 1030 V 676 1000 a Fp(1000)p 1081 1030 V 354 w Fr(0.51)p
1457 1030 V 1474 1030 V 299 w(0.17)p 1956 1030 V 287
w Fq(3.00)p 2342 1030 V 2359 1030 V 327 w Fr(0.15)p 2887
1030 V 310 w Fq(3.40)p 3273 1030 V 3290 1030 V 609 1034
2682 4 v 607 1133 4 100 v 624 1133 V 676 1103 a Fp(2000)p
1081 1133 V 354 w Fr(0.97)p 1457 1133 V 1474 1133 V 299
w(0.29)p 1956 1133 V 287 w Fq(3.35)p 2342 1133 V 2359
1133 V 327 w Fr(0.25)p 2887 1133 V 310 w Fq(3.90)p 3273
1133 V 3290 1133 V 609 1137 2682 4 v 743 1368 a Fr(T)-7
b(able)20 b(4:)26 b(Specialization)19 b(with)h(loops)g(of)g
(250-unrolled)c(inte)o(gers)k(\(times)g(in)g(ms\))0 1635
y Fg(6.1)99 b(Experience)27 b(with)e(T)-9 b(empo)0 1862
y Fr(T)j(empo)18 b(is)h(a)g(state-of-art)f(program)e(specializer)i
(under)f(acti)n(v)o(e)h(de)n(v)o(elopment.)k(Most)d(of)f(its)i
(features)e(described)f(in)i(Section)f(4)h(were)0 1961
y(moti)n(v)n(ated)g(by)g(system)i(code)e(e)o(xperiments,)f(including)h
(the)h(RPC)i(reported)c(in)i(this)h(paper)-5 b(.)125
2133 y(Although)25 b(priority)g(so)j(f)o(ar)f(has)g(been)f(gi)n(v)o(en)
g(to)h(the)g(realization)f(of)h(program)e(specialization)h(technology)f
(\(i.e.,)j(the)f(partial)0 2232 y(e)n(v)n(aluation)19
b(\223engine\224\),)f(a)i(suitable)g(user)h(interf)o(ace)e(is)i(needed)
e(for)h(the)g(handling)e(of)i(real)g(w)o(orld)g(code.)k(T)-6
b(empo)20 b(allo)n(ws)g(the)g(user)g(to)0 2332 y(visualize)j(the)g
(results)g(of)g(the)g(analysis)h(before)d(specialization.)33
b(Dif)n(ferent)22 b(colors)h(are)g(used)g(to)g(display)f(the)i(static)f
(and)g(dynamic)0 2431 y(parts)k(of)g(a)g(program,)g(thus)g(helping)e
(the)i(user)g(to)h(follo)n(w)e(the)h(propagation)d(of)j(the)g(inputs)f
(declared)g(as)i(kno)n(wn)e(and)g(assess)j(the)0 2531
y(de)o(gree)g(of)h(specialization)f(to)i(be)f(obtained.)54
b(After)30 b(specialization,)h(the)g(user)f(can)g(compare)f(the)h
(original)f(program)f(with)j(the)0 2631 y(specialized)20
b(program,)d(and)j(decide)f(whether)h(appropriate)d(reduction)i(and)g
(residualization)g(ha)n(v)o(e)h(been)f(carried)g(out.)125
2802 y(As)j(for)g(an)o(y)f(other)h(optimizer)m(,)e(the)i(programmer)e
(needs)h(to)h(ha)n(v)o(e)g(some)g(kno)n(wledge)e(about)h(the)h
(optimization)f(process)g(itself.)0 2901 y(In)f(the)g(case)h(of)f
(partial)g(e)n(v)n(aluation,)e(one)h(needs)h(to)h(kno)n(w)e(about)g
(fundamental)f(concepts)h(such)h(as)h(binding)d(times.)0
3211 y Fg(6.2)99 b(W)-7 b(orking)25 b(with)g(Existing)f(Code)0
3438 y Fr(An)d(important)e(lesson)j(learned)e(in)h(this)g(e)o
(xperiment)e(is)j(that)f(e)o(xisting)f(code)h(is)h(a)f(challenge)f(for)
g(an)h(optimization)e(technique)h(such)0 3537 y(as)j(partial)e(e)n(v)n
(aluation.)29 b(Indeed,)21 b(lik)o(e)h(an)o(y)g(other)f(optimization)f
(technique,)h(partial)g(e)n(v)n(aluation)g(is)i(sensiti)n(v)o(e)f(to)g
(v)n(arious)f(program)0 3637 y(features)26 b(such)g(as)i(program)c
(structure)i(and)g(data)g(or)o(ganization.)41 b(As)27
b(a)g(result,)h(specializing)e(an)h(e)o(xisting)f(program)e(requires)i
(an)0 3737 y(intimate)j(kno)n(wledge)e(of)i(its)i(structure)d(and)h
(algorithms.)52 b(It)29 b(also)h(requires)f(the)g(programmer)d(to)k
(estimate)g(what)f(parts)g(of)h(the)0 3836 y(program)22
b(should)h(be)i(e)n(v)n(aluated)d(a)o(w)o(ay)-5 b(.)37
b(This)24 b(is)h(in)g(contrast)e(with)i(a)g(situation)e(where)h(the)g
(same)h(programmer)c(both)i(writes)i(and)0 3936 y(specializes)20
b(some)g(code:)25 b(he)20 b(can)g(structure)f(it)i(with)g
(specialization)e(in)h(mind.)125 4107 y(Careful)c(inspection)f(of)i
(the)g(resulting)f(specialized)g(code)g(sho)n(ws)h(fe)n(w)f
(opportunities)f(for)h(further)f(optimization)g(without)h(major)0
4207 y(restructuring)d(the)j(RPC)h(code.)23 b(Ho)n(we)n(v)o(er)m(,)14
b(T)-6 b(empo)14 b(is)j(not)e(the)h(panacea)e(and)h(we)h(occasionally)e
(had)h(to)h(slightly)f(modify)f(the)i(original)0 4306
y(source)k(code)g(in)i(order)d(to)i(obtain)f(suitable)h
(specializations.)27 b(Most)21 b(modi\002cations)e(were)i(to)g(mak)o(e)
g(the)g(some)f(v)n(alue)h(a)n(v)n(ailable)f(for)0 4406
y(specialization.)125 4577 y(More)d(speci\002cally)-5
b(,)17 b(on)h(the)g(client)g(side,)h(there)e(e)o(xists)h(a)h(v)n
(ariable)e(named)g Fk(inlen)g Fr(that)h(stores)h(the)f(length)f(of)g
(already)g(decoded)0 4677 y(data.)42 b(When)26 b(decoding)e(the)i
(input)f(b)n(uf)n(fer)m(,)h(the)g(v)n(ariable)f Fk(inlen)h
Fr(is)h(dynamic)d(because)h(the)h(remote)g(procedure)d(call)k(may)e(f)o
(ail;)0 4776 y(ill-formed)e(recei)n(v)o(ed)g(data)i(must)g(also)g(be)g
(guarded)e(against.)38 b(Ho)n(we)n(v)o(er)m(,)24 b(if)h(no)g(error)f
(occurs,)h Fk(inlen)f Fr(contains)g(the)h(size)h(of)f(the)0
4876 y(e)o(xpected)i(result)i(data,)h(which)e(is)h(usually)f(\002x)o
(ed)g(unless)h(the)g(data)f(structures)g(ha)n(v)o(e)g(v)n(ariable)f
(length.)49 b(In)29 b(this)g(case,)i(we)e(kno)n(w)0 4975
y(the)c(e)o(xpected)e(length)h(of)h(the)g(input)f(message,)i(noted)e
Fk(expected_inlen)p Fr(.)37 b(In)25 b(the)g(unmarshaling)d(part,)k(the)
f(follo)n(wing)e(code)0 5075 y(sk)o(eleton)0 5731 y Fm(PI)17
b(n)c(\011)g(1094)p eop
%%Page: 14 16
14 15 bop 0 352 a Fr(14)507 b Fp(Gilles)21 b(Muller)-9
b(,)20 b(Renaud)e(Marlet,)j(Eug)o(en-Nicolae)d(V)-9 b(olansc)o(hi,)18
b(Charles)j(Consel,)f(Calton)g(Pu)g(&)g(Ashvin)g(Goel)p
0 406 3900 8 v 149 675 a Fk(inlen)49 b(=)h Fb(<dyn>)p
Fk(;)149 775 y Fb(<statements>)p Fk(;)0 991 y Fr(is)21
b(manually)e(re)n(written)g(as)149 1198 y Fk(inlen)49
b(=)h Fb(<dyn>)p Fk(;)149 1298 y(if)g(\(inlen)f(==)g(expected_inlen\))e
({)448 1398 y(inlen)i(=)h(expected_inlen;)448 1497 y
Fb(<statements>)p Fk(;)149 1597 y(})g(else)448 1697 y
Fb(<statements>)p Fk(;)0 1903 y Fr(As)29 b(a)f(result,)i(in)e(the)g
(\223then\224)f(branch,)h(the)g(kno)n(wn)e(v)n(alue)h(of)h(the)g(v)n
(ariable)f Fk(expected_inlen)f Fr(is)j(assigned)e(to)h
Fk(inlen)p Fr(;)k(the)0 2002 y(follo)n(wing)18 b(statements)i(may)g(no)
n(w)f(e)o(xploit)g(this)i(additional)d(v)n(alue.)24 b(Y)-8
b(et,)20 b(the)g(\223else\224)g(branch)f(preserv)o(es)g(the)h
(semantics:)25 b(it)20 b(handles)0 2102 y(the)g(general)f(case.)125
2273 y(The)25 b(actual)h(v)n(alue)g(for)f Fk(expected_inlen)f
Fr(may)i(be)g(computed)e(at)i(specialization)g(time)g(with)g(a)h(dummy)
d(encoding-call)0 2373 y(to)e(the)g(generic)e(encoding/decoding)e
(function.)28 b(W)-7 b(e)23 b(are)e(thus)h(able)g(to)g(specialize)f
(the)h(client)g(decoding.)28 b(This)22 b(situation)f(actually)0
2472 y(occurred)26 b(twice)h(and)g(thus)h(does)f(not)h(contradict)e
(our)g(claim)i(of)f(automatically)f(treating)h(e)o(xisting)g(system)h
(code.)46 b(Ov)o(erall,)29 b(the)0 2572 y(current)19
b(v)o(ersion)g(of)h(T)-6 b(empo)19 b(is)i(v)o(ery)e(successful)h(in)g
(the)h(specialization)e(of)h(system)g(code)g(such)g(as)g(Sun)g(RPC.)0
2875 y Fg(6.3)99 b(General)25 b(A)n(pplicability)0 3102
y Fr(W)-7 b(e)20 b(consider)e(the)i(Sun)f(RPC)h(to)g(be)f(representati)
n(v)o(e)e(of)i(e)o(xisting)f(system)i(code,)e(not)h(only)g(because)f
(it)i(is)g(mature,)e(commercial,)g(and)0 3202 y(standard)j(code,)i(b)n
(ut)f(also)h(because)f(its)i(structure)e(re\003ects)g(production)e
(quality)i(concerns)f(as)j(well)f(as)g(unrestrained)e(use)i(of)f(the)h
(C)0 3302 y(programming)17 b(language.)125 3473 y(The)h(e)o(xamples)g
(that)i(we)f(highlighted)e(in)i(Section)g(3)g(\(i.e.,)g(dispatching,)f
(b)n(uf)n(fer)f(o)o(v)o(er\003o)n(w)h(checking,)f(handling)g(of)i(e)o
(xit)g(status\))0 3572 y(are)29 b(typical)g(instances)g(of)g(general)f
(constructions)f(found)h(in)h(system)h(code.)51 b(The)29
b(f)o(act)g(that)g(T)-6 b(empo)29 b(is)h(able)f(to)g(automatically)0
3672 y(specialize)i(them)h(reinforces)e(our)g(con)m(viction)g(that)h
(automatic)g(optimization)f(tools)h(lik)o(e)h(partial)f(e)n(v)n
(aluators)f(are)i(rele)n(v)n(ant)e(for)0 3772 y(system)20
b(code)g(production.)0 4117 y Ft(7)119 b(Related)31 b(W)-9
b(ork)0 4374 y Fr(The)15 b(specialization)f(techniques)g(presented)g
(in)i(this)g(paper)e(relate)h(to)g(man)o(y)g(studies)g(in)h(v)n(arious)
e(research)g(domains)g(such)h(as)h(speci\002c)0 4474
y(RPC)25 b(optimizations,)e(k)o(ernel)g(le)n(v)o(el)g(optimizations,)g
(operating)f(system)i(structuring,)f(and)g(automatic)g(program)e
(transformation.)0 4574 y(Let)f(us)h(outline)e(the)i(salient)f(aspects)
h(of)f(these)g(research)f(directions.)0 4860 y Fq(General)27
b(RPC)h(optimizations.)82 b Fr(A)28 b(considerable)e(amount)h(of)g(w)o
(ork)g(has)h(been)g(dedicated)e(to)i(optimize)f(RPC)i(\(see)f([32)o(,)g
(17)o(,)0 4960 y(36)o(,)e(25)o(,)h(24)o(]\).)42 b(In)26
b(most)g(of)g(these)g(studies,)h(a)g(f)o(ast)g(path)e(in)h(the)g(RPC)i
(is)f(identi\002ed,)f(corresponding)d(to)j(a)h(performance-critical,)0
5060 y(frequently)d(used)h(case.)43 b(The)26 b(f)o(ast)g(path)g(is)h
(then)e(optimized)g(using)g(a)i(wide)e(range)g(of)h(techniques.)41
b(The)25 b(optimizations)g(address)0 5159 y(dif)n(ferent)16
b(layers)i(of)f(the)h(protocol)e(stack,)i(and)f(are)h(performed)d
(either)i(manually)g(\(by)g(re)n(writing)f(a)j(layer\),)e(or)g(by)g(a)i
(domain-speci\002c)0 5259 y(optimizer)-5 b(.)3782 5731
y Fm(Irisa)p eop
%%Page: 15 17
15 16 bop 0 352 a Fp(F)-6 b(ast,)20 b(Optimized)g(Sun)f(RPC)i(Using)f
(A)n(utomatic)f(Pr)l(o)o(gr)o(am)h(Specialization)1582
b Fr(15)p 0 406 3900 8 v 0 688 a Fq(Marshaling)23 b(lay)o(er)g
(optimizations.)81 b Fr(Clark)23 b(and)g(T)-6 b(ennenhouse)20
b([6)o(])j(were)g(the)g(\002rst)h(to)f(identify)f(the)h(presentation)e
(layer)i(as)h(an)0 788 y(important)19 b(bottleneck)f(in)j(protocol)d
(softw)o(are.)25 b(The)o(y)19 b(attrib)n(ute)h(it)h(to)g(up)f(to)g
(97\045)g(of)g(the)g(total)h(protocol)d(stack)j(o)o(v)o(erhead,)c(in)k
(some)0 888 y(practical)28 b(applications.)47 b(Rather)29
b(than)e(optimizing)g(an)h(e)o(xisting)g(implementation,)f(the)o(y)h
(propose)f(some)h(design)f(principles)g(to)0 987 y(b)n(uild)20
b(ne)n(w)g(ef)n(\002cient)g(implementations.)125 1158
y(Hoschka)28 b(and)g(Huitema)g([15)o(])h(con)m(v)o(ert)e(marshaling)h
(code)g(from)g(a)h(table-dri)n(v)o(en)d(implementation)h(to)i(a)h
(procedure-dri)n(v)o(en)0 1258 y(implementation.)c(In)21
b(the)g(table-dri)n(v)o(en)d(implementation,)h(a)j(generic)e
(interpreter)g(selects)i(among)d(se)n(v)o(eral)i(elementary)f(decoding)
0 1358 y(procedures,)k(or)o(ganized)d(as)26 b(a)f(function)e(table.)39
b(The)25 b(procedure-dri)n(v)o(en)19 b(implementation)k(is)j(a)f
(straight)f(sequence)g(of)h(code)f(spe-)0 1457 y(cialized)g(for)g(a)h
(gi)n(v)o(en)e(compound)e(type.)37 b(Their)24 b(transformation)e(does)i
(not)g(include)f(comple)o(x)g(optimizations.)36 b(Rather)m(,)25
b(the)o(y)f(are)0 1557 y(interested)c(in)g(the)g(time)g
Fp(vs.)26 b Fr(space)20 b(tradeof)n(f)f(between)g(the)h(tw)o(o)h
(implementations.)125 1728 y(O'Malle)o(y)f Fp(et)h(al.)28
b Fr([26)o(])21 b(present)g(a)g(uni)n(v)o(ersal)f(stub)h(compiler)m(,)e
(called)i(USC.)h(As)g(opposed)d(to)j(XDR,)f(which)g(con)m(v)o(erts)e
(between)0 1828 y(a)j(\002x)o(ed)g(host)f(format)g(and)g(another)g
(\002x)o(ed)g(e)o(xternal)g(representation,)f(USC)j(con)m(v)o(erts)d
(data)i(between)f(tw)o(o)h(user)n(-speci\002ed)f(formats.)0
1927 y(USC)j(inte)o(grates)e(se)n(v)o(eral)g(domain-speci\002c)e
(optimizations,)i(resulting)g(in)h(much)e(f)o(aster)i(code)f(than)h
(the)f(one)g(produced)f(by)h(XDR.)0 2027 y(Ho)n(we)n(v)o(er)m(,)d(in)h
(order)g(to)g(perform)f(these)i(aggressi)n(v)o(e)e(optimizations,)g
(USC)j(imposes)e(some)g(restrictions)h(o)o(v)o(er)e(the)h(marshaled)g
(data)0 2126 y(types:)42 b(types)29 b(such)g(as)g(\003oating)f(point)g
(numbers)g(or)g(pointers)g(are)h(not)f(allo)n(wed.)50
b(In)29 b(f)o(act,)i(USC)f(is)f(not)g(designed)e(for)i(general)0
2226 y(ar)o(gument)18 b(marshaling,)g(b)n(ut)i(rather)g(for)f(header)g
(con)m(v)o(ersions)f(and)i(interf)o(acing)e(to)j(memory-mapped)16
b(de)n(vices.)125 2397 y(Blackwell)23 b([4)o(])h(manages)e(e)o(xternal)
g(data)h(formats)g(which)f(allo)n(w)i(v)n(ariable)e(encoding,)g(such)h
(as)h(Q.93B)f([13)n(])h(or)f(ASN.1)g([16)o(].)0 2497
y(In)f(these)h(representations,)e(each)h(data)g(\002eld)h(is)g(tagged)e
(to)i(indicate)f(its)h(actual)f(format,)g(chosen)g(between)f(se)n(v)o
(eral)h(possible)g(ones.)0 2596 y(Blackwell)d(b)n(uilds)f(a)h
(special-purpose)e(on-line)g(compiler)m(,)g(which)h(generates)g
(specialized)g(marshaling)f(code)h(for)g(the)h(formats)e(that)0
2696 y(are)27 b(encountered)d(frequently)h(at)i(run)f(time.)46
b(The)26 b(optimizations)g(inte)o(grated)f(in)i(this)h(compiler)d
(aggressi)n(v)o(ely)g(e)o(xploit)h(domain-)0 2796 y(speci\002c)j
(information,)e(such)i(as)g(the)f(absence)g(of)g(aliases,)j(the)d
(ability)h(to)f(reorder)f(cop)o(y)g(operations)g(of)h(distinct)h
(\002elds,)h(or)f(the)0 2895 y(alignment)19 b(properties)g(which)g(mak)
o(e)h(it)h(possible)f(to)g(collapse)g(se)n(v)o(eral)g(adjacent)f
(\002elds)i(into)f(a)g(single)g(w)o(ord.)125 3066 y(All)h(these)f
(studies)h(require)e(one)h(to)h(b)n(uild)f(a)h(special-purpose)d(code)i
(generator)m(,)e(with)i(a)h(comple)o(xity)e(ranging)f(from)i(an)g
(ad-hoc)0 3166 y(template)27 b(assembler)h(to)f(a)i(full,)g
(domain-speci\002c,)e(optimizing)f(compiler)-5 b(.)47
b(In)28 b(contrast,)h(we)f(tak)o(e)f(the)h(stubs)g(generated)e(by)i(an)
0 3266 y(e)o(xisting)19 b(stub)i(compiler)m(,)d(and)i(deri)n(v)o(e)e
(the)j(specialized)e(stubs)i(with)f(T)-6 b(empo,)19 b(a)i(general)e
(program)f(specialization)h(tool.)0 3558 y Fq(K)n(er)o(nel-le)o(v)o(el)
j(optimizations.)82 b Fr(It)23 b(is)i(well)f(recognized)d(that)j
(physical)e(memory)g(cop)o(y)g(is)j(an)e(important)f(cause)h(of)h(o)o
(v)o(erhead)c(in)0 3658 y(protocol)27 b(implementation.)48
b(Finding)28 b(solutions)g(to)h(a)n(v)n(oid)f(or)g(optimize)g(copies)h
(is)g(a)g(constant)f(concern)f(of)i(operating)d(system)0
3757 y(designers.)f(F)o(or)c(instance,)f(cop)o(y-on-write)d([12)o(])k
(w)o(as)g(the)g(technique)e(which)h(made)g(message)h(passing)f(ef)n
(\002cient)g(enough)f(to)i(allo)n(w)0 3857 y(operating)j(systems)j(to)g
(be)f(designed)f(based)h(on)g(a)g(micro-k)o(ernel)e(architecture)h([30)
o(,)h(31)o(].)44 b(Buf)n(fers)25 b(are)i(needed)e(when)g(dif)n(ferent)0
3957 y(modules)20 b(or)i(layers)f(written)g(independently)e(for)h
(modularity)g(reasons)h(ha)n(v)o(e)g(to)g(cooperate)f(together)g(at)i
(run)f(time.)29 b(This)21 b(cause)h(of)0 4056 y(o)o(v)o(erhead)16
b(has)j(been)f(clearly)g(demonstrated)f(by)h(Thekkath)f(and)h(Le)n(vy)g
(in)h(their)f(performance)e(analysis)j(of)f(RPC)j(implementations)0
4156 y([36)o(].)k(Recent)19 b(proposals)g(in)h(the)f(netw)o(orking)f
(area)h(e)o(xplore)f(solutions)h(to)h(impro)o(v)o(e)e(netw)o(ork)g
(throughput)f(and)i(to)h(reduce)e(latenc)o(y)-5 b(.)0
4256 y(Madea)17 b(and)f(Bershad)h(propose)f(to)i(restructure)d(netw)o
(ork)h(layers)i(and)e(to)i(mo)o(v)o(e)e(some)h(functions)f(into)h(user)
g(space)g([20)o(].)24 b(Mosber)o(ger)0 4355 y Fp(et)c(al.)k
Fr(describe)19 b(techniques)e(for)i(impro)o(ving)d(protocols)i(by)g
(reducing)g(the)h(number)e(of)i(c)o(ycles)g(stalled)g(to)g(w)o(ait)h
(for)f(memory)e(access)0 4455 y(completion)h([24)o(].)0
4747 y Fq(Manual)f(specialization.)82 b Fr(In)16 b(a)h(\002rst)h(step,)
f(operating)e(systems)i(specialization)f(has)h(been)f(performed)e
(manually)i(in)g(e)o(xperiments)0 4847 y(such)26 b(as)h(Synthesis)e
([28)o(,)h(21)o(],)i(and)d(Synthetix)g([27)o(].)43 b(Manual)25
b(specialization,)h(ho)n(we)n(v)o(er)m(,)f(tends)h(to)g(compromise)e
(other)h(system)0 4947 y(properties)f(such)i(as)h(maintainability)d
(and)h(portability)-5 b(.)41 b(Furthermore,)24 b(manual)h
(specialization)g(is)i(typically)e(uniquely)f(tailored)0
5046 y(to)g(each)f(situation)h(and)f(therefore)f(requires)g(a)j(high)e
(de)o(gree)f(of)h(programmer)e(skill)j(and)g(system)g(kno)n(wledge.)33
b(While)24 b(tool-based)0 5146 y(specialization)j(may)g(not)g(\002t)i
(the)e(traditional)g(k)o(ernel)f(de)n(v)o(elopment)f(process,)k(we)f
(see)g(it)h(as)f(a)g(natural)f(ne)o(xt)g(step)g(for)g(operating)0
5246 y(system)20 b(de)n(v)o(elopment)e(the)i(same)g(w)o(ay)h(compilers)
e(became)g(useful)h(programming)c(technology)i(decades)i(ago.)0
5731 y Fm(PI)d(n)c(\011)g(1094)p eop
%%Page: 16 18
16 17 bop 0 352 a Fr(16)507 b Fp(Gilles)21 b(Muller)-9
b(,)20 b(Renaud)e(Marlet,)j(Eug)o(en-Nicolae)d(V)-9 b(olansc)o(hi,)18
b(Charles)j(Consel,)f(Calton)g(Pu)g(&)g(Ashvin)g(Goel)p
0 406 3900 8 v 125 688 a Fr(Recently)-5 b(,)20 b(a)i(semi-automatic)e
(approach)f(to)i(program)f(transformation)e(has)k(been)e(de)n(v)o
(eloped;)g(it)i(e)o(xtends)e(the)i(C)g(language)d(to)0
788 y(include)i(syntactic)g(constructs)g(aimed)g(at)h(b)n(uilding)e
(code)h(at)h(run)f(time[9)o(].)29 b(It)22 b(has)f(been)g(used)h(for)f
(a)h(realistic)g(system)f(application,)0 888 y(namely)g(the)i(pack)o
(et)f(\002lter)h([10)n(].)32 b(This)23 b(w)o(ork)f(demonstrates)f(that)
i(e)o(xploiting)d(in)m(v)n(ariants)h(can)h(produce)f(signi\002cant)h
(speedups)f(for)0 987 y(demultiple)o(xing)d(messages.)27
b(This)21 b(result)g(has)g(been)f(obtained)g(at)h(the)g(cost)g(of)g
(manually)e(re)n(writing)h(a)h(ne)n(w)g(algorithm)e(that)i(adapts)0
1087 y(to)f(the)h(speci\002c)f(usage)g(conte)o(xt.)0
1379 y Fq(A)l(utomatic)15 b(pr)o(ogram)g(transf)n(ormation.)81
b Fr(Program)15 b(transformation)f(has)i(been)g(used)g(successfully)g
(for)g(specializing)f(programs)0 1479 y(in)k(domains)f(such)g(as)i
(computer)d(graphics)g([19)o(].)25 b(The)18 b(k)o(e)o(y)g(point)h(of)f
(program)f(transformation)f(is)k(that)f(it)g(preserv)o(es)f(the)h
(semantics)0 1579 y(of)i(the)g(program.)k(Therefore,)18
b(if)j(the)g(transformation)e(process)h(can)h(be)g(automated,)e(the)i
(\002nal)g(code)f(has)i(the)e(same)i(le)n(v)o(el)e(of)h(safety)0
1678 y(than)j(the)g(initial)g(program.)34 b(T)-6 b(empo)23
b(relies)h(on)g(partial)g(e)n(v)n(aluation)e([7)o(,)i(18)o(],)h(a)g
(form)e(of)g(program)f(transformation)g(which)h(is)i(no)n(w)0
1778 y(reaching)f(a)i(le)n(v)o(el)f(of)g(maturity)f(that)i(mak)o(es)f
(it)h(possible)f(to)h(de)n(v)o(elop)d(specializers)j(for)e(real-sized)h
(languages)f(lik)o(e)i(C)g([8)o(,)g(1)o(])g(and)0 1877
y(apply)19 b(these)i(specializers)f(to)g(real-sized)f(problems.)125
2049 y Fp(C-Mix)g Fr(is)g(the)g(only)f(other)f(partial)i(e)n(v)n
(aluator)e(for)h(C)h(reported)e(in)i(the)f(literature.)24
b(Unfortunately)-5 b(,)15 b(the)k(accurac)o(y)e(of)h(its)i(analyses)0
2148 y(does)g(not)g(allo)n(w)g(it)h(to)f(deal)g(with)h
(partially-static)e(structures)h(and)f(pointers)g(to)i(these)f(objects)
g(interprocedurally)d([2)o(].)0 2441 y Fq(Extensible)26
b(operating)e(systems.)83 b Fr(Safety)24 b(is)i(a)g(well-kno)n(wn)d
(problem)h(encountered)e(in)j(e)o(xtensible)g(operating)e(system)i
(when)0 2540 y(an)e(e)o(xtension)e(code)h(has)h(to)g(be)g(do)n
(wn-loaded)d(directly)i(into)g(the)h(k)o(ernel.)32 b(Recent)23
b(e)o(xtensible)f(operating)f(systems)i(such)g(as)g(SPIN)0
2640 y(and)e(Ae)o(gis)h(ha)n(v)o(e)f(been)f(designed)h(with)g(safety)h
(as)g(a)g(goal.)29 b(In)21 b(SPIN)h([3)o(],)g(e)o(xtensions)e(are)i
(written)f(in)h(a)g(strongly-typed)c(language)0 2740
y(\(MODULA-3\),)33 b(which)e(pre)n(v)o(ents)f(possible)i(in)m(v)n(alid)
e(memory)g(references.)59 b(Ae)o(gis)31 b([11)o(])h(relies)g(mostly)g
(on)f(system)h(libraries)0 2839 y(e)o(x)o(ecuted)f(at)i(application)d
(le)n(v)o(el.)62 b(Still,)36 b(it)d(uses)g(Application-speci\002c)e
(Safe)h(Handlers)g(\(ASH\))g(e)o(x)o(ecuted)f(at)i(k)o(ernel)e(le)n(v)o
(el)h(in)0 2939 y(speci\002c)20 b(cases.)26 b(The)20
b(safety)g(of)g(ASHs)h(is)g(ensured)e(by)h(the)h(use)f(of)g(the)g
Fp(softwar)m(e)h(fault)f(isolation)f Fr(technique)g([37)o(],)h(which)g
(re)n(writes)0 3039 y(the)g(binary)f(code)h(to)g(insert)g(softw)o
(are-based)f(memory)f(protection)g(instructions.)125
3210 y(The)g(e)o(xtensible)f(nature)g(of)h(these)h(operating)d(systems)
j(suggests)g(that)f(a)h(partial)f(e)n(v)n(aluator)e(could)i(be)g(a)h
(useful)f(tool)g(to)g(optimize)0 3309 y(the)i(generic)f(components)f
(to)j(be)f(do)n(wn-loaded)d(into)j(the)g(k)o(ernel.)0
3661 y Ft(8)119 b(Conclusion)0 3918 y Fr(W)-7 b(e)20
b(ha)n(v)o(e)d(described)h(the)g(specialization)f(of)i(Sun)f(RPC)i
(using)e(the)g(T)-6 b(empo)17 b(partial)h(e)n(v)n(aluator)-5
b(.)24 b(This)18 b(is)h(the)g(\002rst)g(successful)f(partial-)0
4018 y(e)n(v)n(aluation)f(based)h(specialization)g(of)g(a)h
(signi\002cant)g(OS)g(component.)j(The)c(e)o(xperiment)f(consists)i(of)
f(declaring)f(the)i(kno)n(wn)e(inputs)0 4117 y(of)28
b(the)f(Sun)h(RPC)h(code)e(and)h(allo)n(wing)f(T)-6 b(empo)26
b(to)i(automatically)f(e)n(v)n(aluate)f(the)i(static)h(parts)f(of)f
(code)g(at)i(specialization)e(time.)0 4217 y(Examples)19
b(of)h(kno)n(wn)f(information)f(include)h(the)h(number)e(and)i(type)g
(of)g(RPC)h(parameters.)125 4388 y(There)j(are)i(three)f(reasons)g(why)
g(partial-e)n(v)n(aluation)e(based)i(specialization)g(is)i(a)f
(signi\002cant)f(inno)o(v)n(ation,)f(in)i(comparison)d(to)0
4488 y(manual)k(specialization)g([27)o(,)h(23)o(,)h(11)o(].)49
b(First,)30 b(T)-6 b(empo)27 b(preserv)o(es)g(the)i(source)e(code)g(at)
i(the)f(programming)d(le)n(v)o(el,)k(thus)f(preser)n(-)0
4587 y(ving)g(the)g(safety)g(and)g(maintainability)f(of)h(a)h(mature)f
(commercial)f(code.)49 b(Second,)29 b(T)-6 b(empo)28
b(achie)n(v)o(es)f(speedup)g(up)h(to)h(3.75)e(in)0 4687
y(micro-benchmarks,)17 b(and)k(1.5)g(in)g(test)h(programs.)27
b(Close)22 b(inspection)e(of)h(the)g(specialized)g(Sun)g(RPC)i(did)e
(not)f(re)n(v)o(eal)h(ob)o(vious)e(op-)0 4786 y(portunities)g(for)g
(further)f(signi\002cant)h(impro)o(v)o(ements)e(without)i(major)h(code)
f(restructuring.)j(Third,)d(the)h(successful)f(specialization)0
4886 y(of)h(commercial)f(code)g(is)i(automatic)e(and)h(sho)n(ws)g(the)h
(promise)e(of)h(industrial)f(application)g(of)h(T)-6
b(empo.)125 5057 y(W)f(e)17 b(carried)e(out)g(e)o(xperiments)f(on)i(tw)
o(o)g(v)o(ery)f(dif)n(ferent)f(platforms,)i(namely)f(Sun)g(4/50)h(w)o
(orkstations)f(running)e(SunOS)j(connec-)0 5157 y(ted)i(with)g(a)h(100)
12 b(Mbits/s)19 b(A)-9 b(TM)18 b(link,)f(and)h(166)12
b(MHz)18 b(Pentium)g(machines)f(running)f(Linux,)h(connected)f(to)i(a)h
(100)12 b(Mbits/s)19 b(Ethernet)3782 5731 y Fm(Irisa)p
eop
%%Page: 17 19
17 18 bop 0 352 a Fp(F)-6 b(ast,)20 b(Optimized)g(Sun)f(RPC)i(Using)f
(A)n(utomatic)f(Pr)l(o)o(gr)o(am)h(Specialization)1582
b Fr(17)p 0 406 3900 8 v 0 688 a(netw)o(ork.)31 b(The)23
b(dif)n(ferences)e(of)h(these)h(platforms)f(and)g(the)h(consistenc)o(y)
e(of)i(performance)c(gains)k(sho)n(w)f(a)h(rob)n(ust)f(applicability)g
(of)0 788 y(T)-6 b(empo)19 b(as)i(a)g(tool)f(for)f(partial-e)n(v)n
(aluation)e(based)j(specialization)f(of)h(layered)f(operating)g
(systems)h(code)g(such)g(as)h(Sun)f(RPC.)0 1140 y Ft(Refer)n(ences)42
1358 y Fr([1])40 b(L.O.)21 b(Andersen.)31 b(Self-applicable)20
b(C)i(program)e(specialization.)31 b(In)22 b Fp(P)-7
b(artial)21 b(Evaluation)e(and)i(Semantics-Based)e(Pr)l(o)o(gr)o(am)180
1458 y(Manipulation)p Fr(,)e(pages)h(54\22661,)g(San)h(Francisco,)f
(CA,)i(USA,)g(June)e(1992.)g(Y)-8 b(ale)19 b(Uni)n(v)o(ersity)-5
b(,)18 b(He)n(w)h(Ha)n(v)o(en,)f(CT)-6 b(,)20 b(USA.)27
b(T)-6 b(ech-)180 1558 y(nical)20 b(Report)g(Y)-10 b(ALEU/DCS/RR-909.)
42 1724 y([2])40 b(L.O.)21 b(Andersen.)30 b Fp(Pr)l(o)o(gr)o(am)21
b(Analysis)g(and)f(Specialization)f(for)j(the)f(C)h(Pr)l(o)o(gr)o
(amming)e(Langua)o(g)o(e)p Fr(.)30 b(PhD)21 b(thesis,)h(Computer)180
1823 y(Science)e(Department,)e(Uni)n(v)o(ersity)h(of)h(Copenhagen,)e
(May)i(1994.)27 b(DIKU)20 b(T)-6 b(echnical)20 b(Report)g(94/19.)42
1989 y([3])40 b(B.N.)26 b(Bershad,)g(S.)f(Sa)n(v)n(age,)h(P)-9
b(.)26 b(P)o(ardyak,)f(E.)g(G)7 b(\250)-35 b(un)25 b(Sirer)m(,)h(M.E.)f
(Fiuczynski,)g(D.)h(Beck)o(er)m(,)g(C.)g(Chambers,)f(and)g(S.)h
(Eggers.)180 2089 y(Extensibility)-5 b(,)18 b(safety)i(and)g
(performance)d(in)k(the)f(SPIN)g(operating)f(system.)29
b(In)20 b(SOSP95)g([35)o(],)g(pages)g(267\226283.)42
2255 y([4])40 b(T)-6 b(.)29 b(Blackwell.)60 b(F)o(ast)31
b(decoding)d(of)h(tagged)g(message)g(formats.)59 b(In)30
b Fp(F)l(ifteenth)f(Annual)f(J)n(oint)i(Confer)m(ence)e(of)i(the)g
(IEEE)180 2355 y(Computer)20 b(and)f(Communication)f(Societies)p
Fr(,)i(San)g(Francisco,)f(CA,)i(March)f(1996.)42 2521
y([5])40 b(G.)30 b(Cabillic)h(and)e(I.)h(Puaut.)61 b(Stardust:)45
b(an)30 b(en)m(vironment)d(for)i(parallel)h(programming)d(on)i(netw)o
(orks)h(of)f(heterogeneous)180 2620 y(w)o(orkstations.)f
Fp(J)n(ournal)19 b(of)h(P)-7 b(ar)o(allel)20 b(and)g(Distrib)n(uted)g
(Computing)p Fr(,)e(February)h(1997.)42 2786 y([6])40
b(D.D.)17 b(Clark)g(and)f(D.L.)h(T)-6 b(ennenhouse.)19
b(Architectural)d(considerations)f(for)h(a)i(ne)n(w)e(generation)f(of)i
(protocols.)k(In)16 b Fp(SIGCOMM)180 2886 y(Symposium)g(on)g
(Communications)f(Ar)m(c)o(hitectur)m(es)i(and)f(Pr)l(otocols)p
Fr(,)h(pages)f(200\226208,)f(Philadelphia,)h(P)-8 b(A,)18
b(September)d(1990.)180 2986 y(A)m(CM)20 b(Press.)42
3152 y([7])40 b(C.)27 b(Consel)f(and)f(O.)i(Dan)m(vy)-5
b(.)46 b(T)l(utorial)25 b(notes)h(on)g(partial)f(e)n(v)n(aluation.)46
b(In)26 b Fp(Confer)m(ence)g(Recor)m(d)f(of)h(the)g(T)-6
b(wentieth)26 b(Annual)180 3251 y(A)n(CM)j(SIGPLAN-SIGA)n(CT)e
(Symposium)h(on)g(Principles)h(Of)g(Pr)l(o)o(gr)o(amming)f(Langua)o(g)o
(es)p Fr(,)h(pages)g(493\226501,)f(Charleston,)180 3351
y(SC,)21 b(USA,)f(January)f(1993.)g(A)m(CM)h(Press.)42
3517 y([8])40 b(C.)21 b(Consel,)g(L.)f(Hornof,)f(F)-7
b(.)21 b(No)5 b(\250)-33 b(el,)21 b(J.)g(No)o(y)5 b(\264)-33
b(e,)20 b(and)g(E.N.)g(V)-11 b(olanschi.)30 b(A)21 b(uniform)e
(approach)f(for)i(compile-time)f(and)h(run-time)180 3617
y(specialization.)59 b(In)30 b(O.)g(Dan)m(vy)-5 b(,)30
b(R.)g(Gl)7 b(\250)-35 b(uck,)32 b(and)d(P)-9 b(.)30
b(Thiemann,)h(editors,)g Fp(P)-7 b(artial)30 b(Evaluation,)g
(International)e(Seminar)-9 b(,)180 3716 y(Da)o(gstuhl)19
b(Castle)p Fr(,)i(number)d(1110)h(in)h(Lecture)g(Notes)g(in)h(Computer)
d(Science,)i(pages)g(54\22672,)e(February)g(1996.)42
3882 y([9])40 b(D.R.)17 b(Engler)m(,)f(W)-8 b(.C.)19
b(Hsieh,)e(and)g(M.F)-7 b(.)18 b(Kaashoek.)j Fk(`)p Fr(C:)d(A)f
(language)f(for)g(high-le)n(v)o(el,)g(ef)n(\002cient,)h(and)f
(machine-independent)180 3982 y(dynamic)26 b(code)g(generation.)50
b(In)27 b Fp(Confer)m(ence)g(Recor)m(d)g(of)g(the)h Fa(23)2178
3952 y Fd(r)r(d)2276 3982 y Fp(Annual)e(A)n(CM)h(SIGPLAN-SIGA)n(CT)f
(Symposium)g(on)180 4081 y(Principles)f(Of)i(Pr)l(o)o(gr)o(amming)d
(Langua)o(g)o(es)p Fr(,)h(pages)h(131\226144,)e(St.)i(Petersb)n(ur)o(g)
e(Beach,)j(FL,)f(USA,)h(January)d(1996.)g(A)m(CM)180
4181 y(Press.)0 4347 y([10])40 b(D.R.)19 b(Engler)f(and)h(M.F)-7
b(.)20 b(Kaashoek.)25 b(DPF:)c(F)o(ast,)e(\003e)o(xible)g(message)g
(demultiple)o(xing)d(using)j(dynamic)e(code)i(generation.)25
b(In)180 4447 y(SIGCOMM96)19 b([33)o(].)0 4613 y([11])40
b(D.R.)25 b(Engler)m(,)g(M.F)-7 b(.)26 b(Kaashoek,)f(and)g(J.W)-8
b(.)26 b(O'T)-7 b(oole.)44 b(Exok)o(ernel:)33 b(An)26
b(operating)d(system)i(architecture)f(for)g(application-)180
4712 y(le)n(v)o(el)c(resource)f(management.)26 b(In)20
b(SOSP95)h([35)n(],)f(pages)g(251\226266.)0 4879 y([12])40
b(R.)21 b(Fitzgerald)f(and)g(R.F)-7 b(.)22 b(Rashid.)31
b(The)21 b(inte)o(gration)e(of)h(virtual)g(memory)f(management)g(and)h
(interprocess)f(communication)180 4978 y(in)h(Accent.)29
b Fp(A)n(CM)20 b(T)-5 b(r)o(ansactions)20 b(on)g(Computer)g(Systems)p
Fr(,)g(4\(2\):147\226177,)15 b(May)20 b(1986.)0 5144
y([13])40 b(A)-9 b(TM)20 b(F)o(orum.)28 b(A)-9 b(TM)20
b(user)n(-netw)o(ork)e(interf)o(ace)h(speci\002cation)h(v)o(ersion)f
(3.0,)g(1993.)0 5731 y Fm(PI)e(n)c(\011)g(1094)p eop
%%Page: 18 20
18 19 bop 0 352 a Fr(18)507 b Fp(Gilles)21 b(Muller)-9
b(,)20 b(Renaud)e(Marlet,)j(Eug)o(en-Nicolae)d(V)-9 b(olansc)o(hi,)18
b(Charles)j(Consel,)f(Calton)g(Pu)g(&)g(Ashvin)g(Goel)p
0 406 3900 8 v 0 688 a Fr([14])40 b(A.)25 b(Geist,)i(A.)e(Be)o(guelin,)
g(J.)h(Dongarra,)d(W)-8 b(.)26 b(Jiang,)g(R.)g(Manchek,)e(and)h(V)-11
b(.)25 b(Sunde.)44 b Fp(PVM:)25 b(P)-7 b(ar)o(allel)25
b(V)-6 b(irtual)24 b(Mac)o(hine)g(-)h(A)180 788 y(User)o(s')c(Guide)f
(and)f(T)-5 b(utorial)20 b(for)h(Network)o(ed)g(P)-7
b(ar)o(allel)20 b(Computing)o(.)27 b Fr(MIT)20 b(Press,)h(1994.)0
954 y([15])40 b(P)-9 b(.)17 b(Hoschka)g(and)f(C.)i(Huitema.)23
b(Control)16 b(\003o)n(w)h(graph)f(analysis)i(for)e(automatic)g(f)o
(ast)i(path)f(implementation.)k(In)c Fp(Second)e(IEEE)180
1054 y(workshop)29 b(on)g(the)h(ar)m(c)o(hitectur)m(e)e(and)h
(Implementation)e(of)j(high)f(performance)f(communication)f(subsystems)
p Fr(,)33 b(W)m(illiam-)180 1153 y(sb)n(ur)o(g,)19 b(V)-11
b(A,)20 b(September)f(1993.)0 1319 y([16])40 b(ISO.)29
b(Speci\002cation)20 b(of)f(abstract)h(syntax)g(notation)f(one)g
(\(ASN.1\).)29 b(ISO)20 b(standard)f(8824,)g(1988.)0
1485 y([17])40 b(D.B.)31 b(Johnson)e(and)i(W)-8 b(.)31
b(Zw)o(aenepoel.)62 b(The)30 b(Pere)o(grine)f(high-performance)d(RPC)33
b(system.)63 b Fp(Softwar)m(e)30 b(-)h(Pr)o(actice)f(And)180
1585 y(Experience)p Fr(,)19 b(23\(2\):201\226221,)c(February)j(1993.)0
1751 y([18])40 b(N.D.)25 b(Jones,)i(C.)f(Gomard,)f(and)g(P)-9
b(.)26 b(Sestoft.)46 b Fp(P)-7 b(artial)26 b(Evaluation)d(and)i(A)n
(utomatic)f(Pr)l(o)o(gr)o(am)h(Gener)o(ation)p Fr(.)45
b(International)180 1851 y(Series)20 b(in)h(Computer)e(Science.)g
(Prentice-Hall,)h(June)f(1993.)0 2017 y([19])40 b(B.N.)16
b(Locanthi.)h(F)o(ast)f(bitblt\(\))f(with)g(asm\(\))g(and)g(cpp.)k(In)c
Fp(Eur)l(opean)e(UNIX)j(Systems)g(User)g(Gr)l(oup)f(Confer)m(ence)g(Pr)
l(oceedings)p Fr(,)180 2116 y(pages)20 b(243\226259,)d(A)-9
b(T&T)19 b(Bell)i(Laboratories,)d(Murray)h(Hill,)i(September)e(1987.)f
(EUUG.)0 2282 y([20])40 b(C.)27 b(Maeda)g(and)f(B.N.)h(Bershad.)50
b(Protocol)25 b(service)i(decomposition)d(for)i(high-performance)c
(netw)o(orking.)48 b(In)27 b(SOSP'93)180 2382 y([34)n(],)21
b(pages)e(244\226255.)0 2548 y([21])40 b(H.)21 b(Massalin)h(and)e(C.)i
(Pu.)33 b(Threads)20 b(and)g(input/output)f(in)i(the)h(Synthesis)f(k)o
(ernel.)31 b(In)21 b Fp(Pr)l(oceedings)f(of)h(the)g(T)-6
b(welfth)22 b(Sympo-)180 2648 y(sium)e(on)g(Oper)o(ating)f(Systems)i
(Principles)p Fr(,)e(pages)h(191\226201,)d(Arizona,)i(December)g(1989.)
0 2814 y([22])40 b(Sun)20 b(Microsystem.)28 b(NFS:)21
b(Netw)o(ork)e(\002le)i(system)f(protocol)f(speci\002cation.)28
b(RFC)21 b(1094,)e(Sun)h(Microsystem,)f(March)g(1989.)0
2980 y([23])40 b(A.B.)35 b(Montz,)i(D.)d(Mosber)o(ger)m(,)h(S.W)-8
b(.)35 b(O'Malle)o(y)-5 b(,)37 b(L.L.)d(Peterson,)j(T)-6
b(.A.)34 b(Proebsting,)i(and)e(J.H.)g(Hartman.)74 b(Scout:)53
b(A)180 3079 y(communications-oriented)24 b(operating)j(system.)58
b(T)-6 b(echnical)28 b(Report)h(94\22620,)g(Department)f(of)g(Computer)
g(Science,)j(The)180 3179 y(Uni)n(v)o(ersity)19 b(of)h(Arizona,)f
(1994.)0 3345 y([24])40 b(D.)29 b(Mosber)o(ger)m(,)g(L.L.)f(Peterson,)j
(P)-9 b(.G.)29 b(Bridges,)i(and)e(S.W)-8 b(.)30 b(O'Malle)o(y)-5
b(.)56 b(Analysis)29 b(of)g(techniques)f(to)h(impro)o(v)o(e)e(protocol)
180 3445 y(processing)19 b(latenc)o(y)-5 b(.)27 b(In)20
b(SIGCOMM96)g([33)n(].)0 3611 y([25])40 b(D.)22 b(Mosber)o(ger)m(,)e
(L.L.)i(Peterson,)g(and)f(S.W)-8 b(.)23 b(O'Malle)o(y)-5
b(.)34 b(Protocol)22 b(latenc)o(y:)28 b(MIPS)22 b(and)g(reality)-5
b(.)35 b(T)-6 b(echnical)21 b(Report)h(95-02,)180 3710
y(Department)d(of)g(Computer)g(Science,)h(The)g(Uni)n(v)o(ersity)f(of)h
(Arizona,)f(1995.)0 3876 y([26])40 b(S.)30 b(O'Malle)o(y)-5
b(,)32 b(T)-6 b(.)30 b(Proebsting,)h(and)e(A.B.)i(Montz.)60
b(USC:)32 b(A)e(uni)n(v)o(ersal)f(stub)h(compiler)-5
b(.)60 b(T)-6 b(echnical)30 b(Report)f(TR94-10,)180 3976
y(Uni)n(v)o(ersity)20 b(of)h(Arizona,)f(Department)f(of)i(Computer)f
(Science,)h(1994.)31 b(Also)21 b(in)g(Proc.)g(Conf.)f(on)h
(Communications)e(Archi.)180 4076 y(Protocols)g(and)h(Applications.)0
4242 y([27])40 b(C.)24 b(Pu,)f(T)-6 b(.)23 b(Autre)o(y)-5
b(,)22 b(A.)i(Black,)f(C.)h(Consel,)g(C.)g(Co)n(w)o(an,)f(J.)h(Inouye,)
d(L.)j(K)n(ethana,)e(J.)i(W)-7 b(alpole,)24 b(and)e(K.)h(Zhang.)37
b(Optimistic)180 4341 y(incremental)19 b(specialization:)24
b(Streamlining)19 b(a)h(commercial)f(operating)f(system.)30
b(In)19 b(SOSP95)i([35)n(],)f(pages)g(314\226324.)0 4507
y([28])40 b(C.)21 b(Pu,)f(H.)g(Massalin,)h(and)e(J.)i(Ioannidis.)28
b(The)20 b(Synthesis)g(k)o(ernel.)28 b Fp(Computing)19
b(Systems)p Fr(,)h(1\(1\):11\22632,)d(W)m(inter)j(1988.)0
4673 y([29])40 b(R.)21 b(Ramse)o(y)-5 b(.)28 b Fp(All)21
b(about)e(administering)g(NIS+)p Fr(.)29 b(SunSoft,)19
b(1993.)0 4839 y([30])40 b(R.F)-7 b(.)32 b(Rashid,)i(A.)e(T)-6
b(e)n(v)n(anian)30 b(Jr)-5 b(.,)34 b(M.W)-8 b(.)32 b(Y)-9
b(oung,)32 b(D.B.)g(Golub,)h(R.V)-11 b(.)32 b(Baron,)h(D.)f(Black,)i
(Bolosk)o(y)c(W)-8 b(.J.,)35 b(and)c(J.)h(Che)n(w)-5
b(.)180 4939 y(Machine-independent)28 b(virtual)k(memory)g(management)e
(for)i(paged)g(uniprocessor)f(and)h(multiprocessor)f(architectures.)180
5039 y Fp(IEEE)19 b(T)-5 b(r)o(ansactions)20 b(on)g(Computer)o(s)p
Fr(,)g(37\(8\):896\226908,)15 b(August)k(1988.)3782 5731
y Fm(Irisa)p eop
%%Page: 19 21
19 20 bop 0 352 a Fp(F)-6 b(ast,)20 b(Optimized)g(Sun)f(RPC)i(Using)f
(A)n(utomatic)f(Pr)l(o)o(gr)o(am)h(Specialization)1582
b Fr(19)p 0 406 3900 8 v 0 688 a([31])40 b(V)-11 b(.)24
b(Rozier)m(,)h(V)-11 b(.)24 b(Abrossimo)o(v)-5 b(,)23
b(F)-7 b(.)24 b(Armand,)g(I.)g(Boule,)g(M.)g(Gien,)h(M.)f(Guillemont,)f
(F)-7 b(.)25 b(Herrmann,)e(C.)i(Kaiser)m(,)f(S.)h(Langlois,)180
788 y(P)-9 b(.)25 b(L)5 b(\264)-33 b(eonard,)24 b(and)g(W)-8
b(.)25 b(Neuhauser)-5 b(.)43 b(Ov)o(ervie)n(w)23 b(of)i(the)f(Chorus)g
(distrib)n(uted)g(operating)f(system.)44 b(In)24 b Fp(USENIX)g(-)h(W)-8
b(orkshop)180 888 y(Pr)l(oceedings)19 b(-)h(Micr)l(o-k)o(ernels)h(and)e
(Other)i(K)m(ernel)f(Ar)m(c)o(hitectur)m(es)p Fr(,)g(pages)g(39\22670,)
e(Seattle,)i(W)-10 b(A,)21 b(USA,)g(April)f(1992.)0 1054
y([32])40 b(M.D.)16 b(Schroeder)f(and)h(M.)h(Burro)n(ws.)k(Performance)
15 b(of)h(Fire\003y)h(RPC.)23 b Fp(A)n(CM)17 b(T)-5 b(r)o(ansactions)16
b(on)h(Computer)f(Systems)p Fr(,)i(8\(1\):1\226)180 1153
y(17,)h(February)g(1990.)0 1319 y([33])40 b Fp(SIGCOMM)17
b(Symposium)g(on)f(Communications)g(Ar)m(c)o(hitectur)m(es)h(and)f(Pr)l
(otocols)p Fr(,)i(Stanford)d(Uni)n(v)o(ersity)-5 b(,)16
b(CA,)i(August)f(1996.)180 1419 y(A)m(CM)j(Press.)0 1585
y([34])40 b Fp(Pr)l(oceedings)27 b(of)h(the)g(1993)f(A)n(CM)h
(Symposium)f(on)h(Oper)o(ating)f(Systems)h(Principles)p
Fr(,)i(Ashe)n(ville,)g(NC,)e(USA,)h(December)180 1685
y(1993.)18 b(A)m(CM)j(Operating)e(Systems)h(Re)n(vie)n(ws,)h(27\(5\),A)
m(CM)d(Press.)0 1851 y([35])40 b Fp(Pr)l(oceedings)16
b(of)h(the)h(1995)d(A)n(CM)j(Symposium)e(on)h(Oper)o(ating)f(Systems)h
(Principles)p Fr(,)h(Copper)e(Mountain)f(Resort,)j(CO,)g(USA,)180
1950 y(December)h(1995.)f(A)m(CM)j(Operating)e(Systems)h(Re)n(vie)n
(ws,)g(29\(5\),A)m(CM)f(Press.)0 2116 y([36])40 b(C.A.)27
b(Thekkath)f(and)g(H.M.)i(Le)n(vy)-5 b(.)50 b(Lo)n(w-latenc)o(y)25
b(communication)f(on)j(high-speed)e(netw)o(orks.)51 b
Fp(A)n(CM)27 b(T)-5 b(r)o(ansactions)27 b(on)180 2216
y(Computer)20 b(Systems)p Fr(,)g(11\(2\):179\226203,)15
b(May)20 b(1993.)0 2382 y([37])40 b(R.)18 b(W)-7 b(ahbe,)19
b(S.)f(Lucco,)f(T)-6 b(.E.)18 b(Anderson,)e(and)h(S.L.)h(Graham.)24
b(Ef)n(\002cient)17 b(softw)o(are-based)f(f)o(ault)i(isolation.)24
b(In)17 b(SOSP'93)h([34)o(],)180 2482 y(pages)i(203\226216.)0
5731 y Fm(PI)d(n)c(\011)g(1094)p eop
%%Trailer
end
userdict /end-hook known{end-hook}if
%%EOF

Date: Fri, 28 Mar 1997 10:48:43 -0800 (PST)
From: Markus Mock <mock@apex.cs.washington.edu>
To: spin-comp@apex.cs.washington.edu
Subject: C-Mix

Here's what I can say about C-Mix.
Anything we need to add? Other observations? 

C-Mix

Structure:

Input:
	source program + binding time pattern for a target function to
	be specialized e.g. DS (first argument dynamic, second static)

Call Graph Analysis, Pointer Analysis and BTA + cogen

	=> annotated program (feedback for the user)
	   + GE

GE is run (by the programmer) with static data as input => residual program


Capabilities:
	- monovariant specialization of C functions

	- polyvariance at program points: at control flow merges splitting is 
	  done unless C-Mix can determine that the static store is "similar"
	  that allows polyvariance after dynamic ifs. There is no mention of 
	  a reachability analysis, so I am not sure how this works in detail.
	  There's an example where C-Mix multi-way unrolls a binary search 
	  function, though, so it seems to work..
		
	- user feedback about the BTA results as annotated source

Limitations:
	- no polyvariant division 
	- no partially static data structure (structs must be 
	completely dynamic / static)
	- polyvariant function calls are limited:
	  the programmer must explicitly call the GE with different values
	  and execute the resulting residual program by hand
	- no control over unrolling:
	  if the loop is statically controlled it will be unrolled completely
	  
	 


[sources: Andersen's PhD thesis, C-Mix Manual, C-Mix Demo description]


To: spin-comp@franklin.cs.washington.edu
Subject: clustering algorithm
Date: Fri, 28 Mar 1997 12:45:51 PST
From: Matthai Philipose <matthai@franklin.cs.washington.edu>

Hi all,
Here's the clustering algorithm, to the best of my current understanding.

While writing it, a few issues came up in my mind, which I have noted
in the text below. The algorithm is still not polished enough, in my
mind to go into the paper. On the other hand, in my mind, a detailed 
discussion of the clustering issue is premature for this paper, because
we're not sure how useful it is. What I'm hoping is that if we have
a summary paragraph mentioning issues like clustering, the below
write-up will enable a few interesting lines about clustering.

I am leaving right now for a weekend trip. Will be back on monday. 
Feedback will be appreciated.
        Matthai


---------------
Algorithm for clustering unit boundaries:
-----------------------------------------

Unit boundaries are of two kinds:

1)Movable boundaries, arising from static-to-dynamic/dynamic-to-static
promotions/demotions, and annotated on the CFG by a prepass as
Promote(x)/Demote(x).

2)Fixed boundaries, arising at merges through edges that are
discordant, or coming in from another unit, or at nodes that the
target of lazy edges.

The aim of the clustering algorithm is to minimize the number of
programs points at which unit boundaries occur. The movable boundaries
are "clustered" at program points, such that the number of clusters is
minimized. Note that, in general, blindly minimizing the number of
units may be counterproductive. For instance, some units may be very
large, with some parts having a high probability of execution, and
others a low probability. It may be then be advantageous to split the
unit into two units which are specialized lazily. The lowering of cost
achieved by minimizing unit boundaries may therefore be offset by the
increased cost of eagerly specializing large units.
(Do not consider execution frequency when determining final location
of boundary.)
(Do not differentiate between eager and lazy boundaries, i.e. those
that have a cost only at setup vs. those that have a stitched-code
cost; the latter are presumably more important.)

The current clustering scheme works in two steps:

1)The _range-marking step_ computes the range or program points across
which each boundary is allowed to move. 

2)The _range-merging step_ clusters overlapping ranges in such a way as to
minimize the number of clusters formed.

It is OK to decouple the two steps, because range-marking as we
currently think of it is independent of range-merging. Specifically,
the ranges of boundaries are determined only by the structure of the
underlying CFG, not by the ranges of other boundaries. The range of a
boundary can therefore be determined independent of the (final)
locations of other boundaries. (This is true only of movable
boundaries; for instance, moving a Promote() below a diamond can
make the discordant merge at the bottom of the diamond
disappear. Moving a Promote() above a diamond can make lazy boundaries
appear on each branch of the diamond. How much of a problem is this?)

Here are the current range-marking rules:

1. Fixed boundaries are limited to the program point they appear at, in
the original CFG.

2. For Promote(x) boundaries:
	i.Cannot move across uses of x. 
	  This is in order to "respect the intention of the user"
       ii.May move below defs of x, but not above.
	  This is conservative: we could allow movement above defs of
	   x that are not promotions, e.g. x=s+1, s static. The rationale behind
	   allowing movement above defs is that in the promotion case, i.e. x =
	   ..d..,	 d static, a promotion will have to left behind after the def)
      iii.May not move above/below merges, except to control equivalent  
	  (CE) regions of the CFG. 
	  Moving to non-CE regions above a merge is bad because a
	  fixed unit boundary will be otherwise be created at the
	  merge due to multiple entries. 
	  Moving below a merge ...
       iv.May not move below branches, except to control equivalent regions.
	  There's no good reason for this, except that we currently
	  do not have a fast algorithm for range-merging in this case. The
	  following scenario (due to Brian), shows why pushing below branches
	  to non-CE regions may be a good idea:
		promote(x)
		   |
		  / \
               lazy lazy
		:    :

	   The "lazy"s represent fixed boundaries at lazy points. We
	   may want to push the promote down to these boundaries to 
	   save a unit boundary.

	        
3. For Demote(x) boundaries:
	--Cannot move across uses of x.
	--Can only move to CE regions across branches and merges.

The range of motions allowed across branches and merges is currently
restrictive. However, the restrictions are in place because we do not
have a good scheme to cluster such ranges. The only hard restriction
on these ranges is that they are not determined by other ranges;
otherwise the two-phase mark/merge scheme may not work.


Here is the range-merging algorithm:

The restriction that boundaries can move only between control-equivalent
parts of a CFG partitions the set of ranges into "mergeable subsets"
of the set of all ranges. Recall that control-equivalence partitions the CFG
into disjoint control-equivalent (CE) sub-graphs. Our range-marking
rules ensure that no range can fall into more than one of these
disjoint sub-graphs. When merging ranges, therefore, we only have to
be concerned about merging together ranges that belong to the same
CE sub-graph. 

The merging algorithm has as input a CE sub-graph, which is a linear,
non-contiguous sub-graph  of the CFG, with ranges marked on it. Ranges
are marked by annotating at each program point the set of boundaries
that may be moved to that point.

The algorithm works by sweeping the sub-graph program points from top to
bottom. Each time we arrive at a program point that denotes the end of
a range that is not already-clustered (denote this range a "kernel"
range), we cluster together all overlapping ranges at that point that
have not already been clustered. We add these overlapping ranges and
the kernel range to the set of "already-clustered" ranges, and
continue the sweep to find the next kernel range, starting at the
next-program point that contains a non-clustered range.  

It is easy to see that this algorithm produces the minimum number of
clusters possible. Note that we produce a cluster only on detecting a
kernel range, so that the number of clusters is equal to the number of
kernels. Now, two kernels cannot overlap at any point because
otherwise they would have been placed in the same cluster. The number
of kernels is therefore also the minimum number of clusters required,
implying that our algorithm produces no more clusters than necessary.

A concern here may be that since ranges can be discontinuous, the two kernels
may overlap at some points, but not at others. Specifically, we may
fear that when clustering was occurring around the initially detected
kernel range, i.e. at the lowest program point on the kernel range,
the later-detected kernel did not extend to this point. However, our
range-marking rules ensure us that if the two ranges overlapped at any
earlier point, then they must overlap at _all_ CE points downstream
till one of them ends. If two kernels overlap therefore, they are
guaranteed to overlap at the point where the earlier-detected of the
two end. The two would have been clustered together, so that the
later-detected kernel could not have been a kernel after all.

The above algorithm takes O(n^2) time in the size of the CFG; at each
instruction, it checks the O(n) ranges in the the already-clustered
set. By sorting ranges by lower end-point and traversing only
range-endpoints (instead of program points), we should easily be able to get
the time down to O(n).


Date: Fri, 28 Mar 1997 18:27:02 -0800 (PST)
From: chambers@klamath (Craig Chambers)
To: spin-comp@cs
Subject: paper

Ugh.  Markus and I spent most of the day futzing with BTA flow functions and
equations.  I think we've gotten the rules finally written (with a kludge for
reachability analysis and lazy branch identification), and now I need to go 
back, revise the initial bit of English I wrote before I wrote the equations,
and write a bunch of English that explains the highlights of what all the rules
do.  Of course, I still have the GEGen section to write and the related work
and conclusions....

So I'm behind schedule.  I hope I'll get some time to work on it over the
weekend.

Feel free to look at the paper, although the text of section 5 starting at
5.3 is out of date.

-- Craig


Date: Sun, 30 Mar 1997 18:23:13 -0800 (PST)
From: chambers@klamath (Craig Chambers)
To: spin-comp@cs
Subject: paper status

I came in yesterday and today to work on the paper, and I got a bunch
done.  I've finished section 5 (BTA) and written all but subsection
6.4 of section 6 (GEGen).  My text probably isn't great, and I have a
number of markers of issues we need to resolve, and I have essentially
no examples anywhere (a big omission; we need to think of a good
running example that we can use to show e.g. the results of the BTA,
unit boundaries, linearized units, and the RandR function w/ emits).
But it's much better than what we had at the end of the day Friday.

Tomorrow morning I'd like to take the draft of related work that you
all did, and finish a complete draft of the paper before lunch.  Then
we all can sit back, ponder our navels, and start polishing, adding
examples, adding slams of related work intermittently, etc.  Ideally,
by Tuesday afternoon we'd have a nice version of the paper done.

See ~chambers/papers/pepm/97/dc.{doc,ps}.

-- Craig

Date: Mon, 31 Mar 1997 10:31:37 -0800 (PST)
From: chambers@klamath (Craig Chambers)
To: spin-comp@thistle.cs.washington.edu, grant@cs.washington.edu
Subject: Re: related work draft

I have never introduced the name DyC.  Should I?

-- Craig

Date: Mon, 31 Mar 1997 18:25:52 -0800 (PST)
From: chambers@klamath (Craig Chambers)
To: spin-comp@cs
Subject: paper status

There's now a complete set of words for everything but the abstract, acks,
and references.  I'm making a pass through the paper from start to finish,
putting in the technical changes that we all discussed and Brian summarized
on the web.  I'm now in the middle section 4.  Feel free to read the latest
draft, particularly up to 4.2 or so.  I'm not doing anything about examples in
this pass; I'd really like you three to design some good examples to illustrate
the subtler issues, and I can plug them in once they're designed well.

-- Craig

To: spin-comp@thistle.cs.washington.edu
Subject: updated "outstanding issues"
Date: Mon, 31 Mar 1997 23:45:42 PST
From: Brian Grant <grant@thistle.cs.washington.edu>

I updated my list of "outstanding issues" to include section 6.  I didn't
update it for the second draft of sections 1-4.2, nor did I update all
references to "context", referring to the old-style context containing
only variables that make up the cache key.  I saw no major problems with
section 6, and I think it summarizes tons of details remarkably well.

I'll look more at section 5 in the morning, hopefully before I come in.
I'll be in a little late (10 or 10:30).

--Brian

Date: Tue, 1 Apr 1997 10:35:05 -0800 (PST)
From: chambers@klamath (Craig Chambers)
To: eggers@pa.dec.com, cecil@cs, spin-comp@cs
Subject: (more) new UltraSparcs

I just got a letter this morning, and Sun finally came through and approved
our grant proposal that we sent in a year ago to get three UltraSparc-170s 
w/ 128MB RAM and (it turns out) fancy graphics cards.

-- Craig

To: chambers@franklin.cs.washington.edu
cc: spin-comp@franklin.cs.washington.edu
Subject: Common idioms section
Date: Tue, 01 Apr 1997 16:30:06 PST
From: Matthai Philipose <matthai@franklin.cs.washington.edu>

Craig,
I don't know if you have this on your agenda, but when
you're tweaking the text in the paper, you may want to
think of adding the common idioms sub-section to the
annotations section, as we discussed.

Markus, Brian and I decided that as Writer of the Text,
you should be the one who thinks about this. :-)
		Matthai

Date: Tue, 1 Apr 1997 16:43:52 -0800 (PST)
From: chambers@klamath (Craig Chambers)
To: chambers@franklin.cs.washington.edu, matthai@cs.washington.edu
Subject: Re: Common idioms section
Cc: spin-comp@franklin.cs.washington.edu


> From matthai@franklin.cs.washington.edu  Tue Apr  1 16:30:12 1997
> Delivery-Date: Tue, 01 Apr 1997 16:30:19 PST
> X-Mailer: exmh version 1.5.3 12/28/94
> To: chambers@franklin.cs.washington.edu
> cc: spin-comp@franklin.cs.washington.edu
> Subject: Common idioms section
> Reply-to: Matthai Philipose <matthai@cs.washington.edu>
> Mime-Version: 1.0
> Date: Tue, 01 Apr 1997 16:30:06 PST
> From: Matthai Philipose <matthai@franklin.cs.washington.edu>
> 
> Craig,
> I don't know if you have this on your agenda, but when
> you're tweaking the text in the paper, you may want to
> think of adding the common idioms sub-section to the
> annotations section, as we discussed.
> 
> Markus, Brian and I decided that as Writer of the Text,
> you should be the one who thinks about this. :-)
> 		Matthai
> 

Hah!  I won't get to it until I'm done w/ this pass through the text,
including the rel. work, conclusions, and abstract.

-- Craig

Date: Tue, 1 Apr 1997 18:29:29 -0800 (PST)
From: chambers@klamath (Craig Chambers)
To: spin-comp@cs
Subject: status

I spent a bunch of time futzing w/ the BTA equations to try to get the new
caching scheme implemented correctly.  I've pretty much finished up my non-
example editing pass through section 5 now.  Tomorrow I pick up w/ sections
6-8 + abstract, then we can all resynchronize.

-- Craig

Date: Wed, 2 Apr 1997 11:40:53 -0800 (PST)
From: chambers@klamath (Craig Chambers)
To: spin-comp@cs
Subject: pepm comments

FYI.

----- Begin Included Message -----

From grove@pysht.cs.washington.edu  Wed Apr  2 11:36:21 1997
Delivery-Date: Wed, 02 Apr 1997 11:36:23 PST
To: chambers@pysht
Subject: pepm comments
Date: Wed, 02 Apr 1997 11:36:18 PST
From: Dave Grove <grove@pysht.cs.washington.edu>

	I finally got around to reading most of the pepm paper.  I read a
draft from Monday night this morning on the stairmaster, so not sure how
applicable any of these comments are any more.  Since this is probably
an old version of the paper by now, I'll just give some high level
comments.

	1) after reading section 1 & 2 I'm still unclear on the precise
defintion of division vs. specialization.  Is this something the target
audience already knows?  Don't see what is special about the one example
of division you just gave (why it's divsion instead of
specialization)....is it becuase there are annotations guarded by a
dynamic if?  Am I just being dense?

	2) RE the marker at the end of 2, I think it would be helpful to
show the generated code for a simple example, although if space is tight
it isn't critical.

	3) page layout of figure 3 & 4 (4 on the page before 3) was
miserable; I assume you'll futz with this once the english stablizes. Also
cross references are out of whack.

	4) I'm not sure if figure 5 belongs in the main text or in an
appendix.  I'd be inclined to briefly state in english where various
classes of annotations can appear and move the modifications to the C
Grammar to an appendix. 

	5) section 5 needed more initial motivation and a better up front
picture of how the various pieces fit together.  I felt like I was
slogging through a bunch of lattice stuff without a good enough roadmap to
see how it was all going to fit together.  (May have been partially due
to trying to read the paper while working out; not sure if I would have
had quite as much trouble if I was reading the paper & doing nothing else).

	Didn't read sections 6,7,8 that carefully, so no comments there.

--dave

	

	


----- End Included Message -----


Date: Wed, 2 Apr 1997 12:56:09 -0800 (PST)
From: chambers@klamath (Craig Chambers)
To: spin-comp@cs
Subject: issue

My current rules do polyvar division even for different policies of the 
polyvar divide variables.  Maybe we don't want to do that.  What do you all
think?

-- Craig

To: chambers@klamath (Craig Chambers)
cc: spin-comp@thistle.cs.washington.edu
Subject: Re: issue 
Date: Wed, 02 Apr 1997 13:13:10 PST
From: Brian Grant <grant@thistle.cs.washington.edu>

>> My current rules do polyvar division even for different policies of the 
>> polyvar divide variables.  Maybe we don't want to do that.  What do you all
>> think?

We had a discussion about this a while ago and decided it was a good idea to
split on policies because that was the "strongest" notion of keepConst.
However, I could imagine cases where the programmer wouldn't want that
behavior.  We could have a footnote saying that splitting only on the raw
division (static/dynamic) might also be reasonable and that we don't have
enough experience to know whether we would want to split or not.  One could
also imagine yet another policy to control the splitting (poly/mono_policies).

I don't think we should change that aspect of the equations.  We have too many
other bugs to fix.

BTW, my list of outstanding issues is now updated for the version of the
paper I found at 9am this morning (timestamp from 6:30pm last night).

--Brian


Date: Wed, 2 Apr 1997 16:27:34 -0800 (PST)
From: chambers@klamath (Craig Chambers)
To: spin-comp@cs
Subject: paper

OK, I'm finally through w/ edits & changes in section 5 (and all earlier
sections).  I'm going on to section 6 (quick changes I hope), and then to
the related work & conclusions (for the first time).  I assume the rest of
you all are finishing up your examples that can be plopped into the paper
easily.

We're at 15 pages now....  Can somebody email Consel and ask for 2 extra
pages?  Never mind, I'll do that now.

-- Craig

Date: Wed, 2 Apr 1997 18:09:50 -0800 (PST)
From: chambers@klamath (Craig Chambers)
To: spin-comp@cs
Subject: paper status

I'm done w/ section 6 (and earlier sections).  I'm planning to come back in
tonight after dinner and go through section 7 & 8 and write an abstract.  Fun
all around.  Then tomorrow morning I can check Susan's comments.  We also need
to integrate examples sometime.

Note that tomorrow my schedule sucks.  I have lunch w/ the faculty candidate
(which I may cancel out from), a faculty meeting, and the faculty candidate's
talk.  That kills noon-4:30, which if we fedex the paper then means we need to
be done by noon (or 1:30 if I skip lunch).  Agh!!  I don't know when you all
were expecting the examples to get integrated....

Oh, yeah, we're supposed to meet at 10:30-noon.  We won't, except to talk about
the paper and finish it off.

-- Craig

To: chambers@klamath (Craig Chambers)
cc: spin-comp@franklin.cs.washington.edu
Subject: Re: bibs 
Date: Wed, 02 Apr 1997 18:12:53 PST
From: Matthai Philipose <matthai@franklin.cs.washington.edu>

OK. Beginning biblio work... I'll broadcast an OK when I'm done.

> Go ahead and do the bibliography now.  Please let me know when you're done,
> so I can work on the related work.
> 
> -- Craig
> 


To: chambers@franklin.cs.washington.edu
cc: spin-comp@franklin.cs.washington.edu
Subject: biblio done
Date: Wed, 02 Apr 1997 19:30:37 PST
From: Matthai Philipose <matthai@franklin.cs.washington.edu>

Craig,
The biblio is done. Since I did not have write perms on
your copy of the file, I made my own copy of dc.doc
and generated the biblio into it. The copy which includes 
the biblio is: 
~matthai/papers/pepm/97/dc_bib.doc

I also have a version of my examples in  
~matthai/papers/pepm/97/dc_bib.doc
The captions on these (especially the unitized
interpreter) needs more work. Other than that, I
have incorporated a round of feedback from Brian
on these examples. Please let me know if you have
any comments/feedback.

	Matthai




Date: Thu, 3 Apr 1997 00:12:52 -0800 (PST)
From: chambers@klamath (Craig Chambers)
To: spin-comp@cs
Subject: Re: extra pages?

Let's try for 15 pages, but not kill ourselves.

----- Begin Included Message -----

From Charles.Consel@compose.irisa.fr  Wed Apr  2 23:21:50 1997
Delivery-Date: Wed, 02 Apr 1997 23:21:55 PST
Date: Thu, 3 Apr 1997 09:21:44 +0200
From: Charles Consel <Charles.Consel@irisa.fr>
To: chambers@cs.washington.edu
Subject: Re: extra pages?


> As we finalize our PEPM camera-ready paper, it's looking a bit longer than 
> 14 pages.  Can we get 2 extra pages in the proceedings?  Thanks.

1 extra page would be good. 2 pages if absolutely necessary.

> We plan to email you postscript tomorrow afternoon, our time, and
> simultaneously express-mail you a hardcopy, in case the hardcopy arrives in
> time for you and you don't need to hassle w/ our postscript.

Excellent plan!

Charles

----------------------------------------------------------------------------
Charles Consel              | University of Rennes / Irisa 
 consel@irisa.fr            | Campus Universitaire de Beaulieu
 Phone: (33) 2 99 84 74 10 | 35042 Rennes Cedex
 Fax:   (33) 2 99 84 71 71 | France
----------------------------------------------------------------------------
  URL: http://www.irisa.fr/EXTERNE/projet/lande/consel/consel.html & index.html
----------------------------------------------------------------------------


----- End Included Message -----


Date: Thu, 3 Apr 1997 00:50:38 -0800 (PST)
From: chambers@klamath (Craig Chambers)
To: spin-comp@cs
Subject: Re: PEPM paper

for the fedex packet.

----- Begin Included Message -----

From Charles.Consel@compose.irisa.fr  Thu Apr  3 00:10:32 1997
Delivery-Date: Thu, 03 Apr 1997 00:10:35 PST
Date: Thu, 3 Apr 1997 10:10:25 +0200
From: Charles Consel <Charles.Consel@irisa.fr>
To: chambers@cs.washington.edu
Subject: Re: PEPM paper


> Also, can you give me a street address for the express-mail package?  I'm not
> sure just "U of Rennes/Irisa" is sufficient for them.

The precise address is

Charles Consel  
University of Rennes / Irisa 
Campus Universitaire de Beaulieu
263 Avenue du General Leclerc
35042 Rennes Cedex
France

Phone: (33) 2 99 84 74 10 
Fax:   (33) 2 99 84 71 71 



----- End Included Message -----


Date: Thu, 3 Apr 1997 01:00:21 -0800 (PST)
From: chambers@klamath (Craig Chambers)
To: spin-comp@cs
Subject: paper status

I've finished a complete, whole, and total draft of the paper.  In the 
standard place.  Essentially no examples were added, because they either had
bugs, were space-hungry, or were hard to integrate.  We'll try again tomorrow.
I also still need to go through Susan's comments.  And there is one citation
that didn't work under bibframe (Andersen92, in marker font; Matthai, please
fix).

See you all around 10:30 tomorrow.

-- Craig

Date: Thu, 03 Apr 1997 12:44:02 -0800
From: Charles Garrett <garrett@cs.washington.edu>
To: Craig Chambers <chambers@klamath>
Subject: Re: paper status

To the holder of the paper lock.

On reading example 3, I noticed that some of the longer lines in 
the typewriter format are getting cut off on the right margin.
For example, in the first comment, the word "for" is not all
there.

--
Charlie

Date: Thu, 3 Apr 1997 12:45:32 -0800 (PST)
From: chambers@klamath (Craig Chambers)
To: garrett@cs.washington.edu
Subject: Re: paper status
Cc: spin-comp@cs

Got it, thanks.

-- Craig

Date: Thu, 3 Apr 1997 13:22:12 -0800 (PST)
From: chambers@klamath (Craig Chambers)
To: spin-comp@cs
Subject: paper

I've finished my pass through the paper, putting in Brian's and Susan's
suggestions.  There remains to plug in and describe Matthai's example and fix
the one messed up bib entry.  That's all, I think.

I'm releasing the write lock, and dashing off to the faculty meeting.

-- Craig

Date: Thu, 3 Apr 1997 13:23:24 -0800 (PST)
From: chambers@klamath (Craig Chambers)
To: spin-comp@cs
Subject: re: paper

And of course we need to do final page layout tweaking and converting all the
et al.'s to italics and any other clean-ups to the reference list.  Matthai,
could you look through the references and try to make the reference formats
consistent, if there are inconsistencies?  Thanks.

-- Craig

To: spin-comp@thistle.cs.washington.edu
Subject: name suggestion
Date: Thu, 03 Apr 1997 13:26:36 PST
From: Brian Grant <grant@thistle.cs.washington.edu>

How about Duchamp?

From Grolier's:
Marcel Duchamp, b. July 28, 1887, d. Oct. 2, 1968, was a French painter and
theorist and one of the most influential figures of avant-garde 20th-century
art.  Duchamp developed a type of symbolic painting, a dynamic version of facet
CUBISM (similar to FUTURISM), in which the image depicted successive movements
of a single body....Following his maxim never to repeat himself...

Note _dynamic_, "depicted successive movements" (sounds like specialized
versions), and "never to repeat" (CacheAllUnchecked!). :-)

--Brian


To: spin-comp@franklin.cs.washington.edu
Subject: I'm munging the paper
Date: Thu, 03 Apr 1997 13:29:47 PST
From: Matthai Philipose <matthai@franklin.cs.washington.edu>

I'm adding the figure with the unitization example and
fixing bib references in my copy of Craig's latest
version of the paper.

I'll sound the all clear when I'm done.
		Matthai

To: spin-comp@thistle.cs.washington.edu
Subject: Re: name suggestion 
Date: Thu, 03 Apr 1997 13:45:42 PST
From: Brian Grant <grant@thistle.cs.washington.edu>

The more I think about it, the more I like it.

-- One of Duchamp's styles, dynamism, attempted to capture dynamic behavior
   (i.e., motion) in a static medium (i.e., painting).  Sounds like templates!
-- Duchamp was French/European, something Consel/the PE audience can
   appreciate :-)
-- If it is mispronounced by Americans it sounds like "duh Champ!"

:-)

--Brian


To: Brian Grant <grant@cs.washington.edu>
Cc: spin-comp@thistle.cs.washington.edu, eggers@pa.dec.com
Subject: Re: name suggestion 
Date: Thu, 03 Apr 97 13:56:31 -0800
From: Susan Eggers <eggers@pa.dec.com>

Help, what have I started.  :-)
I hope we're not putting a new name into this paper.

Susan


Date: Thu, 3 Apr 1997 14:24:32 -0800 (PST)
From: Markus Mock <mock@apex.cs.washington.edu>
To: Craig Chambers <chambers@apex.cs.washington.edu>
cc: spin-comp@apex.cs.washington.edu
Subject: paper comments

I have just a few small comments:

- I guess you have changed "deference" to dereference
- page 1, right half, bullet 1: rather .. that ... lots of space
  between the words
- page 5, section 4.1 "treats each of them as .."
	it's not make_static that treats them, it has the effect that these
	variables are treated as or made into run-time constants

	the figure doesn't show very well the different resulting regions
	maybe makign the static root vars in each region bold face would help
	to get that across, right now we always have ..x,y.. there

- page 12, section 6.1
	The branch successor edge determines ..

	that's a huge sentence, really hard to understand. Breaking it up 
	in two would probably help already..




	-- Markus


Date: Thu, 3 Apr 1997 17:13:37 -0800 (PST)
From: chambers@klamath (Craig Chambers)
To: charles.consel@irisa.fr
Subject: pepm paper
Cc: spin-comp@cs

Here's the postscript for our PEPM paper.  We couldn't get it down to just
15 pages in the time available; it's already very dense; sorry.  We also have
mailed you by express mail a hardcopy of the paper.  Thanks for your patience
with us.

-- Craig


%!PS-Adobe-3.0
%%BoundingBox: (atend)
%%Pages: (atend)
%%PageOrder: (atend)
%%DocumentFonts: (atend)
%%Creator: Frame 4.0
%%DocumentData: Clean7Bit
%%EndComments
%%BeginProlog
%
% Frame ps_prolog 4.0, for use with Frame 4.0 products
% This ps_prolog file is Copyright (c) 1986-1993 Frame Technology
% Corporation.  All rights reserved.  This ps_prolog file may be
% freely copied and distributed in conjunction with documents created
% using FrameMaker, FrameBuilder and FrameViewer as long as this 
% copyright notice is preserved.
%
% Frame products normally print colors as their true color on a color printer
% or as shades of gray, based on luminance, on a black-and white printer. The
% following flag, if set to True, forces all non-white colors to print as pure
% black. This has no effect on bitmap images.
/FMPrintAllColorsAsBlack             false def
%
% Frame products can either set their own line screens or use a printer's 
% default settings. Three flags below control this separately for no 
% separations, spot separations and process separations. If a flag
% is true, then the default printer settings will not be changed. If it is
% false, Frame products will use their own settings from a table based on
% the printer's resolution.
/FMUseDefaultNoSeparationScreen      true  def
/FMUseDefaultSpotSeparationScreen    true  def
/FMUseDefaultProcessSeparationScreen false def
%
% For any given PostScript printer resolution, Frame products have two sets of 
% screen angles and frequencies for printing process separations, which are 
% recomended by Adobe. The following variable chooses the higher frequencies
% when set to true or the lower frequencies when set to false. This is only
% effective if the appropriate FMUseDefault...SeparationScreen flag is false.
/FMUseHighFrequencyScreens true def
%
% PostScript Level 2 printers contain an "Accurate Screens" feature which can
% improve process separation rendering at the expense of compute time. This 
% flag is ignored by PostScript Level 1 printers.
/FMUseAcccurateScreens true def
%
% The following PostScript procedure defines the spot function that Frame
% products will use for process separations. You may un-comment-out one of
% the alternative functions below, or use your own.
%
% Dot function
/FMSpotFunction {abs exch abs 2 copy add 1 gt 
		{1 sub dup mul exch 1 sub dup mul add 1 sub }
		{dup mul exch dup mul add 1 exch sub }ifelse } def
%
% Line function
% /FMSpotFunction { pop } def
%
% Elipse function
% /FMSpotFunction { dup 5 mul 8 div mul exch dup mul exch add 
%		sqrt 1 exch sub } def
%
%
/FMversion (4.0) def 
/FMLevel1 /languagelevel where {pop languagelevel} {1} ifelse 2 lt def
/FMPColor
	FMLevel1 {
		false
		/colorimage where {pop pop true} if
	} {
		true
	} ifelse
def
/FrameDict 400 dict def 
systemdict /errordict known not {/errordict 10 dict def
		errordict /rangecheck {stop} put} if
% The readline in PS 23.0 doesn't recognize cr's as nl's on AppleTalk
FrameDict /tmprangecheck errordict /rangecheck get put 
errordict /rangecheck {FrameDict /bug true put} put 
FrameDict /bug false put 
mark 
% Some PS machines read past the CR, so keep the following 3 lines together!
currentfile 5 string readline
00
0000000000
cleartomark 
errordict /rangecheck FrameDict /tmprangecheck get put 
FrameDict /bug get { 
	/readline {
		/gstring exch def
		/gfile exch def
		/gindex 0 def
		{
			gfile read pop 
			dup 10 eq {exit} if 
			dup 13 eq {exit} if 
			gstring exch gindex exch put 
			/gindex gindex 1 add def 
		} loop
		pop 
		gstring 0 gindex getinterval true 
		} bind def
	} if
/FMshowpage /showpage load def
/FMquit /quit load def
/FMFAILURE { 
	dup = flush 
	FMshowpage 
	/Helvetica findfont 12 scalefont setfont
	72 200 moveto
	show FMshowpage 
	FMquit 
	} def 
/FMVERSION {
	FMversion ne {
		(Frame product version does not match ps_prolog!) FMFAILURE
		} if
	} def 
/FMBADEPSF { 
	(PostScript Lang. Ref. Man., 2nd Ed., H.2.4 says EPS must not call X              )
	dup dup (X) search pop exch pop exch pop length 
	4 -1 roll 
	putinterval 
	FMFAILURE
	} def
/FMLOCAL {
	FrameDict begin
	0 def 
	end 
	} def 
/concatprocs
	{
	/proc2 exch cvlit def/proc1 exch cvlit def/newproc proc1 length proc2 length add array def
	newproc 0 proc1 putinterval newproc proc1 length proc2 putinterval newproc cvx
}def
FrameDict begin 
/FMnone 0 def
/FMcyan 1 def
/FMmagenta 2 def
/FMyellow 3 def
/FMblack 4 def
/FMcustom 5 def
/FrameNegative false def 
/FrameSepIs FMnone def 
/FrameSepBlack 0 def
/FrameSepYellow 0 def
/FrameSepMagenta 0 def
/FrameSepCyan 0 def
/FrameSepRed 1 def
/FrameSepGreen 1 def
/FrameSepBlue 1 def
/FrameCurGray 1 def
/FrameCurPat null def
/FrameCurColors [ 0 0 0 1 0 0 0 ] def 
/FrameColorEpsilon .001 def	
/eqepsilon {		
	sub dup 0 lt {neg} if
	FrameColorEpsilon le
} bind def
/FrameCmpColorsCMYK { 
	2 copy 0 get exch 0 get eqepsilon {
		2 copy 1 get exch 1 get eqepsilon {
			2 copy 2 get exch 2 get eqepsilon {
				3 get exch 3 get eqepsilon
			} {pop pop false} ifelse
		}{pop pop false} ifelse
	} {pop pop false} ifelse
} bind def
/FrameCmpColorsRGB { 
	2 copy 4 get exch 0 get eqepsilon {
		2 copy 5 get exch 1 get eqepsilon {
			6 get exch 2 get eqepsilon
		}{pop pop false} ifelse
	} {pop pop false} ifelse
} bind def
/RGBtoCMYK { 
	1 exch sub 
	3 1 roll 
	1 exch sub 
	3 1 roll 
	1 exch sub 
	3 1 roll 
	3 copy 
	2 copy 
	le { pop } { exch pop } ifelse 
	2 copy 
	le { pop } { exch pop } ifelse 
	dup dup dup 
	6 1 roll 
	4 1 roll 
	7 1 roll 
	sub 
	6 1 roll 
	sub 
	5 1 roll 
	sub 
	4 1 roll 
} bind def
/CMYKtoRGB { 
	dup dup 4 -1 roll add 						  
	5 1 roll 3 -1 roll add 						  
	4 1 roll add 								  
	1 exch sub dup 0 lt {pop 0} if 3 1 roll 	  
	1 exch sub dup 0 lt {pop 0} if exch 	      
	1 exch sub dup 0 lt {pop 0} if exch	  		  
} bind def
/FrameSepInit {
	1.0 RealSetgray
} bind def
/FrameSetSepColor { 
	/FrameSepBlue exch def
	/FrameSepGreen exch def
	/FrameSepRed exch def
	/FrameSepBlack exch def
	/FrameSepYellow exch def
	/FrameSepMagenta exch def
	/FrameSepCyan exch def
	/FrameSepIs FMcustom def
	setCurrentScreen	
} bind def
/FrameSetCyan {
	/FrameSepBlue 1.0 def
	/FrameSepGreen 1.0 def
	/FrameSepRed 0.0 def
	/FrameSepBlack 0.0 def
	/FrameSepYellow 0.0 def
	/FrameSepMagenta 0.0 def
	/FrameSepCyan 1.0 def
	/FrameSepIs FMcyan def
	setCurrentScreen	
} bind def
 
/FrameSetMagenta {
	/FrameSepBlue 1.0 def
	/FrameSepGreen 0.0 def
	/FrameSepRed 1.0 def
	/FrameSepBlack 0.0 def
	/FrameSepYellow 0.0 def
	/FrameSepMagenta 1.0 def
	/FrameSepCyan 0.0 def
	/FrameSepIs FMmagenta def
	setCurrentScreen
} bind def
 
/FrameSetYellow {
	/FrameSepBlue 0.0 def
	/FrameSepGreen 1.0 def
	/FrameSepRed 1.0 def
	/FrameSepBlack 0.0 def
	/FrameSepYellow 1.0 def
	/FrameSepMagenta 0.0 def
	/FrameSepCyan 0.0 def
	/FrameSepIs FMyellow def
	setCurrentScreen
} bind def
 
/FrameSetBlack {
	/FrameSepBlue 0.0 def
	/FrameSepGreen 0.0 def
	/FrameSepRed 0.0 def
	/FrameSepBlack 1.0 def
	/FrameSepYellow 0.0 def
	/FrameSepMagenta 0.0 def
	/FrameSepCyan 0.0 def
	/FrameSepIs FMblack def
	setCurrentScreen
} bind def
 
/FrameNoSep { 
	/FrameSepIs FMnone def
	setCurrentScreen
} bind def
/FrameSetSepColors { 
	FrameDict begin
	[ exch 1 add 1 roll ]
	/FrameSepColors  
	exch def end
	} bind def
/FrameColorInSepListCMYK { 
	FrameSepColors {  
       		exch dup 3 -1 roll 
       		FrameCmpColorsCMYK 
       		{ pop true exit } if
    	} forall 
	dup true ne {pop false} if
	} bind def
/FrameColorInSepListRGB { 
	FrameSepColors {  
       		exch dup 3 -1 roll 
       		FrameCmpColorsRGB 
       		{ pop true exit } if
    	} forall 
	dup true ne {pop false} if
	} bind def
/RealSetgray /setgray load def
/RealSetrgbcolor /setrgbcolor load def
/RealSethsbcolor /sethsbcolor load def
end 
/setgray { 
	FrameDict begin
	FrameSepIs FMnone eq
		{ RealSetgray } 
		{ 
		FrameSepIs FMblack eq 
			{ RealSetgray } 
			{ FrameSepIs FMcustom eq 
			  FrameSepRed 0 eq and
			  FrameSepGreen 0 eq and
			  FrameSepBlue 0 eq and {
			  	RealSetgray
			  } {
				1 RealSetgray pop 
			  } ifelse
			} ifelse
		} ifelse
	end
} bind def
/setrgbcolor { 
	FrameDict begin
	FrameSepIs FMnone eq
	{  RealSetrgbcolor }
	{
		3 copy [ 4 1 roll ] 
		FrameColorInSepListRGB
		{
				FrameSepBlue eq exch 
			 	FrameSepGreen eq and exch 
			 	FrameSepRed eq and
			 	{ 0 } { 1 } ifelse
		}
		{
			FMPColor {
				RealSetrgbcolor
				currentcmykcolor
			} {
				RGBtoCMYK
			} ifelse
			FrameSepIs FMblack eq
			{1.0 exch sub 4 1 roll pop pop pop} {
			FrameSepIs FMyellow eq
			{pop 1.0 exch sub 3 1 roll pop pop} {
			FrameSepIs FMmagenta eq
			{pop pop 1.0 exch sub exch pop } {
			FrameSepIs FMcyan eq
			{pop pop pop 1.0 exch sub } 
			{pop pop pop pop 1} ifelse } ifelse } ifelse } ifelse 
		} ifelse
		RealSetgray
	} 
	ifelse
	end
} bind def
/sethsbcolor {
	FrameDict begin
	FrameSepIs FMnone eq 
	{ RealSethsbcolor } 
	{
		RealSethsbcolor 
		currentrgbcolor  
		setrgbcolor 
	} 
	ifelse
	end
} bind def
FrameDict begin
/setcmykcolor where {
	pop /RealSetcmykcolor /setcmykcolor load def
} {
	/RealSetcmykcolor {
		4 1 roll
		3 { 3 index add 0 max 1 min 1 exch sub 3 1 roll} repeat 
		setrgbcolor pop
	} bind def
} ifelse
userdict /setcmykcolor { 
		FrameDict begin
		FrameSepIs FMnone eq
		{ RealSetcmykcolor } 
		{
			4 copy [ 5 1 roll ]
			FrameColorInSepListCMYK
			{
				FrameSepBlack eq exch 
				FrameSepYellow eq and exch 
				FrameSepMagenta eq and exch 
				FrameSepCyan eq and 
				{ 0 } { 1 } ifelse
			}
			{
				FrameSepIs FMblack eq
				{1.0 exch sub 4 1 roll pop pop pop} {
				FrameSepIs FMyellow eq
				{pop 1.0 exch sub 3 1 roll pop pop} {
				FrameSepIs FMmagenta eq
				{pop pop 1.0 exch sub exch pop } {
				FrameSepIs FMcyan eq
				{pop pop pop 1.0 exch sub } 
				{pop pop pop pop 1} ifelse } ifelse } ifelse } ifelse 
			} ifelse
			RealSetgray
		}
		ifelse
		end
	} bind put
FMLevel1 not { 
	
	/patProcDict 5 dict dup begin
		<0f1e3c78f0e1c387> { 3 setlinewidth -1 -1 moveto 9 9 lineto stroke 
											4 -4 moveto 12 4 lineto stroke
											-4 4 moveto 4 12 lineto stroke} bind def
		<0f87c3e1f0783c1e> { 3 setlinewidth -1 9 moveto 9 -1 lineto stroke 
											-4 4 moveto 4 -4 lineto stroke
											4 12 moveto 12 4 lineto stroke} bind def
		<8142241818244281> { 1 setlinewidth -1 9 moveto 9 -1 lineto stroke
											-1 -1 moveto 9 9 lineto stroke } bind def
		<03060c183060c081> { 1 setlinewidth -1 -1 moveto 9 9 lineto stroke 
											4 -4 moveto 12 4 lineto stroke
											-4 4 moveto 4 12 lineto stroke} bind def
		<8040201008040201> { 1 setlinewidth -1 9 moveto 9 -1 lineto stroke 
											-4 4 moveto 4 -4 lineto stroke
											4 12 moveto 12 4 lineto stroke} bind def
	end def
	/patDict 15 dict dup begin
		/PatternType 1 def		
		/PaintType 2 def		
		/TilingType 3 def		
		/BBox [ 0 0 8 8 ] def 	
		/XStep 8 def			
		/YStep 8 def			
		/PaintProc {
			begin
			patProcDict bstring known {
				patProcDict bstring get exec
			} {
				8 8 true [1 0 0 -1 0 8] bstring imagemask
			} ifelse
			end
		} bind def
	end def
} if
/combineColor {
    FrameSepIs FMnone eq
	{
		graymode FMLevel1 or not {
			
			[/Pattern [/DeviceCMYK]] setcolorspace
			FrameCurColors 0 4 getinterval aload pop FrameCurPat setcolor
		} {
			FrameCurColors 3 get 1.0 ge {
				FrameCurGray RealSetgray
			} {
				FMPColor graymode and {
					0 1 3 { 
						FrameCurColors exch get
						1 FrameCurGray sub mul
					} for
					RealSetcmykcolor
				} {
					4 1 6 {
						FrameCurColors exch get
						graymode {
							1 exch sub 1 FrameCurGray sub mul 1 exch sub
						} {
							1.0 lt {FrameCurGray} {1} ifelse
						} ifelse
					} for
					RealSetrgbcolor
				} ifelse
			} ifelse
		} ifelse
	} { 
		FrameCurColors 0 4 getinterval aload
		FrameColorInSepListCMYK {
			FrameSepBlack eq exch 
			FrameSepYellow eq and exch 
			FrameSepMagenta eq and exch 
			FrameSepCyan eq and
			FrameSepIs FMcustom eq and
			{ FrameCurGray } { 1 } ifelse
		} {
			FrameSepIs FMblack eq
			{FrameCurGray 1.0 exch sub mul 1.0 exch sub 4 1 roll pop pop pop} {
			FrameSepIs FMyellow eq
			{pop FrameCurGray 1.0 exch sub mul 1.0 exch sub 3 1 roll pop pop} {
			FrameSepIs FMmagenta eq
			{pop pop FrameCurGray 1.0 exch sub mul 1.0 exch sub exch pop } {
			FrameSepIs FMcyan eq
			{pop pop pop FrameCurGray 1.0 exch sub mul 1.0 exch sub } 
			{pop pop pop pop 1} ifelse } ifelse } ifelse } ifelse 
		} ifelse
		graymode FMLevel1 or not {
			
			[/Pattern [/DeviceGray]] setcolorspace
			FrameCurPat setcolor
		} { 
			graymode not FMLevel1 and {
				
				dup 1 lt {pop FrameCurGray} if
			} if
			RealSetgray
		} ifelse
	} ifelse
} bind def
/savematrix {
	orgmatrix currentmatrix pop
	} bind def
/restorematrix {
	orgmatrix setmatrix
	} bind def
/dmatrix matrix def
/dpi    72 0 dmatrix defaultmatrix dtransform
    dup mul exch   dup mul add   sqrt def
	
/freq dpi dup 72 div round dup 0 eq {pop 1} if 8 mul div def
/sangle 1 0 dmatrix defaultmatrix dtransform exch atan def
/dpiranges   [  2540    2400    1693     1270    1200     635      600      0      ] def
/CMLowFreqs  [ 100.402  94.8683 89.2289 100.402  94.8683  66.9349  63.2456 47.4342 ] def
/YLowFreqs   [  95.25   90.0    84.65    95.25   90.0     70.5556  66.6667 50.0    ] def
/KLowFreqs   [  89.8026 84.8528 79.8088  89.8026 84.8528  74.8355  70.7107 53.033  ] def
/CLowAngles  [  71.5651 71.5651 71.5651 71.5651  71.5651  71.5651  71.5651 71.5651 ] def
/MLowAngles  [  18.4349 18.4349 18.4349 18.4349  18.4349  18.4349  18.4349 18.4349 ] def
/YLowTDot    [  true    true    false    true    true     false    false   false   ] def
/CMHighFreqs [ 133.87  126.491 133.843  108.503 102.523  100.402   94.8683 63.2456 ] def
/YHighFreqs  [ 127.0   120.0   126.975  115.455 109.091   95.25    90.0    60.0    ] def
/KHighFreqs  [ 119.737 113.137 119.713  128.289 121.218   89.8026  84.8528 63.6395 ] def
/CHighAngles [  71.5651 71.5651 71.5651  70.0169 70.0169  71.5651  71.5651 71.5651 ] def
/MHighAngles [  18.4349 18.4349 18.4349  19.9831 19.9831  18.4349  18.4349 18.4349 ] def
/YHighTDot   [  false   false   true     false   false    true     true    false   ] def
/PatFreq     [	10.5833 10.0     9.4055  10.5833 10.0	  10.5833  10.0	   9.375   ] def
/screenIndex {
	0 1 dpiranges length 1 sub { dup dpiranges exch get 1 sub dpi le {exit} {pop} ifelse } for
} bind def
/getCyanScreen {
	FMUseHighFrequencyScreens { CHighAngles CMHighFreqs} {CLowAngles CMLowFreqs} ifelse
		screenIndex dup 3 1 roll get 3 1 roll get /FMSpotFunction load
} bind def
/getMagentaScreen {
	FMUseHighFrequencyScreens { MHighAngles CMHighFreqs } {MLowAngles CMLowFreqs} ifelse
		screenIndex dup 3 1 roll get 3 1 roll get /FMSpotFunction load
} bind def
/getYellowScreen {
	FMUseHighFrequencyScreens { YHighTDot YHighFreqs} { YLowTDot YLowFreqs } ifelse
		screenIndex dup 3 1 roll get 3 1 roll get { 3 div
			{2 { 1 add 2 div 3 mul dup floor sub 2 mul 1 sub exch} repeat
			FMSpotFunction } } {/FMSpotFunction load } ifelse
			0.0 exch
} bind def
/getBlackScreen  {
	FMUseHighFrequencyScreens { KHighFreqs } { KLowFreqs } ifelse
		screenIndex get 45.0 /FMSpotFunction load 
} bind def
/getSpotScreen {
	getBlackScreen
} bind def
/getCompositeScreen {
	getBlackScreen
} bind def
/FMSetScreen 
	FMLevel1 { /setscreen load 
	}{ {
		8 dict begin
		/HalftoneType 1 def
		/SpotFunction exch def
		/Angle exch def
		/Frequency exch def
		/AccurateScreens FMUseAcccurateScreens def
		currentdict end sethalftone
	} bind } ifelse
def
/setDefaultScreen {
	FMPColor {
		orgrxfer cvx orggxfer cvx orgbxfer cvx orgxfer cvx setcolortransfer
	}
	{
		orgxfer cvx settransfer
	} ifelse
	orgfreq organgle orgproc cvx setscreen
} bind def
/setCurrentScreen {
	FrameSepIs FMnone eq {
		FMUseDefaultNoSeparationScreen {
			setDefaultScreen
		} {
			getCompositeScreen FMSetScreen
		} ifelse
	} {
		FrameSepIs FMcustom eq {
			FMUseDefaultSpotSeparationScreen {
				setDefaultScreen
			} {
				getSpotScreen FMSetScreen
			} ifelse
		} {
			FMUseDefaultProcessSeparationScreen {
				setDefaultScreen
			} {
				FrameSepIs FMcyan eq {
					getCyanScreen FMSetScreen
				} {
					FrameSepIs FMmagenta eq {
						getMagentaScreen FMSetScreen
					} {
						FrameSepIs FMyellow eq {
							getYellowScreen FMSetScreen
						} {
							getBlackScreen FMSetScreen
						} ifelse
					} ifelse
				} ifelse
			} ifelse
		} ifelse
	} ifelse 
} bind def
end
	/gstring FMLOCAL
	/gfile FMLOCAL
	/gindex FMLOCAL
	/orgrxfer FMLOCAL
	/orggxfer FMLOCAL
	/orgbxfer FMLOCAL
	/orgxfer FMLOCAL
	/orgproc FMLOCAL
	/orgrproc FMLOCAL
	/orggproc FMLOCAL
	/orgbproc FMLOCAL
	/organgle FMLOCAL
	/orgrangle FMLOCAL
	/orggangle FMLOCAL
	/orgbangle FMLOCAL
	/orgfreq FMLOCAL
	/orgrfreq FMLOCAL
	/orggfreq FMLOCAL
	/orgbfreq FMLOCAL
	/yscale FMLOCAL
	/xscale FMLOCAL
	/edown FMLOCAL
	/manualfeed FMLOCAL
	/paperheight FMLOCAL
	/paperwidth FMLOCAL
/FMDOCUMENT { 
	array /FMfonts exch def 
	/#copies exch def
	FrameDict begin
	0 ne /manualfeed exch def
	/paperheight exch def
	/paperwidth exch def
	0 ne /FrameNegative exch def 
	0 ne /edown exch def 
	/yscale exch def
	/xscale exch def
	FMLevel1 {
		manualfeed {setmanualfeed} if
		/FMdicttop countdictstack 1 add def 
		/FMoptop count def 
		setpapername 
		manualfeed {true} {papersize} ifelse 
		{manualpapersize} {false} ifelse 
		{desperatepapersize} {false} ifelse 
		{ (Can't select requested paper size for Frame print job!) FMFAILURE } if
		count -1 FMoptop {pop pop} for
		countdictstack -1 FMdicttop {pop end} for 
		}
		{{1 dict dup /PageSize [paperwidth paperheight]put setpagedevice}stopped
		{ (Can't select requested paper size for Frame print job!) FMFAILURE } if
		 {1 dict dup /ManualFeed manualfeed put setpagedevice } stopped pop }
	ifelse 
	
	FMPColor {
		currentcolorscreen
			cvlit /orgproc exch def
				  /organgle exch def 
				  /orgfreq exch def
			cvlit /orgbproc exch def
				  /orgbangle exch def 
				  /orgbfreq exch def
			cvlit /orggproc exch def
				  /orggangle exch def 
				  /orggfreq exch def
			cvlit /orgrproc exch def
				  /orgrangle exch def 
				  /orgrfreq exch def
			currentcolortransfer 
			FrameNegative {
				1 1 4 { 
					pop { 1 exch sub } concatprocs 4 1 roll
				} for
				4 copy
				setcolortransfer
			} if
			cvlit /orgxfer exch def
			cvlit /orgbxfer exch def
			cvlit /orggxfer exch def
			cvlit /orgrxfer exch def
	} {
		currentscreen 
			cvlit /orgproc exch def
				  /organgle exch def 
				  /orgfreq exch def
				  
		currenttransfer 
		FrameNegative {
			{ 1 exch sub } concatprocs
			dup settransfer
		} if 
		cvlit /orgxfer exch def
	} ifelse
	end 
} def 
/pagesave FMLOCAL
/orgmatrix FMLOCAL
/landscape FMLOCAL
/pwid FMLOCAL
/FMBEGINPAGE { 
	FrameDict begin 
	/pagesave save def
	3.86 setmiterlimit
	/landscape exch 0 ne def
	landscape { 
		90 rotate 0 exch dup /pwid exch def neg translate pop 
	}{
		pop /pwid exch def
	} ifelse
	edown { [-1 0 0 1 pwid 0] concat } if
	0 0 moveto paperwidth 0 lineto paperwidth paperheight lineto 
	0 paperheight lineto 0 0 lineto 1 setgray fill
	xscale yscale scale
	/orgmatrix matrix def
	gsave 
} def 
/FMENDPAGE {
	grestore 
	pagesave restore
	end 
	showpage
	} def 
/FMFONTDEFINE { 
	FrameDict begin
	findfont 
	ReEncode 
	1 index exch 
	definefont 
	FMfonts 3 1 roll 
	put
	end 
	} def 
/FMFILLS {
	FrameDict begin dup
	array /fillvals exch def
	dict /patCache exch def
	end 
	} def 
/FMFILL {
	FrameDict begin
	 fillvals 3 1 roll put
	end 
	} def 
/FMNORMALIZEGRAPHICS { 
	newpath
	0.0 0.0 moveto
	1 setlinewidth
	0 setlinecap
	0 0 0 sethsbcolor
	0 setgray 
	} bind def
	/fx FMLOCAL
	/fy FMLOCAL
	/fh FMLOCAL
	/fw FMLOCAL
	/llx FMLOCAL
	/lly FMLOCAL
	/urx FMLOCAL
	/ury FMLOCAL
/FMBEGINEPSF { 
	end 
	/FMEPSF save def 
	/showpage {} def 
% See Adobe's "PostScript Language Reference Manual, 2nd Edition", page 714.
% "...the following operators MUST NOT be used in an EPS file:" (emphasis ours)
	/banddevice {(banddevice) FMBADEPSF} def
	/clear {(clear) FMBADEPSF} def
	/cleardictstack {(cleardictstack) FMBADEPSF} def 
	/copypage {(copypage) FMBADEPSF} def
	/erasepage {(erasepage) FMBADEPSF} def
	/exitserver {(exitserver) FMBADEPSF} def
	/framedevice {(framedevice) FMBADEPSF} def
	/grestoreall {(grestoreall) FMBADEPSF} def
	/initclip {(initclip) FMBADEPSF} def
	/initgraphics {(initgraphics) FMBADEPSF} def
	/initmatrix {(initmatrix) FMBADEPSF} def
	/quit {(quit) FMBADEPSF} def
	/renderbands {(renderbands) FMBADEPSF} def
	/setglobal {(setglobal) FMBADEPSF} def
	/setpagedevice {(setpagedevice) FMBADEPSF} def
	/setshared {(setshared) FMBADEPSF} def
	/startjob {(startjob) FMBADEPSF} def
	/lettertray {(lettertray) FMBADEPSF} def
	/letter {(letter) FMBADEPSF} def
	/lettersmall {(lettersmall) FMBADEPSF} def
	/11x17tray {(11x17tray) FMBADEPSF} def
	/11x17 {(11x17) FMBADEPSF} def
	/ledgertray {(ledgertray) FMBADEPSF} def
	/ledger {(ledger) FMBADEPSF} def
	/legaltray {(legaltray) FMBADEPSF} def
	/legal {(legal) FMBADEPSF} def
	/statementtray {(statementtray) FMBADEPSF} def
	/statement {(statement) FMBADEPSF} def
	/executivetray {(executivetray) FMBADEPSF} def
	/executive {(executive) FMBADEPSF} def
	/a3tray {(a3tray) FMBADEPSF} def
	/a3 {(a3) FMBADEPSF} def
	/a4tray {(a4tray) FMBADEPSF} def
	/a4 {(a4) FMBADEPSF} def
	/a4small {(a4small) FMBADEPSF} def
	/b4tray {(b4tray) FMBADEPSF} def
	/b4 {(b4) FMBADEPSF} def
	/b5tray {(b5tray) FMBADEPSF} def
	/b5 {(b5) FMBADEPSF} def
	FMNORMALIZEGRAPHICS 
	[/fy /fx /fh /fw /ury /urx /lly /llx] {exch def} forall 
	fx fw 2 div add fy fh 2 div add  translate
	rotate
	fw 2 div neg fh 2 div neg translate
	fw urx llx sub div fh ury lly sub div scale 
	llx neg lly neg translate 
	/FMdicttop countdictstack 1 add def 
	/FMoptop count def 
	} bind def
/FMENDEPSF {
	count -1 FMoptop {pop pop} for 
	countdictstack -1 FMdicttop {pop end} for 
	FMEPSF restore
	FrameDict begin 
	} bind def
FrameDict begin 
/setmanualfeed {
%%BeginFeature *ManualFeed True
	 statusdict /manualfeed true put
%%EndFeature
	} bind def
/max {2 copy lt {exch} if pop} bind def
/min {2 copy gt {exch} if pop} bind def
/inch {72 mul} def
/pagedimen { 
	paperheight sub abs 16 lt exch 
	paperwidth sub abs 16 lt and
	{/papername exch def} {pop} ifelse
	} bind def
	/papersizedict FMLOCAL
/setpapername { 
	/papersizedict 14 dict def 
	papersizedict begin
	/papername /unknown def 
		/Letter 8.5 inch 11.0 inch pagedimen
		/LetterSmall 7.68 inch 10.16 inch pagedimen
		/Tabloid 11.0 inch 17.0 inch pagedimen
		/Ledger 17.0 inch 11.0 inch pagedimen
		/Legal 8.5 inch 14.0 inch pagedimen
		/Statement 5.5 inch 8.5 inch pagedimen
		/Executive 7.5 inch 10.0 inch pagedimen
		/A3 11.69 inch 16.5 inch pagedimen
		/A4 8.26 inch 11.69 inch pagedimen
		/A4Small 7.47 inch 10.85 inch pagedimen
		/B4 10.125 inch 14.33 inch pagedimen
		/B5 7.16 inch 10.125 inch pagedimen
	end
	} bind def
/papersize {
	papersizedict begin
		/Letter {lettertray letter} def
		/LetterSmall {lettertray lettersmall} def
		/Tabloid {11x17tray 11x17} def
		/Ledger {ledgertray ledger} def
		/Legal {legaltray legal} def
		/Statement {statementtray statement} def
		/Executive {executivetray executive} def
		/A3 {a3tray a3} def
		/A4 {a4tray a4} def
		/A4Small {a4tray a4small} def
		/B4 {b4tray b4} def
		/B5 {b5tray b5} def
		/unknown {unknown} def
	papersizedict dup papername known {papername} {/unknown} ifelse get
	end
	statusdict begin stopped end 
	} bind def
/manualpapersize {
	papersizedict begin
		/Letter {letter} def
		/LetterSmall {lettersmall} def
		/Tabloid {11x17} def
		/Ledger {ledger} def
		/Legal {legal} def
		/Statement {statement} def
		/Executive {executive} def
		/A3 {a3} def
		/A4 {a4} def
		/A4Small {a4small} def
		/B4 {b4} def
		/B5 {b5} def
		/unknown {unknown} def
	papersizedict dup papername known {papername} {/unknown} ifelse get
	end
	stopped 
	} bind def
/desperatepapersize {
	statusdict /setpageparams known
		{
		paperwidth paperheight 0 1 
		statusdict begin
		{setpageparams} stopped 
		end
		} {true} ifelse 
	} bind def
/DiacriticEncoding [
/.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef
/.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef
/.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef
/.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef
/.notdef /.notdef /.notdef /.notdef /space /exclam /quotedbl
/numbersign /dollar /percent /ampersand /quotesingle /parenleft
/parenright /asterisk /plus /comma /hyphen /period /slash /zero /one
/two /three /four /five /six /seven /eight /nine /colon /semicolon
/less /equal /greater /question /at /A /B /C /D /E /F /G /H /I /J /K
/L /M /N /O /P /Q /R /S /T /U /V /W /X /Y /Z /bracketleft /backslash
/bracketright /asciicircum /underscore /grave /a /b /c /d /e /f /g /h
/i /j /k /l /m /n /o /p /q /r /s /t /u /v /w /x /y /z /braceleft /bar
/braceright /asciitilde /.notdef /Adieresis /Aring /Ccedilla /Eacute
/Ntilde /Odieresis /Udieresis /aacute /agrave /acircumflex /adieresis
/atilde /aring /ccedilla /eacute /egrave /ecircumflex /edieresis
/iacute /igrave /icircumflex /idieresis /ntilde /oacute /ograve
/ocircumflex /odieresis /otilde /uacute /ugrave /ucircumflex
/udieresis /dagger /.notdef /cent /sterling /section /bullet
/paragraph /germandbls /registered /copyright /trademark /acute
/dieresis /.notdef /AE /Oslash /.notdef /.notdef /.notdef /.notdef
/yen /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef
/ordfeminine /ordmasculine /.notdef /ae /oslash /questiondown
/exclamdown /logicalnot /.notdef /florin /.notdef /.notdef
/guillemotleft /guillemotright /ellipsis /.notdef /Agrave /Atilde
/Otilde /OE /oe /endash /emdash /quotedblleft /quotedblright
/quoteleft /quoteright /.notdef /.notdef /ydieresis /Ydieresis
/fraction /currency /guilsinglleft /guilsinglright /fi /fl /daggerdbl
/periodcentered /quotesinglbase /quotedblbase /perthousand
/Acircumflex /Ecircumflex /Aacute /Edieresis /Egrave /Iacute
/Icircumflex /Idieresis /Igrave /Oacute /Ocircumflex /.notdef /Ograve
/Uacute /Ucircumflex /Ugrave /dotlessi /circumflex /tilde /macron
/breve /dotaccent /ring /cedilla /hungarumlaut /ogonek /caron
] def
/ReEncode { 
	dup 
	length 
	dict begin 
	{
	1 index /FID ne 
		{def} 
		{pop pop} ifelse 
	} forall 
	0 eq {/Encoding DiacriticEncoding def} if 
	currentdict 
	end 
	} bind def
FMPColor 
	
	{
	/BEGINBITMAPCOLOR { 
		BITMAPCOLOR} def
	/BEGINBITMAPCOLORc { 
		BITMAPCOLORc} def
	/BEGINBITMAPTRUECOLOR { 
		BITMAPTRUECOLOR } def
	/BEGINBITMAPTRUECOLORc { 
		BITMAPTRUECOLORc } def
	}
	
	{
	/BEGINBITMAPCOLOR { 
		BITMAPGRAY} def
	/BEGINBITMAPCOLORc { 
		BITMAPGRAYc} def
	/BEGINBITMAPTRUECOLOR { 
		BITMAPTRUEGRAY } def
	/BEGINBITMAPTRUECOLORc { 
		BITMAPTRUEGRAYc } def
	}
ifelse
/K { 
	FMPrintAllColorsAsBlack {
		dup 1 eq 2 index 1 eq and 3 index 1 eq and not
			{7 {pop} repeat 0 0 0 1 0 0 0} if
	} if 
	FrameCurColors astore 
	pop combineColor
} bind def
/graymode true def
	/bwidth FMLOCAL
	/bpside FMLOCAL
	/bstring FMLOCAL
	/onbits FMLOCAL
	/offbits FMLOCAL
	/xindex FMLOCAL
	/yindex FMLOCAL
	/x FMLOCAL
	/y FMLOCAL
/setPatternMode {
	FMLevel1 {
		/bwidth  exch def
		/bpside  exch def
		/bstring exch def
		/onbits 0 def  /offbits 0 def
		freq sangle landscape {90 add} if 
			{/y exch def
			 /x exch def
			 /xindex x 1 add 2 div bpside mul cvi def
			 /yindex y 1 add 2 div bpside mul cvi def
			 bstring yindex bwidth mul xindex 8 idiv add get
			 1 7 xindex 8 mod sub bitshift and 0 ne FrameNegative {not} if
			 {/onbits  onbits  1 add def 1}
			 {/offbits offbits 1 add def 0}
			 ifelse
			}
			setscreen
		offbits offbits onbits add div FrameNegative {1.0 exch sub} if
		/FrameCurGray exch def
	} { 
		pop pop
		dup patCache exch known {
			patCache exch get
		} { 
			dup
			patDict /bstring 3 -1 roll put
			patDict 
			9 PatFreq screenIndex get div dup matrix scale
			makepattern
			dup 
			patCache 4 -1 roll 3 -1 roll put
		} ifelse
		/FrameCurGray 0 def
		/FrameCurPat exch def
	} ifelse
	/graymode false def
	combineColor
} bind def
/setGrayScaleMode {
	graymode not {
		/graymode true def
		FMLevel1 {
			setCurrentScreen
		} if
	} if
	/FrameCurGray exch def
	combineColor
} bind def
/normalize {
	transform round exch round exch itransform
	} bind def
/dnormalize {
	dtransform round exch round exch idtransform
	} bind def
/lnormalize { 
	0 dtransform exch cvi 2 idiv 2 mul 1 add exch idtransform pop
	} bind def
/H { 
	lnormalize setlinewidth
	} bind def
/Z {
	setlinecap
	} bind def
	
/PFill {
	graymode FMLevel1 or not {
		gsave 1 setgray eofill grestore
	} if
} bind def
/PStroke {
	graymode FMLevel1 or not {
		gsave 1 setgray stroke grestore
	} if
	stroke
} bind def
	/fillvals FMLOCAL
/X { 
	fillvals exch get
	dup type /stringtype eq
	{8 1 setPatternMode} 
	{setGrayScaleMode}
	ifelse
	} bind def
/V { 
	PFill gsave eofill grestore
	} bind def
/Vclip {
	clip
	} bind def
/Vstrk {
	currentlinewidth exch setlinewidth PStroke setlinewidth
	} bind def
/N { 
	PStroke
	} bind def
/Nclip {
	strokepath clip newpath
	} bind def
/Nstrk {
	currentlinewidth exch setlinewidth PStroke setlinewidth
	} bind def
/M {newpath moveto} bind def
/E {lineto} bind def
/D {curveto} bind def
/O {closepath} bind def
	/n FMLOCAL
/L { 
 	/n exch def
	newpath
	normalize
	moveto 
	2 1 n {pop normalize lineto} for
	} bind def
/Y { 
	L 
	closepath
	} bind def
	/x1 FMLOCAL
	/x2 FMLOCAL
	/y1 FMLOCAL
	/y2 FMLOCAL
/R { 
	/y2 exch def
	/x2 exch def
	/y1 exch def
	/x1 exch def
	x1 y1
	x2 y1
	x2 y2
	x1 y2
	4 Y 
	} bind def
	/rad FMLOCAL
/rarc 
	{rad 
	 arcto
	} bind def
/RR { 
	/rad exch def
	normalize
	/y2 exch def
	/x2 exch def
	normalize
	/y1 exch def
	/x1 exch def
	mark
	newpath
	{
	x1 y1 rad add moveto
	x1 y2 x2 y2 rarc
	x2 y2 x2 y1 rarc
	x2 y1 x1 y1 rarc
	x1 y1 x1 y2 rarc
	closepath
	} stopped {x1 y1 x2 y2 R} if 
	cleartomark
	} bind def
/RRR { 
	/rad exch def
	normalize /y4 exch def /x4 exch def
	normalize /y3 exch def /x3 exch def
	normalize /y2 exch def /x2 exch def
	normalize /y1 exch def /x1 exch def
	newpath
	normalize moveto 
	mark
	{
	x2 y2 x3 y3 rarc
	x3 y3 x4 y4 rarc
	x4 y4 x1 y1 rarc
	x1 y1 x2 y2 rarc
	closepath
	} stopped
	 {x1 y1 x2 y2 x3 y3 x4 y4 newpath moveto lineto lineto lineto closepath} if
	cleartomark
	} bind def
/C { 
	grestore
	gsave
	R 
	clip
	setCurrentScreen
} bind def
/CP { 
	grestore
	gsave
	Y 
	clip
	setCurrentScreen
} bind def
	/FMpointsize FMLOCAL
/F { 
	FMfonts exch get
	FMpointsize scalefont
	setfont
	} bind def
/Q { 
	/FMpointsize exch def
	F 
	} bind def
/T { 
	moveto show
	} bind def
/RF { 
	rotate
	0 ne {-1 1 scale} if
	} bind def
/TF { 
	gsave
	moveto 
	RF
	show
	grestore
	} bind def
/P { 
	moveto
	0 32 3 2 roll widthshow
	} bind def
/PF { 
	gsave
	moveto 
	RF
	0 32 3 2 roll widthshow
	grestore
	} bind def
/S { 
	moveto
	0 exch ashow
	} bind def
/SF { 
	gsave
	moveto
	RF
	0 exch ashow
	grestore
	} bind def
/B { 
	moveto
	0 32 4 2 roll 0 exch awidthshow
	} bind def
/BF { 
	gsave
	moveto
	RF
	0 32 4 2 roll 0 exch awidthshow
	grestore
	} bind def
/G { 
	gsave
	newpath
	normalize translate 0.0 0.0 moveto 
	dnormalize scale 
	0.0 0.0 1.0 5 3 roll arc 
	closepath 
	PFill fill
	grestore
	} bind def
/Gstrk {
	savematrix
    newpath
    2 index 2 div add exch 3 index 2 div sub exch 
    normalize 2 index 2 div sub exch 3 index 2 div add exch 
    translate
    scale 
    0.0 0.0 1.0 5 3 roll arc 
    restorematrix
    currentlinewidth exch setlinewidth PStroke setlinewidth
    } bind def
/Gclip { 
	newpath
	savematrix
	normalize translate 0.0 0.0 moveto 
	dnormalize scale 
	0.0 0.0 1.0 5 3 roll arc 
	closepath 
	clip newpath
	restorematrix
	} bind def
/GG { 
	gsave
	newpath
	normalize translate 0.0 0.0 moveto 
	rotate 
	dnormalize scale 
	0.0 0.0 1.0 5 3 roll arc 
	closepath
	PFill
	fill
	grestore
	} bind def
/GGclip { 
	savematrix
	newpath
    normalize translate 0.0 0.0 moveto 
    rotate 
    dnormalize scale 
    0.0 0.0 1.0 5 3 roll arc 
    closepath
	clip newpath
	restorematrix
	} bind def
/GGstrk { 
	savematrix
    newpath
    normalize translate 0.0 0.0 moveto 
    rotate 
    dnormalize scale 
    0.0 0.0 1.0 5 3 roll arc 
    closepath 
	restorematrix
    currentlinewidth exch setlinewidth PStroke setlinewidth
	} bind def
/A { 
	gsave
	savematrix
	newpath
	2 index 2 div add exch 3 index 2 div sub exch 
	normalize 2 index 2 div sub exch 3 index 2 div add exch 
	translate 
	scale 
	0.0 0.0 1.0 5 3 roll arc 
	restorematrix
	PStroke
	grestore
	} bind def
/Aclip {
	newpath
	savematrix
	normalize translate 0.0 0.0 moveto 
	dnormalize scale 
	0.0 0.0 1.0 5 3 roll arc 
	closepath 
	strokepath clip newpath
	restorematrix
} bind def
/Astrk {
	Gstrk
} bind def
/AA { 
	gsave
	savematrix
	newpath
	
	3 index 2 div add exch 4 index 2 div sub exch 
	
	normalize 3 index 2 div sub exch 4 index 2 div add exch
	translate 
	rotate 
	scale 
	0.0 0.0 1.0 5 3 roll arc 
	restorematrix
	PStroke
	grestore
	} bind def
/AAclip {
	savematrix
	newpath
    normalize translate 0.0 0.0 moveto 
    rotate 
    dnormalize scale 
    0.0 0.0 1.0 5 3 roll arc 
    closepath
	strokepath clip newpath
	restorematrix
} bind def
/AAstrk {
	GGstrk
} bind def
	/x FMLOCAL
	/y FMLOCAL
	/w FMLOCAL
	/h FMLOCAL
	/xx FMLOCAL
	/yy FMLOCAL
	/ww FMLOCAL
	/hh FMLOCAL
	/FMsaveobject FMLOCAL
	/FMoptop FMLOCAL
	/FMdicttop FMLOCAL
/BEGINPRINTCODE { 
	/FMdicttop countdictstack 1 add def 
	/FMoptop count 7 sub def 
	/FMsaveobject save def
	userdict begin 
	/showpage {} def 
	FMNORMALIZEGRAPHICS 
	3 index neg 3 index neg translate
	} bind def
/ENDPRINTCODE {
	count -1 FMoptop {pop pop} for 
	countdictstack -1 FMdicttop {pop end} for 
	FMsaveobject restore 
	} bind def
/gn { 
	0 
	{	46 mul 
		cf read pop 
		32 sub 
		dup 46 lt {exit} if 
		46 sub add 
		} loop
	add 
	} bind def
	/str FMLOCAL
/cfs { 
	/str sl string def 
	0 1 sl 1 sub {str exch val put} for 
	str def 
	} bind def
/ic [ 
	0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0223
	0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0223
	0
	{0 hx} {1 hx} {2 hx} {3 hx} {4 hx} {5 hx} {6 hx} {7 hx} {8 hx} {9 hx}
	{10 hx} {11 hx} {12 hx} {13 hx} {14 hx} {15 hx} {16 hx} {17 hx} {18 hx}
	{19 hx} {gn hx} {0} {1} {2} {3} {4} {5} {6} {7} {8} {9} {10} {11} {12}
	{13} {14} {15} {16} {17} {18} {19} {gn} {0 wh} {1 wh} {2 wh} {3 wh}
	{4 wh} {5 wh} {6 wh} {7 wh} {8 wh} {9 wh} {10 wh} {11 wh} {12 wh}
	{13 wh} {14 wh} {gn wh} {0 bl} {1 bl} {2 bl} {3 bl} {4 bl} {5 bl} {6 bl}
	{7 bl} {8 bl} {9 bl} {10 bl} {11 bl} {12 bl} {13 bl} {14 bl} {gn bl}
	{0 fl} {1 fl} {2 fl} {3 fl} {4 fl} {5 fl} {6 fl} {7 fl} {8 fl} {9 fl}
	{10 fl} {11 fl} {12 fl} {13 fl} {14 fl} {gn fl}
	] def
	/sl FMLOCAL
	/val FMLOCAL
	/ws FMLOCAL
	/im FMLOCAL
	/bs FMLOCAL
	/cs FMLOCAL
	/len FMLOCAL
	/pos FMLOCAL
/ms { 
	/sl exch def 
	/val 255 def 
	/ws cfs 
	/im cfs 
	/val 0 def 
	/bs cfs 
	/cs cfs 
	} bind def
400 ms 
/ip { 
	is 
	0 
	cf cs readline pop 
	{	ic exch get exec 
		add 
		} forall 
	pop 
	
	} bind def
/rip { 
	   
	  
	  bis ris copy pop 
      is
      0
      cf cs readline pop 
      {       ic exch get exec 
              add 
              } forall 
	  pop pop 
	  ris gis copy pop 
	  dup is exch 
	  
      cf cs readline pop 
      {       ic exch get exec 
              add 
              } forall 
	  pop pop
	  gis bis copy pop 
	  dup add is exch 
	  
      cf cs readline pop 
      {       ic exch get exec 
              add 
              } forall 
      pop 
      
      } bind def
/wh { 
	/len exch def 
	/pos exch def 
	ws 0 len getinterval im pos len getinterval copy pop
	pos len 
	} bind def
/bl { 
	/len exch def 
	/pos exch def 
	bs 0 len getinterval im pos len getinterval copy pop
	pos len 
	} bind def
/s1 1 string def
/fl { 
	/len exch def 
	/pos exch def 
	/val cf s1 readhexstring pop 0 get def
	pos 1 pos len add 1 sub {im exch val put} for
	pos len 
	} bind def
/hx { 
	3 copy getinterval 
	cf exch readhexstring pop pop 
	} bind def
	/h FMLOCAL
	/w FMLOCAL
	/d FMLOCAL
	/lb FMLOCAL
	/bitmapsave FMLOCAL
	/is FMLOCAL
	/cf FMLOCAL
/wbytes { 
      dup dup
      24 eq { pop pop 3 mul }
      { 8 eq {pop} {1 eq {7 add 8 idiv} {3 add 4 idiv} ifelse} ifelse } ifelse
	} bind def
/BEGINBITMAPBWc { 
	1 {} COMMONBITMAPc
	} bind def
/BEGINBITMAPGRAYc { 
	8 {} COMMONBITMAPc
	} bind def
/BEGINBITMAP2BITc { 
	2 {} COMMONBITMAPc
	} bind def
/COMMONBITMAPc { 
		 
	/r exch def
	/d exch def
	gsave
	
	3 index 2 div add exch	
	4 index 2 div add exch	
	translate		
	rotate			
	1 index 2 div neg	
	1 index 2 div neg	
	translate		
	scale			
	/h exch def /w exch def
	/lb w d wbytes def 
	sl lb lt {lb ms} if 
	/bitmapsave save def 
	r                    
	/is im 0 lb getinterval def 
	ws 0 lb getinterval is copy pop 
	/cf currentfile def 
	w h d [w 0 0 h neg 0 h] 
	{ip} image 
	bitmapsave restore 
	grestore
	} bind def
/BEGINBITMAPBW { 
	1 {} COMMONBITMAP
	} bind def
/BEGINBITMAPGRAY { 
	8 {} COMMONBITMAP
	} bind def
/BEGINBITMAP2BIT { 
	2 {} COMMONBITMAP
	} bind def
/COMMONBITMAP { 
	/r exch def
	/d exch def
	gsave
	
	3 index 2 div add exch	
	4 index 2 div add exch	
	translate		
	rotate			
	1 index 2 div neg	
	1 index 2 div neg	
	translate		
	scale			
	/h exch def /w exch def
	/bitmapsave save def 
	r                    
	/is w d wbytes string def
	/cf currentfile def 
	w h d [w 0 0 h neg 0 h] 
	{cf is readhexstring pop} image
	bitmapsave restore 
	grestore
	} bind def
/ngrayt 256 array def
/nredt 256 array def
/nbluet 256 array def
/ngreent 256 array def
	/gryt FMLOCAL
	/blut FMLOCAL
	/grnt FMLOCAL
	/redt FMLOCAL
	/indx FMLOCAL
	/cynu FMLOCAL
	/magu FMLOCAL
	/yelu FMLOCAL
	/k FMLOCAL
	/u FMLOCAL
FMLevel1 {
/colorsetup {
	currentcolortransfer
	/gryt exch def
	/blut exch def
	/grnt exch def
	/redt exch def
	0 1 255 {
		/indx exch def
		/cynu 1 red indx get 255 div sub def
		/magu 1 green indx get 255 div sub def
		/yelu 1 blue indx get 255 div sub def
		/k cynu magu min yelu min def
		/u k currentundercolorremoval exec def
%		/u 0 def
		nredt indx 1 0 cynu u sub max sub redt exec put
		ngreent indx 1 0 magu u sub max sub grnt exec put
		nbluet indx 1 0 yelu u sub max sub blut exec put
		ngrayt indx 1 k currentblackgeneration exec sub gryt exec put
	} for
	{255 mul cvi nredt exch get}
	{255 mul cvi ngreent exch get}
	{255 mul cvi nbluet exch get}
	{255 mul cvi ngrayt exch get}
	setcolortransfer
	{pop 0} setundercolorremoval
	{} setblackgeneration
	} bind def
}
{
/colorSetup2 {
	[ /Indexed /DeviceRGB 255 
		{dup red exch get 255 div 
		 exch dup green exch get 255 div 
		 exch blue exch get 255 div}
	] setcolorspace
} bind def
} ifelse
	/tran FMLOCAL
/fakecolorsetup {
	/tran 256 string def
	0 1 255 {/indx exch def 
		tran indx
		red indx get 77 mul
		green indx get 151 mul
		blue indx get 28 mul
		add add 256 idiv put} for
	currenttransfer
	{255 mul cvi tran exch get 255.0 div}
	exch concatprocs settransfer
} bind def
/BITMAPCOLOR { 
	/d 8 def
	gsave
	
	3 index 2 div add exch	
	4 index 2 div add exch	
	translate		
	rotate			
	1 index 2 div neg	
	1 index 2 div neg	
	translate		
	scale			
	/h exch def /w exch def
	/bitmapsave save def
	FMLevel1 {	
		colorsetup
		/is w d wbytes string def
		/cf currentfile def 
		w h d [w 0 0 h neg 0 h] 
		{cf is readhexstring pop} {is} {is} true 3 colorimage 
	} {
		colorSetup2
		/is w d wbytes string def
		/cf currentfile def 
		7 dict dup begin
			/ImageType 1 def
			/Width w def
			/Height h def
			/ImageMatrix [w 0 0 h neg 0 h] def
			/DataSource {cf is readhexstring pop} bind def
			/BitsPerComponent d def
			/Decode [0 255] def
		end image	
	} ifelse
	bitmapsave restore 
	grestore
	} bind def
/BITMAPCOLORc { 
	/d 8 def
	gsave
	
	3 index 2 div add exch	
	4 index 2 div add exch	
	translate		
	rotate			
	1 index 2 div neg	
	1 index 2 div neg	
	translate		
	scale			
	/h exch def /w exch def
	/lb w d wbytes def 
	sl lb lt {lb ms} if 
	/bitmapsave save def 
	FMLevel1 {	
		colorsetup
		/is im 0 lb getinterval def 
		ws 0 lb getinterval is copy pop 
		/cf currentfile def 
		w h d [w 0 0 h neg 0 h] 
		{ip} {is} {is} true 3 colorimage
	} {
		colorSetup2
		/is im 0 lb getinterval def 
		ws 0 lb getinterval is copy pop 
		/cf currentfile def 
		7 dict dup begin
			/ImageType 1 def
			/Width w def
			/Height h def
			/ImageMatrix [w 0 0 h neg 0 h] def
			/DataSource {ip} bind def
			/BitsPerComponent d def
			/Decode [0 255] def
		end image	
	} ifelse
	bitmapsave restore 
	grestore
	} bind def
/BITMAPTRUECOLORc { 
	/d 24 def
        gsave
 	
	3 index 2 div add exch	
	4 index 2 div add exch	
	translate		
	rotate			
	1 index 2 div neg	
	1 index 2 div neg	
	translate		
	scale			
	/h exch def /w exch def
	/lb w d wbytes def 
	sl lb lt {lb ms} if 
        /bitmapsave save def 
        
	/is im 0 lb getinterval def	
	/ris im 0 w getinterval def	
	/gis im w w getinterval def	
	/bis im w 2 mul w getinterval def 
        
        ws 0 lb getinterval is copy pop 
        /cf currentfile def 
        w h 8 [w 0 0 h neg 0 h] 
        {w rip pop ris} {gis} {bis} true 3 colorimage
        bitmapsave restore 
        grestore
        } bind def
/BITMAPTRUECOLOR { 
        gsave
		
		3 index 2 div add exch	
		4 index 2 div add exch	
		translate		
		rotate			
		1 index 2 div neg	
		1 index 2 div neg	
		translate		
		scale			
		/h exch def /w exch def
        /bitmapsave save def 
        /is w string def
        /gis w string def
        /bis w string def
        /cf currentfile def 
        w h 8 [w 0 0 h neg 0 h] 
        { cf is readhexstring pop } 
        { cf gis readhexstring pop } 
        { cf bis readhexstring pop } 
        true 3 colorimage 
        bitmapsave restore 
        grestore
        } bind def
/BITMAPTRUEGRAYc { 
	/d 24 def
        gsave
	
	3 index 2 div add exch	
	4 index 2 div add exch	
	translate		
	rotate			
	1 index 2 div neg	
	1 index 2 div neg	
	translate		
	scale			
	/h exch def /w exch def
	/lb w d wbytes def 
	sl lb lt {lb ms} if 
        /bitmapsave save def 
        
	/is im 0 lb getinterval def	
	/ris im 0 w getinterval def	
	/gis im w w getinterval def	
	/bis im w 2 mul w getinterval def 
        ws 0 lb getinterval is copy pop 
        /cf currentfile def 
        w h 8 [w 0 0 h neg 0 h] 
        {w rip pop ris gis bis w gray} image
        bitmapsave restore 
        grestore
        } bind def
/ww FMLOCAL
/r FMLOCAL
/g FMLOCAL
/b FMLOCAL
/i FMLOCAL
/gray { 
        /ww exch def
        /b exch def
        /g exch def
        /r exch def
        0 1 ww 1 sub { /i exch def r i get .299 mul g i get .587 mul
			b i get .114 mul add add r i 3 -1 roll floor cvi put } for
        r
        } bind def
/BITMAPTRUEGRAY { 
        gsave
		
		3 index 2 div add exch	
		4 index 2 div add exch	
		translate		
		rotate			
		1 index 2 div neg	
		1 index 2 div neg	
		translate		
		scale			
		/h exch def /w exch def
        /bitmapsave save def 
        /is w string def
        /gis w string def
        /bis w string def
        /cf currentfile def 
        w h 8 [w 0 0 h neg 0 h] 
        { cf is readhexstring pop 
          cf gis readhexstring pop 
          cf bis readhexstring pop w gray}  image
        bitmapsave restore 
        grestore
        } bind def
/BITMAPGRAY { 
	8 {fakecolorsetup} COMMONBITMAP
	} bind def
/BITMAPGRAYc { 
	8 {fakecolorsetup} COMMONBITMAPc
	} bind def
/ENDBITMAP {
	} bind def
end 
	/ALDsave FMLOCAL
	/ALDmatrix matrix def ALDmatrix currentmatrix pop
/StartALD {
	/ALDsave save def
	 savematrix
	 ALDmatrix setmatrix
	} bind def
/InALD {
	 restorematrix
	} bind def
/DoneALD {
	 ALDsave restore
	} bind def
/I { setdash } bind def
/J { [] 0 setdash } bind def
%%EndProlog
%%BeginSetup
(4.0) FMVERSION
1 1 0 0 612 792 0 1 38 FMDOCUMENT
0 0 /Helvetica FMFONTDEFINE
1 0 /Times-Roman FMFONTDEFINE
2 0 /Times-Bold FMFONTDEFINE
3 0 /Times-Italic FMFONTDEFINE
4 0 /Courier FMFONTDEFINE
5 0 /Courier-Bold FMFONTDEFINE
6 1 /Symbol FMFONTDEFINE
7 0 /Courier-Oblique FMFONTDEFINE
8 0 /Helvetica-Oblique FMFONTDEFINE
32 FMFILLS
0 0 FMFILL
1 0.1 FMFILL
2 0.3 FMFILL
3 0.5 FMFILL
4 0.7 FMFILL
5 0.9 FMFILL
6 0.97 FMFILL
7 1 FMFILL
8 <0f1e3c78f0e1c387> FMFILL
9 <0f87c3e1f0783c1e> FMFILL
10 <cccccccccccccccc> FMFILL
11 <ffff0000ffff0000> FMFILL
12 <8142241818244281> FMFILL
13 <03060c183060c081> FMFILL
14 <8040201008040201> FMFILL
16 1 FMFILL
17 0.9 FMFILL
18 0.7 FMFILL
19 0.5 FMFILL
20 0.3 FMFILL
21 0.1 FMFILL
22 0.03 FMFILL
23 0 FMFILL
24 <f0e1c3870f1e3c78> FMFILL
25 <f0783c1e0f87c3e1> FMFILL
26 <3333333333333333> FMFILL
27 <0000ffff0000ffff> FMFILL
28 <7ebddbe7e7dbbd7e> FMFILL
29 <fcf9f3e7cf9f3f7e> FMFILL
30 <7fbfdfeff7fbfdfe> FMFILL
%%EndSetup
%%Page: "1" 1
%%BeginPaperSize: Letter
%%EndPaperSize
612 792 0 FMBEGINPAGE
[0 0 0 1 0 0 0]
[ 0 1 1 0 1 0 0]
[ 1 0 1 0 0 1 0]
[ 1 1 0 0 0 0 1]
[ 1 0 0 0 0 1 1]
[ 0 1 0 0 1 0 1]
[ 0 0 1 0 1 1 0]
 7 FrameSetSepColors
FrameNoSep
0 0 0 1 0 0 0 K
J
0 0 0 1 0 0 0 K
54 67.5 294.12 81 R
7 X
0 0 0 1 0 0 0 K
V
0 0 0 1 0 0 0 K
0 0 0 1 0 0 0 K
54 27 558 45 R
V
0 0 0 1 0 0 0 K
0 0 0 1 0 0 0 K
54 666 558 738 R
V
0 16 Q
0 X
(Annotation-Directed Run-T) 130.24 727.33 T
(ime Specialization in C) 319.94 727.33 T
0 12 Q
(Brian Grant, Markus Mock, Matthai Philipose, Craig Chambers, and Susan J. Eggers) 81.25 700.5 T
1 10 Q
(Department of Computer Science and Engineering) 204.77 681.33 T
(University of Washington) 254.06 669.33 T
54 144 294.12 648 R
7 X
V
2 F
0 X
(Abstract) 54 641.33 T
1 9 Q
1.61 (W) 54 625.4 P
1.61 (e present the design of a dynamic compilation system for C.) 61.78 625.4 P
1.15 (Directed by a few declarative user annotations specifying where) 54 615.4 P
0.47 (and on what dynamic compilation is to take place, a binding time) 54 605.4 P
1.1 (analysis computes the set of run-time constants at each program) 54 595.4 P
-0.4 (point in each annotated procedure\325) 54 585.4 P
-0.4 (s control \337ow graph; the analysis) 176.87 585.4 P
8.78 (supports program-point-speci\336c polyvariant division and) 54 575.4 P
2.11 (specialization. The analysis results guide the construction of a) 54 565.4 P
2.03 (specialized run-time specializer for each dynamically compiled) 54 555.4 P
2.85 (region; the specializer supports various caching strategies for) 54 545.4 P
2.84 (managing dynamically generated code and supports mixes of) 54 535.4 P
1.03 (speculative and demand-driven specialization of dynamic branch) 54 525.4 P
0.87 (successors. Most of the key cost/bene\336t trade-of) 54 515.4 P
0.87 (fs in the binding) 232.76 515.4 P
0.32 (time analysis and the run-time specializer are open to user control) 54 505.4 P
3.88 (through declarative policy annotations. Our design is being) 54 495.4 P
(implemented in the context of an existing optimizing compiler) 54 485.4 T
(.) 278.5 485.4 T
2 12 Q
(1) 54 462.8 T
(Intr) 72 462.8 T
(oduction) 92.45 462.8 T
1 9 Q
1.44 (Dynamic compilation of) 54 446.2 P
1.44 (fers the potential for increased program) 144.71 446.2 P
0.33 (performance by delaying some parts of program compilation until) 54 436.2 P
2.77 (run time and then exploiting run-time state to generate code) 54 426.2 P
-0.51 (specialized to actual run-time behavior) 54 416.2 P
-0.51 (. The principal challenge and) 191.43 416.2 P
4.88 (trade-of) 54 406.2 P
4.88 (f in dynamic compilation is achieving high-quality) 82.32 406.2 P
0.09 (dynamically generated code at low run-time cost, since the time to) 54 396.2 P
0.2 (perform run-time compilation and optimization must be recovered) 54 386.2 P
1.99 (before any bene\336t from dynamic compilation can be obtained.) 54 376.2 P
3.21 (Consequently) 54 366.2 P
3.21 (, a key design issue in developing an ef) 102.92 366.2 P
3.21 (fective) 269.63 366.2 P
0.11 (dynamic compilation system is the method for determining where,) 54 356.2 P
0.88 (when, and on what run-time state to apply dynamic compilation.) 54 346.2 P
0.04 (Ideally) 54 336.2 P
0.04 (, the compiler would make these decisions automatically) 78.41 336.2 P
0.04 (, as) 282.08 336.2 P
0.44 (in other compiler optimizations; however) 54 326.2 P
0.44 (, this ideal is beyond the) 204.4 326.2 P
(current state-of-the-art for general-purpose programs.) 54 316.2 T
-0.37 (Instead, current dynamic compilation systems rely on some form of) 54 301.6 P
3.11 (programmer direction to indicate where dynamic compilation) 54 291.6 P
4.23 (would most pro\336tably be applied. Some previous dynamic) 54 281.6 P
-0.07 (compilation systems, such as `C [Engler) 54 271.6 P
3 F
-0.07 (et al.) 200.8 271.6 P
1 F
-0.07 ( 96, Poletto) 218.73 271.6 P
3 F
-0.07 (et al.) 262.02 271.6 P
1 F
-0.07 ( 97]) 279.95 271.6 P
3.77 (and its predecessor) 54 261.6 P
4 F
9.06 (dcg) 136.05 261.6 P
1 F
3.77 ( [Engler & Proebsting 94], take a) 152.25 261.6 P
0.85 (procedural approach to user direction, requiring the user to write) 54 251.6 P
4.44 (programs that explicitly manipulate, compose, and compile) 54 241.6 P
1.11 (program fragments at run time. This kind of system of) 54 231.6 P
1.11 (fers great) 259.28 231.6 P
0.27 (\337exibility and control to the programmer) 54 221.6 P
0.27 (, at the cost of signi\336cant) 202.25 221.6 P
(programmer ef) 54 211.6 T
(fort and debugging dif) 107.57 211.6 T
(\336culty) 188.15 211.6 T
(.) 210.56 211.6 T
3.09 (Alternatively) 54 197 P
3.09 (, several dynamic compilation systems, including) 100.91 197 P
-0.27 (Fabius [Leone & Lee 96], T) 54 187 P
-0.27 (empo [Consel & No\221l 96], and our own) 153.01 187 P
0.02 (previous system [Auslander) 54 177 P
3 F
0.02 (et al.) 156.79 177 P
1 F
0.02 ( 96], take a declarative approach,) 174.82 177 P
1.45 (with user annotations guiding the dynamic compilation process.) 54 167 P
0.79 (Fabius uses function currying to drive dynamic compilation, in a) 54 157 P
4 (purely functional subset of ML; T) 54 147 P
4 (empo uses function-level) 195.63 147 P
317.88 67.5 558 648 R
7 X
V
0 X
1.34 (annotations, annotations on global variables and structure types,) 317.88 642 P
1.91 (and alias analysis to drive dynamic compilation in C; and our) 317.88 632 P
-0.01 (previous system uses intraprocedural annotations to drive dynamic) 317.88 622 P
-0.43 (compilation in C. Each of these declarative approaches adapts ideas) 317.88 612 P
-0.38 (from partial evaluation, expressing dynamic compilation as of) 317.88 602 P
-0.38 (f-line) 538.51 602 P
-0.05 (run-time specialization, where static values correspond to run-time) 317.88 592 P
1.1 (state on which programs are specialized. Declarative approaches) 317.88 582 P
0.23 (of) 317.88 572 P
0.23 (fer the advantages of an easier interface to dynamic compilation) 325.21 572 P
-0.1 (for the programmer \050since dynamic optimizations are derived from) 317.88 562 P
1.39 (the annotations automatically) 317.88 552 P
1.39 (, rather than being programmed by) 426.07 552 P
1.09 (hand by the programmer\051 and easier program understanding and) 317.88 542 P
1.27 (debugging \050since declarative annotations can be designed to not) 317.88 532 P
4.35 (af) 317.88 522 P
4.35 (fect the meaning of the underlying programs\051. However) 324.71 522 P
4.35 (,) 555.75 522 P
1.08 (declarative systems usually of) 317.88 512 P
1.08 (fer less expressiveness and control) 429.2 512 P
(over the dynamic compilation process than do imperative systems.) 317.88 502 T
1.8 (W) 317.88 488.35 P
1.8 (e have developed a new declarative annotation language and) 325.66 488.35 P
4.61 (underlying run-time specialization primitives that are more) 317.88 478.35 P
2.28 (expressive, \337exible, and controllable than previous annotation-) 317.88 468.35 P
0.61 (based systems, while still being easy to use. Our system supports) 317.88 458.35 P
(the following features:) 317.88 448.35 T
(\245) 325.08 435.7 T
4.82 (program-point-speci\336c rather than function-level special-) 332.28 435.7 P
(ization,) 332.28 425.7 T
(\245) 325.08 413.04 T
2.38 (support for both polyvariant specialization and polyvariant) 332.28 413.04 P
-0.15 (division) 332.28 403.04 P
1 7.2 Q
-0.12 (*) 361.29 406.64 P
1 9 Q
-0.15 ( \050both of which have practical utility\051, with the degree) 364.89 403.04 P
2.74 (of specialization for dif) 332.28 393.04 P
2.74 (ferent variables under programmer) 424.57 393.04 P
(control,) 332.28 383.04 T
(\245) 325.08 370.39 T
0.11 (intra- and interprocedural specialization, with caller and callee) 332.28 370.39 P
(separately compilable,) 332.28 360.39 T
(\245) 325.08 347.74 T
3.96 (arbitrary nested and overlapping regions of dynamically) 332.28 347.74 P
(generated code,) 332.28 337.74 T
(\245) 325.08 325.09 T
2.96 (automatic caching, reuse, and reclamation of dynamically) 332.28 325.09 P
3.07 (generated code, with cache policies under control of the) 332.28 315.09 P
(programmer) 332.28 305.09 T
(,) 376.41 305.09 T
(\245) 325.08 292.43 T
-0.37 (automatic interleaving of specialization and dynamic execution) 332.28 292.43 P
4.12 (to avoid unbounded static specialization for terminating) 332.28 282.43 P
4.7 (programs, with the exact trade-of) 332.28 272.43 P
4.7 (f between speculative) 470.63 272.43 P
7.44 (specialization and demand-driven specialization under) 332.28 262.43 P
(programmer control,) 332.28 252.43 T
(\245) 325.08 239.78 T
-0.37 (automatic interleaving of specialization and dynamic execution) 332.28 239.78 P
0.28 (to delay specialization of some code until the appropriate run-) 332.28 229.78 P
(time values have been computed,) 332.28 219.78 T
(\245) 325.08 207.13 T
6.31 (run-time optimizations, including constant propagation,) 332.28 207.13 P
-0.38 (constant folding, strength reduction, conditional branch folding) 332.28 197.13 P
0.17 (and dead code elimination, loop unrolling and mer) 332.28 187.13 P
0.17 (ge splitting,) 515.32 187.13 P
(and procedure call specialization.) 332.28 177.13 T
0.37 (The next section illustrates many of the capabilities of our system) 317.88 163.48 P
3.88 (using an annotated bytecode interpreter example. Section 3) 317.88 153.48 P
1.74 (describes our run-time specializer and its capabilities, and then) 317.88 143.48 P
0.24 (sections 4 through 6 present our annotation language, our analysis) 317.88 133.48 P
0.57 (to compute program-point-speci\336c information, and our approach) 317.88 123.48 P
317.88 105.5 558 120.48 C
0 0 0 1 0 0 0 K
0 0 0 1 0 0 0 K
317.88 105.5 558 120.48 R
7 X
0 0 0 1 0 0 0 K
V
317.88 111.41 470.88 111.41 2 L
V
0.5 H
2 Z
0 X
N
0 0 612 792 C
1 6.4 Q
0 X
0 0 0 1 0 0 0 K
(*) 317.88 103.37 T
1 8 Q
0.96 (Polyvariant division allows the same program point to be analyzed for) 323.56 100.17 P
-0.32 (different combinations of variables being treated as static, and polyvariant) 323.56 91.17 P
2.08 (specialization allows multiple compiled versions of a division to be) 323.56 82.17 P
(produced, each specialized for different values of the static variables.) 323.56 73.17 T
0 0 0 1 0 0 0 K
FMENDPAGE
%%EndPage: "1" 1
%%Page: "2" 2
612 792 0 FMBEGINPAGE
[0 0 0 1 0 0 0]
[ 0 1 1 0 1 0 0]
[ 1 0 1 0 0 1 0]
[ 1 1 0 0 0 0 1]
[ 1 0 0 0 0 1 1]
[ 0 1 0 0 1 0 1]
[ 0 0 1 0 1 1 0]
 7 FrameSetSepColors
FrameNoSep
0 0 0 1 0 0 0 K
54 26 558 44 R
7 X
0 0 0 1 0 0 0 K
V
0 0 0 1 0 0 0 K
0 0 0 1 0 0 0 K
54 72 294.12 738 R
V
1 9 Q
0 X
-0.42 (to producing an \050optimized\051 run-time specializer from the program-) 54 174 P
1.62 (point-speci\336c information, respectively) 54 164 P
1.62 (. Section 7 compares our) 198.39 164 P
0.15 (system to related work, and section 8 concludes with our plans for) 54 154 P
(future work.) 54 144 T
2 12 Q
(2) 54 121.5 T
(Example) 72 121.5 T
1 9 Q
0.67 (Figure 1 presents a simple interpreter of a bytecode program like) 54 105 P
2.01 (those in the Smalltalk and Java virtual machines [Goldber) 54 95 P
2.01 (g &) 278.36 95 P
-0.15 (Robson 83, Lindholm & Y) 54 85 P
-0.15 (ellin 97]. In boldface are the annotations) 149.28 85 P
-0.15 (we added to turn the interpreter into a program that produces at run) 54 75 P
54 180 306 738 C
0 0 0 1 0 0 0 K
0 0 0 1 0 0 0 K
54 75.61 300.9 738 R
7 X
0 0 0 1 0 0 0 K
V
4 8 Q
0 X
(void interp_program\050int bytecodes[], int arg\051 {) 54 732.67 T
(printf\050\322%d\134n\323, interp_fn\050bytecodes, 0, arg\051\051;) 61.2 724.67 T
(}) 54 716.67 T
(int interp_fn\050int bytecodes[], int pc, int arg\051 {) 54 699.67 T
(int stack[N], sp = 0;) 61.2 691.67 T
5 F
(make_static\050bytecodes, pc, sp\051;) 61.2 683.67 T
4 F
(stack[sp++] = arg;) 61.2 675.67 T
(for\050;;\051 {) 61.2 667.67 T
(switch \050bytecodes) 68.4 659.67 T
5 F
(static) 154.8 659.67 T
4 F
([pc++]\051 {) 183.6 659.67 T
(case CONST:) 75.6 651.67 T
(stack[sp++] = bytecodes) 82.8 643.67 T
5 F
(static) 198 643.67 T
4 F
([pc++];) 226.8 643.67 T
(break;) 82.8 635.67 T
(case ADD:) 75.6 627.67 T
(stack[sp-1] = stack[sp-1] + stack[sp]; sp--;) 82.8 619.67 T
(break;) 82.8 611.67 T
(...) 75.6 603.67 T
(case LT:) 75.6 595.67 T
(stack[sp-1] = stack[sp-1] < stack[sp]; sp--;) 82.8 587.67 T
(break;) 82.8 579.67 T
(...) 75.6 571.67 T
(case IF_GOTO:) 75.6 563.67 T
(int nextpc = bytecodes) 82.8 555.67 T
5 F
(static) 193.2 555.67 T
4 F
([pc++];) 222 555.67 T
(if \050stack[sp--]\051 {) 82.8 547.67 T
(pc = nextpc;) 90 539.67 T
(}) 82.8 531.67 T
(break;) 82.8 523.67 T
(case GOTO:) 75.6 515.67 T
(pc = bytecodes) 82.8 507.67 T
5 F
(static) 154.8 507.67 T
4 F
([pc++];) 183.6 507.67 T
(break;) 82.8 499.67 T
(case COMPUTED_GOTO:) 75.6 491.67 T
(pc = stack[sp--];) 82.8 483.67 T
(break;) 82.8 475.67 T
(...) 75.6 467.67 T
(case RETURN:) 75.6 459.67 T
(return stack[sp];) 82.8 451.67 T
(}) 68.4 443.67 T
(}) 61.2 435.67 T
(}) 54 427.67 T
2 10 Q
(Figur) 96.53 410.33 T
(e 1: Simple Interpr) 120.24 410.33 T
(eter Example) 201.44 410.33 T
4 8 Q
(int count[N];) 54 387.67 T
(#define threshold ...) 54 379.17 T
5 F
(specialize interp_fn\050bytecodes, pc, arg\051) 54 370.67 T
(on \050bytecodes, pc\051;) 61.2 362.67 T
4 F
(int interp_fn\050int bytecodes[], int pc, int arg\051 {) 54 354.17 T
(int stack[N], sp = 0;) 61.2 346.17 T
(if \050++count[pc] >= threshold\051 {) 61.2 338.17 T
5 F
(make_static\050bytecodes, pc, sp\051;) 68.4 330.17 T
4 F
(} else {) 61.2 322.17 T
5 F
(make_dynamic\050bytecodes, pc, sp\051;) 68.4 314.17 T
4 F
(}) 61.2 306.17 T
(stack[sp++] = arg;) 61.2 298.17 T
(for\050;;\051 {) 61.2 290.17 T
(switch \050bytecodes) 68.4 282.17 T
5 F
(static) 154.8 282.17 T
4 F
([pc++]\051 {) 183.6 282.17 T
(... /* same as above */) 75.6 274.17 T
(case GOSUB:) 75.6 266.17 T
(callee = bytecodes) 82.8 258.17 T
5 F
(static) 174 258.17 T
4 F
([pc++];) 202.8 258.17 T
(stack[sp] =) 82.8 250.17 T
(interp_fn\050bytecodes, callee, stack[sp]\051;) 90 242.17 T
(break;) 82.8 233.67 T
(}) 68.4 225.67 T
(}) 61.2 217.67 T
(}) 54 209.67 T
2 10 Q
(Figur) 55.54 192.34 T
(e 2: Interpr) 79.25 192.34 T
(ocedural and Conditional Specialization) 128.5 192.34 T
0 0 612 792 C
317.88 72 558 738 R
7 X
0 0 0 1 0 0 0 K
V
1 9 Q
0 X
-0.26 (time an interpreter specialized for the particular array of bytecodes,) 317.88 732 P
(i.e., a run-time compiler) 317.88 722 T
(.) 404.37 722 T
0.63 (The main control annotation is) 317.88 708.74 P
4 F
1.51 (make_static) 433.77 708.74 P
1 F
0.63 (, whose ar) 493.17 708.74 P
0.63 (gument) 531 708.74 P
0.67 (list of variables the system is to treat as) 317.88 698.74 P
3 F
0.67 (run-time constants) 467.66 698.74 P
1 F
0.67 ( when) 535.58 698.74 P
0.54 (run-time execution reaches that point. By default, the system will) 317.88 688.74 P
2.33 (apply polyvariant division and specialization as needed on all) 317.88 678.74 P
0.17 (control-\337ow paths downstream of the) 317.88 668.74 P
4 F
0.4 (make_static) 455.94 668.74 P
1 F
0.17 ( annotation,) 515.34 668.74 P
-0.26 (until the variables go out of scope, in order to preserve the run-time) 317.88 658.74 P
0.18 (constant bindings of each annotated variable. For example, the) 317.88 648.74 P
4 F
0.43 (pc) 547.2 648.74 P
1 F
0.54 (variable is annotated as static. The system will specialize code so) 317.88 638.74 P
-0.03 (that, at each program point in the specialized code, the) 317.88 628.74 P
4 F
-0.08 (pc) 515.99 628.74 P
1 F
-0.03 ( variable) 526.79 628.74 P
0.36 (will have a known run-time constant value. The increments of) 317.88 618.74 P
4 F
0.87 (pc) 547.2 618.74 P
1 F
0.1 (in the) 317.88 608.74 P
4 F
0.24 (switch) 340.58 608.74 P
1 F
0.1 ( body do not cause problems, since the value of) 372.98 608.74 P
4 F
0.24 (pc) 547.2 608.74 P
1 F
-0.07 (after the increment is a run-time constant, if the value of) 317.88 598.74 P
4 F
-0.17 (pc) 522.04 598.74 P
1 F
-0.07 ( before) 532.84 598.74 P
-0 (the increment is. The loop head at the top of the) 317.88 588.74 P
4 F
-0.01 (for) 492.32 588.74 P
1 F
-0 ( loop requires) 508.52 588.74 P
0.33 (additional work: our system will automatically produce a separate) 317.88 578.74 P
-0.3 (specialized version of the loop body for each distinct value of) 317.88 568.74 P
4 F
-0.73 (pc) 538.76 568.74 P
1 F
-0.3 ( at) 549.55 568.74 P
(the loop head, in ef) 317.88 558.74 T
(fect unrolling the loop fully) 386.95 558.74 T
(.) 485.86 558.74 T
0.32 (The references to the contents of the bytecode array are annotated) 317.88 545.49 P
1.19 (as static references, implying that the contents of the referenced) 317.88 535.49 P
1.88 (memory location is a run-time constant if its address is.) 317.88 525.49 P
1 7.2 Q
1.5 (*) 534.27 529.09 P
1 9 Q
1.88 ( This) 537.87 525.49 P
0.43 (enables the system to constant-fold the switch branch within each) 317.88 515.49 P
-0.39 (iteration \050since) 317.88 505.49 P
4 F
-0.93 (bytecodes) 373.09 505.49 P
1 F
-0.39 ( and) 421.69 505.49 P
4 F
-0.93 (pc) 438.41 505.49 P
1 F
-0.39 ( are run-time constants and the) 449.21 505.49 P
-0.26 (loaded bytecode is a run-time constant\051, selecting just one case arm) 317.88 495.49 P
0.79 (in each iteration and eliminating the others as dead code. All the) 317.88 485.49 P
0.56 (code manipulating the) 317.88 475.49 P
4 F
1.33 (bytecodes) 401.79 475.49 P
1 F
0.56 ( array and the) 450.39 475.49 P
4 F
1.33 (pc) 504.09 475.49 P
1 F
0.56 ( value itself) 514.89 475.49 P
-0.01 (are also eliminated as dead, once all the interpretation overhead on) 317.88 465.49 P
3.1 (these data values is constant-folded away) 317.88 455.49 P
3.1 (. Similarly) 481.53 455.49 P
3.1 (, at each) 522.06 455.49 P
1.51 (program point in the unrolled loop the) 317.88 445.49 P
4 F
3.62 (sp) 468.18 445.49 P
1 F
1.51 ( variable will have a) 478.98 445.49 P
2.08 (speci\336c run-time constant value, and so all the references and) 317.88 435.49 P
1.62 (updates to) 317.88 425.49 P
4 F
3.9 (sp) 360.12 425.49 P
1 F
1.62 ( will be eliminated as dead code, once the index) 370.92 425.49 P
0.05 (expressions into the) 317.88 415.49 P
4 F
0.12 (stack) 391.77 415.49 P
1 F
0.05 ( array are replaced with particular run-) 418.77 415.49 P
-0.12 (time constant values. The contents of the) 317.88 405.49 P
4 F
-0.29 (stack) 466.51 405.49 P
1 F
-0.12 ( array are not run-) 493.51 405.49 P
2.72 (time constants, as they depend on the initial) 317.88 395.49 P
4 F
6.53 (arg) 499.37 395.49 P
1 F
2.72 ( value and) 515.57 395.49 P
(subsequent input program execution.) 317.88 385.49 T
1.88 (The) 317.88 372.23 P
4 F
4.51 (IF_GOTO) 336.01 372.23 P
1 F
1.88 ( bytecode rebinds the value of) 373.81 372.23 P
4 F
4.51 (pc) 495.57 372.23 P
1 F
1.88 ( conditionally) 506.37 372.23 P
0.61 (based on the run-time variable outcome of a previous test. At the) 317.88 362.23 P
1.43 (mer) 317.88 352.23 P
1.43 (ge after the) 331.71 352.23 P
4 F
3.43 (if) 378.73 352.23 P
1 F
1.43 (,) 389.53 352.23 P
4 F
3.43 (pc) 395.46 352.23 P
1 F
1.43 ( may hold one of two possible run-time) 406.26 352.23 P
1.73 (constant values, depending on which) 317.88 342.23 P
4 F
4.16 (if) 461.53 342.23 P
1 F
1.73 ( arm was selected. By) 472.33 342.23 P
1.06 (default, because) 317.88 332.23 P
4 F
2.54 (pc) 380.22 332.23 P
1 F
1.06 ( is annotated as) 391.02 332.23 P
4 F
2.54 (make_static) 452.74 332.23 P
1 F
1.06 (, our system) 512.14 332.23 P
4.41 (will apply polyvariant specialization to the mer) 317.88 322.23 P
4.41 (ge and all) 514.18 322.23 P
0.09 (downstream code, making potentially two copies of the mer) 317.88 312.23 P
0.09 (ge and) 534.17 312.23 P
-0.4 (successors, one copy for each run-time constant value of) 317.88 302.23 P
4 F
-0.95 (pc) 520.25 302.23 P
1 F
-0.4 (. For an) 531.05 302.23 P
2.64 (input program containing a tree of) 317.88 292.23 P
4 F
6.33 (IF_GOTO) 459.18 292.23 P
1 F
2.64 ( bytecodes, this) 496.98 292.23 P
2.65 (specialization will produce a tree of unrolled interpreter loop) 317.88 282.23 P
-0.37 (iterations, re\337ecting the expected structure of a compiled version of) 317.88 272.23 P
0.03 (the input program. W) 317.88 262.23 P
0.03 (e call the ability to perform more than simple) 394.75 262.23 P
1.09 (linear unrollings of loops) 317.88 252.23 P
3 F
1.09 (multi-way loop unr) 415.23 252.23 P
1.09 (olling) 486.07 252.23 P
1 F
1.09 (. \050Our system) 507.08 252.23 P
1.63 (allows the programmer to specify less aggressive specialization) 317.88 242.23 P
0.68 (policies for static variables, to provide programmers \336ner control) 317.88 232.23 P
0.87 (over the trade-of) 317.88 222.23 P
0.87 (fs between run-time specialization overhead and) 379.44 222.23 P
(run-time specialization bene\336t.\051) 317.88 212.23 T
0.17 (At each of these) 317.88 198.98 P
3 F
0.17 (specializable mer) 379.05 198.98 P
0.17 (ge points) 442.14 198.98 P
1 F
0.17 (, by default our system) 475.06 198.98 P
1.35 (will maintain a cache of all the previously specialized versions,) 317.88 188.98 P
0.98 (indexed by the values of the static variables at that mer) 317.88 178.98 P
0.98 (ge point.) 525.52 178.98 P
1.44 (When encountering a specializable mer) 317.88 168.98 P
1.44 (ge point during run-time) 465.43 168.98 P
-0.11 (specialization, the cache will be examined to see whether a version) 317.88 158.98 P
0.97 (of that code has already been produced, and, if so, that previous) 317.88 148.98 P
-0.18 (version will be reused. In the interpreter example, the cache checks) 317.88 138.98 P
1.45 (at the loop head mer) 317.88 128.98 P
1.45 (ge have the ef) 397.01 128.98 P
1.45 (fect of connecting backward) 451.43 128.98 P
3.82 (branch bytecodes directly to previously generated iterations,) 317.88 118.98 P
317.88 101 558 115.98 C
0 0 0 1 0 0 0 K
0 0 0 1 0 0 0 K
317.88 101 558 115.98 R
7 X
0 0 0 1 0 0 0 K
V
317.88 106.91 470.88 106.91 2 L
V
0.5 H
2 Z
0 X
N
0 0 612 792 C
1 6.4 Q
0 X
0 0 0 1 0 0 0 K
(*) 317.88 98.87 T
1 8 Q
1.76 (Our system currently does no automatic alias or side-effect analysis,) 323.56 95.67 P
0.18 (unlike some other systems, so these annotations are necessary to achieve) 323.56 86.67 P
(the desired effect.) 323.56 77.67 T
0 0 0 1 0 0 0 K
FMENDPAGE
%%EndPage: "2" 2
%%Page: "3" 3
612 792 0 FMBEGINPAGE
[0 0 0 1 0 0 0]
[ 0 1 1 0 1 0 0]
[ 1 0 1 0 0 1 0]
[ 1 1 0 0 0 0 1]
[ 1 0 0 0 0 1 1]
[ 0 1 0 0 1 0 1]
[ 0 0 1 0 1 1 0]
 7 FrameSetSepColors
FrameNoSep
0 0 0 1 0 0 0 K
54 26 558 44 R
7 X
0 0 0 1 0 0 0 K
V
0 0 0 1 0 0 0 K
0 0 0 1 0 0 0 K
54 72 294.12 738 R
V
1 9 Q
0 X
0.64 (forming loops in the specialized code as desired, and similarly to) 54 732 P
1.99 (introduce sharing of iterations if there exist other control \337ow) 54 722 P
0.2 (mer) 54 712 P
0.2 (ge points in the input interpreted program. \050Our system allows) 67.83 712 P
-0.06 (the programmer to specify alternative caching policies or even that) 54 702 P
3.49 (no caching should be used, to provide \336ner control to the) 54 692 P
(programmer over this potentially expensive primitive.\051) 54 682 T
2.21 (The) 54 668.6 P
4 F
5.3 (COMPUTED_GOTO) 72.45 668.6 P
1 F
2.21 ( bytecode assigns the) 142.65 668.6 P
4 F
5.3 (pc) 229.96 668.6 P
1 F
2.21 ( variable to a) 240.76 668.6 P
0.27 (dynamic expression. By default, our system will suspend program) 54 658.6 P
0.09 (specialization until run-time execution reaches that program point,) 54 648.6 P
1.88 (at which point the system will resume specialization using the) 54 638.6 P
1.46 (actual value assigned to) 54 628.6 P
4 F
3.5 (pc) 147.82 628.6 P
1 F
1.46 ( at that point. As with specializable) 158.62 628.6 P
0.42 (mer) 54 618.6 P
0.42 (ge points, each such) 67.83 618.6 P
3 F
0.42 (dynamic-to-static pr) 144.26 618.6 P
0.42 (omotion) 217.6 618.6 P
1 F
0.42 ( point has an) 247.1 618.6 P
0.66 (associated cache of specialized versions indexed by the values of) 54 608.6 P
0.74 (the promoted variables, and the specializer consults this cache of) 54 598.6 P
0.65 (previously specialized versions to see whether a previous version) 54 588.6 P
1.92 (can be reused or a new version must be produced. The initial) 54 578.6 P
4 F
1.02 (make_static) 54 568.6 P
1 F
0.43 ( entry is also a dynamic-to-static promotion point) 113.4 568.6 P
0.46 (with an associated cache of versions specialized for dif) 54 558.6 P
0.46 (ferent run-) 255.43 558.6 P
1.92 (time values of the initial static variables. \050Again, programmer) 54 548.6 P
1.92 (-) 291.12 548.6 P
0.83 (supplied policies support \336ner control over the aggressiveness of) 54 538.6 P
0.21 (dynamic-to-static promotion and the caching scheme to be used at) 54 528.6 P
(promotion points.\051) 54 518.6 T
-0.07 (A standard issue in specialization is how aggressively to specialize) 54 505.2 P
-0.48 (control-\337ow paths ahead of actually reaching those branches during) 54 495.2 P
1.03 (normal program execution. Aggressive) 54 485.2 P
3 F
1.03 (speculative) 200.85 485.2 P
1 F
1.03 ( specialization) 241.35 485.2 P
3.02 (has the lowest cost, assuming that all specialized paths will) 54 475.2 P
-0.3 (eventually be taken at run time, but it incurs the cost of specializing) 54 465.2 P
0.36 (any path not actually executed at run time, and it can lead to non-) 54 455.2 P
1.47 (termination in the presence of loops or recursion. Alternatively) 54 445.2 P
1.47 (,) 291.87 445.2 P
3 F
0.08 (demand-driven) 54 435.2 P
1 F
0.08 ( specialization only specializes code when it can be) 108.49 435.2 P
3.29 (proven to be executed at run time, typically by suspending) 54 425.2 P
-0.54 (specialization at each successor of a dynamic \050non-constant\051 branch) 54 415.2 P
2.09 (in the program being specialized, resuming specialization only) 54 405.2 P
1.29 (when that successor is actually taken. This strategy avoids non-) 54 395.2 P
0.81 (termination problems and unneeded specialization, but incurs the) 54 385.2 P
1.11 (cost of suspension and resumption of specialization. Our system) 54 375.2 P
-0.12 (allows the programmer to specify policies with variables to control) 54 365.2 P
-0.39 (speculative specialization based on those variables, with the default) 54 355.2 P
1.91 (policy introducing suspension points at each specializable loop) 54 345.2 P
(head.) 54 335.2 T
-0.04 (Figure 2 extends the simple single-procedure interpreter to support) 54 321.8 P
2.3 (interpreting programs made up of multiple procedures. It also) 54 311.8 P
0.99 (illustrates several other of our system\325) 54 301.8 P
0.99 (s capabilities, in particular) 196.17 301.8 P
0.95 (how polyvariant division can be exploited to support conditional) 54 291.8 P
5.43 (specialization, and annotations that support interprocedural) 54 281.8 P
(specialization.) 54 271.8 T
1.23 (In the modi\336ed) 54 258.4 P
4 F
2.94 (interp_fn) 114.92 258.4 P
1 F
1.23 ( routine, a) 163.52 258.4 P
4 F
2.94 (count) 205.69 258.4 P
1 F
1.23 ( array associates) 232.69 258.4 P
-0.31 (with each) 54 248.4 P
4 F
-0.74 (pc) 90.37 248.4 P
1 F
-0.31 ( corresponding to a function entry point the number of) 101.17 248.4 P
0.99 (times that function has been invoked. In order to apply dynamic) 54 238.4 P
1.24 (compilation only to heavily used functions, the programmer has) 54 228.4 P
0.37 (made the original) 54 218.4 P
4 F
0.9 (make_static) 120.36 218.4 P
1 F
0.37 ( call from Figure 1 conditional,) 179.76 218.4 P
2.21 (occurring only when the invocation count of some interpreted) 54 208.4 P
3.81 (procedure reaches a threshold. At the mer) 54 198.4 P
3.81 (ge after the) 226.9 198.4 P
4 F
9.15 (if) 281.07 198.4 P
1 F
3.81 (,) 291.87 198.4 P
4 F
4.06 (bytecodes) 54 188.4 P
1 F
1.69 (,) 102.6 188.4 P
4 F
4.06 (pc) 108.79 188.4 P
1 F
1.69 (, and) 119.59 188.4 P
4 F
4.06 (sp) 142.72 188.4 P
1 F
1.69 ( are static along one predecessor but) 153.52 188.4 P
-0.4 (dynamic along the other) 54 178.4 P
-0.4 (. By default, our system applies polyvariant) 139.54 178.4 P
0.62 (division to produce two separate versions of the remainder of the) 54 168.4 P
0.18 (body of) 54 158.4 P
4 F
0.44 (interp_fn) 84.36 158.4 P
1 F
0.18 (, one where the three variables are static and) 132.96 158.4 P
0.42 (lead to run-time specialization as in Figure 1, and one where they) 54 148.4 P
0.24 (are dynamic and no run-time specialization takes place, leading to) 54 138.4 P
(regular interpretation of the input at no run-time cost.) 54 128.4 T
0.58 (The) 54 115 P
4 F
1.4 (specialize) 70.83 115 P
1 F
0.58 ( annotation directs the compiler to produce an) 124.83 115 P
-0.44 (alternate entry point to the) 54 105 P
4 F
-1.07 (interp_fn) 149.02 105 P
1 F
-0.44 ( procedure to be used when) 197.62 105 P
0.51 (its \336rst two parameters are run-time constants. At call sites of the) 54 95 P
4 F
-0.5 (interp_fn) 54 85 P
1 F
-0.21 ( procedure where the corresponding actual ar) 102.6 85 P
-0.21 (guments) 263.62 85 P
0.62 (are static, a specialized version of) 54 75 P
4 F
1.49 (interp_fn) 181.43 75 P
1 F
0.62 ( is produced \050and) 230.03 75 P
317.88 72 558 738 R
7 X
V
0 X
-0.32 (cached for later reuse\051 for the run-time constant values of the actual) 317.88 732 P
0.5 (ar) 317.88 722 P
0.5 (guments. The body of the specialized) 324.71 722 P
4 F
1.19 (interp_fn) 464.41 722 P
1 F
0.5 ( is compiled) 513.01 722 P
1 (as if its formal parameters were annotated as) 317.88 712 P
4 F
2.4 (make_static) 488.85 712 P
1 F
1 ( at) 548.25 712 P
2.34 (entry) 317.88 702 P
2.34 (. \050The callee procedure and each of its call sites can be) 335.79 702 P
1.67 (compiled separately) 317.88 692 P
1.67 (, given the) 391.2 692 P
4 F
4.02 (specialize) 436.23 692 P
1 F
1.67 ( annotation in the) 490.23 692 P
5.2 (shared header \336le.\051 This specialization has the ef) 317.88 682 P
5.2 (fect of) 529.56 682 P
-0.37 (streamlining the calling sequence for specialized) 317.88 672 P
4 F
-0.89 (GOSUB) 493.13 672 P
1 F
-0.37 ( bytecodes) 520.13 672 P
1.26 (to specialized callees: neither the) 317.88 662 P
4 F
3.02 (bytecodes) 445.39 662 P
1 F
1.26 ( array nor the pc) 493.99 662 P
0.49 (variable will be passed in the specialized call, and the specialized) 317.88 652 P
0.91 (interpreter for the tar) 317.88 642 P
0.91 (get function \050i.e., the compiled code for the) 395.67 642 P
-0.37 (tar) 317.88 632 P
-0.37 (get function\051 will be invoked directly) 327.21 632 P
-0.37 (. If the callee function is not) 459 632 P
3.77 (yet heavily executed, then after entry the) 317.88 622 P
4 F
9.04 (make_dynamic) 493.2 622 P
1 F
0.4 (annotation will turn of) 317.88 612 P
0.4 (f specialization for that input procedure; all) 399.65 612 P
-0.17 (bodies of infrequently executed procedures will branch to the same) 317.88 602 P
(precompiled version of the unspecialized interpreter) 317.88 592 T
(.) 505.09 592 T
2 12 Q
(3) 317.88 569.5 T
(Run-T) 335.88 569.5 T
(ime Specializer) 369.67 569.5 T
1 9 Q
0.24 (In this section we describe our run-time specializer) 317.88 553 P
0.24 (. Later sections) 502.78 553 P
3.2 (present our annotation language and describe how annotated) 317.88 543 P
-0.34 (programs get translated down into static precompiled code and run-) 317.88 533 P
(time specializers. Figures 3 and 4 sketch our specializer) 317.88 523 T
(.) 518.09 523 T
2.99 (Our run-time specializer is an adaptation of the strategy for) 317.88 508.5 P
0.56 (polyvariant program-point specialization of a \337ow chart language) 317.88 498.5 P
-0.46 (described by Jones, Gomard, and Sestoft [Jones) 317.88 488.5 P
3 F
-0.46 (et al.) 488.86 488.5 P
1 F
-0.46 ( 93]. The main) 506.4 488.5 P
-0.41 (process is to produce specialized code for a) 317.88 478.5 P
3 F
-0.41 (unit) 473.02 478.5 P
1 F
-0.41 ( \050a generalization of) 487.02 478.5 P
1.13 (a basic block that has a single entry but multiple possible exits\051) 317.88 468.5 P
-0.3 (given the) 317.88 458.5 P
3 F
-0.3 (context) 352.77 458.5 P
1 F
-0.3 (, i.e., the run-time values of the static variables, on) 378.76 458.5 P
-0.03 (entry to the unit. The static compiler is responsible for breaking up) 317.88 448.5 P
0.99 (dynamically compiled regions of the input program into units of) 317.88 438.5 P
3.74 (specialization, producing the static data structures and code) 317.88 428.5 P
1.06 (describing units and their connectivity) 317.88 418.5 P
1.06 (, and generating the initial) 459.52 418.5 P
0.11 (call to the) 317.88 408.5 P
4 F
0.27 (Specialize) 355.96 408.5 P
1 F
0.11 ( function with the initial unit and context) 409.96 408.5 P
(at the entries to dynamically compiled code.) 317.88 398.5 T
-0.19 (The) 317.88 384 P
4 F
-0.46 (Specialize) 333.93 384 P
1 F
-0.19 ( function \336rst consults a cache to see if code for) 387.93 384 P
2.38 (the unit and entry context being specialized has already been) 317.88 374 P
0.82 (produced \050using the unit\325) 317.88 364 P
0.82 (s caching policy to customize the cache) 410.59 364 P
0.04 (lookup process\051, and reuses the existing specialization if so. If not,) 317.88 354 P
2.6 (the unit\325) 317.88 344 P
2.6 (s) 350.24 344 P
4 F
6.25 (ReduceAndResidualize) 358.59 344 P
1 F
2.6 ( function is invoked to) 466.59 344 P
1.47 (produce code for the unit, specialized to the input context. The) 317.88 334 P
2.72 (updated values of the context at each of the program points) 317.88 324 P
1.68 (corresponding to unit exits is returned. The specialized code is) 317.88 314 P
-0.16 (added to the cache \050again customized by the unit\325) 317.88 304 P
-0.16 (s caching policy\051.) 494.58 304 P
(Finally) 317.88 289.5 T
(, the specializer determines how to process each of the exits) 342.8 289.5 T
-0.25 (of the specialized unit. Each exit edge can either be) 317.88 279.5 P
3 F
-0.25 (eager) 502.61 279.5 P
1 F
-0.25 (, in which) 522.74 279.5 P
-0.07 (case the successor unit is specialized right away) 317.88 269.5 P
-0.07 (, or) 489.54 269.5 P
3 F
-0.07 (lazy) 503.65 269.5 P
1 F
-0.07 (, indicating) 517.57 269.5 P
1.27 (that specialization should be suspended until run-time execution) 317.88 259.5 P
0.49 (reaches that edge; lazy edges are implemented by generating stub) 317.88 249.5 P
1.9 (code at that edge that will call back into the specializer when) 317.88 239.5 P
-0.52 (executed. Points of dynamic-to-static promotion always correspond) 317.88 229.5 P
0.4 (to lazy edges between units; code is generated at these lazy edges) 317.88 219.5 P
-0.38 (that will inject the promoted run-time values into the context before) 317.88 209.5 P
(invoking the specializer) 317.88 199.5 T
(.) 403.37 199.5 T
2.63 (The caching structure for units is one of the chief points of) 317.88 185 P
-0.18 (\337exibility in our system. Each of the variables in the context has an) 317.88 175 P
10.46 (associated policy \050) 317.88 165 P
4 F
25.11 (CacheAllUnchecked) 405.79 165 P
1 F
10.46 (,) 497.59 165 P
4 F
25.11 (CacheAll) 512.55 165 P
1 F
10.46 (,) 555.75 165 P
4 F
5.47 (CacheOne) 317.88 155 P
1 F
2.28 (, and) 361.08 155 P
4 F
5.47 (CacheOneUnchecked) 385.38 155 P
1 F
2.28 (, listed in decreasing) 477.18 155 P
5.41 (order of specialization aggressiveness\051, derived from user) 317.88 145 P
-0.03 (annotations and static analysis.) 317.88 135 P
4 F
-0.08 (CacheAllUnchecked) 431.49 135 P
1 F
-0.03 ( variables) 523.29 135 P
0.68 (are considered to be so rapidly changing that there is no value in) 317.88 125 P
0.05 (checking and maintaining a cache of specializations; each time the) 317.88 115 P
0.88 (unit is specialized, a new version of code is produced, used, and) 317.88 105 P
1.13 (thrown away) 317.88 95 P
1.13 (. For) 365.16 95 P
4 F
2.72 (CacheAll) 386.68 95 P
1 F
1.13 ( variables, the system caches each) 429.88 95 P
-0.07 (combination of those variables for potential future reuse, assuming) 317.88 85 P
1.84 (that previous combinations are likely to recur) 317.88 75 P
1.84 (. For) 491.88 75 P
4 F
4.41 (CacheOne) 514.8 75 P
0 0 0 1 0 0 0 K
FMENDPAGE
%%EndPage: "3" 3
%%Page: "4" 4
612 792 0 FMBEGINPAGE
[0 0 0 1 0 0 0]
[ 0 1 1 0 1 0 0]
[ 1 0 1 0 0 1 0]
[ 1 1 0 0 0 0 1]
[ 1 0 0 0 0 1 1]
[ 0 1 0 0 1 0 1]
[ 0 0 1 0 1 1 0]
 7 FrameSetSepColors
FrameNoSep
0 0 0 1 0 0 0 K
54 26 558 44 R
7 X
0 0 0 1 0 0 0 K
V
0 0 0 1 0 0 0 K
0 0 0 1 0 0 0 K
54 72 294.12 738 R
V
54 72 301.49 738 C
0 0 0 1 0 0 0 K
0 0 0 1 0 0 0 K
54 81 297.05 738 R
7 X
0 0 0 1 0 0 0 K
V
4 8 Q
0 X
(Specialize\050unit:Unit,) 54 732.67 T
(context:Context,) 106.8 724.67 T
(backpatch_addr:Addr\051:Addr {) 106.8 716.67 T
(/* see if we\325ve already specialized this unit for) 61.2 708.67 T
(this particular context */) 75.6 700.67 T
(\050found:bool, start_addr:Addr\051 :=) 61.2 692.67 T
(CacheLookup\050unit, context\051;) 75.6 684.67 T
(if not found then) 61.2 676.17 T
-0.22 (/* need to produce & cache the specialization */) 68.4 668.17 P
(\050start_addr,) 68.4 660.17 T
(edge_contexts:List<Context>,) 73.2 652.17 T
(edge_addrs:List<Addr>\051 :=) 73.2 644.17 T
(unit.ReduceAndResidualize\050context\051;) 82.8 636.17 T
(CacheStore\050unit, context, start_addr\051;) 68.4 628.17 T
(/* see how to handle each successor of the) 68.4 620.17 T
(specialized unit */) 82.8 612.17 T
(foreach edge:UnitEdge,) 68.4 604.17 T
(edge_context:Context,) 106.8 596.17 T
(edge_addr:Addr) 106.8 588.17 T
(in unit.edges, edge_contexts, edge_addrs do) 82.8 580.17 T
(if edge.eager_specialize then) 75.6 572.17 T
(/* eagerly specialize the successor now */) 82.8 564.17 T
(Specialize\050edge.target_unit,) 82.8 556.17 T
(edge_context,) 135.6 548.17 T
(edge_addr\051;) 135.6 540.17 T
(else) 75.6 532.17 T
(/* lazily specialize the successor by) 82.8 524.17 T
(emitting code to compute the values of) 97.2 516.17 T
(promoted variables and then call the) 97.2 508.17 T
(specializer with the revised context */) 97.2 500.17 T
(addr:Addr :=) 82.8 492.17 T
(edge.ResolvePromotions\050edge_context\051;) 90 484.17 T
(Backpatch\050edge_addr, addr\051;) 82.8 476.17 T
(Emit\050\322pc := Specialize\050`edge.target_unit`,) 82.8 468.17 T
(promoted_context,) 193.2 460.17 T
(NULL\051\323\051;) 193.2 452.17 T
(Emit\050\322jump pc\323\051;) 82.8 444.17 T
(endif) 75.6 436.17 T
(endfor) 68.4 428.17 T
(endif) 61.2 420.17 T
-0.99 (/* make the predecessor unit branch to this code */) 61.2 411.67 P
(Backpatch\050backpatch_addr, start_addr\051;) 61.2 403.67 T
(return start_addr;) 61.2 395.67 T
(}) 54 387.67 T
(type Context = Tuple<Value>;) 54 379.17 T
(class Unit {) 54 370.67 T
(id:int,) 61.2 362.67 T
(cache_policies:Tuple<CachePolicy>;) 61.2 354.67 T
(edges:List<UnitEdge>;) 61.2 346.67 T
(ReduceAndResidualize\050context:Context\051) 61.2 338.67 T
(:\050start_addr:Addr,) 152.4 330.67 T
(out_contexts:List<Context>,) 162 322.67 T
(edge_addrs:List<Addr>\051;) 162 314.67 T
(/* Take the the values of the static vars and) 68.4 306.67 T
(produce specialized code for the unit.) 82.8 298.67 T
-0.22 (Return the address of the start of the unit\325s) 82.8 290.67 P
-1.09 (specialized code and, for each successor unit,) 82.8 282.67 P
-0.82 (the new values of the static variables at that) 82.8 274.67 P
-0.19 (edge and the address of the exit point in the) 82.8 266.67 P
(specialized code for the unit */) 82.8 258.67 T
(}) 54 250.67 T
(class UnitEdge {) 54 242.17 T
(target_unit:Unit;) 61.2 234.17 T
(eager_specialize:bool;) 61.2 226.17 T
(ResolvePromotions\050context:Context\051:Addr;) 61.2 218.17 T
-0.25 (/* Generate code to extract the current run-time) 68.4 210.17 P
-0.29 (values of any static variables being promoted) 82.8 202.17 P
(at this edge, updating the input) 82.8 194.17 T
(context and leaving the result in the) 82.8 186.17 T
(\322promoted_context\323 run-time variable.) 82.8 178.17 T
(Return the address of the start of the) 82.8 170.17 T
(generated code. */) 82.8 162.17 T
(}) 54 154.17 T
(enum CachePolicy {) 54 145.67 T
(CacheAll, CacheAllUnchecked,) 61.2 137.67 T
(CacheOne, CacheOneUnchecked) 61.2 129.67 T
(}) 54 121.67 T
2 10 Q
(Figur) 93.68 104.34 T
(e 3: Run-T) 117.39 104.34 T
(ime Specializer) 163.32 104.34 T
(, Part I) 227.11 104.34 T
0 0 612 792 C
317.88 72 558 738 R
7 X
0 0 0 1 0 0 0 K
V
1 9 Q
0 X
2.77 (variables, only one specialized version is maintained, for the) 317.88 273 P
2.42 (current values of those variables. If the values of any of the) 317.88 263 P
0.37 (variables change, the previously specialized code is dropped from) 317.88 253 P
1.59 (the cache, assuming that combination of values is not likely to) 317.88 243 P
4.44 (recur) 317.88 233 P
4.44 (. The values of) 335.87 233 P
4 F
10.65 (CacheOneUnchecked) 409.35 233 P
1 F
4.44 ( variables are) 501.15 233 P
11.2 (invariants or are pure functions of other non-) 317.88 223 P
4 F
0.05 (CacheOneUnchecked) 317.88 213 P
1 F
0.02 ( variables, so the redundant cache checks) 409.68 213 P
1.18 (for those variables are suppressed. Our run-time caching system) 317.88 203 P
0.24 (supports mixes of these cache policies, by skipping cache lookups) 317.88 193 P
11.27 (and stores if any variable in the context is) 317.88 183 P
4 F
6.84 (CacheAllUnchecked) 317.88 173 P
1 F
2.85 (, and otherwise by \336rst performing a) 409.68 173 P
2 (lookup in an unbounded-sized cache based on the) 317.88 163 P
4 F
4.79 (CacheAll) 514.8 163 P
1 F
0.49 (variables \050if any\051, and then \050if successful\051 performing a lookup in) 317.88 153 P
-0.29 (the resulting single-entry cache based on the) 317.88 143 P
4 F
-0.69 (CacheOne) 478.1 143 P
1 F
-0.29 ( variables,) 521.3 143 P
1.47 (in turn resulting if successful in the address for the appropriate) 317.88 133 P
1.37 (specialized code.) 317.88 123 P
4 F
3.3 (CacheOneUnchecked) 384.36 123 P
1 F
1.37 ( variables are ignored) 476.16 123 P
(during cache lookup.) 317.88 113 T
0.07 (Since invoking the specializer is a source of overhead for run-time) 317.88 95 P
0.68 (specialization, our system performs a number of optimizations of) 317.88 85 P
3.24 (this general structure, principally by producing a specialized) 317.88 75 P
317.88 279 558 738 C
0 0 0 1 0 0 0 K
0 0 0 1 0 0 0 K
318.22 288 557.98 738 R
7 X
0 0 0 1 0 0 0 K
V
4 8 Q
0 X
(CacheLookup\050unit:Unit, context:Context\051) 318.22 732.67 T
(:\050found:bool, start_addr:Addr\051 {) 366.22 724.67 T
(if CacheAllUnchecked) 325.42 716.67 T
6 F
(\316) 426.22 716.67 T
4 F
( unit.cache_policies then) 431.92 716.67 T
(/* always produce a new specialization */) 332.62 708.67 T
(return \050false, NULL\051;) 332.62 700.67 T
(else) 325.42 692.67 T
(/* first index on CacheAll values */) 332.62 684.67 T
(let cache_alls :=) 332.62 676.67 T
0 F
(elements of) 339.82 668.67 T
4 F
(context) 383.39 668.67 T
0 F
( with) 416.99 668.67 T
4 F
(CacheAll) 435.67 668.67 T
0 F
( policy) 474.07 668.67 T
4 F
(;) 496.74 668.67 T
(\050found, sub_cache\051 :=) 332.62 660.67 T
(cache.lookup\050unit.id, cache_alls\051;) 339.82 652.67 T
(if not found then return \050false, NULL\051;) 332.62 644.67 T
(/* then index on CacheOne values) 332.62 636.67 T
(in nested cache */) 347.02 628.67 T
(let cache_ones :=) 332.62 620.67 T
0 F
(elements of) 339.82 612.67 T
4 F
(context) 383.39 612.67 T
0 F
( with) 416.99 612.67 T
4 F
(CacheOne) 435.67 612.67 T
0 F
( policy) 474.07 612.67 T
4 F
(;) 496.74 612.67 T
(\050found, start_addr\051 :=) 332.62 604.67 T
(sub_cache.lookup\050cache_ones\051;) 339.82 596.67 T
(/* no need to index on CacheOneUnchecked */) 332.62 588.67 T
(return \050found, start_addr\051;) 332.62 580.67 T
(endif) 325.42 572.67 T
(}) 318.22 564.67 T
(CacheStore\050unit:Unit, context:Context,) 318.22 556.17 T
(start_addr:Addr\051:void {) 371.02 548.17 T
(if CacheAllUnchecked) 325.42 540.17 T
6 F
(\316) 426.22 540.17 T
4 F
( unit.cache_policies then) 431.92 540.17 T
(/* don\325t store it, since we won\325t reuse it */) 332.62 532.17 T
(else) 325.42 524.17 T
(/* first index on CacheAll values */) 332.62 516.17 T
(let cache_alls :=) 332.62 508.17 T
0 F
(elements of) 339.82 500.17 T
4 F
(context) 383.39 500.17 T
0 F
( with) 416.99 500.17 T
4 F
(CacheAll) 435.67 500.17 T
0 F
( policy) 474.07 500.17 T
4 F
(;) 496.74 500.17 T
(\050found, sub_cache\051 :=) 332.62 492.17 T
(cache.lookup\050unit.id, cache_alls\051;) 339.82 484.17 T
(if not found then) 332.62 476.17 T
(sub_cache := new SubCache;) 339.82 468.17 T
(cache.add\050unit.id, cache_alls, sub_cache\051;) 339.82 460.17 T
(endif) 332.62 452.17 T
(/* then index on CacheOne values) 332.62 444.17 T
(in nested cache */) 347.02 436.17 T
(let cache_ones :=) 332.62 428.17 T
0 F
(elements of) 339.82 420.17 T
4 F
(context) 383.39 420.17 T
0 F
( with) 416.99 420.17 T
4 F
(CacheOne) 435.67 420.17 T
0 F
( policy) 474.07 420.17 T
4 F
(;) 496.74 420.17 T
(/* store the new specialization in the cache,) 332.62 412.17 T
(replacing any there previously */) 347.02 404.17 T
(sub_cache.replace\050cache_ones, start_addr\051;) 332.62 396.17 T
(endif) 325.42 388.17 T
(}) 318.22 380.17 T
(Backpatch\050source:Addr, target:Addr\051:void {) 318.22 371.67 T
(/* if source != NULL, then backpatch the branch) 325.42 363.67 T
(instruction at source to jump to target */) 339.82 355.67 T
(}) 318.22 347.67 T
(Emit\050instruction:Code\051 {) 318.22 339.17 T
(/* append a single instruction to the current) 325.42 331.17 T
(code-generation point */) 339.82 323.17 T
(}) 318.22 315.17 T
2 10 Q
(Figur) 354.3 297.83 T
(e 4: Run-T) 378.01 297.83 T
(ime Specializer) 423.94 297.83 T
(, Part II) 487.73 297.83 T
0 0 612 792 C
0 0 0 1 0 0 0 K
FMENDPAGE
%%EndPage: "4" 4
%%Page: "5" 5
612 792 0 FMBEGINPAGE
[0 0 0 1 0 0 0]
[ 0 1 1 0 1 0 0]
[ 1 0 1 0 0 1 0]
[ 1 1 0 0 0 0 1]
[ 1 0 0 0 0 1 1]
[ 0 1 0 0 1 0 1]
[ 0 0 1 0 1 1 0]
 7 FrameSetSepColors
FrameNoSep
0 0 0 1 0 0 0 K
54 26 558 44 R
7 X
0 0 0 1 0 0 0 K
V
0 0 0 1 0 0 0 K
0 0 0 1 0 0 0 K
54 72 294.12 738 R
V
1 9 Q
0 X
1.79 (version of the) 54 732 P
4 F
4.31 (Specialize) 111.12 732 P
1 F
1.79 ( function for each unit. Section 6) 165.12 732 P
(describes these optimizations in more detail.) 54 722 T
2 12 Q
(4) 54 700.83 T
(Annotations) 72 700.83 T
1 9 Q
1.98 (Given the tar) 54 685.65 P
1.98 (get run-time specializer described in the previous) 104.79 685.65 P
4.43 (section, we now present the programmer) 54 675.65 P
4.43 (-visible annotation) 222.44 675.65 P
-0.42 (language \050in this section\051 and then the analyses to construct the run-) 54 665.65 P
1.49 (time specializer based on the annotations \050in sections 5 and 6\051.) 54 655.65 P
0.68 (Appendix A speci\336es the syntax of our annotations, expressed as) 54 645.65 P
0.38 (extensions to the standard C grammar rules [Kernighan & Ritchie) 54 635.65 P
(88].) 54 625.65 T
2 10 Q
(4.1) 54 608.81 T
5 F
(make_static) 72 608.81 T
2 F
( and) 138 608.81 T
5 F
(make_dynamic) 159.12 608.81 T
1 9 Q
3.84 (The basic annotations that drive run-time specialization are) 54 594.31 P
4 F
3.62 (make_static) 54 584.31 P
1 F
1.51 ( and) 113.4 584.31 P
4 F
3.62 (make_dynamic) 133.91 584.31 P
1 F
1.51 (.) 198.71 584.31 P
4 F
3.62 (make_static) 204.72 584.31 P
1 F
1.51 ( takes a) 264.12 584.31 P
0.67 (list of variables, indicating that each of them is to be treated as a) 54 574.31 P
0.7 (run-time constant at all subsequent program points until reaching) 54 564.31 P
0.68 (either a) 54 554.31 P
4 F
1.62 (make_dynamic) 84.34 554.31 P
1 F
0.68 ( annotation that lists the variable or the) 149.14 554.31 P
5.55 (end of the variable\325) 54 544.31 P
5.55 (s scope \050which acts as an implicit) 140.37 544.31 P
4 F
0.25 (make_dynamic) 54 534.31 P
1 F
0.1 ( annotation\051. W) 118.8 534.31 P
0.1 (e call the region of code between) 174.53 534.31 P
0 (a) 54 524.31 P
4 F
0 (make_static) 60.25 524.31 P
1 F
0 ( for a variable and the corresponding \050explicit or) 119.65 524.31 P
2.23 (implicit\051) 54 514.31 P
4 F
5.36 (make_dynamic) 89.49 514.31 P
1 F
2.23 ( a) 154.29 514.31 P
3 F
2.23 (dynamic specialization r) 167.26 514.31 P
2.23 (egion) 259.89 514.31 P
1 F
2.23 (, or) 279.89 514.31 P
3 F
7.78 (dynamic r) 54 504.31 P
7.78 (egion) 97.69 504.31 P
1 F
7.78 ( for short. Because the placement of) 117.69 504.31 P
4 F
-0.69 (make_static) 54 494.31 P
1 F
-0.29 ( and) 113.4 494.31 P
4 F
-0.69 (make_dynamic) 130.32 494.31 P
1 F
-0.29 ( annotations is arbitrary) 195.12 494.31 P
-0.29 (, the) 278.91 494.31 P
1.17 (dynamic region for a variable can have multiple entry points \050if) 54 484.31 P
-0.19 (separate) 54 474.31 P
4 F
-0.45 (make_static) 85.55 474.31 P
1 F
-0.19 ( annotations for a variable mer) 144.95 474.31 P
-0.19 (ge together) 254.07 474.31 P
1.18 (downstream\051 and multiple exit points. A dynamic region can be) 54 464.31 P
0.41 (nested inside or overlap with dynamic regions for other variables,) 54 454.31 P
2.38 (as in the following graph fragment \050static variables shown in) 54 444.31 P
(boldface\051:) 54 434.31 T
-0.22 (This \337exibility in form for dynamic regions is one major dif) 54 318.86 P
-0.22 (ference) 267.64 318.86 P
(between our system and other dynamic-compilation systems.) 54 308.86 T
2.77 (A convenient syntactic sugar for a nested dynamic region is) 54 295.69 P
4 F
3.08 (make_static) 54 285.69 P
1 F
1.28 ( followed by a compound statement enclosed in) 113.4 285.69 P
(braces, for instance) 54 275.69 T
4 8 Q
(make_static\050x, y\051 {) 61.2 264.19 T
(...) 68.4 256.19 T
(}) 61.2 248.19 T
1 9 Q
-0.33 (This places) 54 236.35 P
4 F
-0.8 (make_dynamic) 96.33 236.35 P
1 F
-0.33 ( annotations for the listed variables at) 161.13 236.35 P
(each of the exits of the compound statement.) 54 226.35 T
2 10 Q
(4.2) 54 209.51 T
(Policies) 72 209.51 T
1 9 Q
0.78 (Each variable listed in a) 54 195 P
4 F
1.87 (make_static) 146.63 195 P
1 F
0.78 ( annotation can have an) 206.03 195 P
-0.39 (associated list of policies. These policies control the aggressiveness) 54 185 P
1.57 (of specialization, division, and dynamic-to-static promotion, the) 54 175 P
0.38 (caching policies, and the laziness policies. The semantics of these) 54 165 P
1.39 (policies is described in T) 54 155 P
1.39 (able 1, with the default policy in each) 148.92 155 P
1.09 (category in bold. Annotations in italics are unsafe; their use can) 54 145 P
-0.29 (lead to changes in observable program behavior or non-termination) 54 135 P
3.88 (of specialization, if their stated assumptions about program) 54 125 P
0.99 (behavior are violated. All of our default policies are safe, so the) 54 115 P
0.38 (novice programmer need not worry about simple uses of run-time) 54 105 P
0.17 (specialization. Unsafe policies are included for sophisticated users) 54 95 P
0.41 (who wish to get \336ner control over dynamic compilation for better) 54 85 P
(performance.) 54 75 T
54 72 294.12 738 C
54 329.04 294.12 431.31 C
0 0 0 1 0 0 0 K
0 0 0 1 0 0 0 K
52.56 329.04 295.56 431.31 R
7 X
0 0 0 1 0 0 0 K
V
91.42 408.21 163.42 426.21 R
V
0 0 0 1 0 0 0 K
4 7 Q
0 X
(make_static\050x\051;) 91.42 421.55 T
0 0 0 1 0 0 0 K
0 0 0 1 0 0 0 K
(...) 91.42 413.55 T
5 F
(x) 104.02 413.55 T
4 F
(,y...) 108.22 413.55 T
0 0 0 1 0 0 0 K
190.42 408.21 262.42 426.21 R
7 X
V
0 0 0 1 0 0 0 K
0 X
(make_static\050x\051;) 190.42 421.55 T
0 0 0 1 0 0 0 K
0 0 0 1 0 0 0 K
(...) 190.42 413.55 T
5 F
(x) 203.02 413.55 T
4 F
(,y...) 207.22 413.55 T
0 0 0 1 0 0 0 K
91.42 330.88 163.42 363.21 R
7 X
V
0 0 0 1 0 0 0 K
0 X
(make_dynamic\050x\051;) 91.42 358.55 T
0 0 0 1 0 0 0 K
0 0 0 1 0 0 0 K
(...x,) 91.42 350.55 T
5 F
(y) 112.42 350.55 T
4 F
(...) 116.62 350.55 T
0 0 0 1 0 0 0 K
0 0 0 1 0 0 0 K
(make_dynamic\050y\051;) 91.42 342.55 T
0 0 0 1 0 0 0 K
0 0 0 1 0 0 0 K
(...x,y...) 91.42 334.55 T
0 0 0 1 0 0 0 K
190.42 330.88 262.42 363.21 R
7 X
V
0 0 0 1 0 0 0 K
0 X
(make_dynamic\050y\051;) 190.42 358.55 T
0 0 0 1 0 0 0 K
0 0 0 1 0 0 0 K
(...) 190.42 350.55 T
5 F
(x) 203.02 350.55 T
4 F
(,y...) 207.22 350.55 T
0 0 0 1 0 0 0 K
0 0 0 1 0 0 0 K
(make_dynamic\050x\051;) 190.42 342.55 T
0 0 0 1 0 0 0 K
0 0 0 1 0 0 0 K
(...x,y...) 190.42 334.55 T
0 0 0 1 0 0 0 K
88.56 427.64 88.56 409.64 160.56 409.64 160.56 427.64 4 L
0.5 H
2 Z
N
187.56 427.64 187.56 409.64 259.56 409.64 259.56 427.64 4 L
N
88.56 332.31 88.56 364.64 160.56 364.64 160.56 332.31 4 L
N
187.56 332.31 187.56 364.64 259.56 364.64 259.56 332.31 4 L
N
141.21 377.31 209.07 395.31 R
7 X
V
0 0 0 1 0 0 0 K
0 X
(make_static\050y\051;) 141.21 390.64 T
0 0 0 1 0 0 0 K
0 0 0 1 0 0 0 K
(...) 141.21 382.64 T
5 F
(x) 153.82 382.64 T
4 F
(,) 158.01 382.64 T
5 F
(y) 162.21 382.64 T
4 F
(...) 166.41 382.64 T
0 0 0 1 0 0 0 K
139.56 377.31 210.06 395.31 R
N
0 0 0 1 0 0 0 K
0 0 0 1 0 0 0 K
169.39 400.12 173.56 395.81 167.74 394.35 168.56 397.24 4 Y
V
124.56 409.81 168.56 397.24 2 L
1 H
N
178.85 394.25 173.06 395.81 177.3 400.05 178.08 397.15 4 Y
V
223.56 409.31 178.08 397.15 2 L
N
130.31 363.59 124.56 365.31 128.92 369.43 129.62 366.51 4 Y
V
173.06 376.81 129.62 366.51 2 L
N
219.18 369.41 223.56 365.31 217.82 363.56 218.5 366.48 4 Y
V
174.06 376.81 218.5 366.48 2 L
N
54 72 294.12 738 C
0 0 612 792 C
317.88 72 558 738 R
7 X
0 0 0 1 0 0 0 K
V
1 9 Q
0 X
-0.37 (Our policies currently support either caches of size one or caches of) 317.88 215.5 P
0.74 (unbounded size. It is reasonable to wish for caching policies that) 317.88 204.46 P
2.53 (take an ar) 317.88 193.41 P
2.53 (gument indicating the desired cache size. However) 357.75 193.41 P
2.53 (,) 555.75 193.41 P
3.11 (bounded multiple-entry caches necessitate a non-trivial cache) 317.88 182.36 P
5.15 (replacement policy) 317.88 171.32 P
5.15 (, over which we would want to of) 391.17 171.32 P
5.15 (fer) 548.01 171.32 P
1.53 (programmer control. More generally) 317.88 160.27 P
1.53 (, we might wish to provide) 453.85 160.27 P
0.22 (programmers with direct access to the various caches that the run-) 317.88 149.23 P
0.43 (time specializer maintains. W) 317.88 138.18 P
0.43 (e leave the design of such interfaces) 425.44 138.18 P
(to future work.) 317.88 127.14 T
2.48 (The polyvariant vs. monovariant specialization policy controls) 317.88 108.14 P
0.25 (whether mer) 317.88 97.09 P
0.25 (ge points should be specialized for dif) 363.2 97.09 P
0.25 (ferent values of) 501.52 97.09 P
3.22 (a variable \337owing in along dif) 317.88 86.05 P
3.22 (ferent mer) 442.55 86.05 P
3.22 (ge predecessors. In) 482.84 86.05 P
-0.47 (contrast, promotion points such as) 317.88 75 P
4 F
-1.12 (make_static) 441.05 75 P
1 F
-0.47 ( always perform) 500.45 75 P
2 10 Q
(T) 403.4 731.33 T
(able 1: Policies) 409.15 731.33 T
1 9 Q
(Policy) 345.44 711 T
(Description) 456 711 T
5 8 Q
(poly_divide) 320.88 696.17 T
1 F
(perform polyvariant division) 399 696.17 T
4 F
(mono_divide) 320.88 683.67 T
1 F
(perform monovariant division) 399 683.67 T
5 F
(poly_specialize) 320.88 671.17 T
1 F
(perform polyvariant specialization at mer) 399 671.17 T
(ges) 531.27 671.17 T
-0.29 (within dynamic regions \050specialization is always) 399 661.17 P
(polyvariant at promotion points\051) 399 651.17 T
4 F
(mono_specialize) 320.88 638.67 T
1 F
(perform monovariant specialization at mer) 399 638.67 T
(ges) 535.27 638.67 T
5 F
(auto_promote) 320.88 626.17 T
1 F
(automatically insert a dynamic-to-static promo-) 399 626.17 T
(tion when the annotated static variable is possi-) 399 616.17 T
(bly assigned a dynamic value) 399 606.17 T
4 F
(manual_promote) 320.88 593.67 T
1 F
(introduce promotions only at explicit) 399 593.67 T
4 F
(make_static) 399 583.67 T
1 F
( annotations) 451.8 583.67 T
7 F
(cache_all) 320.88 571.17 T
(_unchecked) 330.48 561.17 T
1 F
-0.4 (specialize at mer) 399 571.17 P
-0.4 (ges, assuming that the context is) 451.82 571.17 P
(dif) 399 561.17 T
(ferent than any previous or subsequent spe-) 407.74 561.17 T
(cialization) 399 551.17 T
5 F
(cache_all) 320.88 538.67 T
1 F
(cache each specialized version at mer) 399 538.67 T
(ges) 519.03 538.67 T
4 F
(cache_one) 320.88 526.17 T
1 F
(cache only latest version at mer) 399 526.17 T
(ges, throwing) 499.94 526.17 T
(away previous version if context changes) 399 516.17 T
7 F
(cache_one) 320.88 503.67 T
(_unchecked) 330.48 493.67 T
1 F
-0.09 (cache one version, and assume the context is the) 399 503.67 P
(same for all future executions of this mer) 399 493.67 T
(ge) 530.61 493.67 T
7 F
(promote_all) 320.88 481.17 T
(_unchecked) 330.48 471.17 T
1 F
-0.32 (specialize at promotion points, assuming that the) 399 481.17 P
-0.03 (promoted value is dif) 399 471.17 P
-0.03 (ferent than any previous or) 466.97 471.17 P
(subsequent specialization) 399 461.17 T
5 F
(promote_all) 320.88 448.67 T
1 F
(cache all specialized versions at promotion) 399 448.67 T
(points) 399 438.67 T
4 F
(promote_one) 320.88 426.17 T
1 F
(cache only latest version at promotion points) 399 426.17 T
7 F
(promote_one) 320.88 413.67 T
(_unchecked) 330.48 403.67 T
1 F
(cache one version, and assume promoted value) 399 413.67 T
(is the same for all future executions of this pro-) 399 403.67 T
(motion) 399 393.67 T
4 F
(lazy) 320.88 381.17 T
1 F
(suspend specialization at all dynamic branches,) 399 381.17 T
(avoiding all speculative code generation) 399 371.17 T
4 F
(specialize_lazy) 320.88 358.67 T
1 F
(suspend specialization at all dynamic branch) 399 358.67 T
(successors dominating specializable mer) 399 348.67 T
(ge) 528.83 348.67 T
-0.18 (points and specializable call sites, avoiding spec-) 399 338.67 P
(ulative specialization of multiple versions of) 399 328.67 T
(code after mer) 399 318.67 T
(ges) 445.06 318.67 T
5 F
(loop_specialize) 320.88 306.17 T
(_lazy) 330.48 296.17 T
1 F
(suspend specialization at all dynamic branch) 399 306.17 T
(successors dominating specializable loop head) 399 296.17 T
(mer) 399 286.17 T
(ge points and specializable call sites, allow-) 411.3 286.17 T
(ing speculative specialization except where it) 399 276.17 T
(might be unbounded) 399 266.17 T
7 F
(eager) 320.88 253.67 T
1 F
(eagerly specialize successors of branches,) 399 253.67 T
(assuming that no unbounded specialization will) 399 243.67 T
(result, allowing full speculative specialization) 399 233.67 T
317.88 721.75 317.88 229.75 2 L
V
0.5 H
0 Z
N
396 722.25 396 229.25 2 L
V
N
558 721.75 558 229.75 2 L
V
N
317.63 722 558.25 722 2 L
V
N
317.63 704.5 558.25 704.5 2 L
V
2 H
N
317.63 692 558.25 692 2 L
V
0.5 H
N
317.63 679.5 558.25 679.5 2 L
V
2 H
N
317.63 647 558.25 647 2 L
V
0.5 H
N
317.63 634.5 558.25 634.5 2 L
V
2 H
N
317.63 602 558.25 602 2 L
V
0.5 H
N
317.63 579.5 558.25 579.5 2 L
V
2 H
N
317.63 547 558.25 547 2 L
V
0.5 H
N
317.63 534.5 558.25 534.5 2 L
V
N
317.63 512 558.25 512 2 L
V
N
317.63 489.5 558.25 489.5 2 L
V
2 H
N
317.63 457 558.25 457 2 L
V
0.5 H
N
317.63 434.5 558.25 434.5 2 L
V
N
317.63 422 558.25 422 2 L
V
N
317.63 389.5 558.25 389.5 2 L
V
2 H
N
317.63 367 558.25 367 2 L
V
0.5 H
N
317.63 314.5 558.25 314.5 2 L
V
N
317.63 262 558.25 262 2 L
V
N
317.63 229.5 558.25 229.5 2 L
V
N
0 0 0 1 0 0 0 K
FMENDPAGE
%%EndPage: "5" 5
%%Page: "6" 6
612 792 0 FMBEGINPAGE
[0 0 0 1 0 0 0]
[ 0 1 1 0 1 0 0]
[ 1 0 1 0 0 1 0]
[ 1 1 0 0 0 0 1]
[ 1 0 0 0 0 1 1]
[ 0 1 0 0 1 0 1]
[ 0 0 1 0 1 1 0]
 7 FrameSetSepColors
FrameNoSep
0 0 0 1 0 0 0 K
54 26 558 44 R
7 X
0 0 0 1 0 0 0 K
V
0 0 0 1 0 0 0 K
0 0 0 1 0 0 0 K
54 72 294.12 738 R
V
1 9 Q
0 X
0.71 (polyvariant specialization of the promoted value beginning at the) 54 732 P
(promotion point.) 54 722 T
2 10 Q
(4.3) 54 705.08 T
(Common Idioms) 72 705.08 T
1 9 Q
-0.46 (W) 54 690.5 P
-0.46 (e designed the annotations to ef) 61.78 690.5 P
-0.46 (fect particular optimizations, such) 173.03 690.5 P
0.15 (as specializing for true run-time constants \050variables whose values) 54 680.5 P
0.32 (remain invariant after initialization at run time\051 or multi-way loop) 54 670.5 P
0.71 (unrolling \050specializing a loop along multiple dynamic paths as in) 54 660.5 P
2.83 (Figure 1\051. Hence, these common optimizations can easily be) 54 650.5 P
1.04 (obtained by the use of concise idioms. For example, a region of) 54 640.5 P
-0.06 (code may be specialized for the value of a true run-time constant) 54 630.5 P
4 F
-0.14 (x) 288.72 630.5 P
1 F
(by using the) 54 620.5 T
4 F
(promote_one_unchecked) 100.25 620.5 T
1 F
( policy:) 213.65 620.5 T
4 8 Q
(make_static\050x:promote_one_unchecked\051;) 61.2 608.92 T
1 9 Q
2.89 (Alternatively) 54 597 P
2.89 (, to conditionally unroll loops shorter than some) 100.91 597 P
(threshold, the following idiom is used:) 54 587 T
4 8 Q
(if \050n < threshold\051 make_static\050n,i:eager\051;) 61.2 575.42 T
(for \050i=0; i<n; i++\051 {) 61.2 566.67 T
(...) 68.4 558.67 T
(}) 61.2 550.67 T
1 9 Q
0.87 (W) 54 538.75 P
0.87 (e achieve a substantial ef) 61.78 538.75 P
0.87 (fect with little annotation because the) 155.05 538.75 P
-0.45 (default policies of the annotations induce the most aggressive \050safe\051) 54 528.75 P
-0.12 (level of specialization \050polyvariant specialization and division, and) 54 518.75 P
1.77 (automatic dynamic-to-static promotion\051. W) 54 508.75 P
1.77 (e have also placed a) 215.07 508.75 P
2.21 (signi\336cant burden on our analyses in that they must clean up) 54 498.75 P
-0.05 (\322sloppy\323 annotations. In this example, the programmer most likely) 54 488.75 P
1.16 (does not require automatic promotion for) 54 478.75 P
4 F
2.78 (n) 211.44 478.75 P
1 F
1.16 ( or) 216.84 478.75 P
4 F
2.78 (i) 231.16 478.75 P
1 F
1.16 (, or polyvariant) 236.56 478.75 P
3.1 (specialization for) 54 468.75 P
4 F
7.43 (n) 124.68 468.75 P
1 F
3.1 ( at control-\337ow mer) 130.08 468.75 P
3.1 (ges. Furthermore, the) 210.94 468.75 P
-0.52 (programmer annotates) 54 458.75 P
4 F
-1.25 (i) 135.94 458.75 P
1 F
-0.52 ( when it is dead, and probably also does not) 141.34 458.75 P
1.51 (wish to specialize code following the loop for) 54 448.75 P
4 F
3.63 (i) 233.07 448.75 P
1 F
1.51 (. However) 238.47 448.75 P
1.51 (, the) 277.11 448.75 P
-0.17 (programmer is not penalized for specifying more powerful policies) 54 438.75 P
0.52 (than are required, and our system uses live-variables analysis and) 54 428.75 P
4.38 (performs other optimizations \050e.g., unit-boundary clustering,) 54 418.75 P
0.2 (described in section 6.3\051 to minimize the cost of the speci\336ed run-) 54 408.75 P
(time specialization.) 54 398.75 T
0.67 (Finally) 54 385.5 P
0.67 (, note that) 78.92 385.5 P
4 F
1.62 (i) 118.94 385.5 P
1 F
0.67 ( is a derived static variable after it is assigned) 124.34 385.5 P
3.84 (zero, and no dynamic-to-static promotion of) 54 375.5 P
4 F
9.23 (i) 238.29 375.5 P
1 F
3.84 ( is required.) 243.69 375.5 P
0.56 (However) 54 365.5 P
0.56 (, the loop would not be unrolled if) 86.62 365.5 P
4 F
1.34 (i) 216.32 365.5 P
1 F
0.56 ( were not annotated) 221.72 365.5 P
1.55 (because we treat unannotated derived static variables as if they) 54 355.5 P
3.08 (were set to the weakest level of specialization \050monovariant) 54 345.5 P
3.38 (specialization and division and manual promotion\051, to avoid) 54 335.5 P
2.44 (incurring run-time specialization expense without explicit user) 54 325.5 P
(direction.) 54 315.5 T
2 10 Q
(4.4) 54 298.58 T
(Partially Static Data Structur) 72 298.58 T
(es) 198.19 298.58 T
1 9 Q
3.83 (Another common idiom is to perform a memory reference) 54 284 P
0.38 (operation \050reading a variable, dereferencing a pointer) 54 274 P
0.38 (, or indexing) 247.61 274 P
0.61 (an array\051 whose result is intended to be a run-time constant. This) 54 264 P
1.52 (occurs, for example, when manipulating a \050partially\051 static data) 54 254 P
-0.24 (structure. By default, the result of a load operation is not a run-time) 54 244 P
0.55 (constant, even if its address is a run-time constant. T) 54 234 P
0.55 (o inform our) 247.53 234 P
2.46 (system that the loaded result should be treated as a run-time) 54 224 P
(constant, the following code can be written:) 54 214 T
4 8 Q
(make_static\050t\051;) 61.2 202.42 T
(t = *p;) 61.2 194.42 T
(... /*) 61.2 186.42 T
0 F
(later uses of) 94.8 186.42 T
4 F
(t) 140.6 186.42 T
0 F
( are specialized for) 145.4 186.42 T
4 F
(t) 214.76 186.42 T
0 F
(\325s value */) 219.56 186.42 T
4 F
( ...) 254.24 186.42 T
1 9 Q
0.77 (This will introduce an automatic promotion and associated cache) 54 174.5 P
0.15 (check at each execution of the load. If the programmer knows that) 54 164.5 P
-0.36 (the result of the dereference will always be the same for a particular) 54 154.5 P
6.17 (run-time constant address, the programmer can use the) 54 144.5 P
4 F
(promote_one_unchecked) 54 134.5 T
1 F
( annotation:) 167.4 134.5 T
4 8 Q
(make_static\050t:promote_one_unchecked\051;) 61.2 122.92 T
(t = *p;) 61.2 114.92 T
(... /*) 61.2 106.92 T
0 F
(later uses of) 94.8 106.92 T
4 F
(t) 140.6 106.92 T
0 F
( are specialized for) 145.4 106.92 T
4 F
(t) 214.76 106.92 T
0 F
(\325s) 219.56 106.92 T
8 F
(first) 227.56 106.92 T
0 F
( value */) 240.45 106.92 T
4 F
( ...) 269.35 106.92 T
1 9 Q
-0.47 (However) 54 95 P
-0.47 (, the semantics of this annotation still delays specialization) 86.62 95 P
-0.43 (until program execution reaches the dereference point the \336rst time.) 54 85 P
1.28 (T) 54 75 P
1.28 (o avoid any run-time overhead in the specialized code for this) 58.87 75 P
317.88 72 558 738 R
7 X
V
0 X
1.24 (dereference, the programmer must state that the load instruction) 317.88 732 P
-0.01 (itself is a static computation, returning a run-time constant result if) 317.88 722 P
2.2 (its ar) 317.88 712 P
2.2 (gument address is a run-time constant. In our annotation) 337.67 712 P
2.85 (language, a memory-reference operation \050a variable access, a) 317.88 702 P
0.41 (pointer dereference, or an array index expression\051 can be pre\336xed) 317.88 692 P
0.19 (with the) 317.88 682 P
4 F
0.45 (static) 349.75 682 P
1 F
0.19 ( keyword, indicating that the associated memory) 382.15 682 P
-0.01 (load should be done at specialization time, assuming the pointer or) 317.88 672 P
2.29 (array is static at that point. The programmer can use a static) 317.88 662 P
(dereference in this example as follows:) 317.88 652 T
4 8 Q
(make_static\050p\051;) 325.08 639.83 T
(...) 325.08 631.83 T
(t = static* p;) 325.08 623.83 T
(... /*) 325.08 615.83 T
0 F
(later uses of) 358.68 615.83 T
4 F
(t) 404.48 615.83 T
0 F
( are specialized for) 409.28 615.83 T
4 F
(t) 478.64 615.83 T
0 F
(\325s value) 483.44 615.83 T
8 F
(at specialization time) 367.22 607.83 T
0 F
( */) 441.47 607.83 T
4 F
( ...) 449.03 607.83 T
1 9 Q
0.5 (The) 317.88 595.33 P
4 F
1.2 (static) 334.63 595.33 P
1 F
0.5 ( pre\336x is a potentially unsafe programmer assertion.) 367.03 595.33 P
1.52 (Alternatively) 317.88 585.33 P
1.52 (, we could attempt to perform alias and side-ef) 364.79 585.33 P
1.52 (fect) 544.51 585.33 P
0.52 (analysis to determine automatically which parts of data structures) 317.88 575.33 P
-0.47 (are run-time constants. Unfortunately) 317.88 565.33 P
-0.47 (, it is extremely challenging to) 450.86 565.33 P
0.8 (produce a safe yet ef) 317.88 555.33 P
0.8 (fective alias and side-ef) 395.39 555.33 P
0.8 (fect analysis for this) 482.86 555.33 P
1.85 (task, because the analysis would have to reason about aliasing) 317.88 545.33 P
1.89 (relationships over the whole program \050not just within dynamic) 317.88 535.33 P
-0.22 (regions\051 and also about the temporal order of execution of dif) 317.88 525.33 P
-0.22 (ferent) 537.01 525.33 P
0.71 (parts of the program \050e.g., side-ef) 317.88 515.33 P
0.71 (fects that occur to construct the) 441.73 515.33 P
0.49 (run-time data structures before the dynamic region is \336rst entered) 317.88 505.33 P
0.3 (should be ignored\051. Sound, ef) 317.88 495.33 P
0.3 (fective interprocedural alias analysis) 425.39 495.33 P
-0.26 (for lower) 317.88 485.33 P
-0.26 (-level languages like C is an open problem and the subject) 350.67 485.33 P
-0.38 (of ongoing research [W) 317.88 475.33 P
-0.38 (ilson & Lam 95, Steensgaard 96], and so we) 401.59 475.33 P
1.18 (do not attempt to solve the full problem as part of our dynamic) 317.88 465.33 P
-0.08 (compilation system; our current system includes only simple, local) 317.88 455.33 P
1.39 (information, such as that local variables that have not had their) 317.88 445.33 P
2.02 (addresses taken are not aliases of any other expression. When) 317.88 435.33 P
1.01 (ef) 317.88 425.33 P
1.01 (fective alias analyses are developed, we can include them as a) 324.71 425.33 P
1.65 (component of our system; even so, there may still be need for) 317.88 415.33 P
1.41 (explicit programmer annotations to provide information that the) 317.88 405.33 P
5.09 (automatic analysis was unable to deduce. Other dynamic) 317.88 395.33 P
0.83 (compilation systems either include an analysis that operates only) 317.88 385.33 P
0.34 (within a dynamic region and is unsafe in the face of some legal C) 317.88 375.33 P
0.6 (programs \050T) 317.88 365.33 P
0.6 (empo\051, disallow side-ef) 362.59 365.33 P
0.6 (fects entirely \050Fabius\051, or rely) 448.37 365.33 P
(on the programmer to perform only legal optimizations \050`C\051.) 317.88 355.33 T
1.26 (Instead of, or in addition to, providing annotations at individual) 317.88 341.5 P
0.35 (dereference operations, we could provide higher) 317.88 331.5 P
0.35 (-level annotations) 493.4 331.5 P
2.29 (of static vs. dynamic components along with variable or type) 317.88 321.5 P
0.32 (declarations. For example, the p variable could be declared with a) 317.88 311.5 P
2.74 (type such as) 317.88 301.5 P
4 F
6.57 (constant*) 372.34 301.5 P
1 F
2.74 ( rather than) 420.94 301.5 P
4 F
6.57 (*) 472.39 301.5 P
1 F
2.74 (, to indicate that all) 477.8 301.5 P
4.56 (dereferences would result in run-time constant values; the) 317.88 291.5 P
4 F
4.21 (bytecodes) 317.88 281.5 P
1 F
1.75 ( array in the initial example in Figure 1 could be) 366.48 281.5 P
0.98 (declared as) 317.88 271.5 P
4 F
2.35 (constant) 362.32 271.5 P
2.35 (int) 408.75 271.5 P
2.35 (bytecodes[]) 428.18 271.5 P
1 F
0.98 ( to indicate that its) 487.58 271.5 P
0.18 (contents were run-time constants, thereby eliminating the need for) 317.88 261.5 P
1.77 (the four) 317.88 251.5 P
4 F
4.24 (static) 351.91 251.5 P
1 F
1.77 ( pre\336x annotations on the) 384.31 251.5 P
4 F
4.24 (bytecodes) 486.9 251.5 P
1 F
1.77 ( array) 535.49 251.5 P
2.36 (index expressions in the example. T) 317.88 241.5 P
2.36 (empo follows this sort of) 458.55 241.5 P
0.08 (approach, at least for \336elds of) 317.88 231.5 P
4 F
0.18 (struct) 427.56 231.5 P
1 F
0.08 ( types. This syntactic sugar) 459.96 231.5 P
(may be a worthwhile addition to our system.) 317.88 221.5 T
2 10 Q
(4.5) 317.88 204 T
(Interpr) 335.88 204 T
(ocedural Annotations) 367.36 204 T
1 9 Q
2.14 (Run-time specialization normally applies within the body of a) 317.88 188.83 P
0.43 (single procedure: calls to a procedure) 317.88 178.83 P
4 F
1.03 (P) 457.41 178.83 P
1 F
0.43 ( from within a specialized) 462.81 178.83 P
0.85 (region all branch to the same unspecialized version of) 317.88 168.83 P
4 F
2.04 (P) 521.75 168.83 P
1 F
0.85 (.) 526.15 168.83 P
4 F
2.04 (P) 531.5 168.83 P
1 F
0.85 ( itself) 536.9 168.83 P
0.57 (may have another specialized region in its body) 317.88 158.83 P
0.57 (, but this break in) 492.98 158.83 P
0.09 (the specialized code will cause all the dif) 317.88 148.83 P
0.09 (ferent specialized calls of) 466.03 148.83 P
4 F
0.51 (P) 317.88 138.83 P
1 F
0.22 ( to mer) 323.28 138.83 P
0.22 (ge together) 349.04 138.83 P
0.22 (, only to be split back apart again by the cache) 389.14 138.83 P
-0.22 (checks at the) 317.88 128.83 P
4 F
-0.53 (make_static) 365.96 128.83 P
1 F
-0.22 ( annotation at) 425.36 128.83 P
4 F
-0.53 (P) 475.94 128.83 P
1 F
-0.22 (\325) 481.34 128.83 P
-0.22 (s entry) 483.85 128.83 P
-0.22 (. T) 507.29 128.83 P
-0.22 (o avoid this) 516.44 128.83 P
3.78 (overhead, calls can themselves be specialized, branching to) 317.88 118.83 P
3.4 (correspondingly specialized versions of the callee procedure,) 317.88 108.83 P
(thereby extending dynamic regions across procedure boundaries.) 317.88 98.83 T
1.64 (The) 317.88 85 P
4 F
3.95 (specialize) 335.77 85 P
1 F
1.64 ( annotation names a procedure with a given) 389.77 85 P
2.48 (number of ar) 317.88 75 P
2.48 (guments and provides a list of divisions for the) 369.16 75 P
0 0 0 1 0 0 0 K
FMENDPAGE
%%EndPage: "6" 6
%%Page: "7" 7
612 792 0 FMBEGINPAGE
[0 0 0 1 0 0 0]
[ 0 1 1 0 1 0 0]
[ 1 0 1 0 0 1 0]
[ 1 1 0 0 0 0 1]
[ 1 0 0 0 0 1 1]
[ 0 1 0 0 1 0 1]
[ 0 0 1 0 1 1 0]
 7 FrameSetSepColors
FrameNoSep
0 0 0 1 0 0 0 K
54 26 558 44 R
7 X
0 0 0 1 0 0 0 K
V
0 0 0 1 0 0 0 K
0 0 0 1 0 0 0 K
54 72 294.12 738 R
V
1 9 Q
0 X
1.35 (procedure. Each division lists a non-empty subset of the formal) 54 732 P
0.52 (parameters of the procedure to be treated as run-time constants; a) 54 722 P
-0.55 (division can specify any of the same policies for listed variables that) 54 712 P
0.45 (a) 54 702 P
4 F
1.08 (make_static) 60.69 702 P
1 F
0.45 ( annotation can specify) 120.1 702 P
0.45 (. As described in section) 204.09 702 P
0.22 (6, for each division, our system\325) 54 692 P
0.22 (s static compiler produces a code-) 170.82 692 P
-0.07 (generation procedure \050i.e., a generating extension\051 for that division) 54 682 P
1.06 (that takes the static formals as ar) 54 672 P
1.06 (guments and, when invoked on) 177.65 672 P
1.53 (their run-time values, produces a specialized residual procedure) 54 662 P
1.34 (that takes the remaining ar) 54 652 P
1.34 (guments of the original procedure \050if) 154.69 652 P
(any\051, in classical partial-evaluation style.) 54 642 T
0.69 (At each call site in a specialized region to a procedure) 54 626.2 P
4 F
1.67 (P) 258.33 626.2 P
1 F
0.69 ( with an) 263.73 626.2 P
1.24 (associated) 54 616.2 P
4 F
2.96 (specialize) 94.48 616.2 P
1 F
1.24 ( annotation, our system will search for) 148.48 616.2 P
0.34 (the division speci\336ed for) 54 606.2 P
4 F
0.82 (P) 146.87 606.2 P
1 F
0.34 (that most closely matches the division) 155.15 606.2 P
-0.02 (of actual ar) 54 596.2 P
-0.02 (guments at the call site \050favoring divisions listed earlier) 94.28 596.2 P
-0.35 (in) 54 586.2 P
4 F
-0.85 (P) 62.9 586.2 P
1 F
-0.35 (\325) 68.3 586.2 P
-0.35 (s) 70.8 586.2 P
4 F
-0.85 (specialize) 76.19 586.2 P
1 F
-0.35 ( annotation in case of ties\051. If one is found, the) 130.2 586.2 P
-0.41 (static compiler produces code that, when specializing the call site at) 54 576.2 P
1.91 (run time, \0501\051 invokes the generating extension for the selected) 54 566.2 P
0.68 (division of) 54 556.2 P
4 F
1.62 (P) 96.36 556.2 P
1 F
0.68 (, passing the necessary run-time constant ar) 100.76 556.2 P
0.68 (guments,) 261.37 556.2 P
1.21 (and \0502\051 generates code that will invoke the resulting specialized) 54 546.2 P
1.05 (version for) 54 536.2 P
4 F
2.51 (P) 97.58 536.2 P
1 F
1.05 (, passing any remaining ar) 101.98 536.2 P
1.05 (guments. Thus, when the) 200.74 536.2 P
-0.09 (specialized call is eventually executed, the call will branch directly) 54 526.2 P
2.82 (to the specialized callee and pass only the run-time variable) 54 516.2 P
0.15 (ar) 54 506.2 P
0.15 (guments. If no division speci\336ed for) 60.83 506.2 P
4 F
0.36 (P) 194.48 506.2 P
1 F
0.15 ( matches the call, then the) 199.88 506.2 P
0.58 (general unspecialized version of) 54 496.2 P
4 F
1.39 (P) 174.78 496.2 P
1 F
0.58 ( is called. Calls to) 180.18 496.2 P
4 F
1.39 (P) 249.57 496.2 P
1 F
0.58 ( outside of) 254.97 496.2 P
-0.4 (any dynamic region continue to invoke the unspecialized version of) 54 486.2 P
4 F
(P) 54 476.2 T
1 F
(.) 58.4 476.2 T
2.43 (The) 54 460.39 P
4 F
5.83 (constant) 72.67 460.39 P
1 F
2.43 ( pre\336x to the) 115.87 460.39 P
4 F
5.83 (specialize) 173.59 460.39 P
1 F
2.43 ( annotation is an) 227.59 460.39 P
-0.16 (\050unsafe\051 assertion by the programmer than the annotated procedure) 54 450.39 P
0.33 (acts like a pure function, returning the same result given the same) 54 440.39 P
0.74 (ar) 54 430.39 P
0.74 (guments without looping forever) 60.83 430.39 P
0.74 (, making externally observable) 180.93 430.39 P
1.6 (side-ef) 54 420.39 P
1.6 (fects, or generating any exceptions or faults. Our system) 78.33 420.39 P
0.88 (exploits this information by calling a constant function from call) 54 410.39 P
-0.07 (sites with all static ar) 54 400.39 P
-0.07 (guments at specialization time and treating its) 129.55 400.39 P
1.77 (result as a run-time constant, i.e., reducing the call rather than) 54 390.39 P
-0.35 (specializing or residualizing the call. This behavior is dif) 54 380.39 P
-0.35 (ferent than) 255.74 380.39 P
1.33 (simply providing a specialization division where all formals are) 54 370.39 P
-0.44 (static, since that would leave a zero-ar) 54 360.39 P
-0.44 (gument call in the specialized) 188.9 360.39 P
(code whose result was a dynamic value.) 54 350.39 T
-0.1 (The callee procedure and any call sites can be compiled separately) 54 334.58 P
-0.1 (.) 291.87 334.58 P
1.34 (All that they need to agree on is the) 54 324.58 P
4 F
3.21 (specialize) 196.28 324.58 P
1 F
1.34 ( annotation,) 250.28 324.58 P
0.11 (which typically is put next to the procedure\325) 54 314.58 P
0.11 (s) 213.51 314.58 P
4 F
0.27 (extern) 219.37 314.58 P
1 F
0.11 ( declaration) 251.77 314.58 P
(in a header \336le.) 54 304.58 T
2 12 Q
(5) 54 280.78 T
(Analysis of the Annotations) 72 280.78 T
1 9 Q
3.13 (Given the programmer annotations described in the previous) 54 262.98 P
-0.37 (section, our system performs data\337ow analysis akin to binding time) 54 252.98 P
-0.3 (analysis over each procedure\325) 54 242.98 P
-0.3 (s control-\337ow graph representation to) 159.83 242.98 P
4.27 (compute where and how run-time specialization should be) 54 232.98 P
1.3 (performed. The output of this analysis is information associated) 54 222.98 P
1.32 (with each program point \050each edge between instructions in the) 54 212.98 P
-0.56 (control \337ow graph\051; the domain of the information,) 54 202.98 P
4 F
-1.34 (BTA) 236.28 202.98 P
1 F
-0.56 (, along with) 252.48 202.98 P
0.21 (some constraints on its form, is speci\336ed in Figure 5.) 54 192.98 P
1 7.2 Q
0.17 (*) 246.6 196.58 P
1 9 Q
0.21 ( This output) 250.2 192.98 P
-0.03 (is used to produce the generating extension which invokes the run-) 54 182.98 P
(time specializer) 54 172.98 T
(, as described in section 6.) 110.38 172.98 T
54 155 294.12 169.98 C
0 0 0 1 0 0 0 K
0 0 0 1 0 0 0 K
54 155 294.12 169.98 R
7 X
0 0 0 1 0 0 0 K
V
54 160.91 207 160.91 2 L
V
0.5 H
2 Z
0 X
N
0 0 612 792 C
1 6.4 Q
0 X
0 0 0 1 0 0 0 K
(*) 54 152.87 T
1 8 Q
0.71 (In our notation,) 59.68 149.67 P
6 F
0.71 (\256) 113.37 149.67 P
1 F
0.71 ( constructs the domain of partial finite maps \050sets of) 121.27 149.67 P
0.63 (ordered pairs\051 from one domain to another,) 59.68 140.67 P
0 F
0.7 (dom) 204.05 140.67 P
1 F
0.63 ( and) 219.61 140.67 P
0 F
0.7 (range) 236.41 140.67 P
1 F
0.63 ( project the) 256.87 140.67 P
0.59 (first and second elements, respectively, of the ordered pairs in the map,) 59.68 131.67 P
0.43 (and applying a map) 59.68 122.67 P
0 F
0.48 (f) 126.27 122.67 P
1 F
0.43 ( to an element in) 128.49 122.67 P
0 F
0.48 (dom\050f\051) 185.96 122.67 P
1 F
0.43 ( returns the corresponding) 209.07 122.67 P
0.14 (range element. We use) 59.68 113.67 P
6 F
0.14 (\201\264) 135.12 113.67 P
1 F
0.14 (to construct cross-product domains. We write) 147.65 113.67 P
8 F
3.24 (D) 59.68 104.67 P
0 F
3.24 (\050p\051) 65.45 104.67 P
1 F
2.91 ( to project from the product) 75.23 104.67 P
0 F
3.24 (p) 182.92 104.67 P
1 F
2.91 ( the element corresponding to) 187.37 104.67 P
-0.03 (component domain) 59.68 95.67 P
8 F
-0.03 (D) 123.18 95.67 P
1 F
-0.03 (, and we write) 128.95 95.67 P
0 F
-0.03 (p[) 176.17 95.67 P
8 F
-0.03 (D) 182.84 95.67 P
6 F
-0.03 (\256) 188.62 95.67 P
0 F
-0.03 (v]) 196.51 95.67 P
1 F
-0.03 ( to compute a new product) 202.74 95.67 P
0 F
-0.03 (p) 289.67 95.67 P
1 F
2.62 (whose) 59.68 86.67 P
8 F
2.92 (D) 84.74 86.67 P
1 F
2.62 ( element has value) 90.52 86.67 P
0 F
2.92 (v) 162.34 86.67 P
1 F
2.62 (.) 166.34 86.67 P
0 F
2.92 (Pow) 172.96 86.67 P
1 F
2.62 ( denotes the powerset domain) 188.52 86.67 P
(constructor. Note that) 59.68 77.67 T
3 F
(A) 131.22 77.67 T
6 F
(\256) 136.11 77.67 T
3 F
(B) 144.01 77.67 T
6 F
(\315) 150.89 77.67 T
0 F
(Pow) 158.6 77.67 T
1 F
(\050) 174.16 77.67 T
3 F
(A) 176.82 77.67 T
6 F
(\264) 181.71 77.67 T
3 F
(B) 186.1 77.67 T
1 F
(\051.) 190.99 77.67 T
317.88 72 558 738 R
7 X
V
317.88 72 558 738 C
0 0 0 1 0 0 0 K
0 0 0 1 0 0 0 K
317.88 72 557.3 738 R
7 X
0 0 0 1 0 0 0 K
V
2 9 Q
0 X
(Domains:) 317.88 732 T
0 8 Q
(BTA) 317.88 720.67 T
6 F
(\272) 335.66 720.67 T
0 F
( Division) 340.06 720.67 T
6 F
(\256) 372.5 720.67 T
0 F
( DivisionInfo) 380.4 720.67 T
(DivisionInfo) 317.88 708.67 T
6 F
(\272) 361.45 708.67 T
0 F
( StaticVarInfo) 365.84 708.67 T
6 F
(\264) 416.09 708.67 T
0 F
( Promotions) 420.48 708.67 T
6 F
(\264) 465.38 708.67 T
0 F
( DiscordantVars) 469.78 708.67 T
(Division) 317.88 696.67 T
6 F
(\272) 348.1 696.67 T
0 F
( Var) 352.5 696.67 T
6 F
(\256) 369.39 696.67 T
0 F
( Policies) 377.29 696.67 T
-0.02 (Var) 317.88 684.67 P
6 F
-0.01 (\272) 332.54 684.67 P
8 F
-0.02 (finite set of all variables in scope of procedure being compiled) 339.14 684.67 P
0 F
(Policies) 317.88 672.67 T
6 F
(\272) 347.66 672.67 T
0 F
( DivisionPolicy) 352.06 672.67 T
6 F
(\264) 405.84 672.67 T
0 F
(SpecializationPolicy) 412.23 672.67 T
6 F
(\264) 485.14 672.67 T
0 F
(PromotionPolicy) 355.69 662.67 T
6 F
(\264) 415.7 662.67 T
0 F
(MergeCachingPolicy) 355.69 652.67 T
6 F
(\264) 431.26 652.67 T
0 F
(PromotionCachingPolicy) 437.66 652.67 T
6 F
(\264) 527.02 652.67 T
0 F
(LazinessPolicy) 355.69 642.67 T
(DivisionPolicy) 317.88 630.67 T
6 F
(\272) 369.44 630.67 T
0 F
( {PolyDivision, MonoDivision}) 373.83 630.67 T
(SpecializtionPolicy) 317.88 618.67 T
6 F
(\272) 386.34 618.67 T
0 F
({PolySpecialization, MonoSpecialization}) 392.74 618.67 T
(PromotionPolicy) 317.88 606.67 T
6 F
(\272) 377.9 606.67 T
0 F
( {AutoPromote, ManualPromote}) 382.29 606.67 T
(MergeCachingPolicy) 317.88 594.67 T
6 F
(\272) 393.46 594.67 T
0 F
({CacheAllUnchecked, CacheAll,) 399.85 594.67 T
(CacheOne, CacheOneUnchecked}) 406.84 584.67 T
(PromotionCachingPolicy) 317.88 572.67 T
6 F
(\272) 407.24 572.67 T
0 F
( {CacheAllUnchecked, CacheAll,) 411.63 572.67 T
(CacheOne, CacheOneUnchecked}) 420.18 562.67 T
(LazinessPolicy) 317.88 550.67 T
6 F
(\272) 373.01 550.67 T
0 F
({Lazy, SpecializeLazy, LoopSpecializeLazy, Eager}) 325.08 540.67 T
(StaticVarInfo) 317.88 528.67 T
6 F
(\272) 365.9 528.67 T
0 F
( Var) 370.3 528.67 T
6 F
(\256) 387.19 528.67 T
0 F
( CachingPolicy) 395.09 528.67 T
6 F
(\264) 450.22 528.67 T
0 F
( SourceRoots) 454.61 528.67 T
(CachingPolicy) 317.88 516.67 T
6 F
(\272) 370.78 516.67 T
0 F
({CacheAllUnchecked, CacheAll,) 377.18 516.67 T
(CacheOne, CacheOneUnchecked}) 382.38 506.67 T
(SourceRoots) 317.88 494.67 T
6 F
(\272) 366.34 494.67 T
0 F
( Pow\050Var\051) 370.74 494.67 T
(Promotions) 317.88 482.67 T
6 F
(\272) 360.56 482.67 T
0 F
( Pow\050Var\051) 364.95 482.67 T
(DiscordantVars) 317.88 470.67 T
6 F
(\272) 374.78 470.67 T
0 F
( Pow\050Var\051) 379.18 470.67 T
(LiveVars) 317.88 458.67 T
6 F
(\272) 351.22 458.67 T
0 F
( Pow\050Var\051) 355.62 458.67 T
(UsedVars) 317.88 446.67 T
6 F
(\272) 355.22 446.67 T
0 F
( Pow\050Var\051) 359.62 446.67 T
(MayDefVars) 317.88 434.67 T
6 F
(\272) 364.11 434.67 T
0 F
( Pow\050Var\051) 368.5 434.67 T
(Specializations) 317.88 422.67 T
6 F
(\272) 373.46 422.67 T
0 F
( Proc) 377.85 422.67 T
6 F
(\256) 398.74 422.67 T
0 F
( SpecializationInfo) 406.64 422.67 T
-0.35 (Proc) 317.88 410.67 P
6 F
-0.31 (\272) 336.2 410.67 P
8 F
-0.35 (finite set of all procedures in scope of function being compiled) 342.47 410.67 P
0 F
(SpecializationInfo) 317.88 398.67 T
6 F
(\272) 382.8 398.67 T
0 F
( IsConstant) 387.19 398.67 T
6 F
(\264) 429.88 398.67 T
0 F
( Divisions) 434.27 398.67 T
(IsConstant) 317.88 386.67 T
6 F
(\272) 358.34 386.67 T
0 F
( {Constant, NotConstant}) 362.74 386.67 T
(Divisions) 317.88 374.67 T
6 F
(\272) 352.1 374.67 T
0 F
( Pow\050Division\051) 356.5 374.67 T
2 9 Q
(Constraints:) 317.88 361 T
0 8 Q
(BTALegal\050bta:BTA\051) 317.88 349.67 T
6 F
(\272) 389.46 349.67 T
0 F
(LegalDivisions\050dom\050bta\051\051) 325.08 339.67 T
6 F
(\331) 416.21 339.67 T
(") 325.08 329.67 T
0 F
(\050d,i\051) 330.78 329.67 T
6 F
(\316) 344.56 329.67 T
0 F
(bta.) 350.26 329.67 T
(StaticVars\050i\051) 332.28 319.67 T
6 F
(\312) 375.84 319.67 T
0 F
(dom\050d\051) 381.54 319.67 T
6 F
(\331) 409.1 319.67 T
(") 332.28 309.67 T
0 F
(v) 337.98 309.67 T
6 F
(\316) 341.98 309.67 T
0 F
(StaticVars\050i\051.) 347.69 309.67 T
(\050SourceRoots\050v, i\051) 339.48 299.67 T
6 F
(\315) 403.94 299.67 T
0 F
(dom\050d\051) 409.64 299.67 T
6 F
(\331) 439.42 299.67 T
0 F
(v) 341.7 289.67 T
6 F
(\317) 345.7 289.67 T
0 F
(dom\050d\051) 351.41 289.67 T
6 F
( \336) 376.74 289.67 T
0 F
(CachingPolicy\050StaticVarInfo\050i\051\050v\051\051 =) 361.08 279.67 T
(CacheOneUnchecked\051) 368.28 269.67 T
6 F
(\331) 453.65 269.67 T
0 F
(Promotions\050i\051) 332.28 259.67 T
6 F
(\315) 379.84 259.67 T
0 F
(dom\050d\051) 385.54 259.67 T
6 F
(\331) 413.1 259.67 T
0 F
(DiscordantVars\050i\051) 332.28 249.67 T
6 F
(\315) 394.06 249.67 T
0 F
(PolySpecializationVars\050d\051) 399.77 249.67 T
(LegalDivisions\050ds:Pow\050Division\051\051) 317.88 237.67 T
6 F
(\272) 436.56 237.67 T
(") 325.08 227.67 T
0 F
(d) 330.78 227.67 T
0 6.4 Q
(1) 335.23 225.67 T
0 8 Q
(,d) 338.79 227.67 T
0 6.4 Q
(2) 345.46 225.67 T
6 8 Q
(\316) 349.02 227.67 T
0 F
(ds. d) 354.73 227.67 T
0 6.4 Q
(1) 372.07 225.67 T
0 8 Q
(=d) 375.63 227.67 T
0 6.4 Q
(2) 384.75 225.67 T
6 8 Q
(\332) 390.53 227.67 T
0 F
( SeparateDivisions\050d) 395.35 227.67 T
0 6.4 Q
(1) 469.15 225.67 T
0 8 Q
(,d) 472.71 227.67 T
0 6.4 Q
(2) 479.38 225.67 T
0 8 Q
(\051) 482.94 227.67 T
(SeparateDivisions\050d) 317.88 215.67 T
0 6.4 Q
(1) 389.46 213.67 T
0 8 Q
(:Division, d) 393.01 215.67 T
0 6.4 Q
(2) 432.13 213.67 T
0 8 Q
(:Division\051) 435.69 215.67 T
6 F
(\272) 470.8 215.67 T
0 F
(PolyDivisionVars\050d) 325.08 205.67 T
0 6.4 Q
(1) 392.2 203.67 T
0 8 Q
(\051) 395.76 205.67 T
6 F
(\271) 398.42 205.67 T
0 F
(PolyDivisionVars\050d) 402.81 205.67 T
0 6.4 Q
(2) 469.93 203.67 T
0 8 Q
(\051) 473.49 205.67 T
6 F
(\332) 478.38 205.67 T
(") 325.08 195.67 T
0 F
(v) 330.78 195.67 T
6 F
(\316) 334.78 195.67 T
0 F
(PolyDivisionVars\050d) 340.49 195.67 T
0 6.4 Q
(1) 407.61 193.67 T
0 8 Q
(\051. d) 411.17 195.67 T
0 6.4 Q
(1) 422.73 193.67 T
0 8 Q
(\050v\051) 426.29 195.67 T
6 F
(\271) 435.61 195.67 T
0 F
(d) 440 195.67 T
0 6.4 Q
(2) 444.45 193.67 T
0 8 Q
(\050v\051) 448.01 195.67 T
(PolyDivisionVars\050d:Division\051) 317.88 183.67 T
6 F
(\272) 420.11 183.67 T
0 F
({ v) 325.08 173.67 T
6 F
(\316) 333.98 173.67 T
0 F
(dom\050d\051 | DivisionPolicy\050d\050v\051\051 = PolyDivision }) 339.68 173.67 T
(PolySpecializationVars\050d:Division\051) 317.88 161.67 T
6 F
(\272) 441.46 161.67 T
0 F
({ v) 325.08 151.67 T
6 F
(\316) 333.98 151.67 T
0 F
(dom\050d\051 | SpecializationPolicy\050d\050v\051\051 = PolySpecialization }) 339.68 151.67 T
(StaticVars\050i:DivisionInfo\051) 317.88 139.67 T
6 F
(\272) 407.23 139.67 T
0 F
( dom\050StaticVarInfo\050i\051\051) 411.62 139.67 T
(SourceRoots\050v:Var, i:DivisionInfo\051) 317.88 129.67 T
6 F
(\272) 440.14 129.67 T
0 F
(if v) 325.08 119.67 T
6 F
(\316) 335.3 119.67 T
0 F
(StaticVars\050i\051 then SourceRoots\050StaticVarInfo\050i\051\050v\051\051 else) 341.01 119.67 T
6 F
(\306) 537.5 119.67 T
2 10 Q
(Figur) 397.96 100.34 T
(e 5: Domains) 421.67 100.34 T
0 0 612 792 C
0 0 0 1 0 0 0 K
FMENDPAGE
%%EndPage: "7" 7
%%Page: "8" 8
612 792 0 FMBEGINPAGE
[0 0 0 1 0 0 0]
[ 0 1 1 0 1 0 0]
[ 1 0 1 0 0 1 0]
[ 1 1 0 0 0 0 1]
[ 1 0 0 0 0 1 1]
[ 0 1 0 0 1 0 1]
[ 0 0 1 0 1 1 0]
 7 FrameSetSepColors
FrameNoSep
0 0 0 1 0 0 0 K
54 26 558 44 R
7 X
0 0 0 1 0 0 0 K
V
0 0 0 1 0 0 0 K
0 0 0 1 0 0 0 K
54 72 294.12 738 R
V
1 9 Q
0 X
0.79 (The analysis computes a set of divisions for each program point.) 54 732 P
7.91 (Each division maps variables annotated as static by) 54 722 P
4 F
2.91 (make_static) 54 712 P
1 F
1.21 ( or) 113.4 712 P
4 F
2.91 (specialize) 127.82 712 P
1 F
1.21 ( to their associated policies at) 181.82 712 P
1.57 (that program point. T) 54 702 P
1.57 (wo divisions are distinct if) 135.07 702 P
1.57 (f there is some) 236.68 702 P
1.52 (variable in one division annotated with the polyvariant division) 54 692 P
3.57 (policy that is either not found \050i.e., dynamic\051 or annotated) 54 682 P
0.47 (dif) 54 672 P
0.47 (ferently in the other division; divisions that do not dif) 63.84 672 P
0.47 (fer in the) 260.68 672 P
1.14 (policies of any variables annotated with the polyvariant division) 54 662 P
(policy will be mer) 54 652 T
(ged together by the analysis.) 119.58 652 T
1.27 (For each division the analysis computes the following pieces of) 54 635.85 P
(information:) 54 625.85 T
(\245) 61.2 610.69 T
2.03 (The analysis computes the set of static variables \050run-time) 68.4 610.69 P
-0.08 (constants\051 at that program point, including both user) 68.4 600.69 P
-0.08 (-annotated) 256.13 600.69 P
2.64 (static variables and any derived static variables computed) 68.4 590.69 P
4.04 (\050directly or indirectly\051 from an annotated variable. The) 68.4 580.69 P
-0.52 (computed set of static variables will be used to determine which) 68.4 570.69 P
-0.28 (computations and operands are static vs. which are dynamic. In) 68.4 560.69 P
-0.21 (addition, the set of static variables is used to index into the run-) 68.4 550.69 P
2.04 (time specializer caches, and consequently the analysis also) 68.4 540.69 P
3.86 (computes the appropriate caching policy for each static) 68.4 530.69 P
0.78 (variable. \050For internal purposes, the analysis tracks the set of) 68.4 520.69 P
3 (root annotated run-time constants from which each static) 68.4 510.69 P
0.86 (variable was computed, directly or indirectly) 68.4 500.69 P
0.86 (, as described in) 233.57 500.69 P
(subsection 5.3.6.\051) 68.4 490.69 T
(\245) 61.2 475.54 T
-0.38 (The analysis computes those points requiring dynamic-to-static) 68.4 475.54 P
-0.5 (promotions of variables. Non-empty promotion sets correspond) 68.4 465.54 P
1.62 (to promotion points for the listed variables. Promotions get) 68.4 455.54 P
2.32 (inserted after) 68.4 445.54 P
4 F
5.57 (make_static) 122.52 445.54 P
1 F
2.32 ( annotations for non-constant) 181.92 445.54 P
-0.53 (variables and after \050potential\051 assignments of dynamic values to) 68.4 435.54 P
(variables annotated with the auto-promotion policy) 68.4 425.54 T
(.) 252.04 425.54 T
(\245) 61.2 410.39 T
0.17 (The analysis identi\336es which mer) 68.4 410.39 P
0.17 (ge points require polyvariant) 189.89 410.39 P
0.35 (specialization \050called) 68.4 400.39 P
3 F
0.35 (discor) 147.58 400.39 P
0.35 (dant mer) 169.74 400.39 P
0.35 (ges) 202.01 400.39 P
1 F
0.35 (\051, because at least one) 214 400.39 P
1.38 (variable annotated with the polyvariant specialization policy) 68.4 390.39 P
5.12 (has potentially dif) 68.4 380.39 P
5.12 (ferent de\336nitions on dif) 143.48 380.39 P
5.12 (ferent mer) 243.43 380.39 P
5.12 (ge) 285.62 380.39 P
-0.21 (predecessors. The set of such) 68.4 370.39 P
3 F
-0.21 (discor) 174.83 370.39 P
-0.21 (dant variables) 196.99 370.39 P
1 F
-0.21 ( is computed) 248.54 370.39 P
(at these mer) 68.4 360.39 T
(ge points, and is empty at all other points.) 111.73 360.39 T
3.49 (In the remainder of this section we describe the procedure) 54 344.23 P
0.32 (representation we assume and the set of data\337ow analyses used to) 54 334.23 P
(construct this output.) 54 324.23 T
2 10 Q
(5.1) 54 304.41 T
(Pr) 72 304.41 T
(ocedur) 82.37 304.41 T
(e Repr) 111.63 304.41 T
(esentation) 140.05 304.41 T
1 9 Q
-0.43 (W) 54 286.92 P
-0.43 (e assume procedures being analyzed are represented in a standard) 61.78 286.92 P
0.37 (control-\337ow graph, where nodes in the graph can be of one of the) 54 276.92 P
(following forms:) 54 266.92 T
(\245) 61.2 251.77 T
2.52 (an operator node such as a move, add, or call, with one) 68.4 251.77 P
(predecessor and successor) 68.4 241.77 T
(,) 162.5 241.77 T
(\245) 61.2 226.61 T
(a mer) 68.4 226.61 T
(ge node with multiple predecessors and one successor) 88.48 226.61 T
(,) 282.33 226.61 T
(\245) 61.2 211.46 T
0.85 (a conditional branch node with one predecessor and multiple) 68.4 211.46 P
0.94 (successors, with a single operand that selects the appropriate) 68.4 201.46 P
(successor edge,) 68.4 191.46 T
(\245) 61.2 176.31 T
1.68 (an entry node with no predecessors and a single successor) 68.4 176.31 P
1.68 (,) 291.87 176.31 P
(which acts to bind the procedure\325) 68.4 166.31 T
(s formals upon entry) 188.13 166.31 T
(, or) 261.78 166.31 T
(\245) 61.2 151.15 T
0.65 (a return node with one predecessor and no successors, with a) 68.4 151.15 P
(single operand that is the procedure\325) 68.4 141.15 T
(s result.) 199.12 141.15 T
3.68 (T) 54 125 P
3.68 (o enable our analyses to detect when potentially dif) 58.87 125 P
3.68 (ferent) 273.13 125 P
0.98 (de\336nitions of a variable mer) 54 115 P
0.98 (ge, we assume that mer) 159.22 115 P
0.98 (ge nodes are) 247.19 115 P
2.4 (annotated with a list of variables that have dif) 54 105 P
2.4 (ferent reaching) 237.5 105 P
-0.55 (de\336nitions along dif) 54 95 P
-0.55 (ferent predecessors, yielding one variable in the) 125.24 95 P
0.38 (list for each) 54 85 P
6 F
0.38 (f) 99.89 85 P
1 F
0.38 (-function that would be inserted if we converted the) 104.58 85 P
-0.44 (procedure to static single assignment \050SSA\051 form [Cytron) 54 75 P
3 F
-0.44 (et al.) 260.49 75 P
1 F
-0.44 ( 89].) 278.06 75 P
317.88 72 558 738 R
7 X
V
0 X
(Flow graph nodes are generated from the following grammar:) 317.88 732 T
0 8 Q
(Node ::= OpNode | MergeNode | BranchNode |) 325.08 720.2 T
(EntryNode | ReturnNode) 358.44 712.2 T
(OpNode ::= MakeStaticNode | MakeDynamicNode |) 325.08 698.73 T
(ConstNode | MoveNode | UnaryNode | BinaryNode |) 371.78 690.73 T
(LoadNode | StaticLoadNode | StoreNode | CallNode) 371.78 682.73 T
(MakeStaticNode ::=) 325.08 669.27 T
4 F
(make_static\050) 397.34 669.27 T
0 F
(Var) 454.94 669.27 T
4 F
(:) 467.38 669.27 T
0 F
(Policies) 472.18 669.27 T
4 F
(\051) 499.74 669.27 T
0 F
(MakeDynamicNode ::=) 325.08 661.27 T
4 F
(make_dynamic\050) 408.44 661.27 T
0 F
(Var) 470.84 661.27 T
4 F
(\051) 483.29 661.27 T
0 F
(CostNode ::= Var) 325.08 653.27 T
4 F
(:=) 388.89 653.27 T
0 F
( Const) 398.49 653.27 T
(MoveNode ::= Var) 325.08 645.27 T
4 F
(:=) 392 645.27 T
0 F
( Var) 401.6 645.27 T
(UnaryNode ::= Var) 325.08 637.27 T
4 F
(:=) 393.78 637.27 T
0 F
( UnaryOp Var) 403.38 637.27 T
(BinaryNode ::= Var) 325.08 629.27 T
4 F
(:=) 395.11 629.27 T
0 F
( Var BinaryOp Var) 404.71 629.27 T
(LoadNode ::= Var) 325.08 621.27 T
4 F
(:=) 390.23 621.27 T
(*) 402.06 621.27 T
0 F
( Var) 406.86 621.27 T
(StaticLoadNode ::= Var) 325.08 613.27 T
4 F
(:=) 410.24 613.27 T
(static*) 422.06 613.27 T
0 F
( Var) 455.66 613.27 T
(StoreNode ::=) 325.08 605.27 T
4 F
(*) 376.89 605.27 T
0 F
( Var) 381.69 605.27 T
4 F
(:=) 398.58 605.27 T
0 F
( Var) 408.18 605.27 T
(CallNode ::= Var) 325.08 597.27 T
4 F
(:=) 386.22 597.27 T
0 F
( Proc) 395.82 597.27 T
4 F
(\050) 414.49 597.27 T
0 F
(Var) 419.29 597.27 T
4 F
(,) 431.74 597.27 T
0 F
( ...) 436.54 597.27 T
4 F
(,) 445.43 597.27 T
0 F
( Var) 450.23 597.27 T
4 F
(\051) 464.9 597.27 T
0 F
(MergeNode ::=) 325.08 583.8 T
4 F
(merge\050) 380.44 583.8 T
0 F
(Var) 409.24 583.8 T
4 F
(,) 421.69 583.8 T
0 F
( ...) 426.49 583.8 T
4 F
(,) 435.38 583.8 T
0 F
( Var) 440.18 583.8 T
4 F
(\051) 454.86 583.8 T
0 F
(BranchNode ::=) 325.08 570.33 T
4 F
(test) 383.11 570.33 T
0 F
( Var) 402.31 570.33 T
(EntryNode ::=) 325.08 556.87 T
4 F
(enter) 376.44 556.87 T
0 F
( Proc) 400.44 556.87 T
(ReturnNode ::=) 325.08 543.4 T
4 F
(return) 381.78 543.4 T
0 F
( Var) 410.58 543.4 T
1 9 Q
0.64 (where) 317.88 529.27 P
0 F
0.71 (V) 342.76 529.27 P
0.71 (ar) 348.1 529.27 P
1 F
0.64 (,) 355.74 529.27 P
0 F
0.71 (Const) 360.88 529.27 P
1 F
0.64 (,) 384.39 529.27 P
0 F
0.71 (UnaryOp) 389.53 529.27 P
1 F
0.64 (,) 425.54 529.27 P
0 F
0.71 (BinaryOp) 430.68 529.27 P
1 F
0.64 (, and) 468.19 529.27 P
0 F
0.71 (Proc) 489.22 529.27 P
1 F
0.64 ( are terminals) 507.73 529.27 P
(and) 317.88 519.27 T
0 F
(Policies) 333.13 519.27 T
1 F
( is as de\336ned in Figure 5.) 364.13 519.27 T
2 10 Q
(5.2) 317.88 502.13 T
(Pr) 335.88 502.13 T
(epasses) 346.25 502.13 T
1 9 Q
0.97 (Our analyses will need to identify those program points where a) 317.88 487.33 P
4.02 (variable in the scope of analysis may be assigned. Direct) 317.88 477.33 P
2.11 (assignments as part of an) 317.88 467.33 P
0 F
2.35 (OpNode) 421.17 467.33 P
1 F
2.11 ( are clear) 454.69 467.33 P
2.11 (, but assignments) 491.52 467.33 P
1 (through pointers and as side-ef) 317.88 457.33 P
1 (fects of calls are more dif) 432.69 457.33 P
1 (\336cult to) 529.24 457.33 P
1.84 (track. W) 317.88 447.33 P
1.84 (e abstract this may side-ef) 349.99 447.33 P
1.84 (fect analysis problem into a) 451.16 447.33 P
1.06 (prepass whose output is) 317.88 437.33 P
0 F
1.17 (MayDefV) 410.1 437.33 P
1.17 (ars) 446.44 437.33 P
1 F
1.06 (, a set of variables at each) 458.94 437.33 P
2.71 (program point that may be modi\336ed during execution of the) 317.88 427.33 P
(previous node, other than the left-hand-side variable of the node.) 317.88 417.33 T
0.42 (Our analyses will work better if they can identify when annotated) 317.88 403.87 P
0.6 (and derived run-time constant variables are dead. W) 317.88 393.87 P
0.6 (e abstract the) 509.31 393.87 P
1.82 (result of a live variables analysis into a prepass that computes) 317.88 383.87 P
0 F
0.38 (LiveV) 317.88 373.87 P
0.38 (ars) 339.72 373.87 P
1 F
0.34 (, the set of live variables at each program point. W) 352.22 373.87 P
0.34 (e also) 536.91 373.87 P
0.28 (compute and abstract a similar analysis,) 317.88 363.87 P
0 F
0.32 (UsedV) 465.32 363.87 P
0.32 (ars) 491.66 363.87 P
1 F
0.28 (, which are the) 504.16 363.87 P
0.6 (set of variables that have an earlier de\336nition and a later use \050but) 317.88 353.87 P
(may temporarily be dead at this point\051.) 317.88 343.87 T
-0.54 (Finally) 317.88 330.4 P
-0.54 (, we assume that the interprocedural specialization directives) 342.8 330.4 P
3.2 (have been processed and represented in the) 317.88 320.4 P
0 F
3.56 (Specializations) 497.98 320.4 P
1 F
0.97 (domain that maps each annotated procedure to a set of divisions) 317.88 310.4 P
1.02 (given in the) 317.88 300.4 P
4 F
2.44 (specialize) 365.68 300.4 P
1 F
1.02 ( annotation and speci\336es whether the) 419.68 300.4 P
3.14 (procedure was annotated as) 317.88 290.4 P
4 F
7.53 (constant) 431.89 290.4 P
1 F
3.14 (. This information is) 475.09 290.4 P
0.29 (assumed to be replicated at all program points, for convenience in) 317.88 280.4 P
(writing the analysis functions.) 317.88 270.4 T
2 10 Q
(5.3) 317.88 253.27 T
(The Main Analysis) 335.88 253.27 T
1 9 Q
0.21 (Figures 6, 7, and 8 de\336ne the annotation analysis. The) 317.88 238.47 P
3 F
0.21 (BT) 516.71 238.47 P
0.21 (A) 526.54 238.47 P
1 F
0.21 ( family) 532.04 238.47 P
2.46 (of data\337ow equations de\336nes the information on the program) 317.88 228.47 P
0.4 (point\050s\051 after a node in terms of the information computed for the) 317.88 218.47 P
0.24 (point\050s\051 before the node \050) 317.88 208.47 P
0 F
0.27 (bta) 410.32 208.47 P
1 F
0.24 (\051, the helper information described in) 422.83 208.47 P
-0.39 (subsection 5.2 for the program point\050s\051 after the node \050) 317.88 198.47 P
0 F
-0.44 (lvs) 511.79 198.47 P
1 F
-0.39 (,) 522.79 198.47 P
0 F
-0.44 (uvs) 526.89 198.47 P
1 F
-0.39 (, and) 540.9 198.47 P
0 F
0.57 (mds) 317.88 188.47 P
1 F
0.51 (\051, and the ever) 334.88 188.47 P
0.51 (-present specialized function information \050) 387.72 188.47 P
0 F
0.57 (sp) 543.25 188.47 P
1 F
0.51 (\051.) 552.75 188.47 P
1.88 (A solution to the \050recursive\051 data\337ow equations is the greatest) 317.88 178.47 P
1.47 (\336xpoint of the set of equations for each node in the procedure,) 317.88 168.47 P
2.32 (which we solve by simple iterative data\337ow analysis; the top) 317.88 158.47 P
-0.46 (element of the lattice, used to initialize back-edges during the initial) 317.88 148.47 P
(iteration of analysis of loops, is the empty set \050no divisions\051.) 317.88 138.47 T
1 7.2 Q
(*) 535.37 142.07 T
1 9 Q
1.94 (In general, each \337ow function computes a new updated set of) 317.88 125 P
1.21 (divisions from the in\337owing set\050s\051 of divisions. W) 317.88 115 P
1.21 (e remove any) 507.11 115 P
1.02 (\050permanently\051 dead variables from the set of annotated variables) 317.88 105 P
0.72 (and any \050at least temporarily\051 dead variables from the set of run-) 317.88 95 P
3.45 (time constants, to avoid unnecessary polyvariant division or) 317.88 85 P
4.05 (specialization. Once a new set of divisions and associated) 317.88 75 P
0 0 0 1 0 0 0 K
FMENDPAGE
%%EndPage: "8" 8
%%Page: "9" 9
612 792 0 FMBEGINPAGE
[0 0 0 1 0 0 0]
[ 0 1 1 0 1 0 0]
[ 1 0 1 0 0 1 0]
[ 1 1 0 0 0 0 1]
[ 1 0 0 0 0 1 1]
[ 0 1 0 0 1 0 1]
[ 0 0 1 0 1 1 0]
 7 FrameSetSepColors
FrameNoSep
0 0 0 1 0 0 0 K
54 26 558 44 R
7 X
0 0 0 1 0 0 0 K
V
0 0 0 1 0 0 0 K
0 0 0 1 0 0 0 K
54 72 294.12 738 R
V
1 9 Q
0 X
1.98 (information is computed, divisions that no longer dif) 54 336 P
1.98 (fer in the) 257.68 336 P
3.02 (policies of any variables annotated as leading to polyvariant) 54 325.09 P
-0.24 (division are mer) 54 314.18 P
-0.24 (ged together into a single division. Thus the degree) 111.84 314.18 P
1.1 (of polyvariant division can vary from program point to program) 54 303.27 P
(point.) 54 292.36 T
2 10 Q
(5.3.1) 54 269.69 T
(Entry Nodes) 81 269.69 T
1 9 Q
3.27 (The analysis of the procedure entry node creates the initial) 54 249.35 P
-0.39 (division\050s\051, including at least the empty unspecialized division with) 54 238.44 P
-0.4 (no run-time constant variables. For a specialized procedure, each of) 54 227.53 P
0.39 (the divisions listed in the) 54 216.62 P
4 F
0.94 (specialize) 148.21 216.62 P
1 F
0.39 ( annotation introduces an) 202.21 216.62 P
0.95 (additional specialized division in the analysis. For each division,) 54 205.71 P
0.9 (the set of run-time constants is initialized to the set of annotated) 54 194.8 P
0.07 (variables, with each variable\325) 54 183.89 P
0.07 (s initial caching policy taken from its) 159.69 183.89 P
(speci\336ed) 54 172.98 T
0 F
(PromotionCachingPolicy) 88.25 172.98 T
1 F
(.) 185.69 172.98 T
54 155 294.12 169.98 C
0 0 0 1 0 0 0 K
0 0 0 1 0 0 0 K
54 155 294.12 169.98 R
7 X
0 0 0 1 0 0 0 K
V
54 160.91 207 160.91 2 L
V
0.5 H
2 Z
0 X
N
0 0 612 792 C
1 6.4 Q
0 X
0 0 0 1 0 0 0 K
(*) 54 152.87 T
1 8 Q
0.87 (We follow the conventions of dataflow analysis in solving for) 59.68 149.67 P
3 F
0.87 (greatest) 268.34 149.67 P
1 F
-0.02 (fixpoints and initializing information along edges to the) 59.68 140.67 P
3 F
-0.02 (top) 239.96 140.67 P
1 F
-0.02 ( of the lattice.) 250.19 140.67 P
-0.17 (In this paper we do not bother to more formally define the lattice ordering) 59.68 131.67 P
0.83 (and meet operations, since we have given an explicit flow function for) 59.68 122.67 P
0.51 (merge nodes and defined the top lattice element, and simple iterative or) 59.68 113.67 P
0.92 (worklist-based analyses need nothing more. A soundness proof for our) 59.68 104.67 P
1.74 (analysis would of course require a more formal treatment. Since the) 59.68 95.67 P
1.56 (domain of analysis is finite and each analysis function is monotonic,) 59.68 86.67 P
(termination of analysis is assured.) 59.68 77.67 T
54 342 294.12 738 C
0 0 0 1 0 0 0 K
0 0 0 1 0 0 0 K
55.02 351 293.42 738 R
7 X
0 0 0 1 0 0 0 K
V
3 8 Q
0 X
(BTA) 55.02 732.67 T
0 6.4 Q
(Entry) 69.24 730.67 T
0 8 Q
(: EntryNode) 84.18 732.67 T
6 F
(\256) 126.42 732.67 T
0 F
(LiveVars) 134.31 732.67 T
6 F
(\256) 165.43 732.67 T
0 F
(UsedVars) 173.33 732.67 T
6 F
(\256) 208.45 732.67 T
0 F
(Specializations) 216.35 732.67 T
6 F
(\256) 269.7 732.67 T
0 F
(BTA) 277.59 732.67 T
3 F
(BTA) 55.02 720.67 T
0 6.4 Q
(Entry) 69.24 718.67 T
0 8 Q
-0.8 ([) 86.4 720.67 S
([) 87.82 720.67 T
4 F
(enter P) 90.05 720.67 T
0 F
-0.8 (]) 123.65 720.67 S
(] lvs uvs sp) 125.07 720.67 T
6 F
(\272) 166.87 720.67 T
0 F
(let ds = \050if) 62.22 710.67 T
4 F
(P) 99.34 710.67 T
6 F
(\316) 104.14 710.67 T
0 F
(dom\050sp\051 then Divisions\050sp\050) 109.85 710.67 T
4 F
(P) 204.98 710.67 T
0 F
(\051\051 else) 209.78 710.67 T
6 F
(\306) 234.22 710.67 T
0 F
(\051) 240.81 710.67 T
6 F
(\310) 245.7 710.67 T
0 F
( {) 251.84 710.67 T
6 F
(\306) 256.74 710.67 T
0 F
(} in) 263.32 710.67 T
(Merge\050lvs, { \050d, \050s,) 69.42 700.67 T
6 F
(\306) 136.54 700.67 T
0 F
(,) 143.13 700.67 T
6 F
(\306) 147.58 700.67 T
0 F
(\051\051 |) 154.16 700.67 T
(d\325) 83.82 690.67 T
6 F
(\316) 90.04 690.67 T
0 F
(ds) 95.74 690.67 T
6 F
(\331) 108.64 690.67 T
0 F
(d = ForgetDeadVars\050uvs, d\325\051) 83.82 680.67 T
6 F
(\331) 188.97 680.67 T
0 F
(s = { InitialBinding\050v, d\051 | v) 83.82 670.67 T
6 F
(\316) 175.94 670.67 T
0 F
(dom\050d\051 } }\051) 181.64 670.67 T
3 F
(BTA) 55.02 646.67 T
0 6.4 Q
(Branch) 69.24 644.67 T
0 8 Q
(:) 89.51 646.67 T
(BranchNode) 55.02 636.67 T
6 F
(\256) 99.48 636.67 T
0 F
(LiveVars) 107.38 636.67 T
6 F
(\264) 138.5 636.67 T
0 F
(LiveVars) 142.89 636.67 T
6 F
(\256) 174.01 636.67 T
0 F
(UsedVars) 181.9 636.67 T
6 F
(\264) 217.02 636.67 T
0 F
(UsedVars) 221.42 636.67 T
6 F
(\256) 59.02 626.67 T
0 F
(MayDefVars) 66.91 626.67 T
6 F
(\264) 110.92 626.67 T
0 F
(MayDefVars) 115.31 626.67 T
6 F
(\256) 159.32 626.67 T
0 F
(Specializations) 167.22 626.67 T
6 F
(\256) 220.57 626.67 T
0 F
(BTA) 228.46 626.67 T
6 F
(\256) 244.02 626.67 T
0 F
(BTA) 251.92 626.67 T
6 F
(\264) 267.48 626.67 T
0 F
(BTA) 271.87 626.67 T
3 F
(BTA) 55.02 614.67 T
0 6.4 Q
(Branch) 69.24 612.67 T
0 8 Q
-0.8 ([) 91.74 614.67 S
([) 93.16 614.67 T
4 F
(test x) 95.39 614.67 T
0 F
-0.8 (]) 124.19 614.67 S
(] \050lvs) 125.61 614.67 T
0 6.4 Q
(1) 142.5 612.67 T
0 8 Q
(,lvs) 146.06 614.67 T
0 6.4 Q
(2) 158.06 612.67 T
0 8 Q
(\051 \050uvs) 161.62 614.67 T
0 6.4 Q
(1) 181.62 612.67 T
0 8 Q
(,uvs) 185.17 614.67 T
0 6.4 Q
(2) 199.85 612.67 T
0 8 Q
(\051 \050mds) 203.4 614.67 T
0 6.4 Q
(1) 226.07 612.67 T
0 8 Q
(,mds) 229.63 614.67 T
0 6.4 Q
(2) 246.96 612.67 T
0 8 Q
(\051 sp bta) 250.52 614.67 T
6 F
(\272) 279.42 614.67 T
0 F
(\050Merge\050lvs) 62.22 604.67 T
0 6.4 Q
(1) 99.99 602.67 T
0 8 Q
(, { \050d) 103.55 604.67 T
0 6.4 Q
(out) 120.01 602.67 T
0 8 Q
(,i) 128.9 604.67 T
0 6.4 Q
(out) 132.9 602.67 T
0 8 Q
(\051 |) 141.8 604.67 T
(\050d,i\051) 69.42 594.67 T
6 F
(\316) 85.42 594.67 T
0 F
( bta) 91.12 594.67 T
6 F
(\331) 108.91 594.67 T
0 F
(\050d) 117.74 594.67 T
0 6.4 Q
(out) 124.85 592.67 T
0 8 Q
(,i) 133.74 594.67 T
0 6.4 Q
(out) 137.74 592.67 T
0 8 Q
(\051 = ProcessStmt\050) 146.64 594.67 T
6 F
(\306) 206.43 594.67 T
0 F
(, uvs) 213.01 594.67 T
0 6.4 Q
(1) 229.91 592.67 T
0 8 Q
(, mds) 233.47 594.67 T
0 6.4 Q
(1) 253.03 592.67 T
0 8 Q
(, d, i\051 }\051,) 256.59 594.67 T
( Merge\050lvs) 62.22 584.67 T
0 6.4 Q
(2) 99.55 582.67 T
0 8 Q
(, { \050d) 103.11 584.67 T
0 6.4 Q
(out) 119.57 582.67 T
0 8 Q
(,i) 128.46 584.67 T
0 6.4 Q
(out) 132.46 582.67 T
0 8 Q
(\051 |) 141.36 584.67 T
(\050d,i\051) 69.42 574.67 T
6 F
(\316) 85.42 574.67 T
0 F
( bta) 91.12 574.67 T
6 F
(\331) 108.91 574.67 T
0 F
(\050d) 117.96 574.67 T
0 6.4 Q
(out) 125.07 572.67 T
0 8 Q
(,i) 133.97 574.67 T
0 6.4 Q
(out) 137.97 572.67 T
0 8 Q
(\051 = ProcessStmt\050) 146.86 574.67 T
6 F
(\306) 206.65 574.67 T
0 F
(, uvs) 213.24 574.67 T
0 6.4 Q
(2) 230.13 572.67 T
0 8 Q
(, mds) 233.69 574.67 T
0 6.4 Q
(2) 253.25 572.67 T
0 8 Q
(, d, i\051 }\051\051) 256.81 574.67 T
3 F
(BTA) 55.02 550.67 T
0 6.4 Q
(Merge) 69.24 548.67 T
0 8 Q
(: MergeNode) 87.38 550.67 T
6 F
(\256) 133.62 550.67 T
0 F
(LiveVars) 141.51 550.67 T
6 F
(\256) 172.63 550.67 T
0 F
(UsedVars) 180.53 550.67 T
6 F
(\256) 215.65 550.67 T
0 F
(MayDefVars) 223.54 550.67 T
6 F
(\256) 127.02 540.67 T
0 F
(Specializations) 134.91 540.67 T
6 F
(\256) 188.26 540.67 T
0 F
(Pow\050BTA\051) 196.16 540.67 T
6 F
(\256) 232.61 540.67 T
0 F
(BTA) 240.5 540.67 T
3 F
(BTA) 55.02 528.67 T
0 6.4 Q
(Merge) 69.24 526.67 T
0 8 Q
-0.8 ([) 89.6 528.67 S
([) 91.03 528.67 T
4 F
(merge\050x) 93.25 528.67 T
4 6.4 Q
(1) 126.85 526.67 T
4 8 Q
(,...,x) 130.69 528.67 T
4 6.4 Q
(n) 159.49 526.67 T
4 8 Q
(\051) 163.33 528.67 T
0 F
-0.8 (]) 168.13 528.67 S
(] lvs uvs mds sp btas) 169.55 528.67 T
6 F
(\272) 246.02 528.67 T
0 F
(let bta =) 62.22 518.67 T
6 F
(\310) 93.13 518.67 T
0 F
( btas in) 99.27 518.67 T
(if) 69.42 508.67 T
3 F
(this is a static merge) 75.64 508.67 T
0 F
( then Merge\050lvs, bta\051) 141.86 508.67 T
(else Merge\050lvs, { \050d) 69.42 498.67 T
0 6.4 Q
(out) 137.88 496.67 T
0 8 Q
(,i) 146.78 498.67 T
0 6.4 Q
(out) 150.78 496.67 T
0 8 Q
(\051 |) 159.67 498.67 T
(\050d,i\051) 98.22 488.67 T
6 F
(\316) 114.22 488.67 T
0 F
( bta) 119.92 488.67 T
6 F
(\331) 137.71 488.67 T
0 F
(pvs = {) 98.22 478.67 T
4 F
(x) 122.46 478.67 T
4 6.4 Q
(1) 127.26 476.67 T
0 8 Q
(,...,) 131.1 478.67 T
4 F
(x) 142.22 478.67 T
4 6.4 Q
(n) 147.02 476.67 T
0 8 Q
(}) 150.86 478.67 T
6 F
(\307) 155.75 478.67 T
0 F
(PolySpecializationVars\050d\051) 163.9 478.67 T
6 F
(\307) 257.26 478.67 T
0 F
( lvs) 263.4 478.67 T
6 F
(\331) 279.85 478.67 T
0 F
(mvs = \050{) 98.22 468.67 T
4 F
(x) 127.34 468.67 T
4 6.4 Q
(1) 132.14 466.67 T
0 8 Q
(,...,) 135.98 468.67 T
4 F
(x) 147.1 468.67 T
4 6.4 Q
(n) 151.9 466.67 T
0 8 Q
(}) 155.74 468.67 T
6 F
(-) 160.63 468.67 T
0 F
( pvs\051) 165.02 468.67 T
6 F
(\307) 184.58 468.67 T
0 F
( lvs) 190.73 468.67 T
6 F
(\331) 207.18 468.67 T
0 F
(d) 98.22 458.67 T
0 6.4 Q
(out) 102.66 456.67 T
0 8 Q
( = ForgetDeadVars\050uvs, d) 111.56 458.67 T
6 F
(-) 205.6 458.67 T
0 F
( { \050x,p\325\051) 209.99 458.67 T
6 F
(\316) 234.89 458.67 T
0 F
(d | x) 240.59 458.67 T
6 F
(\316) 255.57 458.67 T
0 F
(mvs }\051) 261.27 458.67 T
6 F
(\331) 287.94 458.67 T
0 F
(i) 98.22 448.67 T
0 6.4 Q
(out) 99.99 446.67 T
0 8 Q
( =) 108.89 448.67 T
(if pvs =) 105.42 438.67 T
6 F
(\306) 133.21 438.67 T
0 F
( then i[DiscordantVars) 139.79 438.67 T
6 F
(\256\306) 218.49 438.67 T
0 F
(]) 232.97 438.67 T
(else) 104.89 428.67 T
(\050{ \050v, \050mp, {v}\051\051 | \050v,p\051) 112.62 418.67 T
6 F
(\316) 186.71 418.67 T
0 F
(d) 192.42 418.67 T
0 6.4 Q
(out) 196.86 416.67 T
6 8 Q
(\331) 210.21 418.67 T
0 F
(mp = if v) 119.82 408.67 T
6 F
(\316) 150.27 408.67 T
0 F
(pvs then MergeCachingPolicy\050p\051) 155.98 408.67 T
(else CachingPolicy\050StaticVarInfo\050i\051\050v\051\051 },) 139.83 398.67 T
6 F
(\306) 115.42 388.67 T
0 F
(, pvs\051 }\051) 122 388.67 T
2 10 Q
(Figur) 105.42 369.33 T
(e 6: Flow Functions, Part I) 129.13 369.33 T
0 0 612 792 C
317.88 72 558 738 R
7 X
0 0 0 1 0 0 0 K
V
317.88 72 558 738 C
0 0 0 1 0 0 0 K
0 0 0 1 0 0 0 K
317.54 81 557.3 738 R
7 X
0 0 0 1 0 0 0 K
V
3 8 Q
0 X
(BTA) 317.54 732.67 T
0 6.4 Q
(OpNode) 331.77 730.67 T
0 8 Q
(: OpNode) 355.6 732.67 T
6 F
(\256) 389.84 732.67 T
0 F
(LiveVars) 397.73 732.67 T
6 F
(\256) 428.85 732.67 T
0 F
(UsedVars) 436.75 732.67 T
6 F
(\256) 471.87 732.67 T
0 F
(MayDefVars) 479.77 732.67 T
6 F
(\256) 389.54 722.67 T
0 F
(Specializations) 397.44 722.67 T
6 F
(\256) 450.79 722.67 T
0 F
(BTA) 458.68 722.67 T
6 F
(\256) 474.24 722.67 T
0 F
(BTA) 482.14 722.67 T
3 F
(BTA) 317.54 710.67 T
0 6.4 Q
(OpNode) 331.77 708.67 T
0 8 Q
-0.8 ([) 357.82 710.67 S
([) 359.25 710.67 T
4 F
(make_static\050x:p\051) 361.47 710.67 T
0 F
-0.8 (]) 438.27 710.67 S
(] lvs uvs mds sp bta) 439.69 710.67 T
6 F
(\272) 512.17 710.67 T
0 F
(Merge\050lvs, { \050d) 324.74 700.67 T
0 6.4 Q
(out) 376.31 698.67 T
0 8 Q
(,i) 385.2 700.67 T
0 6.4 Q
(out) 389.2 698.67 T
0 8 Q
(\051 |) 398.1 700.67 T
(\050d,i\051) 339.14 690.67 T
6 F
(\316) 355.14 690.67 T
0 F
( bta) 360.85 690.67 T
6 F
(\331) 378.64 690.67 T
0 F
-0.47 (d) 339.14 680.67 P
0 6.4 Q
-0.38 (out) 343.59 678.67 P
0 8 Q
-0.47 ( = ForgetDeadVars\050uvs, d) 352.48 680.67 P
6 F
-0.42 (-) 444.64 680.67 P
0 F
-0.47 ( { \050x\325,p\325\051) 449.04 680.67 P
6 F
-0.42 (\316) 474.77 680.67 P
0 F
-0.47 (d | x\325 =) 480.47 680.67 P
4 F
-1.01 (x) 504.46 680.67 P
0 F
-0.47 ( }) 509.26 680.67 P
6 F
-0.42 (\310) 515.44 680.67 P
0 F
-0.47 ( {\050) 521.59 680.67 P
4 F
-1.01 (x) 528.67 680.67 P
0 F
-0.47 (,) 533.47 680.67 P
4 F
-1.01 (p) 535.7 680.67 P
0 F
-0.47 (\051}\051) 540.5 680.67 P
6 F
-0.42 (\331) 552.48 680.67 P
0 F
(i) 339.14 670.67 T
0 6.4 Q
(out) 340.92 668.67 T
0 8 Q
( = MakeStatic\050) 349.81 670.67 T
4 F
(x) 401.16 670.67 T
0 F
(, d) 405.96 670.67 T
0 6.4 Q
(out) 414.86 668.67 T
0 8 Q
(, i[DiscordantVars) 423.76 670.67 T
6 F
(\256\306) 486.88 670.67 T
0 F
(]\051 }\051) 501.36 670.67 T
3 F
(BTA) 317.54 658.67 T
0 6.4 Q
(OpNode) 331.77 656.67 T
0 8 Q
-0.8 ([) 357.82 658.67 S
([) 359.25 658.67 T
4 F
(make_dynamic\050x\051) 361.47 658.67 T
0 F
-0.8 (]) 433.47 658.67 S
(] lvs uvs mds sp bta) 434.89 658.67 T
6 F
(\272) 507.37 658.67 T
0 F
(Merge\050lvs, { \050d) 324.74 648.67 T
0 6.4 Q
(out) 376.31 646.67 T
0 8 Q
(,i) 385.2 648.67 T
0 6.4 Q
(out) 389.2 646.67 T
0 8 Q
(\051 |) 398.1 648.67 T
(\050d,i\051) 339.14 638.67 T
6 F
(\316) 355.14 638.67 T
0 F
( bta) 360.85 638.67 T
6 F
(\331) 378.64 638.67 T
0 F
(d) 339.14 628.67 T
0 6.4 Q
(out) 343.59 626.67 T
0 8 Q
( = ForgetDeadVars\050uvs, d) 352.48 628.67 T
6 F
(-) 446.52 628.67 T
0 F
( { \050x\325,p\325\051) 450.92 628.67 T
6 F
(\316) 477.59 628.67 T
0 F
(d | x\325 =) 483.29 628.67 T
4 F
(x) 509.16 628.67 T
0 F
( }\051) 513.96 628.67 T
6 F
(\331) 525.97 628.67 T
0 F
(i) 339.14 618.67 T
0 6.4 Q
(out) 340.92 616.67 T
0 8 Q
( = i[DiscordantVars) 349.81 618.67 T
6 F
(\256\306) 417.61 618.67 T
0 F
(] }\051) 432.09 618.67 T
3 F
(BTA) 317.54 606.67 T
0 6.4 Q
(OpNode) 331.77 604.67 T
0 8 Q
-0.8 ([) 357.82 606.67 S
([) 359.25 606.67 T
4 F
(x := k) 361.47 606.67 T
0 F
-0.8 (]) 390.27 606.67 S
(] lvs uvs mds sp bta) 391.69 606.67 T
6 F
(\272) 464.17 606.67 T
0 F
(Merge\050lvs, { \050d) 324.74 596.67 T
0 6.4 Q
(out) 376.31 594.67 T
0 8 Q
(,i) 385.2 596.67 T
0 6.4 Q
(out) 389.2 594.67 T
0 8 Q
(\051 |) 398.1 596.67 T
(\050d,i\051) 339.14 586.67 T
6 F
(\316) 355.14 586.67 T
0 F
( bta) 360.85 586.67 T
6 F
(\331) 378.64 586.67 T
0 F
(\050d) 339.14 576.67 T
0 6.4 Q
(out) 346.25 574.67 T
0 8 Q
(,i) 355.15 576.67 T
0 6.4 Q
(out) 359.15 574.67 T
0 8 Q
(\051 = ProcessAssignment\050) 368.04 576.67 T
4 F
(x) 453.18 576.67 T
0 F
(, true,) 457.98 576.67 T
6 F
(\306) 480.66 576.67 T
0 F
(, uvs, mds, d, i\051 }\051) 487.24 576.67 T
3 F
(BTA) 317.54 564.67 T
0 6.4 Q
(OpNode) 331.77 562.67 T
0 8 Q
-0.8 ([) 357.82 564.67 S
([) 359.25 564.67 T
4 F
(x := y) 361.47 564.67 T
0 F
-0.8 (]) 390.27 564.67 S
(] lvs uvs mds sp bta) 391.69 564.67 T
6 F
(\272) 464.17 564.67 T
0 F
(Merge\050lvs, { \050d) 324.74 554.67 T
0 6.4 Q
(out) 376.31 552.67 T
0 8 Q
(,i) 385.2 554.67 T
0 6.4 Q
(out) 389.2 552.67 T
0 8 Q
(\051 |) 398.1 554.67 T
(\050d,i\051) 339.14 544.67 T
6 F
(\316) 355.14 544.67 T
0 F
( bta) 360.85 544.67 T
6 F
(\331) 378.64 544.67 T
0 F
(\050d) 339.14 534.67 T
0 6.4 Q
(out) 346.25 532.67 T
0 8 Q
(,i) 355.15 534.67 T
0 6.4 Q
(out) 359.15 532.67 T
0 8 Q
(\051 = ProcessAssignment\050) 368.04 534.67 T
4 F
(x) 346.34 524.67 T
0 F
(,) 351.14 524.67 T
4 F
(y) 355.59 524.67 T
6 F
(\316) 360.39 524.67 T
0 F
(StaticVars\050i\051, SourceRoots\050) 366.09 524.67 T
4 F
(y) 463 524.67 T
0 F
(,i\051, uvs, mds, d, i\051 }\051) 467.8 524.67 T
3 F
(BTA) 317.54 512.67 T
0 6.4 Q
(OpNode) 331.77 510.67 T
0 8 Q
-0.8 ([) 357.82 512.67 S
([) 359.25 512.67 T
4 F
(x := op y) 361.47 512.67 T
0 F
-0.8 (]) 404.67 512.67 S
(] lvs uvs mds sp bta) 406.09 512.67 T
6 F
(\272) 478.57 512.67 T
0 F
(Merge\050lvs, { \050d) 324.74 502.67 T
0 6.4 Q
(out) 376.31 500.67 T
0 8 Q
(,i) 385.2 502.67 T
0 6.4 Q
(out) 389.2 500.67 T
0 8 Q
(\051 |) 398.1 502.67 T
(\050d,i\051) 339.14 492.67 T
6 F
(\316) 355.14 492.67 T
0 F
( bta) 360.85 492.67 T
6 F
(\331) 378.64 492.67 T
0 F
(\050d) 339.14 482.67 T
0 6.4 Q
(out) 346.25 480.67 T
0 8 Q
(,i) 355.15 482.67 T
0 6.4 Q
(out) 359.15 480.67 T
0 8 Q
(\051 = ProcessAssignment\050) 368.04 482.67 T
4 F
(x) 346.34 472.67 T
0 F
(,) 351.14 472.67 T
4 F
(y) 355.59 472.67 T
6 F
(\316) 360.39 472.67 T
0 F
(StaticVars\050i\051) 366.09 472.67 T
6 F
(\331) 411.88 472.67 T
0 F
( Pure\050) 416.7 472.67 T
4 F
(op) 438.48 472.67 T
0 F
(\051, SourceRoots\050) 448.08 472.67 T
4 F
(y) 504.1 472.67 T
0 F
(,i\051,) 508.9 472.67 T
(uvs, mds, d, i\051 }\051) 346.34 462.67 T
3 F
(BTA) 317.54 450.67 T
0 6.4 Q
(OpNode) 331.77 448.67 T
0 8 Q
-0.8 ([) 357.82 450.67 S
([) 359.25 450.67 T
4 F
(x := y op z) 361.47 450.67 T
0 F
-0.8 (]) 414.27 450.67 S
(] lvs uvs mds sp bta) 415.69 450.67 T
6 F
(\272) 488.17 450.67 T
0 F
(Merge\050lvs, { \050d) 324.74 440.67 T
0 6.4 Q
(out) 376.31 438.67 T
0 8 Q
(,i) 385.2 440.67 T
0 6.4 Q
(out) 389.2 438.67 T
0 8 Q
(\051 |) 398.1 440.67 T
(\050d,i\051) 339.14 430.67 T
6 F
(\316) 355.14 430.67 T
0 F
( bta) 360.85 430.67 T
6 F
(\331) 378.64 430.67 T
0 F
(\050d) 339.14 420.67 T
0 6.4 Q
(out) 346.25 418.67 T
0 8 Q
(,i) 355.15 420.67 T
0 6.4 Q
(out) 359.15 418.67 T
0 8 Q
(\051 = ProcessAssignment\050) 368.04 420.67 T
4 F
(x) 346.34 410.67 T
0 F
(,) 351.14 410.67 T
({) 355.59 410.67 T
4 F
(y) 358.26 410.67 T
0 F
(,) 363.06 410.67 T
4 F
(z) 365.29 410.67 T
0 F
(}) 370.08 410.67 T
6 F
(\315) 372.76 410.67 T
0 F
(StaticVars\050i\051) 378.46 410.67 T
6 F
(\331) 424.24 410.67 T
0 F
( Pure\050) 429.07 410.67 T
4 F
(op) 450.85 410.67 T
0 F
(\051,) 460.45 410.67 T
(SourceRoots\050) 346.34 400.67 T
4 F
(y) 395.24 400.67 T
0 F
(,i\051) 400.04 400.67 T
6 F
(\310) 408.93 400.67 T
0 F
(SourceRoots\050) 417.08 400.67 T
4 F
(z) 465.98 400.67 T
0 F
(,i\051, uvs, mds, d, i\051 }\051) 470.78 400.67 T
3 F
(BTA) 317.54 388.67 T
0 6.4 Q
(OpNode) 331.77 386.67 T
0 8 Q
-0.8 ([) 357.82 388.67 S
([) 359.25 388.67 T
4 F
(x := *p) 361.47 388.67 T
0 F
-0.8 (]) 395.07 388.67 S
(] lvs uvs mds sp bta) 396.49 388.67 T
6 F
(\272) 468.97 388.67 T
0 F
(Merge\050lvs, { \050d) 324.74 378.67 T
0 6.4 Q
(out) 376.31 376.67 T
0 8 Q
(,i) 385.2 378.67 T
0 6.4 Q
(out) 389.2 376.67 T
0 8 Q
(\051 |) 398.1 378.67 T
(\050d,i\051) 339.14 368.67 T
6 F
(\316) 355.14 368.67 T
0 F
( bta) 360.85 368.67 T
6 F
(\331) 378.64 368.67 T
0 F
(\050d) 339.14 358.67 T
0 6.4 Q
(out) 346.25 356.67 T
0 8 Q
(,i) 355.15 358.67 T
0 6.4 Q
(out) 359.15 356.67 T
0 8 Q
(\051 = ProcessAssignment\050) 368.04 358.67 T
4 F
(x) 453.18 358.67 T
0 F
(, false,) 457.98 358.67 T
6 F
(\306) 483.77 358.67 T
0 F
(, uvs, mds, d, i\051 }\051) 490.36 358.67 T
3 F
(BTA) 317.54 346.67 T
0 6.4 Q
(OpNode) 331.77 344.67 T
0 8 Q
-0.8 ([) 357.82 346.67 S
([) 359.25 346.67 T
4 F
(x := static* p) 361.47 346.67 T
0 F
-0.8 (]) 428.67 346.67 S
(] lvs uvs mds sp bta) 430.09 346.67 T
6 F
(\272) 502.57 346.67 T
0 F
(Merge\050lvs, { \050d) 324.74 336.67 T
0 6.4 Q
(out) 376.31 334.67 T
0 8 Q
(,i) 385.2 336.67 T
0 6.4 Q
(out) 389.2 334.67 T
0 8 Q
(\051 |) 398.1 336.67 T
(\050d,i\051) 339.14 326.67 T
6 F
(\316) 355.14 326.67 T
0 F
( bta) 360.85 326.67 T
6 F
(\331) 378.64 326.67 T
0 F
(\050d) 339.14 316.67 T
0 6.4 Q
(out) 346.25 314.67 T
0 8 Q
(,i) 355.15 316.67 T
0 6.4 Q
(out) 359.15 314.67 T
0 8 Q
(\051 = ProcessAssignment\050) 368.04 316.67 T
4 F
(x) 346.34 306.67 T
0 F
(,) 351.14 306.67 T
4 F
(p) 355.59 306.67 T
6 F
(\316) 360.39 306.67 T
0 F
(StaticVars\050i\051, SourceRoots\050) 366.09 306.67 T
4 F
(p) 463 306.67 T
0 F
(,i\051, uvs, mds, d, i\051 }\051) 467.8 306.67 T
3 F
(BTA) 317.54 294.67 T
0 6.4 Q
(OpNode) 331.77 292.67 T
0 8 Q
-0.8 ([) 357.82 294.67 S
([) 359.25 294.67 T
4 F
(*p := y) 361.47 294.67 T
0 F
-0.8 (]) 395.07 294.67 S
(] lvs uvs mds sp bta) 396.49 294.67 T
6 F
(\272) 468.97 294.67 T
0 F
(Merge\050lvs, { \050d) 324.74 284.67 T
0 6.4 Q
(out) 376.31 282.67 T
0 8 Q
(,i) 385.2 284.67 T
0 6.4 Q
(out) 389.2 282.67 T
0 8 Q
(\051 |) 398.1 284.67 T
(\050d,i\051) 339.14 274.67 T
6 F
(\316) 355.14 274.67 T
0 F
( bta) 360.85 274.67 T
6 F
(\331) 378.64 274.67 T
0 F
(\050d) 339.14 264.67 T
0 6.4 Q
(out) 346.25 262.67 T
0 8 Q
(,i) 355.15 264.67 T
0 6.4 Q
(out) 359.15 262.67 T
0 8 Q
(\051 = ProcessStmt\050) 368.04 264.67 T
6 F
(\306) 427.84 264.67 T
0 F
(, uvs, mds, d, i\051 }\051) 434.42 264.67 T
3 F
(BTA) 317.54 252.67 T
0 6.4 Q
(OpNode) 331.77 250.67 T
0 8 Q
-0.8 ([) 357.82 252.67 S
([) 359.25 252.67 T
4 F
(x := f\050y) 361.47 252.67 T
4 6.4 Q
(1) 399.87 250.67 T
4 8 Q
(,...,y) 403.71 252.67 T
4 6.4 Q
(n) 432.51 250.67 T
4 8 Q
(\051) 436.35 252.67 T
0 F
-0.8 (]) 441.15 252.67 S
(] lvs uvs mds sp bta) 442.57 252.67 T
6 F
(\272) 515.05 252.67 T
0 F
(Merge\050lvs, { \050d) 324.74 242.67 T
0 6.4 Q
(out) 376.31 240.67 T
0 8 Q
(,i) 385.2 242.67 T
0 6.4 Q
(out) 389.2 240.67 T
0 8 Q
(\051 |) 398.1 242.67 T
(\050d,i\051) 339.14 232.67 T
6 F
(\316) 355.14 232.67 T
0 F
( bta) 360.85 232.67 T
6 F
(\331) 378.64 232.67 T
0 F
(\050d) 339.14 222.67 T
0 6.4 Q
(out) 346.25 220.67 T
0 8 Q
(,i) 355.15 222.67 T
0 6.4 Q
(out) 359.15 220.67 T
0 8 Q
(\051 = ProcessAssignment\050) 368.04 222.67 T
4 F
(x) 346.34 212.67 T
0 F
(,) 351.14 212.67 T
({) 346.34 202.67 T
4 F
(y) 349.01 202.67 T
4 6.4 Q
(1) 353.81 200.67 T
0 8 Q
(,...,) 357.65 202.67 T
4 F
(y) 368.77 202.67 T
4 6.4 Q
(n) 373.57 200.67 T
0 8 Q
(}) 377.41 202.67 T
6 F
(\315) 380.08 202.67 T
0 F
(StaticVars\050i\051) 385.79 202.67 T
6 F
(\331) 433.8 202.67 T
4 F
(f) 353.54 192.67 T
6 F
(\316) 358.34 192.67 T
0 F
(dom\050sp\051) 364.05 192.67 T
6 F
(\331) 397.83 192.67 T
0 F
(IsConstant\050sp\050f\051\051 = Constant,) 407.1 192.67 T
6 F
(\310) 346.34 182.67 T
0 6.4 Q
(y) 352.48 180.67 T
3 F
(i) 355.68 180.67 T
6 F
(\316) 359.24 180.67 T
0 F
({y1,...,yn}) 366.03 180.67 T
0 8 Q
( SourceRoots\050) 392.72 182.67 T
4 F
(y) 443.85 182.67 T
3 6.4 Q
(i) 448.64 180.67 T
0 8 Q
(,i\051,) 450.42 182.67 T
(uvs, mds, d, i\051 }\051) 346.34 172.67 T
2 10 Q
(Figur) 366.68 153.34 T
(e 7: Flow Functions, Part II) 390.39 153.34 T
0 0 612 792 C
0 0 0 1 0 0 0 K
FMENDPAGE
%%EndPage: "9" 9
%%Page: "10" 10
612 792 0 FMBEGINPAGE
[0 0 0 1 0 0 0]
[ 0 1 1 0 1 0 0]
[ 1 0 1 0 0 1 0]
[ 1 1 0 0 0 0 1]
[ 1 0 0 0 0 1 1]
[ 0 1 0 0 1 0 1]
[ 0 0 1 0 1 1 0]
 7 FrameSetSepColors
FrameNoSep
0 0 0 1 0 0 0 K
54 26 558 44 R
7 X
0 0 0 1 0 0 0 K
V
0 0 0 1 0 0 0 K
0 0 0 1 0 0 0 K
54 72 294.12 738 R
V
54 72 294.12 738 C
0 0 0 1 0 0 0 K
0 0 0 1 0 0 0 K
54.34 72 292.74 738 R
7 X
0 0 0 1 0 0 0 K
V
0 8 Q
0 X
(Merge\050lvs:LiveVars, bta:BTA\051:BTA) 54.34 732.67 T
6 F
(\272) 178.82 732.67 T
0 F
(MergePartitions\050lvs, Partition\050bta\051\051) 61.54 722.67 T
(Partition\050bta:BTA\051:Pow\050BTA\051) 54.34 710.67 T
6 F
(\272) 158.81 710.67 T
0 F
({ { \050d,i\051) 61.54 700.67 T
6 F
(\316) 85.11 700.67 T
0 F
(bta | DivisionSelector\050d\051 = ds } |) 90.81 700.67 T
(ds) 68.74 690.67 T
6 F
(\316) 79.41 690.67 T
0 F
(DivisionSelectors\050bta\051 } }) 85.11 690.67 T
(DivisionSelectors\050bta:BTA\051:Divisions) 54.34 678.67 T
6 F
(\272) 186.36 678.67 T
0 F
({ DivisionSelector\050d\051 | \050d,i\051) 61.54 668.67 T
6 F
(\316) 153.86 668.67 T
0 F
(bta }) 159.56 668.67 T
(DivisionSelector\050d:Division\051:Division) 54.34 656.67 T
6 F
(\272) 184.13 656.67 T
0 F
({ \050v,p\051) 61.54 646.67 T
6 F
(\316) 82.43 646.67 T
0 F
(d | v) 88.14 646.67 T
6 F
(\316) 103.11 646.67 T
0 F
(PolyDivisionVars\050d\051 }) 108.82 646.67 T
(MergePartitions\050lvs:LiveVars, btas:Pow\050BTA\051\051:BTA) 54.34 634.67 T
6 F
(\272) 237.05 634.67 T
0 F
({ \050d,i\051 | bta) 61.54 624.67 T
6 F
(\316) 100.08 624.67 T
0 F
( btas) 105.79 624.67 T
6 F
(\331) 127.58 624.67 T
0 F
(d =) 88.23 614.67 T
6 11 Q
(\307) 101.79 614.67 T
0 6.4 Q
(Division) 110.24 612.67 T
0 8 Q
( dom\050bta\051) 132.64 614.67 T
6 F
(\331) 171.32 614.67 T
0 F
(i = FilterStaticVars\050lvs, d,) 88.23 604.67 T
6 11 Q
(\307) 179.14 604.67 T
0 6.4 Q
(DivisionInfo) 187.59 602.67 T
0 8 Q
( range\050bta\051\051 }) 220.66 604.67 T
(FilterStaticVars\050lvs:LiveVars, d:Division, i:DivisionInfo) 54.34 592.67 T
(\051:DivisionInfo) 112.16 582.67 T
6 F
(\272) 160.62 582.67 T
0 F
(let si = { \050v, \050p,rvs\051\051) 61.54 572.67 T
6 F
(\316) 128.44 572.67 T
0 F
(StaticVarInfo\050i\051 | v) 134.15 572.67 T
6 F
(\316) 197.58 572.67 T
0 F
(lvs } in) 203.28 572.67 T
(i[StaticVarInfo) 68.74 562.67 T
6 F
(\256) 118.54 562.67 T
0 F
({ \050v, \050p,rvs\051\051) 75.94 552.67 T
6 F
(\316) 117.27 552.67 T
0 F
(si | rvs) 122.98 552.67 T
6 F
(\315) 145.95 552.67 T
0 F
(dom\050d\051 }) 151.65 552.67 T
6 F
(\310) 184.11 552.67 T
0 F
({ InitialBinding\050v, d\051 |) 75.94 542.67 T
(\050v, \050p,rvs\051\051) 83.14 532.67 T
6 F
(\316) 119.58 532.67 T
0 F
(si) 125.28 532.67 T
6 F
(\331) 133.28 532.67 T
0 F
( v) 138.11 532.67 T
6 F
(\316) 144.33 532.67 T
0 F
(dom\050d\051) 150.03 532.67 T
6 F
(\331) 177.59 532.67 T
(\221\330) 184.42 532.67 T
0 F
(\050rvs) 192.35 532.67 T
6 F
(\315) 205.67 532.67 T
0 F
(dom\050d\051\051 }]) 211.38 532.67 T
(InitialBinding\050v:Var, d:Division) 54.34 520.67 T
(\051:Var) 103.27 510.67 T
6 F
(\264) 122.83 510.67 T
0 F
( \050CachingPolicy) 127.22 510.67 T
6 F
(\264) 185.01 510.67 T
0 F
( SourceRoots\051) 189.4 510.67 T
6 F
(\272) 242.75 510.67 T
0 F
(\050v, \050PromotionCachingPolicy\050d\050v\051\051, {v}\051\051) 61.54 500.67 T
(MakeStatic\050v:Var, d:Division, i:DivisionInfo\051:DivisionInfo) 54.34 488.67 T
6 F
(\272) 252.61 488.67 T
0 F
(if v) 61.54 478.67 T
6 F
(\316) 71.76 478.67 T
0 F
(StaticVars\050i\051 then i) 77.47 478.67 T
(else) 61.54 468.67 T
6 F
( \050) 76.21 468.67 T
0 F
(StaticVarInfo\050i\051) 80.87 468.67 T
6 F
(\310) 136 468.67 T
0 F
({InitialBinding\050v, d\051}, {v},) 144.15 468.67 T
6 F
(\306) 231.31 468.67 T
0 F
(\051) 237.89 468.67 T
(ProcessAssignment\050v:Var, rhs_is_static:bool, rvs:SourceRoots,) 54.34 456.67 T
(uvs:UsedVars, mds:MayDefVars,) 129.95 446.67 T
(d:Division, i:DivisionInfo) 129.95 436.67 T
(\051:Division) 129.95 426.67 T
6 F
(\264) 165.07 426.67 T
0 F
( DivisionInfo) 169.46 426.67 T
6 F
(\272) 215.25 426.67 T
0 F
(if rhs_is_static) 61.54 416.67 T
-0.44 (then ProcessStmt\050{\050v,\050CacheOneUnchecked,rvs\051\051}, mds, uvs, d, i\051) 61.54 406.67 P
(else ProcessStmt\050) 61.54 396.67 T
6 F
(\306) 126.44 396.67 T
0 F
(, mds) 133.03 396.67 T
6 F
(\310) 154.81 396.67 T
0 F
( {v}, uvs, d, i\051) 160.95 396.67 T
(ProcessStmt\050static_assigns:StaticVarInfo, dyn_assigns:Pow\050Var\051,) 54.34 384.67 T
(uvs:UsedVars, d:Division, i:DivisionInfo) 105.49 374.67 T
(\051:Division) 105.49 364.67 T
6 F
(\264) 140.6 364.67 T
0 F
( DivisionInfo) 144.99 364.67 T
6 F
(\272) 190.79 364.67 T
0 F
(\050d) 61.54 354.67 T
0 6.4 Q
(out) 68.65 352.67 T
0 8 Q
(,i) 77.55 354.67 T
0 6.4 Q
(out) 81.55 352.67 T
0 8 Q
(\051 where) 90.44 354.67 T
(ps = MayPromotedVars\050d, dyn_assigns\051) 68.74 344.67 T
(d) 68.74 334.67 T
0 6.4 Q
(out) 73.19 332.67 T
0 8 Q
( =) 82.08 334.67 T
(ForgetDeadVars\050uvs,) 91.2 334.67 T
(ForgetDynVars\050dyn_assigns) 97.54 324.67 T
6 F
(-) 200.68 324.67 T
0 F
( ps, d\051\051) 205.07 324.67 T
(ps) 68.74 314.67 T
0 6.4 Q
(out) 77.19 312.67 T
0 8 Q
( = ps) 86.08 314.67 T
6 F
(\307) 105.87 314.67 T
0 F
( dom\050d) 112.02 314.67 T
0 6.4 Q
(out) 136.91 312.67 T
0 8 Q
(\051) 145.81 314.67 T
(si = StaticVarInfo\050i\051) 68.74 304.67 T
(si\325 = si) 68.74 294.67 T
6 F
(-) 93.41 294.67 T
0 F
( { \050v,vi\051) 97.8 294.67 T
6 F
(\316) 122.25 294.67 T
0 F
(si | v) 127.95 294.67 T
6 F
(\316) 144.26 294.67 T
0 F
(dom\050static_assigns\051 }) 149.96 294.67 T
6 F
(\310) 228.21 294.67 T
0 F
( static_assigns) 234.35 294.67 T
(si) 68.74 284.67 T
0 6.4 Q
(out) 74.51 282.67 T
0 8 Q
( = ProcessDynAssigns\050) 83.41 284.67 T
(si\325, dom\050static_assigns\051, dyn_assigns, d) 104.74 274.67 T
0 6.4 Q
(out) 245.67 272.67 T
0 8 Q
(\051) 254.57 274.67 T
(i) 68.74 264.67 T
0 6.4 Q
(out) 70.51 262.67 T
0 8 Q
( = \050si) 79.41 264.67 T
0 6.4 Q
(out) 96.97 262.67 T
0 8 Q
(, ps) 105.87 264.67 T
0 6.4 Q
(out) 118.76 262.67 T
0 8 Q
(,) 127.66 264.67 T
6 F
(\306) 132.11 264.67 T
0 F
(\051) 138.69 264.67 T
(MayPromotedVars\050d:Division, vs:Pow\050Var\051\051:Promotions) 54.34 252.67 T
6 F
(\272) 253.49 252.67 T
0 F
({ v) 61.54 242.67 T
6 F
(\316) 70.43 242.67 T
0 F
(vs | v) 76.14 242.67 T
6 F
(\316) 94.67 242.67 T
0 F
(dom\050d\051) 100.37 242.67 T
6 F
(\331) 130.15 242.67 T
0 F
(PromotionPolicy\050d\050v\051\051 = AutoPromote }) 139.43 242.67 T
(ProcessDynAssigns\050si:StaticVarInfo, svs:Pow\050Var\051, dvs:Pow\050Var\051,) 54.34 230.67 T
(d:Division\051:StaticVarInfo) 130.31 220.67 T
6 F
(\272) 217.89 220.67 T
0 F
(si) 61.54 210.67 T
6 F
(-) 69.54 210.67 T
0 F
( { \050v, \050p,rvs\051\051) 73.93 210.67 T
6 F
(\316) 117.49 210.67 T
0 F
(si |) 123.19 210.67 T
(v) 137.72 210.67 T
6 F
(\316) 141.72 210.67 T
0 F
(dvs) 147.43 210.67 T
6 F
(\332) 164.32 210.67 T
(\050) 173.15 210.67 T
0 F
(v) 175.81 210.67 T
6 F
(\317) 179.81 210.67 T
0 F
(dom\050d\051) 185.51 210.67 T
6 F
(\331) 213.07 210.67 T
0 F
(rvs) 220.12 210.67 T
6 F
(\307) 230.79 210.67 T
0 F
(\050svs) 236.93 210.67 T
6 F
(\310) 251.59 210.67 T
0 F
(dvs\051) 257.74 210.67 T
6 F
(\271\306) 272.85 210.67 T
0 F
(\051 }) 283.83 210.67 T
6 F
(\310) 68.21 200.67 T
0 F
( { InitialBinding\050v, d\051 | v) 74.35 200.67 T
6 F
(\316) 155.58 200.67 T
0 F
(dom\050d\051) 161.28 200.67 T
6 F
(\331) 188.84 200.67 T
0 F
( v) 193.67 200.67 T
6 F
(\316) 199.89 200.67 T
0 F
(dvs }) 205.59 200.67 T
(ForgetDeadVars\050uvs:UsedVars, d:Division\051:Division) 54.34 188.67 T
6 F
(\272) 239.71 188.67 T
0 F
({ \050v,p\051) 61.54 178.67 T
6 F
(\316) 82.43 178.67 T
0 F
(d | v) 88.14 178.67 T
6 F
(\316) 103.11 178.67 T
0 F
(uvs }) 108.82 178.67 T
(ForgetDynVars\050vs:Pow\050Var\051, d:Division\051:Division) 54.34 166.67 T
6 F
(\272) 228.59 166.67 T
0 F
({ \050v,p\051) 61.54 156.67 T
6 F
(\316) 82.43 156.67 T
0 F
(d | v) 88.14 156.67 T
6 F
(\317) 103.11 156.67 T
0 F
(vs }) 108.82 156.67 T
(Pure\050op:Op\051:bool) 54.34 144.67 T
6 F
(\272) 117.92 144.67 T
3 F
(returns true iff) 61.54 134.67 T
0 F
(op) 110.21 134.67 T
3 F
( is idempotent and cannot raise an exception or fault;) 119.11 134.67 T
-0.43 (most operators are pure;) 61.54 124.67 P
0 F
-0.48 (div) 142.02 124.67 P
3 F
-0.43 ( and) 152.24 124.67 P
0 F
-0.48 (malloc) 167.38 124.67 P
3 F
-0.43 ( are canonical impure operators) 190.49 124.67 P
2 10 Q
(Figur) 115.72 105.34 T
(e 8: Helper Functions) 139.43 105.34 T
0 0 612 792 C
317.88 72 558 738 R
7 X
0 0 0 1 0 0 0 K
V
2 10 Q
0 X
(5.3.2) 317.88 731.33 T
5 F
(Make_Static) 344.88 731.33 T
2 F
( and) 410.88 731.33 T
5 F
(Make_Dynamic) 432 731.33 T
2 F
( Nodes) 504 731.33 T
1 9 Q
0.72 (The analysis of a) 317.88 716.43 P
4 F
1.73 (make_static) 384.24 716.43 P
1 F
0.72 ( pseudo-instruction adds a new) 443.64 716.43 P
2.46 (static variable to each of the existing divisions, replacing the) 317.88 706.43 P
1.32 (policies associated with the variable in some division if already) 317.88 696.43 P
-0.17 (present. If the variable was not already a run-time constant in some) 317.88 686.43 P
4.91 (division, then the) 317.88 676.43 P
4 F
11.79 (make_static) 397.12 676.43 P
1 F
4.91 ( instruction introduces a) 456.52 676.43 P
2.77 (dynamic-to-static promotion. The) 317.88 666.43 P
4 F
6.65 (make_dynamic) 449.68 666.43 P
1 F
2.77 ( instruction) 514.48 666.43 P
0.32 (simply removes the annotated variable from each of the in\337owing) 317.88 656.43 P
0.98 (divisions; as described above, this may cause divisions to mer) 317.88 646.43 P
0.98 (ge) 549.5 646.43 P
2.27 (and run-time static variables derived from the newly dynamic) 317.88 636.43 P
(variable to be dropped.) 317.88 626.43 T
2 10 Q
(5.3.3) 317.88 609.19 T
(Assignment and Stor) 344.88 609.19 T
(e Nodes) 434.15 609.19 T
1 9 Q
0.79 (The various forms of assignment nodes all have similar analysis,) 317.88 594.29 P
-0.07 (dependent only on whether or not the right-hand-side expression is) 317.88 584.29 P
4.4 (a run-time constant expression. Compile-time constants are) 317.88 574.29 P
0.6 (trivially run-time constants; a unary or binary expression yields a) 317.88 564.29 P
0.52 (run-time constant if its operands are run-time constants and if the) 317.88 554.29 P
0.47 (operator is a pure function \050e.g., it cannot trap and always returns) 317.88 544.29 P
1.98 (the same result given the same ar) 317.88 534.29 P
1.98 (guments\051. A load instruction) 449.07 534.29 P
1.73 (yields a run-time constant if) 317.88 524.29 P
1.73 (f its address operand is a run-time) 425.63 524.29 P
1.82 (constant \050which includes \336xed values such as the address of a) 317.88 514.29 P
1.55 (global or local variable\051 and it is annotated as) 317.88 504.29 P
4 F
3.71 (static) 498.01 504.29 P
1 F
1.55 ( by the) 530.41 504.29 P
-0.21 (programmer) 317.88 494.29 P
-0.21 (. A call to a procedure annotated by the programmer as) 361.87 494.29 P
4 F
1.89 (constant) 317.88 484.29 P
1 F
0.79 ( yields a run-time constant if all its ar) 361.08 484.29 P
0.79 (guments are. A) 501.69 484.29 P
1.61 (store instruction has no de\336nitely assigned result variable, only) 317.88 474.29 P
(potential side-ef) 317.88 464.29 T
(fects as described by the) 375.96 464.29 T
0 F
(MayDefV) 466.18 464.29 T
(ars) 502.52 464.29 T
1 F
( set.) 515.03 464.29 T
0.07 (These properties are summarized into a \050singleton or empty\051 set of) 317.88 450.71 P
0.43 (variables de\336nitely assigned run-time constant values and a set of) 317.88 440.71 P
-0.16 (variables possibly assigned dynamic expressions \050comprised of the) 317.88 430.71 P
0.68 (assigned variable if the right-hand-side expression is dynamic, as) 317.88 420.71 P
0 (well as any variables in the) 317.88 410.71 P
0 F
0.01 (MayDefV) 417.89 410.71 P
0.01 (ars) 454.23 410.71 P
1 F
0 ( set\051. The de\336nitely static) 466.74 410.71 P
0.74 (variables are added to the set of run-time constant variables. The) 317.88 400.71 P
0.83 (possibly dynamic variables are divided into those annotated with) 317.88 390.71 P
1.71 (the auto-promote policy \050which instructs the system to insert a) 317.88 380.71 P
-0.51 (dynamic-to-static promotion automatically if they ever get assigned) 317.88 370.71 P
0.62 (a dynamic value\051, and those that aren\325) 317.88 360.71 P
0.62 (t auto-promoted, which are) 458.66 360.71 P
-0.01 (dropped from the set of annotated variables and the set of run-time) 317.88 350.71 P
0.88 (constants, if present in either) 317.88 340.71 P
0.88 (. \050As with the analysis of any node,) 424.63 340.71 P
0.99 (dropping variables from the set of annotated variables can cause) 317.88 330.71 P
(divisions to mer) 317.88 320.71 T
(ge.\051) 375.72 320.71 T
2 10 Q
(5.3.4) 317.88 303.48 T
(Merge Nodes) 344.88 303.48 T
1 9 Q
3.06 (Ignoring the de\336nition and analysis of static mer) 317.88 288.57 P
3.06 (ges for the) 513.89 288.57 P
0.79 (moment, the analysis of a mer) 317.88 278.57 P
0.79 (ge node must deal with) 430.15 278.57 P
3 F
0.79 (discor) 519.83 278.57 P
0.79 (dant) 542 278.57 P
0.32 (variables) 317.88 268.57 P
1 F
0.32 ( that have potentially dif) 351.38 268.57 P
0.32 (ferent de\336nitions along dif) 440.48 268.57 P
0.32 (ferent) 537.01 268.57 P
2.21 (predecessors \050these variables were identi\336ed by a prepass and) 317.88 258.57 P
0.17 (stored with the mer) 317.88 248.57 P
0.17 (ge node, as described in section 5.2\051. For those) 387.95 248.57 P
1.7 (discordant variables that the programmer annotated as run-time) 317.88 238.57 P
-0 (constants with a polyvariant specialization policy) 317.88 228.57 P
-0 (, the analysis will) 495.01 228.57 P
-0.38 (mark this mer) 317.88 218.57 P
-0.38 (ge as a discordant mer) 366.96 218.57 P
-0.38 (ge in those variables, triggering) 445.77 218.57 P
2.7 (specialization of the mer) 317.88 208.57 P
2.7 (ge and downstream code. Any other) 414.54 208.57 P
-0.45 (discordant variables are dropped from the set of annotated variables) 317.88 198.57 P
2.13 (and run-time constants, if present. \050As usual, this dropping of) 317.88 188.57 P
1.26 (variables from the annotated set may cause divisions to mer) 317.88 178.57 P
1.26 (ge.\051) 544.26 178.57 P
7.38 (Derived run-time constants are implicitly monovariantly) 317.88 168.57 P
6.09 (specialized, since they were not explicitly annotated as) 317.88 158.57 P
0.81 (polyvariantly specialized by the programmer) 317.88 148.57 P
0.81 (. The caching policy) 482.09 148.57 P
0.78 (for all discordant variables at the mer) 317.88 138.57 P
0.78 (ge is set to those variables\325) 456.86 138.57 P
(mer) 317.88 128.57 T
(ge caching policy) 331.71 128.57 T
(.) 394.61 128.57 T
2.87 (Static mer) 317.88 115 P
2.87 (ges are mer) 357.33 115 P
2.87 (ges where at most one of the mer) 404.38 115 P
2.87 (ge\325) 543.5 115 P
2.87 (s) 554.5 115 P
4.03 (predecessors can appear at specialization time, because the) 317.88 105 P
4.2 (predecessors are reached only on mutually exclusive static) 317.88 95 P
1.89 (conditions. Since only one predecessor will be specialized, the) 317.88 85 P
0.6 (mer) 317.88 75 P
0.6 (ge node won\325) 331.71 75 P
0.6 (t actually mer) 381.74 75 P
0.6 (ge any branches in the specialized) 432.27 75 P
0 0 0 1 0 0 0 K
FMENDPAGE
%%EndPage: "10" 10
%%Page: "11" 11
612 792 0 FMBEGINPAGE
[0 0 0 1 0 0 0]
[ 0 1 1 0 1 0 0]
[ 1 0 1 0 0 1 0]
[ 1 1 0 0 0 0 1]
[ 1 0 0 0 0 1 1]
[ 0 1 0 0 1 0 1]
[ 0 0 1 0 1 1 0]
 7 FrameSetSepColors
FrameNoSep
0 0 0 1 0 0 0 K
54 26 558 44 R
7 X
0 0 0 1 0 0 0 K
V
0 0 0 1 0 0 0 K
0 0 0 1 0 0 0 K
54 72 294.12 738 R
V
1 9 Q
0 X
3.93 (code; hence each of the input divisions is passed through) 54 732 P
-0.26 (unchanged without introducing any cache check points. Subsection) 54 722 P
(5.4 explains how static mer) 54 712 T
(ges are identi\336ed.) 152.58 712 T
2 10 Q
(5.3.5) 54 695.26 T
(Other Nodes) 81 695.26 T
1 9 Q
2.43 (The analysis of a branch node simply replicates its incoming) 54 680.86 P
-0.04 (information along both successors \050as always, after \336ltering the set) 54 670.86 P
1.63 (of variables to exclude those that are no longer live along that) 54 660.86 P
-0.01 (successor\051. Return nodes need no analysis function, since there are) 54 650.86 P
0.65 (no program points after return nodes, and we do not currently do) 54 640.86 P
(interprocedural \337ow analysis of annotations.) 54 630.86 T
2 10 Q
(5.3.6) 54 614.12 T
(Caching Policies and Derivations of) 81 614.12 T
(Static V) 81 602.12 T
(ariables) 114.24 602.12 T
1 9 Q
0.14 (At each program point, the analysis computes a caching policy for) 54 587.71 P
0.24 (each variable. This policy is used to control indexing into the run-) 54 577.71 P
-0.38 (time specializer) 54 567.71 P
-0.38 (\325) 110.69 567.71 P
-0.38 (s caches of previously specialized code. Annotated) 113.19 567.71 P
1.81 (variables at promotion points \050and at the start of analysis of a) 54 557.71 P
2.11 (division of a specialized function\051 are given the user) 54 547.71 P
2.11 (-speci\336ed) 259.13 547.71 P
0 F
6.79 (PromotionCachingPolicy) 54 537.71 P
1 F
6.11 ( value. At discordant mer) 152.03 537.71 P
6.11 (ges, a) 267.52 537.71 P
8.13 (discordant variable is changed to use the variable\325) 54 527.71 P
8.13 (s) 290.62 527.71 P
0 F
(MergeCachingPolicy) 54 517.71 T
1 F
( value.) 136.52 517.71 T
0.52 (Derived run-time constants are given the) 54 504.64 P
0 F
0.58 (CacheOneUnchecked) 206.08 504.64 P
1 F
0.25 (policy) 54 494.64 P
0.25 (. This ensures that unannotated run-time constants are never) 75.92 494.64 P
0.62 (used in cache lookups and consequently do not lead to additional) 54 484.64 P
1.42 (specialization beyond that explicitly requested by the user) 54 474.64 P
1.42 (. This) 272.19 474.64 P
0.27 (unchecked caching policy is safe as long as each derived run-time) 54 464.64 P
1.79 (constant is a pure function of some set of annotated variables,) 54 454.64 P
0.27 (which are checked during cache lookups \050unless the user speci\336es) 54 444.64 P
0.24 (explicitly that no checking is required\051. An annotated variable can) 54 434.64 P
0.97 (be assigned a static expression, in which case it is treated \050more) 54 424.64 P
9.37 (ef) 54 414.64 P
9.37 (\336ciently\051 as a derived run-time constant with a) 60.83 414.64 P
0 F
-0.38 (CacheOneUnchecked) 54 404.64 P
1 F
-0.34 ( policy) 142.04 404.64 P
-0.34 (, instead of whatever caching policy) 165.86 404.64 P
(with which the variable was annotated.) 54 394.64 T
-0.17 (Assignments to root annotated variables can break the assumptions) 54 381.57 P
0.22 (that some derived run-time expression is a function of some set of) 54 371.57 P
2.33 (root annotated variables. In such a case, the derived run-time) 54 361.57 P
0.65 (constants need to be dropped from the set of static variables, and) 54 351.57 P
0.94 (annotated derived run-time constants need to be restored to their) 54 341.57 P
2.72 (regular explicit) 54 331.57 P
0 F
3.03 (PromotionCachingPolicy) 116.43 331.57 P
1 F
2.72 ( value. The analysis) 214.46 331.57 P
0.58 (tracks the set of root annotated variables on which a derived run-) 54 321.57 P
0.52 (time constant depends, and whenever a root variable is \050possibly\051) 54 311.57 P
-0.21 (assigned to or is removed from the division, all dependent run-time) 54 301.57 P
-0.25 (constants are dropped \050or restored to their regular caching policy) 54 291.57 P
-0.25 (, if) 284.37 291.57 P
(roots themselves\051.) 54 281.57 T
2 10 Q
(5.3.7) 54 264.83 T
(Additional Lattice Meet Operations) 81 264.83 T
1 9 Q
0.47 (The) 54 250.43 P
0 F
0.52 (Merge) 70.71 250.43 P
1 F
0.47 ( helper function uses the lattice meet operators for the) 96.22 250.43 P
0 F
2.72 (Division) 54 240.43 P
1 F
2.45 ( and) 85.5 240.43 P
0 F
2.72 (DivisionInfo) 107.89 240.43 P
1 F
2.45 ( domains. The lattice meet operator) 154.4 240.43 P
6 F
2.19 (\307) 54 230.43 P
0 7.2 Q
1.95 (Division) 60.91 228.18 P
1 9 Q
2.19 ( over elements of) 86.11 230.43 P
0 F
2.44 (Division) 159.36 230.43 P
1 F
2.19 ( indicates how to combine) 190.86 230.43 P
-0.2 (dif) 54 220.43 P
-0.2 (ferent annotations for a set of variables in the same division, and) 63.84 220.43 P
(is de\336ned as follows:) 54 210.43 T
0 8 Q
(d) 61.2 199.02 T
0 6.4 Q
(1) 65.65 197.02 T
6 11 Q
(\307) 71.43 199.02 T
0 8.8 Q
(Division) 79.88 196.27 T
0 8 Q
( d) 110.68 199.02 T
0 6.4 Q
(2) 117.35 197.02 T
6 8 Q
(\272) 125.36 199.02 T
0 F
({ \050v,p\051 | v) 68.4 189.02 T
6 F
(\316) 99.82 189.02 T
0 F
(dom\050d) 105.53 189.02 T
0 6.4 Q
(1) 128.2 187.02 T
0 8 Q
(\051) 131.76 189.02 T
6 F
(\307) 134.42 189.02 T
0 F
(dom\050d) 140.57 189.02 T
0 6.4 Q
(2) 163.24 187.02 T
0 8 Q
(\051) 166.8 189.02 T
6 F
(\331) 173.91 189.02 T
0 F
(p = d) 183.18 189.02 T
0 6.4 Q
(1) 201.2 187.02 T
0 8 Q
(\050v\051) 204.76 189.02 T
6 F
(\307) 216.31 189.02 T
0 6.4 Q
(Policies) 222.45 187.02 T
0 8 Q
( d) 244.5 189.02 T
0 6.4 Q
(2) 251.17 187.02 T
0 8 Q
(\050v\051 }) 254.73 189.02 T
1 9 Q
1.36 (Elements of) 54 175.29 P
0 F
1.51 (Policies) 102.21 175.29 P
1 F
1.36 ( are met pointwise. Elements of individual) 133.22 175.29 P
0.63 (policy domains are totally ordered, with elements listed earlier in) 54 165.29 P
0.85 (the set of alternatives for a domain in Figure 5 ordered less than) 54 155.29 P
(elements listed later; for example:) 54 145.29 T
0 8 Q
(AutoPromote) 61.2 133.88 T
6 F
(\243) 110.11 133.88 T
0 6.4 Q
(PromotionPolicy) 114.5 131.88 T
0 8 Q
( ManualPromote) 160.74 133.88 T
1 9 Q
2.3 (Thus, the lattice meet operator for a particular policy domain) 54 120.14 P
(returns its minimum ar) 54 110.14 T
(gument, e.g.:) 136.09 110.14 T
0 8 Q
(AutoPromote) 61.2 98.74 T
6 F
(\307) 110.11 98.74 T
0 6.4 Q
(PromotionPolicy) 116.26 96.74 T
0 8 Q
( ManualPromote = AutoPromote) 162.49 98.74 T
1 9 Q
-0.15 (This rule has the ef) 54 85 P
-0.15 (fect of picking the strongest policy of any of the) 122.23 85 P
(mer) 54 75 T
(ging divisions.) 67.83 75 T
317.88 72 558 738 R
7 X
V
0 X
5.9 (The lattice meet operator) 317.88 732 P
6 F
5.9 (\307) 433.95 732 P
0 7.2 Q
5.25 (DivisionInfo) 440.86 729.75 P
1 9 Q
5.9 ( over elements of) 478.07 732 P
0 F
0.66 (DivisionInfo) 317.88 722 P
1 F
0.6 ( is de\336ned as the pointwise meet over its component) 364.39 722 P
(domains, which are de\336ned as follows:) 317.88 712 T
0 8 Q
(si) 325.08 700.12 T
0 6.4 Q
(1) 330.86 698.12 T
6 8 Q
(\307) 336.64 700.12 T
0 6.4 Q
(StaticVarInfo) 342.78 698.12 T
0 8 Q
( si) 379.42 700.12 T
0 6.4 Q
(2) 387.42 698.12 T
6 8 Q
(\272) 395.43 700.12 T
0 F
({ \050v, \050p,rvs\051\051 | v) 332.28 690.12 T
6 F
(\316) 384.14 690.12 T
0 F
(dom\050si) 389.85 690.12 T
0 6.4 Q
(1) 413.85 688.12 T
0 8 Q
(\051) 417.41 690.12 T
6 F
(\310) 420.07 690.12 T
0 F
(dom\050si) 426.21 690.12 T
0 6.4 Q
(2) 450.21 688.12 T
0 8 Q
(\051) 453.77 690.12 T
6 F
(\331) 460.88 690.12 T
0 F
(p = p) 381.21 680.12 T
0 6.4 Q
(1) 399.22 678.12 T
6 8 Q
(\307) 405.01 680.12 T
0 6.4 Q
(CachingPolicy) 411.15 678.12 T
0 8 Q
( p) 451.69 680.12 T
0 6.4 Q
(2) 458.37 678.12 T
6 8 Q
(\331) 466.37 680.12 T
0 F
(rvs = rvs) 381.21 670.12 T
0 6.4 Q
(1) 411.66 668.12 T
6 8 Q
(\310) 417.44 670.12 T
0 F
( rvs) 423.58 670.12 T
0 6.4 Q
(2) 436.47 668.12 T
0 8 Q
(where p) 346.68 660.12 T
0 6.4 Q
(2) 375.14 658.12 T
0 8 Q
( = if v) 378.69 660.12 T
6 F
(\316) 398.04 660.12 T
0 F
(dom\050si) 403.74 660.12 T
0 6.4 Q
(2) 427.74 658.12 T
0 8 Q
(\051 then CachingPolicy\050si) 431.3 660.12 T
0 6.4 Q
(2) 513.1 658.12 T
0 8 Q
(\050v\051\051) 516.66 660.12 T
(else CacheOneUnchecked) 437.86 650.12 T
(p) 368.68 640.12 T
0 6.4 Q
(1) 373.13 638.12 T
0 8 Q
( = if v) 376.69 640.12 T
6 F
(\316) 396.03 640.12 T
0 F
(dom\050si) 401.73 640.12 T
0 6.4 Q
(1) 425.73 638.12 T
0 8 Q
(\051 then CachingPolicy\050si) 429.29 640.12 T
0 6.4 Q
(1) 511.09 638.12 T
0 8 Q
(\050v\051\051) 514.65 640.12 T
(else CacheOneUnchecked) 437.86 630.12 T
(rvs) 368.68 620.12 T
0 6.4 Q
(1) 379.34 618.12 T
0 8 Q
( = if v) 382.9 620.12 T
6 F
(\316) 402.25 620.12 T
0 F
(dom\050si) 407.95 620.12 T
0 6.4 Q
(1) 431.95 618.12 T
0 8 Q
(\051 then SourceRoots\050si) 435.51 620.12 T
0 6.4 Q
(1) 512.87 618.12 T
0 8 Q
(\050v\051\051 else) 516.43 620.12 T
6 F
(\306) 547.54 620.12 T
0 F
-0.25 (rvs) 368.68 610.12 P
0 6.4 Q
-0.2 (2) 379.34 608.12 P
0 8 Q
-0.25 ( = if v) 382.9 610.12 P
6 F
-0.22 (\316) 401.5 610.12 P
0 F
-0.25 (dom\050si) 407.2 610.12 P
0 6.4 Q
-0.2 (2) 431.2 608.12 P
0 8 Q
-0.25 (\051 then SourceRoots\050si) 434.76 610.12 P
0 6.4 Q
-0.2 (2) 511.63 608.12 P
0 8 Q
-0.25 (\050v\051\051 else) 515.18 610.12 P
6 F
-0.22 (\306 }) 545.8 610.12 P
0 F
(vs) 325.08 597.58 T
0 6.4 Q
(1) 333.08 595.58 T
6 8 Q
(\307) 338.86 597.58 T
0 6.4 Q
(Promotions) 345.01 595.58 T
0 8 Q
( vs) 377.37 597.58 T
0 6.4 Q
(2) 387.6 595.58 T
6 8 Q
(\272) 395.6 597.58 T
0 F
(vs) 403.99 597.58 T
0 6.4 Q
(1) 411.99 595.58 T
6 8 Q
(\310) 415.55 597.58 T
0 F
(vs) 421.7 597.58 T
0 6.4 Q
(2) 429.7 595.58 T
0 8 Q
(vs) 325.08 585.03 T
0 6.4 Q
(1) 333.08 583.03 T
6 8 Q
(\307) 338.86 585.03 T
0 6.4 Q
(DiscordantVars) 345.01 583.03 T
0 8 Q
( vs) 388.75 585.03 T
0 6.4 Q
(2) 398.97 583.03 T
6 8 Q
(\272) 406.98 585.03 T
0 F
(vs) 415.37 585.03 T
0 6.4 Q
(1) 423.37 583.03 T
6 8 Q
(\310) 426.93 585.03 T
0 F
(vs) 433.07 585.03 T
0 6.4 Q
(2) 441.07 583.03 T
2 10 Q
(5.4) 317.88 567.15 T
(Reachability Analysis) 335.88 567.15 T
1 9 Q
2.92 (W) 317.88 552.27 P
2.92 (e identify static mer) 325.66 552.27 P
2.92 (ges by computing a) 405.99 552.27 P
3 F
2.92 (static r) 490.16 552.27 P
2.92 (eachability) 518 552.27 P
3.35 (condition) 317.88 542.27 P
1 F
3.35 ( at each program point for each division. A static) 351.88 542.27 P
2.7 (reachability condition is a boolean expression \050in conjunctive) 317.88 532.27 P
-0.28 (normal form\051 over static branch outcomes that are required in order) 317.88 522.27 P
0.16 (to reach that program point. A static branch is a branch whose test) 317.88 512.27 P
0.07 (variable is identi\336ed as a run-time constant by the) 317.88 502.27 P
3 F
0.07 (BT) 500.27 502.27 P
0.07 (A) 510.11 502.27 P
1 F
0.07 ( analysis. A) 515.61 502.27 P
1.23 (static mer) 317.88 492.27 P
1.23 (ge is one whose predecessors have mutually exclusive) 354.19 492.27 P
6.73 (static reachability conditions. Reachability conditions are) 317.88 482.27 P
-0.34 (computed at the same time as the) 317.88 472.27 P
3 F
-0.34 (BT) 437.27 472.27 P
-0.34 (A) 447.1 472.27 P
1 F
-0.34 ( information, since it depends) 452.6 472.27 P
-0.22 (on the) 317.88 462.27 P
3 F
-0.22 (BT) 341.94 462.27 P
-0.22 (A) 351.78 462.27 P
1 F
-0.22 (\325) 356.28 462.27 P
-0.22 (s division and static variable analysis and in\337uences the) 358.78 462.27 P
3 F
3.21 (BT) 317.88 452.27 P
3.21 (A) 327.72 452.27 P
1 F
3.21 ( analysis\325) 333.22 452.27 P
3.21 (s treatment of mer) 370.18 452.27 P
3.21 (ge nodes. Further details on) 445.4 452.27 P
-0.08 (reachability analysis can be found in an earlier paper [Auslander) 317.88 442.27 P
3 F
-0.08 (et) 551.5 442.27 P
(al.) 317.88 432.27 T
1 F
( 96].) 327.13 432.27 T
2 12 Q
(6) 317.88 410.73 T
(Generating the Run-T) 335.88 410.73 T
(ime Specializer) 449.66 410.73 T
1 9 Q
2.48 (Given the output of the) 317.88 395.18 P
3 F
2.48 (BT) 416.01 395.18 P
2.48 (A) 425.85 395.18 P
1 F
2.48 ( analysis, our compiler statically) 431.35 395.18 P
-0.26 (constructs the code and static data structures that, when executed at) 317.88 385.18 P
-0.31 (run time, will call the run-time specializer with the appropriate run-) 317.88 375.18 P
3.42 (time constant ar) 317.88 365.18 P
3.42 (guments to produce and cache the run-time) 382.04 365.18 P
1.42 (specialized code \050i.e., the generating extensions\051. The following) 317.88 355.18 P
(steps are performed:) 317.88 345.18 T
(\245) 325.08 332.64 T
1.71 (The compiler statically replicates control-\337ow paths so that) 332.28 332.64 P
1.94 (each division receives its own code. After replication each) 332.28 322.64 P
2.06 (program point corresponds to a single division. Points can) 332.28 312.64 P
3.91 (begin to be replicated at entry to specialized functions) 332.28 302.64 P
2.27 (\050producing several distinct functions\051, and at mer) 332.28 292.64 P
2.27 (ge points) 522.98 292.64 P
3.94 (where dif) 332.28 282.64 P
3.94 (ferent divisions combine. Replicated paths can) 370.3 282.64 P
-0.19 (remer) 332.28 272.64 P
-0.19 (ge at points where divisions cease to dif) 353.11 272.64 P
-0.19 (fer and are joined) 495.35 272.64 P
(by the) 332.28 262.64 T
0 F
(Merge) 356.78 262.64 T
1 F
( function.) 382.28 262.64 T
(\245) 325.08 250.09 T
0.41 (The compiler identi\336es which branch successor edges need to) 332.28 250.09 P
0.97 (be lazy specialization edges. Subsection 6.1 discusses this in) 332.28 240.09 P
(more detail.) 332.28 230.09 T
(\245) 325.08 217.55 T
-0.28 (The compiler identi\336es the boundaries of the units manipulated) 332.28 217.55 P
2.81 (by the run-time specializer \050described in section 3\051. Unit) 332.28 207.55 P
8.44 (boundaries primarily correspond to dynamic-to-static) 332.28 197.55 P
4.33 (promotion points, demotion points \050where variables are) 332.28 187.55 P
3.18 (removed from the set of annotated variables\051, discordant) 332.28 177.55 P
0.3 (mer) 332.28 167.55 P
0.3 (ges, and lazy branch successor edges. The \336rst three cases) 346.11 167.55 P
0.97 (are cache lookup points, and the last case avoids speculative) 332.28 157.55 P
2.5 (specialization. This process is described in more detail in) 332.28 147.55 P
0.6 (subsection 6.2 below) 332.28 137.55 P
0.6 (. A clustering algorithm then attempts to) 408.64 137.55 P
0.02 (mer) 332.28 127.55 P
0.02 (ge boundaries together to minimize their cost, as described) 346.11 127.55 P
0.49 (in subsection 6.3. The) 332.28 117.55 P
4 F
1.18 (Unit) 415.75 117.55 P
1 F
0.49 ( and) 437.35 117.55 P
4 F
1.18 (UnitEdge) 455.83 117.55 P
1 F
0.49 ( specializer data) 499.03 117.55 P
(structures are generated at the end of this process.) 332.28 107.55 T
(\245) 325.08 95 T
0.07 (The compiler separates the static operations \050) 332.28 95 P
0 F
0.08 (OpNode) 495.67 95 P
1 F
0.07 (s whose) 529.18 95 P
0.41 (right-hand-side expressions were computed to be static by the) 332.28 85 P
3 F
1.08 (BT) 332.28 75 P
1.08 (A) 342.12 75 P
1 F
1.08 ( analysis\051 and the dynamic operations into two separate,) 347.62 75 P
0 0 0 1 0 0 0 K
FMENDPAGE
%%EndPage: "11" 11
%%Page: "12" 12
612 792 0 FMBEGINPAGE
[0 0 0 1 0 0 0]
[ 0 1 1 0 1 0 0]
[ 1 0 1 0 0 1 0]
[ 1 1 0 0 0 0 1]
[ 1 0 0 0 0 1 1]
[ 0 1 0 0 1 0 1]
[ 0 0 1 0 1 1 0]
 7 FrameSetSepColors
FrameNoSep
0 0 0 1 0 0 0 K
54 26 558 44 R
7 X
0 0 0 1 0 0 0 K
V
0 0 0 1 0 0 0 K
0 0 0 1 0 0 0 K
54 72 294.12 738 R
V
1 9 Q
0 X
-0.11 (parallel control \337ow subgraphs; in earlier work we called these) 68.4 732 P
2.34 (subgraphs \322set-up code\323 and \322template code,\323 respectively) 68.4 722 P
1.62 ([Auslander) 68.4 712 P
3 F
1.62 (et al.) 112.26 712 P
1 F
1.62 ( 96]. Subsection 6.4 discusses some issues) 131.88 712 P
-0.28 (with this separation in more detail. W) 68.4 702 P
-0.28 (e apply standard compiler) 201.73 702 P
2.35 (optimizations, including instruction scheduling and register) 68.4 692 P
1.15 (allocation, to each subgraph separately) 68.4 682 P
1.15 (. \050W) 212.11 682 P
1.15 (e perform higher) 228.53 682 P
1.15 (-) 291.12 682 P
4.43 (level tar) 68.4 672 P
4.43 (get-independent optimizations such as common-) 101.91 672 P
1.21 (subexpression elimination and loop optimizations before our) 68.4 662 P
3 F
-0.56 (BT) 68.4 652 P
-0.56 (A) 78.24 652 P
1 F
-0.56 ( analysis.\051 Performing these regular compiler optimizations) 83.74 652 P
-0.53 (over both statically compiled and dynamically compiled code is) 68.4 642 P
(crucial for generating high-quality code [Auslander) 68.4 632 T
3 F
(et al.) 255.85 632 T
1 F
( 96].) 273.85 632 T
(\245) 61.2 619.69 T
1.36 (Finally) 68.4 619.69 P
1.36 (, each unit\325) 93.32 619.69 P
1.36 (s) 135.79 619.69 P
4 F
3.27 (ReduceAndResidualize) 142.9 619.69 P
1 F
1.36 ( function is) 250.9 619.69 P
0.6 (produced. First, the control-\337ow and the reduce operations of) 68.4 609.69 P
-0.54 (the) 68.4 599.69 P
4 F
-1.3 (ReduceAndResidualize) 81.11 599.69 P
1 F
-0.54 ( function are derived from the) 189.11 599.69 P
3.75 (static control-\337ow subgraph, after removing all dynamic) 68.4 589.69 P
0.33 (branches from the static subgraph; this process is described in) 68.4 579.69 P
0.59 (more detail in subsection 6.5. Then the residualize operations) 68.4 569.69 P
3 (are introduced by translating the operations and dynamic) 68.4 559.69 P
2.89 (branches of the dynamic subgraph into code to emit the) 68.4 549.69 P
6.7 (dynamic instructions \050perhaps with run-time constant) 68.4 539.69 P
0.81 (operands\051 in the static subgraph. This process is described in) 68.4 529.69 P
1.35 (more detail in subsection 6.6 below) 68.4 519.69 P
1.35 (. The resulting subgraph) 202.57 519.69 P
0.75 (forms the) 68.4 509.69 P
4 F
1.79 (ReduceAndResidualize) 106.39 509.69 P
1 F
0.75 ( function for the unit,) 214.39 509.69 P
(and the dynamic subgraph is thrown away) 68.4 499.69 T
(.) 219.79 499.69 T
1.88 (Some optimizations of the calls to the run-time specializer are) 54 486.39 P
(discussed in subsection 6.7.) 54 476.39 T
2 10 Q
(6.1) 54 459.41 T
(Computing Lazy Branch Successors) 72 459.41 T
1 9 Q
1.46 (Laziness policies on variables indicate the extent of speculative) 54 444.77 P
0.12 (specialization after dynamic branches that should be performed. A) 54 434.77 P
0.32 (branch successor is a lazy edge if) 54 424.77 P
0.32 (f its test variable is dynamic and) 175.72 424.77 P
(at least one of the following conditions holds:) 54 414.77 T
(\245) 61.2 402.46 T
-0.32 (At least one of the run-time constants at the branch is annotated) 68.4 402.46 P
(with the) 68.4 392.46 T
0 F
(Lazy) 99.9 392.46 T
1 F
( policy) 118.91 392.46 T
(.) 143.07 392.46 T
(\245) 61.2 380.15 T
1.29 (The branch successor edge) 68.4 380.15 P
3 F
1.29 (determines execution) 172.53 380.15 P
1 F
1.29 ( \050as de\336ned) 250.05 380.15 P
0.25 (below\051 of a predecessor edge of a later discordant mer) 68.4 370.15 P
0.25 (ge node) 265.63 370.15 P
-0.02 (where at least one of the discordant variables is annotated with) 68.4 360.15 P
(the) 68.4 350.15 T
0 F
(SpecializeLazy) 81.65 350.15 T
1 F
( policy) 141.67 350.15 T
(.) 165.83 350.15 T
(\245) 61.2 337.85 T
4.86 (The branch successor edge determines execution of a) 68.4 337.85 P
0.91 (predecessor edge of a later discordant loop head mer) 68.4 327.85 P
0.91 (ge node) 264.97 327.85 P
-0.02 (where at least one of the discordant variables is annotated with) 68.4 317.85 P
(the) 68.4 307.85 T
0 F
(LoopSpecializeLazy) 81.65 307.85 T
1 F
( policy) 161.68 307.85 T
(.) 185.85 307.85 T
(\245) 61.2 295.54 T
0.06 (The branch successor edge determines execution of a later call) 68.4 295.54 P
1.42 (to a specialized division of a procedure, and some run-time) 68.4 285.54 P
-0.06 (constant live at the call is not annotated with the) 68.4 275.54 P
0 F
-0.07 (Eager) 243.76 275.54 P
1 F
-0.06 ( policy) 267.77 275.54 P
-0.06 (.) 291.87 275.54 P
1.44 (W) 54 262.23 P
1.44 (e say that a branch successor edge determines execution of a) 61.78 262.23 P
0.2 (program point if) 54 252.23 P
0.2 (f the edge is postdominated by the program point,) 113.24 252.23 P
0.47 (but the branch node itself is not, i.e., the branch successor is \050one) 54 242.23 P
0.62 (of\051 the earliest points where it is determined that the downstream) 54 232.23 P
(program point will eventually be executed.) 54 222.23 T
4.13 (Once the dominator information relating program points is) 54 208.92 P
1.77 (computed, a linear scan over the dynamic branches, discordant) 54 198.92 P
2.09 (mer) 54 188.92 P
2.09 (ges, and specialized calls serves to compute the lazy edge) 67.83 188.92 P
(information.) 54 178.92 T
2 10 Q
(6.2) 54 161.95 T
(Unit Identi\336cation) 72 161.95 T
1 9 Q
2.15 (Each interaction with the run-time specializer) 54 147.31 P
2.15 (, including cache) 228.59 147.31 P
0.15 (lookup points and demand-driven specialization points, introduces) 54 137.31 P
0.11 (a unit boundary) 54 127.31 P
0.11 (. T) 110.13 127.31 P
0.11 (o identify the boundaries based on cache lookup) 119.61 127.31 P
0.79 (points, we \336rst compute the) 54 117.31 P
3 F
0.79 (cache context) 159.95 117.31 P
1 F
0.79 ( at each program point) 209.97 117.31 P
(from the set of static variables at that point, as follows:) 54 107.31 T
(\245) 61.2 95 T
10.71 (If any static variable is annotated with the) 68.4 95 P
0 F
2.27 (CacheAllUnchecked) 68.4 85 P
1 F
2.04 ( policy) 149.43 85 P
2.04 (, then the cache context is the) 175.63 85 P
(special marker) 68.4 75 T
0 F
(replicate.) 123.38 75 T
317.88 72 558 738 R
7 X
V
1 F
0 X
(\245) 325.08 478.54 T
0.39 (Otherwise, the cache context is the pair of the set of variables) 332.28 478.54 P
1.22 (annotated with the) 332.28 468.54 P
0 F
1.36 (CacheAll) 404.68 468.54 P
1 F
1.22 ( policy and the set of variables) 440.69 468.54 P
1.45 (annotated with the) 332.28 458.54 P
0 F
1.61 (CacheOne) 405.36 458.54 P
1 F
1.45 ( policy) 448.38 458.54 P
1.45 (. \050The set of variables) 473.99 458.54 P
0.86 (annotated with CacheOneUnchecked do not contribute to the) 332.28 448.54 P
(cache context.\051) 332.28 438.54 T
2.78 (Given the cache context and the other program-point-speci\336c) 317.88 425.48 P
(information, unit boundaries are identi\336ed as follows:) 317.88 415.48 T
(\245) 325.08 403.42 T
2.13 (Any point where the cache context dif) 332.28 403.42 P
2.13 (fers from the cache) 482.38 403.42 P
3.26 (context at predecessor point\050s\051 is a unit boundary) 332.28 393.42 P
3.26 (, since) 531.74 393.42 P
2.6 (dif) 332.28 383.42 P
2.6 (ferent degrees of polyvariant specialization or of cache) 342.12 383.42 P
(retention can occur) 332.28 373.42 T
(.) 400.76 373.42 T
(\245) 325.08 361.36 T
0.47 (A non-empty) 332.28 361.36 P
0 F
0.52 (Promotions) 383.21 361.36 P
1 F
0.47 ( set at a program point corresponds) 428.72 361.36 P
0.87 (to a dynamic-to-static promotion point, and introduces a unit) 332.28 351.36 P
(boundary) 332.28 341.36 T
(.) 365.69 341.36 T
(\245) 325.08 329.3 T
6.73 (A non-empty) 332.28 329.3 P
0 F
7.48 (DiscordantV) 395.74 329.3 P
7.48 (ars) 444.08 329.3 P
1 F
6.73 ( list corresponds to a) 456.58 329.3 P
(specializable mer) 332.28 319.3 T
(ge point, and induces a unit boundary) 394.85 319.3 T
0 F
(.) 529.42 319.3 T
1 F
(\245) 325.08 307.24 T
(Each edge labelled as a lazy edge introduces a unit boundary) 332.28 307.24 T
(.) 550.64 307.24 T
0.76 (In addition, units are constrained to be single-entry regions, so if) 317.88 294.18 P
1.05 (any units would otherwise have multiple entry points, additional) 317.88 284.18 P
0.84 (unit boundaries are inserted at control-\337ow mer) 317.88 274.18 P
0.84 (ges of paths with) 494.23 274.18 P
1.5 (dif) 317.88 264.18 P
1.5 (ferent unit entries. It is possible for a program point to be a) 327.72 264.18 P
(boundary in more ways than one; only a single boundary results.) 317.88 254.18 T
1.93 (The) 317.88 241.12 P
4 F
4.64 (UnitEdge) 336.06 241.12 P
1 F
1.93 ( data structure records whether each unit edge) 379.26 241.12 P
0.95 (should be specialized eagerly or lazily) 317.88 231.12 P
0.95 (. A unit boundary is eager) 459.77 231.12 P
0.53 (unless it is a promotion point \050which must be suspended until the) 317.88 221.12 P
(computed run-time value is available\051 or a lazy edge.) 317.88 211.12 T
0.22 (Figure 9 illustrates the units \050shown in gray\051 that are identi\336ed for) 317.88 198.06 P
3.96 (the interpreter example in Figure 2. The two entry points) 317.88 188.06 P
1.39 (correspond to the specialized and unspecialized divisions of the) 317.88 178.06 P
4 F
0.09 (interp_fn) 317.88 168.06 P
1 F
0.04 ( function. The unspecialized entry point and the false) 366.48 168.06 P
0.32 (branches of both the specialized and unspecialized versions of the) 317.88 158.06 P
2.83 (conditional-specialization tests lead to unspecialized, statically) 317.88 148.06 P
0.79 (compiled code. Demotions \050indicated by) 317.88 138.06 P
3 F
0.79 (D) 470.3 138.06 P
1 F
0.79 (\051 of) 476.8 138.06 P
4 F
1.89 (bytecodes) 493.37 138.06 P
1 F
0.79 ( and) 541.97 138.06 P
4 F
(pc) 317.88 128.06 T
1 F
( are required on the edge from the specialized test.) 328.68 128.06 T
0.24 (The specialized entry point begins unit 1, and the true branches of) 317.88 115 P
0.17 (the tests mer) 317.88 105 P
0.17 (ge at the code to be specialized forming unit 2, which) 363.56 105 P
0.32 (is created due to the dynamic-to-static promotion \050indicated by) 317.88 95 P
3 F
0.32 ( P) 546.93 95 P
1 F
0.32 (\051) 555 95 P
0.85 (of) 317.88 85 P
4 F
2.04 (bytecodes) 328.48 85 P
1 F
0.85 ( and) 377.08 85 P
4 F
2.04 (pc) 396.27 85 P
1 F
0.85 ( on the edge from the unspecialized test.) 407.07 85 P
0.54 (Unit 3, which contains the loop body to be specialized, is created) 317.88 75 P
317.88 72 558 738 C
317.88 484.54 558 738 C
0 0 0 1 0 0 0 K
0 0 0 1 0 0 0 K
316.44 484.54 559.44 738 R
7 X
0 0 0 1 0 0 0 K
V
474.25 531.97 558.19 546.86 7.45 RR
5 X
V
0.5 H
2 Z
0 X
N
344.44 562.98 550.73 620.04 9 RR
5 X
V
0 X
N
346.61 658.45 436.04 683.86 9 RR
5 X
V
0 X
N
345.11 698.78 437.04 723.86 9 RR
5 X
V
0 X
N
353.46 701.59 428.69 719.41 R
7 X
V
0 X
N
462.12 701.59 537.34 719.41 R
7 X
V
0 X
N
353.46 661.91 428.69 679.72 R
7 X
V
0 X
N
462.12 630.1 537.34 682.22 R
7 X
V
0 X
N
355.96 598.12 428.33 615.44 R
7 X
V
0 X
N
355.46 571.4 411.97 589.21 R
7 X
V
0 X
N
486.33 572.06 544.83 589.88 R
7 X
V
0 X
N
420.53 572.06 482.53 589.88 R
7 X
V
0 X
N
488.61 534.67 547.12 543.58 R
7 X
V
0 X
N
388.19 685.97 386.54 680.21 384.88 685.97 386.54 685.97 4 Y
V
386.54 702.09 386.54 685.97 2 L
N
502.05 686.67 507.52 684.21 501.58 683.39 501.81 685.03 4 Y
V
386 701.71 501.82 685.03 2 L
N
388.19 621.18 386.54 615.41 384.88 621.18 386.54 621.18 4 Y
V
386.54 657.21 386.54 621.18 2 L
N
380.19 594.98 378.54 589.21 376.88 594.98 378.54 594.98 4 Y
V
378.54 598.12 378.54 594.98 2 L
N
394.75 680.16 388.77 680.71 394.13 683.41 394.44 681.78 4 Y
V
499.53 701.71 394.44 681.78 2 L
N
506.56 688.97 504.91 683.21 503.26 688.97 504.91 688.97 4 Y
V
504.91 701.25 504.91 688.97 2 L
N
388.55 725.18 386.9 719.41 385.24 725.18 386.9 725.18 4 Y
V
386.9 728.32 386.9 725.18 2 L
N
502.56 724.68 500.91 718.91 499.26 724.68 500.91 724.68 4 Y
V
500.91 727.82 500.91 724.68 2 L
N
3 7 Q
(entry 1:) 341.22 730.08 T
4 5 Q
(interp_fn_bytecodes_pc\050...\051) 366.19 730.08 T
3 7 Q
(entry 2:) 478.53 728.32 T
4 5 Q
(interp_fn\050...\051) 503.49 728.32 T
(if \050++count[pc]...) 361.82 705.22 T
(int stack[n],sp=0;) 360.89 711.59 T
(int stack[n],sp=0;) 469.55 712.69 T
(if \050++count[pc]...) 470.64 704.62 T
(stack[sp++] = arg;) 360.82 673.01 T
(stack[sp++] = arg;) 468.88 675.4 T
(for\050;;\051 {) 470.14 667.7 T
(switch\050byte...\051{) 470.48 661.58 T
(case ADD:...) 477.83 655.14 T
(case RETURN:) 477.33 645.26 T
(...) 484.86 651.21 T
(}) 473.83 638.78 T
(}) 469.36 633.57 T
(switch\050bytecodes[pc++]\051) 358.32 606.21 T
(case ADD:) 357.32 583.7 T
(case IF_GOTO:) 488.69 584.6 T
(case COMPUTED_GOTO:) 422.93 583.56 T
(if\050 stack[sp--]\051) 495 574.2 T
(int nextpc = ...) 494.69 580.15 T
(pc = nextpc;) 500.14 538.96 T
2 9 Q
(unit 1) 338.11 691.27 T
(unit 2) 339.45 651.51 T
(unit 3) 516.6 605.83 T
(unit 4) 516.45 524.97 T
7 5 Q
(...) 374.51 578.14 T
1 7 Q
(...) 442.93 580.2 T
1 12 Q
(...) 493.19 598.08 T
4 5 Q
(...) 519.69 645.53 T
376.34 570.63 376.34 519.96 2 L
N
446.84 571.96 378.28 522.29 2 L
N
515 573.29 375.78 521.79 2 L
N
514.66 550.06 513 544.29 511.35 550.06 513 550.06 4 Y
V
513 573.29 513 550.06 2 L
N
500.53 534.79 374.67 520.96 2 L
N
442.12 592.91 447.67 590.63 441.76 589.62 441.94 591.26 4 Y
V
378.5 598.29 441.94 591.26 2 L
N
507.34 592.61 513 590.63 507.15 589.3 507.24 590.96 4 Y
V
379 598.29 507.24 590.96 2 L
N
(pc =...) 430.78 573.79 T
417.53 553.29 435.53 559.79 R
7 X
V
0 0 0 1 0 0 0 K
3 6 Q
0 X
(P:) 417.53 555.79 T
4 5 Q
(pc) 424.69 555.79 T
0 0 0 1 0 0 0 K
399.03 687.71 444.53 691.71 R
7 X
V
0 0 0 1 0 0 0 K
3 6 Q
0 X
(P:) 399.03 687.71 T
4 5 Q
(bytecodes,pc) 406.19 687.71 T
0 0 0 1 0 0 0 K
452.03 685.21 497.53 690.71 R
7 X
V
0 0 0 1 0 0 0 K
3 6 Q
0 X
(D:) 452.03 686.71 T
4 5 Q
(bytecodes,pc) 458.36 686.71 T
0 0 0 1 0 0 0 K
465.53 552.79 479.53 560.29 R
7 X
V
0 0 0 1 0 0 0 K
3 7 Q
0 X
(lazy) 465.53 555.63 T
0 0 0 1 0 0 0 K
506.53 552.79 520.53 560.29 R
7 X
V
0 0 0 1 0 0 0 K
0 X
(lazy) 506.53 555.63 T
0 0 0 1 0 0 0 K
(discor) 391.03 643.21 T
(dant mer) 408.27 643.21 T
(ge:) 433.09 643.21 T
4 5 Q
(pc,sp) 430.53 638.21 T
J
394.48 629.5 388.5 629.04 393.33 632.6 393.91 631.05 4 Y
V
J
418.08 640 393.91 631.04 2 L
J
418.08 640 416.67 639.48 2 L
1 H
N
[3.253 5.422] 3.253 I
416.67 639.48 395.32 631.57 2 L
N
J
395.32 631.57 393.91 631.04 2 L
N
J
384.1 634.9 385.4 629.04 381.19 633.32 382.65 634.11 4 Y
V
376.56 521.76 M
 364.29 506.27 341.81 521.14 340.29 536.63 D
 337.03 569.77 317.69 630.47 362.31 639.75 D
 371.57 641.68 377.63 641.55 382.64 634.12 D
0.5 H
N
318.19 497.64 557.69 511.14 R
7 X
V
2 10 Q
0 X
(Figur) 348.12 504.44 T
(e 9: Specialization Units for Figur) 371.83 504.44 T
(e 2) 515.82 504.44 T
J
[4.268 7.113] 0 I
90 450 1.86 1.86 386.02 627.8 G
1 H
90 450 1.86 1.86 386.02 627.8 A
J
317.88 72 558 738 C
0 0 612 792 C
0 0 0 1 0 0 0 K
FMENDPAGE
%%EndPage: "12" 12
%%Page: "13" 13
612 792 0 FMBEGINPAGE
[0 0 0 1 0 0 0]
[ 0 1 1 0 1 0 0]
[ 1 0 1 0 0 1 0]
[ 1 1 0 0 0 0 1]
[ 1 0 0 0 0 1 1]
[ 0 1 0 0 1 0 1]
[ 0 0 1 0 1 1 0]
 7 FrameSetSepColors
FrameNoSep
0 0 0 1 0 0 0 K
54 26 558 44 R
7 X
0 0 0 1 0 0 0 K
V
0 0 0 1 0 0 0 K
0 0 0 1 0 0 0 K
54 72 294.12 738 R
V
1 9 Q
0 X
-0.12 (because) 54 732 P
4 F
-0.29 (pc) 84.61 732 P
1 F
-0.12 ( and) 95.41 732 P
4 F
-0.29 (sp) 112.67 732 P
1 F
-0.12 (, which have de\336nitions both inside and outside) 123.47 732 P
0.24 (the loop, are discordant at its head. A promotion of) 54 722 P
4 F
0.57 (pc) 242.35 722 P
1 F
0.24 ( is required) 253.15 722 P
1.62 (on the back edge from the) 54 712 P
4 F
3.88 (COMPUTED_GOTO) 159.67 712 P
1 F
1.62 ( case after) 229.87 712 P
4 F
3.88 (pc) 273.45 712 P
1 F
1.62 ( is) 284.25 712 P
0.3 (assigned a dynamic stack location. The successors of the dynamic) 54 702 P
1.56 (branch in the) 54 692 P
4 F
3.74 (IF_GOTO) 107.91 692 P
1 F
1.56 ( case are made) 145.71 692 P
3 F
1.56 (lazy) 206.91 692 P
1 F
1.56 ( as required by the) 221.41 692 P
0.68 (\050default\051) 54 682 P
4 F
1.64 (loop_specialize_lazy) 87.92 682 P
1 F
0.68 ( policy because the branch) 195.92 682 P
-0.3 (determines execution of dif) 54 672 P
-0.3 (ferent paths to the discordant loop head.) 151.68 672 P
2.26 (The false branch extends to the loop head so no new unit is) 54 662 P
(required, but the true branch creates the fourth unit.) 54 652 T
0.52 (The discordant loop head will include a specialization-time cache) 54 639 P
0.05 (lookup, the edges carrying promotions will correspond to run-time) 54 629 P
-0.15 (cache lookups, and the lazy edges will become one-time call-backs) 54 619 P
(to the specializer) 54 609 T
(.) 114.49 609 T
2 10 Q
(6.3) 54 592.33 T
(Clustering Unit Boundaries) 72 592.33 T
1 9 Q
1.38 (A unit boundary introduces run-time specialization overhead, to) 54 578 P
1.04 (package up the run-time constant context from the exiting unit\325) 54 568 P
1.04 (s) 290.62 568 P
4 F
5.83 (ReduceAndResidualize) 54 558 P
1 F
2.43 ( function, to execute the run-time) 162 558 P
0.61 (specializer and any cache lookups, and to invoke the tar) 54 548 P
0.61 (get unit\325) 260.26 548 P
0.61 (s) 290.62 548 P
4 F
-0.93 (ReduceAndResidualize) 54 538 P
1 F
-0.39 ( function \050unpacking the tar) 162 538 P
-0.39 (get\325) 260.26 538 P
-0.39 (s run-) 273.76 538 P
-0.18 (time context\051. In some circumstances, series of unit boundaries can) 54 528 P
0.54 (be created with little if any work in between, for instance when a) 54 518 P
-0.21 (series of annotated static variables become dead, leading to a series) 54 508 P
(of demotion points and corresponding unit boundaries.) 54 498 T
3.38 (T) 54 485 P
3.38 (o avoid excessive unit boundaries, we attempt to combine) 58.87 485 P
2.63 (multiple boundaries whenever possible. W) 54 475 P
2.63 (e have developed a) 217.52 475 P
(boundary clustering algorithm that works as follows:) 54 465 T
(\245) 61.2 453 T
2.51 (First, for each boundary) 68.4 453 P
2.51 (, we construct the range over the) 161.83 453 P
4.69 (procedure where that boundary can be moved legally) 68.4 443 P
4.69 (.) 291.87 443 P
0.12 (Discordant-mer) 68.4 433 P
0.12 (ge and lazy-edge boundaries cannot be moved,) 124.72 433 P
3.03 (so their range is a single program point. Promotion and) 68.4 423 P
3.38 (demotion boundaries can move to any control-equivalent) 68.4 413 P
0.15 ([Ferrante) 68.4 403 P
3 F
0.15 (et al.) 103.79 403 P
1 F
0.15 ( 87] program point bounded by earlier and later) 121.94 403 P
3.81 (uses of any promoted or demoted variable, except that) 68.4 393 P
1.42 (promotion points cannot move above earlier de\336nitions. W) 68.4 383 P
1.42 (e) 290.12 383 P
-0.38 (delay inserting the single-entry-producing unit boundaries until) 68.4 373 P
0.75 (after all the other boundaries have been clustered, so they do) 68.4 363 P
(not participate in the clustering algorithm.) 68.4 353 T
(\245) 61.2 341 T
-0.5 (Second, we sort the boundary ranges in increasing order of their) 68.4 341 P
0.64 (ends, and then we make a linear scan through this sorted list.) 68.4 331 P
-0.06 (W) 68.4 321 P
-0.06 (e remove the range that ends \336rst in the list, remove all other) 76.18 321 P
-0.4 (ranges that overlap with the \336rst range, and \336nd the intersection) 68.4 311 P
2.38 (of these ranges. This resulting intersection is the program) 68.4 301 P
0.38 (region where all of these boundaries can be placed. W) 68.4 291 P
0.38 (e prefer) 266.01 291 P
2.59 (earliest possible points for demotions and later points for) 68.4 281 P
1.88 (promotions, as these will reduce the amount of specialized) 68.4 271 P
-0.48 (code. W) 68.4 261 P
-0.48 (e choose either the start or end of the intersection range,) 97.19 261 P
1.08 (based on the relative mix of promotions and demotions, and) 68.4 251 P
-0.01 (insert a single boundary for all the mer) 68.4 241 P
-0.01 (ged ranges at that point.) 207.91 241 P
-0.47 (Then we continue processing the sorted list of boundary ranges,) 68.4 231 P
(until the list is exhausted.) 68.4 221 T
-0.15 (W) 54 208 P
-0.15 (e have proved that this algorithm for coalescing boundary ranges) 61.78 208 P
-0.08 (is optimal, given the restricted kinds of ranges produced in the \336rst) 54 198 P
(step \050the restriction to control-equivalent program points is key\051.) 54 188 T
0.33 (Dif) 54 175 P
0.33 (ferent kinds of boundaries incur dif) 65.83 175 P
0.33 (ferent kinds of costs. Eager) 194.56 175 P
3.38 (boundaries incur cost only at specialization time. Lazy-edge) 54 165 P
0.38 (boundaries incur cost at run-time, but only once the \336rst time that) 54 155 P
0.39 (boundary is executed, since the edge is patched to branch directly) 54 145 P
1.24 (to the specialized successor code when \336rst invoked. Promotion) 54 135 P
0.49 (boundaries require run-time cost each time they are executed. W) 54 125 P
0.49 (e) 290.12 125 P
2.13 (do not wish to cluster boundaries with dif) 54 115 P
2.13 (ferent kinds of cost) 218.49 115 P
-0.21 (together if that would increase overall expense; for example, we do) 54 105 P
-0.49 (not wish to cluster an eager cache lookup boundary with a lazy edge) 54 95 P
0.1 (to form a lazy cache lookup that would incur run-time cost at each) 54 85 P
1.84 (execution. A simple strategy is to treat each kind of boundary) 54 75 P
317.88 72 558 738 R
7 X
V
0 X
3.23 (separately in the clustering algorithm, running the clustering) 317.88 732 P
1.73 (algorithm three times, one for each class of boundary) 317.88 722 P
1.73 (. A more) 522.81 722 P
0.71 (sophisticated strategy would allow eager caching to be combined) 317.88 712 P
2.59 (with lazy caching, and lazy edges to be combined with lazy) 317.88 702 P
(caching, only avoiding mer) 317.88 692 T
(ging eager caching with lazy edges.) 416.2 692 T
2 10 Q
(6.4) 317.88 674.22 T
(Separating Static and Dynamic Operations) 335.88 674.22 T
1 9 Q
-0.41 (For most straight-line operations, it is clear whether the operation is) 317.88 658.77 P
(static or dynamic. However) 317.88 648.77 T
(, call instructions are trickier) 417 648.77 T
(.) 519.73 648.77 T
(\245) 325.08 635.65 T
4.67 (A call to a regular unspecialized function \050or to the) 332.28 635.65 P
0.39 (unspecialized version of a specialized function\051 is treated as a) 332.28 626.15 P
(dynamic operation and appears only in the dynamic subgraph.) 332.28 616.65 T
(\245) 325.08 604.04 T
-0.33 (A call to a) 332.28 604.04 P
4 F
-0.79 (constant) 370.45 604.04 P
1 F
-0.33 ( function with static ar) 413.65 604.04 P
-0.33 (guments is treated) 493.17 604.04 P
1.53 (as a regular static computation, appearing only in the static) 332.28 594.54 P
(subgraph.) 332.28 585.04 T
(\245) 325.08 572.42 T
-0.23 (A call to a particular specialized division of a function has both) 332.28 572.42 P
1.48 (static and dynamic components. T) 332.28 562.92 P
1.48 (o implement this, the call) 460.82 562.92 P
1.4 (operation is split into two separate calls, one static and one) 332.28 553.42 P
1.08 (dynamic. The static version of the call invokes the statically) 332.28 543.92 P
0.47 (compiled generating extension for the selected division of the) 332.28 534.42 P
-0.14 (callee, taking as ar) 332.28 524.92 P
-0.14 (guments the static ar) 398.66 524.92 P
-0.14 (guments \050as determined) 472.3 524.92 P
0.45 (by the division of the callee\051, and returning a static procedure) 332.28 515.42 P
0.1 (address. This is followed by a dynamic call invoking the static) 332.28 505.92 P
2.17 (procedure address and passing the remaining ar) 332.28 496.42 P
2.17 (guments to) 516.08 496.42 P
0.01 (produce a dynamic result.) 332.28 486.92 P
1 7.2 Q
0.01 (*) 425.3 490.52 P
1 9 Q
0.01 ( The static call will be moved to the) 428.9 486.92 P
3.03 (static subgraph, and the dynamic call will appear in the) 332.28 477.42 P
(dynamic subgraph.) 332.28 467.92 T
1.87 (Control-\337ow nodes including branches and mer) 317.88 454.31 P
1.87 (ges initially are) 498.77 454.31 P
2.07 (replicated in both the static and the dynamic subgraphs. Later) 317.88 444.31 P
(transformations will address them.) 317.88 434.31 T
2 10 Q
(6.5) 317.88 416.52 T
(Linearization within Units) 335.88 416.52 T
1 9 Q
-0.1 (Once each unit has been identi\336ed and split into separate static and) 317.88 401.08 P
0.67 (dynamic control-\337ow subgraphs, the control-\337ow structure of the) 317.88 391.08 P
1.6 (unit\325) 317.88 381.08 P
1.6 (s) 334.39 381.08 P
4 F
3.85 (ReduceAndResidualize) 341.74 381.08 P
1 F
1.6 ( is computed from the static) 449.74 381.08 P
-0.07 (subgraph. Static and dynamic branches in the unit receive dif) 317.88 371.08 P
-0.07 (ferent) 537.01 371.08 P
0.22 (treatment. A static branch is taken at specialization time, and does) 317.88 361.08 P
0.19 (not appear in the dynamically generated \050residual\051 code; similarly) 317.88 351.08 P
0.19 (,) 555.75 351.08 P
0.99 (only one of its successors produces dynamically generated code.) 317.88 341.08 P
-0.42 (Consequently a static branch appears as a regular branch in the \336nal) 317.88 331.08 P
4 F
11.03 (ReduceAndResidualize) 317.88 321.08 P
1 F
4.59 ( function, selecting some single) 425.88 321.08 P
-0.48 (successor to pursue and residualize. A dynamic branch, on the other) 317.88 311.08 P
-0.11 (hand, is emitted as a regular branch into the dynamically generated) 317.88 301.08 P
0.56 (code, and both its successors must be residualized. Consequently) 317.88 291.08 P
0.56 (,) 555.75 291.08 P
0.13 (no branch appears in the) 317.88 281.08 P
4 F
0.31 (ReduceAndResidualize) 408.75 281.08 P
1 F
0.13 ( function at) 516.75 281.08 P
0.89 (a dynamic branch, and the successors of the dynamic branch are) 317.88 271.08 P
3.02 (linearized instead. The following diagram illustrates how the) 317.88 261.08 P
(dynamic branches are linearized:) 317.88 251.08 T
317.88 128 558 142.98 C
0 0 0 1 0 0 0 K
0 0 0 1 0 0 0 K
317.88 128 558 142.98 R
7 X
0 0 0 1 0 0 0 K
V
317.88 133.91 470.88 133.91 2 L
V
0.5 H
2 Z
0 X
N
0 0 612 792 C
1 6.4 Q
0 X
0 0 0 1 0 0 0 K
(*) 317.88 125.87 T
1 8 Q
1.42 (Some other systems, such as Tempo, perform interprocedural binding) 323.56 122.67 P
-0.44 (time analysis and so can deduce that the result of the a specialized function) 323.56 113.67 P
1.68 (is static. If we were to extend our system to support interprocedural) 323.56 104.67 P
-0.05 (analysis of annotations, then the static half of the call would return both a) 323.56 95.67 P
-0.02 (procedure address and the static result value, and the dynamic half would) 323.56 86.67 P
(return no result and be invoked only for its side-effects.) 323.56 77.67 T
317.88 72 558 738 C
317.88 142.98 558 248.08 C
0 0 0 1 0 0 0 K
J
0 0 0 1 0 0 0 K
317.69 142.98 558.19 248.08 R
7 X
0 0 0 1 0 0 0 K
V
J
358.44 222.88 376.44 231.88 R
V
0.5 H
2 Z
0 X
N
371.94 204.88 389.94 213.88 R
7 X
V
0 X
N
344.94 204.88 362.94 213.88 R
7 X
V
0 X
N
382.94 187.13 396.44 196.13 R
7 X
V
0 X
N
365.94 186.88 379.44 195.88 R
7 X
V
0 X
N
359.44 164.38 377.44 173.38 R
7 X
V
0 X
N
358.79 215.1 353.94 213.88 356.86 217.93 357.01 215.96 4 Y
V
367.19 222.88 357.01 215.96 2 L
N
377.95 217.88 380.94 213.88 376.07 215.02 377.83 215.91 4 Y
V
367.19 222.88 377.83 215.91 2 L
N
367.26 178.29 368.19 173.38 364.32 176.54 366.29 176.57 4 Y
V
349.44 204.88 366.29 176.57 2 L
N
377.12 198.19 372.69 195.88 374.6 200.5 375.2 198.61 4 Y
V
380.94 204.88 375.2 198.61 2 L
N
387.58 200.66 389.69 196.13 385.16 198.24 387.07 198.75 4 Y
V
380.94 204.88 387.07 198.75 2 L
N
371.41 177.4 368.44 173.38 368.13 178.37 369.49 176.94 4 Y
V
372.44 186.88 369.49 176.94 2 L
N
373.56 174.5 368.69 173.38 371.7 177.37 371.8 175.4 4 Y
V
389.94 187.13 371.81 175.39 2 L
N
369.15 236.33 367.44 231.63 365.73 236.33 367.44 235.34 4 Y
V
367.44 245.13 367.44 235.34 2 L
N
366.4 155.58 364.69 150.88 362.98 155.58 364.69 154.59 4 Y
V
364.69 164.38 364.69 154.59 2 L
N
496.19 223.5 514.19 232.5 R
7 X
V
0 X
N
509.69 205.5 527.69 214.5 R
7 X
V
0 X
N
482.69 205.5 500.69 214.5 R
7 X
V
0 X
N
491.69 151.5 509.69 160.5 R
7 X
V
0 X
N
512.44 169.5 525.94 178.5 R
7 X
V
0 X
N
512.44 187.5 525.94 196.5 R
7 X
V
0 X
N
506.9 237.2 505.19 232.5 503.48 237.2 505.19 236.21 4 Y
V
505.19 246 505.19 236.21 2 L
N
496.54 215.69 491.69 214.5 494.65 218.53 494.77 216.56 4 Y
V
505.19 223.5 494.78 216.56 2 L
N
515.72 218.53 518.69 214.5 513.83 215.69 515.6 216.56 4 Y
V
505.19 223.5 515.6 216.56 2 L
N
501.44 165.45 500.69 160.51 498.09 164.78 499.96 164.14 4 Y
V
491.69 205.5 499.96 164.14 2 L
N
521.15 200.7 519.44 196 517.73 200.7 519.44 199.71 4 Y
V
519.44 205.5 519.44 199.71 2 L
N
521.15 183.2 519.44 178.5 517.73 183.2 519.44 182.21 4 Y
V
519.44 187.5 519.44 182.21 2 L
N
505.65 161.08 500.69 160.5 504.12 164.14 504.01 162.16 4 Y
V
518.69 169.5 504.01 162.16 2 L
N
502.4 147.2 500.69 142.5 498.98 147.2 500.69 146.21 4 Y
V
500.69 151.5 500.69 146.21 2 L
N
452.39 196.02 469.69 191.05 452.39 186.09 452.39 191.05 4 Y
V
412.69 191.05 452.39 191.05 2 L
2 H
N
0 0 0 1 0 0 0 K
0 0 0 1 0 0 0 K
360.19 225.75 366.19 230.25 R
7 X
V
0 0 0 1 0 0 0 K
1 7 Q
0 X
(1) 360.19 225.59 T
0 0 0 1 0 0 0 K
346.69 207.75 352.69 212.25 R
7 X
V
0 0 0 1 0 0 0 K
0 X
(2) 346.69 207.59 T
0 0 0 1 0 0 0 K
373.69 207.75 379.69 212.25 R
7 X
V
0 0 0 1 0 0 0 K
0 X
(3) 373.69 207.59 T
0 0 0 1 0 0 0 K
368.19 189.75 374.19 194.25 R
7 X
V
0 0 0 1 0 0 0 K
0 X
(4) 368.19 189.59 T
0 0 0 1 0 0 0 K
361.19 167.25 367.19 171.75 R
7 X
V
0 0 0 1 0 0 0 K
0 X
(6) 361.19 167.09 T
0 0 0 1 0 0 0 K
385.19 190.25 391.19 194.75 R
7 X
V
0 0 0 1 0 0 0 K
0 X
(5) 385.19 190.09 T
0 0 0 1 0 0 0 K
497.69 226.75 503.69 231.25 R
7 X
V
0 0 0 1 0 0 0 K
0 X
(1) 497.69 226.59 T
0 0 0 1 0 0 0 K
511.69 208.25 517.69 212.75 R
7 X
V
0 0 0 1 0 0 0 K
0 X
(3) 511.69 208.09 T
0 0 0 1 0 0 0 K
484.69 208.25 490.69 212.75 R
7 X
V
0 0 0 1 0 0 0 K
0 X
(2) 484.69 208.09 T
0 0 0 1 0 0 0 K
514.69 190.25 520.69 194.75 R
7 X
V
0 0 0 1 0 0 0 K
0 X
(4) 514.69 190.09 T
0 0 0 1 0 0 0 K
514.69 172.25 520.69 176.75 R
7 X
V
0 0 0 1 0 0 0 K
0 X
(5) 514.69 172.09 T
0 0 0 1 0 0 0 K
493.69 153.75 499.69 158.25 R
7 X
V
0 0 0 1 0 0 0 K
0 X
(6) 493.69 153.59 T
0 0 0 1 0 0 0 K
7 X
90 450 3.5 3.5 366.94 222.75 G
0.5 H
0 X
90 450 3.5 3.5 366.94 222.75 A
0 0 0 1 0 0 0 K
(s) 365.69 221.34 T
0 0 0 1 0 0 0 K
7 X
90 450 3.5 3.5 504.94 222.75 G
0 X
90 450 3.5 3.5 504.94 222.75 A
0 0 0 1 0 0 0 K
(s) 503.69 221.34 T
0 0 0 1 0 0 0 K
7 X
90 450 3.5 3.5 380.69 204.75 G
0 X
90 450 3.5 3.5 380.69 204.75 A
0 0 0 1 0 0 0 K
(d) 379.19 202.84 T
0 0 0 1 0 0 0 K
317.88 72 558 738 C
0 0 612 792 C
J
0 0 0 1 0 0 0 K
J
FMENDPAGE
%%EndPage: "13" 13
%%Page: "14" 14
612 792 0 FMBEGINPAGE
[0 0 0 1 0 0 0]
[ 0 1 1 0 1 0 0]
[ 1 0 1 0 0 1 0]
[ 1 1 0 0 0 0 1]
[ 1 0 0 0 0 1 1]
[ 0 1 0 0 1 0 1]
[ 0 0 1 0 1 1 0]
 7 FrameSetSepColors
FrameNoSep
0 0 0 1 0 0 0 K
54 26 558 44 R
7 X
0 0 0 1 0 0 0 K
V
0 0 0 1 0 0 0 K
0 0 0 1 0 0 0 K
54 72 294.12 738 R
V
1 9 Q
0 X
1.66 (In the presence of arbitrary unstructured control \337ow of mixed) 54 732 P
-0.14 (static and dynamic branches, this linearization process may require) 54 722 P
1.94 (some code duplication to avoid maintaining specialization-time) 54 712 P
-0.14 (data structures and overhead. Details of our linearization algorithm) 54 702 P
-0.07 (are available in an expanded version of this paper [Grant) 54 692 P
3 F
-0.07 (et al.) 259.76 692 P
1 F
-0.07 ( 97].) 277.69 692 P
2 10 Q
(6.6) 54 673.7 T
(Integrating Dynamic Code into Static Code) 72 673.7 T
1 9 Q
-0.34 (T) 54 657.73 P
-0.34 (o produce the \336nal code for a unit\325) 58.87 657.73 P
-0.34 (s) 180.71 657.73 P
4 F
-0.82 (ReduceAndResidualize) 186.12 657.73 P
1 F
1.49 (function, we take the linearized static control-\337ow graph which) 54 647.73 P
-0.51 (computes all the static expressions and blend in code to generate the) 54 637.73 P
3.36 (dynamic calculations with the appropriate run-time constants) 54 627.73 P
1.56 (embedded in them. T) 54 617.73 P
1.56 (o accomplish this, our system maintains a) 134.53 617.73 P
-0.11 (mapping from each basic block in the dynamic subgraph to a set of) 54 607.73 P
0.67 (corresponding basic blocks in the static subgraph. When splitting) 54 597.73 P
0.96 (apart static and dynamic operations, the mapping is created with) 54 587.73 P
0.85 (each dynamic block mapping to its single static counterpart. The) 54 577.73 P
0.76 (mapping is updated as the static subgraph is linearized and some) 54 567.73 P
0.52 (blocks are replicated, and as the subgraphs are optimized through) 54 557.73 P
1.41 (instruction scheduling. T) 54 547.73 P
1.41 (o integrate the two subgraphs, for each) 145.94 547.73 P
-0.54 (dynamic block, code is appended to each corresponding static block) 54 537.73 P
0.38 (to emit the instructions of the dynamic block, after the static code) 54 527.73 P
3.96 (has computed any run-time constants used in the dynamic) 54 517.73 P
(instructions.) 54 507.73 T
0.54 (The code to emit a dynamic instruction embeds the values of any) 54 493.09 P
-0.1 (run-time constant operands into the generated instruction \050either as) 54 483.09 P
0.05 (a short integer immediate \336eld or as a load from a global table to a) 54 473.09 P
2.51 (scratch register for lar) 54 463.09 P
2.51 (ge integers, \337oating-point numbers, and) 140.59 463.09 P
5.24 (pointers\051. The emitting code also performs any peephole) 54 453.09 P
1.21 (optimizations of the generated instruction based on the run-time) 54 443.09 P
0.05 (constant value, such as replacing multiplications by constants with) 54 433.09 P
(sequences of shifts and adds.) 54 423.09 T
2 10 Q
(6.7) 54 404.79 T
(Optimizing Specializer Interactions) 72 404.79 T
1 9 Q
4.2 (Each initial promotion point entering a dynamic region is) 54 388.82 P
0.06 (implemented by generating a static call to the run-time specializer) 54 378.82 P
0.06 (,) 291.87 378.82 P
0.97 (passing the run-time values of the cache context at that program) 54 368.82 P
1.19 (point. Section 3 described the run-time specializer as if a single) 54 358.82 P
0.88 (general-purpose specializer took control at this and all other unit) 54 348.82 P
3.16 (boundaries. Our system optimizes this pedagogical model as) 54 338.82 P
(follows:) 54 328.82 T
(\245) 61.2 315.18 T
2.49 (The) 68.4 315.18 P
4 F
5.97 (Specialize) 87.13 315.18 P
1 F
2.49 ( function is specialized for each) 141.13 315.18 P
4 F
5.97 (Unit) 272.52 315.18 P
1 F
1.76 (ar) 68.4 305.18 P
1.76 (gument. All the run-time manipulations of the) 75.23 305.18 P
4 F
4.22 (Unit) 255.52 305.18 P
1 F
1.76 ( and) 277.12 305.18 P
4 F
14.72 (UnitEdge) 68.4 295.18 P
1 F
6.13 ( data structures are eliminated, the unit\325) 111.6 295.18 P
6.13 (s) 290.62 295.18 P
4 F
9.23 (ReduceAndResidualize) 68.4 285.18 P
1 F
3.85 ( function is inlined, and the) 176.4 285.18 P
0.5 (processing of outgoing lazy unit edges is inlined. If the cache) 68.4 275.18 P
7.28 (policy for any of the unit\325) 68.4 265.18 P
7.28 (s context variables is) 197.04 265.18 P
0 F
1.23 (CacheAllUnchecked) 68.4 255.18 P
1 F
1.1 (, then the cache lookup and store calls) 149.43 255.18 P
(are omitted.) 68.4 245.18 T
(\245) 61.2 231.55 T
2.28 (Calls to the) 68.4 231.55 P
4 F
5.48 (Specialize) 118.5 231.55 P
1 F
2.28 ( function corresponding to lazy) 172.5 231.55 P
2.34 (edges with no change in cache context or promotions are) 68.4 221.55 P
-0.41 (dynamically overwritten to be direct jumps \050or fall-throughs\051 to) 68.4 211.55 P
(the dynamically generated code for the tar) 68.4 201.55 T
(get unit.) 220.19 201.55 T
(\245) 61.2 187.91 T
0.78 (Demotions corresponding to the ends of dynamic regions are) 68.4 187.91 P
(compiled into direct jumps to statically compiled code.) 68.4 177.91 T
2 12 Q
(7) 54 155.27 T
(Comparison T) 72 155.27 T
(o Related W) 145.24 155.27 T
(ork) 207.9 155.27 T
1 9 Q
4.32 (T) 54 138.64 P
4.32 (empo [Consel & No\221l 96], a compile-time and run-time) 58.87 138.64 P
-0.01 (specialization system for C, is most similar to our system. The two) 54 128.64 P
(dif) 54 118.64 T
(fer chie\337y in the following ways:) 63.84 118.64 T
(\245) 61.2 105 T
-0.29 (Our system may produce multiple divisions and specializations) 68.4 105 P
5.62 (of program points, with the degree of division and) 68.4 95 P
-0.55 (specialization varying from point to point. T) 68.4 85 P
-0.55 (empo supports only) 224.22 85 P
0.33 (function-level polyvariant division and specialization, with no) 68.4 75 P
317.88 72 558 738 R
7 X
V
0 X
4.45 (additional division or specialization possible within the) 332.28 732 P
(function, except for some limited support for loop unrolling.) 332.28 722 T
(\245) 325.08 709.7 T
4.1 (Our system performs analysis over arbitrary) 332.28 709.7 P
4.1 (, potentially) 510.9 709.7 P
-0.14 (unstructured control-\337ow graphs. T) 332.28 699.7 P
-0.14 (empo converts all instances) 459.2 699.7 P
0.31 (of unstructured code to structured form [Erosa & Hendren 94,) 332.28 689.7 P
-0.23 (Consel) 332.28 679.7 P
3 F
-0.23 (et al.) 359.31 679.7 P
1 F
-0.23 ( 96], which introduces a number of additional tests) 377.08 679.7 P
(and may also introduce loops.) 332.28 669.7 T
(\245) 325.08 657.4 T
3.12 (Our system allows dynamic-to-static promotions to occur) 332.28 657.4 P
3.61 (within dynamically compiled code. T) 332.28 647.4 P
3.61 (empo requires such) 480.81 647.4 P
(promotions to occur only at the entry point.) 332.28 637.4 T
(\245) 325.08 625.1 T
2.72 (Our system allows the programmer to specify policies to) 332.28 625.1 P
4.45 (control division, specialization, caching, and speculative) 332.28 615.1 P
-0.23 (specialization. T) 332.28 605.1 P
-0.23 (empo does not provide user controls; the client) 390.91 605.1 P
0.72 (program must perform its own caching of specialized code if) 332.28 595.1 P
(desired.) 332.28 585.1 T
(\245) 325.08 572.8 T
2.16 (Our system relies on the programmer to annotate memory) 332.28 572.8 P
1.39 (references as static. T) 332.28 562.8 P
1.39 (empo performs an automatic alias and) 413.8 562.8 P
0.13 (side-ef) 332.28 552.8 P
0.13 (fect analysis to identify \050partially\051 static data structures.) 356.61 552.8 P
1.52 (T) 332.28 542.8 P
1.52 (empo\325) 337.15 542.8 P
1.52 (s approach is more convenient for programmers and) 359.65 542.8 P
0.06 (less error) 332.28 532.8 P
0.06 (-prone, but it still is not completely safe, relies on the) 365.4 532.8 P
1.96 (programmer to correctly describe aliasing relationships and) 332.28 522.8 P
-0.36 (side-ef) 332.28 512.8 P
-0.36 (fects of parts of the program outside of the module being) 356.61 512.8 P
1.97 (specialized, and may bene\336t from explicit user annotations) 332.28 502.8 P
(wherever the analysis is overly conservative.) 332.28 492.8 T
(\245) 325.08 480.5 T
-0.34 (Our system supports separate compilation while still being able) 332.28 480.5 P
-0.07 (to specialize call sites and callee functions. T) 332.28 470.5 P
-0.07 (empo requires the) 493.65 470.5 P
-0.55 (whole module being specialized to be analyzed and compiled as) 332.28 460.5 P
(a unit.) 332.28 450.5 T
(\245) 325.08 438.2 T
4.87 (Our system is currently under construction; T) 332.28 438.2 P
4.87 (empo is) 524.88 438.2 P
(implemented and usable.) 332.28 428.2 T
0.65 (Fabius [Leone & Lee 95] is another dynamic compilation system) 317.88 414.9 P
-0.11 (based on partial evaluation. Fabius is more limited than our system) 317.88 404.9 P
-0.04 (or T) 317.88 394.9 P
-0.04 (empo, working in the context of a \336rst-order) 332.46 394.9 P
-0.04 (, purely functional) 491.83 394.9 P
0.49 (subset of ML and exploiting a syntactic form of currying to drive) 317.88 384.9 P
4.07 (dynamic compilation. Only polyvariant specialization at the) 317.88 374.9 P
1.35 (granularity of functions is supported. Given the hints of curried) 317.88 364.9 P
2.81 (function invocation, Fabius performs all dynamic compilation) 317.88 354.9 P
0.19 (optimizations automatically with no additional annotations; by the) 317.88 344.9 P
1.51 (same token, the trade-of) 317.88 334.9 P
1.51 (fs involved in the dynamic compilation) 409.22 334.9 P
-0.09 (process are not user) 317.88 324.9 P
-0.09 (-controllable. Fabius does little cross-dynamic-) 388.64 324.9 P
0.34 (statement optimization other than register allocation, since, unlike) 317.88 314.9 P
1.57 (our system, it does not explicitly construct an explicit dynamic) 317.88 304.9 P
(subgraph that can then be optimized.) 317.88 294.9 T
-0.23 (Compared to our previous system [Auslander) 317.88 281.6 P
3 F
-0.23 (et al.) 482.45 281.6 P
1 F
-0.23 ( 96], our current) 500.22 281.6 P
1.49 (system has a more \337exible and expressive annotation language,) 317.88 271.6 P
0.33 (support for polyvariant division and better support for polyvariant) 317.88 261.6 P
-0.51 (specialization, support for nested and overlapping dynamic regions,) 317.88 251.6 P
4.07 (support for demand-driven \050lazy\051 specialization, support for) 317.88 241.6 P
0.98 (interprocedural specialization, a much more ef) 317.88 231.6 P
0.98 (\336cient strategy for) 490.06 231.6 P
1.99 (and optimizations of run-time specialization, and a more well-) 317.88 221.6 P
(developed approach to caching of specialized code.) 317.88 211.6 T
-0.01 (Outside the realm of dynamic compilation, other partial evaluation) 317.88 198.3 P
0.13 (systems share characteristics with our system. In particular) 317.88 188.3 P
0.13 (, C-mix) 530.37 188.3 P
1.33 (is a partial-evaluation system for C that provides program-point) 317.88 178.3 P
3.4 (polyvariant specialization [Andersen 92], but not polyvariant) 317.88 168.3 P
2.89 (division. C-mix copes directly with unstructured code, but it) 317.88 158.3 P
2.66 (appears to lack reachability analysis to identify static mer) 317.88 148.3 P
2.66 (ges) 546 148.3 P
4.59 ([Andersen 94]. C-mix also includes support for automatic) 317.88 138.3 P
0.19 (interprocedural call graph, alias, and side-ef) 317.88 128.3 P
0.19 (fect analysis, although) 476.88 128.3 P
(partially static data structures are not supported.) 317.88 118.3 T
3.95 (Schism\325) 317.88 105 P
3.95 (s \336lters permit choices about whether to unfold or) 346.89 105 P
1.32 (residualize a function and which ar) 317.88 95 P
1.32 (guments to generalize, given) 450.55 95 P
0.74 (binding times for the function\325) 317.88 85 P
0.74 (s parameters [Consel 93]. Because) 430.83 85 P
-0.2 (\336lters are executed by the binding-time analysis, only binding-time) 317.88 75 P
0 0 0 1 0 0 0 K
FMENDPAGE
%%EndPage: "14" 14
%%Page: "15" 15
612 792 0 FMBEGINPAGE
[0 0 0 1 0 0 0]
[ 0 1 1 0 1 0 0]
[ 1 0 1 0 0 1 0]
[ 1 1 0 0 0 0 1]
[ 1 0 0 0 0 1 1]
[ 0 1 0 0 1 0 1]
[ 0 0 1 0 1 1 0]
 7 FrameSetSepColors
FrameNoSep
0 0 0 1 0 0 0 K
54 26 558 44 R
7 X
0 0 0 1 0 0 0 K
V
0 0 0 1 0 0 0 K
0 0 0 1 0 0 0 K
54 72 294.12 738 R
V
1 9 Q
0 X
4.36 (information can be used to make decisions. Our system\325) 54 732 P
4.36 (s) 290.62 732 P
0.66 (conditional specialization can use the results of arbitrary static or) 54 722 P
6.49 (dynamic expressions to control all aspects of run-time) 54 712 P
3.8 (specialization. Filters can be used, for example, to prevent) 54 702 P
0.43 (unbounded unfolding and unbounded specialization. Both of) 54 692 P
0.43 (f-line) 274.63 692 P
-0.2 (partial evaluators, such as Schism, and on-line specializers, such as) 54 682 P
-0.55 (Fuse [W) 54 672 P
-0.55 (eise) 83.47 672 P
3 F
-0.55 (et al.) 99.16 672 P
1 F
-0.55 ( 91], look for dynamic conditionals as a signal that) 116.61 672 P
6.94 (unbounded unfolding or specialization could occur and) 54 662 P
1.52 (specialization should be stopped. Run-time specializers have an) 54 652 P
1.09 (additional option, which is to temporarily suspend specialization) 54 642 P
-0.07 (when dynamic conditionals are found in potential cycles and insert) 54 632 P
(lazy callbacks to the specializer) 54 622 T
(, as our system does.) 167.61 622 T
3.43 (`C extends the ANSI C language to support dynamic code) 54 607.75 P
2.49 (generation in an imperative rather than annotation-based style) 54 597.75 P
2.62 ([Engler) 54 587.75 P
3 F
2.62 (et al.) 85.86 587.75 P
1 F
2.62 ( 96]. The programmer must specify code to be) 106.47 587.75 P
-0.15 (generated at run time, substitute run-time values and combine code) 54 577.75 P
0.11 (fragments \050called tick expressions\051, perform optimizations, invoke) 54 567.75 P
4.51 (the run-time compiler) 54 557.75 P
4.51 (, manage code reuse and code-space) 141.14 557.75 P
-0.41 (reclamation, and ensure correctness. In return for this programming) 54 547.75 P
2.26 (burden, `C would seem to of) 54 537.75 P
2.26 (fer greater expressiveness than a) 168.12 537.75 P
4.1 (declarative, annotation-based system. However) 54 527.75 P
4.1 (, our system\325) 236.16 527.75 P
4.1 (s) 290.62 527.75 P
-0.54 (ability to perform arbitrary and conditional polyvariant division and) 54 517.75 P
-0.51 (specialization enables it perform a wide range of optimizations with) 54 507.75 P
0.37 (very little user intervention, and our system of) 54 497.75 P
0.37 (fers capabilities not) 222.9 497.75 P
0.88 (available in `C. For instance, `C cannot \050multi-way\051 unroll loops) 54 487.75 P
2.36 (with dynamic exit tests because jumps to labels in other tick) 54 477.75 P
0.74 (expressions are not permitted. \050`C recently added limited support) 54 467.75 P
1.08 (for automatic single-way loop unrolling within a tick expression) 54 457.75 P
-0.11 ([Poletto) 54 447.75 P
3 F
-0.11 (et al.) 84.64 447.75 P
1 F
-0.11 ( 97].\051 Also, tick expressions cannot contain other tick) 102.53 447.75 P
3.02 (expressions, so nested \050not to mention overlapping\051 dynamic) 54 437.75 P
2.18 (regions cannot be supported. Both of these weaknesses would) 54 427.75 P
0.1 (appear to prevent `C from handling the simple interpreter example) 54 417.75 P
1.39 (in Figure 1. `C can support run-time compiled functions with a) 54 407.75 P
2.76 (dynamically determined number of ar) 54 397.75 P
2.76 (guments, but it may be) 200.84 397.75 P
0.3 (feasible to achieve at least some of this behavior in our system by) 54 387.75 P
2.02 (specializing a procedure based on the length and values in its) 54 377.75 P
4 F
(varargs) 54 367.75 T
1 F
( pseudo-ar) 91.8 367.75 T
(gument.) 129.38 367.75 T
0.1 (A declarative system such as ours allows better static optimization) 54 353.5 P
-0.21 (of dynamic code than an imperative system such as `C, because the) 54 343.5 P
-0.38 (control \337ow within a dynamic region is more easily determined and) 54 333.5 P
2.23 (conveyed to the rest of the optimizing compiler) 54 323.5 P
2.23 (. Optimization) 239.88 323.5 P
0.83 (across tick expressions is as hard as interprocedural optimization) 54 313.5 P
0.21 (across calls through unknown function pointers [Poletto) 54 303.5 P
3 F
0.21 (et al.) 259.2 303.5 P
1 F
0.21 ( 97].) 277.41 303.5 P
1.03 (Finally) 54 293.5 P
1.03 (, programs written in declarative systems can be easier to) 78.92 293.5 P
1.17 (debug: since \050most of\051 the annotations are semantics-preserving,) 54 283.5 P
0.92 (programs can simply be compiled ignoring them. Debugging the) 54 273.5 P
(use of unsafe annotations is still challenging, however) 54 263.5 T
(.) 248.48 263.5 T
2 12 Q
(8) 54 241.25 T
(Conclusions) 72 241.25 T
1 9 Q
2.52 (W) 54 225 P
2.52 (e have designed an annotation-based system for performing) 61.78 225 P
-0.11 (dynamic compilation that couples a \337exible and systematic partial-) 54 215 P
3.53 (evaluation-based model of program transformation with user) 54 205 P
0.93 (control of key policy decisions. Our annotations\325 design resulted) 54 195 P
1.58 (from a search for a small set of \337exible primitive directives to) 54 185 P
2.61 (govern dynamic compilation, suitable for use by both human) 54 175 P
3.63 (programmers and tools \050such as a semi-automatic dynamic-) 54 165 P
-0.37 (compilation front end\051. W) 54 155 P
-0.37 (ith the exception of support for static data) 146.51 155 P
-0.46 (structures, we believe that our) 54 145 P
4 F
-1.11 (make_static) 162.15 145 P
1 F
-0.46 ( annotation provides) 221.55 145 P
0.56 (the \337exibility we require in a concise, elegant manner) 54 135 P
0.56 (. By adding) 251.24 135 P
2.02 (policy annotations, users can gain \336ne control over the partial) 54 125 P
4.31 (evaluation process when needed. Our support for arbitrary) 54 115 P
0.28 (program-point-speci\336c polyvariant division and specialization is a) 54 105 P
0.81 (key component of our system\325) 54 95 P
0.81 (s \337exibility) 166.23 95 P
0.81 (, enabling, for instance,) 207.21 95 P
5.02 (multi-way loop unrolling and conditional specialization as) 54 85 P
2.77 (illustrated in the interpreter example. W) 54 75 P
2.77 (e exploit the unusual) 211.08 75 P
317.88 72 558 738 R
7 X
V
0 X
0.05 (capabilities of run-time specialization in the forms of arbitrary and) 317.88 732 P
8.41 (nestable dynamic-to-static promotion and demand-driven) 317.88 722 P
(specialization.) 317.88 712 T
0.08 (W) 317.88 698.59 P
0.08 (e are currently in the process of implementing this design, in the) 325.66 698.59 P
2.82 (context of the Multi\337ow compiler [Lowney) 317.88 688.59 P
3 F
2.82 (et al.) 493.8 688.59 P
1 F
2.82 ( 93]. Once) 514.62 688.59 P
3.49 (complete, we plan to focus on gaining experience applying) 317.88 678.59 P
1.66 (dynamic compilation to sizeable, real application programs and) 317.88 668.59 P
0.17 (extending our system to provide some form of automatic alias and) 317.88 658.59 P
2.82 (side-ef) 317.88 648.59 P
2.82 (fect analysis, interprocedural binding-time analysis, and) 342.21 648.59 P
(additional run-time optimizations.) 317.88 638.59 T
2 10 Q
(Acknowledgments) 317.88 621.52 T
1 9 Q
2.07 (W) 317.88 606.78 P
2.07 (e are grateful to the anonymous PEPM\32597 referees for their) 325.66 606.78 P
0.89 (suggestions for refocusing this paper) 317.88 596.78 P
0.89 (, and Charles Consel for his) 453.56 596.78 P
1.58 (help in understanding T) 317.88 586.78 P
1.58 (empo and some of the related issues in) 407.73 586.78 P
1.6 (partial evaluation. W) 317.88 576.78 P
1.6 (e also thank David Grove for feedback on) 396.1 576.78 P
0.39 (earlier drafts of this paper) 317.88 566.78 P
0.39 (, Charles Garrett for his implementation) 412.06 566.78 P
2.38 (work on our dynamic compiler) 317.88 556.78 P
2.38 (, John O\325Donnell and T) 438.54 556.78 P
2.38 (ryggve) 533.01 556.78 P
-0.01 (Fossum for the source for the Alpha AXP version of the Multi\337ow) 317.88 546.78 P
0.94 (compiler) 317.88 536.78 P
0.94 (, and Ben Cutler) 349.52 536.78 P
0.94 (, Michael Adler) 410.95 536.78 P
0.94 (, and Geof) 469.2 536.78 P
0.94 (f Lowney for) 508.65 536.78 P
1.59 (technical advice in altering it. This work is supported by ONR) 317.88 526.78 P
1.71 (contract N00014-96-1-0402, ARP) 317.88 516.78 P
1.71 (A contract N00014-94-1-1) 443.2 516.78 P
1.71 (136,) 542.25 516.78 P
3.55 (NSF Y) 317.88 506.78 P
3.55 (oung Investigator A) 345.79 506.78 P
3.55 (ward CCR-9457767, and an NSF) 424.05 506.78 P
(Graduate Research Fellowship.) 317.88 496.78 T
2 10 Q
(Refer) 317.88 479.71 T
(ences) 341.57 479.71 T
1 8 Q
0.56 ([Andersen 92]) 317.88 466.64 P
0.56 (L.O. Andersen. Self-Applicable C Program Specialization.) 366.99 466.64 P
(pages 54\32061, June 1992.) 335.88 458.14 T
-0.18 ([Andersen 94]) 317.88 447.23 P
-0.18 (L.O. Andersen.) 365.5 447.23 P
3 F
-0.18 (Program Analysis and Specialization for the) 416.46 447.23 P
-0.2 (C Programming Language) 335.88 438.73 P
1 F
-0.2 (. PhD thesis, 1994. DIKU Research Report) 421.69 438.73 P
(94/19.) 335.88 430.23 T
0.65 ([Auslander) 317.88 419.32 P
3 F
0.65 (et al.) 356.08 419.32 P
1 F
0.65 ( 96]) 372.73 419.32 P
0.65 (J.) 388.71 419.32 P
0.65 (Auslander, M.) 395.82 419.32 P
0.65 (Philipose, C.) 444.47 419.32 P
0.65 (Chambers, S.) 488.24 419.32 P
0.65 (Eggers,) 533.78 419.32 P
-0.14 (and B.) 335.88 410.82 P
-0.14 (Bershad. Fast, Effective Dynamic Compilation.) 358.63 410.82 P
3 F
-0.14 (SIGPLAN No-) 512.14 410.82 P
0.86 (tices) 335.88 402.32 P
1 F
0.86 (, pages 149\320159, May 1996. In Proceedings of the ACM SIG-) 350.54 402.32 P
3.13 (PLAN \32596 Conference on Programming Language Design and) 335.88 393.82 P
(Implementation.) 335.88 385.32 T
0.34 ([Consel & No\221l 96]) 317.88 374.42 P
0.34 (C.) 384.56 374.42 P
0.34 (Consel and F.) 393.89 374.42 P
0.34 (No\221l. A General Approach for Run-) 440.79 374.42 P
-0.34 (Time Specialization and its Application to C. In) 335.88 365.92 P
3 F
-0.34 (Conference Record of) 488.48 365.92 P
0.53 (POPL \32596: 23rd ACM SIGPLAN-SIGACT Symposium on Principles) 335.88 357.42 P
0.24 (of Programming Languages) 335.88 348.92 P
1 F
0.24 (, pages 145\320156, St. Petersburg, Florida,) 426.58 348.92 P
(January 1996.) 335.88 340.42 T
0.09 ([Consel 93]) 317.88 329.51 P
0.09 (C.) 357.62 329.51 P
0.09 (Consel. A Tour of Schism: A Partial Evaluation System for) 366.95 329.51 P
(Higher-Order Applicative Languages. pages 145\320154, 1993.) 335.88 321.01 T
-0.35 ([Consel) 317.88 310.1 P
3 F
-0.35 (et al.) 344.41 310.1 P
1 F
-0.35 ( 96]) 360.06 310.1 P
-0.35 (C.) 374.01 310.1 P
-0.35 (Consel, L.) 383.35 310.1 P
-0.35 (Hornof, F.) 418.11 310.1 P
-0.35 (No\221l, J.) 453.3 310.1 P
-0.35 (Noy\216, and N.) 479.61 310.1 P
-0.35 (Volanschi.) 523.56 310.1 P
0.98 (A Uniform Approach for Compile-Time and Run-Time Specializa-) 335.88 301.6 P
0.35 (tion. volume 1110 of) 335.88 293.1 P
3 F
0.35 (Lecture Notes in Computer Science) 406.38 293.1 P
1 F
0.35 (, pages 54\320) 521.09 293.1 P
(72, 1996.) 335.88 284.6 T
0.08 ([Cytron) 317.88 273.7 P
3 F
0.08 (et al.) 344.85 273.7 P
1 F
0.08 ( 89]) 360.93 273.7 P
0.08 (R.) 375.76 273.7 P
0.08 (Cytron, J.) 385.09 273.7 P
0.08 (Ferrante, B.) 418.51 273.7 P
0.08 (K. Rosen, M.) 458.58 273.7 P
0.08 (N. Wegman, and) 503.63 273.7 P
0.76 (F.) 335.88 265.2 P
0.76 (K. Zadeck. An Efficient Method of Computing Static Single As-) 344.33 265.2 P
0.39 (signment Form. In) 335.88 256.7 P
3 F
0.39 (Conference Record of the Sixteenth Annual ACM) 398.37 256.7 P
0.34 (Symposium on Principles of Programming Languages) 335.88 248.2 P
1 F
0.34 (, pages 25\32035,) 511.11 248.2 P
(Austin, Texas, January 1989.) 335.88 239.7 T
0.09 ([Engler & Proebsting 94]) 317.88 228.79 P
0.09 (D.) 401.36 228.79 P
0.09 (R. Engler and T.) 411.14 228.79 P
0.09 (A. Proebsting. DCG: An Ef-) 466.52 228.79 P
0.02 (ficient, Retargetable Dynamic Code Generator. In) 335.88 220.29 P
3 F
0.02 (Sixth International) 497.75 220.29 P
0.27 (Conference on Architectural Support for Programming Languages a) 335.88 211.79 P
(nd Operating Systems \050ASPLOS-VI\051) 335.88 203.29 T
1 F
(, pages 263\320273, October 1994.) 451.64 203.29 T
0.74 ([Engler) 317.88 192.39 P
3 F
0.74 (et al.) 344.61 192.39 P
1 F
0.74 ( 96]) 361.34 192.39 P
0.74 (D.) 377.48 192.39 P
0.74 (R. Engler, W.) 387.25 192.39 P
0.74 (C. Hsieh, and M.) 434.94 192.39 P
0.74 (F. Kaashoek. `C: A) 493.8 192.39 P
1.03 (Language for High-Level, Efficient, and Machine-Independent Dy-) 335.88 183.89 P
0.98 (namic Code Generation. In) 335.88 175.39 P
3 F
0.98 (Conference Record of POPL \32596: 23rd) 428.45 175.39 P
0.5 (ACM SIGPLAN-SIGACT Symposium on Principles of Programming) 335.88 166.89 P
(Languages) 335.88 158.39 T
1 F
(, pages 131\320144, St. Petersburg, Florida, January 1996.) 370.99 158.39 T
-0.31 ([Erosa & Hendren 94]) 317.88 147.48 P
-0.31 (A.M. Erosa and L.J. Hendren. Taming Control Flow:) 389.96 147.48 P
0.52 (A Structured Approach to Eliminating goto Statements. In) 335.88 138.98 P
3 F
0.52 (Proceed-) 528.68 138.98 P
-0.37 (ings of 1994 IEEE International Conference on Computer Languages) 335.88 130.48 P
1 F
-0.37 (,) 556 130.48 P
(pages 229\320240, May 1994.) 335.88 121.98 T
-0 ([Ferrante) 317.88 111.07 P
3 F
-0 (et al.) 349.2 111.07 P
1 F
-0 ( 87]) 365.19 111.07 P
-0 (J.) 379.85 111.07 P
-0 (Ferrante, K.) 386.96 111.07 P
-0 (J. Ottenstein, and J.) 427.39 111.07 P
-0 (D. Warren. The Pro-) 492.04 111.07 P
0.04 (gram Dependence Graph and its Use in Optimization.) 335.88 102.57 P
3 F
0.04 (ACM Transac-) 510.18 102.57 P
0.91 (tions on Programming Languages and Systems) 335.88 94.07 P
1 F
0.91 (, 9\0503\051:319\320349, July) 491.3 94.07 P
(1987.) 335.88 85.57 T
0.82 ([Goldberg & Robson 83]) 317.88 74.67 P
0.82 (A.) 403.39 74.67 P
0.82 (Goldberg and D.) 413.16 74.67 P
0.82 (Robson.) 470.35 74.67 P
3 F
0.82 (Smalltalk-80: The) 499.62 74.67 P
0 0 0 1 0 0 0 K
FMENDPAGE
%%EndPage: "15" 15
%%Page: "16" 16
612 792 0 FMBEGINPAGE
[0 0 0 1 0 0 0]
[ 0 1 1 0 1 0 0]
[ 1 0 1 0 0 1 0]
[ 1 1 0 0 0 0 1]
[ 1 0 0 0 0 1 1]
[ 0 1 0 0 1 0 1]
[ 0 0 1 0 1 1 0]
 7 FrameSetSepColors
FrameNoSep
0 0 0 1 0 0 0 K
54 26 558 44 R
7 X
0 0 0 1 0 0 0 K
V
0 0 0 1 0 0 0 K
0 0 0 1 0 0 0 K
54 72 294.12 738 R
V
3 8 Q
0 X
0.8 (Lanaguge and its Implementation) 72 732.67 P
1 F
0.8 (. Addision-Wesley, Reading, MA,) 182.18 732.67 P
(1983.) 72 724.17 T
2.38 ([Grant) 54 713.67 P
3 F
2.38 (et al.) 79.26 713.67 P
1 F
2.38 ( 97]) 97.64 713.67 P
2.38 (B.) 117.06 713.67 P
2.38 (Grant, M.) 126.39 713.67 P
2.38 (Mock, M.) 162.1 713.67 P
2.38 (Philipose, C.) 198.25 713.67 P
2.38 (Chambers, and) 243.75 713.67 P
-0.01 (S.) 72 705.17 P
-0.01 (Eggers. Annotation-Directed Runtime Specialization in C. Techni-) 80.45 705.17 P
2.73 (cal Report UW-CSE-97-03-03, University of Washington, April) 72 696.67 P
(1997.) 72 688.17 T
-0.13 ([Jones) 54 677.67 P
3 F
-0.13 (et al.) 76.31 677.67 P
1 F
-0.13 ( 93]) 92.18 677.67 P
-0.13 (N.) 106.59 677.67 P
-0.13 (D. Jones, C.) 116.36 677.67 P
-0.13 (K. Gomarde, and P.) 157 677.67 P
-0.13 (Sestoft.) 222.15 677.67 P
3 F
-0.13 (Partial Evalu-) 248.25 677.67 P
0.24 (ation and Automatic Program Generation) 72 669.17 P
1 F
0.24 (. Prentice Hall, New York,) 207.62 669.17 P
(NY, 1993.) 72 660.67 T
0.14 ([Kernighan & Ritchie 88]) 54 650.17 P
0.14 (B.) 138.97 650.17 P
0.14 (W. Kernighan and D.) 148.31 650.17 P
0.14 (M. Ritchie.) 219.36 650.17 P
3 F
0.14 (The C Pro-) 257.85 650.17 P
2.51 (gramming Language \050second edition\051) 72 641.67 P
1 F
2.51 (. Prentice Hall, Englewood) 200.17 641.67 P
(Cliffs, NJ, 1988.) 72 633.17 T
0.79 ([Leone & Lee 95]) 54 622.67 P
0.79 (M.) 116.71 622.67 P
0.79 (Leone and P.) 127.82 622.67 P
0.79 (Lee. Optimizing ML with Run-Time) 173.4 622.67 P
-0.3 (Code Generation. Technical report CMU-CS-95-205, School of Com-) 72 614.17 P
-0.09 (puter Science, Carnegie Mellon University, Pittsburgh, Pennsylvania,) 72 605.67 P
(December 1995.) 72 597.17 T
0.79 ([Leone & Lee 96]) 54 586.67 P
0.79 (M.) 116.71 586.67 P
0.79 (Leone and P.) 127.82 586.67 P
0.79 (Lee. Optimizing ML with Run-Time) 173.4 586.67 P
0.77 (Code Generation.) 72 578.17 P
3 F
0.77 (SIGPLAN Notices) 131.97 578.17 P
1 F
0.77 (, pages 137\320148, May 1996. In) 190.74 578.17 P
-0.12 (Proceedings of the ACM SIGPLAN \32596 Conference on Programming) 72 569.67 P
(Language Design and Implementation.) 72 561.17 T
0.04 ([Lindholm & Yellin 97]) 54 550.67 P
0.04 (T.) 133.25 550.67 P
0.04 (Lindholm and F.) 142.14 550.67 P
0.04 (Yellin. Inside the Java Virtual) 197.77 550.67 P
(Machine.) 72 542.17 T
3 F
(Unix Review) 103.99 542.17 T
1 F
(, 15\0501\051:31\32032, January 1997.) 144.65 542.17 T
-0.16 ([Lowney) 54 531.67 P
3 F
-0.16 (et al.) 84.72 531.67 P
1 F
-0.16 ( 93]) 100.56 531.67 P
-0.16 (P.) 114.9 531.67 P
-0.16 (G. Lowney, S.) 123.35 531.67 P
-0.16 (M. Freudenberger, T.) 171.47 531.67 P
-0.16 (J. Karzes, W.) 241.79 531.67 P
-0.16 (D.) 286.34 531.67 P
1.46 (Lichtenstein, R.) 72 523.17 P
1.46 (P. Nix, J.) 126.35 523.17 P
1.46 (S. ODonnell, and J.) 160.83 523.17 P
1.46 (C. Ruttenberg. The) 229.87 523.17 P
0.95 (Multiflow Trace Scheduling Compiler.) 72 514.67 P
3 F
0.95 (Journal of Supercomputing) 202.67 514.67 P
1 F
0.95 (,) 292.12 514.67 P
(7\0501\051, May 1993.) 72 506.17 T
0.62 ([Poletto) 54 495.67 P
3 F
0.62 (et al.) 81.96 495.67 P
1 F
0.62 ( 97]) 98.58 495.67 P
0.62 (M.) 114.49 495.67 P
0.62 (Poletto, D.) 125.6 495.67 P
0.62 (R. Engler, and M.) 162.67 495.67 P
0.62 (F. Kaashoek.) 223.86 495.67 P
4 F
1.49 (tcc) 269.1 495.67 P
1 F
0.62 (: A) 283.5 495.67 P
0.02 (System for Fast, Flexible, and High-level Dynamic Code Generation.) 72 487.17 P
3 F
-0.03 (SIGPLAN Notices) 72 478.67 P
1 F
-0.03 (, page To Appear, June 1997. In Proceedings of the) 129.97 478.67 P
0.34 (ACM SIGPLAN \32597 Conference on Programming Language Design) 72 470.17 P
(and Implementation.) 72 461.67 T
2.37 ([Steensgaard 96]) 54 451.17 P
2.37 (B.) 114.72 451.17 P
2.37 (Steensgaard. Points-to Analysis in Almost Linear) 124.06 451.17 P
0.34 (Time. In) 72 442.67 P
3 F
0.34 (Conference Record of POPL \32596: 23rd ACM SIGPLAN-SI-) 102.23 442.67 P
0.56 (GACT Symposium on Principles of Programming Languages) 72 434.17 P
1 F
0.56 (, pages) 271.35 434.17 P
(32\32041, St. Petersburg, Florida, January 1996.) 72 425.67 T
0.36 ([Weise) 54 415.17 P
3 F
0.36 (et al.) 79.02 415.17 P
1 F
0.36 ( 91]) 95.38 415.17 P
0.36 (D.) 110.77 415.17 P
0.36 (Weise, R.) 120.55 415.17 P
0.36 (Conybeare, E.) 154.24 415.17 P
0.36 (Ruf, and S.) 202.14 415.17 P
0.36 (Seligman. Auto-) 240.87 415.17 P
0.24 (matic online partial evaluation. In) 72 406.67 P
3 F
0.24 (Functional Programming & Com-) 183.4 406.67 P
(puter Architecture) 72 398.17 T
1 F
(, June 1991.) 130.88 398.17 T
0.21 ([Wilson & Lam 95]) 54 387.67 P
0.21 (R.) 120.18 387.67 P
0.21 (P. Wilson and M.) 129.51 387.67 P
0.21 (S. Lam. Efficient Context-Sensi-) 188.38 387.67 P
-0.06 (tive Pointer Analysis for C Programs.) 72 379.17 P
3 F
-0.06 (SIGPLAN Notices) 194.08 379.17 P
1 F
-0.06 (, pages 1\32012,) 252.02 379.17 P
-0.03 (June 1995. In Proceedings of the ACM SIGPLAN \32595 Conference on) 72 370.67 P
(Programming Language Design and Implementation.) 72 362.17 T
317.88 72 558 738 R
7 X
V
2 11 Q
0 X
(Appendix A) 317.88 730.67 T
(Grammar of Annotations) 389.88 730.67 T
3 8 Q
(statement:) 317.88 718.8 T
4 F
(...) 325.08 710.81 T
0 F
(/* same as in regular C */) 344.28 710.81 T
4 F
(make_static \050) 325.08 702.81 T
3 F
(static-var-list) 392.28 702.81 T
4 F
( \051 ;) 435.39 702.81 T
(make_dynamic \050) 325.08 694.81 T
3 F
(var-list) 397.08 694.81 T
4 F
( \051 ;) 420.19 694.81 T
(make_static \050) 325.08 686.81 T
3 F
(static-var-list) 392.28 686.81 T
4 F
( \051) 435.39 686.81 T
3 F
(compound-statement) 449.79 686.81 T
(static-var-list:) 317.88 672.44 T
(static-var) 325.08 664.44 T
(static-var) 325.08 656.44 T
4 F
( ,) 355.74 656.44 T
3 F
(static-var-list) 370.14 656.44 T
(static-var:) 317.88 642.08 T
(identifier) 325.08 634.08 T
(identifier policies) 325.08 626.08 T
3 6.4 Q
(opt) 381.3 624.08 T
3 8 Q
(policies:) 317.88 611.72 T
4 F
(:) 325.08 603.72 T
3 F
(policy-list) 334.68 603.72 T
(policy-list:) 317.88 589.36 T
(policy) 325.08 581.36 T
(policy) 325.08 573.36 T
4 F
( ,) 344.63 573.36 T
3 F
(policy-list) 359.03 573.36 T
(policy:) 317.88 559 T
(division-policy) 325.08 551 T
(specialization-policy) 325.08 543 T
(promotion-policy) 325.08 535 T
(merge-caching-policy) 325.08 527 T
(promotion-caching-policy) 325.08 519 T
(laziness-policy) 325.08 511 T
(division-policy:) 317.88 496.64 T
4 F
(poly_divide) 325.08 488.64 T
(mono_divide) 325.08 480.64 T
3 F
(specialization-policy:) 317.88 466.28 T
4 F
(poly_specialize) 325.08 458.28 T
(mono_specialize) 325.08 450.28 T
3 F
(promotion-policy:) 317.88 435.92 T
4 F
(auto_promote) 325.08 427.92 T
(manual_promote) 325.08 419.92 T
3 F
(merge-caching-policy:) 317.88 405.55 T
4 F
(cache_all_unchecked) 325.08 397.56 T
(cache_all) 325.08 389.56 T
(cache_one) 325.08 381.56 T
(cache_one_unchecked) 325.08 373.56 T
3 F
(promotion-caching-policy:) 317.88 359.19 T
4 F
(promote_all_unchecked) 325.08 351.19 T
(promote_all) 325.08 343.19 T
(promote_one) 325.08 335.2 T
(promote_one_unchecked) 325.08 327.2 T
3 F
(laziness-policy:) 317.88 312.83 T
4 F
(lazy) 325.08 304.83 T
(specialize_lazy) 325.08 296.83 T
(loop_specialize_lazy) 325.08 288.83 T
(eager) 325.08 280.83 T
3 F
(var-list:) 317.88 266.47 T
(identifier) 325.08 258.47 T
(identifier) 325.08 250.47 T
4 F
( ,) 354.42 250.47 T
3 F
(var-list) 368.82 250.47 T
(external-definition:) 317.88 236.11 T
4 F
(...) 325.08 228.11 T
0 F
(/* same as in regular C */) 344.28 228.11 T
3 F
(specialize-definition) 325.08 220.11 T
(specialize-definition:) 317.88 205.75 T
4 F
(constant) 325.08 197.75 T
3 6.4 Q
(opt) 363.48 195.75 T
4 8 Q
( specialize) 371.66 197.75 T
3 F
(identifier) 429.26 197.75 T
4 F
( \050) 458.6 197.75 T
3 F
(var-list) 472.99 197.75 T
4 F
( \051) 496.11 197.75 T
(on) 339.48 189.75 T
3 F
(specialize-list) 353.88 189.75 T
4 F
( ;) 397.88 189.75 T
3 F
(specialize-list:) 317.88 175.39 T
4 F
(\050) 325.08 167.39 T
3 F
(static-var-list) 334.68 167.39 T
4 F
( \051) 377.79 167.39 T
(\050) 325.08 159.39 T
3 F
(static-var-list) 334.68 159.39 T
4 F
( \051 ,) 377.79 159.39 T
3 F
(specialize-list) 401.79 159.39 T
(expression:) 317.88 145.03 T
4 F
(...) 325.08 137.03 T
0 F
(/* same as in regular C */) 344.28 137.03 T
4 F
(static *) 325.08 129.03 T
3 F
(expression) 368.28 129.03 T
(primary:) 317.88 114.67 T
4 F
(...) 325.08 106.67 T
0 F
(/* same as in regular C */) 344.28 106.67 T
4 F
(static) 325.08 98.67 T
3 F
(identifier) 358.68 98.67 T
(primary) 325.08 90.67 T
4 F
( static [) 350.86 90.67 T
3 F
(expression) 398.86 90.67 T
4 F
( ]) 433.07 90.67 T
3 F
(lvalue) 325.08 82.67 T
4 F
( static .) 344.63 82.67 T
3 F
(identifier) 392.63 82.67 T
(primary) 325.08 74.67 T
4 F
( static ->) 350.86 74.67 T
3 F
(identifier) 403.66 74.67 T
0 0 0 1 0 0 0 K
FMENDPAGE
%%EndPage: "16" 16
%%Trailer
%%BoundingBox: 0 0 612 792
%%PageOrder: Ascend
%%Pages: 16
%%DocumentFonts: Helvetica
%%+ Times-Roman
%%+ Times-Bold
%%+ Times-Italic
%%+ Courier
%%+ Courier-Bold
%%+ Symbol
%%+ Courier-Oblique
%%+ Helvetica-Oblique
%%EOF

Date: Thu, 3 Apr 1997 17:20:06 -0800 (PST)
From: chambers@klamath (Craig Chambers)
To: spin-comp@cs
Subject: paper done!!

I've mailed postscript to Consel and we express-mailed him hardcopy.
I've made three versions of the file in my directory:

dc-camera.{doc,ps}: What we sent Consel, w/ no page numbers.

dc-notice.{doc,ps}: Like dc-camera, except w/ page numbers and a
notice saying where the paper will appear.  This is what we should
make available on our web page and point other people to.

dc.doc: The version before I hacked the page layout, converting
variables to text, etc.  When we extend this document to the expanded
TR form, or reuse pieces of it for other papers, we should use this
document, since it hasn't been hacked up just for a particular
publication form.

-- Craig

Date: Fri, 4 Apr 1997 10:27:39 +0200
From: Charles Consel <Charles.Consel@irisa.fr>
To: chambers@cs.washington.edu
Subject: Re: pepm paper


Got it. Pretty well. Thanks!

Charles

----------------------------------------------------------------------------
Charles Consel              | University of Rennes / Irisa 
 consel@irisa.fr            | Campus Universitaire de Beaulieu
 Phone: (33) 2 99 84 74 10 | 35042 Rennes Cedex
 Fax:   (33) 2 99 84 71 71 | France
----------------------------------------------------------------------------
  URL: http://www.irisa.fr/EXTERNE/projet/lande/consel/consel.html & index.html
----------------------------------------------------------------------------

Date: Fri, 4 Apr 1997 10:26:36 -0800 (PST)
From: chambers@klamath (Craig Chambers)
To: spin-comp@cs
Subject: meeting time

We need to schedule an official meeting time for Spring quarter.  I want to 
pick an afternoon, to keep all my mornings free to stay home after the new
baby arrives.  Please let me know what constraints you have in the afternoon
that I don't share.

-- Craig

Date: Fri, 4 Apr 1997 11:34:41 -0800 (PST)
From: chambers@klamath (Craig Chambers)
To: spin-comp@cs
Subject: re: meeting

BTW, I'm gone next W-F, so we won't meet next week unless we pick a meeting
time early in the week.

-- Craig

To: spin-comp@franklin.cs.washington.edu
Subject: Getting abbreviated bib refs in bibframe
Date: Fri, 04 Apr 1997 12:11:22 PST
From: Matthai Philipose <matthai@franklin.cs.washington.edu>

There are a few options:

1) For the document being edited, define the variable bf-bibstyle
   and set it to mmlabbrv

2)Before you start frame (and/or in your .cshrc) 
	setenv BIBFRAMEBST 'mmlabbrv'

3)Set the system bib style default to mmlabbrv; I don't know how this is done, 
and
  it may not be practical unless the Cecil group is also OK
  with this default.

The refs in the paper show up as [3],[1],[2]... and the biblio
is alphabetized, with only initials for each author's first names. The bibframe
documentation does not describe an abbreviated bibstyle which makes the
refs show up as [Grant et. al] instead of [2] (i.e. word-references
instead of numbers). However, if we prefer this style, the document
indicates it's easy to create this format.

Any preferences?
		Matthai

Date: Mon, 7 Apr 1997 11:26:18 -0700 (PDT)
From: chambers@klamath (Craig Chambers)
To: spin-comp@klamath
Subject: meeting time

Given everyone's constraints, it looks like either Mondays 12-2 or Fridays
2-4 for meeting times.  Any preferences?

-- Craig

To: spin-comp@thistle.cs.washington.edu
Subject: Cache replacement (cache_one)
Date: Mon, 07 Apr 1997 12:24:22 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

Over the weekend, I thought of a problem with the implementation of the
cache_one policy as described in the paper.

Eager and lazy unit edges w/o promotions are patched to be direct branches
to their destinations.  What happens if their destination is removed from the
cache?  I thought of three possible solutions:

	1) Require a run-time cache lookup for any unit where any static
	   variable has the cache_one policy (henceforth called a cache_one
	   unit), rather than putting in a direct branch.
	2) Leave a callback in the place of the cache_one unit; a cache
	   flush is required*, and the space required by the callback
	   cannot be freed until all units jumping to it are freed; thus,
	   we must also maintain a list of units branching to the cache_one
	   unit.
	3) Insert an indirect jump, rather than a direct branch.  When the
	   cache_unit unit is generated, set the jump address to the address
	   of the unit.  Initially or when it is removed from the cache,
	   direct the jump to a callback stub.  We wouldn't be able to set the
	   prefetch-hint bits, because then the indirect jumps would require
	   patching as in #2.

#1 is conceptually simple and has no specialize-time cost but the
   greatest run-time cost (run time being time spent executing generated code).
#2 is the most complicated scheme and has a significant specialize-time cost,
   but no run-time cost.
#3 is very simple and has a small specialize-time cost and a small run-time
   cost.

#1 is obviously out.  #3 would be easier to implement than #2.

One might also think of using a valid/invalid flag for the cache_one unit,
but I couldn't think of a way to use a flag that wouldn't be strictly more
expensive (at both specialize time and run time) than #2.

--Brian

* If we have to flush the entire instruction cache anyway to replace the
  previous specialized version, then no additional flush is needed.

To: spin-comp@franklin.cs.washington.edu
Subject: name game
Date: Mon, 07 Apr 1997 12:24:27 PDT
From: Matthai Philipose <matthai@franklin.cs.washington.edu>

My two cents towards the advancement of science:

EDyCT: Efficient/Excellent ;-) Dynamic Compilation Technology/Tools
PrEDyCt: Practical, Efficient, Dynamic Compilation Technology/Tools

PARADyCE: Practical Automatic RApid Dynamic Compilation Engine

Date: Mon, 7 Apr 1997 12:49:01 -0700 (PDT)
From: chambers@klamath (Craig Chambers)
To: grant@cs.washington.edu
Subject: Re: corrections to the paper
Cc: spin-comp@cs

> From grant@thistle.cs.washington.edu  Mon Apr  7 12:37:00 1997
> Delivery-Date: Mon, 07 Apr 1997 12:37:04 PDT
> X-Mailer: exmh version 1.5.3 12/28/94
> Reply-To: grant@cs.washington.edu
> To: chambers@thistle.cs.washington.edu
> Subject: corrections to the paper
> Mime-Version: 1.0
> Date: Mon, 07 Apr 1997 12:36:56 PDT
> From: Brian Grant <grant@thistle.cs.washington.edu>
> 
> I have found some typos, fontos, etc. in the paper.  I would also like to
> twiddle with Figure 9 a little more.  None of the corrections/modifications
> I would make is major.
> 
> 	-- Should we bother to send Consel a corrected version of the
> 	   postscript?  (my guess: no)
> 	-- Should we put a corrected version of dc-notice.ps on our web
> 	   page, or just the version that will be in the PEPM proceedings?
> 
> --Brian
> 
> 

I don't think we can send anything new to Consel.

I think we can make dc-notice.ps anything we want.  We should definitely fix
bugs there, and other minor improvements too.

And remember that we still have to do the TR version, which can have major
improvements and extensions to e.g. the linearization algorithm, the better
version of reachability, single-run-time-predecessor and related optimizations,
etc.

For the TR version, I'd like to have some more implementation experience before
finishing it, so we can have some additional confidence it's right.

-- Craig

Date: Mon, 7 Apr 1997 17:09:15 -0700 (PDT)
From: chambers@klamath (Craig Chambers)
To: spin-comp@cs
Subject: group meeting

OK, given the conflicting preferences, I'll pick Monday at noon for our 
group meeting.  Feel free to bring lunch.  I assume we'll normally be an hour,
but we can take up to two if needed.

-- Craig

To: spin-comp@cs
Subject: we have RTCONSTs! (sort of)
Date: Tue, 08 Apr 1997 21:43:25 PDT
From: Brian Grant <grant@meitner.cs.washington.edu>

Well, at least the _one_ I've inserted is no longer crashing Multiflow. :-)
Now to just get Multiflow to do what we want with them...
	
Current translation of a rtconst + temp in template code:
	lda	r26,rtconst_0_0%(rZ)	;class source,cspec
	...
	addl	r25,r26,r3	;class source

--Brian

To: spin-comp@thistle.cs.washington.edu
Subject: RTCONSTs working!
Date: Wed, 09 Apr 1997 16:28:13 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

I have replaced static operands in the template code with
RTCONSTs and inserted store ops in the setup code corresponding to
those uses.  The RTCONSTs go through for my small test program and
print in the format Matthai requested.

Example template use:
	lda	r3,rtconst_0_0(r26)
Example setup store:
	stl	r26,rtconst_0_0_0(gp)

The store ensures that a register (r26) contains the value corresponding to
hole (rtconst_0_0) in the template.  (I think r26 appearing in both
instructions is a coincidence; that register happened to have been free in
that basic block in both the setup block and the template block.)

I'll check this version into CVS momentarily.

--Brian


To: spin-comp@thistle.cs.washington.edu
Subject: commit completed
Date: Wed, 09 Apr 1997 16:36:58 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

Let me know if you have any problems.

--Brian


To: spin-comp@franklin.cs.washington.edu
Subject: GE-gen/merger interface seems to be working
Date: Wed, 09 Apr 1997 18:00:09 PDT
From: Matthai Philipose <matthai@franklin.cs.washington.edu>

Brian's simple example passes all the way through in the
format expected by the merger. 

Specifically, the trace-scheduler now leaves all our basic-block
begin/end labels where we expect them. The way in which the
trace-scheduler works, I had to modify the merger slightly. 

There is an open question about how the merger "returns" the
location of the generated code (and what version/approximation of
the code caching/lookup scheme to implement). Brian and I will probably
agree on an interface  tomorrow. Once this interface is fixed,
we should be able to send the code through the merger, execute the
GE and execute the emitted code.

		Matthai




To: spin-comp@thistle.cs.washington.edu
Subject: ACM computing surveys on PE
Date: Fri, 11 Apr 1997 17:13:40 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

It seems like we should be able to come up with a 1000-word submission for
this by October. :-)  Do people have any interest in this, or would it be a
waste of time?  Only once have I even read Computing Surveys...

--Brian


                            Call for Journal Contributions

                              ACM Computing Surveys
                       1998 Symposium on Partial Evaluation

                                        Guest Editors:
                      Olivier Danvy, Robert Glück, and Peter Thiemann 



The 1998 Symposium on Partial Evaluation is a collection of short articles characterizing the state of the art, stating
challenging problems, and outlining promising directions for future work.

Topics of interest include all areas of partial evaluation and semantics-based program manipulation, automatic
program transformation, and their applications. Contributions should be expository in nature and should explain
relevant trends in partial evaluation in both general and technical terms, with a maximum of clarity and
conciseness. Statements of open problems that have a potential impact on the future development are particularly
welcome. Every effort should be made to make contributions self-contained and understandable to a general
audience.

Submission Procedure

Submissions should be no longer than 1000 words. They should adhere to the Information for Authors of the ACM
Computing Surveys. Please send your submission as a postscript file by electronic mail to

     sope98@brics.dk 

Each submission should be accompanied by a plain ASCII message giving the title, authors, and the postal and
electronic address of the corresponding author. 

Important Dates

     Papers due: September 30, 1997 
     Notification: November 30, 1997 
     Final papers: January 31, 1998 

Please consult one of the guest editors in advance if you are in doubt about the appropriateness of your planned
contribution.

Guest Editors

     Olivier Danvy, BRICS, University of Aarhus (danvy@brics.dk) 
     Robert Glück, DIKU, University of Copenhagen (glueck@diku.dk) 
     Peter Thiemann, Wilhelm-Schickard-Institut, University of Tübingen
     (thiemann@informatik.uni-tuebingen.de) 


March 25, 1997


To: spin-comp@thistle.cs.washington.edu
Subject: list of possible things for Matthai to do
Date: Mon, 14 Apr 1997 13:20:10 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

Off of the top of my head...

--Brian

1) Analyses
	-- Prepass to compute MayDefVars, LiveVars, UsedVars
		-- includes intraprocedural points-to analysis
	-- Reachability conditions
		-- to work in polyvariant BTA
		-- capable of handling static IGOTOs
		-- keeping track of equivalence classes of predecessors wrt
		   variables (or weaker notion?)
	-- Postpass to compute lazy edges
	-- Clustering

2) Oracle
	-- Instrumentation to write out static values and nec. unit info
	-- Module to read in static values and invoke compile-time specializer
	-- Compile-time specializer
		-- includes interface to BTA

3) Caching
	-- Remaining cache_one and other cache-replacement details
		-- Keeping track of direct branches to replaceable code
		-- Coping with reclamation and reuse of variable-sized
		   chunks of memory, fragmentation, etc.
		-- Minimize space-allocation checks and other overhead
	-- Hybrid hierarchical/flat caching scheme
	-- Cache-replacement schemes for cache(n)
	-- Global caching policies, rather than local ones (i.e., we would
	   like to free memory for specializations of functions that won't
	   be called again)
	-- More flexible interface to the cache (e.g., for looking up more
	   general versions if the more specialized version isn't in the
	   cache)
	-- Evaluating importance of caching/replacement schemes


To: spin-comp@franklin.cs.washington.edu
Subject: One topic of discussion for next week's meeting
Date: Mon, 14 Apr 1997 15:57:19 PDT
From: Matthai Philipose <matthai@franklin.cs.washington.edu>

Folks,
I had a chat with Craig after today's meeting, continuing
the discussion of what would be good for me to work on,
but this time with an emphasis on longer term plans. (In
the short term, it seems that working on the post/pre-
passes to the BTA is the most useful thing to do, and Markus, 
Brian and I will discuss this further).

We decided that it would be a good idea for all group members
to be in on a discussion in next week's meeting about what
they would like to work on once this implementation phase is
over, especially wrt "thesis-directed" work. If nothing else,
the discussion should set us thinking about what the possiblities/
preferences are, and help us see beyond a possibly long implementation
phase.

If you have some views on this topic, please make sure you remember
them and bring them up at next Monday's meeting.
			Matthai





To: Matthai Philipose <matthai@cs.washington.edu>
Cc: spin-comp@franklin.cs.washington.edu, eggers@pa.dec.com
Subject: Re: One topic of discussion for next week's meeting 
Date: Mon, 14 Apr 97 16:15:24 -0700
From: Susan Eggers <eggers@pa.dec.com>

I'll be out of town next Monday.

In addition to talking about dissertation directions, can you also
give some thought to a PLDI submission.  Because its content may
"steal" from the individual research areas.

My current thinking is an overview of the new system, emphasizing its
new features and performance results on the new, expanded workload.
But we may need to include other related topics, such as what opts or
annotations were used in what programs, stressing the extent to which
our new functionality was needed.

Susan


To: spin-comp@thistle.cs.washington.edu
Subject: Re: Good news from the folks upstairs ...
Date: Tue, 15 Apr 1997 09:45:58 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

From Mr. Ed:
>> I'm delighted to report that the Provost has today approved all
>> three of our promotion cases.  As of September 16, Craig Chambers
>> will be an Associate Professor with tenure, and Carl Ebeling and
>> Dan Weld will be Professors.

Congrats, Craig!  Just in time to take time off with the new baby. :-)

--Brian


To: grant@cs.washington.edu
Cc: spin-comp@thistle.cs.washington.edu, eggers@pa.dec.com
Subject: Re: ACM computing surveys on PE 
Date: Wed, 16 Apr 97 17:25:53 -0700
From: Susan Eggers <eggers@pa.dec.com>

I would think that we have more important venues to target.

Susan


Date: Fri, 18 Apr 1997 14:23:16 -0700
From: Charles Garrett <garrett@cs.washington.edu>
To: spin-m3
Subject: Talk on Monday

For the SPIN group:
	I switched weeks with David, so I will be talking about
	the dynamic compilation project on Monday.

For the dynamic compilation group:
	The SPIN meetings include a 45 minute presentation on 
	current work. This week I'll be discussing our project.
	Please join us in room 422 on Monday at 9:30 if you can
	make it. The bigger the crowd, the better the discussion
	should be.

--
Charlie

To: spin-comp@thistle.cs.washington.edu
Subject: updated research agenda on the group web
Date: Mon, 21 Apr 1997 11:07:50 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

http://www.cs.washington.edu/research/projects/unisw/DynComp/www/
	Internal/Research/agenda.html

It would be helpful to take a look before the meeting.

--Brian


Date: Tue, 22 Apr 1997 18:34:24 -0700 (PDT)
From: chambers@klamath (Craig Chambers)
To: spin-comp@cs
Subject: bytecodes vs. translation paper

I found the bytecodes vs. translation paper, if anyone wants to borrow it.

-- Craig

To: spin-comp@thistle.cs.washington.edu
Subject: cvs commit of p2dyc
Date: Wed, 23 Apr 1997 12:35:19 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

I just checked in new versions of nearly all of the files in p2dyc, and
also a few files in p2graph, p2types, and phase1.  The new version works
for the test case Matthai and I have been using: a single single-unit 
(single basic block!) dynamic region (essentially promote_all_unchecked).
It exercises a fair bit of the unit code, and is largely unhacked.

--Brian


Date: Wed, 23 Apr 1997 21:48:18 -0700
From: chambers@hoh
To: cecil@cs, faculty@cs, spin-comp@cs
Subject: Baby!

At 5:27 Wednesday morning, Adelaide Woods Chambers (a.k.a. Addie) was born.
Mom and Dad are pretty beat, sister Caitlin is extremely energetic and excited,
and Addie is sleepy and doing very well.

I won't be in on Thursday; can someone take over my 11:30 appt with Debevec?

-- Craig

To: spin-comp@franklin.cs.washington.edu
Subject: regression tests
Date: Fri, 25 Apr 1997 12:26:53 PDT
From: Matthai Philipose <matthai@franklin.cs.washington.edu>

Given the major changes we've been making to the compiler
(64-bit conversion, dynamic-compilation related work),
it's probably a good idea to make sure the "official
version(s)" at any time is(are) working.

We should probably set up a regression suite that
contains both programs that use dynamic compilation
and those that don't (e.g. spec95) to this end.

Perhaps we should talk about this at the next meeting.
		Matthai

Date: Fri, 25 Apr 1997 14:14:45 -0700 (PDT)
From: chambers@klamath (Craig Chambers)
To: spin-comp@franklin.cs.washington.edu, matthai@cs.washington.edu
Subject: Re: regression tests

Good idea.  And a regression suite for the test cases that are being used for
DC testing can be started at the same time.

-- Craig

Date: Mon, 5 May 1997 08:58:10 -0700 (PDT)
From: "Markus U. Mock" <mock@cs.washington.edu>
To: spin-comp@cs.washington.edu
Subject: sick

I woke up with fever and stomach cramps and therefore won't be in today.

The sometimes incorrect BTA was due to the removal of the annotation stats
without propagating that info to the following stats.  I am now looking at
the output of the equivalence set info trying to figure out that it is all
correct.



	-- Markus 



To: spin-comp@franklin.cs.washington.edu
Subject: Merging with the 64-bit version			
Date: Tue, 06 May 1997 11:50:50 PDT
From: Matthai Philipose <matthai@franklin.cs.washington.edu>

Folks,
I have just committed all the code in the mflow backend
necessary for generating the generating extension; I have
also committed the merger perl scripts into the bin directory.
Everything is committed to the 32-bit branch right now.

Brian and Markus will try to get a "commitable" version of
their codes by today afternoon. We (Charlie and I?) can 
then merge the  up-do-date and "complete" 32-bit version with 
the 64-bit version.

Hopefully, beginning later today, everyone will commence
working with the 64-bit version of the dynamic compilation 
infrastructure.
	Matthai



To: Matthai Philipose <matthai@cs.washington.edu>
Cc: spin-comp@franklin.cs.washington.edu, eggers@pa.dec.com
Subject: Re: Merging with the 64-bit version 
Date: Tue, 06 May 97 12:00:28 -0700
From: Susan Eggers <eggers@pa.dec.com>

The 64 bit version?
This is great.

Susan


To: spin-comp@thistle.cs.washington.edu
Subject: my version has been merged with Matthai's
Date: Tue, 06 May 1997 17:01:40 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

I merged my version with Matthai's and checked it into CVS.  The merge
uncovered a bug in Matthai's code.  We introduced a quick fix to get around
the problem, and Matthai is trying to determine whether the quick fix should
be the permanent fix.

About the new version:

You should checkout DyC/bin and DyC/lib if you haven't already, and update
all of bin, lib, and mflow.  In the future, run your own version of dyc2c,
NOT the version in /afs/cs/project/dyncomp/bin.  You will also need to
set an environment variable, DYC_LIB_DIR, to your lib directory (e.g.,
/afs/cs/project/dyncomp/grant/DyC/lib).

--Brian


Date: Wed, 7 May 1997 10:03:34 -0700 (PDT)
From: Markus Mock <mock@apex.cs.washington.edu>
To: spin-comp@apex.cs.washington.edu
Subject: ready for 64bit change

I committed my changes to the repository, so we're ready for the 64 bit 
merge.


	-- Markus


Date: Thu, 8 May 1997 00:27:33 -0700 (PDT)
From: garrett@porky-pig
To: spin-comp@porky-pig
Subject: 64 bit code merged


I checked in the combined dynamic compilation and 64 bit code and
tagged it with the name "dyc-64bit". There are a couple of changes
that users should be aware of.

I editted the pmakefiles in p2dyc and p2bta so that object files are
rebuilt when the headers they depend on are changed. It appears that
you have to put the line with the .o file immediately after the
dependencies for its .C file to make it work right.

I added functions called DYC_Keyword and DYC_RTKeyword to recognize
the special function names beginning with DyC in the boilerplate code.
This only matters for the function names, because they need a "_" in
32-bit mode but no "_" in 64-bit mode.

I found one bug in the bk_Process_Tags_And_Igotos function. It
would interpret partially compact micro instructions as if they
were uncompact ones. The partially compact ones can contain control
flow graph edges where the uncompact ones contain statements and this
caused problems. I inserted an extra test to check that a micro
instruction is really an uncompact one before accessing its fields.
This may not be the right solution, but it works on the current test
programs.

This merge adds two directories called cfe_alpha and ffe_alpha which
are the modified front-ends for C and Fortran respectively. Make sure
that these directories are created and filled when you update to my
changes. I think using "cvs upd -d" should ensure that the directories
are created.

There are a number of compiler flags to use when running the 64-bit
version of the compiler. Here is the whole list, with explanations to
follow:

	-mGLOB_machine_word_size=64 
	-mP1OPT_call_default=P1OPT_CALL_DEFAULT_REGS 
	-mP1OPT_entry_default=P1OPT_ENTRY_DEFAULT_REGS
	-mGLOB_as_type=osf 
	-mP1COPT_ansi 
	-D__LANGUAGE_C__
	-Dsigned=
	-I/projects/trace1/mflow/usr/vssad/release/garrett/usr/usr_include_alpha
	-S

The GLOB_machine_word_size option tells the compiler to use
the 64 bit version. The P1OPT_call_default and P1OPT_entry_default
options cause the compiler to pass arguments in registers according
to the standard Alpha calling convention. The GLOB_as_type option
makes it generate assembly language for the DEC assembler rather
than Multiflow's version of the GNU assembler. The P1COPT_ansi
option is useful for any ANSI C programs, such as our test suite.
The __LANGUAGE_C__ definition conditionally includes the right
code from the DEC header files. The signed= definition eliminates
a C keyword that Multiflow doesn't understand. The -I option causes
the compiler to use the regular DEC header files instead of
Multiflow's. This is necessary to link with the 64-bit standard
libraries. Finally, use the -S option to generate assembly language
and prevent the scc driver program from calling the GNU assembler.
Use a makefile to assemble the output with "as" and link the 
final program with "cc".

My test programs are in /afs/cs/project/dyncomp/garrett/dyncomp/lcc.
I will work on placing them in some central location with automated
regression test scripts.

--
Charlie


Date: Fri, 16 May 1997 17:24:35 -0700 (PDT)
From: Markus Mock <mock@apex.cs.washington.edu>
To: spin-comp@apex.cs.washington.edu
Subject: PEPM practice talk, Monday 12pm 

in the chateau conference room. I've also reserved Sieg 114, just in case.

Brian and I will give a practice run of our "Run-Time Specialization in C".


	-- Markus


Date: Fri, 16 May 1997 18:30:47 -0700
From: Charles Garrett <garrett@cs.washington.edu>
To: spin-comp
Subject: More changes to Multiflow

I have a few more things working with Multiflow now.

First, I have compiled three Fortran programs (SPEC benchmarks) 
with the 64 bit compiler. This also entailed compiling Multiflow's
Fortran library with the DEC C compiler. One of the programs 
runs correctly. One runs with small numerical errors which may be due
to the compiler or the library. The third one seg faults.

One side benefit of compiling these programs is that they exposed
bugs in optimization phases of the 64 bit backend. These bugs were
primarily concerned with floating point types which are not heavily
used in our C benchmark programs.

I also managed to get two more C language SPEC benchmarks to compile,
although I rewrote parts of them that use variable argument lists.
The 130.li lisp interpreter benchmark now runs correctly. The 
124.m88ksim simulator program runs but produces incorrect output.
I also tried compiling the 126.gcc benchmark, but it doesn't compile
yet. I will continue working on these last two benchmarks and on
the variable arguments facility.

--
Charlie

To: spin-comp@thistle.cs.washington.edu
Subject: practice talk postponed
Date: Mon, 19 May 1997 10:37:34 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

We're not quite ready to give the practice talk.  We need to work a little
more on the slides and work out in more detail what we will say, particularly
about the example.  So, we'll aim for a practice tomorrow or Wednesday.

Instead, at today's meeting, we should probably discuss the TR in more
detail.

--Brian


Date: Mon, 19 May 1997 11:55:48 -0700 (PDT)
From: chambers@klamath (Craig Chambers)
To: spin-comp@cs
Subject: postpone talk?

I have to guest-lecture 341 today, 12:30-1:30.  Can we postpone the practice
talk till 3pm?

-- Craig

Date: Mon, 19 May 1997 11:57:07 -0700 (PDT)
From: chambers@klamath (Craig Chambers)
To: spin-comp@thistle.cs.washington.edu, grant@cs.washington.edu
Subject: Re: practice talk postponed

OK, never mind about my postpone msg.  But I can't meet anyway today.

-- Craig

Date: Mon, 19 May 1997 12:19:50 -0700 (PDT)
From: Markus Mock <mock@apex.cs.washington.edu>
To: spin-comp@apex.cs.washington.edu
Subject: PEPM practice talk: Tuesday, 2:30 in 422



	-- Markus


Date: Mon, 19 May 1997 15:40:17 -0700 (PDT)
From: chambers@klamath (Craig Chambers)
To: spin-comp@cs
Subject: bad link.

Can someone fix this?  Actually, the reference to dynamic compilation research
on the Spin pages should go to the whole dyn-comp web space (if it doesn't
already).

-- Craig


----- Begin Included Message -----

From bershad@lace.cs.washington.edu  Mon May 19 14:21:07 1997
Delivery-Date: Mon, 19 May 1997 14:21:10 PDT
To: chambers@cs
cc: eggers@cs
Subject: bad link.
Date: Mon, 19 May 1997 14:21:03 PDT
From: Brian Bershad <bershad@lace.cs.washington.edu>


------- Forwarded Message

Date:    Mon, 19 May 1997 14:07:37 -0700
From:    Jean Brouwers <Jean.Brouwers@Eng.Sun.COM>
To:      spin@cs.washington.edu
Subject: Bad URL link

Hi,

On your web page

http://www.cs.washington.edu/research/projects/spin/www/papers/index.html

the link "Paper (postscript)" for Conference Paper "Fast, Effective
Dynamic Compilation" is broken.  It probably should point to
.../pli96.ps.Z instead of .../pli96.ps.

/Jean Brouwers


------- End of Forwarded Message



----- End Included Message -----


Date: Thu, 22 May 1997 11:50:12 -0700 (PDT)
From: chambers@klamath (Craig Chambers)
To: grant@cs.washington.edu
Subject: Re: Division Querying / Filters
Cc: spin-comp@cs

Interesting.

To: spin-comp@franklin.cs.washington.edu
Subject: code for temps/source-code variable correspondence checked in
Date: Thu, 22 May 1997 12:05:50 PDT
From: Matthai Philipose <matthai@franklin.cs.washington.edu>

I have just checked in the code for maintaining the correpondence
between temporaries and their source code variables. As we discussed,
this is essential if the scope of our annotations is to extend beyond
re-definitions of the variable made static. In particular, it is
essential if autopromotion and polyvariant specialization at merges
is to work.

The dump_graph() routine has been modified to annotate each temp
with the name of the source-variable it corresponds to, if any.
A temp that originally printed out as t1 now prints out as
<x>t1, where x is the original source-variable.

I have tested the code on our simple test program test.c, stack.c 
from the previous benchmark suite, and the main cache update routine
from dinero, and it seems to work.

The correspondence is extracted when variables are assigned
to temporaries in the p2rvd.C (register value detection module).
Essentially, any time I see:
	load t1, <source-var>  or
       store t1, <source-var>        
I annotate t1 with source-var.

I also went through every routine that looked like it replacing a temp, 
and made sure the source-var field was transferred to the target temp.

I have now commenced working on a pass for computing the helper sets
MayDefVars, LiveVars and UsedVars. I am modelling the latter passes very
losely after the mflow live-temps phase, except that I deal  with variables, 
not just 
temps. I am deferring the simple points-to analysis for MayDefVars at present; 
all variables whose addresses are taken anywhere in the function may be def'ed 
at a 
store/fn-call. I hope to be done with the first cut early next week.

The Multiflow compiler has been very co-operative so far. Hope that lasts! :-)
					Matthai
    




To: spin-comp@thistle.cs.washington.edu
Subject: TR
Date: Fri, 23 May 1997 10:25:58 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

Given that there are only 10 working days left before Markus and I leave
for Amsterdam, we should probably start on the TR.  We should decide what
examples to add, what details to add, and what extensions to make, if any.
Some possibilities are listed below.

Oh, and should we try to come up with a name for the system?

Examples
--------
Interpreted Program
Specialized Interpreter (mention run-time register allocation)
Demonstrations of trickier points in the BTA
	-- Annotated variable becoming derived
	-- Derived annotated variable becoming a root variable
	-- Dead variables removed from StaticVarInfo but not Division
Application of clustering (e.g., when dead variables are removed from
	StaticVarInfo)
Better linearization example (with code)

Details
-------
Semantics for lazy policy?
Syntactic sugar for pointers (constant)
More text about the BTA
	-- Differences between Division and StaticVarInfo
	-- Partition and MergePartitions
	-- FilterStaticVars
	-- SourceRoots
The Naming Problem
Reachability Conditions
Unit Identification
Clustering
	-- Importance of control equivalence
Linearization
Merging
Small detail: intra-unit branch patching
Small detail: overwriting computed jump with direct branch
Repatching direct branches to replaced cache_one units
More comparison with `C

Extensions
----------
A policy that determines whether to split on policies or not
Division Querying (is_static)
Control-point "lazy" annotation
Interprocedural Specializer
Compile-time inlining
Run-time inlining
Hierarchical Cache
Fancier Clustering
Singe Run-Time Predecessor Optimizations
setjmp/longjmp
No static merges: make reachability conditions a BTA output

--Brian


To: spin-comp@thistle.cs.washington.edu
Subject: meeting today?
Date: Mon, 26 May 1997 08:22:44 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

Will there be a meeting today?

--Brian

Date: Mon, 26 May 1997 11:23:42 -0700 (PDT)
From: chambers@klamath (Craig Chambers)
To: spin-comp@thistle.cs.washington.edu, grant@cs.washington.edu
Subject: Re: meeting today?

I'm here and assuming we'll meet.

-- Craig

Date: Mon, 26 May 1997 13:47:46 -0700 (PDT)
From: chambers@klamath (Craig Chambers)
To: chambers@klamath.cs.washington.edu, mock@cs.washington.edu
Subject: Re: meeting today?
Cc: spin-comp@cs

Actually, no one came.

-- Craig

Date: Mon, 26 May 1997 16:11:24 -0700 (PDT)
From: chambers@klamath (Craig Chambers)
To: cecil@cs, spin-comp@cs
Subject: Brunch party
Cc: sylviac@klamath

To celebrate Jeff's and Greg's graduation, and to wish Charlie well in his new
job at Equator, I'd like to have a brunch at my house.  The date that appears 
to work best for everyone's schedule is Friday June 13.  (Sorry, Brian and 
Markus, you'll have to enjoy Amsterdam instead!)  Can people make it between
11am and 1pm at my house on that date?  Families are welcome.

-- Craig

Date: Mon, 26 May 1997 18:08:25 -0700 (PDT)
From: chambers@klamath (Craig Chambers)
To: spin-comp@thistle.cs.washington.edu, grant@cs.washington.edu
Subject: Re: TR

I read through your list, and selected a bunch of points I think we should 
include, time permitting.  I wanted to discuss it at today's meeting, but 
perhaps we should have a different meeting to go over it.

I don't know if we want to do whatever we can in two weeks and then release
that, or if we want to do more work and release something solid & complete,
or if we want to do next to nothing and focus all our attention on the 
implementation.  The latter path has distinct advantages, but the communication
benefits of the second path are in line with our academic purpose.

-- Craig

To: chambers@klamath (Craig Chambers)
cc: spin-comp@thistle.cs.washington.edu
Subject: Re: TR 
Date: Mon, 26 May 1997 21:09:05 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

We should probably have a meeting about the TR asap, and also schedule another
practice talk.

--Brian

To: chambers@franklin.cs.washington.edu
cc: spin-comp@franklin.cs.washington.edu
Subject: Meeting on TR/talk
Date: Tue, 27 May 1997 10:31:54 PDT
From: Matthai Philipose <matthai@franklin.cs.washington.edu>

Should we meet today about the TR and the talk? I am free all day.
			Matthai

Date: Tue, 27 May 1997 10:50:08 -0700
From: Brian Grant <grant@cs.washington.edu>
To: Matthai Philipose <matthai@cs.washington.edu>
Subject: Re: Meeting on TR/talk

Matthai Philipose wrote:

> Should we meet today about the TR and the talk? I am free all day.

Me, too.

--Brian




Date: Tue, 27 May 1997 10:52:55 -0700 (PDT)
From: chambers@klamath (Craig Chambers)
Subject: Re: Meeting on TR/talk
Cc: spin-comp@franklin.cs.washington.edu

How about 1-1:30 today?

-- Craig

Date: Tue, 27 May 1997 11:26:15 -0700 (PDT)
From: Markus Mock <mock@apex.cs.washington.edu>
To: Craig Chambers <chambers@klamath>
cc: spin-comp@franklin.cs.washington.edu
Subject: Re: Meeting on TR/talk

Fine with me too.

	-- Markus

On Tue, 27 May 1997, Craig Chambers wrote:

> How about 1-1:30 today?
> 
> -- Craig
> 

Date: Tue, 27 May 1997 11:35:15 -0700
From: Charles Garrett <garrett@cs.washington.edu>
To: Craig Chambers <chambers@klamath>
Subject: Re: Meeting on TR/talk

Craig Chambers wrote:
> 
> How about 1-1:30 today?
> 
> -- Craig

Ok.

--
Charlie

Date: Tue, 27 May 1997 11:57:54 -0700
From: Charles Garrett <garrett@cs.washington.edu>
To: spin-m3
Subject: Make money in the comfort of your own home

I realized while talking to Tian that not everyone has heard this
news, although I think most of you have. I am leaving the University
to start a job with Equator Technologies Consulting on June 1. I will
be staying in Seattle and working from home, at least until January.
I hope to continue attending some seminars and meetings
and for those of you using software that I wrote, I will be around
to maintain it.

This company is not the same as the Equator chip company located
in Seattle, although the two are related. The consulting company
is a much smaller business which concentrates on writing compiler
software for clients. The reason I like the job is because they
are putting reasonably advanced compiler techniques into practice,
although rumors that I am selling out for the money are also
well founded.

Thursday will be my last day here, so I hope I get to see you
all before then.

--
Charlie

Date: Tue, 27 May 1997 17:07:09 -0700 (PDT)
From: Markus Mock <mock@apex.cs.washington.edu>
To: spin-comp@apex.cs.washington.edu
Subject: PEPM practice talk, Thursday, after colluqium

We'll have another practice talk on Thursday, right after the colloquium, 
i.e.  around 4:30/4:45.

We'll try the Chateau conference room, but just in case I've also booked 114.

See you there

	-- Markus



To: grant@cs.washington.edu
Cc: spin-comp@thistle.cs.washington.edu, eggers@pa.dec.com
Subject: Re: TR 
Date: Thu, 29 May 97 12:24:00 -0700
From: Susan Eggers <eggers@pa.dec.com>

Can someone fill me in on this?  What is the purpose of the TR and
why are we tieing it to PEPM?

Susan


Date: Thu, 29 May 1997 12:39:41 -0700
From: Brian Grant <grant@cs.washington.edu>
To: Susan Eggers <eggers@pa.dec.com>
Subject: Re: TR

Susan Eggers wrote:

> Can someone fill me in on this?  What is the purpose of the TR and
> why are we tieing it to PEPM?

The purpose of the TR is twofold:
1) Add examples and explanation to make the PEPM paper more
understandable and
to show why certain things are the way they are.
2) Include a few details that we left out of the PEPM paper due to lack
of space.

We cited the TR in the PEPM paper, and therefore thought it would be
nice to finish it
before the conference.  However, we have decided to put off the TR
indefinitely, though
with good intentions to write it eventually.
--Brian


To: chambers@thistle.cs.washington.edu
cc: spin-comp@thistle.cs.washington.edu
Subject: we can unroll k iterations!
Date: Fri, 30 May 1997 11:01:12 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

make_static(constant bytecodes, pc, sp, k, i);
i = 0;
for (;;) {
  if (i++ >= k)
     make_dynamic(bytecodes, pc, sp, k, i);
  switch (bytecodes[pc++]) {
  ...
  }
}

Seems like it should work.

--Brian


Date: Fri, 30 May 1997 11:05:55 -0700 (PDT)
From: chambers@klamath (Craig Chambers)
To: grant@cs.washington.edu
Subject: Re: we can unroll k iterations!
Cc: spin-comp@cs

Interesting.  OK, maybe we can get just as much control (or is it flexibility?)
as `C in terms of specializing exactly where and when and to the extent we 
want.

-- Craig

To: spin-comp@franklin.cs.washington.edu
Subject: Re: we can unroll k iterations!
Date: Fri, 30 May 1997 12:46:45 PDT
From: Matthai Philipose <matthai@franklin.cs.washington.edu>

One way in which our system is more restricted is if the
specialization depends on the internal state of the
specializer... for instance, if we want to say "stop
specializing after 4 units".

The issue seems to be that in our model, the specializer
is a black box, whereas in theirs, the user writes it, and
they can therefore refer to its internal state.
           Matthai


>make_static(constant bytecodes, pc, sp, k, i);
>i = 0;
>for (;;) {
>  if (i++ >= k)
>     make_dynamic(bytecodes, pc, sp, k, i);
>  switch (bytecodes[pc++]) {
>  ...
>  }
>}

>Seems like it should work.

>--Brian


Date: Wed, 4 Jun 1997 17:37:17 -0700 (PDT)
From: chambers@demille (Craig Chambers)
To: spin@demille, spin-comp@demille
Subject: FYI

> From crispin@cse.ogi.edu  Wed Jun  4 16:15:39 1997
> Delivery-Date: Wed, 04 Jun 1997 16:15:48 PDT
> From: crispin@cse.ogi.edu (Crispin Cowan)
> Subject: Synthetix Toolkit Workshop June 20
> To: jis@hpk.hp.com (Jishnu Mukerji), sears@hpl.hp.com (Bart Sears),
>         sontag@cup.hp.com (John Sontag), wilkes@hpl.hp.com (John Wilkes),
>         holly@tis.com (D. Hollingworth), kaos@tis.com (Karen Oostendorp),
>         llp@cs.arizona.edu (Larry Peterson),
>         todd@cs.arizona.edu (Todd Proebsting), dbakken@bbn.com (D. Bakken),
>         rschantz@bbn.com (R. Schantz), tdcl@bu.edu (Tom Little),
>         daniel.jackson@cs.cmu.edu (D. Jackson), roc@cs.cmu.edu (R. O'Callahan),
>         garth+@cs.cmu.edu (Garth Gibson), aurel@ctr.columbia.edu (Aurel Lazar),
>         rvr@cs.cornell.edu (Robbert van Rennesse),
>         mustaque@cc.gatech.edu (Mustaque Ahamad),
>         eisen@cc.gatech.edu (Greg Eisenhauer),
>         schwan@cc.gatech.edu (Karsten Schwan),
>         margo@eecs.harvard.edu (Margo Seltzer),
>         chris@eecs.harvard.edu (Chris Small),
>         islam@watson.ibm.com (Nayeem Islam),
>         jaegert@watson.ibm.com (Trent Jaeger),
>         jochen@watson.ibm.com (Jochen Liedtke),
>         lawrencet@rl.af.mil (Tom Lawrence),
>         staehli@informix.com (Rich Staehli),
>         dirk@mink.jf.intel.com (Dirk Brandewie),
>         carbajal@ibeam.jf.intel.com (John Carbajal),
>         merrow@ssd.intel.com (Tom Merrow),
>         jack_d_mills@ccm.sc.intel.com (Jack Mills),
>         neiger@ichips.intel.com (Gil Neiger),
>         yavatkar@ibeam.jf.intel.com (Raj Yavatkar),
>         kochh@tango-vs1.hanscom.af.mil (Harry Koch),
>         mbj@MICROSOFT.com (Mike Jones), black@opengroup.org (David Black),
>         pauld@opengroup.org (Paul Dale), c.kahn@opengroup.org (Clifford Kahn),
>         suggs@nosc.mil (Charles Suggs), druschel@cs.rice.edu (Peter Druschel),
>         avantil@itd.nrl.navy.mil (Andre van Tilborg),
>         ted.brunner@tek.com (Ted Brunner),
>         mayer.schwartz@tek.com (Mayer Schwartz),
>         chris.tilt@tek.com (Chris Tilt), jeffay@cs.unc.edu (Kevin Jeffay),
>         baford@cs.utah.edu (Bryan Ford), lepreau@cs.utah.edu (Jay Lepreau),
>         chambers@cs.washington.edu (Craig Chambers),
>         eggers@cs.washington.edu (Susan Eggers),
>         gregor@parc.xerox.com (Gregor Kiczales),
>         schwan@cc.gatech.edu (Karsten Schwan), danh@qnx.com (Dan Hildebrand)
> Date: Wed, 4 Jun 1997 16:11:57 -0700 (PDT)
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> 
> You are invited to the Synthetix Specialization Toolkit Workshop to be
> held Friday, June 20th, immediately following the COOTS conference in
> Portland, Oregon.
> 
> This Workshop coincides with the initial release of the Synthetix
> Specialization and Feedback Toolkits. Because this is not a general
> release, this is an invitation-only, early view of the toolkit, allowing
> hands-on evaluation and feedback. These toolkits have been under
> development at OGI and IRISA for the past three years. The
> specialization toolkit assists operating system designers with the task
> of specializing production operating system code. The feedback toolkit
> helps developers build system and application software that adapts to
> dynamic environments.
> 
> Our groups have used the specialization toolkit to significantly improve
> the performance of a broad range of production system code, including
> Linux signal delivery, Sun RPC, the vmalloc memory allocator and network
> protocol processing.
> 
> The feedback toolkit has been used to build a streaming video player
> that successfully adapts to varying network bandwidth and local CPU
> load.
> 
> The Workshop will describe the toolkits and their individual tools, as
> well as demonstrate both toolkits in use. We will discuss many of the
> example applications mentioned above.
> 
> If you are interested in using either toolkit, or are curious about how
> these toolkits could help your work, you are encouraged to attend the
> Workshop.
> 
> More details are provided at the following URL:
> http://www.cse.ogi.edu/DISC/projects/synthetix/workshop/
> 
> The workshop registration form is:
> http://www.cse.ogi.edu/DISC/projects/synthetix/workshop/registration.html
> 
> The workshop will last from 9:30 AM to 4:00 PM, Friday, June 20th. It
> will be held at the Oregon Graduate Institute in Beaverton, Oregon. Due
> to limited facilities, we can accommodate up to 50 participants. There is
> no fee to attend the Workshop.
> 
> We look forward to seeing you on June 20th. If you have any questions
> about the workshop or registration, contact Walt Leyland,
> wleyland@cse.ogi.edu, (503) 690-4073
> 
> Crispin Cowan, for Calton Pu
> 

Date: Wed, 4 Jun 1997 21:37:56 -0700 (PDT)
From: Markus Mock <mock@apex.cs.washington.edu>
To: spin-comp@apex.cs.washington.edu
Subject: equivalence flow functions

Matthai and I came up with the following flow functions for the 
equivalence class problem. They seem to do what we want, however, we 
haven't been able to define a partial order yet that would allow us to 
show that iteration will converge to a solution.
Any ideas?

	-- Markus

Lattice: 
	Pow(Pow(Vars)) representing a set of equivalence sets at each
	program point

Partial order:
	<= = ???

Bottom: {{v1}, {v2} ... {vn}}
Top:	{{v1,v2,..vn}

Meet: 
	M(P1,P2) = {V1 \intersect V2 | forall V1 \in P1, V2 \in P2 and
		 	and V1 \intersect V2 != {}}
	i.e., pairwise intersection of the equivalence sets

	Invariant: each variable occurs in exactly one equivalence
	set, therefore it will also occur exactly once in the set
	computed by the meet


Flow Functions:

	F(x = y) [[{V1, ..  Viy, .. Vn}]] = 
			{Zi | Zi = Vi -{x}, i=0..n, i != iy,
			      Vi-{x} != {}} U  
			{Viy U{x}}
			   where y \in Viy,

			i.e., x is moved from whatever set it is into
			the set where y is. If that makes x's previous
			set  empty, that set is removed (no empty
			equivalence classes)
	


	F(x = y op z) [[{V1,..  Vix, .. Vn}]] =
			{{x}, V1, .., Vix - {x}, .. Vn} if Vix -{x} != {}
			{{x}, V1, .. Vix-1, Vix+1, .. Vn} if Vix -{x} = {}




Example:
		{{x}, {y}, {z}}
	x = y
		{{x,y}, {z}}
	z = x 
		{{x,y,z}}
	z = z + 1
		{{x,y}. {x}}
	x = z 
		{{y}, {x,z}}




	

To: spin-comp@franklin.cs.washington.edu
Subject: Update on equivalence analysis...
Date: Thu, 05 Jun 1997 14:19:32 PDT
From: Matthai Philipose <matthai@franklin.cs.washington.edu>

The problem of convergence of the equivalence-under-copy analysis
is solved; it turns out that the simple partial order we had (see below)
works. When we worked on it yesterday, I was hazy on what "monotonic" meant, 
and Markus was hazy on what our partial order was, because of which we 
couldn't show that the partial order is monotonic! :-)

I thought of another problem while figuring out the
analysis: How are we going to use its results?

The problem is that if we want the equivalence sets to reflect
source-variable equivalence, the analysis needs to happen very
early, probably right after assignment of vars to temps is done.
However, we will use the results only at the end of phase2, after
the CFG has been transformed many times. Will the info computed still
be valid/sufficient? At least two kinds of problems could arise:
1)New stats could be created e.g. in (compile-time) loop unrolling; what 
equivalence
  conditions should be associated with them? The working solution
  here is to use bottom as the equivalence sets for these stats. If 
  test cases show that getting more specific info is important in some
  cases (say in the code produced by unrolling), we can update the 
  info in these stats when they are produced (e.g. just copying the
  info should do the trickin urolling).
2)Stats could be moved to a place where their equivalence-set information
  is no longer valid. Brian had a good observation for this case: the 
  only equivalence set information we care about is the equivalence
  of variables used/defed in the stat. A stat cannot be moved to a 
  point where equivalence info on these variables is invalid (because this
  would mean breaking dependences). So we don't have to worry about
  equivalence sets being invalid.
Since I can't think of any more show-stoppers, I'm going ahead with
implementation of the equivalence analysis. Any further feedback would
be great.
	 
Wish I hadn't been quite so ambitious in setting my schedule at the
last meeting ;-).
		Matthai
	  

----- Partial order:

For two partitions V and U of the vars into equivalence sets:

V = (v1,v2,...vn) <=  U = (u1,u2,...,um)
	iff
	for 1<=i<=n
	there is some 1<=j<=m s.t.
		        vi is contained in or equal to uj 

(intuitively, the  partition V is the result of splitting partition U)

--------FYI, the rest of the lattice-theoretic def (from Markus' earlier 
letter):
Lattice: 
	Pow(Pow(Vars)) representing a set of equivalence sets at each
	program point

Bottom: {{v1}, {v2} ... {vn}}
Top:	{{v1,v2,..vn}

Meet: 
	M(P1,P2) = {V1 \intersect V2 | forall V1 \in P1, V2 \in P2 and
		 	and V1 \intersect V2 != {}}
	i.e., pairwise intersection of the equivalence sets

	Invariant: each variable occurs in exactly one equivalence
	set, therefore it will also occur exactly once in the set
	computed by the meet


Flow Functions:

	F(x = y) [[{V1, ..  Viy, .. Vn}]] = 
			{Zi | Zi = Vi -{x}, i=0..n, i != iy,
			      Vi-{x} != {}} U  
			{Viy U{x}}
			   where y \in Viy,

			i.e., x is moved from whatever set it is into
			the set where y is. If that makes x's previous
			set  empty, that set is removed (no empty
			equivalence classes)
	


	F(x = y op z) [[{V1,..  Vix, .. Vn}]] =
			{{x}, V1, .., Vix - {x}, .. Vn} if Vix -{x} != {}
			{{x}, V1, .. Vix-1, Vix+1, .. Vn} if Vix -{x} = {}




Example:
		{{x}, {y}, {z}}
	x = y
		{{x,y}, {z}}
	z = x 
		{{x,y,z}}
	z = z + 1
		{{x,y}. {x}}
	x = z 
		{{y}, {x,z}}





To: spin-comp@franklin.cs.washington.edu
Subject: used-vars commited
Date: Thu, 05 Jun 1997 18:52:13 PDT
From: Matthai Philipose <matthai@franklin.cs.washington.edu>

The used-vars phase is commited.

The boolean flag -mDGOPT_show_used_vars=true prints out used
vars into and out of basic blocks as part of the dump_graph
routine.
			Matthai

To: chambers@thistle.cs.washington.edu
cc: spin-comp@thistle.cs.washington.edu
Subject: practice talk
Date: Fri, 06 Jun 1997 10:03:02 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

Are we on for a practice talk at 2pm?  How about Sieg 225?  That room has
been pretty empty all week.

--Brian


Date: Fri, 6 Jun 1997 10:52:47 -0700 (PDT)
From: chambers@klamath (Craig Chambers)
To: chambers@thistle.cs.washington.edu, grant@cs.washington.edu
Subject: Re: practice talk
Cc: spin-comp@thistle.cs.washington.edu

Sorry for not responding earlier, as I said I would.  Peter Van Vleet has a
generals I'd like to attend at 1:30.  So how about 2:30?

-- Craig

To: chambers@klamath (Craig Chambers)
cc: spin-comp@thistle.cs.washington.edu, sparekh@thistle.cs.washington.edu
Subject: Re: practice talk 
Date: Fri, 06 Jun 1997 10:54:06 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

>> Sorry for not responding earlier, as I said I would.  Peter Van Vleet has a
>> generals I'd like to attend at 1:30.  So how about 2:30?

Sure.

--Brian


To: spin-comp@cs, grove@cs, mernst@cs
Subject: practice talk by Max Poletto on Friday?
Date: Sun, 08 Jun 1997 23:24:32 PDT
From: Wilson Hsieh <whsieh@tweetie-bird.cs.washington.edu>


Hi everyone, I'm not sure who will be here and who
will be at PEPM; would anyone be interested in hearing
a practice PLDI talk on tcc by Max Poletto on Friday
afternoon?  And do you know of anyone else in the
department who might be interested?
 - Wilson



To: spin-comp@cs, spin-m3@tweetie-bird.cs.washington.edu
cc: t-maxp@microsoft.com
Subject: talk by Max Poletto
Date: Tue, 10 Jun 1997 10:50:30 PDT
From: Wilson Hsieh <whsieh@tweetie-bird.cs.washington.edu>


Hi, Max Poletto is going to give a talk this Friday
at 3:30 in 114; this is a preview of his talk at PLDI
next week.  Below is his abstract.  Max is a student
of Frans Kaashoek's, and is spending the summer working
at Microsoft Research with Chris Fraser and Dave Hanson.
Please forward to anyone here who might be interested.

Unfortunately, I wasn't able to reserve 422, and I'm not
sure how finals schedules may occupy the classrooms on
the 2nd floor.  Please let me know if you're likely to
go, just so I know if we'll need a bigger space.
 - Wilson

-------------------------------------------------------

I will present tcc, a compiler that gives efficient and high-level
access to dynamic code generation.  tcc implements the `C ("Tick-C")
programming language, an extension of ANSI C that supports dynamic code
generation.  `C provides a powerful way of specifying dynamically
generated code, allowing the programmer to create and compose arbitrary
expressions and statements at run time.

The talk will discuss some of the motivations for the language and the
compiler, outline the key parts of tcc's design and implementation, and
provide some performance results.

To: spin-m3@tweetie-bird.cs.washington.edu, spin-comp@cs
cc: maxp@lcs.mit.edu
Subject: visitor schedule for Max Poletto
Date: Tue, 10 Jun 1997 20:37:17 PDT
From: Wilson Hsieh <whsieh@tweetie-bird.cs.washington.edu>


I've created one.  He'll be here around 1pm on Friday.
I'm trying to find a bigger room, just in case.
 - Wilson



To: spin-m3@tweetie-bird.cs.washington.edu, spin-comp@cs
cc: maxp@lcs.mit.edu
Subject: Max Poletto's talk
Date: Wed, 11 Jun 1997 14:33:23 PDT
From: Wilson Hsieh <whsieh@tweetie-bird.cs.washington.edu>



Hi, I've managed to get 226 for his talk on Friday at 3:30.
See you there!
 - Wilson

Date: Thu, 12 Jun 1997 11:05:42 -0700 (PDT)
From: chambers@klamath (Craig Chambers)
To: cecil@cs, spin-comp@cs
Subject: MS intern visit day

On Thurs June 26, a bunch of interns from MS will be visiting the dept, 
from our perspective to get impressed with the interesting stuff going on here
and with the interesting students here, so that they'll want to apply to grad
school here themselves.  We need to work out a half-hour demo show to people
interested in PLs and compilers, to get them excited about work going on here.
Basically, put yourself in the shoes of seniors and think what you would think
was cool and interesting in a quickie visit to a CS dept., and try to give it
to them.  Some blend of little demos, talking from a poster, and just talking
seems right.

I don't know where all this will take place, but I'll let you know more
details as I get them.

Thanks for your help in grad student recruiting.

-- Craig

> From ebeling@edison  Thu May 29 10:20:03 1997
> Delivery-Date: Thu, 29 May 1997 10:20:10 PDT
> Date: Thu, 29 May 1997 10:20:00 -0700 (PDT)
> From: Carl Ebeling <ebeling@edison.cs.washington.edu>
> To: Craig Chambers <chambers@edison.cs.washington.edu>
> Subject: Microsoft Intern Day
> MIME-Version: 1.0
> 
> Craig,
> 
> We're planning to have a bunch of Microsoft interns over to show off
> the department and attract some good people for the graduate program.
> Here is the plan:
> 
> Visit for Microsoft Interns
> Thursday, June 26
> 
> 3:30 some sort of overview intro; very fast; in 134; by Ed
> 4:00 Several parallel sessions in which they SEE STUFF and MEET
>    STUDENTS
> 	graphics / salesin
> 	AI / weld, etzioni
> 	systems / bershad, levy, anderson
> 	etc.
>    These sessions would go a half-hour so we can fit in two copies in
>    the hour we'll have
> 5:00 Reception
> 6:00 Back to Microsoft
> 
> 
> I'm asking you to line up students/faculty to run the demo session for the
> software engineering/compilers group?  If you see a problem with this,
> please let me know right away.
> 
> 
> 
> 
> 

Date: Thu, 12 Jun 1997 17:22:54 -0700 (PDT)
From: Michael Ernst <mernst@fielder.cs.washington.edu>
To: cecil@fielder, spin-comp@fielder
Subject: Advice on writing

Craig Chambers gave some of you an American Scientist article on writing.
I didn't get much out of it -- some of its examples were unambiguous before
rewriting but ambiguous after!  For another perspective, I copied a few
pages of writing tips from the book _Getting What You Came For:  The Smart
Student's Guide to Earning a Master's or PhD_.  Ask me if you want a copy.

					-Mike

Date: Thu, 12 Jun 1997 17:51:47 -0700 (PDT)
From: Michael Ernst <mernst@fielder.cs.washington.edu>
To: cecil@fielder, spin-comp@fielder
Subject: Re: Advice on writing

> Does this say something about the quality of American Scientist?

No.  I subscribe to American Scientist, and it's a good magazine -- better
than Scientific American, which has lately become more an organ for
disparaging its editors' enemies than a bona fide scientific journal.  I
just didn't like this particular article.

					-Mike

To: Susan Eggers <eggers@pa.dec.com>
cc: spin-comp@cs
Subject: PEPM report
Date: Tue, 17 Jun 1997 16:31:17 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

>> I'd like to know the reaction to the system capability as a whole,
>> but I assume that will be part of your general report.

I guess I'll make this message into my report and write something a little
different for ONR.

High-level: I had a good time at PEPM, but it was too short.  Most people
attended most of the talks, at least during the time that they were at the
conference site, so there wasn't enough time outside the talks to talk to
other people.  Fortunately, I managed to meet some people from the
conference at lunch and dinner on Thursday and Friday.

Because we were part of the last session, we didn't have much opportunity
to talk to people after our talk before everyone scrambled to leave.  Nobody
asked any hard or particularly deep questions (e.g., about alias analysis,
safety, comparisons with `C, or applications).  There was one question about
code explosion and a couple other minor questions.  So, it was difficult to
tell how the general PEPM audience felt about the system.  I talked to a few
people who were interested in the idea of run-time code generation, but had
no specific comments about our system.

Consel seemed impressed, but I didn't have much time to talk to him.  Hornof
mentioned that there were some specific aspects that Consel liked, but I
wasn't able to find out which those were (because of time).  Consel seemed
concerned about code explosion when doing intraprocedural polyvariant
specialization and division because their system doesn't have policies
to control it.  Consel, Hornof, and Marlet seemed interested in
supporting "entry points" within functions, but at least Marlet held the view
that inserting annotations into the actual source code "tainted" it somehow.
So, they would have to introduce labels to support this, which seems no
better to me, except that the source code would still be valid C code.  Also,
their caching & reuse still isn't automatic.  They still have to
manually alter the source code to invoke the specializer and call the
specialized function that is returned.  The caching was another aspect of our
system that Consel and Marlet liked.

FYI, the Sun RPC application has driven much of the work on Tempo.  It has
lots of small functions, at most requires single-way unrolling, and is
well suited for compile-time specialization.

Hornof, Noye, and Volanschi plan to leave the group by the end of 1997.
They are planning a release of Tempo before then.  Schultz, a student of
Danvy, will join the group this fall.  He will work on Harissa (their Java
specializer), I think.  He thought our system sounded pretty cool, but isn't
yet familiar with Tempo's details.

Consel didn't think much of run-time register allocation, but I don't know
why.  We had to part ways just at the moment when this topic came up.  He
started to say something about leaves(???).  I'll have to ask him in e-mail.
:-)

Tim Sheard and Walid Taha of OGI have developed a neat system for
multi-stage programming called MetaML, which I think of as "Tick ML". :-)
It's a much cleaner system than `C.  They've extended the ML type system to
support code types, and their multi-stage extensions to the language are
statically typed.  They support arbitrarily many stages (think nested tick
expressions) and also have some type-directed PE.  The "code" that they
generate at run time not executable, however, but is interpreted.  A nice
feature of their system is that their multi-stage programs can be trivially
converted to legal ML programs (by using closures), and that multi-stage ML
programs aren't written in too different a style from ordinary ML programs.
Walid (a student) was very interested in our system, in particular the way
in which we interleave execution and specialization to achieve multi-stage
execution.  By the way, there were at least a dozen people from OGI at ICFP
and PEPM.  I met Jim Hook, Tim Sheard, Walid Taha (of MetaML), Buck Krasic
(of Synthetix), and a few other students.

The talk on "PE & separate compilation" was nearly incomprehensible.

There wasn't much additional insight on "Resource-Bounded PE", other than
what was discussed in 590k.  We had breakfast with the author.  It seems to
be a side project for him.  He may never implement anything.  It still isn't
clear how he could unroll a loop if he had already specialized N iterations
of the loop before running out of resources.  He admitted that it was a hack.
He wrote a script to do the unrolling when he knew there wouldn't be enough
space.  It isn't clear how to apply his idea of an accountant that alternates
with the specializer to our system.  The accountant can change arbitrary
binding times, which someone in the audience pointed out isn't compatible
with generating extensions, which have already set the binding times in stone.
We could implement a limited version of his idea using conditional
specialization (e.g., not unroll if we estimate the fully unrolled loop won't
fit in the cache).

There were a few interesting talks about applications of PE.  One was even
an application of run-time specialization!  All three talks on applications
applied relatively simple PE techniques to achieve impressive speedups (in
addition to Marlet's talk on applying Tempo to Sun RPC).  Two involved run-
time code generation.  These were:

-- 3D visualization environment for multivariate functions: used memoization
   to reduce computations redundant across successive frames and dynamic
   compilation to specialize subcomputations of the function being viewed
   (3D slices of higher-dimensional functions)

-- Dynamic hardware specialization: specialized FPGA circuits at run time
   (this was the invited talk was given by Satnam Singh, with whom I had
   lunch at the SmallTalk cafe; he's a funny guy)

In both of these cases, simple, special-purpose specializers of functional
languages were used at run time.  But, applications similar to the
visualization tool could be possible targets for our system.  In fact, most
of that application is written in C++ and at run time they:
	1) create a functional specification (subset of Scheme) of the
	   visualization
	2) apply a partial evaluator to the Scheme source
	3) generate C source code
	4) compile the C source
	5) dynamically link in the resulting object file

The other talks were of less immediate interest.  I went to all but 2 talks.

I also met Neil Jones, Olivier Danvy, and Peter Thiemann, but didn't have
substantive conversations with them.  Steensgaard and Knoblock (from MS)
happened to show up briefly.  I didn't get to talk to Reps, Shivers,
Jorgensen, or Mogensen.

That's enough for now.  Let me know if you have any questions.

--Brian


To: spin-comp@thistle.cs.washington.edu
Subject: addendum to PEPM report
Date: Tue, 17 Jun 1997 16:56:44 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

I forgot something important!

1) The Tempo group expressed interest in developing a pool of common
benchmarks so that we can more easily compare our systems.

2) The Tempo group is primarily targetting systems code for their run-time
specializer, but they don't have any killer apps yet.  Most of their work
has been on the BTA and the compile-time specializer (for Sun RPC).

--Brian

Date: Thu, 19 Jun 1997 12:11:30 -0700 (PDT)
From: chambers@klamath (Craig Chambers)
To: spin-comp@cs
Subject: no meeting monday; new meeting time?

Since we have so many absences, let's not meet on Monday.  Also, we need to
pick a new meeting time for the summer qtr.  I have a 1pm commitment Mondays.

-- Craig

To: spin-comp@thistle.cs.washington.edu
Subject: need another piece of info from the BTA
Date: Thu, 03 Jul 1997 09:25:38 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

It would be handy if the BTA could also output a set DemotedVars along with
PromotedVars.  The DemotedVars would be live static variables that become
dynamic.  The reason is that we need to insert an assignment or load to make
sure the correct value carries past the end of a variable's dynamic region.

--Brian

To: spin-comp@thistle.cs.washington.edu
Subject: more to think about when implementing the BTA
Date: Thu, 03 Jul 1997 16:59:42 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

-- Don't run directly off the annotations; have a prepass insert your own
   representation for make_static and make_dynamic
	-- When we do clustering, we'll need these to be easy to create,
	   destroy, and move around

-- Reachability conditions (RC) need to be part of the BTA output
	-- Make it possible to turn this analysis on and off with a
	   command-line switch
	-- It needs to be modified or rewritten to handle IGOTOs
	-- We'd like to be able augment the concept of static merges with
	   something more general: use the RC to determine which definitions
	   are truely discordant (this doesn't have to be in the first cut,
	   but think about adding it later)

-- Separate StaticVarInfo and RC from single-program-point info (PromotedVars,
   DemotedVars, DiscordantVars) in the BTA's output
	-- I introduce STATs for which I need to copy the
	   StaticVarInfo, but not PromotedVars, etc.
	-- I need to move PromotedVars, DemotedVars, and DiscordantVars
	   when doing clustering and restructuring
	-- I also need to be able to move "voluntary" lazy edges, which
	   should be permitted anywhere, not just following branches

-- We should have a pointwise user-level lazy annotation for testing
   purposes

-- We'll need promote_one_unchecked_eager (as from the early paper draft)
   in order to kill bogus MayDefVar promotions

-- Think about how you'll replicate control-flow paths for each division;
   Partition and an iterator should be all that you'll need

-- Think about how we can make the BTA incremental: if I move make_static,
   make_dynamic, promotions, or demotions, I'd like to be able to rerun the
   BTA on just the part of the graph that needs to be updated (stop when
   the sets being computed are the same as the previous results?)

-- Make all BTA output easily accessible, preferably through accessor
   functions; in particular, I need the following functions:
	-- Returns the size of the StaticVarInfo set (I'll assume
	   0 means the STAT won't be specialized)
	-- Iterates over the StaticVarInfo set (e.g., I need to be able to
	   to create a load for each static variable)
	-- Ditto for PromotedVars, DemotedVars, and DiscordantVars
		-- Size
		-- Iterator
	-- Returns the cache policy for a static variable
	-- Determines whether an operation is static
	-- Determines whether two edges have mutually exclusive static
	   reachability conditions
	-- Indicates whether an edge is voluntarily lazy (doesn't need to
	   check PromotedVars)
	-- Sets an edge to be voluntarily lazy or not
	-- Returns a STAT's or BBLOCK's initial BTA output
	-- Returns a STAT's or BBLOCK's final BTA output
	-- Copies StaticVarInfo and RC pieces of the BTA output and returns
	   BTA output structure with empty PromotedVars, etc.
	-- As mentioned above, eventually I'd like to be able to create,
	   destroy, and move annotations, promotions, and demotions

--Brian

To: spin-comp@thistle.cs.washington.edu
Subject: hit dead end with old BTA
Date: Thu, 03 Jul 1997 17:16:43 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

I can't easily go further with the old BTA, for a number of reasons:
	-- crashes whenever there are merges within the dynamic region
	-- incorrectly set contexts
	-- unidentified autopromotions
	-- old-style cache policies

Matthai should finish the merger update tomorrow, after which we should be
able to test the full pipeline for the single-basic-block region.  Woo hoo!

Before that's finished and after that example works, I'm going to start
working on things farther down my list.  These are things that are still
important, but aren't really on the critical path.  I probably won't be
able to port to the new BTA until the middle or end of next week, when more
of the interface has been specified.

After Markus returns, if he/we can quickly fix the crashing at merges, I
might be able to do more multi-unit testing with the old BTA.  Otherwise, it
will probably be a couple weeks (?) before the new BTA is stable enough for
more extensive testing of my code.

--Brian


To: spin-comp@franklin.cs.washington.edu
Subject: Meeting?
Date: Mon, 07 Jul 1997 11:27:39 PDT
From: Matthai Philipose <matthai@franklin.cs.washington.edu>

Since Markus is back, we should decide on a meeting
time.

I'm free all day, every day. This time, I would prefer
an end-of-the-week meeting day, say Friday. My brain
doesn't work well at the beginning of the week. :-)
			Matthai

Date: Mon, 7 Jul 1997 11:35:26 -0700 (PDT)
From: chambers@klamath (Craig Chambers)
To: spin-comp@franklin.cs.washington.edu, matthai@cs.washington.edu
Subject: Re: Meeting?

Let's meet at 3pm either Thursdays or Fridays.

-- Craig

To: spin-comp@franklin.cs.washington.edu
Subject: meeting-time
Date: Mon, 07 Jul 1997 15:38:18 PDT
From: Matthai Philipose <matthai@franklin.cs.washington.edu>

Based on further input from Markus and Brian,
the dynamic compilation meetings will be Thursdays 3:30
in Craig's office.
		Matthai

------- Forwarded Message

Date:    Mon, 07 Jul 1997 11:35:26 -0700
From:    chambers@klamath (Craig Chambers)
To:      spin-comp@franklin.cs.washington.edu, matthai@cs.washington.edu
Subject: Re: Meeting?

Let's meet at 3pm either Thursdays or Fridays.

- -- Craig


------- End of Forwarded Message



To: spin-comp@franklin.cs.washington.edu
Subject: correction: meeting time
Date: Mon, 07 Jul 1997 16:01:12 PDT
From: Matthai Philipose <matthai@franklin.cs.washington.edu>

The meeting is at 3:00pm Thursdays, as per Craig's original suggestion.
My previous mail said 3:30pm.
	Sorry,
	Matthai

Date: Thu, 10 Jul 1997 14:15:59 -0700
From: garrett@cs.washington.edu
To: spin-comp@cs.washington.edu
Subject: meeting

I'll come in to today's meeting.

See you at 3.

--
Charlie

To: eggers@pa.dec.com
cc: spin-comp@thistle.cs.washington.edu
Subject: meeting minutes
Date: Thu, 10 Jul 1997 21:47:50 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

We're close.  Matthai has made most of the necessary merger modifications,
and I've completed most of the details needed to get the system working
(e.g., initializing various pointers and counters).  The last remaining
sticky point is getting the generating extension to correctly jump to the
stitched code.  Currently, that is implemented as a hacked return in the
Multiflow IR, followed by a jump.  The return is returning to the wrong
location, however.  That should be fixed or worked-around tomorrow.  Otherwise,
the merged code for our small (~5-6 instructions) single-unit/single-block
test case looks good and generates correct code when run.

I spent most of today struggling with the debugger and cpp.  The line
numbers in more and more files have been getting out of sync, making
debugging difficult.  By today, it became intolerable (line numbers in 3
files I needed to debug were hundreds of lines off, making setting of
breakpoints, single-stepping, etc. impossible).  So, I tracked it down.
The bug is due to the program Multiflow uses to expand its special loop
constructs (iterators).  It drops some line-number directives emitted by
cpp.  Matthai and I came up with a possible work-around.  I'll let everyone
know tomorrow if it works.

Matthai and Markus:

        -- Markus is now back from PEPM and is getting back to work.  He
           fixed a bug in the old BTA yesterday so that I could get back to
           debugging multiple units.  He is trying to finish the BTA "helper
           functions" (as defined in the paper) and should be able to hash
           out the flow functions as well by next Thursday.  Debugging, of
           course, will follow.

        -- Matthai has been debugging his BTA prepasses, most recently
	   the equivalent-variables analysis.  We need to keep track of
	   which source-level variables various temps created by Multiflow
	   correspond to so that we know how to apply the annotations.
	   We're planning to compute this information early and keep it
	   around at every IR statement.  That takes lots of memory and
	   Matthai found that his initial implementation caused Multiflow
	   to run into memory problems when run on larger files.  So,
	   he reimplemented it to be more careful with memory usage.  That
	   is nearly done and, I think, he will move on to other parts of
	   the BTA (reachability analysis, finding lazy branch successors,
	   replicating a path for each division, etc.).  He will also work
	   on the merger as needed.

We're all supposed to be thinking about applications and angles on the
PLDI paper as well.

--Brian

To: spin-comp@thistle.cs.washington.edu
Subject: URGENT! CVS problems
Date: Fri, 11 Jul 1997 13:40:32 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

Please don't check things into or out of CVS until further notice.  I just
did an update and my source tree has been corrupted, apparently partially
rolled back by a few weeks.

I'll keep you posted.

--Brian

To: spin-comp@thistle.cs.washington.edu
Subject: CVS fixed; new major revision: 2.0
Date: Fri, 11 Jul 1997 16:22:37 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

I was able to recover my files from a separate branch I checked in this
morning and from my emacs buffers.  For some reason, CVS reverted my files
to the old versions instead of merging into the main branch as it was
supposed to do.  How it can let an older version overwrite a newer one,
I don't now (there were no updates to the main branch since I forked
off this morning).

I have committed all of my files as version 2.0.  Before you check out this
version, you may want to first backup your changed files.  Then do:
cvs update -d -A

Let me know if you have problems.

This version includes a totally new BCC script that automatically replaces:
DYC_LND;
with line-number directives.  So, just insert these anywhere line numbers are
screwed and you want to debug - even inside LOOP nests!  Matthai and I had a
few important insights yesterday:
	-- Maintaining the line numbers manually would be painful
	-- Inserting directives automatically is very hard because of
	   conditional compilation (#ifdef's)
	-- Inserting them by hand but maintaining them automatically sounded
	   like the right solution
	-- If they don't look like line-number directives loop won't strip
	   them out
So, BCC first appends line numbers to the "DYC_LND;" tags, then passes the
program through cpp and loop, and finally converts the tags to real
line-number directives.  Because of these extra steps, BCC is somewhat slower.
Another glitch is that gcc expects the file names of the preprocessed and
compiled files to be the same, so I have to move the original source file
and put a processed verion in its place, then move the original file back.
Consequently, if you interrupt BCC, it may leave a source file out of place.
I'm working on a fix for this, but if you do have to interrupt do_make, do a
find . -name "*.BCC" -print
The *.BCC files are the originals.  No more than one should exist.  Move
them back to their original names.  I guess I could also write a script to
do that...

Let me know if you have questions.  I have tried it with gdb -- it seems
to work.  I also used the new BCC script to recompile my entire tree, so it
seems robust.

--Brian


Date: Tue, 15 Jul 1997 16:12:36 -0700 (PDT)
From: chambers@klamath (Craig Chambers)
To: cecil@cs, spin-comp@klamath
Subject: some dissertation advice

Olin Shivers has some good advice on focus for theses, that I just came across.

http://www.ai.mit.edu/~shivers/diss-advice.html

-- Craig

Date: Wed, 16 Jul 1997 10:48:52 -0700 (PDT)
From: Markus Mock <mock@apex.cs.washington.edu>
To: spin-comp@apex.cs.washington.edu
Subject: SIGPLAN PAC Report for PEPM 97

Here's the joint (Mihnea Minescu and myself) report for SIGPLAN.


	-- Markus

======================================================================

                           PEPM 97 - A Trip Report
                                     by
                               Markus U. Mock
                              Mihnea Marinescu

Participating in PEPM 97 (aka. ACM SIGPLAN Symposium on Partial Evaluation.
and Semantics-Based Program) held June 12-13, was both fun and instructive.
This year the symposium was coupled with the ICFP conference, both being
held in the city of Amsterdam. This provided an opportunity to attend both
conferences and to meet people with related research interests. This was
beneficial especially given that some papers presented at ICFP during the
last day were centered on partial evaluation techniques. Coming to PEPM
itself, one would remark the density of the conference due to to the short
duration of only two days (well, almost!). Especially day one going from 9am
to 6pm was very long and intense. Instead day two ended at noon with most
people leaving immediately after the last talk cutting down the time
available to interact with other attendees. Apart from that, the
organization of the conference was excellent and without glitches.

The papers presented showed the level of maturity of the domain and the wide
variety of languages to which program specialization techniques can be
applied. There were a number of talks on Partial Evaluation (PE) of
languages with side effects, as well as talks on PE of concurrent languages.

The talk titled "Partial Evaluation of Call-By-Value Lambda-Calculus with
Side-Effects" presented an approach where side-effect analysis was used to
extract immutable data structures, separating mutable and immutable data
structures and turning the program into two parts, the functional and
side-effecting part. Then an online partial evaluator interpreted functions
recursively. Accesses to immutable data structures can then be reduced.
Using their approach, Asai, Masuhara and Yonezawa were able to specialize
real Scheme programs with side effects such as an interpreter.

Several talks presented significant effective results regarding the partial
evaluation of ordinary C programs. Luke Hornof's talk was on "Accurate
Binding-Time Analysis for Imperative Languages: Flow, Context, and Return
Sensitivity". The term flow sensitive BTA is used for what is known in the
literature as program-point specific BTA and the term context sensitivity
for polyvariant BTA. However, the return sensitivity seems to be a new
technique that can lead to a better binding-time separation of values in
functions with side effects. The main application that has driven the design
of their BTA was the specialization of SUN RPC, which they managed to speed
up by successfully partially evaluating it.

Another talk on C-programs specialization, entitled "Annotation-Directed
Run-Time Specialization in C" was given by Brian Grant and Markus Mock from
the University of Washington, Seattle. They described a complex dynamic
compilation system for the C language in which a specialized specializer is
generated for each dynamically compiled code region. Their system is based
on annotations (a declarative annotation language is defined) and relies
heavily on quite sophisticated static analysis and specialization
techniques.

Tim Sheard presented a "Type-directed, On-line, Partial Evaluator for a
Polymorphic Language", extending an idea by Oliver Danvy. In this work types
are used to control the PE of a simply-typed language based on lambda
calculus.

Walid Taha presented his joint work with Tim Sheard on "Multi-Stage
Programming with Explicit Annotations". Their approach is to extend the (ML
in this case) type system to support code types, and their multi-stage
extensions to the language are statically typed. This allows for arbitrarily
many specialization stages in some form of type-directed PE. The "code" that
they generate at run time not executable, however, but is interpreted. A
nice feature of their system is that their multi-stage programs can be
trivially converted to ML programs, by using closures, and that multi-stage
ML programs aren't written in too different a style from ordinary ML
programs.

Ulrik Schultz presented a technique called Lambda Dropping which allows to
transform recursive equations into programs with block structure. While
interesting in its own right, Ulrik showed how it can be used for Partial
Evaluation when programs are first transformed to recursive equations, then
partially evaluated leading to functions with often many formal parameters.
Instead of compiling these directly which are not handled efficiently by
most compilers lambda dropping is applied first converting these functions
back to nested functions with local variables and a smaller number of
parameters facilitating simpler compilation thus enabling better object
code.

Flemming Nielson's talk was on "Prescriptive Frameworks for Multi-Level
Lambda-Calculi". Coming from the author that has developed the concept of a
multi-level language, this presentation attempted an alternative
formalization (well, in fact two formalizations) that are intended to be
used across all applications of multi-level languages from abstract
interpretation to partial evaluation and code generation.

Mihnea Marinescu presented an interesting application of Partial Evaluation
to Concurrent Programs. Using a CSP-based language that, however, separates
data transfer and synchronization operations, the authors manage to
specialize concurrent programs, both with an online and offline PE system.
It would be interesting to examine how effective the approach is for the
removal of redundant synchronization operations, and if it leads significant
speed-ups of certain parallel and distributed applications.

David Melski gave a very good talk on "Interconvertability of Set
Constraints and Context-Free Language Reachability" in which he showed that
the two problems are equally difficult. It was a little off the mainstream
theme of the conference, however, insofar relevant as it showed that some
program analysis problems are unlikely to be solved in better than O(n*n*n)
time.

The invited talk by Satnam Singh "Dynamic hardware specialization:
specialized FPGA circuits at run time" was very lively and showed how even
very simply PE could lead to big speedups. He is applying specialization
techniques to FPGAs, i.e. dynamically reprogrammable logic circuits,
partially evaluating the circuits given that certain input values are known.
For instance. a general adder might be used with one of the two inputs being
1, i.e. as a counter. Using PE the FPGA circuit will simplify to a much
smaller and faster circuit because many redundant gates can be replaced by
simply wires.

An issue that has been ignored by most PE work but may become of major
interest was raised by Saumya Debray's presentation of "Resource-Bounded
Partial Evaluation". While in theory PE should always lead to better
performance, on real computers this might not always be the case due to
resource constraints. For instance, if specialized programs get too large,
they no longer fit into caches and hence performance will degrade compared
to smaller, less specialized programs fitting entirely in the cache. In
Debray's model the BTA is performed off-line and is separated from the
specialization. An additional component, the accountant, decides on-line
(i.e. at run-time), based on the available resources, to specialize a piece
of code. By hand-simulating his algorithm on convolution and matrix
multiplication, Debray showed that the accountant prevented slowdown,
although it sometimes backed off too early leading to a speedup of 1 where
resources would still have permitted a higher speedup. It is not clear,
however, to which extent this performance improvement

   * is due to the replacement of an off-line decision (call it BTA) with an
     on-line decision (call it accountant) or
   * is due to the replacement of a decision based on data availability
     (call it BTA) with a decision based on resource availability (call it
     accountant).

Debray also showed that optimal resource bounded specialization is
NP-complete, leaving room for good heuristics that will perform well in
practice where more complicated resource models than the one that he
considered will come up.

Those were some of the talks at PEPM'97 commented by one or the other of the
authors of this report. We left with the only regret that it lasted only for
one and a half days. For future PEPM conferences it might be worthwhile to
reconsider the format in order to give more time for mingling and BOF (birds
of a feather) sessions, which were missing, unfortunately.
----------------------------------------------------------------------------

Markus U. Mock (e-mail: marinesc@cs.washington.edu ) is a third year
graduate student in Computer Science at the University of Washington,
Seattle. He's currently working on run-time code generation as a member of
the Dynamic Compilation Group of the Department of Computer Science at UW.
His other research interests are compilers, programming languages, parallel
computers and networks.

Mihnea Marinescu (e-mail: marinesc@cs.nyu.edu ) is a graduate student in
Computer Science at New York University. His main research interests are
static analysis and source-to-source program transformation (mainly for
concurrent systems) as well as (meta)text processing, information extraction
and retrieval.


Date: Thu, 17 Jul 1997 11:56:31 -0700 (PDT)
From: chambers@klamath (Craig Chambers)
To: spin-comp@cs
Subject: cancel meeting today?

Can we cancel (or I skip) today's meeting?  I have three papers due today or
tomorrow.

-- Craig

Date: Thu, 17 Jul 1997 12:00:22 -0700 (PDT)
From: Markus Mock <mock@apex.cs.washington.edu>
To: Craig Chambers <chambers@klamath>
cc: spin-comp@cs
Subject: Re: cancel meeting today?

Ok with me.


	-- Markus


To: spin-comp@franklin.cs.washington.edu
Subject: Summary for the week.
Date: Thu, 17 Jul 1997 12:41:03 PDT
From: Matthai Philipose <matthai@franklin.cs.washington.edu>

Folks,
Here's what I did the last week.

I continued working on the equivalent-variable analysis. The
challenge is to propagate information from the analysis
(which happens very early so that source-variable information
is not lost before it) to the BTA (which happens very late so that
basic-block structure is not altered after it).

I finished an implementation of a memory-efficient version of
the analysis, which computed the right result for our small
test program and for the (larger) dinero function. However,
I ran into a stumbling block, because it turns out that the
multiflow CSE phase translates the CFG structure into its own
IR, operates on it, and spits back a modified CFG structure.
We therefore needed to somehow transfer equiv-var information from
the input CFG to the output CFG.

After a lot of initial angst and code-examining, I determined that
the CSE IR has certain nodes that correspond one-to-one with the
input and output CFG statements. I added code to transfer equiv-vars 
information
through these nodes. The code was a bit dicey to get right, because
the nodes are not created in a central place in the CSE module, but
I now think I have all the cases squared away, modulo extensive
testing. I haven't yet tried the transfer-scheme with the large
dinero function, but it  works with our small test case i.e. 
the information is propagated unhindered __to the BTA__!

Seems that we're almost there with the pre-passes. Once I test with
the big dinero function, and do a bit of other cleaning up, I will
write the abstract interfaces to the pre-pass information. Markus
will specify this interface. This work should "definitely" be
done by early next week, if Multiflow so wills it!

		Matthai

		Matthai






To: spin-comp@franklin.cs.washington.edu
Subject: Equivalent-variable analysis seems to work...
Date: Thu, 17 Jul 1997 17:40:07 PDT
From: Matthai Philipose <matthai@franklin.cs.washington.edu>

...I've tested it on the update() function of dinero too.

Pending further testing, I will move on to nailing down
the abstract interfaces to the pre-passes with Markus and 
implementing them.

I will  update and commit my work to CVS by tomorrow noonish.
	Matthai

To: spin-comp@franklin.cs.washington.edu
Subject: equiv-vars commited
Date: Fri, 18 Jul 1997 11:42:21 PDT
From: Matthai Philipose <matthai@franklin.cs.washington.edu>

I just committed the  equiv-vars analysis and related changes.

There's one change to the interface to the compiler. You now
need to set an environment variable DYC_BCC to pathname of your
BCC script.

For example, I added the line:
setenv DYC_BCC /afs/cs.washington.edu/project/dyncomp/matthai/DyC/bin/BCC

to my .cshrc. In general, given our CVS setup, you'll probably need to add:
setenv DYC_BCC /afs/cs.washington.edu/project/dyncomp/<user_name>/DyC/bin/BCC

		Matthai


To: spin-comp@thistle.cs.washington.edu
Subject: progress report
Date: Fri, 18 Jul 1997 16:57:21 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

I finally got the returns from generating extensions to be emitted
properly.  It was much trickier than I expected.  I couldn't get Multiflow
to not remove code I was inserting, so I decided to let the merger insert
the code.  However, this meant I needed to pass information through 4
different IRs to get it to the merger.  I had to trace the generation of
spill code through the back end to do this, but it now works.  I also needed
to stop Multiflow from emitting certain instructions, which I eventually
succeeded in doing.

So, all that remains is one simple addition to the merger and we should be
able to get this trivial test program to correctly produce and run
dynamically generated code.  Woo hoo!

There were also several problems this week: the line-numbering problem and
fix (via the new BCC script), the CVS troubles, servers being down for a day,
and, last but not least, the hard drive on my home PC crashed (permanently).

Next week, I'll get back to debugging multiple units.

--Brian

To: spin-comp@thistle.cs.washington.edu
Subject: FYI: Edge order in Mflow
Date: Wed, 23 Jul 1997 12:04:47 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

Previously, I had thought that the order of successor edges in Multiflow
were "reversed".  That is, the first node in the successor list was for
the "false" branch and the second corresponded to the "true" branch.  I
thought switch cases were similarly in reversed sorted order.  It is
true that the front end reverses the order, however,
ph12_Set_Bblock_Preds_And_Succs() reverses the order again at the beginning
of phase 2.  So, the edges are in the "correct" order after the second
reversal: True, then False.  I've fixed the IL-2 DG_Dump_Graph() routine to
label the edges of the dot graph correctly and checked it into CVS.

--Brian

To: spin-comp@franklin.cs.washington.edu
Subject: how to use the merger.
Date: Thu, 24 Jul 1997 17:13:47 PDT
From: Matthai Philipose <matthai@franklin.cs.washington.edu>

Folks,
Just a note on how to use the merger. The nerger driver-script, 
stitch.pl, is in your CVS bin subdirectory. 

Suppose test.s is the file generated by multiflow
containing code for dynamic region(s).

Invoke the merger:

	stitch.pl test.s > test.merged.s

Now just compile and link with the library functions;
(dycrt.c should be in the lib subdirectory of your cvs tree):

	cc test.merged.s dycrt.c -o test.merged.x

test.merged.x is now an executable that dynamically
compiles!
		Matthai

To: eggers@pa.dec.com
cc: spin-comp@franklin.cs.washington.edu
Subject: first dynamically compiling program!
Date: Thu, 24 Jul 1997 17:22:47 PDT
From: Matthai Philipose <matthai@franklin.cs.washington.edu>

Susan,
Earlier today, we got the first program to pass
through our system completely automatically. It
was a single unit, single basic block dynamic 
region (see below). We still used the old (pre-PEPM)
BTA, and  need to integerate the new one. 

Markus is continuing work on the new BTA. 

Brian has moved on to debugging multiple units.

I have finished work on the pre-passes and
am moving onto gathering, annotating and
testing applications.
		Matthai


------
#include <stdio.h>

main(argc, argv)
    int argc;
    char *argv[];
{
    int x, y, z;

    x = atoi(argv[1]);
    y = atoi(argv[2]);

    dynamicRegion {
  keepConst(x);
  if (x < 0)
      x = - x;
  z = 10 * x + y;
    }

    printf("z = %d\n", z);

    return;
}


To: Matthai Philipose <matthai@cs.washington.edu>
Cc: eggers@pa.dec.com, spin-comp@franklin.cs.washington.edu, eggers@pa.dec.com
Subject: Re: first dynamically compiling program! 
Date: Thu, 24 Jul 97 17:32:34 -0700
From: Susan Eggers <eggers@pa.dec.com>

YES!
OpenGL, here we come.

Susan


To: spin-comp@thistle.cs.washington.edu
Subject: new dyc2c script checked in
Date: Wed, 30 Jul 1997 14:22:14 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

It is under the name dyc2c-ms.  It should be able to cope with PEPM-style
make_static and make_dynamic annotations.  It also takes an option "-noop",
which indicates that the annotations should be removed.

Note that the first line of your .DyC file must be blank (as in empty).  This
is where the #include for our run-time library will be inserted.  If the
first line isn't blank, the script will tell you.

--Brian

Date: Wed, 30 Jul 1997 16:36:58 -0700 (PDT)
From: chambers@klamath (Craig Chambers)
To: cecil@cs, spin-comp@cs
Subject: more travel

For the record, I'll be gone on vacation (plus a side trip to IBM Watson) 
August 19-Sept. 8.

-- Craig

To: spin-comp@franklin.cs.washington.edu
Subject: Abstract interfaces to pre-passes
Date: Tue, 05 Aug 1997 19:18:15 PDT
From: Matthai Philipose <matthai@franklin.cs.washington.edu>

Below are the interfaces to the prepasses to the bta.
They are intended primarily for Markus, who is implementing the bta.

I'm sending this to spin-comp only so that it gets
archived in the mail archive and can be readily looked
up by whoever needs it.
             Matthai
      
------------------
Markus,
Here are the abstract interfaces to the prepasses.
Let me know if you have have questions.

---------------- Summary of how pre-pass info is used (details beyond the PEPM 
paper):

Our understanding right now is that the StaticVarInfo
datastructures will contain TEMP->(policy,source_root) mappings. 

The SourceRoots should be VARs.

The Promotion and DiscordantVar sets will both contain TEMPs that need
to promoted/are discordant at program points.

The Divisions on the other hand will map VAR->policies.

At each make-static(x_i), we identify the x_j equivalent to x_i
(from the equiv-vars set below) iterate through the live temps to 
identify the corresponding temp t_x_j and put it into the 
static-var-info set, as derived static temps with x_i as the source var.

t_x = .... results in t_x getting promoted iff x has the right policy
     (autopromote) in each divisions.

--------------------numbering of   VARs:

Given a VAR "var" you can determine if it is a source-level
variable by the function (all variables annotated to temps... see
next section... are guaranteed to be source-level vars; so you should
never have to use this test):
      BOOL VAR_Is_Source_Level(VAR var) (declared in symtab/val_pack.H)

Given a source-level variable "var", you can get its number by
the macro:
      INT VAR_number(var)              (declared in symtab/val_pack.H)

Given the number "num" of a source-var, you can find the corresponding
var by the function (if no corresponding var exists, it returns NULL):
      VAR VAR_Get_Var_From_Var_Number(INT var_num); (declared in  
symtab/val_pack.H)

--------------------correspondence between temps and VARs:

Given a temp "temp", the source-level variable to which it 
corresponds can be obtained by the macro (defined in symtab/val_pack.H)
      VAR TEMP_source_var(temp)

--------------------makestatic/makedynamic annotated variable:

Given a source-level stat "stat", the VAR that is being made
static at this stat can be obtained by the macro:

VAR STAT_dyc_annotation_var(stat) 
The macro returns a NULL if no var is being made static.


--------------------used-vars:

Given a STAT "stat" you can get a bitset of vars used at the program
pt. before the stat ("used_in_stat") by:
EXTERN BS UV_UsedVars_In(BS      used_in_set,
			 STAT    stat
			 );

...and after the stat ("used_out_stat") by:
EXTERN BS UV_UsedVars_Out(
			  BS      used_out_set,
			  STAT    stat
			  );

Both functions are declared in p2used_vars/p2used_vars.H

--------------------live-temps:

Given a stat you can get a bitset of temps live at the program
pt. before the stat by:
EXTERN BS LT_Live_In(BS live_temps_in_set,
		      STAT    stat
		      );

...and after the stat by:
EXTERN BS LT_LiveVars_Out(
			  BS      live_temps_out_set,
			  STAT    stat
			  );

Both functions are declared in p2live_temps/p2live_temps.H

------------------may-def-vars:

This set is empty at every program point in the multiflow implementation
of the PEPM equations, since may-defs are taken into account explicitly
by the introduction of loads from may-defed values before their next
use.

-------------------equiv-vars:

The following function computes equiv-vars info and attaches it to every 
stat earl in phase2. I have already put in an the invocation, and you don't
need to worry about invoking the function:
EXTERN VOID EV_Compute();

The abstract interface to equiv-vars is through the iterator:
		FOR_EACH_VAR_EQUIV_TO_VAR(stat,orig_var,equiv_var)
which is defined in p2equiv/p2equiv.H.


Given a stat and a source-level variable orig_var, this iterator steps
through every source-level var equivalent to orig_var (INCLUDING orig_var) 
just before the stat.

The function 	
	BOOL EV_EquivVarsP(STAT stat, VAR v1,VAR v2);
(also declared in p2equiv/p2equiv.H) is also available, though
probably will not need to use it. It checks if v1 equiv v2 just
before "stat".
-----------------


To: spin-comp-archive@cs
Subject: This is a test of the spin-comp-archive mailing list
Date: Thu, 07 Aug 1997 08:40:25 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

T.

--Brian

To: spin-comp@cs
Subject: New mail alias: spin-comp-archive@cs
Date: Thu, 07 Aug 1997 08:44:25 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

Now we have a way of automatically dumping messages to the archive and
discussion lists.  Just cc e-mail to spin-comp-archive@cs.

--Brian

To: spin-comp@cs
Subject: gdb initialization
Date: Thu, 07 Aug 1997 09:56:15 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

I checked a file containing Charlie's gdb macros for accessing Multiflow's
data structures (with a couple of my own added) into the DyC bin directory.
Whenever we go to the effort of hand-expanding Multiflow's macros, we should
translate them into gdb macros and put them into this file.

So, the file I source (dbx.in) when I start gdb now contains the following:

source /afs/cs/project/dyncomp/grant/DyC/bin/gdb-macros
dir /afs/cs/project/dyncomp/grant/DyC/mflow/
cd /afs/cs/project/dyncomp/grant/Test/test2
b ERR_AssertFailed
b ERR_Error
b DYC_assert
run -mmain_arg_file=/afs/cs/project/dyncomp/grant/Test/test2/ccomargs.in

I updated the "Debugging Multiflow" web page to include this.

--Brian

To: Markus Mock <mock@apex.cs.washington.edu>
cc: spin-comp-archive@cs
Subject: Re: bta_export.H 
Date: Thu, 07 Aug 1997 10:10:49 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

>> What kind of laziness info do you need exactly? Laziness information will
>> be computed for edges.

The result of identifying lazy branch successors should be that particular
edges emanating from branches are marked as lazy.  No other edges should be
marked lazy.  It should be possible for me to move a lazy mark from its
original edge to any other edge, even one not immediately preceded by a
branch because I may insert blocks on edges.

>> Do you want to inspect the variables' annotated policies?

Assuming that I run after lazy branch successors are identified, no, I don't
need to look at lazy policies for individual variables.

Thanks.
--Brian

To: spin-comp@cs
Subject: Makefiles for easier testing
Date: Thu, 07 Aug 1997 10:17:00 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

I created two new Makefiles.  One is in the lib directory and builds dycrt.a.
The other is in bin.  It can used to build single-file programs that are
to be dynamically compiled (for testing purposes).  If you have a test file
named test.DyC, just type (or make an alias for)
make -f /afs/cs/project/dyncomp/$USER/DyC/bin/Makefile test.x

It will automatically run dyc2c, Multiflow, stitch.pl, and cc as needed.
You should set DYC_BIN_DIR to your bin directory (e.g.,
/afs/cs/project/dyncomp/grant/DyC/bin) and make sure your DYC_LIB_DIR and
USER environment variables are still set correctly.  If you want to run
dyc2c-ms instead of dyc2c, you'll need to change the Makefile in bin.

To grab all the current files, update your (at least) lib and bin directories.

--Brian

Date: Thu, 7 Aug 1997 13:33:28 -0700 (PDT)
From: Markus Mock <mock@apex.cs.washington.edu>
To: spin-comp@cs.washington.edu
Subject: meeting

I forgot that I have an appointment at the doctor's today and can't come
to the meeting.

Progress:
Brian and I have agreed on an interface for the new BTA so that he can
start porting
Due to a misunderstanding between Matthai and me I had to make some
changes to the BTA implementation, I'll finish these today and can then
start testing.
I have started implementing the laziness part of the BTA, because
Multiflow has some dominator and postdominator information already, this
turns out to be not so much code to write.

I'll give an update later tonight.


	-- Markus


To: spin-comp@thistle.cs.washington.edu
Subject: problem with previous makefile
Date: Thu, 07 Aug 1997 17:08:36 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

You'll want to pick up the new Makefile from DyC/bin.  The old one had
problems with dependence chains longer than one not working.  The new one
fixes that problem, but requires the variable TARGET to be set to the
basename of the file on the make command line.  For example, if you're
building test.x TARGET must be set to "test".  I use the following bash
function to do this automatically:

function dcmake {
	file="$1"
	make -f ${DYC_BIN_DIR}/Makefile TARGET=${file%.*} ${file}
}

If other people are using shells where this is more difficult, we can easily
turn this into a bash script.

--Brian

To: eggers@pa.dec.com
cc: spin-comp-archive@cs
Subject: post-meeting update
Date: Thu, 07 Aug 1997 17:20:17 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

I have been debugging multiple units and working on infrastructure for
debugging and testing.  After Matthai and I fixed some problems in the
trace scheduler, multiple units are going through our pipeline (front-end
script -> multiflow -> back-end script -> DEC cc), but are not yet working.
Matthai and I will continue to debug multiple units and also begin looking
at adding functionality we'll need to handle reasonable test cases, such as
caching and static loads.  In addition, I need to start to port my code to
the new BTA (which is not yet functional).

--Brian

Date: Mon, 11 Aug 1997 15:08:42 -0700 (PDT)
From: chambers@klamath (Craig Chambers)
To: cecil@cs, spin-comp@klamath
Subject: Keith Cooper and Tim Harvey : Building and Using Static Single As

FYI.

----- Begin Included Message -----

From voting-faculty-request@june  Mon Aug 11 10:42:05 1997
Delivery-Date: Mon, 11 Aug 1997 10:42:06 PDT
From: Johnny Foehner <johnnyf@microsoft.com>
To: "'ms-talks@cs.washington.edu'" <ms-talks@cs.washington.edu>
Cc: Mark Roberts <markro@MICROSOFT.com>, Bob Davidson <bobd@MICROSOFT.com>,
        Trinh Vo <trinhv@MICROSOFT.com>
Subject: Keith Cooper and Tim Harvey : Building and Using Static Single As
	signment Form: Rice University
Date: Mon, 11 Aug 1997 10:41:07 -0700
X-Priority: 3
X-Mailer: Internet Mail Service (5.0.1459.27)

************************************************************************
************************************************************WHO:
Keith Cooper and Tim Harvey 
AFFILIATION:		Rice University
TITLE:				Building and Using Static Single
Assignment Form
WHEN:				Friday August 15, 1997
WHERE:			9s/1007
TIME:				1:30-3:00
HOST:				Mark Roberts
CONTACT:			Johnny Foehner(johnnyf@microsoft.com)
     
NOTE:			      If you plan to attend, please send an
e-mail with your name and UW
				      affiliation to
Johnnyf@microsoft.com, so that the Bldg. 9 
					receptionists can give you
access to the seminar room at Microsoft 
					Research.  Directions are on the
web clicking on "About MSR"
					at
http://www.research.microsoft.com
************************************************************************
************************************************************
                                              Building and Using Static
Single Assignment Form

                                                               Timothy
J. Harvey
                                                                Keith D.
Cooper

                                                                Rice
University


 Much recent work in code optimization has relied on the Static Single
Assignment form (SSA) for a procedure. This talk will address two key
questions that arise in building an optimizing compiler that uses SSA:

 (1) How do you build SSA?

 (2) How do you use SSA to obtain better code?

The first part of the talk will focus on algorithms for constructing the
SSA form for a procedure; the discussion includes improvements and
corrections to the published algorithms.  The second part will examine
SSA-based algorithms for global value numbering and operator strength
reduction; these algorithms highlight some of the benefits of using SSA.

The talk covers material found in three as yet unpublished papers.
Copies of the papers can be found at

	http://www.cs.rice.edu/~keith/Microsoft.html



Keith D. Cooper
                                 Associate Professor, Department of
Computer Science, Rice University

                                 Research Interests:
-------------------
Dr. Cooper's research focuses on the analysis and optimization of
compiled code for uniprocessor machines. He has developed efficient
algorithms for a number of problems in interprocedural analysis, has
done extensive work
on graph-coloring register allocation, and has explored several problems
in scalar optimization. He was one of the principal designers and
implementors of the Rn Programming Environment and helped lead the
ParaScope project.
As one of the leaders of the Massively Scalar Compiler Project at Rice
University, his current work includes code space optimization,
non-constructive algorithms for instruction scheduling, and the
application of classical code
optimization techniques to intermediate forms used in VHDL compilers.

--------------------
                                                               Timothy
J. Harvey
                               Research Programmer, Department of
Computer Science, Rice University

                               Research Interests:
-------------------
 As lead programmer on the Massively Scalar Compiler Project at Rice
University, Mr. Harvey wrote the core of the research compiler, as well
as a number of optimization passes for it, including the constant
propagator, the peephole analyzer, and the register allocator.  His
current work concerns optimization of spill-code insertion and
improved spilling heuristics during register allocator.








http://www.research.microsoft.com



----- End Included Message -----


Date: Mon, 11 Aug 1997 15:11:46 -0700 (PDT)
From: Markus Mock <mock@apex.cs.washington.edu>
To: Craig Chambers <chambers@klamath>
cc: cecil@cs, spin-comp@klamath
Subject: Re: Keith Cooper and Tim Harvey : Building and Using Static Single As signment Form: Rice University

I'd like to go but need a ride. Is anyone from the group going who could
share a ride?


	-- Markus


To: Markus Mock <mock@apex.cs.washington.edu>
cc: spin-comp-archive@cs
Subject: Re: splitting the CFG 
Date: Tue, 12 Aug 1997 08:39:09 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

>> I'll either need to split the graph for the laziness info or
>> compute it per division (which is what I am currently doing).

Computing it for each division seems fine.  Is there any reason why that is
harder than splitting the graph first?  Just curious.

>> Let me know if there are any routines I can reuse or where I should look
>> at.

The routines I have aren't really suitable for your use, but I could write
the routines that split the CFG.  The tricky issues involve IGOTOs:

	-- Tags: tag anchors must be renamed when they are copied; I have
	   code that does this
	-- Tag arrays: when an IGOTO and some or all of its targets are copied
	   a new tag array must be created; I have code that does this
	-- Loads: STATs (primarily loads) that reference the old tag array
	   must be changed; I have put in some support for finding these
	   STATs

Of course, basic copy routines (assuming no IGOTOs) should be pretty easy.
Let me know if you want me to whip up non-IGOTO-compliant version, or if you will go ahead and do it.

--Brian

Date: Tue, 12 Aug 1997 13:41:03 -0700 (PDT)
From: Markus Mock <mock@apex.cs.washington.edu>
To: Brian Grant <grant@thistle.cs.washington.edu>
cc: spin-comp-archive@cs
Subject: Re: splitting the CFG 

I'd appreciate if you could write the simply non-igoto routine. 
It makes the routines for laziness stuff somewhat easier as it saves me
about everywhere an outer loop going through the different divisions.

So it's not really harder but more convenient to have the data associated
with each branch node than  an additional set indexed by division for each
branch node.


	-- Markus

On Tue, 12 Aug 1997, Brian Grant wrote:

> >> I'll either need to split the graph for the laziness info or
> >> compute it per division (which is what I am currently doing).
> 
> Computing it for each division seems fine.  Is there any reason why that is
> harder than splitting the graph first?  Just curious.
> 
> >> Let me know if there are any routines I can reuse or where I should look
> >> at.
> 
> The routines I have aren't really suitable for your use, but I could write
> the routines that split the CFG.  The tricky issues involve IGOTOs:
> 
> 	-- Tags: tag anchors must be renamed when they are copied; I have
> 	   code that does this
> 	-- Tag arrays: when an IGOTO and some or all of its targets are copied
> 	   a new tag array must be created; I have code that does this
> 	-- Loads: STATs (primarily loads) that reference the old tag array
> 	   must be changed; I have put in some support for finding these
> 	   STATs
> 
> Of course, basic copy routines (assuming no IGOTOs) should be pretty easy.
> Let me know if you want me to whip up non-IGOTO-compliant version, or if you will go ahead and do it.
> 
> --Brian
> 


To: mock@thistle.cs.washington.edu
cc: spin-comp-archive@cs
Subject: splitting the graph
Date: Tue, 12 Aug 1997 14:59:42 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

I quickly wrote a routine to split one node, but I realized it isn't quite
what we want.  Here is a proposed algorithm.

I envision this pass going after the BTA but before unit assignment in
DYC_PrepForDynComp():

    /* Split the divisions */
    dyc_PartitionBBlocksAtDivisionMerges();
    DEP_Destroy_All();
    DEP_COMPUTE_INFO(DFO_Compute);
    DEP_COMPUTE_INFO(TOPO_Compute);
    dyc_SplitDivisions();

dyc_PartitionBBlocksAtDivisionMerges():

We'll need a prepass to split BBLOCKs wherever the number of divisions
decreases.  I also have routines that can be easily modified to do that.
I already partition BBLOCKs when "interesting" things occur in the BTA
(promotions, etc.), so I can write this routine.

dyc_SplitDivisions():

/*
We need a topological traversal so that we can assume that when we process a
given node we can be sure all of its predecessors have only single divisions.
*/
LOOP { FOR_EACH_TOPO_BBLOCK(BBlock) DO {

1) Correlate each incoming (forward) edge with a division (every incoming edge
   must be assigned to one division and every division should correspond to at
   least one incoming edge)
2) Paritition the incoming edges by their divisions
3) Make (N-1) duplicates of the node for the N partitions of incoming edges;
	-- call BBLOCK dyc_CopyBBlock(BBlock) (in p2dyc/util.[CH])
4) Attach the appropriate BTA info to each copy
5) Redirect the edges to their new destinations
	-- call BBLOCK BBLOCK_Redirect_Succ_Edge(source, BBlock, newdest)
	   (in p2graph/bblock_3.C)
}

/*
After the topological traversal has completed, we need to invoke a routine to
fix jump tables (tag arrays).  I put a prototype for this in p2dyc/util.[CH].
*/
dyc_FixTagArrays();


Do we need to worry about backedges?  I don't think so, but I haven't thought
about it carefully.

Steps #1 and #2 should be the bulk of the work remaining, and probably easier
for you to do since I'm not yet familiar with the BTA interface.  Does it
seem reasonable for you to try to code up dyc_SplitDivisions?  Does the
algorithm seem correct?

--Brian

Date: Thu, 14 Aug 1997 14:37:01 -0700 (PDT)
From: Markus Mock <mock@apex.cs.washington.edu>
To: Brian Grant <grant@apex.cs.washington.edu>
cc: spin-comp-archive@apex.cs.washington.edu
Subject: DYC2_AnnotationsExist()

returns TRUE if there are any annotations

it's part of the new bta in bta-v2.H

The other function you want something like

(1) BOOL DYC_InDynamicRegion(STAT stat)

depends on the division, do you want it like 
(2) BOOL DYC_InDynamicRegion(STAT stat, DYC2_DIVISION div)

or after like above (1) to be used after the splitting of the graph?

	-- Markus



	-- Markus


To: grant@franklin.cs.washington.edu,
cc: Matthai Philipose <matthai@franklin.cs.washington.edu>
Subject: cache available
Date: Thu, 14 Aug 1997 14:53:29 PDT
From: Matthai Philipose <matthai@franklin.cs.washington.edu>

I have just tested and checked in mflow/lib/dyc_cache.[ch]. The cache is
a doubly-hashed open hashtable (elements are stored in the
hash-table: no chaining), with automatic expansion of the table as it
begins to get too congested. Memory allocation for hashtables
is currently from the pool:
	long int DYC_CACHE_cache_space[DYC_CACHE_SPACE_SIZE]


The abstract interface is:
	void DYC_CACHE_insert(dyc_cache cache, long int *key_vector,int 
key_vector_size,int *pc);
	int* DYC_CACHE_lookup(dyc_cache cache, long int *key_vector,int 
key_vector_size);

with the additional utility function:
	void DYC_CACHE_print(dyc_cache cache);


No delete operation is currently implemented. According to CLR, a
chained implementation is better if delete is required.
			Matthai

Date: Fri, 15 Aug 1997 16:59:57 -0700 (PDT)
From: Markus Mock <mock@apex.cs.washington.edu>
To: spin-comp@apex.cs.washington.edu
Subject: Harvey and Cooper's talk on SSA at MS

Here's a short summary of the talk(s):

First, Harvey, who apparently programmed the various implementations of
SSA at Rice, gave an intro on how SSA is computed.
3 variants:

- minimal SSA (as described by Zadeck et al) motivated by goal to
  minimize the number of phi-nodes, done by computing the iterated dominance
  frontier

- semi-pruned (an improvement over minimal) due to Briggs

- pruned: less phis by liveness analysis and removing phis that are
  are not live

He then explained how they discovered two problems with SSA or rather a
subtleties that made previously described algorihms based on SSA buggy. In
one case copy folding may remove a copy that it should not. The example
how this happens and details are in their (yet unpublished) papers at
http://www.cs.rice.edu/~keith/Microsoft.html

Cooper, in the second half of the 1 1/2 hour talk, gave an overview of the
usefulness of SSA:

- the namespace created by SSA was useful for 
	easier value numbering
	lazy code motion (based on Steffen et al) which ran in O(n)
	instead of O(n^2), although with a worse constant

- the sparsety (less space than def-use chains) made analysis generally
  faster

- the third point was explained in the way "Trust me", essentially he was
  saying that the placement of the phi-nodes gave important topological 
  info about the program (whatever that was supposed to say)

The two new algorithms that they came up with that were improvements of
previous work are:

1) global value numbering 
2) strength reduction 

Details are in their papers, I guess.


	-- Markus


To: spin-comp@franklin.cs.washington.edu
Subject: discordant temps analysis working...
Date: Mon, 18 Aug 1997 17:33:08 PDT
From: Matthai Philipose <matthai@franklin.cs.washington.edu>

The discordant temps analysis is up and running. It has
been tested on a simple case (~matthai/dyc/test/discordant/discordant.C),
and seems to work. I'll test it on another more complex case (discordant1.C
in the above directory) before laying it to rest.

Under the current implementation, a temp is  discordant at a merge
if there exist two incoming edges to the merge along which the temp
has different reaching def sets. 

Each basic block has a discordant_temps_in field of type
BS (bitset), which is non-null if the block is a merge node.
The following fragment of code illustrates how the discordant_temps
set may be accessed:
---------
BS discordant_temps;
IF(discordant_temps=BBLOCK_discordant_temps_in(bblock))
{
 LOOP{
    FOR_EACH_TEMP_SET_ELEMENT(discordant_temps,temp)
     DO{
         ...temp...
       }}
}
--------------

The main complicaion in the implementation was to save per-program point
reaching defs information from multiflow's reaching-defs analysis. The
existing analysis only preserved reaching defs info at uses. I've
added the ability to get reaching-defs info at the end of each
basic-block. Writing data-structure accessors and layers of (routine) memory
management code accounted for most of the remaining hassle.
                     Matthai

To: grant@franklin.cs.washington.edu
cc: spin-comp-archive@franklin.cs.washington.edu
Subject: Spec modification for setup/template block end tags
Date: Thu, 21 Aug 1997 17:45:40 PDT
From: Matthai Philipose <matthai@franklin.cs.washington.edu>

Right now, the tags look like:
<function name>.dyn_setup_end_<int>_<int>
and
<function name>.dyn_template_end_<int>

I would like the tags to look as follows:
<function name>.dyn_setup_end_<int>_<int>_n
and
<function name>.dyn_template_end_<int>_n

where the 'n's at the end mean that (by default)
no goto is required after the branch (if one exists) 
at the end of the basic block.

If I find late in the backend that a branch is required,
I will convert the 'n' into a 'y'.
			Thanks,
			Matthai

To: Matthai Philipose <matthai@franklin.cs.washington.edu>
cc: spin-comp-archive@franklin.cs.washington.edu
Subject: handling beq/br pairs in the merger
Date: Thu, 21 Aug 1997 18:08:23 PDT
From: Matthai Philipose <matthai@franklin.cs.washington.edu>

The aim of the game is to set a flag in the tags at setup and
template ends to indicate that the conditional branch (if one exists) 
at the end of the block, is followed by an unconditional branch.
                 Matthai

What happens now:
emit.C/em_Mi__Emit_Instruction(MI mi)
	1)sets: 	em_need_goto_instruction = FALSE;
	2)emits tags: 	em_Mi__Emit_Tags(mi);
	3)calls:  	em_Mi__Emit_Instruction_Body(mi), which
				1)sets:			emit_goto = MI_is_aregion_end_get(mi) && 
em_Aregion_End__Need_Goto(mi);
				2)emits:		em_Mop_Target_Mi__Emit_Conditional_Jump(...)  (conditionally)
				3)sets: 		em_need_goto_instruction = TRUE;   (conditionally, based on 
emit_goto and other checks)
	4)calls: 	IF (em_need_goto_instruction) em_Mi__Emit_Goto_Instruction(mi);

What needs to be done:
	1)Compute em_need_goto_instruction in ...Emit_instruction() _before_ 
...Emit_Tags()
		(by copying relavent code from ...Emit_Instruction_Body())
	2)Define a routine em_Mi__Set_Goto_Flag(mi) which 
		-iterates through the the tags of mi till one of the form 
			<function name>.dyn_setup_end_<int>_<int>_n
		 or
		 	<function name>.dyn_template_end_<int>_n
		 is found
		-if such a tag exists, change the trailing 'n' into a 'y'
	3)Invoke ...Set_Goto_Flag() right before em_Mi__Emit_Tags()

 

To: mock@thistle.cs.washington.edu
cc: spin-comp-archive@cs
Subject: BTA interface
Date: Wed, 27 Aug 1997 12:41:07 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

Thanks for adding the iterators, etc. to bta_export.H.  I'm working on porting
to the new BTA again.  I would like at least one change to what is in
bta_export.H:

BS DYC2_BTA_StaticUnpromoted(DYC2_BTA bta, DYC2_DIVISION div); /* returns the static
	temps minus the promoted temps */

As we discussed, I plan to do something like the following:
promotions = DYC2_BTA_get_promotedBS(original_bta, div);
interim_bta = DYC2_BTA_StaticUnpromoted(original_bta, div);
/* copy interim_bta to all stats in this bblock */
...
/* make original_bta the initial bta of the next bblock (including promotions)*/
...

So, it would be more convenient for me if StaticUnpromoted returned a BTA
rather than a bitset.  I don't know how to construct a BTA from a bitset.

Let me know what you think.
--Brian

Date: Wed, 27 Aug 1997 12:59:30 -0700 (PDT)
From: Markus Mock <mock@apex.cs.washington.edu>
To: grant@cs.washington.edu
cc: mock@thistle.cs.washington.edu, spin-comp-archive@cs
Subject: Re: BTA interface

> 
> 
> So, it would be more convenient for me if StaticUnpromoted returned a BTA
> rather than a bitset.  I don't know how to construct a BTA from a bitset.
> 

No problem. So in the returned BTA you want static varinfo to be adjusted
by subtracting the promoted temps?
Or would you simply like a copied bta and an accessor for the bta that
returned a BS like the one I proposed in export?

	-- Markus



To: Markus Mock <mock@apex.cs.washington.edu>
cc: spin-comp-archive@cs
Subject: Re: BTA interface 
Date: Wed, 27 Aug 1997 13:41:07 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

>> No problem. So in the returned BTA you want static varinfo to be adjusted
>> by subtracting the promoted temps?
>> Or would you simply like a copied bta and an accessor for the bta that
>> returned a BS like the one I proposed in export?

I need to annotate bblocks and stats I insert with modified BTA information.
So, I would like a routine that returns a BTA with the temps promoted in the
original BTA removed from the StaticVarInfo and also with an empty
PromotedVars set.  I don't want a routine that returns a bitset because I
don't know how to filter the StaticVarInfo using a bitset.

--Brian

Date: Wed, 27 Aug 1997 14:25:30 -0700 (PDT)
From: Markus Mock <mock@apex.cs.washington.edu>
To: Brian Grant <grant@thistle.cs.washington.edu>
cc: Markus Mock <mock@cs>, spin-comp-archive@cs
Subject: Re: BTA interface 

Ok. I checked in a new version of bta_export.H that has the routine you
want.


	-- Markus

On Wed, 27 Aug 1997, Brian Grant wrote:

> >> No problem. So in the returned BTA you want static varinfo to be adjusted
> >> by subtracting the promoted temps?
> >> Or would you simply like a copied bta and an accessor for the bta that
> >> returned a BS like the one I proposed in export?
> 
> I need to annotate bblocks and stats I insert with modified BTA information.
> So, I would like a routine that returns a BTA with the temps promoted in the
> original BTA removed from the StaticVarInfo and also with an empty
> PromotedVars set.  I don't want a routine that returns a bitset because I
> don't know how to filter the StaticVarInfo using a bitset.
> 
> --Brian
> 



Date: Wed, 27 Aug 1997 14:50:08 -0700 (PDT)
From: Markus Mock <mock@apex.cs.washington.edu>
To: Matthai Philipose <matthai@cs>, spin-comp-archive@cs
Subject: psused vars trouble

Matthai,

p2used vars causes an out of memory.
The problem is that in p2used_vars.C:268 a bogos VAR is returned with
var number being pretty big:
 {number = 1090968672, type = VAR_RECORD, name = 0x14106dae0 "\001", 
  parent_pack = 0x14106dc70, parent_record = 0x0, next_var = 0x0, size =
4, 
  offset = 0, esize = 4, ndinfo_cnt = 0, ndinfo_ptr = 0x0, 
  address_directly_taken = 0, address_taken = 0, lim_store_directly_seen =
0, 
  lim_store_seen = 0, union1 = {rvd_var_info = 0x140eef2e8, 
    inline_copy = 0x140eef2e8}}

hence, the BS allocation routine in used vars tries to allocate memory for
that huge number.

Any idea why UV_UsedVars_In could cause that?
This is the call stack:

#0  PAGE_Alloc (size=136371112, allocated_size=0x11fffe3f0) at alloc/page.C:232
#1  0x1200e1204 in pool_Do_Alloc (pool=0x1400150b0, size=136371096)
    at alloc/pool.C:869
#2  0x1200e0da8 in POOL_Srealloc (pool=0x1400150b0, ptr=0x14106d800 "\005", 
    old_size=24, new_size=136371092) at alloc/pool.C:670
#3  0x120110a2c in VAR_UVSet_Realloc (ptr=0x14106d800 "\005", old_size=24, 
    new_size=136371092) at p2mem/p2mem.C:581
#4  0x120105478 in bs_Realloc (set=0x14106d800, length=34092772, 
    rf=0x1201109d8 <VAR_UVSet_Realloc(char *, int, int)>) at util/bitset.C:967
#5  0x120105300 in bs_ExpandD (set=0x14106d800, size=34092772, 
    rf=0x1201109d8 <VAR_UVSet_Realloc(char *, int, int)>) at util/bitset.C:931
#6  0x120104a20 in BS_Union1D (set=0x14106d800, x=1090968672, 
    rf=0x1201109d8 <VAR_UVSet_Realloc(char *, int, int)>) at util/bitset.C:695
#7  0x12017a13c in VAR_UVSet_Union1D (set=0x14106d800, element=0x140f24e90)
    at p2used_vars/var_utils.C:79
#8  0x120179dcc in uv_UsedVars_Out_Internal (used_out_set=0x14106d800, 
    stat=0x140ee1b40, bblock=0x140eebd18) at p2used_vars/p2used_vars.C:270
#9  0x1201799b4 in UV_UsedVars_In (used_in_set=0x14106d800, stat=0x140ee1ca8)
    at p2used_vars/p2used_vars.C:230
#10 0x1201b2a2c in DYC2_BtaIdfa () at p2bta/bta-v2.C:392


	-- Markus


To: spin-comp-archive@franklin.cs.washington.edu
Subject: Original interface to the merger
Date: Thu, 28 Aug 1997 14:34:53 PDT
From: Matthai Philipose <matthai@franklin.cs.washington.edu>

This is the spec I gave Charlie. I'm just archiving it before
I lose it. Inter-unit branches were ignored in this spec.

Charlie did a crackerjack job in coding this spec up. Even
I can read and modify his perl!
	Matthai

------------------A description of the algorithm:
We have decided to merge setup code with code to generate template
code by transforming the assembler file that contains the setup and
template code. 

The algorithm for merging the setup code with instructions to stitch
template code is described below. Recall that setup code computes the
values of runtime constants that are used in template code. Setup code
is executed just once for each distinct set of root runtime constant values.
The template code that uses the values computed by the setup code is
transformed to an executabe form ("stitched") on the basis of these
computed values. On subsequent executions (with this set of root
runtime constant values), only the stitched code is executed. 

The first version of our system went about this transformation by
emiting directives that indicated how the template code could be
stitched, given that the values of the runtime constants used in the
template were computed and placed in an intermediate "setup table". An
independent program called the stitcher followed the directives to
produce a stitched version of the template, essentially patching the
runtime constants from the setup table into the holes in the template
and eliminating branches that depended on runtime constants. 

In the new version of the system, we wish to avoid the intermediate
table, the directives, and the separate stitcher program. Instead of
producing _directives_ that _describe_ how template code is to be
translated once all possibly necessary setup values are calculated, we
produce _code_  that _emits_ the transformed version of the template
code. We eliminate the setup table by integrating this emitting-code
with the setup code, such that runtime constant values used for
transforming the template are passed between setup code and emitting-
code through registers as far as possible. A natural question then
arises: where in setup code should the emitting-code for producing a
given template statement be placed?

Because the setup code and template code are produced by duplicating
the CFG for the dynamic region in the source program, every template
block has at least one (possibly empty) setup block associated with
it. A natural place to emit code for a template block is therefore in
its correspondig setup block. 


The algorithm for transformation is as follows:


for each template-code basic block T
  //There could be many setup bbs corresponding to T
  for each corresponding setup basic block S;

  //Find the beginning and end of the first "sequence"
  //of instructions in T to be emitted (a sequence consists of 
  //the instructions between two holes (exclusive of the holes)
 
  current_hole = NULL;
  next_hole = find_next_hole(current_seq_end);
  //If there are no holes in the bb, the first sequence is the entire bb
  //otherwise it only extends to the program point _after_ the previous hole
  current_seq_begin = basic_block_begin(T);
  if (!next_hole)
      current_seq_end = basic_block_end(T);
  else
      current_seq_end = next_hole;

  //Find the point in S, where the sequence should be
  //inserted
  current_insertion_point = basic_block_begin(S);	


  //Loop over all sequences in T,
  //inserting them at the corresponding insertion point in S 
  while(current_seq_begin)
  {
	//Emit the current sequence
	emit_sequence(current_insertion_point,current_seq_begin,current_seq_end);
	if(current_hole)
		emit_hole(current_insertion_point,current_hole);


	//Find the next sequence
	current_hole = next_hole;
	if(current_hole)
		current_seq_begin= next_program_point(current_hole);
	else
		current_seq_begin= NULL; //can break here

	next_hole = find_next_hole(next_hole);
	if (!next_hole)
		//No more holes in the bb; sequence extends to end of bb
		current_seq_end = basic_block_end(T);
	else
		current_seq_end = next_hole;
	current_insertion_point = find_next_rtconst_store(current_insertion_point)
  }	


//Helper function details

0) basic_block_[begin|end](T) 
Finds the program point before the first instruction in T.
 
The beginning and end of each basic block in the template, and the
corresponding basic block in the setup will be marked by the labels:
	[setup|template]_[begin|end]_<template_bb_number>_<setup_index>

Note that many setup blocks can correspond to a single template block.
All of them will have the same template_bb_number, but different
setup_index'es.

Only setup labels will have the setup index, to distinguish them from
other setup bbs with the same template_bb_number.

1) find_next_hole(prog_point)
Find the program point before the next hole in the current _template_
block. If no such pp exists, return NULL.

Every hole in a template will be labelled:
	template_hole_<template_bb_number>_<hole_number>


2)find_next_rtconst_store(prog_point)
Find the program point before the next (dummy) store of an rtconst in the
current _setup_ block. 

Recall that every point in the setup code where a hole in the template
code needs to be emitted is marked with a store. The store should have
the form: 
	stl r_i,rtconst_<bb_number>_<template_bb_number>_<setup_bb_num>_<hole_number>
(gp)

The value of the rtconst that needs to go into the hole is live in
register r_i. Each such instruction will also be labelled:
	setup_hole_<template_bb_number>_<setup_bb_num>_<hole_number>

Remember that one template_bb can have many corresponding setup_bbs.


--------------An example of the input specifications:
	// Here's the source code for the below assembler
	// The whole body of the procedure is a dynamic region
  add(int a, int b, int c0, int c1){
	keepconst(c0,c1)	//The whole function is a dynamic region 
	t1= a+1			

	c2= c1 + c0		//c_i are runtime constants
	c3= c1 - c0

	if(c2==0)		//static branch
		c4 = c2+1
		t1 += c3
	else
		t1+=b	//b global

	if(t1==0)
		return c4	
	else
		return c1
	}




	//Here's the corresponding assembler for setup, template and merged code
	
	//Assume a,b,c0,c1 are in r0,r1,r2,r3
	//r31 is the zero register

;;;setup code
		
dyn_setup_begin_1_0:			; template no. == 1, setup index == 0	
		addl	r4,r2,r3	; r4=r2+r3
		subl	r5,r3,r2	; r5=r3-r2
dyn_setup_end_1_0:		
		bne	r5,L1
	
dyn_setup_begin_2_0:
		addl	r6,1,r4
	;;  dummy store ensures that rtconst c3 is live at this point (in register
	;;  r5); the store will be replaced by an emit of the corresponding
	;;  template hole... the value in r5 will go into the hole.
		stl	r5,rtconst_2_0_1(gp)
dyn_setup_end_2_0:
		br	L2

L1:	
dyn_setup_begin_3_0:		

dyn_setup_end_3_0:	

L2:		
dyn_setup_begin_4_0:	
dyn_setup_end_4_0:	

dyn_setup_begin_5_0:
		stl	r6,rtconst_5_0_0(gp); another placeholder store
dyn_setup_end_5_0:	

dyn_setup_begin_6_0:
		stl	r3,rtconst_6_0_0(gp); placeholder 
dyn_setup_end_6_0:	


	
;;; template code
	
dyn_template_begin_1:	
		addl	r6,1,r0
		lda	r5,rtconst_1_0(r31); r31 contains zero
dyn_template_end_1:	
		bne	r5,L10

dyn_template_begin_2:
		addl	r6,rtconst_2_0,r6
		br	L11
dyn_template_end_2:	

L10:		
dyn_template_begin_3:
		ldl	r8,_b(gp)
		addl	r6,r8,r6
dyn_template_end_3:	

L11:		
dyn_template_begin_4:
		bne	r6,L12
dyn_template_end_4:	

dyn_template_begin_5:
		lda	r7,rtconst_5_0(r31)
		ret	r7
dyn_template_end_5:	

L12:	
dyn_template_begin_6:
		lda	r7,rtconst_6_0(r31)
		ret	r7
dyn_template_end_6:	



	
;;;merged code
	;; note: I've removed all bb begin/end markers
		
		addl	r4,r2,r3	; r4=r2+r3
		subl	r5,r3,r2	; r5=r3-r2
		emit    'addl r6,1,r0'
	;; note:static branch is not emitted
		bne	r5,L1
	
		addl	r6,1,r4
	;; note:dummy store is replaced by emit sequence	
		emit    r5, 'addl r6,rtconst_2_0,r6'
		emit	'br L11'
		br	L2

L1:	
		emit 'L10:ldl	r8,_b(gp)'
		emit '	addl	r6,r8,r6'
	
L2:		
		;; dynamic branches are emitted
		emit	'L11:	bne r6,L12'

		emit	r6,'lda	r7,rtconst_5_0(r31)'
		emit	'ret r7'		

		emit	r3,'L12:  lda r7,rtconst_6_0(r31)'
		emit	'ret r7'	


---------------An improved input spec with more realistic support for static 
branches:
#setup code
		
dyn_setup_begin_1_0:			# template no. == 1, setup index == 0	
		addl	a1,a2,t2	# r4=r2+r3
		subl	a2,a1,t3	# r5=r3-r2
		bne	t2,L1
dyn_setup_end_1_0:		
	
dyn_setup_begin_2_0:
		addl	t2,1,t4
	#  dummy store ensures that rtconst c3 is live at this point (in register
	#  t3). the store will be replaced by an emit of the corresponding
	#  template hole... the value in t3 will go into the hole.
		stl	t3,rtconst_2_0_1
		br	L2
dyn_setup_end_2_0:

L1:	
dyn_setup_begin_3_0:		

dyn_setup_end_3_0:	

L2:		
dyn_setup_begin_4_0:	
dyn_setup_end_4_0:	

dyn_setup_begin_5_0:
		stl	t4,rtconst_5_0_0# another placeholder store
dyn_setup_end_5_0:	

dyn_setup_begin_6_0:
		stl	a2,rtconst_6_0_0# placeholder 
dyn_setup_end_6_0:	


	
# template code
	
dyn_template_begin_1:	
		addl	a0,1,t6
static_branch:	lda	t2,rtconst_1_0(zero)
dyn_template_end_1:	
static_branch:	bne	t2,L10

dyn_template_begin_2:
		addl	t6,rtconst_2_0,t6
		br	L11
dyn_template_end_2:	

L10:	
dyn_template_begin_3:
		ldl	t7,b
		addl	t6,t7,t6
dyn_template_end_3:	

L11:	
dyn_template_begin_4:
		bne	t6,L12
dyn_template_end_4:	

dyn_template_begin_5:
		lda	v0,rtconst_5_0(zero)
		ret	
dyn_template_end_5:	

L12:	
dyn_template_begin_6:
		lda	v0,rtconst_6_0(zero)
		ret	
dyn_template_end_6:	



	


Date: Sat, 30 Aug 1997 02:15:49 -0700 (PDT)
From: "Markus U. Mock" <mock@cs.washington.edu>
To: spin-comp@cs.washington.edu
Subject: BTA works for multi.DyC

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.
  Send mail to mime@docserver.cac.washington.edu for more info.

--1602278152-1495322112-872932549=:2003
Content-Type: TEXT/PLAIN; charset=US-ASCII

The BTA now produces correct output for the multiple unit example.
Since this is a very simple example (no loops, just one division) I can't
yet claim that the BTA works ok, but we are getting there.

Later today I'll check it in after testing that the interface functions
for Brian are all ok.
I am attacking debug output with the info for the example in case you want
to check it by hand.



	-- Markus 


--1602278152-1495322112-872932549=:2003
Content-Type: TEXT/PLAIN; charset=US-ASCII; name=foo
Content-Transfer-Encoding: BASE64
Content-ID: <Pine.LNX.3.96.970830021549.2003I@bloch.non.cs.washington.edu>
Content-Description: 

U3RhdCAxMTQJRW1wdHkgQlRBDQoNCkZpbmFsIEJUQToNCg0KRGl2aXNpb24g
MDoJezxfdSQxLjJQb2x5RGl2LFBvbHlTcGVjLEF1dG9Qcm9tbyxDYWNoZVBB
bGwsQ2FjaGVNQWxsLExvb3BMYXp5LD48X3UkMS4yUG9seURpdixQb2x5U3Bl
YyxBdXRvUHJvbW8sQ2FjaGVQQWxsLENhY2hlTUFsbCxMb29wTGF6eSw+fQ0K
U3RhdGljIFRlbXBzOgl7KHQwLENhY2hlQWxsLHtfdSQxLjIsfSl9DQpQcm9t
b3RlZCBUZW1wczoJezAsfQ0KRGlzY29yZGFudCBUZW1wczoJe30NCkRlbW90
ZWQgVGVtcHM6CXt9DQpCYmxvY2sgMjQNCkluaXRpYWwgQlRBOg0KDQpEaXZp
c2lvbiAwOgl7PF91JDEuMlBvbHlEaXYsUG9seVNwZWMsQXV0b1Byb21vLENh
Y2hlUEFsbCxDYWNoZU1BbGwsTG9vcExhenksPjxfdSQxLjJQb2x5RGl2LFBv
bHlTcGVjLEF1dG9Qcm9tbyxDYWNoZVBBbGwsQ2FjaGVNQWxsLExvb3BMYXp5
LD59DQpTdGF0aWMgVGVtcHM6CXsodDAsQ2FjaGVBbGwse191JDEuMix9KX0N
ClByb21vdGVkIFRlbXBzOgl7MCx9DQpEaXNjb3JkYW50IFRlbXBzOgl7fQ0K
RGVtb3RlZCBUZW1wczoJe30NClN0YXQgMTE2CQ0KRGl2aXNpb24gMDoJezxf
dSQxLjJQb2x5RGl2LFBvbHlTcGVjLEF1dG9Qcm9tbyxDYWNoZVBBbGwsQ2Fj
aGVNQWxsLExvb3BMYXp5LD48X3UkMS4yUG9seURpdixQb2x5U3BlYyxBdXRv
UHJvbW8sQ2FjaGVQQWxsLENhY2hlTUFsbCxMb29wTGF6eSw+fQ0KU3RhdGlj
IFRlbXBzOgl7KHQwLENhY2hlQWxsLHtfdSQxLjIsfSl9DQpQcm9tb3RlZCBU
ZW1wczoJezAsfQ0KRGlzY29yZGFudCBUZW1wczoJe30NCkRlbW90ZWQgVGVt
cHM6CXt9DQpGaW5hbCBCVEE6DQoNCkRpdmlzaW9uIDA6CXs8X3UkMS4yUG9s
eURpdixQb2x5U3BlYyxBdXRvUHJvbW8sQ2FjaGVQQWxsLENhY2hlTUFsbCxM
b29wTGF6eSw+PF91JDEuMlBvbHlEaXYsUG9seVNwZWMsQXV0b1Byb21vLENh
Y2hlUEFsbCxDYWNoZU1BbGwsTG9vcExhenksPjxfdiQxLjJQb2x5RGl2LFBv
bHlTcGVjLEF1dG9Qcm9tbyxDYWNoZVBBbGwsQ2FjaGVNQWxsLExvb3BMYXp5
LD59DQpTdGF0aWMgVGVtcHM6CXsodDAsQ2FjaGVBbGwse191JDEuMix9KSwo
dDQsQ2FjaGVBbGwse192JDEuMix9KX0NClByb21vdGVkIFRlbXBzOgl7NCx9
DQpEaXNjb3JkYW50IFRlbXBzOgl7fQ0KRGVtb3RlZCBUZW1wczoJe30NCkJi
bG9jayAyNQ0KSW5pdGlhbCBCVEE6DQoNCkRpdmlzaW9uIDA6CXs8X3UkMS4y
UG9seURpdixQb2x5U3BlYyxBdXRvUHJvbW8sQ2FjaGVQQWxsLENhY2hlTUFs
bCxMb29wTGF6eSw+PF91JDEuMlBvbHlEaXYsUG9seVNwZWMsQXV0b1Byb21v
LENhY2hlUEFsbCxDYWNoZU1BbGwsTG9vcExhenksPjxfdiQxLjJQb2x5RGl2
LFBvbHlTcGVjLEF1dG9Qcm9tbyxDYWNoZVBBbGwsQ2FjaGVNQWxsLExvb3BM
YXp5LD59DQpTdGF0aWMgVGVtcHM6CXsodDAsQ2FjaGVBbGwse191JDEuMix9
KSwodDQsQ2FjaGVBbGwse192JDEuMix9KX0NClByb21vdGVkIFRlbXBzOgl7
NCx9DQpEaXNjb3JkYW50IFRlbXBzOgl7fQ0KRGVtb3RlZCBUZW1wczoJe30N
ClN0YXQgMTE4CQ0KRGl2aXNpb24gMDoJezxfdSQxLjJQb2x5RGl2LFBvbHlT
cGVjLEF1dG9Qcm9tbyxDYWNoZVBBbGwsQ2FjaGVNQWxsLExvb3BMYXp5LD48
X3UkMS4yUG9seURpdixQb2x5U3BlYyxBdXRvUHJvbW8sQ2FjaGVQQWxsLENh
Y2hlTUFsbCxMb29wTGF6eSw+PF92JDEuMlBvbHlEaXYsUG9seVNwZWMsQXV0
b1Byb21vLENhY2hlUEFsbCxDYWNoZU1BbGwsTG9vcExhenksPn0NClN0YXRp
YyBUZW1wczoJeyh0MCxDYWNoZUFsbCx7X3UkMS4yLH0pLCh0NCxDYWNoZUFs
bCx7X3YkMS4yLH0pfQ0KUHJvbW90ZWQgVGVtcHM6CXs0LH0NCkRpc2NvcmRh
bnQgVGVtcHM6CXt9DQpEZW1vdGVkIFRlbXBzOgl7fQ0KU3RhdCAxMzgJDQpE
aXZpc2lvbiAwOgl7PF91JDEuMlBvbHlEaXYsUG9seVNwZWMsQXV0b1Byb21v
LENhY2hlUEFsbCxDYWNoZU1BbGwsTG9vcExhenksPjxfdSQxLjJQb2x5RGl2
LFBvbHlTcGVjLEF1dG9Qcm9tbyxDYWNoZVBBbGwsQ2FjaGVNQWxsLExvb3BM
YXp5LD48X3YkMS4yUG9seURpdixQb2x5U3BlYyxBdXRvUHJvbW8sQ2FjaGVQ
QWxsLENhY2hlTUFsbCxMb29wTGF6eSw+fQ0KU3RhdGljIFRlbXBzOgl7KHQw
LENhY2hlQWxsLHtfdSQxLjIsfSksKHQ0LENhY2hlQWxsLHtfdiQxLjIsfSks
KHQxNDMsQ2FjaGUxVSx7X3UkMS4yLH0pfQ0KUHJvbW90ZWQgVGVtcHM6CXt9
DQpEaXNjb3JkYW50IFRlbXBzOgl7fQ0KRGVtb3RlZCBUZW1wczoJe30NClN0
YXQgMTQwCQ0KRGl2aXNpb24gMDoJezxfdSQxLjJQb2x5RGl2LFBvbHlTcGVj
LEF1dG9Qcm9tbyxDYWNoZVBBbGwsQ2FjaGVNQWxsLExvb3BMYXp5LD48X3Uk
MS4yUG9seURpdixQb2x5U3BlYyxBdXRvUHJvbW8sQ2FjaGVQQWxsLENhY2hl
TUFsbCxMb29wTGF6eSw+PF92JDEuMlBvbHlEaXYsUG9seVNwZWMsQXV0b1By
b21vLENhY2hlUEFsbCxDYWNoZU1BbGwsTG9vcExhenksPn0NClN0YXRpYyBU
ZW1wczoJeyh0MCxDYWNoZUFsbCx7X3UkMS4yLH0pLCh0NCxDYWNoZUFsbCx7
X3YkMS4yLH0pLCh0MTQzLENhY2hlMVUse191JDEuMix9KSwodDE0MixDYWNo
ZTFVLHtfdSQxLjIsfSl9DQpQcm9tb3RlZCBUZW1wczoJe30NCkRpc2NvcmRh
bnQgVGVtcHM6CXt9DQpEZW1vdGVkIFRlbXBzOgl7fQ0KU3RhdCAxMjkJDQpE
aXZpc2lvbiAwOgl7PF91JDEuMlBvbHlEaXYsUG9seVNwZWMsQXV0b1Byb21v
LENhY2hlUEFsbCxDYWNoZU1BbGwsTG9vcExhenksPjxfdSQxLjJQb2x5RGl2
LFBvbHlTcGVjLEF1dG9Qcm9tbyxDYWNoZVBBbGwsQ2FjaGVNQWxsLExvb3BM
YXp5LD48X3YkMS4yUG9seURpdixQb2x5U3BlYyxBdXRvUHJvbW8sQ2FjaGVQ
QWxsLENhY2hlTUFsbCxMb29wTGF6eSw+fQ0KU3RhdGljIFRlbXBzOgl7KHQ0
LENhY2hlQWxsLHtfdiQxLjIsfSksKHQxMzAsQ2FjaGUxVSx7X3UkMS4yLH0p
fQ0KUHJvbW90ZWQgVGVtcHM6CXt9DQpEaXNjb3JkYW50IFRlbXBzOgl7fQ0K
RGVtb3RlZCBUZW1wczoJe30NClN0YXQgMTI4CQ0KRGl2aXNpb24gMDoJezxf
dSQxLjJQb2x5RGl2LFBvbHlTcGVjLEF1dG9Qcm9tbyxDYWNoZVBBbGwsQ2Fj
aGVNQWxsLExvb3BMYXp5LD48X3UkMS4yUG9seURpdixQb2x5U3BlYyxBdXRv
UHJvbW8sQ2FjaGVQQWxsLENhY2hlTUFsbCxMb29wTGF6eSw+PF92JDEuMlBv
bHlEaXYsUG9seVNwZWMsQXV0b1Byb21vLENhY2hlUEFsbCxDYWNoZU1BbGws
TG9vcExhenksPn0NClN0YXRpYyBUZW1wczoJeyh0NCxDYWNoZUFsbCx7X3Yk
MS4yLH0pLCh0MTMwLENhY2hlMVUse191JDEuMix9KSwodDg0LENhY2hlMVUs
e191JDEuMix9KX0NClByb21vdGVkIFRlbXBzOgl7fQ0KRGlzY29yZGFudCBU
ZW1wczoJe30NCkRlbW90ZWQgVGVtcHM6CXt9DQpTdGF0IDEyNwkNCkRpdmlz
aW9uIDA6CXs8X3UkMS4yUG9seURpdixQb2x5U3BlYyxBdXRvUHJvbW8sQ2Fj
aGVQQWxsLENhY2hlTUFsbCxMb29wTGF6eSw+PF91JDEuMlBvbHlEaXYsUG9s
eVNwZWMsQXV0b1Byb21vLENhY2hlUEFsbCxDYWNoZU1BbGwsTG9vcExhenks
PjxfdiQxLjJQb2x5RGl2LFBvbHlTcGVjLEF1dG9Qcm9tbyxDYWNoZVBBbGws
Q2FjaGVNQWxsLExvb3BMYXp5LD59DQpTdGF0aWMgVGVtcHM6CXsodDQsQ2Fj
aGVBbGwse192JDEuMix9KSwodDEzMCxDYWNoZTFVLHtfdSQxLjIsfSksKHQx
MjgsQ2FjaGUxVSx7X3UkMS4yLF92JDEuMix9KX0NClByb21vdGVkIFRlbXBz
Ogl7fQ0KRGlzY29yZGFudCBUZW1wczoJe30NCkRlbW90ZWQgVGVtcHM6CXt9
DQpGaW5hbCBCVEE6DQoNCkRpdmlzaW9uIDA6CXs8X3UkMS4yUG9seURpdixQ
b2x5U3BlYyxBdXRvUHJvbW8sQ2FjaGVQQWxsLENhY2hlTUFsbCxMb29wTGF6
eSw+PF91JDEuMlBvbHlEaXYsUG9seVNwZWMsQXV0b1Byb21vLENhY2hlUEFs
bCxDYWNoZU1BbGwsTG9vcExhenksPjxfdiQxLjJQb2x5RGl2LFBvbHlTcGVj
LEF1dG9Qcm9tbyxDYWNoZVBBbGwsQ2FjaGVNQWxsLExvb3BMYXp5LD59DQpT
dGF0aWMgVGVtcHM6CXsodDQsQ2FjaGVBbGwse192JDEuMix9KSwodDEzMCxD
YWNoZTFVLHtfdSQxLjIsfSksKHQxMjgsQ2FjaGUxVSx7X3UkMS4yLF92JDEu
Mix9KX0NClByb21vdGVkIFRlbXBzOgl7fQ0KRGlzY29yZGFudCBUZW1wczoJ
e30NCkRlbW90ZWQgVGVtcHM6CXt9DQpCYmxvY2sgMjcNCkluaXRpYWwgQlRB
Og0KDQpEaXZpc2lvbiAwOgl7PF91JDEuMlBvbHlEaXYsUG9seVNwZWMsQXV0
b1Byb21vLENhY2hlUEFsbCxDYWNoZU1BbGwsTG9vcExhenksPjxfdSQxLjJQ
b2x5RGl2LFBvbHlTcGVjLEF1dG9Qcm9tbyxDYWNoZVBBbGwsQ2FjaGVNQWxs
LExvb3BMYXp5LD48X3YkMS4yUG9seURpdixQb2x5U3BlYyxBdXRvUHJvbW8s
Q2FjaGVQQWxsLENhY2hlTUFsbCxMb29wTGF6eSw+fQ0KU3RhdGljIFRlbXBz
Ogl7KHQ0LENhY2hlQWxsLHtfdiQxLjIsfSksKHQxMzAsQ2FjaGUxVSx7X3Uk
MS4yLH0pLCh0MTI4LENhY2hlMVUse191JDEuMixfdiQxLjIsfSl9DQpQcm9t
b3RlZCBUZW1wczoJe30NCkRpc2NvcmRhbnQgVGVtcHM6CXt9DQpEZW1vdGVk
IFRlbXBzOgl7fQ0KU3RhdCAxMzkJDQpEaXZpc2lvbiAwOgl7PF91JDEuMlBv
bHlEaXYsUG9seVNwZWMsQXV0b1Byb21vLENhY2hlUEFsbCxDYWNoZU1BbGws
TG9vcExhenksPjxfdSQxLjJQb2x5RGl2LFBvbHlTcGVjLEF1dG9Qcm9tbyxD
YWNoZVBBbGwsQ2FjaGVNQWxsLExvb3BMYXp5LD48X3YkMS4yUG9seURpdixQ
b2x5U3BlYyxBdXRvUHJvbW8sQ2FjaGVQQWxsLENhY2hlTUFsbCxMb29wTGF6
eSw+fQ0KU3RhdGljIFRlbXBzOgl7KHQ0LENhY2hlQWxsLHtfdiQxLjIsfSks
KHQxMzAsQ2FjaGUxVSx7X3UkMS4yLH0pLCh0MTI4LENhY2hlMVUse191JDEu
MixfdiQxLjIsfSl9DQpQcm9tb3RlZCBUZW1wczoJe30NCkRpc2NvcmRhbnQg
VGVtcHM6CXt9DQpEZW1vdGVkIFRlbXBzOgl7fQ0KRmluYWwgQlRBOg0KDQpE
aXZpc2lvbiAwOgl7PF91JDEuMlBvbHlEaXYsUG9seVNwZWMsQXV0b1Byb21v
LENhY2hlUEFsbCxDYWNoZU1BbGwsTG9vcExhenksPjxfdSQxLjJQb2x5RGl2
LFBvbHlTcGVjLEF1dG9Qcm9tbyxDYWNoZVBBbGwsQ2FjaGVNQWxsLExvb3BM
YXp5LD48X3YkMS4yUG9seURpdixQb2x5U3BlYyxBdXRvUHJvbW8sQ2FjaGVQ
QWxsLENhY2hlTUFsbCxMb29wTGF6eSw+fQ0KU3RhdGljIFRlbXBzOgl7KHQ0
LENhY2hlQWxsLHtfdiQxLjIsfSksKHQxMzAsQ2FjaGUxVSx7X3UkMS4yLH0p
LCh0MTI4LENhY2hlMVUse191JDEuMixfdiQxLjIsfSl9DQpQcm9tb3RlZCBU
ZW1wczoJe30NCkRpc2NvcmRhbnQgVGVtcHM6CXt9DQpEZW1vdGVkIFRlbXBz
Ogl7fQ0KQmJsb2NrIDI4DQpJbml0aWFsIEJUQToNCg0KRGl2aXNpb24gMDoJ
ezxfdSQxLjJQb2x5RGl2LFBvbHlTcGVjLEF1dG9Qcm9tbyxDYWNoZVBBbGws
Q2FjaGVNQWxsLExvb3BMYXp5LD48X3UkMS4yUG9seURpdixQb2x5U3BlYyxB
dXRvUHJvbW8sQ2FjaGVQQWxsLENhY2hlTUFsbCxMb29wTGF6eSw+PF92JDEu
MlBvbHlEaXYsUG9seVNwZWMsQXV0b1Byb21vLENhY2hlUEFsbCxDYWNoZU1B
bGwsTG9vcExhenksPn0NClN0YXRpYyBUZW1wczoJeyh0NCxDYWNoZUFsbCx7
X3YkMS4yLH0pLCh0MTMwLENhY2hlMVUse191JDEuMix9KSwodDEyOCxDYWNo
ZTFVLHtfdSQxLjIsX3YkMS4yLH0pfQ0KUHJvbW90ZWQgVGVtcHM6CXt9DQpE
aXNjb3JkYW50IFRlbXBzOgl7fQ0KRGVtb3RlZCBUZW1wczoJe30NClN0YXQg
MTQ0CQ0KRGl2aXNpb24gMDoJezxfdSQxLjJQb2x5RGl2LFBvbHlTcGVjLEF1
dG9Qcm9tbyxDYWNoZVBBbGwsQ2FjaGVNQWxsLExvb3BMYXp5LD48X3UkMS4y
UG9seURpdixQb2x5U3BlYyxBdXRvUHJvbW8sQ2FjaGVQQWxsLENhY2hlTUFs
bCxMb29wTGF6eSw+PF92JDEuMlBvbHlEaXYsUG9seVNwZWMsQXV0b1Byb21v
LENhY2hlUEFsbCxDYWNoZU1BbGwsTG9vcExhenksPn0NClN0YXRpYyBUZW1w
czoJeyh0NCxDYWNoZUFsbCx7X3YkMS4yLH0pLCh0MTMwLENhY2hlMVUse191
JDEuMix9KSwodDEyOCxDYWNoZTFVLHtfdSQxLjIsX3YkMS4yLH0pfQ0KUHJv
bW90ZWQgVGVtcHM6CXt9DQpEaXNjb3JkYW50IFRlbXBzOgl7fQ0KRGVtb3Rl
ZCBUZW1wczoJe30NClN0YXQgMTQ2CQ0KRGl2aXNpb24gMDoJezxfdSQxLjJQ
b2x5RGl2LFBvbHlTcGVjLEF1dG9Qcm9tbyxDYWNoZVBBbGwsQ2FjaGVNQWxs
LExvb3BMYXp5LD48X3UkMS4yUG9seURpdixQb2x5U3BlYyxBdXRvUHJvbW8s
Q2FjaGVQQWxsLENhY2hlTUFsbCxMb29wTGF6eSw+PF92JDEuMlBvbHlEaXYs
UG9seVNwZWMsQXV0b1Byb21vLENhY2hlUEFsbCxDYWNoZU1BbGwsTG9vcExh
enksPn0NClN0YXRpYyBUZW1wczoJeyh0NCxDYWNoZUFsbCx7X3YkMS4yLH0p
LCh0MTMwLENhY2hlMVUse191JDEuMix9KSwodDEyOCxDYWNoZTFVLHtfdSQx
LjIsX3YkMS4yLH0pfQ0KUHJvbW90ZWQgVGVtcHM6CXt9DQpEaXNjb3JkYW50
IFRlbXBzOgl7fQ0KRGVtb3RlZCBUZW1wczoJe30NClN0YXQgMTQ1CQ0KRGl2
aXNpb24gMDoJezxfdSQxLjJQb2x5RGl2LFBvbHlTcGVjLEF1dG9Qcm9tbyxD
YWNoZVBBbGwsQ2FjaGVNQWxsLExvb3BMYXp5LD48X3UkMS4yUG9seURpdixQ
b2x5U3BlYyxBdXRvUHJvbW8sQ2FjaGVQQWxsLENhY2hlTUFsbCxMb29wTGF6
eSw+PF92JDEuMlBvbHlEaXYsUG9seVNwZWMsQXV0b1Byb21vLENhY2hlUEFs
bCxDYWNoZU1BbGwsTG9vcExhenksPn0NClN0YXRpYyBUZW1wczoJeyh0NCxD
YWNoZUFsbCx7X3YkMS4yLH0pLCh0MTMwLENhY2hlMVUse191JDEuMix9KSwo
dDEyOCxDYWNoZTFVLHtfdSQxLjIsX3YkMS4yLH0pfQ0KUHJvbW90ZWQgVGVt
cHM6CXt9DQpEaXNjb3JkYW50IFRlbXBzOgl7fQ0KRGVtb3RlZCBUZW1wczoJ
e30NCkZpbmFsIEJUQToNCg0KRGl2aXNpb24gMDoJezxfdSQxLjJQb2x5RGl2
LFBvbHlTcGVjLEF1dG9Qcm9tbyxDYWNoZVBBbGwsQ2FjaGVNQWxsLExvb3BM
YXp5LD48X3UkMS4yUG9seURpdixQb2x5U3BlYyxBdXRvUHJvbW8sQ2FjaGVQ
QWxsLENhY2hlTUFsbCxMb29wTGF6eSw+PF92JDEuMlBvbHlEaXYsUG9seVNw
ZWMsQXV0b1Byb21vLENhY2hlUEFsbCxDYWNoZU1BbGwsTG9vcExhenksPn0N
ClN0YXRpYyBUZW1wczoJeyh0NCxDYWNoZUFsbCx7X3YkMS4yLH0pLCh0MTMw
LENhY2hlMVUse191JDEuMix9KSwodDEyOCxDYWNoZTFVLHtfdSQxLjIsX3Yk
MS4yLH0pfQ0KUHJvbW90ZWQgVGVtcHM6CXt9DQpEaXNjb3JkYW50IFRlbXBz
Ogl7fQ0KRGVtb3RlZCBUZW1wczoJe30NCkJibG9jayAzMw0KSW5pdGlhbCBC
VEE6DQoNCkRpdmlzaW9uIDA6CXs8X3UkMS4yUG9seURpdixQb2x5U3BlYyxB
dXRvUHJvbW8sQ2FjaGVQQWxsLENhY2hlTUFsbCxMb29wTGF6eSw+PF91JDEu
MlBvbHlEaXYsUG9seVNwZWMsQXV0b1Byb21vLENhY2hlUEFsbCxDYWNoZU1B
bGwsTG9vcExhenksPjxfdiQxLjJQb2x5RGl2LFBvbHlTcGVjLEF1dG9Qcm9t
byxDYWNoZVBBbGwsQ2FjaGVNQWxsLExvb3BMYXp5LD59DQpTdGF0aWMgVGVt
cHM6CXsodDQsQ2FjaGVBbGwse192JDEuMix9KSwodDEzMCxDYWNoZTFVLHtf
dSQxLjIsfSksKHQxMjgsQ2FjaGUxVSx7X3UkMS4yLF92JDEuMix9KX0NClBy
b21vdGVkIFRlbXBzOgl7fQ0KRGlzY29yZGFudCBUZW1wczoJe30NCkRlbW90
ZWQgVGVtcHM6CXt9DQpTdGF0IDEzMwkNCkRpdmlzaW9uIDA6CXs8X3UkMS4y
UG9seURpdixQb2x5U3BlYyxBdXRvUHJvbW8sQ2FjaGVQQWxsLENhY2hlTUFs
bCxMb29wTGF6eSw+PF91JDEuMlBvbHlEaXYsUG9seVNwZWMsQXV0b1Byb21v
LENhY2hlUEFsbCxDYWNoZU1BbGwsTG9vcExhenksPjxfdiQxLjJQb2x5RGl2
LFBvbHlTcGVjLEF1dG9Qcm9tbyxDYWNoZVBBbGwsQ2FjaGVNQWxsLExvb3BM
YXp5LD59DQpTdGF0aWMgVGVtcHM6CXsodDQsQ2FjaGVBbGwse192JDEuMix9
KSwodDEzMCxDYWNoZTFVLHtfdSQxLjIsfSksKHQxMjgsQ2FjaGUxVSx7X3Uk
MS4yLF92JDEuMix9KX0NClByb21vdGVkIFRlbXBzOgl7fQ0KRGlzY29yZGFu
dCBUZW1wczoJe30NCkRlbW90ZWQgVGVtcHM6CXt9DQpTdGF0IDEzNwkNCkRp
dmlzaW9uIDA6CXs8X3UkMS4yUG9seURpdixQb2x5U3BlYyxBdXRvUHJvbW8s
Q2FjaGVQQWxsLENhY2hlTUFsbCxMb29wTGF6eSw+PF91JDEuMlBvbHlEaXYs
UG9seVNwZWMsQXV0b1Byb21vLENhY2hlUEFsbCxDYWNoZU1BbGwsTG9vcExh
enksPjxfdiQxLjJQb2x5RGl2LFBvbHlTcGVjLEF1dG9Qcm9tbyxDYWNoZVBB
bGwsQ2FjaGVNQWxsLExvb3BMYXp5LD59DQpTdGF0aWMgVGVtcHM6CXsodDQs
Q2FjaGVBbGwse192JDEuMix9KSwodDEzMCxDYWNoZTFVLHtfdSQxLjIsfSks
KHQxMjgsQ2FjaGUxVSx7X3UkMS4yLF92JDEuMix9KX0NClByb21vdGVkIFRl
bXBzOgl7fQ0KRGlzY29yZGFudCBUZW1wczoJe30NCkRlbW90ZWQgVGVtcHM6
CXt9DQpGaW5hbCBCVEE6DQoNCkRpdmlzaW9uIDA6CXs8X3UkMS4yUG9seURp
dixQb2x5U3BlYyxBdXRvUHJvbW8sQ2FjaGVQQWxsLENhY2hlTUFsbCxMb29w
TGF6eSw+PF91JDEuMlBvbHlEaXYsUG9seVNwZWMsQXV0b1Byb21vLENhY2hl
UEFsbCxDYWNoZU1BbGwsTG9vcExhenksPjxfdiQxLjJQb2x5RGl2LFBvbHlT
cGVjLEF1dG9Qcm9tbyxDYWNoZVBBbGwsQ2FjaGVNQWxsLExvb3BMYXp5LD59
DQpTdGF0aWMgVGVtcHM6CXsodDQsQ2FjaGVBbGwse192JDEuMix9KSwodDEz
MCxDYWNoZTFVLHtfdSQxLjIsfSksKHQxMjgsQ2FjaGUxVSx7X3UkMS4yLF92
JDEuMix9KX0NClByb21vdGVkIFRlbXBzOgl7fQ0KRGlzY29yZGFudCBUZW1w
czoJe30NCkRlbW90ZWQgVGVtcHM6CXt9DQpCYmxvY2sgMjkNCkluaXRpYWwg
QlRBOg0KDQpEaXZpc2lvbiAwOgl7PF91JDEuMlBvbHlEaXYsUG9seVNwZWMs
QXV0b1Byb21vLENhY2hlUEFsbCxDYWNoZU1BbGwsTG9vcExhenksPjxfdSQx
LjJQb2x5RGl2LFBvbHlTcGVjLEF1dG9Qcm9tbyxDYWNoZVBBbGwsQ2FjaGVN
QWxsLExvb3BMYXp5LD48X3YkMS4yUG9seURpdixQb2x5U3BlYyxBdXRvUHJv
bW8sQ2FjaGVQQWxsLENhY2hlTUFsbCxMb29wTGF6eSw+fQ0KU3RhdGljIFRl
bXBzOgl7KHQ0LENhY2hlQWxsLHtfdiQxLjIsfSksKHQxMzAsQ2FjaGUxVSx7
X3UkMS4yLH0pfQ0KUHJvbW90ZWQgVGVtcHM6CXt9DQpEaXNjb3JkYW50IFRl
bXBzOgl7fQ0KRGVtb3RlZCBUZW1wczoJe30NClN0YXQgMTU3CQ0KRGl2aXNp
b24gMDoJezxfdSQxLjJQb2x5RGl2LFBvbHlTcGVjLEF1dG9Qcm9tbyxDYWNo
ZVBBbGwsQ2FjaGVNQWxsLExvb3BMYXp5LD48X3UkMS4yUG9seURpdixQb2x5
U3BlYyxBdXRvUHJvbW8sQ2FjaGVQQWxsLENhY2hlTUFsbCxMb29wTGF6eSw+
PF92JDEuMlBvbHlEaXYsUG9seVNwZWMsQXV0b1Byb21vLENhY2hlUEFsbCxD
YWNoZU1BbGwsTG9vcExhenksPn0NClN0YXRpYyBUZW1wczoJeyh0NCxDYWNo
ZUFsbCx7X3YkMS4yLH0pLCh0MTMwLENhY2hlMVUse191JDEuMix9KX0NClBy
b21vdGVkIFRlbXBzOgl7fQ0KRGlzY29yZGFudCBUZW1wczoJe30NCkRlbW90
ZWQgVGVtcHM6CXt9DQpTdGF0IDE1NgkNCkRpdmlzaW9uIDA6CXs8X3UkMS4y
UG9seURpdixQb2x5U3BlYyxBdXRvUHJvbW8sQ2FjaGVQQWxsLENhY2hlTUFs
bCxMb29wTGF6eSw+PF91JDEuMlBvbHlEaXYsUG9seVNwZWMsQXV0b1Byb21v
LENhY2hlUEFsbCxDYWNoZU1BbGwsTG9vcExhenksPjxfdiQxLjJQb2x5RGl2
LFBvbHlTcGVjLEF1dG9Qcm9tbyxDYWNoZVBBbGwsQ2FjaGVNQWxsLExvb3BM
YXp5LD59DQpTdGF0aWMgVGVtcHM6CXsodDQsQ2FjaGVBbGwse192JDEuMix9
KSwodDEzMCxDYWNoZTFVLHtfdSQxLjIsfSl9DQpQcm9tb3RlZCBUZW1wczoJ
e30NCkRpc2NvcmRhbnQgVGVtcHM6CXt9DQpEZW1vdGVkIFRlbXBzOgl7fQ0K
RmluYWwgQlRBOg0KDQpEaXZpc2lvbiAwOgl7PF92JDEuMlBvbHlEaXYsUG9s
eVNwZWMsQXV0b1Byb21vLENhY2hlUEFsbCxDYWNoZU1BbGwsTG9vcExhenks
Pn0NClN0YXRpYyBUZW1wczoJeyh0NCxDYWNoZUFsbCx7X3YkMS4yLH0pfQ0K
UHJvbW90ZWQgVGVtcHM6CXt9DQpEaXNjb3JkYW50IFRlbXBzOgl7fQ0KRGVt
b3RlZCBUZW1wczoJezAsfQ0KQmJsb2NrIDMwDQpJbml0aWFsIEJUQToNCg0K
RGl2aXNpb24gMDoJezxfdiQxLjJQb2x5RGl2LFBvbHlTcGVjLEF1dG9Qcm9t
byxDYWNoZVBBbGwsQ2FjaGVNQWxsLExvb3BMYXp5LD59DQpTdGF0aWMgVGVt
cHM6CXsodDQsQ2FjaGVBbGwse192JDEuMix9KX0NClByb21vdGVkIFRlbXBz
Ogl7fQ0KRGlzY29yZGFudCBUZW1wczoJe30NCkRlbW90ZWQgVGVtcHM6CXsw
LH0NClN0YXQgMTU5CQ0KRGl2aXNpb24gMDoJezxfdiQxLjJQb2x5RGl2LFBv
bHlTcGVjLEF1dG9Qcm9tbyxDYWNoZVBBbGwsQ2FjaGVNQWxsLExvb3BMYXp5
LD59DQpTdGF0aWMgVGVtcHM6CXsodDQsQ2FjaGVBbGwse192JDEuMix9KX0N
ClByb21vdGVkIFRlbXBzOgl7fQ0KRGlzY29yZGFudCBUZW1wczoJe30NCkRl
bW90ZWQgVGVtcHM6CXswLH0NCkZpbmFsIEJUQToNCg0KRGl2aXNpb24gMDoJ
e30NClN0YXRpYyBUZW1wczoJe30NClByb21vdGVkIFRlbXBzOgl7fQ0KRGlz
Y29yZGFudCBUZW1wczoJe30NCkRlbW90ZWQgVGVtcHM6CXsyLH0NCkJibG9j
ayAzMQ0KSW5pdGlhbCBCVEE6DQoNCkRpdmlzaW9uIDA6CXt9DQpTdGF0aWMg
VGVtcHM6CXt9DQpQcm9tb3RlZCBUZW1wczoJe30NCkRpc2NvcmRhbnQgVGVt
cHM6CXt9DQpEZW1vdGVkIFRlbXBzOgl7Mix9DQpTdGF0IDE2MwkNCkRpdmlz
aW9uIDA6CXt9DQpTdGF0aWMgVGVtcHM6CXt9DQpQcm9tb3RlZCBUZW1wczoJ
e30NCkRpc2NvcmRhbnQgVGVtcHM6CXt9DQpEZW1vdGVkIFRlbXBzOgl7Mix9
DQpGaW5hbCBCVEE6DQoNCkRpdmlzaW9uIDA6CXt9DQpTdGF0aWMgVGVtcHM6
CXt9DQpQcm9tb3RlZCBUZW1wczoJe30NCkRpc2NvcmRhbnQgVGVtcHM6CXt9
DQpEZW1vdGVkIFRlbXBzOgl7fQ0KQmJsb2NrIDMyDQpJbml0aWFsIEJUQToN
Cg0KRGl2aXNpb24gMDoJe30NClN0YXRpYyBUZW1wczoJe30NClByb21vdGVk
IFRlbXBzOgl7fQ0KRGlzY29yZGFudCBUZW1wczoJe30NCkRlbW90ZWQgVGVt
cHM6CXt9DQpTdGF0IDE2NQkNCkRpdmlzaW9uIDA6CXt9DQpTdGF0aWMgVGVt
cHM6CXt9DQpQcm9tb3RlZCBUZW1wczoJe30NCkRpc2NvcmRhbnQgVGVtcHM6
CXt9DQpEZW1vdGVkIFRlbXBzOgl7fQ0KRmluYWwgQlRBOg0KDQpEaXZpc2lv
biAwOgl7fQ0KU3RhdGljIFRlbXBzOgl7fQ0KUHJvbW90ZWQgVGVtcHM6CXt9
DQpEaXNjb3JkYW50IFRlbXBzOgl7fQ0KRGVtb3RlZCBUZW1wczoJe30=
--1602278152-1495322112-872932549=:2003--

Date: Sat, 30 Aug 1997 16:49:14 -0700 (PDT)
From: "Markus U. Mock" <mock@cs.washington.edu>
To: spin-comp@cs.washington.edu
Subject: BTA checked in

I've checked the BTA in.  

I also changed the pmakefile to use as temp directory /var/tmp/$(USER) so
that different people can compile on the same machine at the same time,
otherwise, if temp files did not get cleaned up properly (as on meitner)
you'd run into a problem. 

The BTA now computes the divisions, static temps, promotions, demotions
and discordant vars. The next step is getting the laziness info running
and splitting the graph for different divisions. 


	-- Markus 



To: "Markus U. Mock" <mock@cs.washington.edu>
cc: spin-comp-archive@cs
Subject: more on the BTA interface
Date: Sun, 31 Aug 1997 14:25:36 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

As it turns out, I need to be able to attach BTAs to BBLOCKs and STATs that
I create.

BBLOCKs look straightforward:
	    DYC2_BTA        dyc2_initial_bta; 
	    DYC2_BTA        dyc2_final_bta; 

However, I see several fields on STATs:
    DYC2_BTA_OpType    dyc2_btaOpType; /* MM new bta info */
    BOOL               dyc2_staticOp; /* MM set true if operation static */
    DYC2_VAR_W_POLICIES dyc2_annot;
    DYC2_BTA            dyc2_bta;

What are btaOpType and annot?  Can I set these other three fields just from
a DYC2_BTA?  Do you have a routine that does this?

Thanks.
--Brian

Date: Sun, 31 Aug 1997 15:11:38 -0700 (PDT)
From: "Markus U. Mock" <mock@cs.washington.edu>
To: Brian Grant <grant@thistle.cs.washington.edu>
cc: Markus Mock <mock@cs.washington.edu>, spin-comp-archive@cs.washington.edu
Subject: Re: more on the BTA interface


   As it turns out, I need to be able to attach BTAs to BBLOCKs and STATs that
   I create.
   
   BBLOCKs look straightforward:
   	    DYC2_BTA        dyc2_initial_bta; 
   	    DYC2_BTA        dyc2_final_bta; 
   
   However, I see several fields on STATs:
       DYC2_BTA_OpType    dyc2_btaOpType; /* MM new bta info */
       BOOL               dyc2_staticOp; /* MM set true if operation static */
       DYC2_VAR_W_POLICIES dyc2_annot;
       DYC2_BTA            dyc2_bta;
   
   What are btaOpType and annot?  Can I set these other three fields just from
   a DYC2_BTA?  Do you have a routine that does this?



dyc2_btaOpType:
	 tells the bta if the stat is an annotation or a normal op, used
	during IDFA

dyc2_staticOp:
	set to true if the operation was computed to be static, false
	otherwise

dyc2_annot:
	is the internal representation of a variable and its policies at 
	a stat that is a makestatic / makedynamic annotation

If you want to run flow functions again on some stats, these should be
copied when you create or copy stats.

If you want to I can create a function


VOID STAT_copy_BTA(STAT dest, STAT from)
VOID BBLOCK_copy_BTA(BBLOCK dest, BBLOCK from)

that copies all that bta info (including the dyc2_bta) from one
stat/bblock to another.
How's that?

	-- Markus



To: matthai@thistle.cs.washington.edu
cc: spin-comp-archive@cs
Subject: dyc_LastBranch2 and extra br instructions
Date: Sun, 31 Aug 1997 23:23:11 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

Matthai,

I think the right thing to do is to insert an unconditional branch following
the conditional one whenever both branches go to dynamic (i.e., template)
units.  If the last br of the unit is not needed, I can overwrite it.
Or, do you think it isn't difficult for the merger to figure out when not
to insert them?

--Brian

To: matthai@thistle.cs.washington.edu
cc: spin-comp-archive@cs
Subject: no need for dyc_LastBranch2
Date: Mon, 01 Sep 1997 00:17:02 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

Actually, I guess there is no need for dyc_LastBranch2 since I know when
I need to patch that second branch and that it immediately follows the
conditional branch.

--Brian

To: spin-comp@franklin.cs.washington.edu
Subject: "static" annotation in place
Date: Tue, 02 Sep 1997 15:49:15 PDT
From: Matthai Philipose <matthai@franklin.cs.washington.edu>

I just finished testing the "static" annotation for memory
dereferences. There is a slight change in syntax. Instead of
the "static" key-word, I use the "@" symbol. So dereferences look like:
@*foo
foo@.bar
foo@->bar
foo@[bar]

Given a STAT "stat", the following macro returns a BOOL which is true
iff the STAT corresponds to a source-level static dereference:
	STAT_op_part_get(stat,dyc_static_deref) 

Charlie very generously spent most of Friday helping me with hacking 
this. Though hacking the front end was a learning experience for him 
too, he was a _huge_ help. 
		Matthai


------------------sample program:
#include <stdio.h>


int arr[3]={0,1,2};

struct foo{
int bar;
double baz;
}foos;

struct foo* foop;

int main(void)
{
  int num;
  int *two=(&arr[2]);
  foop=(&foos);

  scanf("%d",&num);

  arr[2]=num+20;
  foos.bar=num+30;
  foop->baz=num+40.0;


  printf("%d %d %lf %d",arr@[2],foos@.bar,foop@->baz,@*two);

  return 0;
}


To: spin-comp@franklin.cs.washington.edu
Subject: ps on static dereferences...
Date: Tue, 02 Sep 1997 15:58:03 PDT
From: Matthai Philipose <matthai@franklin.cs.washington.edu>

I have modified the IR formatting routines to prepend
all static dereferences with the string "DYC_STATIC_DEREF."

The static dereference bit is propagated through to the BTA,
but not through the subsequent memory operation expansion
stages.

The relevant code is all checked in.
	Matthai

To: mock@thistle.cs.washington.edu
cc: spin-comp-archive@cs
Subject: scary memory usage in bta_sets-v2.C
Date: Tue, 02 Sep 1997 16:16:06 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

I took a look at bta_sets-v2.C and noticed a few distressing things:

1) You use free().  Is that #defined to be something else?  I didn't find
any defintions of it in the header files.  I don't think we should ever be
using the standard free.  We never just malloc anything, right?  free() is
used on objects allocated from your pool by dyc_malloc.  That seems bad.
Could you please explain what is going on here?

2) You create a lot of bitsets, and then free them.  That seems expensive.
There are in-place versions of all the bit operations, and it seems
like you should be using them.  Was there a reason why you didn't?

For example:

BS DYC2_TEMPSET_to_BS(DYC2_TEMPSET s)
{
  BS bs, bs1, t;
  int i;
  DYC2_TEMP v;

  bs = BS_CreateEmpty(s->size, dyc_malloc);

  for (i=0;i<s->size;i++) {
    v = (DYC2_TEMP) s->element[i];
    t = BS_Singleton( v->tempnum, dyc_malloc);
    bs1 = bs;
    bs = BS_Union(bs, t, dyc_malloc);
    free(t); free(bs1);
  }

  return bs;
}

could be implemented as:

BS DYC2_TEMPSET_to_BS(DYC2_TEMPSET s)
{
  BS bs;
  int i;
  DYC2_TEMP v;

  bs = BS_CreateEmpty(s->size, dyc_malloc);

  for (i=0;i<s->size;i++) {
    v = (DYC2_TEMP) s->element[i];
    bs = BS_Union1D(bs, v->tempnum, dyc_malloc);
  }

  return bs;
}

--Brian

Date: Wed, 3 Sep 1997 12:12:30 -0700 (PDT)
From: Markus Mock <mock@apex.cs.washington.edu>
To: Brian Grant <grant@cs>, spin-comp-archive@cs
cc: Markus Mock <mock@cs>
Subject: bta interface

I checked in the two interface functions and took out the calls to free
for now.


	-- Markus


To: spin-comp@thistle.cs.washington.edu
Subject: major commit of port to new BTA, multiple units, scripts, etc.
Date: Thu, 04 Sep 1997 01:18:54 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

1) I put two new scripts in /afs/cs/project/dyncomp/bin.
	what-update
		Tells you what files are modified, out of date, etc. with
		respect to the CVS archive without all the cruft that
		"cvs -n update" normally gives you.
	do-update
		Actually does the CVS update; has the same pruned output as
		what-update.

2) I put a new script in DyC/bin:
	dcmake [-ms]
		Build an application to be dynamically compiled.  This
		uses the Makefiles I put in place a while ago.  I had
		been using this as a bash function, but decided it was
		time to share it.  It is pretty straightforward to use.
		E.g., if you need a preprocessed version of mytest.DyC for
		debugging, just type "dcmake mytest.i".  Use -ms with the
		new BTA.

3) The boilerplate is now automatically versioned.  If the boilerplate in
your preprocessed file doesn't match what your version of the
compiler expects (though, it should always match if you use dcmake), then
the compiler will tell you which is out of date.

4) I have introduced several new source files in p2dyc.  The one you
probably care the most about is bta_version.H.  It defines (or not)
the macro DYC_NEW_BTA.  In any file in which a BTA header file is included,
you must include this file before it.  See any .C file in p2dyc for an
example.  I checked in the version that uses the new BTA.  If you need a
version that doesn't crash in p2dyc, then you'll probably want to comment
out the #define in this header before compiling to get a version that works
with the old BTA (Matthai, I'm talking to you :-).

5) The merger is still out of date with respect to the new output spec,
and the compiler's inter-unit branch patching support is out of spec,
so don't try to build executables yet (i.e., "dcmake mytest.x").

6) Life is easier with breakpoints in all major error routines.  I have
the following dbx.in (works with both BTAs):
source /afs/cs/project/dyncomp/grant/DyC/bin/gdb-macros
dir /afs/cs/project/dyncomp/grant/DyC/mflow/
cd /afs/cs/project/dyncomp/grant/Test/test2
b ERR_AssertFailed
b ERR_Error
b DYC_assert
b dyc_btaReportError
b dyc_btaReportErrorStat
run -mmain_arg_file=/afs/cs/project/dyncomp/grant/Test/test2/ccomargs.in

7) Remember to do your update in DyC, not just DyC/mflow, as I've modified
files in all major subdirectories.

If you have trouble, let me know.  I have tested it with both versions
of the BTA (and I know that the version with the new BTA seg faults).

We're getting there!
--Brian

To: Matthai Philipose <matthai@cs.washington.edu>
cc: spin-comp-archive@cs
Subject: Re: Unconditional branches between units 
Date: Thu, 04 Sep 1997 21:05:10 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

>> My understanding of the spec is that unconditional branches between
>> template units/ from unit to static code are marked by DYC.NO_BRANCH
>> markers. When exactly are the NO_BRANCHes followed by igotos to their
>> intended successors? When the successors are static units? Or when
>> the successor is such that no natural basic block boundary across the
>> units? Can the igotos target both static and dynamic code?

Right.

Unconditional branches from a template unit to a template or static unit
have the NO_BRANCH markers.  I only insert IGOTOs on fall-throughs from
a template unit to a static unit.  So, in test2.pms, I see one NO_BRANCH
to another template unit with no IGOTO or unconditional branch, another
NO_BRANCH label preceding an unconditional branch, and a NO_BRANCH label
preceding an IGOTO.

So, IGOTOs only go to static code.  They don't go to dynamic code for two
reasons:
	1) We don't know how to allocate space for the jump destination and
	then patch it (though we have to figure this out eventually).
	2) We figured inserting an unconditional branch would be easy since
	it has to be done in other cases.  We didn't really determine whether
	it should be done by the merger or by my run-time support.  It
	would be easier for me for the merger to put it in so I can patch
	it.  That is what my code is designed to do now in this case.

Sound ok?  Any problems you've thought of or are worried about?

--Brian

To: spin-comp@thistle.cs.washington.edu
Subject: port to new BTA completed
Date: Fri, 05 Sep 1997 09:38:01 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

The port to the new BTA is finished.  Development using the old BTA has now
stopped.  The simple multi-unit example goes through the compiler using the
new BTA and produces the same output as with the old BTA.  Demotions should
be working shortly as well.  So, once the last few merger modifications are
completed, we will be able to test the entire pipeline.

--Brian

To: mock@thistle.cs.washington.edu
cc: spin-comp-archive@cs
Subject: program points and BTA info
Date: Fri, 05 Sep 1997 11:25:25 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

Markus,

[By point-specific info, I mean promotions, demotions, discordant temps, and
(eventually) lazy edges.]

In the current example demotions(*) appear at the end of one block and at
the beginning of the next block.  This is not good.

(* The demotions shouldn't be there at all, but they did illustrate this
problem with interpreting the output of the BTA.)

I need to determine which point-specific info to use, so I'm proposing the
following convention.  Let me know if it contrasts sharply with the
implementation.

I'm assuming all point-specific BTA information can be unambiguously found
by looking at the initial BTAs of the STATs and at the final BTAs of the
blocks.  Some implications of this are:

	-- The point-specific info of the final BTA of a block cannot be
	   duplicated at the beginning of the next block.  It should be easy
	   enough to check this and create a partial copy if necessary (which
	   may then have different point-specific info, e.g. discordant temps,
	   attached to it).

	-- The initial BTA of a block should be identical to the intial BTA of
	   the first STAT of that block (if the block contains STATs).

I've settled on this because the BTA already seems to associate the program
point prior to a STAT with the STAT (i.e.g, STAT_dyc2_bta(Stat) is the initial
BTA of Stat).

Let me know what you think.

--Brian

To: mock@thistle.cs.washington.edu
cc: spin-comp-archive@cs
Subject: one more thing about the BTA output
Date: Fri, 05 Sep 1997 11:41:49 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

In the case of an empty BBLOCK (though I think this shouldn't arise), the
point-specific info of the initial/final BTA should not be duplicated in the
final/initial BTA of that block or of previous/next blocks.

--Brian

Date: Fri, 5 Sep 1997 12:56:44 -0700 (PDT)
From: "Markus U. Mock" <mock@cs.washington.edu>
To: grant@cs.washington.edu
cc: mock@thistle.cs.washington.edu, spin-comp-archive@cs.washington.edu
Subject: Re: program points and BTA info

On Fri, 5 Sep 1997, Brian Grant wrote:

   
   
   I'm assuming all point-specific BTA information can be unambiguously found
   by looking at the initial BTAs of the STATs and at the final BTAs of the
   blocks.  Some implications of this are:

CORRECT
   
   	-- The point-specific info of the final BTA of a block cannot be
   	   duplicated at the beginning of the next block.  It should be easy
   	   enough to check this and create a partial copy if necessary (which
   	   may then have different point-specific info, e.g. discordant temps,
   	   attached to it).
   
   	-- The initial BTA of a block should be identical to the intial BTA of
   	   the first STAT of that block (if the block contains STATs).
   
   I've settled on this because the BTA already seems to associate the program
   point prior to a STAT with the STAT (i.e.g, STAT_dyc2_bta(Stat) is the initial
   BTA of Stat).
   
That sounds good. I'll fix that by introducing partical copies as you
suggested.

I'll check why we have a demotion in the example and fix that. I hope to
have this done in a few hours, ok?

	-- Markus



Date: Mon, 8 Sep 1997 17:08:38 -0700 (PDT)
From: chambers@klamath (Craig Chambers)
To: grant@cs.washington.edu, spin-comp@thistle.cs.washington.edu
Subject: Re: port to new BTA completed

Congratulations!

-- Craig

Date: Tue, 9 Sep 1997 15:47:10 -0700 (PDT)
From: Markus Mock <mock@apex.cs.washington.edu>
To: Brian Grant <grant@cs>, spin-comp-archive@cs,
cc: Markus Mock <mock@cs>
Subject: bta checked in

I checked in the new version with the fixed BTA merge. t166 is now demoted
at the beginnin of bblock 37.


	-- Markus


To: mock@thistle.cs.washington.edu, matthai@thistle.cs.washington.edu
cc: spin-comp-archive@cs
Subject: demotions -- argh
Date: Wed, 10 Sep 1997 03:44:56 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

Demotions are trickier than I thought due to two reasons that I had
forgotten:

	1) Place-holder stores must be inserted in corresponding locations
	in the setup code.  This was a pain, but fairly straightforward.

	2) I actually need the demoVars in the BTA on the last STAT(s) where
	the demoted variables were actually static, not in the BTA of the
	first STAT where the TEMPs aren't static.  I looked through bta-v2.C
	and made changes to my copy (not committed yet) that I think will
	do this for the easy cases.  However, I'm not sure how to do it
	for the merge.  Markus -- I could use some help with that.  Basically,
	demoVars needs to be updated for every final bblock BTA leading to
	the merge.  This looks like a pain.  The other option is to leave
	the demotion information where it is now and then hoist it later.
	This may sound easier, but it also seems no better since it has the
	same problems with matching divisions and filtering demoVars based
	on the StaticVarInfo.

--Brian

To: spin-comp@thistle.cs.washington.edu
Subject: it works!!!
Date: Wed, 10 Sep 1997 11:43:31 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

I don't think it is too soon to proclaim victory!  Except for a small bug
(possibly in the merger?) in generating a handful of floating-point
instructions, the small multi-unit example works.

It was more difficult than expected to properly handle demotions (when a
live static temp is killed, we need to reload the static value into its
original temp) working.  One reason was that the demotion information looks
ahead by one program point.  We need to know when a temp will no longer be
static (but currently still is, so we can get the value).  The easiest way
to do this was to have the BTA compute what live static temps have been
dropped from the set of static temps, and then have a post-pass hoist these
sets to the BTA info on the previous program points.  There was additional
trouble in figuring out where to insert the loads in the template code and
associated stores in the setup code (the stores are converted to hole-filling
code by the merger).

On to caching...

--Brian

Date: Wed, 10 Sep 1997 11:49:41 -0700 (PDT)
From: chambers@klamath (Craig Chambers)
To: spin-comp@thistle.cs.washington.edu, grant@cs.washington.edu
Subject: Re: it works!!!


Fantastic!!

-- Craig

P.S.  See you all Thurs at 3pm.

Date: Wed, 10 Sep 1997 22:14:29 -0700
From: Matthai Philipose <matthai@cs.washington.edu>
To: spin-comp@cs.washington.edu
Subject: Simple multi-unit example works (fully)!

I just fixed the floating-point instruction emission code (it turns out
that
some fp instructions only have two arg registers, and this wasn't
expected), and the
simple multi-unit example now seems to work along all paths.

In the meantime, I have identified a few efficiency hacks I want to get
out
of the way tomorrow.
                        Matthai


Date: Thu, 11 Sep 1997 13:02:12 -0700 (PDT)
From: Markus Mock <mock@apex.cs.washington.edu>
To: Matthai Philipose <matthai@cs>, spin-comp-archive@cs
Subject: OP_part_get_dyc_static_deref(op)

Matthai,

can I assume that this returns 0 iff the load is not static? I.e. is this
the right macro to use?

	-- Markus


To: grant@cs.washington.edu
Cc: spin-comp@thistle.cs.washington.edu, eggers@pa.dec.com
Subject: Re: it works!!! 
Date: Thu, 11 Sep 97 14:31:04 -0700
From: Susan Eggers <eggers@pa.dec.com>

Great news.

What's your "large multi-unit example"?

Susan


To: spin-comp@thistle.cs.washington.edu
Subject: cache_one_unchecked
Date: Fri, 12 Sep 1997 11:36:44 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

It's working.

--Brian

Date: Fri, 12 Sep 1997 11:48:03 -0700 (PDT)
From: chambers@klamath (Craig Chambers)
To: spin-comp@thistle.cs.washington.edu, grant@cs.washington.edu
Subject: Re: cache_one_unchecked

> From grant@thistle.cs.washington.edu  Fri Sep 12 11:36:52 1997
> Delivery-Date: Fri, 12 Sep 1997 11:36:53 PDT
> X-Mailer: exmh version 1.5.3 12/28/94
> Reply-To: grant@cs.washington.edu
> To: spin-comp@thistle.cs.washington.edu
> Subject: cache_one_unchecked
> Mime-Version: 1.0
> Date: Fri, 12 Sep 1997 11:36:44 PDT
> From: Brian Grant <grant@thistle.cs.washington.edu>
> 
> It's working.
> 
> --Brian
> 

Cool!  A feature a day is a nice pace....

-- Craig

To: grant@cs.washington.edu
Cc: spin-comp@thistle.cs.washington.edu
Subject: Re: cache_one_unchecked 
Date: Fri, 12 Sep 97 11:44:11 -0700
From: Susan Eggers <eggers@pa.dec.com>

Great, I like this snowballing.

Susan


To: mock@thistle.cs.washington.edu, matthai@thistle.cs.washington.edu
cc: spin-comp-archive@cs
Subject: checked in changes in bin, lib, mflow/p2dyc
Date: Fri, 12 Sep 1997 15:40:45 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

that allow contiguous code-space allocation.  I haven't eliminated the
unneeded branches, however.

--Brian

To: spin-comp@cs
Subject: what's next...
Date: Mon, 15 Sep 1997 11:42:52 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

No comments on the priority list?

In any case, I'm going to continue to debug my code using bigger examples.
I'm going to try some simple unrolled loops first, then move on to the
byte-code interpreter.  I'll let everybody know when that works.

--Brian

To: mock@thistle.cs.washington.edu
cc: spin-comp-archive@cs
Subject: demotions bug
Date: Tue, 16 Sep 1997 10:10:40 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

Try the following routine:

----

#include <stdio.h>
#include <stdlib.h>
double rum=5.0;
double H(int i)
{
  double sum=rum;

  make_static(i); 
  sum += ((double) i);
  return sum;
}
----

The dynamic region should consist of a single ILFLOAT conversion STAT, and
the following GADD STAT should have a demotion for the temp computed by
ILFLOAT.  However, the GADD STAT has no BTA information (because it's outside
the region?).

--Brian

To: spin-comp@cs
Subject: UsedVars
Date: Tue, 16 Sep 1997 11:22:48 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

We (Matthai, Markus, and I) have decided to can the UsedVars analysis for now.
We're going to turn it off with a command-line option and simply not dump
anything from the division except at make_dynamic annotations and merges
(for mono_divide variables).  UsedVars seems like a good idea, but as
implemented, it removes things too aggressively, preventing specialized uses
of some derived static values.  What we may want it to reflect is uses of
derived values, but that would be significantly more difficult to compute
than what we do now, would require much more space, and would be redundant
with the part of the BTA that computes derivations (ideally, that part of
the analysis would be factored out).  So, it seems best to rely on
make_dynamic for now.

Another possibility would be to have another policy that controls whether to
filter a variable with UsedVars or not, but that seems unnecessarily
complicated.

--Brian

Date: Tue, 16 Sep 1997 11:28:30 -0700 (PDT)
From: chambers@klamath (Craig Chambers)
To: spin-comp@cs, grant@cs.washington.edu
Subject: Re: UsedVars

I'd like to hear more about what the problems are at our weekly meeting.  But 
only for my curiosity, not to second-guess or revisit the decision.  I think
we should be fine w/o automatic UsedVars for our benchmarking purposes, right?

-- Craig

To: spin-comp@cs
Subject: switching gears to floats, longs, and pointers
Date: Tue, 16 Sep 1997 11:34:07 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

I'm switching gears a little.  Instead of working on debugging loop unrolling,
I'm working on adding support for 64-bit (e.g. pointer) and floating-point
run-time constants.  The current RTCONST pathway wasn't set up to deal
with them, so I'm going to implement the original plan of inserting
explicit stores and loads.  This is what the merger would do if I could get
the RTCONST path to work (which is difficult because the same kinds of
instructions can't be used for floating-point values).  Eventually, we want
to eliminate redundant stores and loads, so this seems like the way to go.

--Brian

To: chambers@klamath (Craig Chambers)
cc: spin-comp@franklin.cs.washington.edu
Subject: Re: UsedVars 
Date: Tue, 16 Sep 1997 11:37:38 PDT
From: Matthai Philipose <matthai@franklin.cs.washington.edu>

> I'd like to hear more about what the problems are at our weekly meeting.  But 
> only for my curiosity, not to second-guess or revisit the decision.  I think
> we should be fine w/o automatic UsedVars for our benchmarking purposes, right?
> 
> -- Craig
> 

Yeah, we can always place explicit make_dynamics instead of using
the used_vars.

On the other hand, if we modified the bta to remove a var from a division
only if it is not in the used-vars _and_ none of its derived temps are
live, we could get rid of the "too aggressive" behavior of the current
bta. Not that we should implement it in the short term, but it may
be a good thing to add when we have some free time.

		Matthai

Date: Tue, 16 Sep 1997 12:01:24 -0700 (PDT)
From: Markus Mock <mock@apex.cs.washington.edu>
To: grant@cs.washington.edu
cc: mock@thistle.cs.washington.edu, spin-comp-archive@cs
Subject: Re: demotions bug

I fixed it, it was due to the comparing the in-out staticVars set without
taking into account FilterStaticVars that can kick additional temps out.

However, in the concrete example still no demotions are computed, since
t104 is not live after stat 132.


	-- Markus

On Tue, 16 Sep 1997, Brian Grant wrote:

> Try the following routine:
> 
> ----
> 
> #include <stdio.h>
> #include <stdlib.h>
> double rum=5.0;
> double H(int i)
> {
>   double sum=rum;
> 
>   make_static(i); 
>   sum += ((double) i);
>   return sum;
> }
> ----
> 
> The dynamic region should consist of a single ILFLOAT conversion STAT, and
> the following GADD STAT should have a demotion for the temp computed by
> ILFLOAT.  However, the GADD STAT has no BTA information (because it's outside
> the region?).
> 
> --Brian
> 


To: matthai@thistle.cs.washington.edu
cc: spin-comp-archive@cs
Subject: new way to end traces
Date: Wed, 17 Sep 1997 01:50:08 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

I had troubles with tags moving to where they shouldn't.  There was no
easy way to insert the IGOTO barriers where I needed them, so I implemented
the scheme we discussed, where a single tag can mark the beginning of a new
trace.  I just had to add essentially one test to a subroutine of the trace
picker.  Pretty cool.

BTW, the redundant IGOTO edges are apparently eliminated in ts/tags.C, so
I'm not sure what they did for us beyond single-edged IGOTOs.

--Brian

Date: Wed, 17 Sep 1997 10:40:59 -0700 (PDT)
From: chambers@klamath (Craig Chambers)
To: cecil@cs, spin-comp@cs
Subject: no Whirlwind meetings?

I'd like to postpone the Friday Whirlwind/DC meetings until there's
some specific topic(s) to discuss.  I'm feeling like I want to focus on
just a couple of things, get them designed to some reasonable level,
and then move on to a couple other things, rather than many things
simultaneously without much thinking between meetings.  I feel that we got
out many of the interesting issues in the couple of meetings we had, so 
people can be thinking of them even if we don't meet.  OK?

-- Craig

Date: Wed, 17 Sep 1997 10:41:28 -0700 (PDT)
From: chambers@klamath (Craig Chambers)
To: spin-comp@cs
Subject: no meeting thursday

I'm at Battelle (the faculty retreat/glorified faculty meeting) all day
Thursday, so I can't meet then.  We can reschedule either for e.g. 11am on
Friday (in place of the Whirlwind meeting), or today 2:30-3:30, or cancel for
this week.

What's your preference?

-- Craig

Date: Wed, 17 Sep 1997 15:12:05 -0700 (PDT)
From: chambers@klamath (Craig Chambers)
To: cecil@cs, spin-comp@cs
Subject: PLDI'91?

Did any of you borrow my PLDI '91 proceedings?  I seem to be missing it.
Thanks.

-- Craig

Date: Thu, 18 Sep 1997 11:44:59 -0700 (PDT)
From: Markus Mock <mock@apex.cs.washington.edu>
To: Brian Grant <grant@cs>, spin-comp-archive@cs
Subject: specializeLazy

Brian,

what is the annotation for specializeLazy (not loopSpecializeLazy) in
dyc2c?
I only see lazy, looplazy and eager there.


	-- Markus


Date: Fri, 19 Sep 1997 11:05:48 -0700 (PDT)
From: chambers@klamath (Craig Chambers)
To: spin-comp@cs
Subject: meeting?

Aren't we meeting now?  (11am)

-- Craig

Date: Fri, 19 Sep 1997 11:12:55 -0700 (PDT)
From: chambers@klamath (Craig Chambers)
To: cecil@cs, spin-comp@cs
Subject: ICFP proceedings

For any of you who didn't get your own copy of ICFP proceedings as part of your
SIGPLAN membership, I have (Susan's) spare copy to give you.  FCFS.

-- Craig

To: consel@irisa.fr
cc: Matthai Philipose <matthai@franklin.cs.washington.edu>,
Subject: Run-Time Specialization Examples
Date: Fri, 19 Sep 1997 15:30:18 PDT
From: Matthai Philipose <matthai@franklin.cs.washington.edu>

Dear Charles,
I'm a member of the UW dynamic compilation group, working
with Professors Susan Eggers and Craig Chambers. 

We're in the process of testing our new dynamic compilation
system, and would like to try out the benchmarks from your
"Automatic, Template-Based Run-Time Specialization: Implementation
and Experimental Study" tech report. You mentioned during your visit
here that you would be willing to make these programs available
to us. We would like to take you up on your generous offer.

Can you please place the source code in an area accessible
to me, and let me know how to get at it? If you have any additional
benchmarks you have numbers for, we would be delighted to try
those on our system too.
				Thanks,
				Matthai Philipose



To: spin-comp@cs
Subject: minor victory
Date: Fri, 19 Sep 1997 17:00:14 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

One small float example works, another doesn't.  I'm having a little more
trouble with tags.  I have a little more work yet on demotions.  All in all,
I would guess one more day is required on the demotions and back-end work.
Ug.  However, after that, the bulk of my code should be pretty robust.  Then,
on to loops...

--Brian

Date: Mon, 22 Sep 1997 21:41:20 -0700 (PDT)
From: Markus Mock <mock@apex.cs.washington.edu>
To: spin-comp@apex.cs.washington.edu
Subject: laziness computation committed

I've committed the code that computes the laziness info. It's
automatically called from the BTA module.

bta_export.H has the interface function to query if an edge is lazy or
not.


	-- Markus


To: mock@thistle.cs.washington.edu
cc: matthai@thistle.cs.washington.edu, spin-comp-archive@cs
Subject: yet more demotion weirdness
Date: Wed, 24 Sep 1997 13:10:50 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

Continuing with test3i2.DyC...

At the bottom of the loop, t128 is demoted.  Does UsedVars ignore back edges?

At the end of the dynamic region, t142 is demoted, I think, due to a "use" of
"i" by the make_dynamic.  If you transfer the make_static and make_dynamic
annotations to their own representations, you should probably replace their
call STATs with TAG_ANCHORs to eliminate bogus uses before the BTA runs.  Do
you see any problems with this approach?  It seems like the right thing to
do, at least for make_dynamic.  It should be ok for make_static, too, I think.

--Brian

To: spin-comp@thistle.cs.washington.edu
Subject: somewhat bad news about loop unrolling
Date: Wed, 24 Sep 1997 13:19:41 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

It is the case, at least for the short examples that I've seen, that
Multiflow creates a second induction-variable temp to control the loop.  This
temp does not receive the same treatment by the BTA as the original, annotated
temp.  So, the loop-exit condition is determined to be dynamic when it should
be static.

What this means is that we need to modify p2ivs (the induction-variable-
munging pass) to transfer the temp-variable correspondence to the new temps.
We don't expect this to be difficult for Matthai to do (he setup the original
correspondence between temps and variables).

There are some other problems with loops in the BTA and in my code as well,
so I doubt that loop unrolling will work by Friday.

--Brian

To: spin-comp@thistle.cs.washington.edu
Subject: induction-variable "simplification"
Date: Wed, 24 Sep 1997 14:06:00 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

For now, it's just turned off.

--Brian

To: mock@thistle.cs.washington.edu
cc: spin-comp-archive@cs
Subject: STAT_dyc2_staticOp
Date: Wed, 24 Sep 1997 17:20:43 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

Once we have multiple divisions, STAT_dyc2_staticOp(stat) must be set in a
post-pass after divisions are split.  For now, I've hacked my version to set
it appropriately for branches (not yet committed) during the BTA, as it
is for assignments.

--Brian

To: matthai@thistle.cs.washington.edu
cc: spin-comp-archive@cs
Subject: static branches
Date: Wed, 24 Sep 1997 23:15:59 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

I put in some support for static branches into the merger.  For example,
I updated the lines that remove the bogus instructions.  I also put in
code to record the STATIC_BRANCH branch layout prediction tag.  However,
more support needs to be put in.  If both edges go to dynamic code (other
template blocks), then an unconditional branch must be put in, similar
to the NO_BRANCH case.  I'm not yet sure what to do about edges to static
code.  They shoud also sort of be handled like NO_BRANCH for each possible
static destination.  The question is when to insert the jumps to static
code.  I can either try to put them in the template graph, in which case
I'm not sure how to label them.  Or, the merger can cause it to be
emitted at the top of the destination's block.

Hmm...

--Brian

To: spin-comp@franklin.cs.washington.edu
Subject: outline for the paper
Date: Thu, 25 Sep 1997 18:03:49 PDT
From: Matthai Philipose <matthai@franklin.cs.washington.edu>

Folks, 
Here's the outline (actually a detailed introduction
section) I came up with last week. I haven't yet incorporated
Craig's suggestions on what we should measure to prove the
points we claim below.

The stuff preceded by *** summarizes the intension of the
paragraph that follows.

         Matthai

------------
***What is DC; DC is cool
Dynamic Compilation, the generation and optimization of code
at runtime, has received much attention recently as a means of
transforming programs using information available at runtime. Proposed
applications for this capability have included specializing
architectural simulators for the configuration being simulated,
language interpreters for the program being interpreted, numerical
programs for dimensions and values of frequently used arrays, and
critical paths in operating systems for the type of data being
processed and the current state of the system. Trends in
software engineering toward dynamic reconfigurability,
parameterization for re-use and portability across hardware
architecture all imply a promising role for dynamic compilation. 

***People have shown DC is viable, but not for big programs:
Recent research efforts have made considerable progress towards
proving the viability of dynamic compilation. In particular,
researchers have demonstrated that run-time optimization overhead can
be more than amortized quickly by the increased efficiency of the
optimized code for many small, frequently used kernels. Existing
techniques have, however, failed to demonstrate applicability on any
existing applications of the size and complexity of the interpreters and
simulators mentioned above. The underlying reason for the failure is the
tradeoff between expressivity of the language interface for dynamic 
compilation and its ease of use:
	--Systems that require the programmer to explicity construct,
	  compose and compile the dynamically generated code ("imperative
	  systems") imply large scale re-writing of existing code that
         needs to be dynamically compiled. <The expressivity of these
	  systems is also in question: e.g. breaks out of loops>
	--Systems that offer a declarative scheme of sparse
          user-annotation to guide dynamic compilation ("declarative systems" 
have not
	  been able to express directions for compiling complex
	  programs in a natural, compact way.


***This the new stuff we do:
In this paper, we describe a declarative annotation-based system which:
	--Is expressive enough to exploit complex opportunities for dynamic
	  compilation in large, realistic programs. The required
	  expressiveness is significantly beyond that of existing
	  annotation-based DC systems.
	--Requires only sparse annotations of existing statically
	  compilable code, thereby eliminating the rewriting hurdle of
	  existing imperative systems 
	--Is based on a principled extension of traditional offline
	  PE techniques to the online case, and
	--Produces code of quality comparable to that other existing
	  systems at similar speeds.

***This is how we do it, in a paragraph:
Summarize features (~list from PEPM paper intro):
--per program-point specialization.
--polyvariant specialization and division.
--on-demand specialization to avoid specializing for values not yet
computed.
--interprocedural specialization with support for separate compilation. 
--automatic caching of specialized code

***We can get speedups on reasonable inputs for _big_ programs
We demonstrate the effectiveness of our approach by profitably applying dynamic
compilation to  javap, the  bytecode interpreter for the Java
programming language, and to MIPSI, an instruction-level simulator
for the MIPS R3000. Translating the dynamically compiled regions of
these programs (x and y lines of C) into an imperative language would
clearly require a lengthy, painstaking effort by programmers using an
imperative scheme. In contrast, we enable dynamic compilation of
both systems by  adding a few carefully selected annotations (x and y
lines) to their C source code. We also identify the features of these
applications that prevent existing annotation-based systems from optimizing 
them without substantial re-writing. <These applications are representative--
talk of other similar alluring ones!> 

***JITs do much better than us; why? opportunities...
Using java provides us the opportunity...
The existence of hand-written "just-in-time" (and conventional)
compilers for Java bytecode allows us to measure a few more
data-points on the code-quality vs. compilation time curve.

***We do as well as other systems: not trading off expressivity/ease
   for speed.
The improved expressivity and ease of use of our system do not come at
the expense of dynamically generated code quality or longer dynamic
compile times. Though our current system is not configured for
extremely aggressive run-time optimizations (we do not perform global
optimizations such as register allocation or scheduling), we use a
combination of cheap local optimization, extensive static global
optimization of templates for dynamic code and customized
code-generators to achieve speedups and code-generation costs
comparable to those of other existing systems. We   

***We will do much better, once our future work is done: microbenchmarks with 
proposed optimizations
   show this (Brian's list):
	  + Cost of not specializing calls
	  + Categorized unit boundary crossings (promotions,
                    discordant merges, etc.)
          + Cache lookups
          + Work-list operations
          + Function-call overhead
          + Per-instruction-generated (with & without above overheads)
	  + Cost of not doing register actions.

***Summary of sections <important: what will be the order and content of 
sections?>

Date: Fri, 26 Sep 1997 10:42:32 -0700 (PDT)
From: Markus Mock <mock@apex.cs.washington.edu>
To: grant@cs.washington.edu
cc: mock@thistle.cs.washington.edu, matthai@thistle.cs.washington.edu,
Subject: Re: yet more demotion weirdness

I have fixed the problem. 
> 
> At the end of the dynamic region, t142 is demoted, I think, due to a "use" of
> "i" by the make_dynamic.  If you transfer the make_static and make_dynamic
> annotations to their own representations, you should probably replace their
> call STATs with TAG_ANCHORs to eliminate bogus uses before the BTA runs.  Do
> you see any problems with this approach?  It seems like the right thing to
> do, at least for make_dynamic.  It should be ok for make_static, too, I think.
> 

That will require me to change FindAnnotationsStats where I am looking for
those calls and also the way I grab the policies. So before you make that
change let me know.

	-- Markus



Date: Fri, 26 Sep 1997 15:41:14 -0700 (PDT)
From: chambers@klamath (Craig Chambers)
To: spin-comp@cs
Subject: meeting

I can meet Mondays any time between 1 and 3.

-- Craig

To: chambers@klamath (Craig Chambers)
cc: spin-comp@cs
Subject: Re: meeting 
Date: Fri, 26 Sep 1997 15:42:42 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

>> I can meet Mondays any time between 1 and 3.

Sounds good.

--Brian

Date: Fri, 26 Sep 1997 15:43:23 -0700
From: eggers@yakima (Susan Eggers)
To: spin-comp@cs, chambers@klamath
Subject: Re: meeting


How about 1:30?

Susan

Date: Fri, 26 Sep 1997 16:05:01 -0700 (PDT)
From: Markus Mock <mock@apex.cs.washington.edu>
To: Susan Eggers <eggers@yakima>
cc: spin-comp@cs, chambers@klamath
Subject: Re: meeting

> 
> How about 1:30?

Fine with me.
	
	-- Markus



Date: Fri, 26 Sep 1997 16:24:53 -0700 (PDT)
From: Markus Mock <mock@apex.cs.washington.edu>
To: Matthai Philipose <matthai@cs>, Markus Mock <mock@cs>,
Subject: @ annotation for calls

Matthai,

since you're already familiar with the front end, it's best if you add
that annotation to the front end.
Just let me know how I can get the static annotation for calls then
(probably the same thing works that did for loads)
thanks.

	-- Markus


Date: Fri, 26 Sep 1997 16:34:10 -0700 (PDT)
From: chambers@klamath (Craig Chambers)
To: spin-comp@cs
Subject: Re: Job opportunities

[Luke is a Consel student.]

----- Begin Included Message -----

From Luke.Hornof@compose.irisa.fr  Fri Sep 26 11:52:10 1997
Delivery-Date: Fri, 26 Sep 1997 11:52:11 PDT
Date: Fri, 26 Sep 1997 20:52:06 +0200
From: Luke Hornof <Luke.Hornof@irisa.fr>
To: chambers@cs.washington.edu
Subject: Re: Job opportunities

Hello again, Craig,

...

I will, however, be visiting Seattle on Oct. 23 and 24 (to visit Microsoft)
and would happy to stop by UW to give a talk as well.  If you are interested,
please let me know which day (23rd or 24th) would be better for you.

Thanks,
Luke

----- End Included Message -----


I said yes.  Which day/time would be best for you all?  I'll probably try to
arrange a general talk, e.g. in 422.

-- Craig



Date: Fri, 26 Sep 1997 16:44:13 -0700 (PDT)
From: chambers@klamath (Craig Chambers)
To: cecil@cs, spin-comp@klamath
Subject: individual meetings

I need to reschedule all individual meetings at the start of the quarter
(for next week).

I'm free 11am-5pm MWF except for Monday 1pm onwards and Wednesdays 2:30-4.
(And if forced I can schedule time on TTh.)

Pick some good times, and I'll try to fit people in.

-- Craig

Date: Fri, 26 Sep 1997 16:53:25 -0700 (PDT)
From: Markus Mock <mock@apex.cs.washington.edu>
To: spin-comp@apex.cs.washington.edu
Subject: demotion changes committed

I've committed the changes that fixed the problems with the computation of
demotions in our examples.

I've also added a switch  P2DYC_use_used_vars  (default = FALSE) to turn
filtering by used vars on/off. By default used vars are ignored as they
caused us some problems in our examples.


	-- Markus


Date: Fri, 26 Sep 1997 16:55:24 -0700
From: eggers@yakima (Susan Eggers)
To: spin-comp@cs, chambers@klamath
Subject: Re: Job opportunities

Why don't you fold him into an ongoing seminar?

Susan

Date: Fri, 26 Sep 1997 17:34:19 -0700 (PDT)
From: chambers@klamath (Craig Chambers)
To: spin-comp@cs, eggers@yakima
Subject: Re: Job opportunities

> From eggers@yakima  Fri Sep 26 16:55:26 1997
> Delivery-Date: Fri, 26 Sep 1997 16:55:27 PDT
> Date: Fri, 26 Sep 1997 16:55:24 -0700
> From: eggers@yakima (Susan Eggers)
> To: spin-comp@cs, chambers@klamath
> Subject: Re: Job opportunities
> 
> Why don't you fold him into an ongoing seminar?
> 
> Susan
> 

What does that mean?  What seminar on Thurs or Friday are you thinking of?
Or do you mean the colloq?

-- Craig

Date: Fri, 26 Sep 1997 17:56:23 -0700
From: eggers@yakima (Susan Eggers)
To: spin-comp@cs, eggers@yakima, chambers@klamath
Subject: Re: Job opportunities

I was thining the collog,
but on second thought that
perhaps is not appropriate.

Date: Mon, 29 Sep 1997 11:17:12 -0700 (PDT)
From: Markus Mock <mock@apex.cs.washington.edu>
To: Brian Grant <grant@cs>, spin-comp-archive@cs
cc: Markus Mock <mock@cs>
Subject: removing annotation calls

I've not committed the code yet but it works. However, it causes your
setup pass to crash at different places, maybe because you assume the
annotatation to be in a call stat? At any rate, I added a command line
switch to turn the replacement with a tag stat off
P2DYC_bta_delete_annot_call

If you want to take a look at it now, I an check it in right away.
Othewise I'll first change the dotgraph routines first and update it in
one shot.


	-- Markus


To: spin-comp@franklin.cs.washington.edu
Subject: Dynamic compilation of xv
Date: Mon, 29 Sep 1997 16:03:58 PDT
From: Matthai Philipose <matthai@franklin.cs.washington.edu>

The `C folks got their speedup got their speedup on XV by unrolling the
inner-loop below. The big gains are through eliminating bounds checks. 

--n2 and sel[x|y|w|h] are runtime constants, but 
--x and y are dynamic (i.e. we cannot afford to specialize on them).

Seems to me that in order to avoid promotions at every (innermost) loop 
iteration, 
we would need to re-write the loop as I have at the bottom. Essentially, we 
want
to expose the fact that the loop-bound is a runtime constant. The
weird thing is that re-writing it in this manner seems to put an additional
calculation in the loop body.

In the long run, this seems like a transformation that could be done 
automatically
by a runtime optimization-aware static loop optimizer at least for simple 
loops. 

Comments/corrections/suggestions?
              Matthai

-----------
Original version:
-----------
 for (y1=y-n2; y1<=y+n2; y1++) {

	if (y1>=sely && y1<sely+selh) {
	  p24 = pic24 + y1*w*3 +(x-n2)*3; 

	  for (x1=x-n2; x1<=x+n2; x1++) {
	    if (x1>=selx && x1<selx+selw) {
	      rsum += *p24++;
	      gsum += *p24++;
	      bsum += *p24++;
	      count++;
	    }
	    else p24 += 3;
	  }
	}
      }
-------------

--------------
Re-written version:
-------------
 for (temp_y1=-n2; temp_y1 <= n2; temp_y1++) {
        y1=y+temp_y1;
	if (y1>=sely && y1<sely+selh) {
	  p24 = pic24 + y1*w*3 +(x-n2)*3; 

	  for (temp_x1=-n2; temp_x1<=n2; temp_x1++) {
	    x1 = x + temp_x1; 
	    if (x1>=selx && x1<selx+selw) {
	      rsum += *p24++;
	      gsum += *p24++;
	      bsum += *p24++;
	      count++;
	    }
	    else p24 += 3;
	  }
	}
      }
----

To: spin-comp@franklin.cs.washington.edu
Subject: Charlie's too busy to help
Date: Mon, 29 Sep 1997 16:25:36 PDT
From: Matthai Philipose <matthai@franklin.cs.washington.edu>

Charlie's message follows. His offer to help fix 64-bit related
bugs still stands.
			Matthai

------- Forwarded Message

Date:    29 Sep 1997 16:16:01
From:    Charlie Garrett <garrett@deer-park.etcons.com>
To:      Matthai Philipose <matthai@cs.washington.edu>
Subject: Re: Work on paper for pldi?

Matthai,

It sounds like my message got garbled in transmission. Here is what I
sent Craig:


>     Second, let me know if you run into any difficulties with my changes
> to Multiflow.  It sounds like the group is making slow and steady
> progress and I don't want my work to become a roadblock for you.
>
Unfortunately, I don't have any time to spare to work on a new part of
the DyC project.  I will be very, very busy until late November.  All I
meant to say was that if you turn up some bugs in my changes to
Multiflow, you should contact me.  That's for two reasons.  First, I
should be able to fix it faster since I am more familiar with it.
Second, I will feel terrible if my code prevents you from running one of
the benchmarks.

Having said that, please do ask me questions if there is something you
want to know about Alpha measurement code and send me a draft of the
paper when you want comments.

> At the meeting everyone seemed comfortable with making you a co-author
>
> on the paper.

That's very kind of you, but I think an acknowledgement is fine for my
contribution.  I did almost nothing to help design the system or to
implement the DyC algorithms.  I just helped bring the infrastructure up
to snuff.

- --
Charlie




------- End of Forwarded Message



To: spin-comp@thistle.cs.washington.edu
Subject: loop unrolling works
Date: Mon, 29 Sep 1997 16:31:30 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

I'll try our polynomial interpreter from the previous set of benchmarks
next...

--Brian

Date: Mon, 29 Sep 1997 16:58:51 -0700
From: eggers@yakima (Susan Eggers)
To: spin-comp@franklin.cs.washington.edu, matthai@franklin.cs.washington.edu
Subject: Re: Charlie's too busy to help


He is so nice.

Date: Tue, 30 Sep 1997 09:59:49 -0700 (PDT)
From: chambers@klamath (Craig Chambers)
To: spin-comp@cs, cecil@cs
Subject: FW: Paintball


----- Begin Included Message -----

From trmorris@cs.washington.edu  Tue Sep 30 09:36:37 1997
Delivery-Date: Tue, 30 Sep 1997 09:36:38 PDT
From: T R Morris <trmorris@cs.washington.edu>
To: kimera <kimera@cs.washington.edu>, spin <spin@cs.washington.edu>,
        rocky2 <rocky2@cs.washington.edu>
Cc: Tom Anderson <tom@cs.washington.edu>,
        Craig Chambers
	 <chambers@cs.washington.edu>,
        Susan Eggers <eggers@cs.washington.edu>
Subject: FW: Paintball
Date: Tue, 30 Sep 1997 09:32:22 -0700
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)

Hey gang,

I have contacted a paintball organization in Black Diamond, WA (between
Tacoma and Mt. Rainier). They have Saturday and Sunday openings in late
October (25th or 26th ) and November is wide open (weekends only).

The cost is $25 per person and includes semiautomatic pistols and 10
rounds of ammo (1$ buys 25 more). 

Lunch (hot dogs, chips and pop) is included provided we have at least 20
people.

We can play from dawn till dusk.

Now comes the hard part: What day works best, or rather, what days do
not work for those that are interested? I'll coordinate.

TR

P.S. (To: Tom, Craig and Susan) any of your students who are not part of
spin, kimera, or rocky2 need to be notified. Please either forward the
message or let me know who they are so I can do it.


----- End Included Message -----


Date: Tue, 30 Sep 1997 13:16:36 -0700 (PDT)
From: chambers@klamath (Craig Chambers)
To: spin-comp@franklin.cs.washington.edu, matthai@cs.washington.edu
Subject: Re: Dynamic compilation of xv

Interesting.  You're factoring out the static part of some calculation, for
better binding time separation.  Yes, it could be done automatically in some
smarter compiler.  I think it's fair to say that we hand-modified to do this
separation manually, in order to get the right effects.  Such hand mods 
hopefully are easier than `C-ifying.  Certainly you can test & debug the
program after hand-mods, which you can't easily do after `C-ifying.

-- Craig

Date: Tue, 30 Sep 1997 15:30:26 -0700 (PDT)
From: Markus Mock <mock@apex.cs.washington.edu>
To: spin-comp@apex.cs.washington.edu
Subject: changes to dotgraph routines checked in

I've checked in the changes to the dotgraph dumping routines. 
If DGOPT_show_bta_info is set to true the bta info before and after each
block will be included.
Also stats are marked as dynamic / static and individual temps are marked
(@) if they are static before the stat.

The annotation calls are now removed and replaced by tag stats, this can
be switched off by setting  the option
P2DYC_bta_delete_annot_calls  
to false.



	-- Markus


Date: Tue, 30 Sep 1997 16:40:06 -0700 (PDT)
From: Markus Mock <mock@apex.cs.washington.edu>
To: Matthai Philipose <matthai@cs>, spin-comp-archive@cs
Subject: C-front end changes

Any progress on the static annotation for function calls?


	-- Markus


Date: Tue, 30 Sep 1997 17:25:20 -0700 (PDT)
From: Markus Mock <mock@apex.cs.washington.edu>
To: Brian Grant <grant@cs>, spin-comp-archive@cs,
Subject: another bta update

I had to make a fix (some non-annotation calls got replaced by tags).
Please update again.


	-- Markus


To: Markus Mock <mock@apex.cs.washington.edu>
cc: spin-comp-archive@cs
Subject: Re: call arguments 
Date: Wed, 01 Oct 1997 12:38:34 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

>> Since true and the loop condition are not mutually exclusive the merge would
>> be dynamic even with reachability analysis.

What this says to me is that whatever scheme we devised to handle static
loops is broken and we should fix it.  It appears that loop heads will never
be static and will always require cache lookups.  Is that correct?  Is that
what we want?

Is the following rule our current one?

Two edges are mutually exclusive if the conjunction of their
reachability conditions is not satisfiable.  A merge is static if all of
its incoming edges are pairwise mutually exclusive.

--Brian

Date: Wed, 1 Oct 1997 12:52:33 -0700 (PDT)
From: chambers@klamath (Craig Chambers)
To: spin-comp@cs
Subject: Luke Hornoff

Since no one expressed any constraints, how about scheduling a talk 2:30 on
Friday Oct 24?

Also, any suggestions from us about what he talks about?  I'll suggest a half-
hour talk, fyi.

-- Craig


----- Begin Included Message -----

From Luke.Hornof@compose.irisa.fr  Wed Oct  1 12:49:31 1997
Delivery-Date: Wed, 01 Oct 1997 12:49:32 PDT
Date: Wed, 1 Oct 1997 21:49:02 +0200
From: Luke Hornof <Luke.Hornof@irisa.fr>
To: chambers@cs.washington.edu
Subject: UW visit in October


Hi Craig,

I was just wondering if you able to tell me which date would be best for me
to visit UW:  Oct 23 or 24 (or even the 22nd).

Thanks,
Luke


----- End Included Message -----


Date: Wed, 1 Oct 1997 13:48:51 -0700
From: eggers@yakima (Susan Eggers)
To: spin-comp@cs, chambers@klamath
Subject: Re: Luke Hornoff


Matthai and I have our standing meeting then.
Let's pick another time.

I am also tied up on Friday before 11:30 and 1:30 - 2:30.

Susan

Date: Wed, 1 Oct 1997 14:53:27 -0700 (PDT)
From: Markus Mock <mock@apex.cs.washington.edu>
To: Brian Grant <grant@cs>, spin-comp-archive@cs
Subject: VOID DYC2_XferPointInfo(DYC2_BTA from, DYC2_BTA to)

is checked in.


	-- Markus


Date: Wed, 1 Oct 1997 16:11:21 -0700 (PDT)
From: chambers@klamath (Craig Chambers)
To: spin-comp@cs
Subject: Re: Luke Hornoff

I've coordinated w/ Daniel Weise, who's interviewing Hornoff, and we have
Friday afternoon to see him.  So we have to pick a time then.

How about 11:30-12:30?

-- Craig

Date: Wed, 1 Oct 1997 16:23:18 -0700
From: eggers@yakima (Susan Eggers)
To: spin-comp@cs, chambers@klamath
Subject: Re: Luke Hornoff

I have that time free.

Susan


----- Begin Included Message -----

From chambers@klamath Wed Oct  1 16:11:32 1997
To: spin-comp@cs
Subject: Re: Luke Hornoff
X-Sun-Charset: US-ASCII
Content-Length: 170
X-Lines: 6
Status: RO

I've coordinated w/ Daniel Weise, who's interviewing Hornoff, and we have
Friday afternoon to see him.  So we have to pick a time then.

How about 11:30-12:30?

-- Craig


----- End Included Message -----


Date: Wed, 1 Oct 1997 16:26:01 -0700 (PDT)
From: Markus Mock <mock@apex.cs.washington.edu>
To: Susan Eggers <eggers@yakima>
cc: spin-comp@cs, chambers@klamath
Subject: Re: Luke Hornoff

Works for me too.

	-- Markus


Date: Wed, 1 Oct 1997 18:38:42 -0700 (PDT)
From: Markus Mock <mock@apex.cs.washington.edu>
To: Brian Grant <grant@cs>, spin-comp-archive@cs
Subject: context problem example

Can you send me a pointer to the file that caused the problem? I'd like to
use it to test the fix.


	-- Markus


To: mock@june
cc: spin-comp-archive@cs
Subject: bug in BTA: duplicate point-specific info
Date: Thu, 02 Oct 1997 01:35:45 PDT
From: Brian Kris Grant <grant@june.cs.washington.edu>

The BTA violates an agreed-upon invariant, which is it duplicates point-
specific information at multiple program points.  The example is:
/afs/cs/project/dyncomp/grant/Test/regression/static-branch.DyC

BBLOCK 32:
preds: 31 34
succs:
stats:
    170 LRET.NV 26     0 1 [N32] [<_sum$1.6>t123] $2.3$2auto_size(I32) <>t124 <>t125 0(I64)

In DYC2_BtaIdfa () at p2bta/bta-v2.C:471, the BBLOCK_dyc2_final_bta is
assigned to point to the same BTA as BBLOCK_dyc2_initial_bta, which
contains a demotion for TEMP 123.

Division 0:	{<_n$1.5PolyDiv,PolySpec,AutoPromo,CachePAllU,CacheMAll,Eager><_x$1.5PolyDiv,PolySpec,AutoPromo,CachePAllU,CacheMAll,Eager>}
Static Temps:	{}
Promoted Temps:	{}
Discordant Temps:	{}
Demoted Temps:	{123}

The problem is due to line 534, in FlowStat.  You just pass the incoming
BTA as the output in the case of a return STAT.  If the BTA has point-
specific info, this can't be done.  I didn't see any other cases where that
was done, but if you know of any, they need to be fixed, too.

Thanks.
--Brian

To: Markus Mock <mock@cs.washington.edu>
cc: spin-comp-archive@franklin.cs.washington.edu
Subject: @ for functions
Date: Thu, 02 Oct 1997 11:14:10 PDT
From: Matthai Philipose <matthai@franklin.cs.washington.edu>

Markus,
I finally got the @ for function calls to work. There was
a little bit of yacc hackery involved.

To check if a particular call stat is a static call,
you can use:
STAT_op_part_get(stat,dyc_static_call)
which will be true iff the call is a static call.

Of course, you should first check if the stat is a call
using something like:
if(STAT_group_prop(stat,call))
...

This is because I have overloaded the static_deref bit on
the OP datastructure to mean different things for calls and
memory dereferences.
              Matthai

To: matthai@thistle.cs.washington.edu
cc: spin-comp-archive@cs
Subject: IGOTO stuff that may help
Date: Thu, 02 Oct 1997 11:14:36 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

I assume STAT_switch_igoto(stat) is NULL only for STATs I create.  It should
be fine to set this field to non-NULL for copies.

p2dyc/boilerplate.C:dyc_MakeJumpTableAndLoad
	You won't be able to use this directly, but it should provide an
	example for how to munge a tag array.

p2dyc/util.C:dyc_CopyStat
	Has the code that makes new tag names when they are copied.  Right
	now the new tags are appended with .dyc_copy.%d, but you can make that
	string whatever you like.  If you need to propagate/set
	STAT_switch_igoto, this is the place to do it.

p2graph/stat_3.C:
cfe_alpha/ccode.C:
p2cse:
il2/mem.C:
	Sets/propagates STAT_switch_igoto.

p2dcr/p2dcr.C:
	Dead code removal is the pass that removes useless IGOTOs.  Search
	for switch_igoto.

p2dyc/p2dyc.C:dyc_FixTagArrays
	This is where I expect this to be done.  If it isn't the best place,
	feel free to move it.

--Brian

Date: Thu, 2 Oct 1997 14:35:44 -0700 (PDT)
From: chambers@klamath (Craig Chambers)
To: spin-comp@cs
Subject: Luke Hornoff talk

OK, I messed up and forgot that I arranged with Daniel to have Luke here
Friday afternoon, not 11:30am.  Asking around quickly suggests 3:30, Oct. 24,
as an acceptable time.  (Matthai, we'll have to reschedule our meeting.)
OK?

-- Craig

Date: Thu, 2 Oct 1997 14:49:59 -0700 (PDT)
From: Markus Mock <mock@apex.cs.washington.edu>
To: Craig Chambers <chambers@klamath>
cc: spin-comp@cs
Subject: Re: Luke Hornoff talk

3:30 is fine.


	-- Markus


Date: Thu, 2 Oct 1997 17:26:08 -0700 (PDT)
From: Markus Mock <mock@apex.cs.washington.edu>
To: Matthai Philipose <matthai@cs.washington.edu>
cc: spin-comp-archive@franklin.cs.washington.edu
Subject: Re: @ for functions

Matthai, 

can you look at
/afs/cs.washington.edu/project/dyncomp/mock/test/staticcall.DyC

It appears that the function call is not marked as static:
sum += sin@(M_PI / ((double) i));

(I assume that is the right syntax at least the compiler did not complain)

	-- Markus


Date: Thu, 2 Oct 1997 18:11:27 -0700 (PDT)
From: Markus Mock <mock@apex.cs.washington.edu>
To: Brian Grant <grant@cs>, spin-comp-archive@cs
cc: Markus Mock <mock@cs>, Matthai Philipose <matthai@cs>
Subject: bta update

Brian,

both the context and the static function call changes are checked in now.
The static call doesn't work yet since Matthai's annotation gets lost
before the BTA runs (we just looked at that). Once Matthai fixes this,
static calls should work alright.


	-- Markus


Date: Fri, 3 Oct 1997 10:11:37 -0700 (PDT)
From: Markus Mock <mock@apex.cs.washington.edu>
To: Brian Grant <grant@thistle.cs.washington.edu>
cc: Markus Mock <mock@cs>, Matthai Philipose <matthai@cs>,
Subject: Re: bta update 

Great!
Matthai's changes also let the BTA now pick up the @-call annotation and
calls are correctly identified as static if annotated (and the arguments
are static).


	-- Markus

On Fri, 3 Oct 1997, Brian Grant wrote:

> The context fix works for the examples I had.
> 
> Thanks.
> --Brian
> 


To: Markus Mock <mock@cs.washington.edu>
cc: spin-comp-archive@franklin.cs.washington.edu
Subject: Inputs for Consel's examples.
Date: Wed, 08 Oct 1997 14:00:58 PDT
From: Matthai Philipose <matthai@franklin.cs.washington.edu>

Markus,
Here are Luke Hornof's comments on inputs for their
kernels.
	
Enjoy!
	Matthai

------- Forwarded Message

Date:    29 Sep 1997 20:36:39
From:    Luke Hornof <Luke.Hornof@irisa.fr>
To:      matthai@cs.washington.edu
Subject: Re: Run-Time Specialization Examples


> Luke,
> Do you by any chance have the sample input files you used
> to test the programs you sent us? Sample output files would be
> great too, so we can test our results to make sure we're not
> producing junk.
> 		Thanks,
> 		Matthai

Inputs
- ------
romberg: I think you have all that you need.

cubic spline: both vectors filled using following routine:
  
  void fill_vect(int size, float u[MAX])
  {
    int i;
  
    for (i=0; i<size; i++)
      u[i] = i;
  }

  (. . .which makes pretty boring "curves".  We were planning on changing
   this but never got around to it.  Shouldn't make any difference as far as
   the results are concernred, though.)

chebyshev: approximated the cosine function

FFT: random numbers 

dotproduct: random numbers (+ 0s randomly placed for sparse matrices)

dith_dither: I can't find it at the moment but I could try to hunt it down!


Outputs
- ------
I don't have the files readily available, but if you know what the programs
are doing, some outputs are quite obvious (e.g. romberg), while others are
not (e.g. chebyshev).


Again, I know this is not ideal.  Some day I would like to create a little
archive that is completely self-contained and intuitive to use.  People could
just cd to the right directory and type "make" to generate the normal
version.  After that, they could extract the function(s) they want to modify,
modify them how they like, and then re-insert them.  Type "make" again, and
the new super-duper-RT-verion gets built.  Would makes it a lot easier.

'till then. . .
Luke

P.S. Again, don't hesitate to get back in touch with me if you have any more
questions, problems, etc.  Good luck!


------- End of Forwarded Message



To: Markus Mock <mock@cs.washington.edu>
cc: spin-comp@franklin.cs.washington.edu
Subject: Change of plans...
Date: Wed, 08 Oct 1997 14:03:44 PDT
From: Matthai Philipose <matthai@franklin.cs.washington.edu>

Because Brian and I have been busy trying to get the back
end to work for the stack (and mipsi) examples, we (along
with Susan) decided at this monday's meeting that it makes 
much more sense for you to start work on compiling consel's 
benchmark and xv than to get the dispatcher going.

Consel's benchmarks are in /afs/cs.washington.edu/project/dyncomp/examples/cons
el
and xv is in afs/cs.washington.edu/project/dyncomp/examples/xv. I have looked
at both these and they should be amenable to annotation and dynamic 
compilation.
Consel's benchmarks are described in their tech report "Automatic Template-
Based Run-Time Specialization: Implementation and Experimental Study". I have
forwarded to you Hornoff's comments on inputs for these apps in a separate
mail.

The function to be munged in xv is the doBlurConvolv() function in:
/afs/cs.washington.edu/project/dyncomp/examples/xv/xv-3.10a/xvalg.c
My comments on this app are appended; Craig seems to agree with
my assessment (i.e. the loop needs to be re-written as indicated).
				
Let me know of any questions.
				Matthai


---------------My previous mail on xv:
The `C folks got their speedup got their speedup on XV by unrolling the
inner-loop below. The big gains are through eliminating bounds checks. 

--n2 and sel[x|y|w|h] are runtime constants, but 
--x and y are dynamic (i.e. we cannot afford to specialize on them).

Seems to me that in order to avoid promotions at every (innermost) loop 
iteration, 
we would need to re-write the loop as I have at the bottom. Essentially, we 
want
to expose the fact that the loop-bound is a runtime constant. The
weird thing is that re-writing it in this manner seems to put an additional
calculation in the loop body.

In the long run, this seems like a transformation that could be done 
automatically
by a runtime optimization-aware static loop optimizer at least for simple 
loops. 

Comments/corrections/suggestions?
              Matthai

-----------
Original version:
-----------
 for (y1=y-n2; y1<=y+n2; y1++) {

	if (y1>=sely && y1<sely+selh) {
	  p24 = pic24 + y1*w*3 +(x-n2)*3; 

	  for (x1=x-n2; x1<=x+n2; x1++) {
	    if (x1>=selx && x1<selx+selw) {
	      rsum += *p24++;
	      gsum += *p24++;
	      bsum += *p24++;
	      count++;
	    }
	    else p24 += 3;
	  }
	}
      }
-------------

--------------
Re-written version:
-------------
 for (temp_y1=-n2; temp_y1 <= n2; temp_y1++) {
        y1=y+temp_y1;
	if (y1>=sely && y1<sely+selh) {
	  p24 = pic24 + y1*w*3 +(x-n2)*3; 

	  for (temp_x1=-n2; temp_x1<=n2; temp_x1++) {
	    x1 = x + temp_x1; 
	    if (x1>=selx && x1<selx+selw) {
	      rsum += *p24++;
	      gsum += *p24++;
	      bsum += *p24++;
	      count++;
	    }
	    else p24 += 3;
	  }
	}
      }
----




Date: Wed, 8 Oct 1997 14:15:28 -0700
From: eggers@yakima (Susan Eggers)
To: mock@cs.washington.edu, matthai@cs.washington.edu
Subject: Re: Change of plans...
Cc: spin-comp@franklin.cs.washington.edu


Markus --

Is this ok with you?  Our rationale was that getting Consel's
programs to run was a better debugging exercise for DyC
(and we need this at this point) and that we need to get a
comparison for the paper anyway.
Then we could work on the dispatcher next.

Susan

To: eggers@thistle.cs.washington.edu
cc: spin-comp-archive@thistle.cs.washington.edu
Subject: meeting today?
Date: Wed, 08 Oct 1997 15:48:44 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

Please send me mail when you get in and let me know when/whether I should
come up.

I've been debugging the compiler for this stack program.  There have been
many minor problems.  Its CFG is by far the most complex we've tried to
tackle (fairly long if-then-else).  I fixed the problem in the back end that
was alternately causing the compiler to hang or fail an assertion.  It had
to do (again) with the way we were causing traces to end/begin.  Essentially,
there are informational nodes that must be allowed in the trace following the
point where we would like to end the trace.

After that problem was solved and the compiler was generating code, I found
that tags were being duplicated and lost (that's fixed), holes were being
duplicated and lost (not yet fixed), and holes were being reordered (not yet
fixed).

Most of the problems stemmed from a small number of bugs.  For example, most
of the problems with the holes appear to arise do to the particular iterator
I'm using to process the operand of each IL operation.  I thought it was the
right one, but it can include values that are not real operands.  It appears
that there may not be a general iterator that iterates over just real
operands, so I have to write one that will special-case each different type
of operation.  I'm not yet sure if that means a dozen special cases or a
hundred.

--Brian

To: matthai@thistle.cs.washington.edu
cc: spin-comp-archive@cs
Subject: reminder: hole numbers
Date: Wed, 08 Oct 1997 16:33:06 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

Use the hole numbers to match setup place-holder stores with holes in the
template.  Only print a warning if there is no template hole corresponding to
a setup place holder.  Obviously, there must always be a place holder for
every store.

--Brian

Date: Wed, 8 Oct 1997 17:44:46 -0700 (PDT)
From: Markus Mock <mock@apex.cs.washington.edu>
To: Susan Eggers <eggers@yakima>
cc: matthai@cs.washington.edu, spin-comp@franklin.cs.washington.edu
Subject: Re: Change of plans...

That's ok with me. 

	-- Markus

On Wed, 8 Oct 1997, Susan Eggers wrote:

> 
> Markus --
> 
> Is this ok with you?  Our rationale was that getting Consel's
> programs to run was a better debugging exercise for DyC
> (and we need this at this point) and that we need to get a
> comparison for the paper anyway.
> Then we could work on the dispatcher next.
> 
> Susan
> 


Date: Thu, 9 Oct 1997 17:29:27 -0700 (PDT)
From: Markus Mock <mock@apex.cs.washington.edu>
To: Brian Grant <grant@cs>, spin-comp-archive@cs
Subject: crash in p2dyc/setup.C:1853

Expression ( UnitTail == BBLOCK_DYC_INFO_UnitTail(BBlock) ) evaluated to
FALSE at (file:line) p2dyc/setup.C:1853

for
/afs/cs.washington.edu/project/dyncomp/mock/benchmarks/consel/benchmark-chebychev/cheb.DyC

Can you take a look at it?
Thanks.


	-- Markus


Date: Thu, 9 Oct 1997 17:43:59 -0700 (PDT)
From: Markus Mock <mock@apex.cs.washington.edu>
To: Matthai Philipose <matthai@cs>, spin-comp-archive@cs
cc: Markus Mock <mock@cs>
Subject: source var bug?

Matthai,

before any of the bta runs I get:

 FATAL COMPILER ERROR
? Assertion failed.
? Annotation argument without a source-var

? (file:line) p2rvd/p2rvd.C:513


for program

/afs/cs.washington.edu/project/dyncomp/mock/benchmarks/consel/benchmark-csi/csi.DyC

Can you take a look?
Thanks.


	-- Markus


To: Markus Mock <mock@apex.cs.washington.edu>
cc: spin-comp-archive@franklin.cs.washington.edu
Subject: Re: source var bug? 
Date: Thu, 09 Oct 1997 18:07:21 PDT
From: Matthai Philipose <matthai@franklin.cs.washington.edu>

Markus,
The problem lies in the fact that if you say make_static
on a variable before it is defined, the temporary you make_
static does not have an var associated with it. For the short
term, you can get around this problem by introducing pseudo-definitions
of the variable before the use. I am not sure how to fix this in the
long term... i.e. how to get over the problem that mflow does
not seem to associate undefined uses with a particular temp.

I have appended a munged version of the program below which
passes throught the early stuff but seems to barf in p2dyc.
		Matthai

ps: You should probably just document the problem with each failed program
    or send an update, and proceed to the next program. With the simpler
    programs, it's proably a good idea to look at the bta information
     (i.e. at least which stat is static vs. dynamic) and  ensure that
   the info is ok as best you can.

-----------------

/* annotated by Markus Mock */
#include <stdio.h>
#include <math.h>

#define MAX 500

/* csi(S, S, D, D); */
void csi(int n, float x[MAX], float y[MAX], float z[MAX])
{
  float h_0[MAX],b[MAX],u_0[MAX],v[MAX];
  float* h=h_0,*u=u_0;
  int i=0;

  make_static(n, x);
  make_static(i,h);
  for (i = 0; i<= n-1; i=i+1){
    h[i] = x@[i+1]-x@[i];
    b[i] = (6/h@[i])*(y[i+1]-y[i]);
  }

  make_static(u);
  u[1] = 2*(h@[0]+h@[1]);
  v[1] = b[1]-b[0];
  for (i = 2; i <= n-1; i=i+1){
    u[i] = 2*(h@[i]+h@[i-1])-h@[i-1]*h@[i-1]/u@[i-1];
    v[i] = b[i]-b[i-1]-h@[i-1]*v[i-1]/u@[i-1];
  }

  z[n] = 0;
  i=n-1;
  if ( i>=1 )
    do {
      z[i] = (v[i]-h@[i]*z[i+1])/u@[i];
      i=i-1;
    } while ( i>=1 );
  z[0] = 0;
}


Date: Thu, 9 Oct 1997 18:11:07 -0700 (PDT)
From: Markus Mock <mock@apex.cs.washington.edu>
To: Matthai Philipose <matthai@cs.washington.edu>
cc: spin-comp-archive@franklin.cs.washington.edu
Subject: Re: source var bug? 

Ok. Yeah, I am looking at the BTA so I am not completely held up, but we
want to run things eventually. The fix for that program is simple, though.
Thanks.


	-- Markus

On Thu, 9 Oct 1997, Matthai Philipose wrote:

> Markus,
> The problem lies in the fact that if you say make_static
> on a variable before it is defined, the temporary you make_
> static does not have an var associated with it. For the short
> term, you can get around this problem by introducing pseudo-definitions
> of the variable before the use. I am not sure how to fix this in the
> long term... i.e. how to get over the problem that mflow does
> not seem to associate undefined uses with a particular temp.
> 
> I have appended a munged version of the program below which
> passes throught the early stuff but seems to barf in p2dyc.
> 		Matthai
> 
> ps: You should probably just document the problem with each failed program
>     or send an update, and proceed to the next program. With the simpler
>     programs, it's proably a good idea to look at the bta information
>      (i.e. at least which stat is static vs. dynamic) and  ensure that
>    the info is ok as best you can.
> 
> -----------------
> 
> /* annotated by Markus Mock */
> #include <stdio.h>
> #include <math.h>
> 
> #define MAX 500
> 
> /* csi(S, S, D, D); */
> void csi(int n, float x[MAX], float y[MAX], float z[MAX])
> {
>   float h_0[MAX],b[MAX],u_0[MAX],v[MAX];
>   float* h=h_0,*u=u_0;
>   int i=0;
> 
>   make_static(n, x);
>   make_static(i,h);
>   for (i = 0; i<= n-1; i=i+1){
>     h[i] = x@[i+1]-x@[i];
>     b[i] = (6/h@[i])*(y[i+1]-y[i]);
>   }
> 
>   make_static(u);
>   u[1] = 2*(h@[0]+h@[1]);
>   v[1] = b[1]-b[0];
>   for (i = 2; i <= n-1; i=i+1){
>     u[i] = 2*(h@[i]+h@[i-1])-h@[i-1]*h@[i-1]/u@[i-1];
>     v[i] = b[i]-b[i-1]-h@[i-1]*v[i-1]/u@[i-1];
>   }
> 
>   z[n] = 0;
>   i=n-1;
>   if ( i>=1 )
>     do {
>       z[i] = (v[i]-h@[i]*z[i+1])/u@[i];
>       i=i-1;
>     } while ( i>=1 );
>   z[0] = 0;
> }
> 
> 


Date: Fri, 10 Oct 1997 13:11:36 -0700 (PDT)
From: chambers@klamath (Craig Chambers)
To: cecil@cs, spin-comp@cs, zahorjan@cs
Subject: Appel Java compiler book?

I can't find my copy of Appel's Java compiler book.  Did I loan it to any of
you?

-- Craig

Date: Fri, 10 Oct 1997 15:51:58 -0700 (PDT)
From: Markus Mock <mock@apex.cs.washington.edu>
To: Brian Grant <grant@cs>, Matthai Philipose <matthai@cs>,
cc: Markus Mock <mock@cs>
Subject: discordant temps bug 

It appears that the discordant_temps prepass does not correctly compute
that t199 <j> is discordant on entry to block 34 and t200 <k> on entry to
block 37. Therefore the discordant sets (and other things) in the bta are
not computed correctly.

Could you take a look, Matthai.
Thanks.

	-- Markus

The example is in
/afs/cs.washington.edu/project/dyncomp/mock/benchmarks/consel/benchmark-chebychev/cheb.DyC



Date: Fri, 10 Oct 1997 15:54:28 -0700 (PDT)
From: chambers@klamath (Craig Chambers)
To: cecil@cs, spin-comp@cs
Subject: retreat?

There was some brief discussion of having a retreat for the group to go off
somewhere and think good thoughts about Diesel and Whirlwind (and any other
good topics).  There was mention that such a retreat could help clarify ideas
and approaches, in preparation for writing one or more grant proposals.

I'm interested in pursuing this idea, with a Nov. 9 & 10 candidate date.  
Say drive to the woods morning of Nov. 9, come back afternoon of Nov. 10.  Or
depending on agenda, go out eve of Nov. 8.

What do you all think?  Who else do you think we could invite who would be
interested and help give us ideas?  I was thinking about some people on the
Spin project (e.g. Gun has talked about Java server ideas with me), or people
on the ZPL project (as another compiler project).  Borning-ites?  Notkin-ites?

-- Craig

Date: Fri, 10 Oct 1997 16:54:18 -0700 (PDT)
From: chambers@klamath (Craig Chambers)
To: spin-comp@cs
Subject: shift meeting time?

I would like to schedule a meeting at 2:30 on Mondays.  Since that is 
uncomfortably close to the DyC meeting, can we shift our meetings a bit earlier
to 1pm?

-- Craig

To: grant@franklin.cs.washington.edu,
cc: spin-comp-archive@franklin.cs.washington.edu
Subject: Trouble with empty setup blocks
Date: Fri, 10 Oct 1997 21:08:29 PDT
From: Matthai Philipose <matthai@franklin.cs.washington.edu>

Brian,
The switch example seems to work, except for the following bug
(refer to code below).

Basically, the  main.dyb_setup_begin_1 block turns out to be empty. 
Consequently,
all branches originally intended for the boundary between 
main.dyn_setup_end_1_0: and main.dyn_setup_begin_9_0: are now
redirected to L12$3. The problem of course, is that this is the
wrong control behavior once I merge in emits for template codes for
seup_bb_1 and setup_bb_9.

One fix may be to put in a dummy store in an empty setup block, so the
label is forced.
         Matthai
 
  

-----------------
       ...
main.dyn_setup_end_3_0:
L12$3:
main.dyn_setup_begin_1_0:
main.dyn_setup_end_1_0:
main.dyn_setup_begin_9_0:
 			....
 	

Date: Sun, 12 Oct 1997 21:36:48 -0700
From: eggers@yakima (Susan Eggers)
To: spin-comp@cs, chambers@klamath
Subject: Re: shift meeting time?


fine with me.

Date: Mon, 13 Oct 1997 16:00:30 -0700 (PDT)
From: Markus Mock <mock@apex.cs.washington.edu>
To: Matthai Philipose <matthai@cs>, spin-comp-archive@cs,
cc: Markus Mock <mock@cs>
Subject: update bta

fft now runs through, it just fails the merger:

/afs/cs.washington.edu/project/dyncomp/mock/benchmarks/consel/benchmark-fft


fft_duhamel.c", line 38: warning: illegal pointer combination
Starting BTA...
Testing used vars / live temps invariant
passed
BTA pass finished
Merging...
line 17902: Label L535$3: for template block template_56 emitted after
begin tag at /afs/cs/project/dyncomp/mock/DyC/bin/stitch.pl line 399,
<ASSEMBLER> chunk 17902.


/afs/cs.washington.edu/project/dyncomp/mock/benchmarks/consel/benchmark-ppmdither:
ppmdither.DyC

fails in

Expression ( BBLOCK_pred_list(BBlock) &&
BBLOCK_list_bblock(BBLOCK_pred_list(BBlock)) ) evaluated to FALSE at
(file:line) p2dyc/util.C:1423


all the programs in your regression suite, Brian, run through fine.


	-- Markus


Date: Mon, 13 Oct 1997 16:04:30 -0700 (PDT)
From: Markus Mock <mock@apex.cs.washington.edu>
To: Matthai Philipose <matthai@cs>, spin-comp-archive@cs
cc: Markus Mock <mock@cs>
Subject: merger warnings

what do these mean?

dcmake dotproduct.o
Compiling...
rcc: warning: -S overrides -mAS
"dotproduct.c", line 13: warning: illegal pointer combination
"dotproduct.c", line 13: warning: illegal pointer combination
Starting BTA...
Testing used vars / live temps invariant
passed
BTA pass finished
Merging...
WARNING: placeholder    stl     $25,dotproduct.rtconst_2_0_1($31)
#class source   # line 0, <>t194, 0(I64), dotproduct.rtconst_2_0_1,
0(I32), 0(I32), 0(I32), 0(I32) ignored
WARNING: placeholder    stl     $24,dotproduct.rtconst_2_0_3($31)
#class source   # line 0, <>t113, 0(I64), dotproduct.rtconst_2_0_3,
0(I32), 0(I32), 0(I32), 0(I32) ignored
WARNING: placeholder    stl     $21,dotproduct.rtconst_2_0_5($31)
#class source   # line 0, <>t150, 0(I64), dotproduct.rtconst_2_0_5,
0(I32), 0(I32), 0(I32), 0(I32) ignored
WARNING: placeholder    stl     $20,dotproduct.rtconst_2_0_7($31)
#class source   # line 0, <>t157, 0(I64), dotproduct.rtconst_2_0_7,
0(I32), 0(I32), 0(I32), 0(I32) ignored
setup and template holes not for corresponding bblocks in (     stl
$27,dotproduct.rtconst_4_0_1($31)        #class source   # line 0,
<dotproduct.rtconst_4_0_1($31)        #class source   # line 0, <>t165,
0(I64), dotproduct.rtconst_4_0_1, 0(I32), 0(I32), 0(I32), 0(I32) and
lda     $22,dotproduct.rtconst_6_0($31)  #class dmove,dm_constant        #
dotproduct.rtconst_6_0)
*** Exit 2
Stop.


This is for the dot product 
/afs/cs.washington.edu/project/dyncomp/mock/benchmarks/consel/benchmark-dotproduct


	-- Markus


Date: Mon, 13 Oct 1997 16:25:46 -0700 (PDT)
From: chambers@klamath (Craig Chambers)
To: spin-comp@cs
Subject: meeting time

I've moved my other meeting to be 11:30-1.  So I'm happy if we leave the DyC
meeting at 1:30.  Can we move it back?  Thanks.  And sorry for the shuffling.

-- Craig

Date: Tue, 14 Oct 1997 09:29:52 -0700 (PDT)
From: Markus Mock <mock@apex.cs.washington.edu>
To: Brian Kris Grant <grant@june.cs.washington.edu>
cc: Markus Mock <mock@cs>, Matthai Philipose <matthai@cs>,
Subject: Re: stack interpreter 


> In the BTA you sent me, t197 is made dynamic and demoted in bblock 40,
> apparently due to bogus<?> discordant temps that include one of its roots
> (t215).  This causes all branches on c to be dynamic.  
> 
> The program should still work, so I have to fix the inter-unit branch-patching
> problem, but it would be nice if the branches were static. :-)  Is this
> a bug in discordant temps?
> 

Yep. I just checked and on entry these temps are marked as discordant:
{197,198,199,215}
since t197 has no definition from 38 -> 40 and 39 -> 40 this is a bug in 
discordant temps.
Can you take a look, Matthai?

	-- Markus




> --Brian
> 
> bblock38 [label=" BBlock 38\lStatic Temps: {(t199,CacheAll,{_n$1.2}),(t2
> 15,CacheAll,{_i$1.2}),(t186,CacheAll,{_s$1.1}),(t197,Cache1U,{_i$1.2,_s$1.1})}\l
> Promoted Temps: {}\lDiscordant Temps: {}\lDemoted Temps: {}\l 174 <S> IF_REL.GE 
> @<_n$1.2>t199 0(I64)\lStatic Temps: {(t199,CacheAll,{_n$1.2}),(t215,CacheAll,{_i
> $1.2}),(t186,CacheAll,{_s$1.1}),(t197,Cache1U,{_i$1.2,_s$1.1})}\lPromoted Temps:
>  {}\lDiscordant Temps: {}\lDemoted Temps: {}\l"];
> 	 bblock38 -> bblock40 [label="T"];
> 	 bblock38 -> bblock39 [label="F"];
> 
>         bblock39 [label=" BBlock 39\lStatic Temps: {(t199,CacheAll,{_n$1.2}),(t2
> 15,CacheAll,{_i$1.2}),(t186,CacheAll,{_s$1.1}),(t197,Cache1U,{_i$1.2,_s$1.1})}\l
> Promoted Temps: {}\lDiscordant Temps: {}\lDemoted Temps: {}\l 179 <S> TCALL [] [
> ] [addr(_$1STRINGVAR.1)(P64),addr(_$1STRINGVAR.2)(P64),24(SI32)] [] raddr(__asse
> rt)(P64)\lStatic Temps: {(t199,CacheAll,{_n$1.2}),(t215,CacheAll,{_i$1.2}),(t186
> ,CacheAll,{_s$1.1}),(t197,Cache1U,{_i$1.2,_s$1.1})}\lPromoted Temps: {}\lDiscord
> ant Temps: {}\lDemoted Temps: {}\l"];
>         bblock39 -> bblock40;
> 
>         bblock40 [label=" BBlock 40\lStatic Temps: {(t199,CacheAll,{_n$1.2}),(t2
> 15,CacheAll,{_i$1.2}),(t186,CacheAll,{_s$1.1})}\lPromoted Temps: {}\lDiscordant 
> Temps: {199,215}\lDemoted Temps: {197}\l 181 <D> IF_EQT.EQ<_c$1.2>t197 61(SI32)\
> lStatic Temps: {(t199,CacheAll,{_n$1.2}),(t215,CacheAll,{_i$1.2}),(t186,CacheAll
> ,{_s$1.1})}\lPromoted Temps: {}\lDiscordant Temps: {}\lDemoted Temps: {}\l"];
> 
> 


Date: Tue, 14 Oct 1997 10:29:57 -0700 (PDT)
From: Markus Mock <mock@apex.cs.washington.edu>
To: Matthai Philipose <matthai@cs>, spin-comp-archive@cs
Subject: unresolved symbols

Matthai,

what does the following mean:
collect2: ld returned 1 exit status
/usr/bin/ld:
Unresolved:
romberg.rtconst_9_0_1
romberg.rtconst_9_0_3
romberg.rtconst_9_0_5
romberg.rtconst_9_0_7
romberg.rtconst_9_0_11
romberg.rtconst_9_0_13
romberg.rtconst_9_0_16
romberg.rtconst_9_0_18
romberg.rtconst_11_0_1
romberg.rtconst_11_0_3
romberg.rtconst_12_0_1
romberg.rtconst_13_0_1
?


	-- Markus


To: spin-comp@thistle.cs.washington.edu
Subject: one more thing...
Date: Tue, 14 Oct 1997 23:38:51 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

I also checked in a new-and-improved version of dyc2c. You can now just use
the plain-old dyc2c and not dyc2c-ms.  Differences:

-- It now generates foo.noop.c by default instead of foo.c, when -noop is used.
-- The output file can be specified with -o.
-- It can read and write from/to standard input and output.

--Brian

To: spin-comp@cs
Subject: regression tests
Date: Tue, 14 Oct 1997 23:28:40 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

I finished the new version of the regression-test script, rt.  I also
have created a new-and-improved version of dcmake.  I don't have time to
go into all of the features now, but feel free to ask me about them.  The
basic usage is:
% rt
Or, to test a specific program:
% rt program
You have to run rt from the regression-test directory (or use the
environment variable or command-line option).  Do
% cvs checkout regression
from you DyC directory to grab it.

You'll also want to update your bin and lib directories.  Put your bin
directory in your path if it isn't there already.

I'm pretty sure all of the programs in the suite once worked, but now
most fail for me.  Before I check in my version, I'll try to fix the
problems.  Please run the suite using your versions of the compiler and
let me know which ones fail.  Here are my results:

+++ Application extend-context passed
### Application float-demotions failed
### Application float-holes failed
+++ Application float-int passed
+++ Application float-unroll passed
### Application int-unroll failed
### Application loop-lazy crashed
+++ Application multiunit-all passed
### Application multiunit-lazy crashed
### Application multiunit-promote crashed
+++ Application multiunit-rep passed
### Application multiunit-unchecked failed
### Application promote1 crashed
### Application rt-merge crashed
+++ Application side-effects passed
### Application static-branch crashed
+++ Application unchecked passed
+++ Application unroll1 passed

--Brian

To: garrett@thistle.cs.washington.edu
cc: spin-comp@cs
Subject: bug in 64-bit floating point?
Date: Wed, 15 Oct 1997 11:47:42 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

Charlie,

I think I've uncovered a bug in how Multiflow represents (64-bit) floating-
point constants.

Multiflow represents the double constant 5.43 in assembler as:
	.long	0x4015b851eb851eb8
whereas the DEC compiler (cc) represents it as:
        .t_floating     5.4299999999999997e+00:1

Multiflow's causes a float exception in my program and evaluates to
1.9522361275299495e-314, not 5.43.  Multiflow's representation for pi
evaluates to 6.984873502635735e-315.  Have you come across the code that
emits these constants?  We can edit the assembly files by hand to put in the
correct constants, but it would be much better to get Multiflow to emit the
right thing.  Consel's benchmarks each have several float constants (PI,
0.5, 1.0, 2.0, 3.0) and it would be tedious to replace them all (and constants
that are the result of folding as well).

Thanks.
--Brian


Date: Wed, 15 Oct 1997 12:25:13 -0700
From: eggers@yakima (Susan Eggers)
To: garrett@thistle.cs.washington.edu, grant@cs.washington.edu
Subject: Re: bug in 64-bit floating point?
Cc: spin-comp@cs


I think Charlie is out of town at the moment.
Because he sent me a regret for my talk yesterday.

Susan

To: spin-comp@thistle.cs.washington.edu
Subject: major commit
Date: Wed, 15 Oct 1997 13:19:58 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

I just committed my code.  You'll want to do a top-level update, since I
also made changes in bin, lib, and regression.

The new code doesn't pass all of the regression tests, but passes more than
the previous committed version.  The new version sports a new unit-
assignment algorithm that shouldn't go berserk in the presence of multiple
loops and improved handling of the tags when there is out-of-line spill code.

--Brian

To: spin-comp@franklin.cs.washington.edu
Subject: dot-product works...
Date: Wed, 15 Oct 1997 14:12:17 PDT
From: Matthai Philipose <matthai@franklin.cs.washington.edu>

The dotproduct example (used by both Consel and the 'C folk)
works, except that vectors of size > 125 currently cause the
DyC runtime to run out of memory. Basically, we're currently allocating
memory using a very conservative policy (one 16k table per instance
of unit stitched!). We're moving to a more discerning
scheme which allocates new table only when needed, so this problem 
should go away.

Anyway, this is probably the first "usable" program to work...	
			Matthai

Date: Wed, 15 Oct 1997 14:17:37 -0700 (PDT)
From: Markus Mock <mock@apex.cs.washington.edu>
To: Brian Grant <grant@cs>, spin-comp-archive@cs
Subject: romberg assertion failure

/afs/cs.washington.edu/project/dyncomp/mock/benchmarks/consel/benchmark-romberg 
fails an assertion

xpression ( BBlock == BBLOCK_DYC_UNIT_INFO_Head(BBlock) ) evaluated to
FALSE at (file:line) p2dyc/unit.C:902*** Exit 1

	-- Markus


Date: Wed, 15 Oct 1997 14:21:48 -0700
From: eggers@yakima (Susan Eggers)
To: spin-comp@franklin.cs.washington.edu, matthai@cs.washington.edu
Subject: Re: dot-product works...


Wonderful!

Date: Wed, 15 Oct 1997 14:41:51 -0700 (PDT)
From: Markus Mock <mock@apex.cs.washington.edu>
To: Matthai Philipose <matthai@cs>, spin-comp-archive@cs
Subject: equiv vars

Matthai,

can you explain why temp_x1 and selh are equivalent in
/afs/cs.washington.edu/project/dyncomp/mock/benchmarks/xv/xv-3.10a/xvalg.DyC
?

at stat 160?

Is that a bug or a feature?


	-- Markus


Date: Wed, 15 Oct 1997 16:04:06 -0700 (PDT)
From: Markus Mock <mock@apex.cs.washington.edu>
To: Brian Grant <grant@cs>, spin-comp-archive@cs
Subject: big rtconsts

? FATAL COMPILER ERROR
? Assertion failed.
? Can't have big RTCONSTs
? (file:line) cg/mop_alpha.C:1253
*** Exit 1

this happens if we make w and h static too on line 197 in ppmdither.DyC

(both are ints)


	-- Markus


Date: Wed, 15 Oct 1997 17:19:31 -0700 (PDT)
From: Markus Mock <mock@apex.cs.washington.edu>
To: Brian Grant <grant@thistle.cs.washington.edu>
cc: Markus Mock <mock@cs>, Matthai Philipose <matthai@cs>,
Subject: Re: romberg assertion failure 

It compiles fine but the memory allocation problem bites us here too:
romberg
running 10000 iterations of romber with 8 integration iterations
Input:
3.000000 7.000000
computing ..
Assertion failed: 0, file dycrt.c, line 111
IOT trap

I've seen this also with the other Consel apps that go thru now
(chebychev, csi)


	-- Markus

On Wed, 15 Oct 1997, Brian Grant wrote:

> Romberg now compiles and merges, but can't be tested without a driver.
> The necessary changes to the compiler are committed.
> 
> --Brian
> 


To: Charlie Garrett <garrett@etcons.com>
cc: spin-comp@cs
Subject: Re: bug in 64-bit floating point? 
Date: Wed, 15 Oct 1997 20:52:43 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

>>     I haven't seen that problem before, so I can't point you
>> to the right place to fix it at the moment.

By greping, I found possible culprits in cg/mop_alpha.C, p4_alpha/p4_alpha.C,
saturn/target.C, vom/vom_as_directives.C, and symtab/value.C.  It doesn't
look like it would be too hard to change, but there might be a few catches.
For example, it looks like Multiflow thinks the types of the constants are
float (32-bit), but 64-bit ldt instructions are used to load them.  The
types may have to be fixed.

>>     Susan is correct that I am out of town.  I will be back in
>> Seattle by the 21st so I will check in with you then.

Sounds good.  At least five other things are higher on my priority list, so
it isn't likely I'll be stuck on this before then.

--Brian

To: spin-comp@meitner.cs.washington.edu
Subject: commit to lib, bin, mflow/p2dyc
Date: Thu, 16 Oct 1997 01:46:46 PDT
From: Brian Grant <grant@meitner.cs.washington.edu>

I added the test for sufficient table space, so now we can use tables until
they are filled, rather than allocating a new one each time.  This and one
other minor fix has caused one more of the regression tests to work, but
two working ones to fail.  However, the reason they are failing is the
cache problem we've encountered before.

The programs crash after jumping to two words beyond the last instruction
stitched.  It always happens after the second call to the GE.  Of course,
no code really branches or jumps to that address, and the program runs
fine if a breakpoint is inserted anywhere in the stitched code.  So, it
can't be debugged with gdb.  

It doesn't seem to matter how much space we leave between the two pieces of
stitched code (I've tried between zero and 1024 bytes) and it doesn't matter
whether the code stitched second branches to the code stitched first or not.
Ideas, anyone?

--Brian

To: spin-comp@thistle.cs.washington.edu
Subject: i-cache problem
Date: Thu, 16 Oct 1997 11:12:36 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

I put in an imb pal call to flush the icache every time after stitching and
that solved the weird behavior, but at the cost of >200 cycles for every
call to the GE.

From Charlie's previous message:
>> There are two parts to the cost of an imb. First there is a constant
>> cost to execute the instruction itself and second there is the
>> cost of every cache miss you take that would have been a hit without
>> the imb instruction. I carried out the measurements on one of the 
>> SPIN Alpha's, but we can repeat them on any machine we want to know
>> about. I found that the constant cost of the imb instruction was
>> 219 cycles and the cost of the added cache misses was 1.05 cycles per
>> instruction. This gives us a lower bound on how many cycles it will cost
>> us to dynamically compile an instruction. For example, if we dynamically
>> generate N instructions and don't cause any extra cache misses, then it
>> takes at least 219/N cycles per generated instruction.

--Brian

Date: Thu, 16 Oct 1997 11:20:05 -0700 (PDT)
From: chambers@klamath (Craig Chambers)
To: grant@cs.washington.edu
Subject: Re: i-cache problem
Cc: spin-comp@cs

Hmm.  Unless you're reusing previously-executed instruction space, I don't
see how this problem could occur.  As long as you have at least a cache line
distance between the last instruction of the previous chunk of instructions 
and the first instruction of the new one.  Does the alpha prefetch instructions
beyond a cache line?

-- Craig

Date: Thu, 16 Oct 1997 11:50:20 -0700 (PDT)
From: Markus Mock <mock@apex.cs.washington.edu>
To: Brian Grant <grant@cs>, spin-comp-archive@cs,
cc: Markus Mock <mock@cs>
Subject: dotproduct & first times

With an additional make_static in the loop to prevent Multiflow unrolling
dotproduct runs for n=10 and n=100 but not for n=200:
Assertion failed: 0, file dyc_cache.c, line 42

The result is correct, the runtime, however, is more than twice as high
than the noop version. (for n = 10, 35% slower for n=100)


Probably we should compile the noop version with Multiflow and not with cc
to make sure that the time difference is not due to better
cc-optimizations.


	-- Markus


To: mock@thistle.cs.washington.edu
cc: spin-comp-archive@cs
Subject: Consel's benchmarks, loop lazy
Date: Thu, 16 Oct 1997 13:14:38 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

The BTA doesn't seem to be correctly finding lazy edges.  It works for the
simple specialize_lazy case in DyC/regression/multiunit-lazy, but not for
loop_specialize_lazy in DyC/regression/loop-lazy.  The run-time symptom of
this is that the loop unrolls until the cache runs out of space.  I believe
this is what is also happening for Consel's benchmarks.  Please take a look.
I left the CFG for loop-lazy on your keyboard.

--Brian

Date: Thu, 16 Oct 1997 13:29:14 -0700 (PDT)
From: Markus Mock <mock@apex.cs.washington.edu>
To: grant@cs.washington.edu
cc: mock@thistle.cs.washington.edu, spin-comp-archive@cs
Subject: Re: Consel's benchmarks, loop lazy

Ok, I'll check it out.


	-- Markus

On Thu, 16 Oct 1997, Brian Grant wrote:

> The BTA doesn't seem to be correctly finding lazy edges.  It works for the
> simple specialize_lazy case in DyC/regression/multiunit-lazy, but not for
> loop_specialize_lazy in DyC/regression/loop-lazy.  The run-time symptom of
> this is that the loop unrolls until the cache runs out of space.  I believe
> this is what is also happening for Consel's benchmarks.  Please take a look.
> I left the CFG for loop-lazy on your keyboard.
> 
> --Brian
> 


To: spin-comp@thistle.cs.washington.edu
Subject: a new hypothesis on the i-cache trouble: write buffer
Date: Thu, 16 Oct 1997 13:39:19 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

It could be that the instructions in the write buffer don't get flushed
before they are executed.  The write buffer can store up to 32 instructions.
I put in a wmb instruction to flush the write buffer instead of executing
an "call_pal imb" and all of the examples still worked, so that may have
been it.

--Brian

To: spin-comp@franklin.cs.washington.edu
cc: jlo@franklin.cs.washington.edu
Subject: More details on the cache behavior fix...
Date: Thu, 16 Oct 1997 13:54:39 PDT
From: Matthai Philipose <matthai@franklin.cs.washington.edu>

Luckily, it turns out that Patterson and Hennessy has a detailed
account of the 21064's memory hierarchy. Basically, there's prefetching
of one (32 byte) cache block into the Icache. But we are padding to
allow a whole empty cache block, so that shouldn't be the problem
(as Craig pointed out earlier too).

The only other option I could think of is that the L1 (writeback) d-cache  is 
not 
coherent wrt the L2 cache because it doesn't flush its write buffer
(which contains 4 cache blocks  == 32 instructions) soon enough.
We start executing instructions almost as soon as they are generated.

If so, we should be able to use a much cheaper mechanism than imb
(which makes the entire i-cache coherent wrt L2/memory); the wmb
instruction that Brian found in the architecture manual is hopefully
this cheaper instruction. As a quick sanity check, I'm going to 
"manually" flush the write buffer by appending the current code with
4 cache-blocks worth of no-ops and check if the code still works.

Of course, at some stage, we should probably confirm that the 
wmb is indeed cheaper than the imb (i.e. flushing the 4 cache-block
write buffer is cheaper than making the 8K icache coherent)... just
a sanity check.
			Matthai


-------Brian's original message:
It could be that the instructions in the write buffer don't get flushed
before they are executed.  The write buffer can store up to 32 instructions.
I put in a wmb instruction to flush the write buffer instead of executing
an "call_pal imb" and all of the examples still worked, so that may have
been it.

--Brian


Date: Thu, 16 Oct 1997 17:47:58 -0700 (PDT)
From: Markus Mock <mock@apex.cs.washington.edu>
To: Brian Grant <grant@cs>, spin-comp-archive@cs
cc: Matthai Philipose <matthai@cs>, Markus Mock <mock@cs>
Subject: laziness

Brian,

the reason why the branch was not found lazy was because you moved the
call to  dyc_ComputeBranchLaziness() out of the BTA without making sure
that the QLOOP info was computed correctly at that point. I inserted a
call to compute the QLOOP info directly in the lazinesss computation now
and it identifies the branch correctly now. I am testing on the regression
suite then check in.


	-- Markus


To: Markus Mock <mock@apex.cs.washington.edu>
cc: Brian Grant <grant@cs>, spin-comp-archive@cs,
Subject: Re: laziness 
Date: Thu, 16 Oct 1997 21:10:09 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

>> the reason why the branch was not found lazy was because you moved the
>> call to  dyc_ComputeBranchLaziness() out of the BTA without making sure
>> that the QLOOP info was computed correctly at that point. I inserted a
>> call to compute the QLOOP info directly in the lazinesss computation now
>> and it identifies the branch correctly now. I am testing on the regression
>> suite then check in.

Thanks.  Sorry about that.  There was something I thought I wanted to do before
computing the edges, then changed my mind and decided to incrementally update
the edge info afterwards.

If you have programs you used to test the bta, we should put them into the
regression test suite.  Do you have any that actually compile and run that
you would like included?

--Brian

Date: Thu, 16 Oct 1997 21:50:59 -0700 (PDT)
From: "Markus U. Mock" <mock@cs.washington.edu>
To: spin-comp@cs.washington.edu
Subject: chebychev going through

The laziness computations works correctly again (it was called from a
place where the Mflows loop info pass was out of date and hence loop
headers were not identified correctly).

This makes the chebychev approximation go through now (runs and produces
correct result).

All but one of our regression test programs work now too.



	-- Markus 



To: matthai@thistle.cs.washington.edu
cc: spin-comp-archive@cs
Subject: another lost label
Date: Fri, 17 Oct 1997 10:40:42 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

In /afs/cs/project/dyncomp/grant/Test/consel/romberg.DyC:

Unresolved:
L187$3

This is a weird one.  It is the destination of two static branches.  Another
static branch branches to L186$3, which just then branches to L187$3.  I
thought Multiflow would be smarter than that?  Anyway, just removing the
static branches leaves the following unreachable piece of code:

L186$3:
	br	$31,L187$3

I'm not sure what to do about this...

--Brian

Date: Fri, 17 Oct 1997 15:58:31 -0700 (PDT)
From: Markus Mock <mock@apex.cs.washington.edu>
To: Matthai Philipose <matthai@cs>, spin-comp-archive@cs
Subject: dotproduct

for large n=200 it fails too:
(like chebychecv)

assertion failed: 0, file dyc_cache.c, line 42


	-- Markus


Date: Sat, 18 Oct 1997 16:53:21 -0700 (PDT)
From: Markus Mock <mock@cs.washington.edu>
To: Brian Grant <grant@cs>, Matthai Philipose <matthai@cs>,
cc: Markus Mock <mock@cs>
Subject: some new error

xv now goes thru the BTA. I had to munge the annotation a bit to prevent
multiple divisions which in turn exposed a bug in BTA merge where empty
divisions were not correctly purged.
Now, however, I get a new error:

mi(2276) expect(8016.07) rel_expect(0) (Is_Igoto)(compact)  Schedule(0)
Aregion(-1)(Empty)

        preds: mi(2275) 
        succs: mi(2113) mi(2280) 
        edge_count(2) edge_probs: 0.5 0.5 


? FATAL COMPILER ERROR
? bk_Mi__Buffer_Rejoin: 'pred' is compact
? (file:line) ts/bookkeeper.C:1204
*** Exit 1
Stop.

Any ideas?

	-- Markus


To: spin-comp@thistle.cs.washington.edu
Subject: stack works!
Date: Sun, 19 Oct 1997 11:48:25 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

A version of the stack interpreter now works and has been added to the
regression test suite.  However, the system is still very fragile and extremely
minor changes to the interpreter code cause the compiler to crash in the
back end.  I don't have a clue why it is happening and it is in a part of
the back end I've not looked at before.  What is peculiar is that just about
any change (variable types from long to int, moving lines around, inserting/
removing calls to printf(), etc.) causes the compiler to fail the same
assertion.  Another of the regression tests, multiunit-promote, also fails
when a call to printf() is inserted in a particular place.  Pretty scary.

--Brian


To: grant@franklin.cs.washington.edu
cc: Matthai Philipose <matthai@franklin.cs.washington.edu>,
Subject: Change needed in scheme for emitting static branches?
Date: Sun, 19 Oct 1997 16:46:26 PDT
From: Matthai Philipose <matthai@franklin.cs.washington.edu>

Hey Brian,
I'm working on the scheme for emitting out-of-line static
branches, and came across this apparent problem with our
current scheme for emitting them in the in-line case.

Consider the following static branch followed by inline
spill code from the fft code (lots of cruft removed):

-----code from fft_duhamel.pms:
fft.dyn_template_begin_10:
fft.DYC.STATIC_BRANCH.D.7.B.32:
fft.dyn_template_end_10_n:
	static_branch: beq	$25,L645$3	 #class source	 # line 49, 
fft.static_branch_10_0
	lda	$25,-1($31)	 
	cpys	$f31,$f31,$f31	

L646$3:
fft.DYC.UNIT_HEAD.TEMPLATE.7:
fft.dyn_template_begin_19:
	...
----------

In the case that the above branch falls through in setup code (at stitch
time), the lda (inline spill-code) gets emitted, and we're fine.

However, in the case the branch takes, we don't want the lda to get emitted.
Currently, all we do for static branches (inter or intra unit) is to ignore 
the static branch. 
So the lda will still get emitted, giving the wrong answer.

What we want is for the lda (inline spillcode) to get emitted only if the beq 
holds at stitch time.

The only  convenient way in which I can think of doing this is to make
the rtconst argument of the beq a bonafide rtconst with a corresponding
placeholder store. We could then transfer the above branch to setup code so as 
to
branch on the rtconst-holding register of the setup code (see the example
below, if that sounds like garbage!).

------Example:
Assuming you have placeholders for static_branch... rtconsts,
the setup code line:
		stq	$17,fft.static_branch_10_0($31)
will become (given the above template code):
		beq	$17, DL1
		emit	'lda	$25,-1($31)'
		emit 	'cpys	$f31,$f31,$f31'
	DL1:
		...

-------

What do you think? 
	--Do you agree there's a problem?
	--Does it look like the above solution works?
	--If so, can you think of any easier ways to solve it?
	--If you're agreed on this method, can you put in the placeholder store ASAP?
		
Let me know ASAP, because I want to begin hacking this
thing as soon as I can. I will probably spend another hour or so working
on a big overhaul of the branchpatching code (taking ool blocks into account)
and will probably begin hacking the merger around 6:00 pm.
			Matthai



Date: Mon, 20 Oct 1997 10:01:54 -0700 (PDT)
From: chambers@klamath (Craig Chambers)
To: spin-comp@cs, spin@cs, cecil@cs
Subject: UW-CSE Colloq / 10-24-97 / Hornof / IRISA / Program Specialization for Adaptive Operating Systems

In case you didn't see this....

-- Craig


----- Begin Included Message -----

From voting-faculty-request@june  Fri Oct 17 11:29:16 1997
Delivery-Date: Fri, 17 Oct 1997 11:29:17 PDT
Date: Fri, 17 Oct 1997 11:26:07 -0700 (PDT)
From: Scott Dakins <sjdakins@cs.washington.edu>
To: talks@cs.washington.edu
Subject: UW-CSE Colloq / 10-24-97 / Hornof / IRISA / Program Specialization for Adaptive Operating Systems
MIME-Version: 1.0
Sender: owner-talks@cs.washington.edu

UNIVERSITY OF WASHINGTON
Seattle, Washington 98195

Department of Computer Science and Engineering
Box 352350
(206) 543-1695

*NOTE* This lecture will NOT be videotaped for broadcast.

COLLOQUIUM

SPEAKER:	Luke Hornoff, IRISA

TITLE:		Program Specialization for Adaptive Operating Systems

DATE:		Friday, October 24, 1997

TIME:		3:30 pm

PLACE:		224 Sieg Hall

HOST:		Craig Chambers

ABSTRACT:

The need for an operating system to adapt to a changing environment is
becoming increasingly important in areas such as mobile computing,
interactive multimedia, and large distributed databases.  Program
specialization, i.e. optimizing a program with respect to its context of
use, plays a key role in obtaining such an adaptive system.  Toward this
end, we have developed Tempo, a partial evaluator designed to specialize
systems code.  This talk gives an overview of Tempo and an in depth
presentation of its static analyses, which contain a number of key features
that enable Tempo to automatically and effectively exploit specialization
opportunities.  Experimental results show significant speedups are obtained
by specializing system components, such as Sun RPC.

Email: talk-info@cs.washington.edu
Info: http://www.cs.washington.edu



----- End Included Message -----


Date: Mon, 20 Oct 1997 14:57:34 -0400 (EDT)
From: Charles Garrett <garrett@deer-park.etcons.com>
To: eggers@cs.washington.edu
Subject: my address


Susan,

    I want to make sure that you receive my new
address, so I am repeating this e-mail which 
bounced.  

My current address is:

8517A 5th Ave. NE
Seattle WA, 98115

My home and work number is (206) 528-3766.

I will have to move at the end of October and I will
send you the updated address info then.

--
Charlie

Date: Mon, 20 Oct 1997 12:30:18 -0700 (PDT)
From: chambers@klamath (Craig Chambers)
To: spin-comp@cs
Subject: meeting @ 1:30

We meet at 1:30 (again), from now on, starting today.

-- Craig

To: egs@franklin.cs.washington.edu
cc: spin-comp-archive@franklin.cs.washington.edu
Subject: bug in mipsi from tar file...
Date: Mon, 20 Oct 1997 19:10:10 PDT
From: Matthai Philipose <matthai@franklin.cs.washington.edu>

Hey Gun,
When I run the verion of mipsi that comes out of the
tar file on sort as you suggested, it does the
sorting and then seg faults in syscalls.c, line 388:
	sighandler[R[REG_A0]].sv_handler = (void(*)()) x;
Basically, R[REG_A0] evaluates to 4199644, which is out of
range for the sighandler array.

The command that generated the seg fault was:
	mipsi sort < print.c

"mipsi ls" seems to work fine.

Any feedback?
		Thanks,
		Matthai
		



Date: Mon, 20 Oct 1997 19:52:48 -0700 (PDT)
From: Markus Mock <mock@cs.washington.edu>
To: Matthai Philipose <matthai@cs.washington.edu>
cc: Markus Mock <mock@cs>, Brian Grant <grant@cs>, spin-comp-archive@cs
Subject: Re: Strange behavior of multiunit-promote 

Actually, I don't see a demotion there in the BTA, when I debug it. So I
guess the demotion comes in when Brian does some graph restructuring since
the BTA that's printedin .bta file is not actually the BTA as it is
computed after the BTA pass but after some of Brian's restructuring.


	-- Markus

On Mon, 20 Oct 1997, Matthai Philipose wrote:

> But v is demoted at the same edge... (v is annotated to be
> specialized monvariantly).
> 			Matthai
> 
> 


Date: Mon, 20 Oct 1997 19:57:45 -0700
From: egs@june (Emin Gun Sirer)
To: matthai@cs.washington.edu
Subject: Re:  bug in mipsi from tar file...
Cc: spin-comp-archive@june

Matthai,

The problem is just that I wrote portable but not cross-architecture
code. Specifically, I used "sizeof(int *)" to refer to a pointer size
in the simulated program. But since the simulator is compiled on an
alpha, that expression evaluates to 8, whereas it ought to evaluate
to 4 to match the MIPS program being simulated.

I fixed all such occurances of this problem in syscall emulation. The
patch is appended to the end of this message. You can also pick up the
whole file from /homes/gws/egs/src/mipsi/alpha/syscalls.c

Enjoy, (and don't count on such speedy turnaround next time)
Gun.

;diff -c syscalls.c*
*** syscalls.c  Mon Oct 20 19:53:07 1997
--- syscalls.c~ Mon Sep 29 12:18:25 1997
***************
*** 37,47 ****
  #define stdin           (&_iob[0])
  #define stdout          (&_iob[1])
  #define stderr          (&_iob[2])
- #define INTSIZE 4
- #define SIGSETSIZE 4
  #else
- #define INTSIZE sizeof(int*)
- #define SIGSETSIZE sizeof(sigset_t)
  #include <stdio.h>
  #endif
  
--- 37,43 ----
***************
*** 382,398 ****
            traceout("SYSCALL sigvec(%d, 0x%x, 0x%x) = ", R[REG_A0], R[REG_A1], R[REG_A2]);
            if(R[REG_A2] != 0) {
                snr_mem_word(R[REG_A2], sighandler[R[REG_A0]].sv_handler);
!               snr_mem_word(R[REG_A2]+INTSIZE,sighandler[R[REG_A0]].sv_mask);
!               snr_mem_word(R[REG_A2]+INTSIZE+SIGSETSIZE, sighandler[R[REG_A0]].sv_flags);
            }
            if((R[REG_A1] == 0) || (R[REG_A1] == 1)) /* SIG_DFL SIG_IGN */
                R[REG_RES] = sigvec(R[REG_A0], R[REG_A1],NULL);
            else {
                x = rnr_mem_word(R[REG_A1]);
                sighandler[R[REG_A0]].sv_handler = (void(*)()) x;
!               x = rnr_mem_word(R[REG_A1] + INTSIZE);
                sighandler[R[REG_A0]].sv_mask = x;
!               x = rnr_mem_word(R[REG_A1] + INTSIZE + SIGSETSIZE);
                sighandler[R[REG_A0]].sv_flags = x;
                R[REG_RES] = sigvec(R[REG_A0], &hnd, NULL);
            }
--- 378,394 ----
            traceout("SYSCALL sigvec(%d, 0x%x, 0x%x) = ", R[REG_A0], R[REG_A1], R[REG_A2]);
            if(R[REG_A2] != 0) {
                snr_mem_word(R[REG_A2], sighandler[R[REG_A0]].sv_handler);
!               snr_mem_word(R[REG_A2]+sizeof(int*),sighandler[R[REG_A0]].sv_mask);
!               snr_mem_word(R[REG_A2]+sizeof(int *)+sizeof(sigset_t), sighandler[R[REG_A0]].sv_flags);
            }
            if((R[REG_A1] == 0) || (R[REG_A1] == 1)) /* SIG_DFL SIG_IGN */
                R[REG_RES] = sigvec(R[REG_A0], R[REG_A1],NULL);
            else {
                x = rnr_mem_word(R[REG_A1]);
                sighandler[R[REG_A0]].sv_handler = (void(*)()) x;
!               x = rnr_mem_word(R[REG_A1] + sizeof (int *));
                sighandler[R[REG_A0]].sv_mask = x;
!               x = rnr_mem_word(R[REG_A1] + sizeof(int *) + sizeof(sigset_t));
                sighandler[R[REG_A0]].sv_flags = x;
                R[REG_RES] = sigvec(R[REG_A0], &hnd, NULL);
            }

Date: Tue, 21 Oct 1997 11:44:41 -0700 (PDT)
From: Markus Mock <mock@apex.cs.washington.edu>
To: spin-comp@apex.cs.washington.edu
Subject: One reason why dotproduct is slow

Small runtime constants are not put into the immediate field (as they
should) and are instead loaded from memory. Matthai is fixing this right
now and since the Consel dotproduct uses vectors with 90% zero values that
should make some notable difference. 
Also, we currently don't constant-fold away multiplications by 0 so I'll
add a check

 if (u@[i])
      res = res + u@[i]*v[i];

to do the multiplation only in the non-zero case. The test should be
folded away during setup and only the 10% remaining multiplications and
adds should remain.


	-- Markus


Date: Tue, 21 Oct 1997 11:52:57 -0700 (PDT)
From: Markus Mock <mock@apex.cs.washington.edu>
To: Matthai Philipose <matthai@cs>, spin-comp-archive@cs
cc: Markus Mock <mock@cs>
Subject: merger problem

Merging...
line 1098: Label L34$3: for template block template_4 emitted after begin
tag at /afs/cs/project/dyncomp/mock/DyC/bin/stitch.pl line 418,
<ASSEMBLER> chunk 1098.
*** Exit 2


for the folling code:

int dotproduct(int size, int u[], int v[])
{
  int i;
  int res;

  make_static(size, u);
  res = 0;

  make_static(i);
  for (i=0; i<size; i++)
  {
    if (u@[i])
      res = res + u@[i]*v[i];
    make_static(i);
  }
  return res;
}


	-- Markus


Date: Tue, 21 Oct 1997 11:53:20 -0700 (PDT)
From: chambers@klamath (Craig Chambers)
To: spin-comp@apex.cs.washington.edu, mock@apex.cs.washington.edu
Subject: Re: One reason why dotproduct is slow

> Also, we currently don't constant-fold away multiplications by 0 so I'll
> add a check
> 
>  if (u@[i])
>       res = res + u@[i]*v[i];
> 
> to do the multiplation only in the non-zero case. The test should be
> folded away during setup and only the 10% remaining multiplications and
> adds should remain.

Why isn't this something that should be done as part of the emit statement
for the multiply?  Along with the other arithmetic simplifications of mults
by powers of two and mults using sequences of shifts and adds?  Or is this
change just a stop-gap until we actually implement the simplification rules
for multiplies?  (Mult by 1/-1 and add of 0 and div by 1/-1 and div of 
unsigned numbers by powers of two and mod of unsigned numbers by powers of
two should also be simplified, eventually.)

-- Craig

Date: Tue, 21 Oct 1997 11:56:52 -0700 (PDT)
From: Markus Mock <mock@apex.cs.washington.edu>
To: Craig Chambers <chambers@klamath>
cc: spin-comp@apex.cs.washington.edu
Subject: Re: One reason why dotproduct is slow

Just a stopgap until we do those simplifications.


	-- Markus

On Tue, 21 Oct 1997, Craig Chambers wrote:

> > Also, we currently don't constant-fold away multiplications by 0 so I'll
> > add a check
> > 
> >  if (u@[i])
> >       res = res + u@[i]*v[i];
> > 
> > to do the multiplation only in the non-zero case. The test should be
> > folded away during setup and only the 10% remaining multiplications and
> > adds should remain.
> 
> Why isn't this something that should be done as part of the emit statement
> for the multiply?  Along with the other arithmetic simplifications of mults
> by powers of two and mults using sequences of shifts and adds?  Or is this
> change just a stop-gap until we actually implement the simplification rules
> for multiplies?  (Mult by 1/-1 and add of 0 and div by 1/-1 and div of 
> unsigned numbers by powers of two and mod of unsigned numbers by powers of
> two should also be simplified, eventually.)
> 
> -- Craig
> 


Date: Tue, 21 Oct 1997 11:58:46 -0700 (PDT)
From: chambers@klamath (Craig Chambers)
To: spin-comp@cs
Subject: Diesel/Whirlwind retreat

It looks like I'm going to have a weekend retreat in Nov. or Dec. to a
nice place in Leavenworth (complete with indoor and outdoor hot tubs)
to brainstorm and plan Diesel and Whirlwind research ideas.  You all are
invited to participate, ideally actively by making presentations of your ideas
related to this work (e.g. the dynamic compilation aspects).  Who is 
interested?  What weekends in Nov. or Dec. could you make?

-- Craig

Date: Tue, 21 Oct 1997 12:04:46 -0700 (PDT)
From: Markus Mock <mock@apex.cs.washington.edu>
To: Brian Grant <grant@cs>, spin-comp-archive@cs,
cc: Markus Mock <mock@cs>
Subject:  multiunit-promote problem fixed

With the new version of the BTA the multiunit-promote test works fine. I
haven't checked it in yet, though.

Brian, since you found the loop-lazy problem, can I update and check in?


	-- Markus


Date: Tue, 21 Oct 1997 12:10:08 -0700 (PDT)
From: chambers@klamath (Craig Chambers)
To: cecil@cs, spin-comp@cs, egs@klamath, brad@klamath, echris@klamath
Subject: Re: retreat

PS.  Nov 8 & 9 is the only open date it turns out at the place I was thinking
about.  Let me know soon if that date doesn't work for you.  If enough people
have conflicts with that date, then we can try a different place & date.

-- Craig

Date: Tue, 21 Oct 1997 13:33:04 -0700 (PDT)
From: chambers@klamath (Craig Chambers)
To: cecil@cs, spin-comp@cs, egs@klamath, brad@klamath, echris@klamath
Subject: Re: retreat

P.P.S.  Please send me *all* your constraints over Nov. & Dec. weekends,
if you're interested in coming to the retreat, even if you can/can't make
the Nov 8-9 weekend.  Thanks.

-- Craig

To: spin-comp@thistle.cs.washington.edu
Subject: float-constant bug fixed!
Date: Tue, 21 Oct 1997 14:01:11 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

I wrote a test program that demonstrated that only the sizes of float constants
were wrong, and only when double globals were initialized with constants.  So,
I tracked the problem down to a single line that tested the size of the global,
but didn't do the right thing with that information:
	unit_btype = (size == 32) ? ".align 2\n\t.long" : ".align 3\n\t.long";
which I changed to:
	unit_btype = (size == 32) ? ".align 2\n\t.long" : ".align 3\n\t.quad";

This fixed the program in the regression test suite.

GDB had printed incorrect values for the floats.

--Brian

Date: Tue, 21 Oct 1997 14:33:33 -0700 (PDT)
From: Markus Mock <mock@apex.cs.washington.edu>
To: Matthai Philipose <matthai@cs>, spin-comp-archive@cs
Subject: equiv vars revisited

Matthai,

does STAT_equiv_vars return the equiv vars set after or before the stat?
I thought before but looking back at your comment in p2equiv_vars.H
suggests after.
If it's after, then the info in multiple-promote example was bogus after
all.


	-- Markus


Date: Tue, 21 Oct 1997 15:30:50 -0700 (PDT)
From: Markus Mock <mock@apex.cs.washington.edu>
To: Matthai Philipose <matthai@cs>, spin-comp-archive@cs
cc: Markus Mock <mock@cs>
Subject: iterator problem

Matthai,

does that iterator to step through equiv vars AFTER a stat look ok to you:
#define FOR_EACH_VAR_EQUIV_TO_VAR_AFTER_STAT(stat,orig_var,equiv_var)
\
DECLARE(
\
	SET_PARTITION EV_ALIAS(equiv_var);
\
	VAR EV_VAR_ALIAS(equiv_var);
\
	VAR equiv_var;
\
	)                                                              	)
\
INITIAL {
\
	 EV_ALIAS(equiv_var)= STAT_succ(stat) ?
STAT_equiv_vars(STAT_succ(stat)) :
BBLOCK_equiv_vars_out(STAT_bblock(stat));                           \
	 EV_VAR_ALIAS(eSTAT_bblock(stat));                           \
	 EV_VAR_ALIAS(equiv_var)=orig_var;
\
      }
\
FOR_EACH_SET_PARTITION_EQUIVALENT_ELEMENT(EV_ALIAS(equiv_var),
\
					  EV_VAR_ALIAS(equiv_var),
var),               \
					  EV_VAR_ALIAS(equiv_var),
\
					  EV_VAR_ALIAS2(equiv_var))
\
DO{
\
     equiv_var=EV_VAR_ALIAS2(equiv_var);
\
}
					  
?

(pine messed up the formatting)


If there's nothing wrong with that, then I probably have an example where
the equiv vars info isn't set right..

	-- Markus


To: Markus Mock <mock@apex.cs.washington.edu>
cc: spin-comp-archive@franklin.cs.washington.edu
Subject: Re: iterator problem 
Date: Tue, 21 Oct 1997 17:22:16 PDT
From: Matthai Philipose <matthai@franklin.cs.washington.edu>

In general, you cannot look at the bblock_equiv_vars_[in|out] field following
any transformation that succeeds equiv-vars analysis because it is out of 
date. Specifically,
since stats can be re-ordered after the analyses by successor transformation
phases, only the information attached to a stat will be valid. The crucial 
invariant
is that a stat cannot be moved in a way which invalidates its equiv-vars 
analysis,
so the information attached to the stat should still be usable.

Finally, on re-reading the spec I sent you a while ago (appended below), you
should be looking at the equiv-vars info only at a makestatic, where the e-vars
info before and after the stat should be identical. So my understanding is that
you shouldn't need the addition to abstract interface you're trying to write.

Have we changed the way in which we're using equiv-vars?
				Matthai

ps: Frankly, I am not even comfortable with  this minimal use
    of equiv-vars, because there are possible code movements which I am not
    sure multiflow performs in phase2 (but could, I think) that could 
    invalidate the information. The reason we decided to leave it in there
    seems to be to counter the effects of copy prop in some cases we care 
    about.

----------------------
To: spin-comp@franklin.cs.washington.edu
Subject: Abstract interfaces to pre-passes
Date: Tue, 05 Aug 1997 19:18:15 PDT
From: Matthai Philipose <matthai@franklin.cs.washington.edu>

Below are the interfaces to the prepasses to the bta.
They are intended primarily for Markus, who is implementing the bta.

I'm sending this to spin-comp only so that it gets
archived in the mail archive and can be readily looked
up by whoever needs it.
             Matthai
      
------------------
Markus,
Here are the abstract interfaces to the prepasses.
Let me know if you have have questions.

---------------- Summary of how pre-pass info is used (details beyond the PEPM 
paper):

Our understanding right now is that the StaticVarInfo
datastructures will contain TEMP->(policy,source_root) mappings. 

The SourceRoots should be VARs.

The Promotion and DiscordantVar sets will both contain TEMPs that need
to promoted/are discordant at program points.

The Divisions on the other hand will map VAR->policies.

At each make-static(x_i), we identify the x_j equivalent to x_i
(from the equiv-vars set below) iterate through the live temps to 
identify the corresponding temp t_x_j and put it into the 
static-var-info set, as derived static temps with x_i as the source var.

t_x = .... results in t_x getting promoted iff x has the right policy
     (autopromote) in each divisions.

--------------------numbering of   VARs:
		... irrelevant stuff removed.

-------------------equiv-vars:

The following function computes equiv-vars info and attaches it to every 
stat earl in phase2. I have already put in an the invocation, and you don't
need to worry about invoking the function:
EXTERN VOID EV_Compute();

The abstract interface to equiv-vars is through the iterator:
                FOR_EACH_VAR_EQUIV_TO_VAR(stat,orig_var,equiv_var)
which is defined in p2equiv/p2equiv.H.


Given a stat and a source-level variable orig_var, this iterator steps
through every source-level var equivalent to orig_var (INCLUDING orig_var) 
just before the stat.

The function    
        BOOL EV_EquivVarsP(STAT stat, VAR v1,VAR v2);
(also declared in p2equiv/p2equiv.H) is also available, though
probably will not need to use it. It checks if v1 equiv v2 just
before "stat".
-----------------


				


Date: Tue, 21 Oct 1997 18:13:20 -0700 (PDT)
From: "Markus U. Mock" <mock@cs.washington.edu>
To: Matthai Philipose <matthai@franklin.cs.washington.edu>
cc: Markus Mock <mock@apex.cs.washington.edu>, grant@cs.washington.edu,
Subject: Re: iterator problem 

The equiv vars was also intended to be used to treat temps that do not
correspond to an annotated source variable equivalent to a temp
corresponding to an annotated source variable, e.g. when promotions
should happen.
It's easy to disregard the info at that point (i.e. process assignment),
however, we might make a temp static when we really want to keep it
static because of the indirect correspondence to an annotated variable. 
If we don't care about that case, it's easy to change.
Do we agree that we don't care? 


	-- Markus 



To: "Markus U. Mock" <mock@cs.washington.edu>
cc: Matthai Philipose <matthai@franklin.cs.washington.edu>,
Subject: Re: iterator problem 
Date: Tue, 21 Oct 1997 20:55:00 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

>> The equiv vars was also intended to be used to treat temps that do not
>> correspond to an annotated source variable equivalent to a temp
>> corresponding to an annotated source variable, e.g. when promotions
>> should happen.
>> It's easy to disregard the info at that point (i.e. process assignment),
>> however, we might make a temp static when we really want to keep it
>> static because of the indirect correspondence to an annotated variable. 
>> If we don't care about that case, it's easy to change.
>> Do we agree that we don't care? 

I don't remember this case.  I need better notes.  My current thinking is
that two variables can't be equivalent after an assignment unless that
assignment is a copy.  In that case, what would equivalency give us that
derived temps in the BTA would not?  The annotated variable must be static,
so the copied temp will be derived, regardless of its policies.  Therefore,
I claim that equiv_vars gives no useful information at assignments.  Am
I wrong?

--Brian

To: spin-comp@thistle.cs.washington.edu
Subject: all regression tests pass!
Date: Tue, 21 Oct 1997 21:21:30 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

All of our regression tests now pass.  Yeah!
Let's try to keep it that way. :-)

+++ Application dotproduct passed
+++ Application extend-context passed
+++ Application float-demotions passed
+++ Application float-holes passed
+++ Application float-int passed
+++ Application float-unroll passed
+++ Application int-unroll passed
+++ Application loop-lazy passed
+++ Application multiunit-all passed
+++ Application multiunit-lazy passed
+++ Application multiunit-promote passed
+++ Application multiunit-rep passed
+++ Application multiunit-unchecked passed
+++ Application promote1 passed
+++ Application rt-merge passed
+++ Application side-effects passed
+++ Application stack passed
+++ Application static-branch passed
+++ Application unchecked passed
+++ Application unroll1 passed

--Brian

To: mock@thistle.cs.washington.edu
cc: spin-comp-archive@cs
Subject: xvalg
Date: Tue, 21 Oct 1997 23:10:02 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

Update your compiler and try xv again.  I essentially eliminated the
checking of the assertion for certain cases, but I don't know if Multiflow
will do the right thing given that we're violating one of its assumptions
(that tags will always be preceded only by IGOTOs).  Let me know.  I also
fixed what appeared to have been a bug in the original Multiflow source in
the loop-unrolling code.  I don't know if that fix had the right effect,
either.  In any case, the compiler no longer barfs outright on xvalg.DyC.

--Brian

Date: Wed, 22 Oct 1997 09:12:08 -0700
From: eggers@yakima (Susan Eggers)
To: spin-comp@thistle.cs.washington.edu, grant@cs.washington.edu
Subject: Re: all regression tests pass!

This is real good, you all.

Susan

Date: Wed, 22 Oct 1997 10:45:11 -0700 (PDT)
From: chambers@klamath (Craig Chambers)
To: cecil@cs, spin-comp@cs, melody@cs

Thanks for the card!

-- Craig

Date: Wed, 22 Oct 1997 11:01:43 -0700 (PDT)
From: chambers@klamath (Craig Chambers)
To: spin-comp@thistle.cs.washington.edu, grant@cs.washington.edu
Subject: Re: all regression tests pass!

Great!!

-- Craig

Date: Wed, 22 Oct 1997 17:44:12 -0700 (PDT)
From: Markus Mock <mock@apex.cs.washington.edu>
To: spin-comp@apex.cs.washington.edu
Subject: romberg added to regression suite

I've just added romberg to the regression suite. It goes through fine for
my current configuration, so update your regression directory.

I've also integrated the smarter BTA_Merge
where a derived temp is only killed if any of its root temps is discordant
at the merge.  This made cos@(PI * (k - 0.5) / n)) static as desired in
the chebychev benchmark.


[before Multiflow had hoisted PI/n out of the loop as a loop invariant and
the loop head merge made it (PI/n) dynamic.]


	-- Markus


To: Markus Mock <mock@cs.washington.edu>
cc: spin-comp-archive@franklin.cs.washington.edu
Subject: try timing dotproduct...
Date: Wed, 22 Oct 1997 17:56:44 PDT
From: Matthai Philipose <matthai@franklin.cs.washington.edu>

We're supposed to be optimized to avoid producing extra
table loads now. So except for the multiply be zero,
we should be pretty close to where we want.
			Matthai

To: spin-comp@franklin.cs.washington.edu
Subject: small-victory...
Date: Wed, 22 Oct 1997 19:18:08 PDT
From: Matthai Philipose <matthai@franklin.cs.washington.edu>

mipsi passes through multiflow and gives the right answer
(WITHOUT D.C. annotations). There were some minor hiccups because the
mipsi file contains a setjmp (not in the dynamic region) and because
it has a function with no body. I am going ahead with annotation...

Of consel's benchmarks, we currently have dotproduct and romberg
working. We found a bunch of reasons why dotproduct was slow (not the
the least of which was that we weren't unrolling the dotproduct loop
using an unchecked policy). Consel's Chebyshev benchmark was working
along the way, but doesn't seem to, anymore.
		Matthai

Date: Wed, 22 Oct 1997 21:12:42 -0700
From: eggers@yakima (Susan Eggers)
To: spin-comp@franklin.cs.washington.edu, matthai@cs.washington.edu
Subject: Re: small-victory...


I love this phase.

Susan

Date: Wed, 22 Oct 1997 22:50:03 -0700 (PDT)
From: "Markus U. Mock" <mock@cs.washington.edu>
To: Matthai Philipose <matthai@cs.washington.edu>
cc: spin-comp-archive@franklin.cs.washington.edu
Subject: Re: try timing dotproduct...

I haven't looked at the new code that's produced yet but the timings are
still bad, in fact I think they might be worse.



	-- Markus 


On Wed, 22 Oct 1997, Matthai Philipose wrote:

   We're supposed to be optimized to avoid producing extra
   table loads now. So except for the multiply be zero,
   we should be pretty close to where we want.
   			Matthai
   


To: spin-comp@cs
Subject: fixed memory problems
Date: Wed, 22 Oct 1997 23:18:55 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

All regression tests, including chebychev and romberg, now pass.  I fixed
a memory leak and expanded space provided for the caches.  Update lib and
mflow/p2dyc.

--Brian

Date: Thu, 23 Oct 1997 11:29:58 -0700 (PDT)
From: Markus Mock <mock@apex.cs.washington.edu>
To: Brian Grant <grant@cs>, spin-comp-archive@cs,
cc: Markus Mock <mock@cs>
Subject: update on fft and csi


Both fft and csi fail with a floating point exception. 


I've put the code in my regression directory 
/afs/cs.washington.edu/project/dyncomp/mock/DyC/regression/
csi/fft

(not checked in yet since they don't work)

I am now looking back at xv.


	-- Markus


Date: Thu, 23 Oct 1997 11:48:37 -0700 (PDT)
From: Markus Mock <mock@apex.cs.washington.edu>
To: spin-comp@apex.cs.washington.edu
Subject: small victory for dotproduct

With the latest changes to DyC we get some speedups for dotproduct if we
check for multiplication by zero:

n = vector size (90% zero-filled vector)
10000 iterations for each n
times in ms for 10000 iterations (only user time)


n       dyc     mflow   cc -O2
--------------------------------------
10      76      14      12

100     110     98      85

200     152     193     167

500     308     478     411

The code we produce has only the necessary loads, multiplies and adds left
for the non-zero vector elements. Some unconditional branches to branches
are left that should have been removed, Brian is looking for that bug.





	-- Markus


Date: Thu, 23 Oct 1997 11:52:29 -0700 (PDT)
From: chambers@klamath (Craig Chambers)
To: spin-comp@apex.cs.washington.edu, mock@apex.cs.washington.edu
Subject: Re: small victory for dotproduct

Cool!

Can we time how long just executing the dynamically compiled code takes?
E.g., call a dynamic region once to generate the code, and then time calling it
N times?  By subtracting, we could measure the DC start-up cost and the
asymptotic per execution cost pretty easily, and calculate the cross-over
point etc. directly.  Also knowing the # of instructions generated would let
us compute the # of cycles/instruction generated DC overhead.

-- Craig

To: mock@thistle.cs.washington.edu
cc: matthai@thistle.cs.washington.edu, spin-comp-archive@cs
Subject: memory leak in dotproduct
Date: Thu, 23 Oct 1997 12:52:08 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

I don't see a memory leak.  In the debugger, I put a break point whenever
new memory is allocated and none is allocated after the first successful
cache lookup.  I can also run a million iterations with a modified version
of the driver that doesn't try to save all of the answers in a vector and
print them out.  Look at:
/afs/cs/project/dyncomp/grant/Test/consel/dotproduct.DyC

% dotproduct.x 100 1000000
Answers match: 656442

--Brian

Date: Thu, 23 Oct 1997 14:45:27 -0700 (PDT)
From: Markus Mock <mock@apex.cs.washington.edu>
To: grant@cs.washington.edu
cc: mock@thistle.cs.washington.edu, matthai@thistle.cs.washington.edu,
Subject: Re: memory leak in dotproduct

I think I know what happened: my dycrt.a had not been correctly
recompiled. With the new one it now works fine!
Sorry for the trouble.

Doesn't the standard makefile rebuild the library if necessary?

	-- Markus

On Thu, 23 Oct 1997, Brian Grant wrote:

> I don't see a memory leak.  In the debugger, I put a break point whenever
> new memory is allocated and none is allocated after the first successful
> cache lookup.  I can also run a million iterations with a modified version
> of the driver that doesn't try to save all of the answers in a vector and
> print them out.  Look at:
> /afs/cs/project/dyncomp/grant/Test/consel/dotproduct.DyC
> 
> % dotproduct.x 100 1000000
> Answers match: 656442
> 
> --Brian
> 


Date: Thu, 23 Oct 1997 18:41:09 -0700 (PDT)
From: Markus Mock <mock@apex.cs.washington.edu>
To: Brian Grant <grant@cs>, spin-comp-archive@cs
cc: Markus Mock <mock@cs>
Subject: xv

I am not sure why the 0x2 and 0x4 get emitted.
You can build xv in 
/afs/cs.washington.edu/project/dyncomp/mock/benchmarks/xv/xv-3.10a
by invoking the build script.

run xv on liebe.jpg (or any other image) and invoke Blur from the
algorithms menu.

	-- Markus


Date: Fri, 24 Oct 1997 10:39:17 -0700 (PDT)
From: Markus Mock <mock@apex.cs.washington.edu>
To: spin-comp@apex.cs.washington.edu
Subject: application status web page

I have set one up in our internal web at:

Go to:
http://www.cs.washington.edu/research/projects/unisw/DynComp/www/Internal/

and from there to "Application Status"

Will be continually updated as more applications make it through DyC.

	-- Markus


Date: Fri, 24 Oct 1997 11:51:22 -0700
From: eggers@yakima (Susan Eggers)
To: spin-comp@apex.cs.washington.edu, mock@apex.cs.washington.edu
Subject: Re: application status web page


Actually I like getting mail from you all about the victories.
Kind of perks up my day.

Susan

Date: Fri, 24 Oct 1997 12:56:40 -0700 (PDT)
From: chambers@klamath (Craig Chambers)
To: spin-comp@apex.cs.washington.edu, mock@apex.cs.washington.edu,
Subject: Re: application status web page

The hourly perk-ups can continue, but the web page will summarize all previous
victories, for when you want to get an overall picture of what the status is.
I've done this in my work with e.g. Jeff and Dave, and it's helped me a lot to
keep track, and I suggested to Markus that he set this up for the PLDI work.
I already have a better picture (I think!) from the chart.

-- Craig

Date: Fri, 24 Oct 1997 14:57:31 -0700 (PDT)
From: chambers@klamath (Craig Chambers)
To: spin-comp@cs, cecil@cs
Subject: reminder: Luke Hornoff talk

Remember, Luke Hornoff's talk is at 3:30 this afternoon in 224.

-- Craig

To: spin-comp@franklin.cs.washington.edu
Subject: Need for reachability analysis?
Date: Fri, 24 Oct 1997 18:43:49 PDT
From: Matthai Philipose <matthai@franklin.cs.washington.edu>

mipsi has the following code configuration:

s1 is known to be  static:

           switch(s1){
		case 1: t = 3; ... break;
		case 2: t = 4; ... break;
		case 3: t = 5; ... break;
	    }

	   switch(t){
		{
		...


		}


Without reachability analysis, t is deduced to be dynamic and the second 
switch becomes a dynamic switch, which we  cannot handle right now (we have a 
design for, but haven't implemented, the code for copying switches at 
runtime). Since it  is a small  switch, (3 cases, 3 source) lines, it is 
trivial to hand-convert it to an if...else, but this is one reason to have a 
reachability analysis.

		Matthai

To: Matthai Philipose <matthai@cs.washington.edu>
cc: spin-comp@franklin.cs.washington.edu
Subject: Re: Need for reachability analysis? 
Date: Fri, 24 Oct 1997 22:34:43 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

>> Without reachability analysis, t is deduced to be dynamic and the second 
>> switch becomes a dynamic switch, which we  cannot handle right now (we have a 
>> design for, but haven't implemented, the code for copying switches at 
>> runtime). Since it  is a small  switch, (3 cases, 3 source) lines, it is 
>> trivial to hand-convert it to an if...else, but this is one reason to have a
>> reachability analysis.

Another thing we can do (for now) is annotate t to be polyvariantly
specialized.  That should be done for any discordant derived values we want
to live beyond discordant merges.  The cost is a specialization-time cache
lookup + unit-boundary crossing, but we get rid of the execution-time dynamic
branch.  We can explain that X overhead and Y annotations could be removed if
our system were fully implemented.

Clearly, eventually we will want reachability analysis.

--Brian

Date: Sat, 25 Oct 1997 14:52:54 -0700 (PDT)
From: chambers@klamath (Craig Chambers)
To: brad@cs, cecil@cs, echris@cs, egs@cs, fix@cs, spin-comp@cs, trmorris@cs
Subject: Diesel/Whirlwind retreat

As there are more conflicts on the Nov 8-9 date, we'll schedule the
Diesel/Whirlwind retreat for Dec. 6-7, at Semi-ah-moo.  TR, can you go
ahead and cancel the Enzian reservations and proceed on the
Semi-ah-moo stuff?  There'll be 12 students going (perhaps one or two
more), plus me.  I assume they have an indoor pool & hot-tub set-up,
which is a principal requirement for a successful retreat....

Thanks.

-- Craig

Date: Sun, 26 Oct 1997 23:12:21 -0800 (PST)
From: Markus Mock <mock@cs.washington.edu>
To: spin-comp@cs.washington.edu
Subject: speedups for chebychev: from 3.8 to 8.0

I did some timings for chebychev. Here are the results:

time for 10000 iterations [ms]

	dyc	mflow	speedup	consel dyc-stitched	overhead #ins	time/ins
5	239.4	916.2	3.8	5.2	230.0		9.4	425	0.0221

10	505.8	3323.8	6.6	8.2	496.3		9.5	1325	0.0072

15	979.1	7379.7	7.5	9.6	961.8		17.3	2725	0.0063

20	1620.4	13016.8	8.0	10.4	1550.9		69.5	4625	0.0150



dyc is the dynamically compiled version, mflow the standard Multiflow
version.

I determined the DC overhead by timing the 10000 iterations after calling
chebychev() once so that the subsequent calls only had to run the already
stitched code [and do the cache check]. The difference between the time in
column 2 and this time (dyc-stitched) is listed in column overhead.
n is the approximation degree, consel lists the speedup reported by
Consel's group.

I did  the timings on meitner. Assuming that meitner is running at 150Mhz
(I am not sure about this) the 0.0221 ms/instruction stitched would
translate to ~3300 cycles per instruction stitched.

For computed asymptotic speedup and breakeven points this translates to:

n	asym. speedup		#iterations for breakeven
	mflow / dyc-stiched	10000 * overhead / (mflow -dyc-stitched)

5	3.98			137

10	6.70			34

15	7.67			30

20	8.39			61

Consel reports 3 as their breakeven point for all n (5, 10, 15 and 20.)

The times for n=20 are a bit odd. So I timed them again with the same
result. All are averaged over 10 runs. 
Any ideas?



	-- Markus


Date: Sun, 26 Oct 1997 23:17:23 -0800 (PST)
From: Markus Mock <mock@cs.washington.edu>
To: Matthai Philipose <matthai@cs>, spin-comp-archive@cs
cc: Markus Mock <mock@cs>
Subject: table ptr builds in chebychev code

Matthai, 

there are some ldas and ldqs that are superfluous in the dynamically
generated code.
Maybe you can take a look if these should already be removed or this
requires some further hacking (or is impossible).

The  code is in
/afs/cs.washington.edu/project/dyncomp/mock/benchmarks/consel/benchmark-chebychev/cheb-dyn-n 
(n=5,10,15,20)


	-- Markus


To: spin-comp@thistle.cs.washington.edu
Subject: more timing results
Date: Mon, 27 Oct 1997 01:28:59 PST
From: Brian Grant <grant@thistle.cs.washington.edu>

(The first argument is vector size; random elements with about half zeroes.
 Second argument is number of calls to dot product function with same
 arguments.)

Standard Multiflow:
% dotproduct-time.noop.x 300 500
Total time: 3632518 cycles
Total dynamic-compilation overhead: 0 cycles
Work-list overhead: 0 cycles
Caching overhead: 0 cycles
Number of work-list pops: 0
Time spent in stitched code: 0 cycles

Dynamically compiled:
% dotproduct-time.x 300 500
Total time: 3695517 cycles
Total dynamic-compilation overhead: 1292976 cycles
Work-list overhead: 528269 cycles
Caching overhead: 367536 cycles
Number of work-list pops: 1301
Time spent in stitched code: 2319692 cycles

Clearly, we're getting killed on (especially) work-list overhead and caching
overhead.  This is with the loop annotated cache_all_unchecked, so the caching
overhead should only be at the entry to the dynamic region.  A work-list
push/pop is paid upon every execution of the stitched code as well as during
dynamic compilation.  I'll try to determine which work-list operations
should be easy to eliminate so that we can at least make a good argument
that we can cut the cost of DC.

What other info do we want?  I could generate per-unit data as well.  We might
also want more categories (unit-boundary crossings, promotions, discordant
merges, etc.).

--Brian

To: spin-comp@cs
Subject: commit of timing support
Date: Mon, 27 Oct 1997 01:51:28 PST
From: Brian Grant <grant@thistle.cs.washington.edu>

You'll need to do a top-level update.  Currently, only dotproduct has
been updated to include the timing code.  The boilerplate has changed, so
you'll need to remake your .i files for debugging.

The current version doesn't average over multiple runs or compute any
statistics.  It only prints raw times and counts for one run.

Summary of how to use the timing framework:
rt -time [apps]
	Cause the listed apps to be timed instead of tested.  Timing results
	are in app-time*.t for the three versions.
rt -fb ...
	Causes a message to be printed before and after compiling/running
	an app instead of just after.
dcmake -time app-time.x
	When you want to generate a timing target, use -time, which sets
	the appropriate command-line options.  You can also use with for
	noop and cc versions.
do_make BCC_FLAGS="-k" file
	When you want to compile just one file and pass additional arguments
	to BCC, you can set BCC_FLAGS on the command-line.  For example, -k
	causes the preprocessed file to be left behind instead of deleted.
DyCRT_ReadCycleCounter()
	Returns an unsigned long that is the current value of the
	accumulated cycles since DyCRT_InitializeInstrumentation() was
	called.
DyCRT_PrintCounters()
	Prints the detailed DC measurements.  Will, of course, be zero for
	non-dynamically compiled versions.

Timing code/output should be guarded by #ifdef DYC_RT_TIME and
testing code/output by #ifndef DYC_RT_TIME.  Here is what I did in
dotproduct:

#ifdef DYC_RT_TIME
  DyCRT_InitializeInstrumentation();
  initial_cycle = DyCRT_ReadCycleCounter();
#endif

  result = dotproduct(ndata, x, y);

  for (r = 0; r < nruns; r++)
    {
      tmp = dotproduct(ndata, x, y);
#ifndef DYC_RT_TIME
      if (tmp != result) {
	  fprintf(stderr, "Answer, %d,  doesn't match first result: %d\n",
		  tmp, result);
	  exit(2);
      }
#endif
    }

#ifdef DYC_RT_TIME
  total_cycles = DyCRT_ReadCycleCounter() - initial_cycle;
  printf("Total time: %lu cycles\n", total_cycles);
  DyCRT_PrintCounters(stdout);
  printf("\n");
#else
  printf("Answers match: %d\n", result);
#endif


--Brian

Date: Mon, 27 Oct 1997 06:33:48 -0800
From: eggers@yakima (Susan Eggers)
To: spin-comp@cs.washington.edu, mock@cs.washington.edu
Subject: Re: speedups for chebychev: from 3.8 to 8.0


Looks like the next step here is to see why we aren't getting speedups
close to Tempo.  One avenue is what Brian is pursuing: the overhead
in our stitched code.  What about code quality when compared to Tempo?
Is this small enough to eyeball?

Susan

Date: Mon, 27 Oct 1997 06:37:13 -0800
From: eggers@yakima (Susan Eggers)
To: spin-comp@thistle.cs.washington.edu, grant@cs.washington.edu
Subject: Re: more timing results


I would focus on measuring those categories that will help
you investigate why speedups are low or breakeven high.  Rather than
compiling a detailed list of how long it takes DyC to do any arbitrary task.
Maybe that will amount to the same metrics in the end, but it's a different 
mindset.

Susan

Date: Mon, 27 Oct 1997 07:35:16 -0800 (PST)
From: "Markus U. Mock" <mock@cs.washington.edu>
To: Susan Eggers <eggers@yakima.cs.washington.edu>
cc: spin-comp@cs.washington.edu
Subject: Re: speedups for chebychev: from 3.8 to 8.0

We don't know what Consel's group generates but as talked about with Luke
we could ask them to send us their assebmly code output.

I looked at the chebychev in some detail: apart from a few table pointer
build operations the code looks pretty optimal, we have the  number
of multiplies and adds we'd expect. Maaatthai will take a look what to do
about the few remainung unnecessary ldas and ldqs.




	-- Markus 


On Mon, 27 Oct 1997, Susan Eggers wrote:

   
   Looks like the next step here is to see why we aren't getting speedups
   close to Tempo.  One avenue is what Brian is pursuing: the overhead
   in our stitched code.  What about code quality when compared to Tempo?
   Is this small enough to eyeball?
   
   Susan
   


Date: Mon, 27 Oct 1997 07:46:17 -0800
From: eggers@yakima (Susan Eggers)
To: eggers@yakima.cs.washington.edu, mock@cs.washington.edu
Subject: Re: speedups for chebychev: from 3.8 to 8.0
Cc: spin-comp@cs.washington.edu


What Alpha are we running on?  Could there be an issue wrt instruction
order?
Here's a tack:  We could write out the dynamically generated code,
read it back in and execute it with DCPI and DCPI would tell us where
the time is going, where the stalls are and why.

Susan

Date: Mon, 27 Oct 1997 11:56:49 -0800 (PST)
From: Markus Mock <mock@apex.cs.washington.edu>
To: Brian Grant <grant@cs>, spin-comp-archive@cs
Subject: xv now fails

? FATAL COMPILER ERROR
? Assertion failed.
? (file:line) cg/schedule_vn.C:799

after I updated..


	-- Markus


Date: Mon, 27 Oct 1997 13:35:04 -0800 (PST)
From: chambers@klamath (Craig Chambers)
To: spin-comp@cs.washington.edu, mock@cs.washington.edu
Subject: Re: speedups for chebychev: from 3.8 to 8.0

My questions:

Which kind of time are we measuring?  real time?  cpu time?  user time?
We don't want to pay for touching a page of memory the first time in our
timings.

Are Consel's results for *statically* specialized & compiled programs, or
*dynamically* specialized programs?  If the former, then he should do better,
I think.  And he's running on a Sparc, so architectural differences could
account for things.

I think we should make cache lookups etc. faster.

-- Craig

To: eggers@franklin.cs.washington.edu, chambers@franklin.cs.washington.edu
cc: spin-comp@franklin.cs.washington.edu
Subject: Outline
Date: Mon, 27 Oct 1997 16:49:19 PST
From: Matthai Philipose <matthai@franklin.cs.washington.edu>

BTW, what's the status of the paper outline? :-)
		Matthai

Date: Mon, 27 Oct 1997 17:00:49 -0800 (PST)
From: chambers@klamath (Craig Chambers)
To: eggers@franklin.cs.washington.edu, chambers@franklin.cs.washington.edu,
Subject: Re: Outline
Cc: spin-comp@franklin.cs.washington.edu

The outline was on my to-do list.  I haven't done it.  But I plan to Real Soon
Now.

-- Craig

Date: Mon, 27 Oct 1997 17:11:13 -0800 (PST)
From: Markus Mock <mock@apex.cs.washington.edu>
To: Matthai Philipose <matthai@cs>, spin-comp-archive@cs
Subject: chebychvev

no ldas + better run-time lib get as very close to Consel wrt speedup.
I'll do detailed timings later.

Can't a simple peephole post-merger pass remove the unnecessary ldas even
in the case of cache_all? Looks like that should not be too hard.

	-- Markus


Date: Mon, 27 Oct 1997 18:05:36 -0800 (PST)
From: Markus Mock <mock@apex.cs.washington.edu>
To: Matthai Philipose <matthai@cs>, spin-comp-archive@cs,
cc: Markus Mock <mock@cs.washington.edu>
Subject: BTA checked in.

Let me know if there are problems.


	-- Markus


Date: Tue, 28 Oct 1997 11:17:14 -0800 (PST)
From: Markus Mock <mock@apex.cs.washington.edu>
To: Brian Grant <grant@cs>, spin-comp-archive@cs
Subject: xv 

it works for 

make_static(n2);
make_static(temp_x1:cache_all_unchecked, eager);
make_static(temp_y1:cache_all_unchecked, eager)


but fails for:

make_static(n2);
make_static(temp_x1, temp_y1); 



	-- Markus


Date: Tue, 28 Oct 1997 11:56:23 -0800 (PST)
From: Markus Mock <mock@apex.cs.washington.edu>
To: Brian Grant <grant@cs>, spin-comp-archive@cs
Subject: xv Assertion failed: DestinationAddr, file dycrt.c, line 180



	-- Markus


Date: Tue, 28 Oct 1997 12:24:40 -0800 (PST)
From: Markus Mock <mock@apex.cs.washington.edu>
To: Brian Grant <grant@cs>, spin-comp-archive@cs
Subject: ppmdither

Dies with a segmentation fault in the generated code.
If you want to take a look the code is in:
/afs/cs.washington.edu/project/dyncomp/mock/benchmarks/consel/benchmark-ppmdither


	-- Markus


To: spin-comp@thistle.cs.washington.edu
Subject: Alpha cycle counter
Date: Tue, 28 Oct 1997 14:46:43 PST
From: Brian Grant <grant@thistle.cs.washington.edu>

According to Alec Wolman (I think this is what he said):

	-- The "process cycle counter" register is saved and restored at
	   context switches
	-- The lower 32 bits of the cycle counter is a free-running counter
	   that measures process (user+system?) time, implemented by the
	   architecture
	-- The upper 32 bits of the cycle counter is implemented by the OS.
	   In Digital UNIX, it should be the negation of system time, so that
	   when you add the upper bits to the lower bits you get user time.
	   This is what the architecture manual says to do, but it doesn't
	   say what the upper 32 bits mean, nor does it say exactly what the
	   result gives you.

We have been adding the upper and lower bits so we should be measuring user
time.

However, Alec said they somehow came to this conclusion experimentally, by
looking at the high- and low-order bits separately, reporting both system
and user time, and comparing with other measures (getrusage, I guess).

Perhaps we should ask someone from the DCPI group to confirm this.

--Brian

Date: Tue, 28 Oct 1997 14:51:06 -0800 (PST)
From: Markus Mock <mock@apex.cs.washington.edu>
To: Matthai Philipose <matthai@cs>, spin-comp-archive@cs
cc: Markus Mock <mock@cs>
Subject: negative immediates

Matthai,

what does the following mean:

Merging...
operation       addq    $18,-8,$2         has too negative an immediate: 8
*** Exit 2

Does the merger not yet convert these to subs?


	-- Markus


Date: Tue, 28 Oct 1997 15:00:42 -0800
From: eggers@yakima (Susan Eggers)
To: spin-comp@thistle.cs.washington.edu, grant@cs.washington.edu
Subject: Re: Alpha cycle counter


alias dean jdean@pa.dec.com

He is on a retreat to day, should be back tomorrow.

Susan

To: spin-comp@franklin.cs.washington.edu
Subject: 'C query works...
Date: Tue, 28 Oct 1997 15:10:47 PST
From: Matthai Philipose <matthai@franklin.cs.washington.edu>

Folks,
While Markus was modifying the bta yesterday to handle a case
in mipsi, I went ahead and annotated the mipsi "query" benchmark,
and it ran right without much trouble.

"query" basically checks if each record of a database matches
a runtime-constant query. The query is an array of (field,value,predicate) 
triples. Each triple  specifies  which record field to examine, the value to 
compare against the the field, and the comparison predicate to apply. The 
dynamic region is basically a loop over the triples. so the bigger the number 
of triples and the bigger the number of triples that match (query hit-rate), 
the longer the time spent in the dynamic region.

I haven't done detailed timing, but using the unix time utility on large 
inputs, I got the following info. 

The runtime (i.e. post stitchtime) cache push/pop for unchecked dynamic 
regions bites us here. For the input provided with 'C, we never break even 
because the overhead of the push-pop on each invocation to the dynamic region 
is greater than the time spent iterating over triples, most of the time.

If the inputs are such that the time spent in the dynamic region per 
invocation to the region is large enough:
--with  63 element queries, as opposed to 7, along with  a 100% query hitrate, 
we get a 3.1x asymptotic speedup and breakeven of 50 database elements).
	+with a very small (almost 0%)  hit rate, we are _slower_ by 2.2x !   

--with  21 elements, 100% hit rate, we get 1.3x speedup and breakeven of 250.

--with 5 elements, 100% hit rate, we are 3x slower, asymptotically.

The corresponding numbers for `C (with 5-element queries and unspecified query 
hit-rate) are 2.5x and breakeven approx 220 db elements.

Basically, there are two conclusions:
1)We need to get rid of the extra runtime push/pop overhead for the unchecked 
case (Brian's working on this right now).
2)There are unspecified parameters (such as the query hitrate) in the
  reported experiments which can make a big difference to our bottom line.

I have placed query in the regression test and am moving back to hacking mipsi.
	Matthai



To: spin-comp@franklin.cs.washington.edu
Subject: correction...
Date: Tue, 28 Oct 1997 15:15:29 PST
From: Matthai Philipose <matthai@franklin.cs.washington.edu>

>in mipsi, I went ahead and annotated the mipsi "query" benchmark,
					  ^^^^^
				    read  tick-C "query" bencmark

To: mock@thistle.cs.washington.edu, matthai@thistle.cs.washington.edu
cc: spin-comp-archive@cs
Subject: commit of latest timing stuff
Date: Tue, 28 Oct 1997 16:23:40 PST
From: Brian Grant <grant@thistle.cs.washington.edu>

rt only does coarse measurements (dc overhead + stitched code cycles).  To
get the detailed info, remove the pms file and do "dcmake -inst cheb-time.x".
The interface has changed slightly, so look at dotproduct for an example.

--Brian

Date: Tue, 28 Oct 1997 22:37:22 -0800
From: Charlie Garrett <garrett@etcons.com>
To: grant@cs.washington.edu
Subject: Re: [Fwd: Alpha cycle counter]

I think that the cycle counter gives you user+system time for your
process.  I know that the following things are true:

	1. The high order 32 bits are writable by the operating system.
	2. The low order 32 bits are a free running counter measuring
	   individual cycles.
	3. The operating system sets the high order bits so that 
	   (high2 + low2) - (high1 + low1) = the cycles elapsed in
	   this process between rpcc call 1 and rpcc call 2.  This 
	   subtracts out all of the cycles that are spent in other
	   processes.

The reason that I think it gives you user+system time is that
subtracting system time would require setting the high order 32 bits on
every system call while reporting the sum just requires setting the high
order bits on context switch.  I don't think that they bother to do it
on every system call.

To test this theory, I wrote two programs of the form:

	for (i=0; i<10; i++) {
	    time1 = Rpcc();         // Call function which returns rpcc
	    system_call();
	    time2 = Rpcc();
	    printf("%d\n", time2 - time1);
	}

Where system_call was either getpid() or open(). getpid() is a canonical
fast system call, while open() is much more complex.  They do virtually
the same amount of work at user level (open has to place its arguments
in registers) then they trap to the kernel.  The getpid() version runs
between 700 and 2000 cycles.  The open() version runs between 11,000 and
24,000 cycles.  This shows that the difference in time spent in the
system is reflected in the rpcc figure and is very strong evidence that
rpcc includes user+system time.

Look in ~garrett/tests on porky-pig for these programs if you want to
play with them yourself.

--
Charlie

To: spin-comp@thistle.cs.washington.edu
Subject: Jeff confirms Charlie's understanding of rpcc
Date: Wed, 29 Oct 1997 10:27:09 PST
From: Brian Grant <grant@thistle.cs.washington.edu>

Jeff said that, to his knowledge, the cycle counter works exactly as
Charlie says.

Good job, Charlie!

So, it looks like we will need a different way to measure user time. :-(
Some have suggested DCPI, but I can't imagine us learning how to use it
over the next week, so getrusage is the obvious choice.

--Brian

Date: Wed, 29 Oct 1997 11:19:49 -0800 (PST)
From: Markus Mock <mock@apex.cs.washington.edu>
To: Matthai Philipose <matthai@cs>, spin-comp-archive@cs
cc: Markus Mock <mock@cs>
Subject: Mismatched setup block numbers at line 1150

Matthai,

I get the above error for the testprogram ltest.DyC in 
/afs/cs.washington.edu/project/dyncomp/mock/benchmarks/misc

Can you take a look?


	-- Markus

BTW: Newton ('C) is useless for us: all speedup was obtained by inlining
functions which we can't do. Since the arguments are not static, we can't
do anything about it.

I am looking at binary (the binary tree search) which we should be able to
handle by multi-way loop unrolling, so this would be a test of our
advanced features. Doesn't work yet, which is why I am trying somehing
easier (ltest.DyC)



To: matthai@thistle.cs.washington.edu
cc: spin-comp-archive@cs
Subject: jump patching label formats
Date: Wed, 29 Oct 1997 15:09:52 PST
From: Brian Grant <grant@thistle.cs.washington.edu>

Format of place-holders in setup code:
	stq	<reg>, <function>.DYC.JUMP_PLACEHOLDER.%d
where <reg> holds the address of the location to patch.

Format of destinations in template code (1-1 correspondence between
place-holders and destinations):
<function>.DYC.JUMP_DESTINATION.%d

--Brian

Date: Wed, 29 Oct 1997 18:29:16 -0800 (PST)
From: Markus Mock <mock@apex.cs.washington.edu>
To: Brian Grant <grant@cs>, spin-comp-archive@cs,
Subject: romberg fails for me

Romberg seems to produce different answers now:
8 numbers differ between the two files out of 91 comparisons.
 Sum of the differences: 1.766740e-01
 Largest difference:     7.612800e-02    number count 28
 Numbers                 6.8808000000000e-01          6.1195200000000e-01
 Largest % difference:   5.000000e+01 %  number count 6
 Numbers                 1.4000000000000e-05          7.0000000000000e-06
 Average % difference:   1.640050e+01 %
 Tolerance specified was 1.000000e-05 %


Do you have the same behavior?

	-- Markus


Date: Wed, 29 Oct 1997 18:40:19 -0800 (PST)
From: Markus Mock <mock@apex.cs.washington.edu>
To: Matthai Philipose <matthai@cs.washington.edu>
cc: Brian Grant <grant@cs>, spin-comp-archive@cs, Markus Mock <mock@cs>
Subject: romberg ok

I had some spurious output..

	-- Markus

On Wed, 29 Oct 1997, Matthai Philipose wrote:

> When I last tried it (about an hour ago) all my tests passed.
> 


To: mock@thistle.cs.washington.edu, matthai@thistle.cs.washington.edu
cc: spin-comp-archive@cs
Subject: benchmarks
Date: Thu, 30 Oct 1997 22:38:08 PST
From: Brian Grant <grant@thistle.cs.washington.edu>

csi seg faults on a load in the stitched code.  fft runs but gives the
wrong answer.  So, these two are back to the same state they were two weeks
ago.  I'll move on to ms.  I can't effectively run xv at home, so I won't
do that unless I run out of things to do, in which case I'll write another
driver for it.

I'll try to pick up the latest copies of ppmdither, ms, binary, etc. and
try them out.

--Brian

Date: Thu, 30 Oct 1997 22:44:07 -0800 (PST)
From: "Markus U. Mock" <mock@cs.washington.edu>
To: grant@cs.washington.edu
cc: mock@thistle.cs.washington.edu, matthai@thistle.cs.washington.edu,
Subject: Re: benchmarks

Ok. pow works fine now for me too and xv links again.



	-- Markus 


On Thu, 30 Oct 1997, Brian Grant wrote:

   csi seg faults on a load in the stitched code.  fft runs but gives the
   wrong answer.  So, these two are back to the same state they were two weeks
   ago.  I'll move on to ms.  I can't effectively run xv at home, so I won't
   do that unless I run out of things to do, in which case I'll write another
   driver for it.
   
   I'll try to pick up the latest copies of ppmdither, ms, binary, etc. and
   try them out.
   
   --Brian
   


To: "Markus U. Mock" <mock@cs.washington.edu>, matthai@cs.washington.edu
cc: spin-comp-archive@cs
Subject: Re: xv works! + new problem
Date: Fri, 31 Oct 1997 01:53:24 PST
From: Brian Grant <grant@thistle.cs.washington.edu>

Awesome!

Something pathological is happening with binary, I think.  Nearly 30 units
are created for that little piece of code.  It has another problem, however.
The gp is clobbered by a hole-patching operation that is supposed to
restore the gp following a call to DyCRT_AllocateTableFromFreeList.  The
value loaded from position 0 in the table is not the right one.  Could you
please take a look at this, Matthai?

--Brian

Date: Fri, 31 Oct 1997 09:29:49 -0800 (PST)
From: Markus Mock <mock@apex.cs.washington.edu>
To: Brian Grant <grant@cs>, spin-comp-archive@cs,
Subject: xv :-(

It turns out that I have /uns/bin in my path before . and on meitner there
is a xv in /uns/bin so the one I ran last night when I thought it was
working was actually the one in /uns, arrg ( I forgot to type ./xv)
So:
xv still faults:
inst fault=4, status word=               8, pc=       1400ffddc
Illegal instruction
n

I'll write the driver now so that we can test it more easily.


	-- Markus


Date: Fri, 31 Oct 1997 10:42:15 -0800 (PST)
From: Markus Mock <mock@apex.cs.washington.edu>
To: Brian Grant <grant@cs>, spin-comp-archive@cs,
cc: Markus Mock <mock@cs>
Subject: xvalg added to regression

I've added the main routine from xv with a driver and input data into the
regression suite.

For me it fails 
Assertion failed: 0, file dycrt.c, line 170


	-- Markus


To: mock@thistle.cs.washington.edu
cc: spin-comp@thistle.cs.washington.edu
Subject: infinite loops and cache policies
Date: Fri, 31 Oct 1997 11:29:29 PST
From: Brian Grant <grant@thistle.cs.washington.edu>

xv and ms can't currently be annotated cache_all_unchecked.  This was causing
them to go into infinite loops in their GEs.  The reason is that when there
happens to be a unit boundary at a loop head, the unit for the loop head is
pushed onto the work list at every back edge so that the inter-unit branches
to the loop head can be patched.  If the loop isn't to be unrolled, there
shouldn't be any discordant variables so a cache lookup should succeed if
a copy of the loop body has already been stitched.  That should be fine --
the address should be found in the cache and the branch corresponding to
the back edge can then be patched.  However, if the cache lookup is removed
due to the all_unchecked policy, then the loop will be unrolled indefinitely.
I'll think about how to best deal with this in the redesign of the work-list
loop.

I changed the policies to cache_all in my version and now they merely seg.
fault. :-)

Eager should still be ok, I think.  Another possibility is to make the policy
cache_all_unchecked for the outer loop, then change it around the inner loop(s).
I tried this, but it didn't work (still infinite loop) and I didn't pursue it
further.

--Brian


Date: Fri, 31 Oct 1997 16:01:46 -0800 (PST)
From: chambers@klamath (Craig Chambers)
To: spin-comp@cs
Subject: paper draft

I've created a draft for the PLDI paper, cribbing from Matthai's draft intro
and sections of the PEPM paper.  I added some comments and a short sketch of
the experimental results section.  I'm giving up the write lock on the 
document now.

See ~chambers/papers/pldi/98/DyC/dc.doc, a Frame document.

-- Craig

Date: Fri, 31 Oct 1997 18:56:28 -0800
From: eggers@yakima (Susan Eggers)
To: spin-comp@cs, chambers@klamath
Subject: Re: paper draft


I'll take the write lock through tomorrow afternoon.  But in all
honesty I won't be working on the paper until late morning.

Susan

To: eggers@franklin.cs.washington.edu
cc: spin-comp-archive@franklin.cs.washington.edu
Subject: resend: MIPSI
Date: Sat, 01 Nov 1997 17:39:48 PST
From: Matthai Philipose <matthai@franklin.cs.washington.edu>

Susan,
Sorry I missed you. I was here till 12:30 in the afternoon, and just got back 
from lunch and some errands.

Here're the answers to your questions.
        Matthai

-----------We currently use the following in mimpsi

1. program-point-specific rather than function-level specialization,

2. support for polyvariant specialization. <WE COULD DEFINITELY USES 
POLYVARIANT DIVISION TO CONDITIONALLY SPECIALIZE FUNCTIONS AS OUTLINED IN THE 
PAPER, BUT THIS CAPABILITY IS NOT YET IMPLEMENTED>

3.  nested regions of dynamically generated code <I DON'T QUITE REMEMBER WHAT 
OVERLAPPING REGIONS MEANS>

4. automatic caching, reuse, and reclamation of dynamically generated code, 
with cache policies under control of the programmer,

5. automatic interleaving of specialization and dynamic execution to delay 
specialization of some code until the appropriate   run-time values have been 
computed,

6. run-time optimizations, ons, including constant propagation, constant 
folding, strength reduction, conditional branch folding and dead code 
elimination, loop unrolling and merge splitting; <PROCEDURE SPECIALIZTION IS 
UNIMPLEMENTED, THOUGH IT WOULD HAVE BEEN USEFUL.>

----------We do not use:
1. automatic interleaving of specialization and dynamic execution to avoid 
unbounded static specialization for terminating programs, with the exact 
trade-off between speculative specialization and demand-driven specialization 
under programmer control,

On the other hand, we don use the "programmer control" to turn off this 
feature (by using an "eager" annotation).
-----------



To: mock@thistle.cs.washington.edu
cc: matthai@thistle.cs.washington.edu, grant@thistle.cs.washington.edu,
Subject: Another problem with policy change....
Date: Sun, 02 Nov 1997 15:13:50 PST
From: Brian Grant <grant@thistle.cs.washington.edu>

Markus,

We're still having trouble with temps derived from themselves.  The ones
we're having trouble with are derived from themselves indirectly, however,
and not in a single STAT.  We should be able to deal with that case, too.
One possible way is to check the source temps of the operands rather than
the operands themselves.

In the short term, perhaps we should always make annotated temps keep their
annotated policies, and not become unchecked even if they appear to be derived.
If you do this, please make it controllable via a command-line option.

What do you think the right long- and short-term solutions are?

Here's the example in a block from the post.bta file of run_DyC_simple.
The policy of t513 incorrectly becomes unchecked.

------------------------ 
bblock93 [label=" BBlock 93\lStatic Temps: {(t514,Cache1U,{_nnpc$1.2}),(t513,Ca
cheAll,{_nnpc$1.2}),(t523,Cache1U,{_npc$1.2})}\l 615 <S> GBANDOR.AND<>t418 
[@<_inst$1.2>t523,67108863(I32)] [F,F]\l 620 <S> GBANDOR.AND<>t421 [@<_npc$1.2>
t514,4026531840(I32)] [F,F]\l 619 <S> ADDS.2 @<_nnpc$1.2>t513 @<>t418 @<>
t421\lStatic Temps: {(t514,Cache1U,{_nnpc$1.2}),(t513,Cache1U,{_npc$1.2,_nnpc$1
.2})}\l"];
	bblock93 -> bblock47;
--------------------------

--Brian

To: eggers@yakima (Susan Eggers)
cc: spin-comp-archive@cs
Subject: Re: MIPSI 
Date: Sun, 02 Nov 1997 16:37:34 PST
From: Brian Grant <grant@thistle.cs.washington.edu>

Matthai said that he e-mailed you a response earlier, but this is what I
wrote last night...

--Brian




>> Which of these features does MIPSI use that the other declarative systems
>> do not?

I would guess that it is essentially the same as the dinky interpreter from
the PEPM paper except that it does not use recursion to implement calls.
Matthai should know more precisely what is needed since he's been working on it.

>> program-point-specific rather than function-level specialization,

Yes.  The program is mostly one loop around a switch.  We multi-way unroll the
loop.

>> support for both polyvariant specialization and polyvariant division (both o
f which have practical utility), with the degree of specialization for differen
t variables under programmer control,

Yes.  We don't necessarily want to unroll the intepreter loop for the entire
program (e.g., the exit function).

>> intra- and interprocedural specialization, with caller and callee separately
 compilable,

No, I don't think it needs interprocedural specialization, though we do make
some calls static.

>> arbitrary nested and overlapping regions of dynamically generated code,

Yes.  There are computed jumps.

>> automatic caching, reuse, and reclamation of dynamically generated code, wit
h cache policies under control of the programmer,

Yes for caching.

>> automatic interleaving of specialization and dynamic execution to avoid unbo
unded static specialization for terminating programs, with the exact trade-off 
between speculative specialization and demand-driven specialization under progr
ammer control,

Yes, though I think we annotated all variables to be eager.  (So, the control
is needed but dynamic-branch laziness may not be.)

>> automatic interleaving of specialization and dynamic execution to delay spec
ialization of some code until the appropriate run-time values have been compute
d,

Yes. E.g., computed jumps again.

>> run-time optimizations, including constant propagation, constant folding, st
rength reduction, conditional branch folding and dead code elimination, loop un
rolling and merge splitting, and procedure call specialization.

Yes (except call specialization and strength reduction).



To: Markus Mock <mock@cs.washington.edu>
cc: spin-comp-archive@franklin.cs.washington.edu
Subject: Re: Another problem with policy change.... 
Date: Sun, 02 Nov 1997 18:03:26 PST
From: Matthai Philipose <matthai@franklin.cs.washington.edu>

Markus,
I have a few questions wrt your reply to Brian's email:

> a) a temp that has a corresponding source var gets the derived policy
> (unless it's annotated)
Which derived policy? Specifically, what will be the root variable(s) of the 
temp? I thing Brian's suggestion of having temps with corresponding 
source-vars have their source-var as the corresponding root var is probably 
the simplest correct thing to do.

> b) other temps ("those introduced only by Mflow) get the same policy as
> the temp they are derived from. If derived from different temps, choose
> the strongest policy.
Is this the same as saying that derived temps will have as root vars the union 
of the root vars of the temps they are derived from (and the policy can be 
computed by some operation on these root vars)? If so, I agree that this is 
could be the right thing in the long run (though we will have to switch to 
root-temps instead of root vars because of the multiple-temps-per-var 
simultneously live problem). 

In the short term, for getting mipsi to work, I am perfectly happy with 
derived temps without a corresponding source var getting unchecked policies, 
as long as they are killed from the static temps set immediately when one of 
their root variables is assigned to. I assume this is how things are set up 
currently?

> I think as a first step I'll add a switch to turn off the change to
> cache1Umchecked from cacheAll.
What's this?

		Thanks,
		Matthai 


Date: Mon, 3 Nov 1997 00:31:55 -0800 (PST)
From: "Markus U. Mock" <mock@cs.washington.edu>
To: Brian Grant <grant@thistle.cs.washington.edu>
cc: mock@thistle.cs.washington.edu, matthai@thistle.cs.washington.edu,
Subject: Re: Another problem with policy change....

I committed a fixed BTA. There's now a switch
P2DYC_bta_keep_cache_policy (default true) that makes sure that the
"demotion" to cache_one_unchecked will not happen for annotated temps.
That fixed the problem in mipsi.





	-- Markus 



Date: Mon, 3 Nov 1997 15:59:45 -0800 (PST)
From: Markus Mock <mock@apex.cs.washington.edu>
To: Matthai Philipose <matthai@cs>, spin-comp-archive@cs
Subject: binary

is checked into the regression suite.

I changed it a little so that you can simply run it with 
binary.x n
where n is the number of iterations you want to do 


	-- Markus


To: eggers@yakima (Susan Eggers)
cc: spin-comp-archive@cs
Subject: Re: lines of code 
Date: Mon, 03 Nov 1997 16:03:45 PST
From: Brian Grant <grant@thistle.cs.washington.edu>

>> how many did the 3 of you write for DYC?

Total?

front/back-end perl scripts:	 4500
Multiflow C:			27000
C run-time library:		 1350
build shell scripts:		  700
				-----
				33550

The scripts are a required part of our system but I don't know if it
reasonable to just add up all the lines of code, given that some are in
Multiflow's macroized C, some are perl, and some are bash.  Also, these
line counts include white space and comments (not that there are a lot of
comments :-).

--Brian

To: spin-comp@cs
Subject: committed support for re-initializing DyC
Date: Mon, 03 Nov 1997 23:38:20 PST
From: Brian Grant <grant@franklin.cs.washington.edu>

I've committed new tools and libraries that allow DyC to be reinitialized.
The solution was to create a perl script (gotta love perl) that finds
the locations that need to be initialized and what their initial values
should be.  Manually setting these locations in the C text would not work
because they can be initialized to jump locations which can't be referenced
in C.  In any case, the perl script was trivial to write.  What took longer
was just making sure all our global variables were initialized properly
and getting the tools and libraries set up.

I have modified dotproduct to run two times.  Improvement for
the second execution was significant, and more for the smaller vector sizes.
There didn't seem to be any change for runs beyond the second.

To reset the system, simply call DyCRT_ResetSystem().  An empty version
of this function is linked into the noop versions.

--Brian

To: spin-comp@cs
Subject: one additional note about "warming up" the caches
Date: Mon, 03 Nov 1997 23:45:19 PST
From: Brian Grant <grant@franklin.cs.washington.edu>

All of the benefit must be from priming the data cache because I do an IMB
to flush the i-cache.

--Brian

To: spin-comp@cs
Subject: order of magnitude improvement in DC overhead!
Date: Tue, 04 Nov 1997 01:33:28 PST
From: Brian Grant <grant@franklin.cs.washington.edu>

I'm seeing a disproportionate improvement in dynamic compilation overhead
compared to the whole application when running twice to warm the caches.
For example, dotproduct run 500 times on vectors of length 30 achieves
a factor of 10(!) reduction in DC overhead.  In fact, virtually the entire
improvement in run time is due to reduction in DC overhead.

First run:
Total time: 509251 cycles
Total dynamic-compilation overhead: 80974 cycles
Number of instructions emitted: 100
Cycles / instruction emitted: 809.740000
Time spent in dynamically generated code: 332390 cycles

Third run (slightly better than second run):
Total time: 421333 cycles
Total dynamic-compilation overhead: 8703 cycles
Number of instructions emitted: 100
Cycles / instruction emitted: 87.030000
Time spent in dynamically generated code: 322256 cycles

Static version:
Total time: 412717 cycles

Note that our breakeven is still very high for these small vector lengths.
I'm looking into this.  The version measured here does include hoisting the
cache_one_unchecked dispatch out of the work-list loop.  On the other hand,
does this mean we can quote overheads of less than 100 cycles per instruction
stitched?  That would be cool. :-)

A question about methodology (a proposal, really): 

Should we run ten times, throw out the lowest and highest times, then
average the rest?

Note that I'm still using the cycle counter.  getrusage isn't fine-
grained enough to measure times this short.  I haven't yet compared the
cycle counter to getrusage for longer times, but it is on my list.

--Brian

To: spin-comp@cs
Subject: more on DC overhead
Date: Tue, 04 Nov 1997 01:53:23 PST
From: Brian Grant <grant@franklin.cs.washington.edu>

All of the work-list operations and data-structure construction for 
the specialization context can be eliminated for dotproduct (i.e., we
know how to eliminate that overhead).  This overhead counts for about 40%
of the total DC overhead even after warming the caches.  Eliminating it
entirely would produce a cycles/instr. stitched of about 52.

--Brian

Date: Tue, 4 Nov 1997 11:16:02 -0800 (PST)
From: Markus Mock <mock@apex.cs.washington.edu>
To: Brian Grant <grant@cs>, spin-comp-archive@cs,
cc: Markus Mock <mock@cs>
Subject: chebychev

Running it again, I can confirm that the warm cache improves our overhead
times:


We have about 100 cycles per instruction emitted.
Speedups compared to the noop version range from 
3.2 (n=5) to 
8.8 (n=2)
pretty close to Consel's (5.2 .. 10.4)
(within 18% for n=20)


n = 5
Total time: 24354281 cycles
Total dynamic-compilation overhead: 151394 cycles
Number of instructions emitted: 292
Cycles / instruction emitted: 518.472603
Time spent in dynamically generated code: 120910845857 cycles

Total time: 24228118 cycles
Total dynamic-compilation overhead: 37449 cycles
Number of instructions emitted: 292
Cycles / instruction emitted: 128.250000
Time spent in dynamically generated code: 121039365581 cycles

Total time: 24214696 cycles
Total dynamic-compilation overhead: 41193 cycles
Number of instructions emitted: 292
Cycles / instruction emitted: 141.071918
Time spent in dynamically generated code: 120952685794 cycles

n = 10
Total time: 45513598 cycles
Total dynamic-compilation overhead: 103747 cycles
Number of instructions emitted: 1139
Cycles / instruction emitted: 91.086040
Time spent in dynamically generated code: 227017161524 cycles

Total time: 49192535 cycles
Total dynamic-compilation overhead: 106820 cycles
Number of instructions emitted: 847
Cycles / instruction emitted: 126.115702
Time spent in dynamically generated code: 245587723195 cycles

Total time: 49208384 cycles
Total dynamic-compilation overhead: 99469 cycles
Number of instructions emitted: 847
Cycles / instruction emitted: 117.436836
Time spent in dynamically generated code: 245472574093 cycles

n = 15
Total time: 83651683 cycles
Total dynamic-compilation overhead: 228489 cycles
Number of instructions emitted: 2549
Cycles / instruction emitted: 89.638682
Time spent in dynamically generated code: 416969334474 cycles

Total time: 85566578 cycles
Total dynamic-compilation overhead: 217355 cycles
Number of instructions emitted: 1702
Cycles / instruction emitted: 127.705640
Time spent in dynamically generated code: 426856407771 cycles

Total time: 85561662 cycles
Total dynamic-compilation overhead: 220477 cycles
Number of instructions emitted: 1702
Cycles / instruction emitted: 129.539953
Time spent in dynamically generated code: 426753276331 cycles

n = 20
Total time: 130918100 cycles
Total dynamic-compilation overhead: 384767 cycles
Number of instructions emitted: 4559
Cycles / instruction emitted: 84.397236
Time spent in dynamically generated code: 652796101203 cycles

Total time: 135266316 cycles
Total dynamic-compilation overhead: 355071 cycles
Number of instructions emitted: 2857
Cycles / instruction emitted: 124.281064
Time spent in dynamically generated code: 674665923593 cycles

Total time: 135225296 cycles
Total dynamic-compilation overhead: 346795 cycles
Number of instructions emitted: 2857
Cycles / instruction emitted: 121.384319
Time spent in dynamically generated code: 674322406398 cycles



	-- Markus


To: spin-comp@franklin.cs.washington.edu
Subject: mipsi update
Date: Tue, 04 Nov 1997 13:16:41 PST
From: Matthai Philipose <matthai@franklin.cs.washington.edu>

mipsi now works with all opcodes.

Also, it can simulate the exit functions and everything it calls. In other 
words, it can apparently simulate everything the original mipsi simulator can! 

Of course, we will isolate the time it takes to specialize and execute the 
main routine from
the setup and cleanup time. But it's probably interesting to see how much time 
it spends specializing everything in exit() so that we can claim that with 
polyvariant division and conditional specialization, we can avoid that 
(humongous) overhead... clearly very important for real programs.

I still have to remove all my printfs and other debugging hooks before 
timing... will keep you posted.
	Matthai

Date: Tue, 4 Nov 1997 13:30:19 -0800 (PST)
From: chambers@klamath (Craig Chambers)
To: spin-comp@cs, grant@cs.washington.edu
Subject: Re: committed support for re-initializing DyC

Cool!

-- Craig


Date: Tue, 4 Nov 1997 13:43:05 -0800 (PST)
From: chambers@klamath (Craig Chambers)
To: spin-comp@franklin.cs.washington.edu, matthai@cs.washington.edu
Subject: Re: mipsi update

Cowabunga!

-- Craig

Date: Tue, 4 Nov 1997 14:07:22 -0800
From: eggers@yakima (Susan Eggers)
To: spin-comp@franklin.cs.washington.edu, matthai@cs.washington.edu,
Subject: Re: mipsi update


Wow.
With baited breath I'm waiting to hear what Craig will say when 
we break even with 10 executions.  :-)

Date: Tue, 4 Nov 1997 18:57:06 -0800 (PST)
From: Markus Mock <mock@apex.cs.washington.edu>
To: Brian Grant <grant@cs>, spin-comp-archive@cs
cc: Markus Mock <mock@cs>
Subject: Total dynamic-compilation overhead

Brian,

that number seems to be dependent on the number of iterations that are
executed, i.e. if I run chebychev (or dotproduct) 1000 times in the loop
instead of 100 times it reports vastly different overheads.
I was assuming this is only the constant time overhead.

How can we separate out the constant time overhead? We need to know this
to have meaningful estimates for the breakeven point as well as asymptotic
speedup.


	-- Markus


To: Markus Mock <mock@apex.cs.washington.edu>
cc: spin-comp-archive@cs
Subject: Re: Total dynamic-compilation overhead 
Date: Tue, 04 Nov 1997 21:57:48 PST
From: Brian Grant <grant@thistle.cs.washington.edu>

>> that number seems to be dependent on the number of iterations that are
>> executed, i.e. if I run chebychev (or dotproduct) 1000 times in the loop
>> instead of 100 times it reports vastly different overheads.
>> I was assuming this is only the constant time overhead.

Currently, I include the cache lookups in the overhead.  If you are still
using checked (promote_all/cache_all) policies, then this number won't be
fixed.  You have a good point -- regardless of the policy we should report
the fixed overhead.

Note that with unchecked policies and P2DYC_peel_worklist_loop=true, you
should see fixed overhead.  The version of dotproduct in the archive shows
fixed overhead of about 58k cycles for a vector of length 300.  This is
independent of whether there are 500 iterations or 500000.

>> How can we separate out the constant time overhead? We need to know this
>> to have meaningful estimates for the breakeven point as well as asymptotic
>> speedup.

I'll put in an option to do this.

--Brian

To: matthai@noether.cs.washington.edu, mock@noether.cs.washington.edu
cc: spin-comp-archive@cs
Subject: commit of new timing support
Date: Wed, 05 Nov 1997 04:05:13 PST
From: Brian Grant <grant@noether.cs.washington.edu>

Do a top-level update (-d).  

The new version permits the specification of arguments to dcmake in a file
called rt-args in a regression-test directory.  Several of the apps now
have these files.  For example, the apps for which peel_worklist_loop works
have that argument set.  pow needs special unrolling arguments to work
properly.  I changed the annotations on a couple more apps that were
annotated cache_one_unchecked instead of promote_one_unchecked.  I added
binary even though it is not working, and updated query and romberg to
run multiple times.  I updated pow to take an argument that sets the
power.  I fixed the ndata argument to a couple other tickc apps, too.

The story on binary is that it works for small data sets, but not ones
larger than a few hundred elements.  For the larger arrays, it loads
a static array element from the table instead the address that was
expected and seg. faults.  I don't yet know why this is happening.

The dc overhead reported should now truely be independent of the number
of executions of the stitched code.  If it isn't, let me know.  I noticed
a huge range in overheads.  It is possible that the timing support is
screwed.  I'll look at it further in the morning.  For example, romberg
shows an overhead of less than 40 cycles per instruction stitched, which
query shows more than 100,000!  I expected query to have more overhead due
to multiway unrolling, but that is ridiculous (not that it couldn't be 
accurate).

Markus, the versions of the apps I committed probably will conflict with
yours, assuming you've modified yours locally.  I didn't run into any
assertion failures with the ones committed.  I also noticed that you
added binary roughly simultaneously.  Yours looked like the version I
started with, so I just replaced it with mine.  I totally overhauled
binary's driver for useful testing and timing, at the expense of diverging
from the way the tickc people measured it.

--Brian

To: matthai@noether.cs.washington.edu, mock@noether.cs.washington.edu
cc: spin-comp-archive@cs
Subject: query's overhead
Date: Wed, 05 Nov 1997 04:10:46 PST
From: Brian Grant <grant@noether.cs.washington.edu>

At least one possible reason for query's overhead is that the cache-check
hoisting was turned off.  When I turn it on, I run into the assertion failure
in the back end that Markus encountered earlier.  I'll tackle that in the
morning, too.

--Brian

Date: Wed, 5 Nov 1997 10:12:18 -0800 (PST)
From: Markus Mock <mock@apex.cs.washington.edu>
To: spin-comp@apex.cs.washington.edu
Subject: chebychev breaks even at 2-5 runs!

After sorting out some troubles with the trace scheduler and our cycle
counter timer we have some numbers.

Here are the timings for chebychev with our new timing framework.
This is the experimental setup:

for each n (n = size of the chebychev polynomial)
chebychev is called in a loop 10000 times
this loop is timed using our cycle counter

This timing is repeated 11 times and the first time (cold cache, memory
allocation) is discarded. Of the remaining 10 measured run-times for the
10000 calls to chebychev the median times were used. 

This gave the following cycle measurements:
n	m		dc		overhead inst 	cyc/in 	speedup


5       85093146        24157178        34342   282     121	3.52
asymptotic speedup = 3.527493
breakeven = 5

10      311442680       47873864        90448   837     112	6.50
asymptotic speedup =  6.517799
breakeven = 3

15      713244009       83007494        179962  1692 	106 	8.59
asymptotic speedup = 8.611195
breakeven = 2

20      1264779835      134452724       302340  2847    106	9.40
asymptotic speedup = 9.428075
breakeven = 2


ins = # instructions emitted
cyc/in = cycles per instruction emitted
speedup = speedup for the 10000 calls to chebychev

The asymptotic speedup and breakeven point were computed as follows:

asymptotic speedup = m / (dc - overhead)
breakeven = (10000 * overhead) / (m - dc + overhead)

I verified the computed breakeven points by running with chebychev called
in the loop just 2/5 times and the resulting running times of the mflow
and DyC version were about comparable (4% difference for the 5 runs, 23%
for the 2 runs). 

	-- Markus



Date: Wed, 5 Nov 1997 10:32:26 -0800 (PST)
From: chambers@klamath (Craig Chambers)
To: spin-comp@apex.cs.washington.edu, mock@apex.cs.washington.edu
Subject: Re: chebychev breaks even at 2-5 runs!

Yippie-kai-ay!

-- Craig

To: spin-comp@franklin.cs.washington.edu
Subject: acknowledgement
Date: Wed, 05 Nov 1997 10:32:02 PST
From: Matthai Philipose <matthai@franklin.cs.washington.edu>

Folks, 
Just a reminder (in case I forget!) to acknowledge Gun for his help in 
providing and debugging at very short notice a verion of mipsi for the alpha.
		Matthai

Date: Wed, 5 Nov 1997 10:36:10 -0800 (PST)
From: chambers@klamath (Craig Chambers)
To: spin-comp@franklin.cs.washington.edu, matthai@cs.washington.edu
Subject: Re: acknowledgement

Got it.

-- Craig

> From matthai@franklin.cs.washington.edu  Wed Nov  5 10:32:14 1997
> Delivery-Date: Wed, 05 Nov 1997 10:32:15 PST
> X-Mailer: exmh version 1.5.3 12/28/94
> To: spin-comp@franklin.cs.washington.edu
> Subject: acknowledgement
> Reply-to: Matthai Philipose <matthai@cs.washington.edu>
> Mime-Version: 1.0
> Date: Wed, 05 Nov 1997 10:32:02 PST
> From: Matthai Philipose <matthai@franklin.cs.washington.edu>
> 
> Folks, 
> Just a reminder (in case I forget!) to acknowledge Gun for his help in 
> providing and debugging at very short notice a verion of mipsi for the alpha.
> 		Matthai
> 

Date: Wed, 5 Nov 1997 13:22:43 -0800 (PST)
From: Markus Mock <mock@apex.cs.washington.edu>
To: spin-comp@apex.cs.washington.edu
Subject: good speedups and breakevens for romberg: better than Consel

With the same methodology we get the following measurements for romberg:

M	mflow		dyc		overhead ins. 	cyc/ins	speedup

2	8731414		6131876		12243	 173	70	 1.42
	asymptotic speedup =  1.426787
	breakeven = 46


4	29192469	19511866	28763	 480	59	 1.49
	asymptotic speedup = 1.498348
	breakeven = 29

6	90851530	58784117	73733	 1376	53	 1.54
	asymptotic speedup = 1.547452
	breakeven = 22

8	306517392	209990892	213221	 4472	47	1.45
	asymptotic speedup = 1.461154
	breakeven = 22

compared to Consel's results:

	Tempo			Dyc
M	speedup	breakeven	speedup	breakeven
				(rounded)

2	1.17	61		1.43	46
4	1.25	48		1.50	29
6	1.28	38		1.55	22
8	1.19	45		1.46	22


	-- Markus



To: spin-comp@franklin.cs.washington.edu
Subject: preliminary numbers for  mipsi
Date: Wed, 05 Nov 1997 15:33:15 PST
From: Matthai Philipose <matthai@franklin.cs.washington.edu>

I finally got mipsi to compile and run after removing all printfs.

I made it simulate a lprogram that just increments a counter a varying number 
of times and returns it. I just used unix "time" to figure out the total time 
with mipsi and with smipsi ("special" mipsi, the dynamically compiled version).

The time below _includes_ the time for smipsi to specialize the exit() 
function), and the exit function is _much_ bigger than the loop we're 
simulating. So our real numbers should be considerably better.

Just thought I'd spread a little good cheer...
			Matthai



Incrementing 1 million times: (1.6x speedup)
------------
franklin.cs.washington.edu% time mipsi test/loop_sum.x
Program exited with status 255.
11.480u 0.130s 0:12.33 94.1% 0+4k 1+1io 0pf+0w

franklin.cs.washington.edu% time smipsi test/loop_sum.x
Program exited with status 255.
7.235u 0.101s 0:07.40 99.0% 0+5k 0+0io 0pf+0w
---------------

For incrementing 32,000 times: (1.5x speedup)
------------------------------------------
franklin.cs.washington.edu% time mipsi test/loop_sum.x
Program exited with status 255.
0.289u 0.032s 0:00.42 73.8% 0+3k 2+2io 0pf+0w

franklin.cs.washington.edu% time smipsi test/loop_sum.x
Program exited with status 255.
0.201u 0.037s 0:00.29 79.3% 0+5k 0+0io 0pf+0w
-------------------------------------

Date: Wed, 5 Nov 1997 19:56:56 -0800 (PST)
From: Markus Mock <mock@apex.cs.washington.edu>
To: spin-comp@apex.cs.washington.edu
Subject: speedups for dotproduct

This benchmark was run in 3 configurations:

1) with 90% of the static vector filled with zeros (Consel)
2) with 67% of the static vector filled with zeros ('C)
3) with 50% of the static vector filled with zeros (a more sensible
configuration where one still might prefer a array representation to a
linked list sparse representation for the vector)


We're getting comparable speedup compared to Consel and are better than 'C
(at least if we compare to their speedups in comparison to gcc. Their
speedups compared to lcc are of course bigger since lcc is such a bad
baseline). The 'C paper has no numbers but from the bar graph they got
less than ~1.7 speedup for the gcc comparison.

So here are the (asymptotic) speedups and breakevens in a nutshell:

CONFIGURATION 1: (90% 0's)

	Consel			DyC
n	speedup	breakeven	speedup breakeven	

10	3.37	7		2.71	54	
100	5.26	5		4.35	38	
200	5.61	5		4.42	36


CONFIGURATION 2: (67% 0's)

n	tcc		DyC
10			1.81	52
32	~1.7	~100	2.16	38
100			2.21	35
200			2.16	34
	
The 1.7 and 100 are estimated from the bar graph in the 'C paper.

None of the 'C papers reports the vector size they used (at least I did
not find it there). But the source code they sent us uses a vector size of
32 in their test suite, so I tested with that vector size to get some
numbers we can compare. 


CONGIGURATION 3: (50%
0's)

n	DyC

10	1.77 47
100	1.91 33
200	1.83 34

Even in this configuration we get good speedups and acceptable breakeven
points.



	
	-- Markus




To: matthai@thistle.cs.washington.edu, mock@thistle.cs.washington.edu
cc: spin-comp-archive@cs
Subject: pow works with hand hacking
Date: Wed, 05 Nov 1997 23:23:17 PST
From: Brian Grant <grant@thistle.cs.washington.edu>

A load for a floating-point constant (1.0) is dropped and not in the .pms
file.  I copied both the constant declaration and the load from the .noop.s
file and pow worked.  For now, you'll just have do this manual editting of
the .pms file.

Where the other float constants are initialized, put the following line:
L$4C9:	.quad	0x3ff0000000000000

Just after the adjustment of the stack pointer in mpow insert the following
instruction:
	ldt	$f30,L$4C9	 #class source	 # line 20, <_result$1.2>t18, 1.0000000000000000e+000=0x3ff0000000000000(F64)

We do get some speedup, at least.  I tried exp=500.  For reasonably sized
exponents, we may not do as well.

--Brian

Date: Thu, 6 Nov 1997 00:02:30 -0800 (PST)
From: "Markus U. Mock" <mock@cs.washington.edu>
To: spin-comp@cs.washington.edu
Subject: query speeds up too!

Here are the speedups for query:
I ran with different input sizes, 2000 was the one used by 'C.

n	speedup	breakeven
100	1.93	3
1000	1.67	1
2000	1.66	1

I don't have the 'C times at hand at the moment.



	-- Markus 





To: spin-comp@franklin.cs.washington.edu
Subject: Another data point for mipsi
Date: Thu, 06 Nov 1997 10:11:57 PST
From: Matthai Philipose <matthai@franklin.cs.washington.edu>

To ensure that we have a more interesting app than increment a counter to 
simulate on mipsi, I wrote a simple O(n^2) sort routine that sorts and prints 
an array (generated 
by a parameterized perl script as you recommended). (Yes, we can simulate 
printf(), and we gain from it, since it's called on every element of the 
array!)

Simulating it on mipsi  gives breakeven at 150 elts in the array, 1.6x speedup 
at 500, 1.8x (1000),  1.84x (2000). So, things are still OK, speedup-wise, on 
a "reasonable" 
example. Far as robustness, we're able to simulate printf, and gain from it, 
since it is called many times when the sorted array is printed out. The 
instructions/ instructions stitched doesn't seem to be all that great, given  
that the inner looop code has to be invoked ~ 150^2/2 == 11,250 times before  
we get breakeven... however, this may all seem more reasonable if we do away  
with the exit specializing overhead.

I am putting in wires to get the instructions per instruction stitched number.
			Matthai

FYI, the previous program I simulated was a loop that incremented a counter N 
times: 
The asymptotic speedup on this is 1.8x.
The breakeven point was for N=6144.
For N= 8,000 we get 1.25x speedup.
For N= 16,000 we get 1.6x speedup
For N= 25,000 we get 1.7x speedup
For N= 32,000 we get 1.8x speedup, which is asymptotic.




Date: Thu, 6 Nov 1997 10:54:25 -0800 (PST)
From: chambers@klamath (Craig Chambers)
To: matthai@cs.washington.edu
Subject: Re: Another data point for mipsi
Cc: spin-comp@cs

Are there any regular MIPS compiled programs lying around?  E.g., we could
configure gcc to produce MIPS output, and compile some reasonable test program
to MIPS code, and then simulate it, w/o a MIPS machine lying around.  (If we
had a MIPS machine lying around, we could test how slow simulation is relative
to hardware execution.  For my own curiosity, I guess.)

-- Craig

Date: Thu, 6 Nov 1997 11:05:33 -0800 (PST)
From: Markus Mock <mock@apex.cs.washington.edu>
To: spin-comp@apex.cs.washington.edu
Subject: tcc test configuration  & times

I just got back an answer from Max Poletto confirming the sizes I had used
for timing, all are from their regression suite script.

Also I noticed that the tcc numbers I had previously quoted were from the
paper we used in 590K which was not the final version of their PLDI paper.
Their final numbers are better:
Their vcode-gcc speedup for dotproduct is ~3 and we are at 2.16,
For query we do worse: we are at 1.6 they are again at ~3.



	-- Markus


%benchmarks = (
	       binary =>  {
		   exec	=>	"binary",
		   comp	=>	400,
		   runs	=>	600000,
		   data	=>	0,
	       },
	       ilp => {
		   exec	=>	"cmp2",
		   comp	=>	2000,
		   runs	=>	400,
		   data	=>	4096,
	       },
	       dp => {
		   exec	=>	"dp",
		   comp	=>	2000,
		   runs	=>	80000,
		   data	=>	32,
	       },
	       heap => {
		   exec	=>	"heap",
		   comp	=>	4000,
		   runs	=>	100,
		   data	=>	500,
	       },
	       hash => {
		   exec	=>	"hsh",
		   comp	=>	2000,
		   runs	=>	500000,
		   data	=>	0,
	       },
	       ms => {
		   exec	=>	"ms",
		   comp	=>	2000,
		   runs	=>	300,
		   data	=>	100,
	       },
	       ntn => {
		   exec	=>	"ntn",
		   comp	=>	1500,
		   runs	=>	6000,
		   data	=>	0,
	       },
	       pow => {
		   exec	=>	"pow",
		   comp	=>	4000,
		   runs	=>	500000,
		   data	=>	13,
	       },
	       query => {
		   exec	=>	"query",
		   comp	=>	1000,
		   runs	=>	1000,
		   data	=>	2000,
	       },
	       mshl => {
		   exec	=>	"mshl2",
		   comp	=>	3000,
		   runs	=>	500000,
		   data	=>	1,
	       },
	       unmshl => {
		   exec	=>	"mshl2",
		   comp	=>	3000,
		   runs	=>	500000,
		   data	=>	0,
	       },
	  );





To: chambers@klamath (Craig Chambers)
cc: spin-comp@franklin.cs.washington.edu
Subject: Re: Another data point for mipsi 
Date: Thu, 06 Nov 1997 11:07:58 PST
From: Matthai Philipose <matthai@franklin.cs.washington.edu>

We do have a mips machine (coho@cs), and it has native C-to-mipsi compilers.
We have a couple of "regular" mips programs, the unix shell prorams ls and 
sort.
The numbers for native hardware vs. mipsi interpreted code for sort are below.

However, neither of these seem to work on the dynamically compiled simulator, 
and I'm not sure why. If we are concerned about having more realistic programs 
to simulate, I shold poke around right now to find one that works on our 
system. Should I?
			Matthai

Here're the native vs. simulated numbers:

------Native execution:
coho.cs.washington.edu% time sort < run.c
0.074u 0.195s 0:00.64 40.6% 15+36k 0+4io 0pf+0w

-----Simulation
coho.cs.washington.edu% time mipsi sort < run.c
2.046u 0.120s 0:04.47 48.3% 0+10k 0+7io 0pf+0w
-----------

I ran each test a few times, and the numbers varied a bit, but the above two 
are representative.
        Matthai

To: spin-comp@franklin.cs.washington.edu
Subject: topic for a paper (sub)-section
Date: Thu, 06 Nov 1997 11:49:18 PST
From: Matthai Philipose <matthai@franklin.cs.washington.edu>

We should probably discuss any interesting annotations (e.g. eager, 
cache_one_unchecked, cache_all_unchecked), the @ dereference operator, etc, 
that we use on each benchmark.
		Matthai

To: eggers@yakima (Susan Eggers)
cc: spin-comp@cs
Subject: Re: ticC 
Date: Thu, 06 Nov 1997 12:01:23 PST
From: Brian Grant <grant@thistle.cs.washington.edu>

>> should we be comparing ourselves to vcode or icode results,
>> and why?

On one hand, vcode is more comparable to what we do in that it does no
run-time register allocation.  Icode builds an IR and at least does some
"register assignment".  I don't know if they do anything else.  On the
other hand, we do some register allocation statically while I think vcode
does not.  Another thing to consider is whether our DC overheads more
comparable to the vcode or icode overheads.

I lean towards vcode because it better matches what we do at run time.
It will also make our speedups look better. :-)

What do you think, Markus?

--Brian

Date: Thu, 6 Nov 1997 12:07:05 -0800 (PST)
From: chambers@klamath (Craig Chambers)
To: spin-comp@apex.cs.washington.edu, mock@apex.cs.washington.edu
Subject: Re: tcc test configuration  & times

> Also I noticed that the tcc numbers I had previously quoted were from the
> paper we used in 590K which was not the final version of their PLDI paper.
> Their final numbers are better:
> Their vcode-gcc speedup for dotproduct is ~3 and we are at 2.16,
> For query we do worse: we are at 1.6 they are again at ~3.

These are speedups relative to lcc base?  Using vcode or icode gen?

-- Craig

Date: Thu, 6 Nov 1997 12:09:13 -0800 (PST)
From: Markus Mock <mock@apex.cs.washington.edu>
To: Brian Grant <grant@thistle.cs.washington.edu>
cc: Susan Eggers <eggers@yakima>, spin-comp@cs
Subject: Re: ticC 

I think vcode is the right thing to compare against.

icode does register allocation and computes live ranges at run time
allowing it to produce better code at the expense of a much higher
overhead. They report 1000 - 2500 cycles / instruction generated for icode
vs. 100 - 500 for vcode.


	-- Markus

On Thu, 6 Nov 1997, Brian Grant wrote:

> >> should we be comparing ourselves to vcode or icode results,
> >> and why?
> 
> On one hand, vcode is more comparable to what we do in that it does no
> run-time register allocation.  Icode builds an IR and at least does some
> "register assignment".  I don't know if they do anything else.  On the
> other hand, we do some register allocation statically while I think vcode
> does not.  Another thing to consider is whether our DC overheads more
> comparable to the vcode or icode overheads.
> 
> I lean towards vcode because it better matches what we do at run time.
> It will also make our speedups look better. :-)
> 
> What do you think, Markus?
> 
> --Brian
> 
> 


Date: Thu, 6 Nov 1997 12:10:35 -0800 (PST)
From: Markus Mock <mock@apex.cs.washington.edu>
To: Craig Chambers <chambers@klamath>
cc: spin-comp@apex.cs.washington.edu
Subject: Re: tcc test configuration  & times

> > Also I noticed that the tcc numbers I had previously quoted were from the
> > paper we used in 590K which was not the final version of their PLDI paper.
> > Their final numbers are better:
> > Their vcode-gcc speedup for dotproduct is ~3 and we are at 2.16,
> > For query we do worse: we are at 1.6 they are again at ~3.
> 
> These are speedups relative to lcc base?  Using vcode or icode gen?
> 

These are relative to gcc using vode.

	-- Markus



To: spin-comp@thistle.cs.washington.edu
Subject: Re: Another data point for mipsi 
Date: Thu, 06 Nov 1997 12:49:25 PST
From: Brian Grant <grant@thistle.cs.washington.edu>

>> And we are currently slower than ticC by an uncomfortble amount.

On dotproduct, I don't see how we could do better.  Short of alignment, which
I haven't looked at, we seem to be generating the optimal code.

On query, we have at least two problems.  One is a bug that causes us to generate
branches to the next instruction about every 6 instructions or so.  Another
is that it is comparison- and branch-intensive and we don't do a peephole
optimization that looks important for the Alpha and this small kernel.  The Alpha
has only comparisons in one direction and only one of the two operands may be an
immediate.  Therefore, if our rtconst is the other operand, we would like to
switch the comparison and the branch so we could put it in the immediate field
of the comparison.  More than half of the comparisons could benefit from this
optimization.  I bet if we fixed these two problems, we could reduce the number
of instructions generated by 20-25%.  Does that sound about right, Markus, or
am I overstating the benefit?  This is all from memory....  Unfortunately, these
improvements aren't going to happen by tomorrow. :-(

My point is that we may be able to cite Alpha-specific reasons as at least part
of the reason why we are slower.  Something we should do is compile all of the
benchmarks with gcc to see how different our baseline is from theirs.

--Brian


Date: Thu, 6 Nov 1997 12:50:14 -0800 (PST)
From: Markus Mock <mock@apex.cs.washington.edu>
To: spin-comp@apex.cs.washington.edu
Subject: speedups for pow and binary

For pow we get the following asymptotic speedups:

n	speedup	breakeven	tcc (vcode vs gcc)
13	1.14	398		~2	~100
125	1.09	393
253	1.09	417	
509	1.08	444


For binary, which requires multi-way loop unrolling we get the following
numbers:

	speedup	breakeven	tcc (vcode-gcc)
n
16	1.32	2916		~1.6	~2500
500	1.56	31086

	-- Markus




Date: Thu, 6 Nov 1997 13:04:57 -0800 (PST)
From: Markus Mock <mock@apex.cs.washington.edu>
To: Brian Grant <grant@thistle.cs.washington.edu>
cc: spin-comp@thistle.cs.washington.edu
Subject: Re: Another data point for mipsi 

Brian is about right:

of the 85 instructions we generate we could do without 14 (2 for each of
the 7 iterations of the unrolled loop) simply by omitting the branch and
the following nop. Putting the comparison and branch in one save 1 more
per iteration for a total of 21 / 85 ~= 25% reduction.



> On query, we have at least two problems.  One is a bug that causes us to generate
> branches to the next instruction about every 6 instructions or so.  Another
> is that it is comparison- and branch-intensive and we don't do a peephole
> optimization that looks important for the Alpha and this small kernel.  The Alpha
> has only comparisons in one direction and only one of the two operands may be an
> immediate.  Therefore, if our rtconst is the other operand, we would like to
> switch the comparison and the branch so we could put it in the immediate field
> of the comparison.  More than half of the comparisons could benefit from this
> optimization.  I bet if we fixed these two problems, we could reduce the number
> of instructions generated by 20-25%.  Does that sound about right, Markus, or
> am I overstating the benefit?  This is all from memory....  Unfortunately, these
> improvements aren't going to happen by tomorrow. :-(
> 
> My point is that we may be able to cite Alpha-specific reasons as at least part
> of the reason why we are slower.  Something we should do is compile all of the
> benchmarks with gcc to see how different our baseline is from theirs.
> 
> --Brian
> 
> 


Date: Thu, 6 Nov 1997 13:20:51 -0800 (PST)
From: Markus Mock <mock@apex.cs.washington.edu>
To: Matthai Philipose <matthai@cs>, spin-comp-archive@cs
Subject: pow-code

0x1400168c0 <DyCRT_CodeSpace+48>:	
    	215d8450	lda	s1, -31664(gp)
0x1400168c4 <DyCRT_CodeSpace+52>:		47ff041f	nop
0x1400168c8 <DyCRT_CodeSpace+56>:	
    	a54a0000	ldq	s1, 0(s1)
0x1400168cc <DyCRT_CodeSpace+60>:	
    	5e10041d	fmov	f16, f29
0x1400168d0 <DyCRT_CodeSpace+64>:	
    	5bdd145e	mult	f30, f29, f30
0x1400168d4 <DyCRT_CodeSpace+68>:	
    	5bbd145c	mult	f29, f29, f28
0x1400168d8 <DyCRT_CodeSpace+72>:	
    	5f9c041d	fmov	f28, f29
0x1400168dc <DyCRT_CodeSpace+76>:	
    	5bbd145c	mult	f29, f29, f28
0x1400168e0 <DyCRT_CodeSpace+80>:	
    	c3e00000	br	 0x1400168e4 <DyCRT_CodeSpace+84>
0x1400168e4 <DyCRT_CodeSpace+84>:	
    	5f9c041d	fmov	f28, f29
0x1400168e8 <DyCRT_CodeSpace+88>:	
    	5bdd145e	mult	f30, f29, f30
0x1400168ec <DyCRT_CodeSpace+92>:	
    	5bbd145c	mult	f29, f29, f28
0x1400168f0 <DyCRT_CodeSpace+96>:	
    	5f9c041d	fmov	f28, f29
0x1400168f4 <DyCRT_CodeSpace+100>:	
    	5bdd145e	mult	f30, f29, f30
0x1400168f8 <DyCRT_CodeSpace+104>:	
    	5bbd145c	mult	f29, f29, f28
0x1400168fc <DyCRT_CodeSpace+108>:	
    	5f9c041d	fmov	f28, f29
0x140016900 <DyCRT_CodeSpace+112>:	
    	b41e0000	stq	v0, 0(sp)
0x140016904 <DyCRT_CodeSpace+116>:		5fde0400	fmov	f30, f0
0x140016908 <DyCRT_CodeSpace+120>:	
    	23de00c0	lda	sp, 192(sp)
0x14001690c <DyCRT_CodeSpace+124>:	
    	6be08001	ret	zero, (v0), 1





Date: Thu, 6 Nov 1997 13:58:44 -0800 (PST)
From: chambers@klamath (Craig Chambers)
To: spin-comp@cs
Subject: paper lock

I'm grabbing the write lock on the 1st 3 sections of the paper.  I'm reading
them now, then I'll be doing some revising for focus, technical accuracy
(if I find any problems), and finishing section 2 on our back-end stuff.

-- Craig

Date: Thu, 6 Nov 1997 14:03:40 -0800
From: eggers@yakima (Susan Eggers)
To: spin-comp@cs, chambers@klamath
Subject: Re: paper lock


I have the write lock on the results section

To: spin-comp@cs
Subject: the paper slant, comparison with Tempo and TickC
Date: Thu, 06 Nov 1997 15:13:26 PST
From: Brian Grant <grant@thistle.cs.washington.edu>

I liked Craig's restatement of the slant.  After thinking about it, it wasn't that I
wanted to hype mipsi so much as I felt that we needed to talk more about our system on
its own merits.  If I remember correctly, points we want to make are:

	-- More complex programs need certain features
	-- DyC provides those features
	-- Some of these features are unique to DyC
	-- Others would be difficult to achieve
	-- The features are easy to apply using our concise, expressive annotations
	-- Other systems don't have these features and/or are the desired transformations
	   are difficult to express

Mipsi as an example:
	-- Mipsi requires most of DyC's functionality, and could benefit from the
	   unimplemented features in DyC's design as well.  I think the only features
	   that wouldn't be useful are laziness to avoid unbounded specialization
	   (because the value of the pc is bounded(?)) and strength reduction.  Maybe
	   procedure specialization isn't really needed, either.


The rest of this is trying to clarify our differences with Tempo and TickC and to figure
out what our contributions are.

What are our features?
	-- In common with Tempo and/or TickC
		-- Polyvariant specialization
		-- Polyvariant division (Tempo only)
		-- Standard value-specific optimizations: constant propagation and
		   folding, constant-branch folding, dead-code elimination, loop
		   unrolling
	-- Unique to DyC (among general-purpose DC systems)
		-- Controlled by policies at arbitrary program points
		-- Intraprocedural polyvariant specialization
			-- Multi-way loop unrolling
			-- Merge splitting
		-- Intraprocedural polyvariant division
			-- Conditional specialization
		-- Lazy specialization at arbitrary program points
			-- To avoid unbounded specialization
			-- To delay until needed values have been computed
			   ==> Can continue to specialize after a value is computed by
			       dynamically generated code
		-- Automatic code caching
			-- Automatic dispatching to the correct version for lazy points

What would be easy for Tempo to add?  Tempo could easily add intraprocedural polyvariant
specialization and division.  With somewhat greater difficulty, they could implement
automatic dynamic-to-static promotion.  Why haven't they done these things?  In the
case of polyvariant specialization and division, Charles told me they were concerned
about code explosion and unbounded specialization.  Why should they be while we're not?
Our policies address the code-explosion issue.  They would have to redesign their BTA
from scratch to use policies, which would not be feasible for them.

I could be overly optimistic about how easy it would be to add polyvariant specialization
to their system.  The change to the BTA should be straightforward, but they may need
to implement run-time support or optimize different parts of their existing specializer.
Automatic caching and branch laziness address unbounded specialization.  I don't think
they have either of these capabilities.

The lack of policies to guide the BTA is also one reason why they don't to automatic
dynamic-to-static promotion.  That is, they don't always want to promote static
variables when they become dynamic (i.e., once some variables becomes static,
they don't necessarily want to keep it that way at any cost).  Another is that they
don't have automatic caching and dispatching to the correct version.  This simply means
their system can't automatically insert these lazy caching points.  Automatic caching
would be non-trivial for them to add, but I they could be working on that since Charles
said he liked that aspect of our system and it shows up in their specialization classes
work.

What about TickC?  At the lowest level, TickC can't have nested tick expressions and
tick expressions cannot manipulate cspecs or make calls to compile (since it takes a
tick expression as an argument).  This means they can't dynamically generate code that
_directly_ generates code.  As I previously said, they could call a function that
generates the code and returns a function pointer, however.  This means that linkage
between pieces of code generated at different times is always through function pointers.
This means, for example, they can't practically unroll a loop lazily.

A major overhaul of their system would probably be required to add true laziness.
In our system, dispatches to lazily generated code is currently via jmps rather than
branches, but at lazy points where cache lookups are not required we intend to
overwrite these jmps with branches.

Another weakness of TickC's current design is that they lack an inter-tick-expression
labelling and resolution scheme.  This is what prevents them from generating code with
arbitrary CFGs and, in particular, code with breaks from unrolled loops or other forward
jumps that span tick expressions.  This problem could be solved relatively easily.

TickC lacks a caching library also.

Given these weaknesses, I don't see how TickC could be used to unroll an interpreter
loop when the interpreter included a dynamic jump to interpreted code that could already
have been dynamically compiled.  It seems TickC would either have to:
	-- Generate each loop iteration as a separate dynamically compiled function
	   that called the next iteration in continuation-like way.  Manually cache
	   each of these functions using the values with which they were generated as
	   the cache keys.
   OR
	-- Unroll the loop up to these dynamic indirect jumps, emitting a call to a
	   function that unrolls again when the address becomes known.  There would be 
	   no way to share code between the separately unrolled copies of the loop, so
	   in interpreted programs with loops around computed jumps, the _iterpreted_
	   loops would also be unrolled, basically eliminating any hope of speedup for
	   a single execution of the interpreted program.

Neither of these two schemes would be very successful, so probably we should just say
they can't deal with this case effectively.


In light of these things, what is cool/new/unique about our system?
	-- Highly automatic, but guided by policies that are crucial given the range
	   of powerful but potentially expensive features DyC supports
	-- Arbitrary laziness
	-- Automatic caching + dispatching
	-- Intraprocedural/program-point-specific

I hope this is helpful and that I didn't ramble too much.

--Brian


To: eggers@thistle.cs.washington.edu
cc: spin-comp-archive@cs
Subject: features table
Date: Thu, 06 Nov 1997 15:38:52 PST
From: Brian Grant <grant@thistle.cs.washington.edu>

Remove the dither row from the table.
Remove the "lazy dynamic compilation" column from the table.  We don't use
branch laziness for any of these benchmarks.
Remove the "polyvariant specialization" column from the table.  It is redundant
with loop unrolling and multiway loop unrolling.

What does the "cache policies" column mean?  Does this mean we using caching,
or that we don't because we use a non-default policy?  Maybe drop this column.

All programs have dynamic-to-static promotions at entries to dynamic regions, but
only mipsi has ones inside the region that were automatically inserted, rather
than inserted at annotations.

mipsi uses constant branch removal, multiway loop unrolling, caching, and
nested dynamic-to-static promotions.  It also uses @s.

I'm checking on the others...

--Brian

To: spin-comp@franklin.cs.washington.edu
Subject: Speedups vs. tickc
Date: Thu, 06 Nov 1997 15:43:26 PST
From: Matthai Philipose <matthai@franklin.cs.washington.edu>

Since in cases like dotproduct (where our code is "optimal"), we still don't 
get the speedups that the tick-C folk do, maybe we can just compile our 
distrbution of tick-C, run their sample tick-C program (e.g. dotproduct) and 
compare it against the same program optimizedby multiflow and see what speedup 
they get. If the speedup is closer to ours, our argument that "intangibles" 
like machine architecture may be stronger.

If the speedup is bigger than they report, we forget we ever did this.
			Matthai

To: eggers@thistle.cs.washington.edu
cc: spin-comp-archive@cs
Subject: default policies
Date: Thu, 06 Nov 1997 15:57:58 PST
From: Brian Grant <grant@thistle.cs.washington.edu>

The defaults are all safe.  The unsafe policies can provide better performance.
There are some analyses we currently don't do that could automatically determine
when the potentially unsafe policies would actually be safe.

Here are the defaults, and which ones we used and why.

Caching: promote_all, cache_all
	The defaults say to cache all versions emitted and always perform lookups
	for maximal code sharing.  That is inefficient and unnecessary for most
	of the benchmarks.  An invalidation-based caching scheme would be
	preferable, but what we do is use promote_one_unchecked at region entries
	to ensure only one version is stitched and then reused, and
	cache_all_unchecked to remove all lookups when unrolling loops.  We can
	do that because we know there won't be sharing anyway and that the
	unrolling is bounded by a static exit condition.  Only mipsi uses caching
	to permit code sharing in its unrolled interpreter loop.  This is
	necessary to emit loops corresponding to loops in the interpreted programs.

Laziness: loop_specialize_lazy
	This doesn't matter for most benchmarks, which don't have any dynamic
	branches.  Binary, query, and mipsi all use the eager policy for their
	multiway unrolling.  This is safe for binary and query because their
	loops have static exit conditions and they don't execute static
	instructions that cause exceptions on the multiple paths they eagerly
	execute.  This is safe for mipsi because of its cache check and the
	boundedness of the loop induction variable (the pc).

Promotion: auto_promote
	All benchmarks use the default, but it doesn't matter except for mipsi,
	which has one instance of automatic dynamic-to-static promotion.

Specialization: poly_specialize
	All benchmarks use the default to do loop unrolling, single-way or
	multi-way.

Division: poly_divide
	All benchmarks use the default because it doesn't matter.

--Brian

To: spin-comp@thistle.cs.washington.edu
Subject: dynamic-compilation overhead
Date: Thu, 06 Nov 1997 16:08:26 PST
From: Brian Grant <grant@thistle.cs.washington.edu>

Just to clarify where a lot of our DC overhead is coming from...

Around half of our overhead is due to two general-purpose, unoptimized mechanisms used
in our generating extensions:
	-- Work list: we maintain a work-list of units of code to be generated.  In
	   short, a unit is a generalization of a basic block that has a single entry
	   but can have multiple exits.  Currently, units can contain static branches,
	   but not merges, but dynamic branches always end units.
	-- Caching: at every cache lookup, we allocate memory and store the values making
	   up the cache key to it, and pass the key to a general lookup function.  The
	   lookup function frees the memory.

There are a number of optimizations we can perform to eliminate or reduce this overhead.

THE BIGGIE:
1) Currently, we do a work-list push and pop (which includes saving and restoring
the specialization context) for every unit that we emit.  We really only need to do
this for one side of an inter-unit dynamic branch.  If we eliminated the other cases
we do work-list pushes and pops, it would eliminate all work-list operations from all
of the benchmarks except those that do multi-way loop unrolling (binary, query, and
mipsi).  Even for those three benchmarks, more than half of the work-list operations
would be eliminated.

2) We could eliminate the building of the data structure at every cache lookup by
inlining the lookup and computing the key directly from the context variables.

3) Bigger units will reduce both of these overheads.  By how much is difficult to tell.
The main way to get bigger units is linearization of dynamic branches.

4) Reachability analysis can eliminate cache lookups at static merges.

--Brian

To: eggers@thistle.cs.washington.edu
cc: spin-comp@cs
Subject: costs of emitting instructions (without overheads I just mentioned)
Date: Thu, 06 Nov 1997 16:10:03 PST
From: Brian Grant <grant@thistle.cs.washington.edu>

We should probably state this somewhere.

From Matthai:

No hole:
4 instructions (lda/ldah to construct the isntruction, a store and an add).

Fast hole patching:
14 instructions (checking if the hole fits in the range, building and emitting 
the instruction
		  and spilling/restoring a scratch register)


Slow hole patching:
25 instructions (checking if the hole fits in the range, computing a pointer 
into the static value table, 			 storing into the static value table, emitting 
a load from the static value table, emitting 		the actual computation that 
uses the rtconst, spilling/restoring a scratch register,
		incrementing the codespace pointer).

--Brian

To: eggers@thistle.cs.washington.edu
cc: spin-comp-archive@cs
Subject: features used for other benchmarks
Date: Thu, 06 Nov 1997 16:24:01 PST
From: Brian Grant <grant@thistle.cs.washington.edu>

We also use @s to indicate that calls should be evaluated at specialization time.  I'll
call this static calls.  You can decide whether it deserves a column or not.  We need
this because we don't do interprocedural side-effect analysis.

All of these benchmarks do some kind of loop unrolling where the exit condition is
static.  You can decide whether or not to count this as constant branch removal.
(But I would say not since that would be then redundant with the loop unrolling columns.)

mipsi:
	add check: static calls

chebychev:
	add check: static calls

dotproduct:
	add check: constant folding (for static array indexing)

romberg:
	looks fine

binary:
	remove check: loop unrolling (redundant with multiway unrolling)

pow:
	looks fine
	
query:
	remove check: loop unrolling (redundant)
	add checks: constant folding, multiway unrolling, static derefs (@)

--Brian

Date: Thu, 6 Nov 1997 16:53:40 -0800 (PST)
From: Markus Mock <mock@apex.cs.washington.edu>
To: Susan Eggers <eggers@apex.cs.washington.edu>
cc: spin-comp@apex.cs.washington.edu
Subject: total dc overhead and instructions stitched

BINARY

n	overhead #ins   #cycles/instruction stitched

16	66200	 373	177	(*) this is the size 'C used
500	1564463  9775	160

-----------------------------
CHEBYCHEV

5	34342	282	121
10	90448	837	112
15	179962	1692	106
20	302340	2847	106

-----------------------------
90% 0's: (Consel config)

10	5924	14	423
100	40763	53	769
200	77432	103	751

67% 0's: ('C config)

10	6153	26	238
32	15067	54	279 (*) this is the size 'C used
100	42281	153	276
200	78793	318	247

50% 0's:

10	6290	30	209
100	42401	218	194
200	82961	468	177
-----------------------------

POW:

13	4855	20	242 (*) this is the size 'C used
125	4777	29	164
253	5035	32	157
509	5494	35	156

-----------------------------

QUERY:

100	14511	85	170
1000	15668	85	184
2000	17222	85	202  (*) this is the size 'C used
-----------------------------


ROMBERG:

2	12243	173	70
4	28763	480	59
6	73733	1376	53
8	213221	4472	47




	-- Markus



To: eggers@thistle.cs.washington.edu, chambers@thistle.cs.washington.edu
cc: spin-comp-archive@thistle.cs.washington.edu
Subject: mipsi info
Date: Thu, 06 Nov 1997 17:36:18 PST
From: Brian Grant <grant@thistle.cs.washington.edu>

Gun's web page has info and references for mipsi:
http://www.cs.washington.edu/homes/egs/mipsi/mipsi.html

The info on who uses mipsi doesn't include any corporate users, but does include
people at Princeton:

MIPSI has been used by Andrew Appel and Marcelo Goncalves at Princeton University
to investigate garbage collection alternatives for future architectures.

--Brian

Date: Thu, 6 Nov 1997 17:36:20 -0800 (PST)
From: chambers@klamath (Craig Chambers)
To: spin-comp@cs
Subject: intro revised

FYI, I've finished editing the intro to the pldi paper,  in

~chambers/papers/pldi/98/DyC/paper.doc.

(Except for the last paragraph where I mention the PEPM paper)

I'm going to look at the abstract now.

-- Craig

Date: Thu, 6 Nov 1997 17:55:40 -0800
From: eggers@yakima (Susan Eggers)
To: eggers@thistle.cs.washington.edu, chambers@thistle.cs.washington.edu,
Subject: Re: mipsi info
Cc: spin-comp-archive@thistle.cs.washington.edu


We don't need to check this -- Gun has contacted all his "people"
and has a summary for us.

Susan

Date: Thu, 6 Nov 1997 17:58:33 -0800 (PST)
From: chambers@klamath (Craig Chambers)
To: spin-comp@cs
Subject: finished abstract and intro

I guess I'm releasing the write lock on these sections.  I don't know what to
look at now.  Maybe section 3?

-- Craig

Date: Thu, 6 Nov 1997 18:08:10 -0800 (PST)
From: Markus Mock <mock@apex.cs.washington.edu>
To: Craig Chambers <chambers@klamath>
cc: spin-comp@cs
Subject: Re: finished abstract and intro

That's a good idea. 

	-- Markus

On Thu, 6 Nov 1997, Craig Chambers wrote:

> I guess I'm releasing the write lock on these sections.  I don't know what to
> look at now.  Maybe section 3?
> 
> -- Craig
> 


Date: Thu, 6 Nov 1997 18:17:17 -0800 (PST)
From: Markus Mock <mock@apex.cs.washington.edu>
To: Matthai Philipose <matthai@cs>, spin-comp-archive@cs
Subject: timings for mipsi

Matthai,

since meitner has been reserved for us you might want to use it for
timing. I am logging off from meitner right now so you can be the lucky
guy.


	-- Markus


Date: Thu, 6 Nov 1997 20:06:33 -0800 (PST)
From: Markus Mock <mock@apex.cs.washington.edu>
To: Brian Grant <grant@cs>, spin-comp-archive@cs
Subject: example 

I have written up register interpreter with a sample program that computes
n factorial.

Tell me what you think. It's in
/afs/cs.washington.edu/project/dyncomp/mock/DyC/regression/interpreter

The noop version runs 
the dyc version seg faults in my compiler cc: Fatal error in
/projects/trace1/mflow/usr/vssad/release/mock/lib/ccom
cc: Terminated by segmentation violation

I am going home now to have dinner should be back on at 9:30.




	-- Markus


Date: Thu, 6 Nov 1997 20:15:24 -0800 (PST)
From: Markus Mock <mock@apex.cs.washington.edu>
To: Matthai Philipose <matthai@cs>, spin-comp-archive@cs
Subject: interpreter example

look at
/afs/cs.washington.edu/project/dyncomp/mock/DyC/regression/interpreter/interpreter.DyC


	-- Markus


To: Markus Mock <mock@apex.cs.washington.edu>
cc: spin-comp-archive@cs, matthai@thistle.cs.washington.edu
Subject: Re: example 
Date: Thu, 06 Nov 1997 20:58:27 PST
From: Brian Grant <grant@thistle.cs.washington.edu>

Cool.  Looks pretty good.  It was easy to get working -- I just had to
put something between the initial annotation and the loop head.  It is
important to remember that rule. :-)  I committed my version to CVS:
DyC/regression/interpreter.  Times suck for all computable factorials,
however. :-)

--Brian

To: spin-comp@thistle.cs.washington.edu
Subject: Markus wrote an interpreter example for the paper
Date: Thu, 06 Nov 1997 21:26:22 PST
From: Brian Grant <grant@thistle.cs.washington.edu>

The current version is in:
/afs/cs/project/dyncomp/grant/DyC/regression/interpreter/interpreter.DyC

Here is the routine:

int interpreter(int bytecodes[], int pc, int arg) 
{
  unsigned int inst, rs, rt, rd, offset, reg[32];

  make_static(bytecodes,pc:promote_one_unchecked,eager);
  reg[1] = arg;  

  for (;;) {
    inst = bytecodes@[pc];
    rs = (inst >> 21) & 0x1f; /* should we macroize all of these? */
    rt = (inst >> 16) & 0x1f;
    rd = (inst >> 11) & 0x1f;
    offset = inst & 0xffff;
    switch(inst>>26) {
    case LI:
      reg[rt] = offset;
      ++pc; continue;
    case MUL:
      reg[rd] = (int) reg[rs] * (int) reg[rt];
      ++pc; continue;
    case SUBI:
      reg[rt] = (int) reg[rs] - offset; ++pc; continue;
    case BE:
      if (reg[rs] == reg[rt]) {
	pc = pc + offset; continue;
      } else {
	++pc; continue;
      }
    case JUMP:
      pc = offset; continue;
    case RET:
      return reg[31];
    }
  }
}

Here is a program that computes factorial:

     LI r31, #1             # r1 = 1
     LI r2, #0              # r2 = 0
 L0: BE r1,r2, L1:          # if r1 == r2 goto L1
     MUL r31, r1, r31       # r31 = r31 * r1
     SUBI r1,r1,#1          # r1 = r1 - 1
     JUMP L0                # goto L0
 L1: RET                    # return result in r31

Here is the code we generate (for real!):
	ldq	t10, 440(sp)
	ldl	a2, 416(sp)
	stl	a2, 4(t10)
	fnop
	ldq	t10, 440(sp)
	lda	t12, 124(zero)
	lda	t11, 1(zero)
	addq	t10, t12, t12
	stl	t11, 0(t12)
	lda	t12, 8(zero)
	lda	t11, 0(zero)
	addq	t10, t12, t12
	stl	t11, 0(t12)
L1:	ldl	t12, 8(t10)
	ldl	t11, 4(t10)
	cmpeq	t12, t11, t11
	bne	t11, L2
	ldl	t12, 4(t10)
	ldl	t11, 124(t10)
	mull	t12, t11, t11
	stl	t11, 124(t10)
	ldl	t12, 4(t10)
	lda	t12, -1(t12)
	stl	t12, 4(t10)
	br	 L1
L2:	ldl	v0, 124(t10)
	ldq	ra, 128(sp)
	fnop
	lda	sp, 544(sp)
	ret	zero, (ra), 1

--Brian

Date: Thu, 6 Nov 1997 21:30:05 -0800 (PST)
From: "Markus U. Mock" <mock@cs.washington.edu>
To: Brian Grant <grant@thistle.cs.washington.edu>
cc: Markus Mock <mock@apex.cs.washington.edu>,
Subject: Re: example 

Great!



	-- Markus 


On Thu, 6 Nov 1997, Brian Grant wrote:

   Cool.  Looks pretty good.  It was easy to get working -- I just had to
   put something between the initial annotation and the loop head.  It is
   important to remember that rule. :-)  I committed my version to CVS:
   DyC/regression/interpreter.  Times suck for all computable factorials,
   however. :-)
   
   --Brian
   


To: spin-comp@thistle.cs.washington.edu
Subject: cleaned up interpreter example
Date: Thu, 06 Nov 1997 22:23:57 PST
From: Brian Grant <grant@thistle.cs.washington.edu>

Here is the interpreter:

int interpreter(int bytecodes[], int pc, int arg) 
{
  unsigned int inst, rs, rt, rd, offset, reg[32];
  make_static(bytecodes,pc:promote_one_unchecked,eager);
  reg[1] = arg;  
  for (;;) {
    inst = bytecodes@[pc];
    rs = R1(inst); rt = R2(inst); rd = R3(inst);
    offset = IMMEDIATE(inst);
    switch(OPCODE(inst)) {
    case LI:
      reg[rt] = offset; ++pc; continue;
    case MUL:
      reg[rd] = (int) reg[rs] * (int) reg[rt];
      ++pc; continue;
    case SUBI:
      reg[rt] = (int) reg[rs] - offset;
      ++pc; continue;
    case RBE:
      if (reg[rs] == reg[rt])
	 { pc += offset; continue; }
      else
	 { ++pc; continue; }
    case ABR:
      pc = offset; continue;
    case JMP:
      pc = reg[rs]; continue;
    case RET:
      return reg[31];
    }
  }
}

Here is an interpreted program that computes factorial:

     LI r31, #1             # r1 = 1
     LI r2, #0              # r2 = 0
 L0: RBE r1,r2, L1          # if r1 == r2 goto L1
     MUL r31, r1, r31       # r31 = r31 * r1
     SUBI r1,r1,#1          # r1 = r1 - 1
     ABR L0                 # goto L0
 L1: RET                    # return result in r31

Here is the code we generate:

	ldq	r24, 440(sp)
	ldl	r18, 416(sp)
	stl	r18, 4(r24)
	fnop
	ldq	r24, 440(sp)
	lda	r27, 124(zero)
	lda	r25, 1(zero)
	addq	r24, r27, r27
	stl	r25, 0(r27)
	lda	r27, 8(zero)
	lda	r25, 0(zero)
	addq	r24, r27, r27
	stl	r25, 0(r27)
L0:	ldl	r27, 8(r24)
	ldl	r25, 4(r24)
	cmpeq	r27, r25, r25
	bne	r25, L1
	ldl	r27, 4(r24)
	ldl	r25, 124(r24)
	mull	r27, r25, r25
	stl	r25, 124(r24)
	ldl	r27, 4(r24)
	lda	r27, -1(r27)
	stl	r27, 4(r24)
	br	L0
L1:	ldl	r0, 124(r24)
	ldq	ra, 128(sp)
	fnop
	lda	sp, 544(sp)
	ret	zero, (ra), 1


Date: Fri, 7 Nov 1997 00:24:22 -0800 (PST)
From: "Markus U. Mock" <mock@cs.washington.edu>
To: grant@cs.washington.edu
cc: spin-comp@thistle.cs.washington.edu
Subject: Re: Markus wrote an interpreter example for the paper

I added a few comments to the generated code..

We probably want to say that we got rid of all the interpretation overhead
but would be doing even better by register allocating the reg-array
(future work).



     LI r31, #1             # r31 = 1
     LI r2, #0              # r2 = 0
 L0: RBE r1,r2, L1          # if r1 == r2 goto L1
     MUL r31, r1, r31       # r31 = r31 * r1
     SUBI r1,r1,#1          # r1 = r1 - 1
     JMPI L0                # goto L0
 L1: RET                    # return result in r31





	ldq	r24, 440(sp) 	// r1 = arg	
	ldl	r18, 416(sp)
	stl	r18, 4(r24)
	fnop
	ldq	r24, 440(sp)	// LI r31, #1
	lda	r27, 124(zero)	
	lda	r25, 1(zero)
	addq	r24, r27, r27
	stl	r25, 0(r27)
	lda	r27, 8(zero)	// LI r2, #0
	lda	r25, 0(zero)
	addq	r24, r27, r27
	stl	r25, 0(r27)
L0:	ldl	r27, 8(r24)	// RBE r1, r2, L1
	ldl	r25, 4(r24)
	cmpeq	r27, r25, r25
	bne	r25, L1
	ldl	r27, 4(r24)	// MUL r1, r31, r31
	ldl	r25, 124(r24)
	mull	r27, r25, r25
	stl	r25, 124(r24)
	ldl	r27, 4(r24)
	lda	r27, -1(r27)	// SUBI r1, r1, #1
	stl	r27, 4(r24)
	br	L0		// JMPI L0
L1:	ldl	r0, 124(r24)	// RET
	ldq	ra, 128(sp)
	fnop
	lda	sp, 544(sp)
	ret	zero, (ra), 1









To: spin-comp@thistle.cs.washington.edu
Subject: effect of register actions on the example code
Date: Fri, 07 Nov 1997 08:32:15 PST
From: Brian Grant <grant@thistle.cs.washington.edu>

Here is the code we would like to generate (via register actions):

	ldl	r1,  416(sp)		# dynamically allocated
	lda	r2,  1(zero)		# dynamically allocated
	lda	r3,  0(zero)		# dynamically allocated
L0:	cmpeq	r1,  r3, r25
	bne	r25, L1
	mull	r1,  r2, r2
	lda	r1,  -1(r1)
	br	L0
L1:	or	r2,  zero, r0
	ldq	ra, 128(sp)
	fnop
	lda	sp, 544(sp)
	ret	zero, (ra), 1

The generated code went from 30 instructions to 13.

--Brian

To: spin-comp@thistle.cs.washington.edu
Subject: Fabius & caching
Date: Fri, 07 Nov 1997 09:08:44 PST
From: Brian Grant <grant@thistle.cs.washington.edu>

It looks like they had cache_one:

From "Optimizing ML with Run-Time Code Generation":
Curried applications that are not inlined are instead compiled into two calls,
the first to a memoized code generator and the second to the address returned by
the first call.  Memoization is currently implemented using a per-procedure log
that records the entry points of previously optimized code and the values that
were used to optimize it.  For efficiency, values are compared using pointer
equality to determine whether code can be reused.  However, this causes
unacceptable duplication of effort in some benchmarks because structurally
equivalent values fail to match.

--Brian

To: spin-comp@thistle.cs.washington.edu
Subject: section 2, the example
Date: Fri, 07 Nov 1997 09:14:02 PST
From: Brian Grant <grant@thistle.cs.washington.edu>

What do we want section 2 to show?

1) Explain DyC's capabilities (esp. those used in the benchmarks)
2) Illustrate conciseness of the annotations
3) Give a sense for the complexity of interpreter/simulator programs
4) Show how DyC works

Is that about right?  We've worked on bullets 1-3 and are starting on #4.

--Brian

Date: Fri, 7 Nov 1997 09:33:00 -0800 (PST)
From: chambers@klamath (Craig Chambers)
To: spin-comp@thistle.cs.washington.edu, grant@cs.washington.edu
Subject: Re: section 2, the example

> From grant@thistle.cs.washington.edu  Fri Nov  7 09:14:08 1997
> Delivery-Date: Fri, 07 Nov 1997 09:14:09 PST
> X-Mailer: exmh version 1.5.3 12/28/94
> Reply-To: grant@cs.washington.edu
> To: spin-comp@thistle.cs.washington.edu
> Subject: section 2, the example
> Mime-Version: 1.0
> Date: Fri, 07 Nov 1997 09:14:02 PST
> From: Brian Grant <grant@thistle.cs.washington.edu>
> 
> What do we want section 2 to show?
> 
> 1) Explain DyC's capabilities (esp. those used in the benchmarks)
> 2) Illustrate conciseness of the annotations
> 3) Give a sense for the complexity of interpreter/simulator programs
> 4) Show how DyC works
> 
> Is that about right?  We've worked on bullets 1-3 and are starting on #4.
> 
> --Brian
> 

Sounds good to me.

Cool that the interpreter is for real!

-- Craig

Date: Fri, 7 Nov 1997 09:40:26 -0800
From: eggers@yakima (Susan Eggers)
To: spin-comp@thistle.cs.washington.edu, grant@cs.washington.edu
Subject: Re: section 2, the example

What you are doing sounds right to me.
The only wrinkle is that Craig may be doing/have done the same thing.  We
have too many writers for our situation of rewriting on the day of
submission.

So can I suggest that we divide up the work?  How about this division:
-- Craig and Brian do section 2
-- Craig is already making changes to highlighted areas in section 4
-- I'm making changes to Craig's changes in the intro, and will also
	be responsible for making sure the paper reads as though it
	was written with one voice.  I'd like input on this.
-- Matthai and Markus don't seem to be here now.  So when you come in,
	want to help one of the groups?

Is this ok with everyone?

Susan

To: eggers@yakima (Susan Eggers)
cc: spin-comp@thistle.cs.washington.edu
Subject: Re: section 2, the example 
Date: Fri, 07 Nov 1997 09:42:08 PST
From: Brian Grant <grant@thistle.cs.washington.edu>

Markus is here and helping with section 2.

--Brian

Date: Fri, 7 Nov 1997 09:42:32 -0800 (PST)
From: Markus Mock <mock@apex.cs.washington.edu>
To: Susan Eggers <eggers@yakima>
cc: spin-comp@thistle.cs.washington.edu, grant@cs.washington.edu
Subject: Re: section 2, the example

Nope I'm here. I am currently putting the example in frame showing the
results of the BTA and also the generated code and the register allocated
code we'd really like.


	-- Markus

On Fri, 7 Nov 1997, Susan Eggers wrote:

> What you are doing sounds right to me.
> The only wrinkle is that Craig may be doing/have done the same thing.  We
> have too many writers for our situation of rewriting on the day of
> submission.
> 
> So can I suggest that we divide up the work?  How about this division:
> -- Craig and Brian do section 2
> -- Craig is already making changes to highlighted areas in section 4
> -- I'm making changes to Craig's changes in the intro, and will also
> 	be responsible for making sure the paper reads as though it
> 	was written with one voice.  I'd like input on this.
> -- Matthai and Markus don't seem to be here now.  So when you come in,
> 	want to help one of the groups?
> 
> Is this ok with everyone?
> 
> Susan
> 


Date: Fri, 7 Nov 1997 10:05:33 -0800 (PST)
From: chambers@klamath (Craig Chambers)
To: spin-comp@cs
Subject: paper lock

I'm grabbing the write lock on sections 3 and 4 and 5.  I'm starting from 
Susan's copy, right?

-- Craig

Date: Fri, 7 Nov 1997 10:07:34 -0800 (PST)
From: chambers@klamath (Craig Chambers)
To: spin-comp@thistle.cs.washington.edu, grant@cs.washington.edu,
Subject: Re: section 2, the example

As I discussed with Susan, Brian & Markus should do section 2 to their
heart's content, then Susan and/or I will read it over later.  I'm focussing
on sections 3 onwards now.

-- Craig

Date: Fri, 7 Nov 1997 10:40:48 -0800 (PST)
From: chambers@klamath (Craig Chambers)
To: spin-comp@cs
Subject: questions

Is it spelled chebyshev or chebychev?

I need data on what each benchmark does (a one liner), what the run-time
constant is for each benchmark, its total size in lines, and the size in lines
of the dynamic region.

-- Craig

Date: Fri, 7 Nov 1997 11:09:45 -0800 (PST)
From: Markus Mock <mock@apex.cs.washington.edu>
To: Craig Chambers <chambers@apex.cs.washington.edu>
cc: spin-comp@apex.cs.washington.edu
Subject: RE: questions


Is it spelled chebyshev or chebychev?

I just double-checked in Grolier's: CHEBYSHEV


BINARY

desc:	does a binary search on an array of size n given a value v
rtc: 	array size and the array contents
region	19 lines
total	136

-----------------------------
CHEBYCHEV

desc:	computes a chebyshev polynomial to approximate a function (cos in
	our case) n = degree of polynomial to be computed
rtc:	n
region 	19
total	139

-----------------------------
DOTPRODUCT

desc:	computes the dotproduct of two vectors of size n
rtc:	vector1 and n
region:	11
total:	127
-----------------------------
POW

desc:	computes f **n, f a double, n int by successive squaring 
	(log n) algo

rtc:	n
region:	12
total:	102

-----------------------------

QUERY:

desc: 	does a query for a database of size n. The query struct q has
	7 elements specifying a database record field, a test and a value.
	It interpretes the query for a given database record testing if
	all query conditions are true. 

rtc:	query q, size of query (7)
region:	24
total:	184

-----------------------------


ROMBERG:

desc:	does a Romberg integration (approximation) of a function
	iterating M times. We're integrating (x * x) + (2.0 * x) + 1.0;

rtc:	iteration bound M
region:	24
total:	155




	-- Markus







Date: Fri, 7 Nov 1997 12:24:48 -0800 (PST)
From: Markus Mock <mock@apex.cs.washington.edu>
To: Brian Grant <grant@cs>, spin-comp-archive@cs
Subject: frame doc

my version of the paper is in 
~mock/submission/paper.doc


	-- Markus


Date: Fri, 7 Nov 1997 12:33:48 -0800 (PST)
From: chambers@klamath (Craig Chambers)
To: spin-comp@cs
Subject: experiments & rel work

I'm done revising the former sections 3-5, now sections 3-4.  See .../exp.doc
in my paper directory.  I'm now going to draft a conclusion, then we can try to
do some integration.

-- Craig

Date: Fri, 7 Nov 1997 13:02:21 -0800
From: eggers@yakima (Susan Eggers)
To: spin-comp@cs, chambers@klamath
Subject: Re: experiments & rel work

I now have the lock on these sections.

Date: Fri, 7 Nov 1997 13:02:56 -0800 (PST)
From: chambers@klamath (Craig Chambers)
To: spin-comp@cs
Subject: conclusion

I'm done drafting a conclusion.  In the same document as before: exp.doc.

-- Craig

To: eggers@franklin.cs.washington.edu
cc: spin-comp@franklin.cs.washington.edu
Subject: mipsi cycles/instr stitched and number of instructions
Date: Fri, 07 Nov 1997 13:31:29 PST
From: Matthai Philipose <matthai@franklin.cs.washington.edu>

mipsi on sort.x:
Instructions stitched: 59169
Cycles/instr stitched: 331

Cycles/instruction is higher than for the mini-programs, because:
	1) It doesn't use the unchecked policy (it uses cache_all); this is because 
is we see a pc twice, the second time we want to do the cache check, figure 
out we've seen the pc before and stitch a branch to the pc. 
	2) It has two lazy points within the loop being unrolled (basically two 
computed jump instructions beins simulated, namely JR (return) and JALR (jump 
and link through register).
		Matthai



To: spin-comp@thistle.cs.washington.edu
Subject: Monday's meeting
Date: Fri, 07 Nov 1997 16:18:49 PST
From: Brian Grant <grant@thistle.cs.washington.edu>

Monday's meeting is cancelled.

I won't come in at least until Wednesday.  I suggest everybody else get as much
rest as they can. :-)

--Brian

Date: Sat, 08 Nov 1997 13:38:25 -0500
From: Charlie Garrett <garrett@etcons.com>
To: spin-comp@cs.washington.edu
Subject: way to go

It sounds like you got the PLDI paper off in time with some
good performance numbers.  Congratulations.

Could you point me to the file containing the submission?  I'll
assume that I should not show it to anyone else.  Thanks.

--
Charlie

To: Markus Mock <mock@cs.washington.edu>
cc: spin-comp@franklin.cs.washington.edu
Subject: e-mail confirmation for PLDI receipt?
Date: Mon, 10 Nov 1997 09:42:22 PST
From: Matthai Philipose <matthai@franklin.cs.washington.edu>

Markus,
Did you get the e-mail confirmation that they received our submission?
Sung, for instance, did not get one last year and found out too late that
her paper had been lost in some bureaucratic snafu.
		Matthai

Date: Mon, 10 Nov 1997 11:00:57 -0800 (PST)
From: Markus Mock <mock@apex.cs.washington.edu>
To: Matthai Philipose <matthai@cs.washington.edu>
cc: spin-comp@franklin.cs.washington.edu
Subject: Re: e-mail confirmation for PLDI receipt?

I got two, one each for each of our submissions.


	-- Markus

On Mon, 10 Nov 1997, Matthai Philipose wrote:

> Markus,
> Did you get the e-mail confirmation that they received our submission?
> Sung, for instance, did not get one last year and found out too late that
> her paper had been lost in some bureaucratic snafu.
> 		Matthai
> 


Date: Wed, 12 Nov 1997 22:54:55 -0800 (PST)
From: "Markus U. Mock" <mock@cs.washington.edu>
To: spin-comp@cs.washington.edu
Subject: PLDI 98 (fwd)



---------- Forwarded message ----------
Date: Wed, 12 Nov 1997 22:52:36 -0600 (CST)
From: Keith Cooper <keith@cs.rice.edu>
To: mock@cs.washington.edu
Subject: PLDI 98

You submitted an extended abstract to PLDI 98.
We have printed your abstract without problem;
this notice should reassure you that we have 
the abstract registered and printed.

If you submitted multiple abstracts, you should
receive multiple copies of this notice.

keith d. cooper
(cooper@rice.edu)


To: spin-comp@thistle.cs.washington.edu
Subject: priorities (mostly wrt the PLDI deadline)
Date: Mon, 17 Nov 1997 15:01:56 PST
From: Brian Grant <grant@thistle.cs.washington.edu>

We mainly want to try to lower breakeven points (BE) and increase speedups (SU)
for our current apps (BS for both), but we also would like to extend our
expressivity (EX) to include most of our core design and another app (AP)
might be nice.

With this in mind, we've set the following priorities for people:

Priority can be one (*) or two (**) stars.  Lower priority items, such as
clustering or run-time inlining, are not mentioned below.

Matthai:
	** [SU] Peephole (flipping branch directions, strength reduction)
	** [SU] Eliminate useless unconditional branches

Markus:
	** [SU] Register actions
	 * [BS] Reachability conditions
	 * [EX] Polyvariant division
	 * [AP] SPIN dispatcher

Brian:
	** [BE] Inline common case of cache lookups and memory allocation
	** [BE] Remove work-list pushes for "last edge" from a unit (common
		case is only one edge!)

Markus is working on his generals now, until mid-December.  Brian will be 
working on his Jan-Feb.  We are all responsible for debugging, but Matthai
will likely have to track down most of the currently known bugs after he
returns on Dec. 14.

--Brian

To: spin-comp@thistle.cs.washington.edu
Subject: things to think about for next week
Date: Mon, 17 Nov 1997 15:05:09 PST
From: Brian Grant <grant@thistle.cs.washington.edu>

1) Register actions.
2) Reachability analysis in the general framework with polyvariant
   specialization, cache checks, etc.  Which merges should be identified as
   static?  Is this still a useful notion?  How else might we want/need to use
   the results of reachability analysis?
3) Do we have any ideas that we might want to patent (e.g., register actions)?

--Brian

Date: Mon, 17 Nov 1997 20:11:23 -0800
From: eggers@yakima (Susan Eggers)
To: spin-comp@thistle.cs.washington.edu, grant@cs.washington.edu
Subject: Re: priorities (mostly wrt the PLDI deadline)


Brian --

Thank you for doing this.

Susan

To: spin-comp@cs
Subject: status
Date: Wed, 19 Nov 1997 13:44:18 PST
From: Brian Grant <grant@thistle.cs.washington.edu>

In my version, all but one of the (previously working) regression tests works;
pow is the exception.  In pow, initialization of loop-induction variable,
a floating-point load of a float constant, is dropped.  I had this problem
before with another benchmark, but I don't remember how I fixed it.  I should
probably make a compendium of bugs since many of them have been recurring
problems.  I'm putting pow on the back burner fow now.

My version includes the new macroized boilerplate with a generic mechanism for
extracting the boilerplate and recording its components in a hash table.
Unfortunately, my generic parameterized code-copying routines aren't working
yet, so the old "manual" copy routines are still in use.  The hitch is that
the parameter-naming mechanism I chose (VAR/TEMP correspondence) doesn't work
when the source variables are not initialized.  I just need to figure out a
way to initialize the variables in a way that doesn't allow their corresponding
TEMPs to be eliminated but does allow me to easily delete the initialization
code.

As soon as I get the new boilerplate mechanisms fully working, I'll fix a
bug in the compiler/merger interface and inline memory allocation and
caching code (at least for the first hash).  After that, I'll move on to
optimizing the work-list loop.

--Brian

To: spin-comp@cs
Subject: a couple bits of progress
Date: Thu, 20 Nov 1997 23:13:21 PST
From: Brian Grant <grant@thistle.cs.washington.edu>

1) I resolved the glitches in my naming mechanism for the general boilerplate.
I used calls of appropriate types (to prevent coercion operations) to
initialize the parameters of boilerplate code snippets.  Now I just need
to debug the copying routine and I can then insert several new snippets
for memory allocation and caching.

2) I made the first pass on eliminating needless work-list pushes and pops.
I already had code to identify which pushes were eliminable, so I used this
information to put in an edge directly to the next unit, rather than go
through the push/pop cycle.  It seems to work in most cases.  Binary and
query appear to have some problem with caching, but it should be easily
fixed.

I didn't run on an idle machine, but it looks like the benefit will be as
big as expected.  Dotproduct now has a best cycle / instruction emitted of
42 for a vector of length 200, compared to the ~150 I saw before and the
250-750 reported in the paper.

Note that what I have done is for eager edges only.  Lazy edges
will be trickier, but will have a big effect on lowering breakevens for
small input sizes.

If only we had had one or two more weeks.... :-)

I'm running into failures in the scheduler with increasing frequency.  I
had to tweak the unrolling options a little more to get our programs to go
through.  One of these days, I may have to plunge in and try to find the
root of the problem.

--Brian

Date: Fri, 21 Nov 1997 09:06:14 -0800
From: eggers@yakima (Susan Eggers)
To: spin-comp@cs, grant@cs.washington.edu
Subject: Re: a couple bits of progress


Nice report.  I'm glad your breakeven estimates are panning out.

Susan

To: eggers@yakima (Susan Eggers)
cc: spin-comp@cs
Subject: Re: a couple bits of progress 
Date: Fri, 21 Nov 1997 11:33:41 PST
From: Brian Grant <grant@thistle.cs.washington.edu>

>> Nice report.  I'm glad your breakeven estimates are panning out.

One thing I didn't check is how many zeros there were in the test I ran.
The primary reason some of the cycles/instr. were so high for dotproduct
was just that no instructions were generated for 90% of the loop iterations
due to zeroes.

But < 50 cycles/instr. is pretty good.

--Brian

To: spin-comp@thistle.cs.washington.edu
Subject: Leone's new dynamic-compilation project
Date: Mon, 24 Nov 1997 16:22:30 PST
From: Brian Grant <grant@thistle.cs.washington.edu>

I just found this (meaning I don't know anything yet):
http://www.cs.indiana.edu/proglang/dynamo/

--Brian

Date: Mon, 24 Nov 1997 16:29:19 -0800
From: eggers@yakima (Susan Eggers)
To: spin-comp@thistle.cs.washington.edu, grant@cs.washington.edu
Subject: Re: Leone's new dynamic-compilation project


Have to say he is a little better at names that we are...

To: spin-comp@thistle.cs.washington.edu
Subject: code for aligning a code address
Date: Mon, 24 Nov 1997 17:00:41 PST
From: Brian Grant <grant@thistle.cs.washington.edu>

The code required has essentially three instructions:
	- Add
	- Build mask
	- Mask

I don't see how to get it down to two since the mask is a 64-bit quantity.

There are also a few more instructions because of some accounting I forgot
about (that lets us know how many instructions we generated).

Here is the C source from the boilerplate:

    AlignedAddress = (char*) (((long)DYCBP_PARAM(1) +
			       ALPHA_CACHE_LINE_SIZE*PAD_CACHE_LINES - 1) &
			      (long)~(ALPHA_CACHE_LINE_SIZE-1));
    DyCRT_PaddedBytes += ((unsigned long) AlignedAddress -
			  (unsigned long) DYCBP_PARAM(1));
    DYCBP_PARAM(1) = AlignedAddress;

Here is the Multiflow IR (result temp is first, followed by operands):

ADD <>t259 <>t398 63(SI64)
SUB <_AlignedAddress$1.54>t444 0(I64) 32(SI64)
BANDOR.AND.NN <_AlignedAddress$1.54>t387 <>t259 <_AlignedAddress$1.54>t444
LD <_DyCRT_PaddedBytes$1.0>t261 <>t381 addr(_DyCRT_PaddedBytes$1.0)(P64) _DyCRT_PaddedBytes$1.0
SUB <_DyCRT_PaddedBytes$1.0>t445 <_AlignedAddress$1.54>t387 <>t398
ADD <_DyCRT_PaddedBytes$1.0>t264 <_DyCRT_PaddedBytes$1.0>t445 <_DyCRT_PaddedBytes$1.0>t261
ASSIGN <>t398 <_AlignedAddress$1.54>t387
ST <_DyCRT_PaddedBytes$1.0>t264 <>t381 addr(_DyCRT_PaddedBytes$1.0)(P64) _DyCRT_PaddedBytes$1.0

--Brian

Date: Mon, 24 Nov 1997 17:46:27 -0800 (PST)
From: chambers@klamath (Craig Chambers)
To: spin-comp@thistle.cs.washington.edu, grant@cs.washington.edu
Subject: Re: Leone's new dynamic-compilation project

I've seen this before.  I printed out the white paper on Dynamo, and it looks
very boring; exactly Lightweight RTCG as in Fabius as far as I can tell.

Sorry I didn't point you all at it at the time; I'm surprised I
didn't.  I guess Jeff Dean first pointed me at it, because of some
inlining work on the page that's mostly a subset of what Jeff & I did
before.

-- Craig

Date: Mon, 24 Nov 1997 17:55:19 -0800 (PST)
From: chambers@klamath (Craig Chambers)
To: spin-comp@thistle.cs.washington.edu, grant@cs.washington.edu
Subject: Re: code for aligning a code address

> The code required has essentially three instructions:
> 	- Add
> 	- Build mask
> 	- Mask
> 
> I don't see how to get it down to two since the mask is a 64-bit quantity.

Can you use a negative immediate?  It's a small negative number, not a large
positive number.  Sparc has signed immediates....

> 
> There are also a few more instructions because of some accounting I forgot
> about (that lets us know how many instructions we generated).

We shouldn't do this instrumentation except in a slow version.  The measured,
fast, normal version should have no unneeded instrumentation overhead.  That's
4 instructions of overhead from the sequence, including a LD and a ST.

Removing those, we get:

> 
> Here is the C source from the boilerplate:
> 
>     AlignedAddress = (char*) (((long)DYCBP_PARAM(1) +
> 			       ALPHA_CACHE_LINE_SIZE*PAD_CACHE_LINES - 1) &
> 			      (long)~(ALPHA_CACHE_LINE_SIZE-1));
>     DYCBP_PARAM(1) = AlignedAddress;
> 
> Here is the Multiflow IR (result temp is first, followed by operands):
> 
> ADD <>t259 <>t398 63(SI64)
> SUB <_AlignedAddress$1.54>t444 0(I64) 32(SI64)
> BANDOR.AND.NN <_AlignedAddress$1.54>t387 <>t259 <_AlignedAddress$1.54>t444
> ASSIGN <>t398 <_AlignedAddress$1.54>t387

The SUB appears to be making a -32 constant into t444, then doing a t387 &= -32
instruction in the bizarre BANDOR.AND.NN instruction.  So maybe no negative
immediates, therefore an extra instruction.

Why is there a separate ASSIGN instruction?  Why doesn't the BANDOR instruction
compute directly into t398?  If you dropped the AlignedAddress temp from the
boilerplate, and assigned directly into DYCBP_PARAM(1), would that 4th
instruction go away?

So 3 instrs should be the goal, 2 if negative immediates are supported.

-- Craig

To: chambers@klamath (Craig Chambers)
cc: spin-comp@thistle.cs.washington.edu
Subject: Re: code for aligning a code address 
Date: Tue, 25 Nov 1997 07:05:58 PST
From: Brian Grant <grant@thistle.cs.washington.edu>

>> Can you use a negative immediate?  It's a small negative number, not a large
>> positive number.  Sparc has signed immediates....

I'll check the architecture manual and write a test in assembly code.

--Brian

To: chambers@klamath (Craig Chambers)
cc: spin-comp@thistle.cs.washington.edu
Subject: Re: code for aligning a code address 
Date: Tue, 25 Nov 1997 14:52:16 PST
From: Brian Grant <grant@thistle.cs.washington.edu>

>> Sparc has signed immediates....

I checked the arch. manual.  Alpha only has signed immediates for memory-
format instructions (like LDA).  Short immediates for operate-format
instructions such as the BAND are zero-extended (and non-negative).

--Brian

Date: Tue, 25 Nov 1997 14:59:13 -0800
From: eggers@yakima (Susan Eggers)
To: chambers@klamath, grant@thistle.cs.washington.edu
Subject: Re: code for aligning a code address
Cc: spin-comp@thistle.cs.washington.edu

now we have something else to add to the list of arch-dep effects.

susan

To: spin-comp@thistle.cs.washington.edu
Subject: another possible thing to do before the final paper deadline
Date: Wed, 26 Nov 1997 10:55:00 PST
From: Brian Grant <grant@thistle.cs.washington.edu>

We could implement the syntactic sugar(s) that would make @ largely
unnecessary.  I think we now know enough about the front end to do it.

--Brian

Date: Wed, 26 Nov 1997 10:59:24 -0800 (PST)
From: chambers@klamath (Craig Chambers)
To: spin-comp@thistle.cs.washington.edu, grant@cs.washington.edu
Subject: Re: another possible thing to do before the final paper deadline


> From grant@thistle.cs.washington.edu  Wed Nov 26 10:55:27 1997
> Delivery-Date: Wed, 26 Nov 1997 10:55:28 PST
> X-Mailer: exmh version 1.5.3 12/28/94
> Reply-To: grant@cs.washington.edu
> To: spin-comp@thistle.cs.washington.edu
> Subject: another possible thing to do before the final paper deadline
> Mime-Version: 1.0
> Date: Wed, 26 Nov 1997 10:55:00 PST
> From: Brian Grant <grant@thistle.cs.washington.edu>
> 
> We could implement the syntactic sugar(s) that would make @ largely
> unnecessary.  I think we now know enough about the front end to do it.
> 
> --Brian
> 

This is the idea for annotating structure/array element types in place of
all references to them?

-- Craig

To: chambers@klamath (Craig Chambers)
cc: spin-comp@thistle.cs.washington.edu
Subject: Re: another possible thing to do before the final paper deadline 
Date: Wed, 26 Nov 1997 11:02:50 PST
From: Brian Grant <grant@thistle.cs.washington.edu>

>> This is the idea for annotating structure/array element types in place of
>> all references to them?

Yes.  We could annotate call as constant in their declarations as well, which
would be useful for annotating sin/cos in Consel's benchmarks but may not be
useful in mipsi.

--Brian

Date: Wed, 26 Nov 1997 11:36:02 -0800
From: eggers@yakima (Susan Eggers)
To: chambers@klamath, grant@thistle.cs.washington.edu
Subject: Re: another possible thing to do before the final paper deadline
Cc: spin-comp@thistle.cs.washington.edu


Can you spell out what this would save us in terms of either
asymp. speedup or breakeven?

Susan

To: spin-comp@thistle.cs.washington.edu
Subject: results page
Date: Tue, 02 Dec 1997 11:12:12 PST
From: Brian Grant <grant@thistle.cs.washington.edu>

I have entered Table 2 from our PLDI submission.  It currently contains the
same results as are in the submission.  I'll update it tonight with our
new and improved breakevens.

http://www.cs.washington.edu/research/dyncomp/Latest_Results.html

--Brian

To: spin-comp@thistle.cs.washington.edu
Subject: numbers for dotproduct are on the results page
Date: Tue, 02 Dec 1997 15:52:28 PST
From: Brian Grant <grant@thistle.cs.washington.edu>

Speedup is lower, I think, because of unnecessary table-pointer builds and
useless unconditional branches.  The table-pointer-build problem was
re-introduced when I eliminated a certain class of work-list push/pops.  That's
a bug that I need to fix.  The branch problem just didn't happen to manifest
itself in dotproduct previously, but does now.  That is something that
Matthai can fix when he returns.

--Brian

To: spin-comp@thistle.cs.washington.edu
Subject: commit
Date: Tue, 02 Dec 1997 16:09:33 PST
From: Brian Grant <grant@thistle.cs.washington.edu>

I just committed my code.  Do a top-level update.  binary and query run
again, but not with my work-list optimizations.

--Brian

To: spin-comp@thistle.cs.washington.edu
Subject: another possible app: Limbo
Date: Thu, 04 Dec 1997 11:25:27 PST
From: Brian Grant <grant@thistle.cs.washington.edu>

I just talked to Dave Presotto and he was interested in giving us the Bell
Labs (research) version of the Limbo interpreter.  It is written in C and he
said that is pretty small.  Limbo is the language used for Inferno, Lucent's
answer to the JavaVM and JavaOS.

--Brian

To: matthai@thistle.cs.washington.edu
cc: spin-comp@cs
Subject: report on benchmark status and what I've been up to
Date: Sun, 07 Dec 1997 12:57:43 PST
From: Brian Grant <grant@thistle.cs.washington.edu>

Report for Matthai (and everyone else)

Summary:

	-- We have better breakevens (and a few speedups, too!) for
	   nearly all of the `C and Tempo benchmarks

	-- Save a backup copy of your stitcher before you update
	-- Try your table-pointer-build-elimination optimization
	-- Try mipsi with -mP2DYC_peel_worklist_loop=true
	-- Look at query and the insidious assertion at cg/schedule_vn.C:799
	-- Look at the problem of intra-unit branches to the next
	   instruction

Details:

I have been working on lowering our dynamic-compilation overhead and
breakeven points.  The two main strategies I've used are:

	1) Inlining library routines for allocating and freeing
	   memory.
	2) Eliminating the work-list push/pop for one successor of
	   every unit (the "last" successor).  Since exactly one
	   successor is the common case (everywhere except at a
	   dynamic branch), this yields big speedups.

I'm mostly done with these optimizations.  The one case I have not
addressed is that of nested (emitted) lazy points.  The reason for
this is that doing either of these things at an emitted lazy point
would require the insertion of a dynamic branch into template code,
which cannot easily be done.  Another optimization I have yet to get
started on is inlining the first hash of the cache lookup and
eliminating the construction of the context vector preceding cache
lookups (the vector would then only be constructed if the lookup
failed).

I also fixed a few bugs.  One was a work-list bug that affected apps
with dynamic branches.  I'm not sure if it will allow any broken apps
to work.  The other main bug was in the table-pointer-build
elimination.  I now propagate the flag through the work-list.  I need
to make one more fix, however, which would be to check that the table
used is the same as the one for the predecessor.  I copied your
version of the stitcher, fixed a few minor bugs, changed a couple of
the label formats in minor ways, and commented out your optimization
that built the table pointer only when needed.  When you do an update
you should get a conflict there.

I committed my version as 3.0.  When you do an update, your whole
compiler may be rebuilt.

I have created new scripts, called rt-time, that are invoked when
using rt to perform timings.  rt-exec is still used for regression
testing.

I have created a new script, gen-stats.pl, that is invoked
automagically when you use rt to time the benchmarks.  It creates a
file called <app>.stats in the rt directory for <app>.  The script
automatically computes the median times and overheads, speedup, and
breakeven.  I have modified the `C and Tempo benchmarks we reported
in the submission to conform to the output that it expects.  To make
other apps print data in the right format, take a look at, for
example, dotproduct.  Probably, you'll have to only add three print
statements.

Updated performance results for the `C and Tempo benchmarks (all
except query) can be found at:

	http://www.cs.washington.edu/research/dyncomp/Latest_Results.html

The page is globally accessible, but I currently only have a link to
it from our internal page.

Note that I have not tried to compile or run mipsi with these
optimizations turned on.  While I'm gone, you should try this, but
don't bother to debug it if it doesn't work.

The other apps:

	chebyshev	I was unable to duplicate Markus' spectacular
			speedups.  I looked at his raw numbers and
			found my noop version (plain Mflow, same
			options as DyC version) to be significantly
			faster, while my dc version was slightly
			slower.  Some compiler options have changed,
			but not ones that I would expect to account
			for the difference.  In any case, we should
			probably compare to those faster numbers and
			report the lower speedups.  Two fewer
			instructions were stitched due to one
			table-pointer build being eliminated.  DC
			overhead was about the same since chebyshev
			already had relatively large units.
			Breakevens went up slightly due to the lower
			speedups. 

	romberg		I haven't yet looked at why we're generating
			more instructions than before.  It could be
			due to a bug in the
			table-pointer-build-elimination optimization.
			Despite that, we get slightly better speedups
			for the three smaller data sizes, but slightly
			lower for the largest.  Overhead was already
			the lowest of all the apps, but the
			optimizations cut it nearly in half, causing a
			corresponding drop in the breakevens.

	binary		Higher speedup is due partially to slowing
			down of the baseline, I think.  Overhead and
			breakevens are cut by a factor of 5.  The loop
			we unroll is small but has lots of units due
			to dynamic branches.

	pow		Again, more instructions generated.  Slightly
			lower speedups but it doesn't show due to
			rounding.  Overhead was reduced by about a
			factor of three, but breakevens were only
			reduced by about half due to the decrease in
			speedup.

	query		This works with the work-list optimizations
			turned off, but we won't even get the same
			performance as we reported in the submission
			if we do that.  With the optimizations turned
			on, I expect it to work but I keep running
			into the infamous assertion failure at
			cg/schedule_vn.C:799.  Matthai, please take a
			look at this.

	dotproduct	The killer app!  Speedups better, breakevens
			better.  Nothing surprising here.

My travel plans have changed.  I'm leaving now and will be back on Dec. 22.

I hope you had a good trip!
--Brian


Date: Thu, 18 Dec 1997 20:06:36 -0800 (PST)
From: "Markus U. Mock" <mock@cs.washington.edu>
To: Matthai Philipose <matthai@cs.washington.edu>,
Subject: compiler version 3

Matthai,

have you compiled version 3 as checked in by Brian? I got unresolved
symbols and needed to copy some files from his directories that did
apparently not get checked in... 

	-- Markus 



Date: Sun, 21 Dec 1997 16:57:08 -0800 (PST)
From: chambers@chiwawa (Craig Chambers)
To: cecil@cs, melody@cs, spin-comp@cs
Subject: out

I've been out for a while, tending to Sylvia (who had an operation last
Thursday and has been in the hospital since) and my kids.  I'll probably
continue to be out for another week or so.  Sylvia hopefully will be coming
home before Christmas, but she'll still need lots of help around the house.
I'll try to read email, but only sporadically.

-- Craig

To: spin-comp@thistle.cs.washington.edu
Subject: I'm back
Date: Wed, 24 Dec 1997 23:48:42 PST
From: Brian Grant <grant@thistle.cs.washington.edu>

It will take a few days for me to get back on Seattle time.  I'll fill you
in on the ordeal later.  I plan be in on Monday.

--Brian

To: spin-comp@thistle.cs.washington.edu
Subject: meeting time this week?
Date: Mon, 29 Dec 1997 11:19:59 PST
From: Brian Grant <grant@thistle.cs.washington.edu>

Will we meet today, at another time this week, or not at all this week?

--Brian

Date: Mon, 29 Dec 1997 13:22:53 -0800 (PST)
From: chambers@klamath (Craig Chambers)
To: grant@cs.washington.edu, spin-comp@thistle.cs.washington.edu
Subject: Re: meeting time this week?

No meeting this week.

-- Craig

Date: Mon, 29 Dec 1997 13:27:15 -0800 (PST)
From: chambers@klamath (Craig Chambers)
To: cecil@cs, faculty@cs, melody@cs, spin-comp@cs
Subject: Sylvia is home!

Well, after getting sick Dec. 13, going in to the hospital Dec. 18, and
having two operations to combat her abdominal infection, Sylvia finally came
home this morning.  Thanks for all your good wishes, and the flowers really
lifted our spirits.  Sylvia will be recovering her strength and stamina for 
another month, but after that she should be completely back to normal.

-- Craig

To: spin-comp@thistle.cs.washington.edu
Subject: web page with updated performance numbers
Date: Mon, 29 Dec 1997 16:39:09 PST
From: Brian Grant <grant@thistle.cs.washington.edu>

Should we make this table public yet?  Have we made it public?  If the
committee will meet mid-January, we should do it soon.

--Brian

To: spin-comp@thistle.cs.washington.edu
Subject: latest numbers on web page
Date: Fri, 02 Jan 1998 17:05:36 PST
From: Brian Grant <grant@thistle.cs.washington.edu>

Except for mipsi, all of the benchmarks have been run with the breakeven-
lowering optimizations.  A few of the apps have slightly better speedups as
well.  Chebyshev's speedups are still lower, but not as low as before.  We
probably won't be able to squeeze much more speedup out of pow or dotproduct,
but we may have a little more to gain on binary and query.  In the long term,
pow should probably be dropped as a benchmark.  Matthai looked at the
generated instructions and found them to be nearly optimal, with about half
the instructions removed from the critical path, including three branches.
Yet, we get only about a 10% improvement in performance.  The reason appears
to be that the cost of one loop iteration is dominated by its multiply, and
the other (integer) instructions don't matter much.

Matthai removed extraneous branches from query, and that also had little
impact.

So, our speedups still aren't great for the `C benchmarks and probably won't
improve much soon.  We'll try to generate new numbers for mipsi this weekend.
We should probably decide what to write on the web page, then notify the
program committee.  Should we also link to the performance page from our
home page?

--Brian

Date: Sun, 4 Jan 1998 20:28:38 -0800 (PST)
From: chambers@klamath (Craig Chambers)
To: spin-comp@cs
Subject: meeting time?

We need to reschedule our meeting time for this quarter.  When?  I can't
meet before 3pm on MWF, and I can't meet T 12-1, Th 11-4:30, T 3:30-4:30.

-- Craig

Date: Sun, 4 Jan 1998 20:59:09 -0800
From: eggers@yakima (Susan Eggers)
To: spin-comp@cs, chambers@klamath
Subject: Re: meeting time?


Wed at (or after 3) is fine with me, as is Tuesday 2:30,
Tuesday mornings (although I would have to miss some meetings
then). 

Susan

Date: Sun, 4 Jan 1998 21:54:16 -0800 (PST)
From: "Markus U. Mock" <mock@cs.washington.edu>
To: Susan Eggers <eggers@yakima.cs.washington.edu>
cc: spin-comp@cs.washington.edu, chambers@klamath.cs.washington.edu
Subject: Re: meeting time?

Wed 3:30 or later (after 590L), Tuesday 2:30 work for me too, Tuesday and
Thursday mornings don't work, anything else than that would work too.


	-- Markus


Date: Sun, 4 Jan 1998 23:01:55 -0800
From: eggers@yakima (Susan Eggers)
To: spin-comp@thistle.cs.washington.edu, grant@cs.washington.edu
Subject: Re: latest numbers on web page


Why don't we discuss what to do the the numbers at our next meeting.

Susan

To: "Markus U. Mock" <mock@cs.washington.edu>
cc: Susan Eggers <eggers@yakima.cs.washington.edu>,
Subject: Re: meeting time? 
Date: Mon, 05 Jan 1998 08:06:52 PST
From: Brian Grant <grant@thistle.cs.washington.edu>

Tues and Wed afternoons are fine by me.  Wed might be better so we don't have
to worry about running into 519.

--Brian

To: spin-comp@franklin.cs.washington.edu
Subject: Meeting time
Date: Mon, 05 Jan 1998 11:13:03 PST
From: Matthai Philipose <matthai@franklin.cs.washington.edu>

I can't make it after 3:30 on Mondays and Wednesdays. Also, Tue 12:30-1:20 are 
Wed 2:30-3:20 out, in addition to the usual colloqium constraints.

Based on the constraints I've seen so far, Tue 2:30-3:20 seems to be the slot 
that works for everyone.
			Matthai


Date: Mon, 5 Jan 1998 11:23:53 -0800 (PST)
From: chambers@klamath (Craig Chambers)
To: spin-comp@franklin.cs.washington.edu, matthai@cs.washington.edu
Subject: Re: Meeting time

OK, let's do it T 2:30-3:30.  We can run long if there no colloq or we're
not going.

This Tuesday I have to leave at 3:15, to take Sylvia to get her stitches out
(we hope!).

-- Craig

Date: Mon, 5 Jan 1998 23:15:39 -0800
From: mock@cs.washington.edu (Markus U. Mock)
To: spin-comp@cs.washington.edu
Subject: Reachability  

There's a problem with the the BTA_Merge function as written in our
PEPM submission  with respect to reachability conditions:

It states:

IF this is a static merge THEN
   Merge(lvs, bta)
ELSE
   ...

This condition is independent of the divisions, however, a merge may
be static in one division and not static in another. example:

if (d)
  make_static(x);
else 
  make_static(x,y);

if (y)
   ...
else
   ...

M: /* merge is static in division {x,y} but dynamic in division {x} */

In a nutshell the modification of the BTAMerge rule that I have
implemented and which I am currently debugging does the following:

(1) at a merge sort incoming btas by their division
(2) compute mutual exclusion conditions and updated reachability
    conditions by combining the information of those btas that have
    the same division (after splitting the graph creating one for each
			     division only the information from the
			     same division will merge)
    call the set of resulting btas BTAS
(3) for each bta in BTAS compute out-division, out-info and
out-conditions as follows:
    a) out-conditions = in-conditions (they were already combined in
       step 2
    b) out-divisions are computed as in the old PEPM rule by
       forgetting dead vars
    c) the rule that computes which variables to drop at the merge is
       modified as follows: 
       before we dropped merged vars that were not polyvariantly
       specialized ({x1 .. xn} - pvs)
       NOW: if the merge is dynamic for the division: as before
            if the merge is static for the division: drop merged 
            vars that are neither polyvariantly specialized nor static
            on all incoming branches
                   ({x1, .. xn) - pvs - smv)
            Reason: variables that are static on all incoming branches
            have in fact only one reaching definition since the merge
            is static, and are therefore not discordant.



Here are more details of the rules [indices are a pain in email]:


bta is augmented to incorporate the reachability conditions:
BTA = Division -> DivisionInfo x ReachabilityConditions

BTAMerge computes bta = U btas is computed by combining incoming
divisions in the following way:

let btas = {(d1, i11, c11), (d1, i12, c12) .. (d1, d1n_1, c1n_1),
            (d2, d21, c21), (d2, i22, c22) .. (d2, i2n_2, c2_n2),
            ...
            (dm, im1, cm1), (dm, im2, cm2) .. (dm, imn_m, cmn_m)}

i.e. we sort the incoming btas by their division.
Since after splitting the graph for each division, only the same
divisions merge at a control flow merge, only the reachability
conditions for the same divisions need to be combined to compute
whether a merge is static, so

bta = {(d1, i11, c1), (d1, i12, c1) .. (d1, i1n_1, c1),
       (d2, i21, c2), (d2, i22, c2) .. (d2, i2n_2, c2).
       ...
       (dm, im1, cm), (dm, dm2, cm) .. (dm, imn_m, cm)}
 
where ci = ci1 v ci2 v .. cin_i 
The merge for division di is static iff 
bi := mutex(ci1, ci2, .. cin_i)

where mutex(..) tests whether the arguments are mutually exclusive.

Given bta the updated bta after merging is computed by modifying the BTA_Merge rule
as follows:

BTAMerge[[merge(x1, .. xn)]] lvs uvs mds sp btas =
  bta = as computed above
  Merge(lvs, {dout, iout, cout) |
       (dk, info, c) \in bta , and info = (si, prom, dis)
       pvs = {x1, .. xn} ^ PolySpecializationVars(d) ^ lvs 
       mvs = ({x1, .. xn} - pvs) ^ lvs  IF bk = false (merge in this
							     division
							     is
							     dynamic )
             ({x1, .. xn) -pvs - smv(k)) ^lvs IF bk=TRUE

             where smv(k) = ^ staticVars(info_kj), j = 1 .. nk
               i.e. smv(k) is the intersection of all variables that 
                            are static on all incoming branches when
                            computing the merge for division k.
                            These variables do not have to be
                            considered merged (mvs), since the merge
                            is static and are therefore subtracted
                            when computing mvs.

      
      cout = c 
      dout = ForgetDeadVars(uvs, d - {x,p') \in d| x \in mvs})
      iout = IF pvs = {} THEN (si - mvs, {}, {})  
              ELSE
                              ({v, (mp, {v})) | (v,pol) \in dout
                                 mp = if v \in pvs then
                                         MergeCachingPolicy(pol)
                                       else
                                         CachingPolicy(StaticVarInfo(i)(v))}, {}, pvs)})



Any comments?

	-- Markus

                                         
             









Date: Tue, 6 Jan 1998 09:57:05 -0800 (PST)
From: chambers@klamath (Craig Chambers)
To: spin-comp@cs.washington.edu, mock@cs.washington.edu
Subject: Re: Reachability

English:

>             if the merge is static for the division: drop merged 
>             vars that are neither polyvariantly specialized nor static
>             on all incoming branches

Math:

>                    ({x1, .. xn} - pvs - smv)

The English and the math do different things.  The English says this:

                     ({x1, .. xn} - (pvs intersect smv))

Which is right?

-- Craig

Date: Tue, 6 Jan 1998 10:05:07 -0800 (PST)
From: Markus Mock <mock@apex.cs.washington.edu>
To: Craig Chambers <chambers@klamath>
cc: spin-comp@cs.washington.edu
Subject: Re: Reachability

The math. 

	-- Markus

On Tue, 6 Jan 1998, Craig Chambers wrote:

> English:
> 
> >             if the merge is static for the division: drop merged 
> >             vars that are neither polyvariantly specialized nor static
> >             on all incoming branches
> 
> Math:
> 
> >                    ({x1, .. xn} - pvs - smv)
> 
> The English and the math do different things.  The English says this:
> 
>                      ({x1, .. xn} - (pvs intersect smv))
> 
> Which is right?
> 
> -- Craig
> 


Date: Tue, 6 Jan 1998 10:10:08 -0800 (PST)
From: chambers@klamath (Craig Chambers)
To: mock@apex.cs.washington.edu
Subject: Re: Reachability
Cc: spin-comp@cs.washington.edu

Actually, I think I was wrong, and your English and math do the same thing.
The set that's being computed is what to drop, and you correctly remove both
polyvariantly specialized and static values from the list of variables to drop.

Never mind.

-- Craig

> From mock@apex.cs.washington.edu  Tue Jan  6 10:05:11 1998
> Delivery-Date: Tue, 06 Jan 1998 10:05:12 PST
> Date: Tue, 6 Jan 1998 10:05:07 -0800 (PST)
> From: Markus Mock <mock@apex.cs.washington.edu>
> To: Craig Chambers <chambers@klamath>
> cc: spin-comp@cs.washington.edu
> Subject: Re: Reachability
> MIME-Version: 1.0
> 
> The math. 
> 
> 	-- Markus
> 
> On Tue, 6 Jan 1998, Craig Chambers wrote:
> 
> > English:
> > 
> > >             if the merge is static for the division: drop merged 
> > >             vars that are neither polyvariantly specialized nor static
> > >             on all incoming branches
> > 
> > Math:
> > 
> > >                    ({x1, .. xn} - pvs - smv)
> > 
> > The English and the math do different things.  The English says this:
> > 
> >                      ({x1, .. xn} - (pvs intersect smv))
> > 
> > Which is right?
> > 
> > -- Craig
> > 
> 
> 

Date: Tue, 6 Jan 1998 17:40:18 -0800
From: eggers@yakima (Susan Eggers)
To: spin-comp@cs
Subject: pldi paper

Can someone print our PLDI submission on my printer?  ps3ES.

Thanks, Susan

Date: Tue, 6 Jan 1998 17:44:32 -0800
From: eggers@yakima (Susan Eggers)
To: spin-comp@cs, eggers@yakima
Subject: Re: pldi paper


Never mind.  I found a copy in Craig's directory.

Susan

To: spin-comp@thistle.cs.washington.edu
Subject: comparison with gcc: bad news
Date: Tue, 06 Jan 1998 23:33:04 PST
From: Brian Grant <grant@thistle.cs.washington.edu>

gcc -O2 produces, in most cases, much faster code than Multiflow (up to 50%).
Only for chebyshev is it slower.  We turned off induction variable
simplification, loop unrolling, and insertion of conditional moves for all of
the apps, so that is certainly a factor.  I could post the numbers if people
are interested, but they are pretty bleak.  For many of the apps, we
have speedup less than 1 when using gcc as the baseline.

--Brian

Date: Wed, 7 Jan 1998 09:40:10 -0800
From: eggers@yakima (Susan Eggers)
To: spin-comp@thistle.cs.washington.edu, grant@cs.washington.edu
Subject: Re: comparison with gcc: bad news


Yuk.  I don't think it's worth a post.

Susan

Date: Wed, 7 Jan 1998 09:43:49 -0800
From: eggers@yakima (Susan Eggers)
To: spin-comp@thistle.cs.washington.edu, grant@cs.washington.edu
Subject: Re: comparison with gcc: bad news

> From grant@thistle.cs.washington.edu Tue Jan  6 23:33:14 1998
> Reply-To: grant@cs.washington.edu
> We turned off induction variable
> simplification, loop unrolling, and insertion of conditional moves for all of
> the apps, so that is certainly a factor.

I'm not sure what you meant here by "that is a factor".
Turning these on should make the gcc runs faster, meaning things would
be worse of these opts were part of the compile.

Susan

To: eggers@yakima (Susan Eggers)
cc: spin-comp@thistle.cs.washington.edu
Subject: Re: comparison with gcc: bad news 
Date: Wed, 07 Jan 1998 09:45:50 PST
From: Brian Grant <grant@thistle.cs.washington.edu>

>> I'm not sure what you meant here by "that is a factor".
>> Turning these on should make the gcc runs faster, meaning things would
>> be worse of these opts were part of the compile.

I meant they were turned off in Multiflow.  Matthai checked gcc's man page
and found that loop unrolling was also turned off for gcc, so that wasn't
actually a factor.

--Brian

Date: Wed, 7 Jan 1998 09:57:57 -0800
From: eggers@yakima (Susan Eggers)
To: eggers@yakima, grant@thistle.cs.washington.edu
Subject: Re: comparison with gcc: bad news
Cc: spin-comp@thistle.cs.washington.edu


I think we need to compare apples and apples, particularly if
we are trying to show that gcc is slower.  We've set up a situation
in which either we guarantee that it is not, and/or we are not sure
why.

Susan

To: spin-comp@thistle.cs.washington.edu
Subject: Shady `C Results?
Date: Thu, 08 Jan 1998 13:05:19 PST
From: Brian Grant <grant@thistle.cs.washington.edu>

We've looked more closely at TickC's implementation of pow.  The C code for
their baseline and their `C code are below.  Note that square is declared
as an int in the baseline, but base, the corresponding vspec in the `C
implementation, is a double.  We compiled the baseline on roughly the same
type of machine that they used for their benchmarks (Sparc 5) and found the
"square *= square" to be implemented by a software implementation of an
integer multiply, a call that requires around 16(?) cycles.  The double-
precision floating-point multiply used in their `C version requires only 6
cycles.

So, conversion of an incorrect and slow integer multiply to a faster
floating-point one could easily explain their speedup.

How do we handle this?

--Brian

double pow(double base, int exp) {
     int t, bit = 1;
     int square = base;
     double result = 1.0;

     while (bit <= exp) {
	  if (bit & exp)
	       result *= square;
	  bit = bit << 1;
	  square *= square;
     }
     return result;
}

dptr mkpow(int exp) {
     double vspec base = param(double,0);
     switch (exp) {
     case 0:
	  return compile(`{ return 1.; },double);
     case 1:
	  return compile(`{ return @base; },double);
     default:
     {
	  double vspec result = local( double);
	  void cspec squares = `{ @result = 1.; };
	  int t, bit = 2;

	  if (1 & exp)
	       squares = `{ @squares; @result *= @base; };
	  while (bit <= exp) {
	       squares = `{ @squares; @base *= @base; };
	       if (bit & exp)
		    squares = `{ @squares; @result *= @base; };
	       bit = bit << 1;
	  }
	  return compile(`{ @squares; return @result; },double);
     }
     }
}


Date: Thu, 8 Jan 1998 13:16:42 -0800 (PST)
From: chambers@klamath (Craig Chambers)
To: spin-comp@thistle.cs.washington.edu, grant@cs.washington.edu
Subject: Re: Shady `C Results?

How about asking them to explain their results, given our study, and ask them
to recompute a correct speed-up number for their system that we can quote?

-- Craig

> From grant@thistle.cs.washington.edu  Thu Jan  8 13:05:40 1998
> Delivery-Date: Thu, 08 Jan 1998 13:05:41 PST
> X-Mailer: exmh version 1.5.3 12/28/94
> Reply-To: grant@cs.washington.edu
> To: spin-comp@thistle.cs.washington.edu
> Subject: Shady `C Results?
> Mime-Version: 1.0
> Date: Thu, 08 Jan 1998 13:05:19 PST
> From: Brian Grant <grant@thistle.cs.washington.edu>
> 
> We've looked more closely at TickC's implementation of pow.  The C code for
> their baseline and their `C code are below.  Note that square is declared
> as an int in the baseline, but base, the corresponding vspec in the `C
> implementation, is a double.  We compiled the baseline on roughly the same
> type of machine that they used for their benchmarks (Sparc 5) and found the
> "square *= square" to be implemented by a software implementation of an
> integer multiply, a call that requires around 16(?) cycles.  The double-
> precision floating-point multiply used in their `C version requires only 6
> cycles.
> 
> So, conversion of an incorrect and slow integer multiply to a faster
> floating-point one could easily explain their speedup.
> 
> How do we handle this?
> 
> --Brian
> 
> double pow(double base, int exp) {
>      int t, bit = 1;
>      int square = base;
>      double result = 1.0;
> 
>      while (bit <= exp) {
> 	  if (bit & exp)
> 	       result *= square;
> 	  bit = bit << 1;
> 	  square *= square;
>      }
>      return result;
> }
> 
> dptr mkpow(int exp) {
>      double vspec base = param(double,0);
>      switch (exp) {
>      case 0:
> 	  return compile(`{ return 1.; },double);
>      case 1:
> 	  return compile(`{ return @base; },double);
>      default:
>      {
> 	  double vspec result = local( double);
> 	  void cspec squares = `{ @result = 1.; };
> 	  int t, bit = 2;
> 
> 	  if (1 & exp)
> 	       squares = `{ @squares; @result *= @base; };
> 	  while (bit <= exp) {
> 	       squares = `{ @squares; @base *= @base; };
> 	       if (bit & exp)
> 		    squares = `{ @squares; @result *= @base; };
> 	       bit = bit << 1;
> 	  }
> 	  return compile(`{ @squares; return @result; },double);
>      }
>      }
> }
> 
> 

To: maxp@lcs.mit.edu
cc: spin-comp@franklin.cs.washington.edu
Subject: Clarification on pow benchmark in the tcc distribution
Date: Thu, 08 Jan 1998 13:43:10 PST
From: Matthai Philipose <matthai@franklin.cs.washington.edu>

Max,
We're running our new dynamic compilation system on some of the 'C benchmarks for purposes of comparison, and noticed a minor error that seems to make a big performance difference in the pow benchmark. 

Basically, it seems that in the function "pow" below, the variable "square" should be declared as a double, just as the "base" vspec in mkpow is declared as a double. Otherwise the "square*=square" operation in pow seems to be generated as a software integer multiply, whereas the corresponding operation in mkpow, "@base *= @base", seems to be generated as a (much faster) hardware multiply. This makes it very difficult to compare the two in terms of the effect of dynamic compilation alone.

What's your take on this? If you agree that this is a problem, can you please make the required change (i.e. make square a double), re-run the pow benchmark and let us know the new speedup ASAP?
            Thanks,
            Matthai       


------------ Part of the code for pow.tc follows:

#include <stdio.h>	
#include "benchmark.h"

typedef double (*dptr)(double);

double pow(double base, int exp) {
     int t, bit = 1;
     int square = base;
     double result = 1.0;

     while (bit <= exp) {
	  if (bit & exp)
	       result *= square;
	  bit = bit << 1;
	  square *= square;
     }
     return result;
}

dptr mkpow(int exp) {
     double vspec base = param(double,0);
     switch (exp) {
     case 0:
	  return compile(`{ return 1.; },double);
     case 1:
	  return compile(`{ return @base; },double);
     default:
     {
	  double vspec result = local( double);
	  void cspec squares = `{ @result = 1.; };
	  int t, bit = 2;

	  if (1 & exp)
	       squares = `{ @squares; @result *= @base; };
	  while (bit <= exp) {
	       squares = `{ @squares; @base *= @base; };
	       if (bit & exp)
		    squares = `{ @squares; @result *= @base; };
	       bit = bit << 1;
	  }
	  return compile(`{ @squares; return @result; },double);
     }
     }
}


To: Matthai Philipose <matthai@cs.washington.edu>
cc: spin-comp@cs.washington.edu
Subject: Re: Clarification on pow benchmark in the tcc distribution 
Date: Fri, 09 Jan 1998 14:24:47 -0500
From: Massimiliano Poletto <maxp@cag.lcs.mit.edu>


Hi Matthai, sorry for the late reply.

What you point out is indeed a major error, and not only for the reason you
mention.  When comparing the dynamic code against lcc-generated static code,
the static code does contain a call to a software multiply routine.  This
certainly makes the comparison unfair, but I don't think it's a very big deal:
(1) it could be fixed without too much work by changing the tcc/lcc sparc back
end to emit hardware integer multiplies; (2) I don't give the comparison
against lcc too much importance: sure, lcc is the natural baseline for tcc, but
beating lcc is hardly a claim to fame.

The bigger problem in my opinion -- one that affects the comparison of dynamic
code to gcc-generated static code ("gcc -mv8" uses the hardware integer
multiplies on Sparc v8 and v9) -- is the extra code necessary to multiply
"result *= square" when result is a double and square is int.  Consider below
the code emitted by gcc for that multiplication when square is an int (marked
by "X"s) versus when square is a double (marked by "Y").  Ironically, the
reason I had square be an int in the first place was to allow gcc to emit a
hardware int multiply rather than float multiply.  Not a good idea, it turns
out.


pow, when "square" is an int:
        13520:  9c 03 bf 88        add          %sp, -120, %sp
        13524:  d0 3b a0 68        std          %o0, [%sp + 104]
        13528:  c9 1b a0 68        ldd          [%sp + 104], %f4
        1352c:  8b a0 1a 44        fdtoi        %f4, %f36
        13530:  84 10 20 01        mov          1, %g2
        13534:  17 00 00 df        sethi        %hi(0x37c00), %o3
        13538:  c1 1a e2 c0        ldd          [%o3 + 0x2c0], %f0
        1353c:  cb 23 a0 64        st           %f5, [%sp + 100]

        13540:  80 a0 80 0a        cmp          %g2, %o2
        13544:  14 80 00 0c        bg           0x13574
        13548:  c6 03 a0 64        ld           [%sp + 100], %g3

        1354c:  80 88 80 0a        andcc        %g2, %o2, %g0
        13550:  02 80 00 06        be           0x13568
        13554:  85 28 a0 01        sll          %g2, 1, %g2

X        13558:  c6 23 a0 64        st           %g3, [%sp + 100]
X        1355c:  c9 03 a0 64        ld           [%sp + 100], %f4
X        13560:  85 a0 19 04        fitod        %f4, %f2
X        13564:  81 a0 09 42        fmuld        %f0, %f2, %f0

        13568:  80 a0 80 0a        cmp          %g2, %o2
        1356c:  04 bf ff f8        ble          0x1354c
        13570:  86 58 c0 03        smul         %g3, %g3, %g3

        13574:  81 c3 e0 08        jmp          %o7 + 8
        13578:  9c 23 bf 88        sub          %sp, -120, %sp


pow, when "square" is a double:
        13520:  9c 03 bf 88        add          %sp, -120, %sp
        13524:  d0 3b a0 60        std          %o0, [%sp + 96]
        13528:  c9 1b a0 60        ldd          [%sp + 96], %f4
        1352c:  84 10 20 01        mov          1, %g2
        13530:  85 a0 00 24        fmovs        %f4, %f2
        13534:  07 00 00 df        sethi        %hi(0x37c00), %g3
        13538:  c1 18 e2 b0        ldd          [%g3 + 0x2b0], %f0

        1353c:  80 a0 80 0a        cmp          %g2, %o2
        13540:  14 80 00 09        bg           0x13564
        13544:  87 a0 00 25        fmovs        %f5, %f3

        13548:  80 88 80 0a        andcc        %g2, %o2, %g0
        1354c:  32 80 00 02        bne,a   0x13554

Y        13550:  81 a0 09 42        fmuld        %f0, %f2, %f0

        13554:  85 28 a0 01        sll          %g2, 1, %g2
        13558:  80 a0 80 0a        cmp          %g2, %o2
        1355c:  04 bf ff fb        ble          0x13548
        13560:  85 a0 89 42        fmuld        %f2, %f2, %f2

        13564:  81 c3 e0 08        jmp          %o7 + 8
        13568:  9c 23 bf 88        sub          %sp, -120, %sp


The results of changing "square" to a double are:

(1) dynamic code using icode is about 50% faster than lcc static code, but
~25-30% slower than gcc static code

(2) dynamic code using vcode is about the same speed as lcc static code, but
half as fast as gcc static code



More work ahead, I guess.  Thanks for the bug report.

max

To: spin-comp@franklin.cs.washington.edu
Subject: Five sentences on comparing DC numbers across machines
Date: Fri, 09 Jan 1998 13:27:45 PST
From: Matthai Philipose <matthai@franklin.cs.washington.edu>

Folks,
Below I've tried to summarize why processor implementation makes a big difference to DC speedup. It's down to five lines + a line pointing to the detailed analysis. It can probably be made shorter, and any feedback will be great.

       Thanks,
       Matthai


------------ Summary:
Speedups due to dynamic compilation are heavily affected by the issue width and instruction latencies of the processor on which the dynamically computed code runs. In particular, on a multi-issue machine, if the instructions removed by dynamic compilation are not on the critical path of a computation, the total running time of the computation may not be affected. 

In the "pow" kernel, all inner-loop instructions except a float multiply can be removed by dynamic compilation. Unfortunately, on the Alpha 21064, the latency of the float multiply (6 cycles) determines the critical path through the loop. Removing the other instructions therefore does not make the loop any faster.

We provide a more detailed analysis of the interaction between issue-width, instruction latency and speedup due to dynamic compilation for the "pow" benchmark at http://www.cs.washington.edu/research/dyncomp/arch-note.html.


--------- This is the more detailed analysis:

Speedups due to dynamic compilation are heavily affected by the issue
width and instruction latencies of the processor on which the
dynamically computed code runs. In particular, on a multi-issue
machine, if the instructions removed by dynamic compilation are not
on the critical path of a computation, the total running time of the
computation may not be affected. 

Consider the following loop schedule (the core of the pow benchmark)
running on the dual-issue 21064, where a floating-point multiply has a
latency of six cycles. Each line represents a cycle of the schedule,
and contains a maximum of two instructions that can be issued
together. All instructions except the multiplies have a one-cycle
latency. The exact functioning of the loop is unimportant, but note
that the multiply M is data-dependent on itself.

L0:	and t1, a1, t0

	beq t0, L1       <--branch B1

	mult f0, f16, f0

L1:	addq t1, t1, t0 

	addl t0, zero, t1

	cmple t1, a1, t0

	mult f16, f16, f16 <--multiply M	bne t0, L0 <--branch B2


According to this schedule, the loop body takes a minimum of 6 cycles to
execute (this is the case if branch B1 is taken).  Even if every
instruction in the body except M were removed (as dynamic
compilation could), the body would still take 6 cycles to execute,
since M has a dependence of latency 6 on itself. On this machine,
therefore, dynamic compilation would not give a speedup.

On the other hand, if the loop ran on a single-issue machine, the
minimum latency of the above schedule would be 7 cycles, since branch
B2 would issue in a cycle of its own. Removing all instructions except
M would result in a loop of latency 6 cycles (as before), giving a
speedup of 7/6 (= 1.17x) for dynamic compilation. On the other hand,
if multiplies took only 3 cycles (e.g. this is the latency for single 
precision floating point multiplies on the MicroSparc II used in the tcc 
experiments)instead of 6, the speedup due to dynamic compilation would 
double to 7/3 ( = 2.34x).


To: spin-comp@thistle.cs.washington.edu
Subject: about this journal: Theoretical Computer Science
Date: Sun, 11 Jan 1998 09:54:18 PST
From: Brian Grant <grant@thistle.cs.washington.edu>

Hmmm......



AIMS AND SCOPE

Theoretical Computer Science is mathematical and abstract in spirit,
but it derives its motivation from practical and everyday
computation. Its aim is to understand the nature of computation and,
as a consequence of this understanding, provide more efficient
methodologies. All papers introducing or studying mathematical, logic
and formal concepts and methods are welcome, provided that their
motivation is clearly drawn from the field of computing.

Papers published in Theoretical Computer Science are grouped in two
sections according to their nature. One section `Algorithms, automata,
complexity and games' is devoted to the study of algorithms and their
complexity using analytical, combinatorial or probabilistic
methods. It includes the whole field of abstract complexity (i.e. all
the results about the hierarchies that can be defined using Turing
machines), the whole field of automata and language theory (including
automata on infinite words and infinitary languages), the whole field
of geometrical (graphic) applications and the whole field of
measurement of system performance using statistical methods. The
subsection Mathematical Games is devoted (but not restricted) to the
mathematical and computational analysis of games. It also covers
connections or applications of games to areas such as complexity,
graph and matroid theory, networks, coding theory, logic and surreal
numbers.

The other section, `Logic, semantics and theory of programming', is
devoted to formal methods to check properties of programs or implement
formally described languages; it contains all papers dealing with
semantics of sequential and parallel programming languages. All formal
methods treating these problems are published in this section,
including rewriting techniques, abstract data types, automatic theorem
proving, calculi such as SCP or CCS, Petri nets, new logic calculi and
developments in categorical methods.




To: spin-comp@thistle.cs.washington.edu
Subject: should we submit to Theoretical Computer Science?
Date: Sun, 11 Jan 1998 13:34:49 PST
From: Brian Grant <grant@thistle.cs.washington.edu>

After reading the somewhat intimidating statement of purpose for the journal,
I decided to look at another special issue for perspective.  Selected papers
from PLILP `91 were published 4 years later in 1995.  Of the 41 original
papers in PLILP `91, only 5 appeared in TCS.  All were equation-heavy
theory papers.  None of the more practical papers from PLILP were selected.
Also, all of the papers were 25-30 pages in length, about twice as long as
the original papers.

What does this say about our planned submission to the TCS special issue?

Given that:
	-- our chance of acceptance appears low,
	-- none of us seems willing to put in a significant amount of work
	   into this, and
	-- the visibility of a publication in this journal is in question
	   (theory journal, European publication, a few years from now)
I
I recommend that we seriously reconsider the decision to prepare a submission.
What do you think?

--Brian

To: spin-comp@thistle.cs.washington.edu
Subject: Re: should we submit to Theoretical Computer Science? 
Date: Sun, 11 Jan 1998 14:13:27 PST
From: Brian Grant <grant@thistle.cs.washington.edu>

Our odds for PEPM may be somewhat better than the PLILP example indicated.
PEPM had only 17 papers, of which only perhaps 5-7 are clearly better suited
to the journal than ours.  Also, reformatting of our paper to the
single-column format of the journal could very well give us much of the
needed page-count expansion.

Is it possible to ask Charles what he thinks of our chances?

Anyway, something to think about.
--Brian

Date: Sun, 11 Jan 1998 18:24:36 -0800
From: eggers@yakima (Susan Eggers)
To: grant@cs.washington.edu, spin-comp@thistle.cs.washington.edu
Subject: Re:  should we submit to Theoretical Computer Science?

Why don't we discuss all this on Tuesday?

Susan

To: spin-comp@thistle.cs.washington.edu
Subject: explaining architectural differences on results page
Date: Mon, 12 Jan 1998 17:27:17 PST
From: Brian Grant <grant@thistle.cs.washington.edu>

I put a slightly editted version of Matthai's explanation of the
architectural impact on pow on the results page.  Please look at it
before the meeting:

http://www.cs.washington.edu/research/dyncomp/Latest_Results.html

--Brian

Date: Tue, 13 Jan 1998 13:54:38 -0800 (PST)
From: chambers@klamath (Craig Chambers)
To: matthai@cs.washington.edu
Subject: Re: TOPLAS review
Cc: spin-comp@cs

It's not due any specific time other than as soon as feasible.  I think the
by end of this month should be the target.

-- Craig

> From matthai@franklin.cs.washington.edu  Tue Jan 13 11:43:34 1998
> Delivery-Date: Tue, 13 Jan 1998 11:43:35 PST
> To: chambers@franklin.cs.washington.edu
> Subject: TOPLAS review
> Reply-to: Matthai Philipose <matthai@cs.washington.edu>
> Mime-Version: 1.0
> Date: Tue, 13 Jan 1998 11:43:33 PST
> From: Matthai Philipose <matthai@franklin.cs.washington.edu>
> 
> Craig,
> When's the review of the 'C toplas paper due?
> 			Matthai
> 
> ps: I've placed a copy of the paper in your mailbox.
> 

To: spin-comp@thistle.cs.washington.edu
Subject: public benchmark results
Date: Tue, 13 Jan 1998 17:21:53 PST
From: Brian Grant <grant@thistle.cs.washington.edu>

I made a public version of the benchmarks page.  There is a link from our
homepage.  We'll wait for comment before notifying the Tempo and TickC groups.

--Brian

To: spin-comp@thistle.cs.washington.edu
Subject: TCS paper progress
Date: Thu, 15 Jan 1998 09:16:26 PST
From: Brian Grant <grant@thistle.cs.washington.edu>

I think I've done everything on my list of essential changes, and a couple
other minor things.  The current draft is in the same place as I previously
announced:

	/afs/cs/project/dyncomp/grant/Papers/jtcs98/dc.doc

We need to get cracking on the BTA changes, because they'll take a while to
debug, and the big example, because it will require changes throughout
the whole text.  Markus, Matthai: it seems that this paper should have your
highest priority now since the deadline is near.  Better to get it over with,
in any case.

I think we should consider doing two optional things:

	1) Clustering proof: Matthai said it was easy to describe and I
	   remember him even having written it up already.

	2) Linearization algorithm: we previously promised to include it in
	   an expanded version of the paper and lack of space is no longer an
	   excuse.  I'll think about the algorithm in my spare moments.

--Brian

Date: Thu, 15 Jan 1998 15:03:47 -0800 (PST)
From: chambers@klamath (Craig Chambers)
To: spin-comp@cs
Subject: draft note to Cooper

Here's the email I'd like to send to Cooper.  Comments?

-- Craig


Hi, Keith.  My group submitted a paper to PLDI on dynamic compilation
("DyC: An Expressive, Annotation-Based Dynamic Compiler for C") in which we
made some promises about improvements we were going to make in our system to
1) reduce the run-time cost of dynamic code generation, and 2) generate better
dynamic code.  I just wanted to let you know that we've done this work, 
for example reducing our run-time cost by between 30% and a factor of 7.
If you or any of the referees want to check on our promises, we've put updated
numbers and a detailed discussion of the results on a web page:
http://www.cs.washington.edu/research/dyncomp/arch-note.html.

Thanks.

-- Craig Chambers

To: chambers@klamath (Craig Chambers)
cc: spin-comp@thistle.cs.washington.edu
Subject: Re: draft note to Cooper 
Date: Thu, 15 Jan 1998 15:09:55 PST
From: Brian Grant <grant@thistle.cs.washington.edu>

Sounds good, harmless.  Please use the following URL:

http://www.cs.washington.edu/research/dyncomp/Latest_Results.html

--Brian

Date: Thu, 15 Jan 1998 15:16:13 -0800 (PST)
From: chambers@klamath (Craig Chambers)
To: keith@cs.rice.edu
Subject: note on PLDI submission
Cc: spin-comp@cs

Hi, Keith.  My group submitted a paper to PLDI on dynamic compilation
("DyC: An Expressive, Annotation-Based Dynamic Compiler for C") in which we
made some promises about improvements we were going to make in our system to
1) reduce the run-time cost of dynamic code generation, and 2) generate better
dynamic code.  I just wanted to let you know that we've done this work, 
for example reducing our run-time cost by between 30% and a factor of 7.
If you or any of the referees want to check on our promises, we've put updated
numbers and a detailed discussion of the results on a web page:
http://www.cs.washington.edu/research/dyncomp/Latest_Results.html.

Thanks.

-- Craig Chambers

Date: Thu, 15 Jan 1998 17:12:13 -0800
From: eggers@yakima (Susan Eggers)
To: spin-comp@thistle.cs.washington.edu, grant@cs.washington.edu
Subject: Re: public benchmark results


some of it strikes me as a little detailed for public consumption,
where public consumption at this point is someone on the PLDI committee.
In particular, I would scratch the details on measuring instruction
overhead (it sounds convoluted and that we really don't know what the
correct measurement is) and the reference to Max and his personal
correspondence.

Susan

Date: Thu, 15 Jan 1998 22:05:27 -0800 (PST)
From: "Markus U. Mock" <mock@cs.washington.edu>
To: spin-comp@cs.washington.edu
Subject: Reachability Conditions checked in

I've checked in the implementation of reachability conditions which works
fine on our regression test suite. 

I also found the bug in the BTA that made the register allocated
interpreter fail an assertion in the bta (spurious equiv-vars info was
used). It now runs through the bta but crashes the compiler when trying to
compile it all the way through. I'll continue to look into that but also
start on the paper on Friday.


	-- Markus 



To: spin-comp@thistle.cs.washington.edu
Subject: Consel wants copy of PLDI submission
Date: Fri, 16 Jan 1998 07:41:24 PST
From: Brian Grant <grant@thistle.cs.washington.edu>

Any objections?  Should we make any improvements before sending it (e.g.,
error corrections, the new numbers, drop in discussion from web page, etc.)?

--Brian

Date: Fri, 16 Jan 1998 10:03:07 -0800
From: eggers@yakima (Susan Eggers)
To: spin-comp@thistle.cs.washington.edu, grant@cs.washington.edu
Subject: Re: Consel wants copy of PLDI submission

I like the idea of making improvements first.

Susan

Date: Fri, 16 Jan 1998 10:41:48 -0800 (PST)
From: chambers@klamath (Craig Chambers)
To: spin-comp@thistle.cs.washington.edu, grant@cs.washington.edu,
Subject: Re: public benchmark results


> From eggers@yakima  Thu Jan 15 17:12:17 1998
> Delivery-Date: Thu, 15 Jan 1998 17:12:18 PST
> Date: Thu, 15 Jan 1998 17:12:13 -0800
> From: eggers@yakima (Susan Eggers)
> To: spin-comp@thistle.cs.washington.edu, grant@cs.washington.edu
> Subject: Re: public benchmark results
> 
> 
> some of it strikes me as a little detailed for public consumption,
> where public consumption at this point is someone on the PLDI committee.
> In particular, I would scratch the details on measuring instruction
> overhead (it sounds convoluted and that we really don't know what the
> correct measurement is) and the reference to Max and his personal
> correspondence.
> 
> Susan
> 

Are you talking about the page for the PC members, or the public page?

I think the reference to Max is important for the PC; it explains one big
difference in speed-up numbers.

-- Craig

Date: Fri, 16 Jan 1998 10:42:24 -0800 (PST)
From: chambers@klamath (Craig Chambers)
To: spin-comp@thistle.cs.washington.edu, grant@cs.washington.edu,
Subject: Re: Consel wants copy of PLDI submission


> From eggers@yakima  Fri Jan 16 10:03:16 1998
> Delivery-Date: Fri, 16 Jan 1998 10:03:17 PST
> Date: Fri, 16 Jan 1998 10:03:07 -0800
> From: eggers@yakima (Susan Eggers)
> To: spin-comp@thistle.cs.washington.edu, grant@cs.washington.edu
> Subject: Re: Consel wants copy of PLDI submission
> 
> I like the idea of making improvements first.
> 
> Susan
> 

Alternatively, we could send it along with a reference to our web page.

I'm guessing that, given our other paper-writing obligations, we won't be
making improvements to the submission for a while.

-- Craig

Date: Fri, 16 Jan 1998 10:49:47 -0800
From: eggers@yakima (Susan Eggers)
To: spin-comp@thistle.cs.washington.edu, grant@cs.washington.edu,
Subject: Re: public benchmark results


I was talking about how it was said, not that we should omit discussing
an error in a 'C results.

Susan

To: chambers@klamath (Craig Chambers)
cc: spin-comp@thistle.cs.washington.edu
Subject: Re: Consel wants copy of PLDI submission 
Date: Fri, 16 Jan 1998 14:21:35 PST
From: Brian Grant <grant@thistle.cs.washington.edu>

>> > I like the idea of making improvements first.
>> > Susan
>> 
>> Alternatively, we could send it along with a reference to our web page.
>> I'm guessing that, given our other paper-writing obligations, we won't be
>> making improvements to the submission for a while.
>> -- Craig

I could make a couple of the easy fixes (typos, numbers) and then send it
to him.  I'll tell him about the web page now.

--Brian

To: eggers@yakima (Susan Eggers)
cc: spin-comp@thistle.cs.washington.edu
Subject: Re: public benchmark results 
Date: Fri, 16 Jan 1998 14:31:42 PST
From: Brian Kris Grant <grant@june.cs.washington.edu>

>> I was talking about how it was said, not that we should omit discussing
>> an error in a 'C results.
>> Susan

Have you looked at the page today?  I removed the complicated discussion
of the overhead, but did not change the `C / Max comment.  How should we
make that comment? The file is at:
/projects/unisw/DynComp/www/Latest_Results.html
Feel free to edit the text.  I have to go now, but will check my e-mail
again in a couple hours.

--Brian

Date: Mon, 19 Jan 1998 17:06:26 -0800 (PST)
From: Markus Mock <mock@apex.cs.washington.edu>
To: spin-comp@apex.cs.washington.edu
Subject: Re: TCS paper progress

I've updated the paper with the fixed bta equations, including the
demotions. Please take a look:
/afs/cs.washington.edu/project/dyncomp/grant/Papers/jtcs98/dc-mm.doc
I'll start with the section on bta problems, naming etc tomorrow.


	-- Markus


To: spin-comp@franklin.cs.washington.edu
Subject: put in the PLDI figs into tcs paper
Date: Mon, 19 Jan 1998 17:27:46 PST
From: Matthai Philipose <matthai@franklin.cs.washington.edu>

I've put the figures from the pldi example into the tcs paper. These include the interpreter example, its conditional specialization variation, the program to be interpreted, the program after dynamic compilation, the program after register allocation. The examples section still needs to be reworded to talk about the new example and the units picture needs to be re-done to refer to the interpreter example. All the figures in the document need re-numbering and some re-alignment.

I also placed my one-paragraph argument of why the clustering algo produces as few clusters as possible in the clustering section, with change bars on. 

All this is in:
/afs/cs/project/dyncomp/grant/Papers/jtcs98/dc.doc
			Matthai

Date: Tue, 20 Jan 1998 11:37:40 -0800
From: eggers@yakima (Susan Eggers)
To: spin-comp@apex.cs.washington.edu, mock@apex.cs.washington.edu
Subject: Re: TCS paper progress


I'd prefer to read it as a whole -- once all the sections have been
put in.  So whoever is the last to treak it, could you say this?

Susan

Date: Wed, 21 Jan 1998 12:45:13 -0800 (PST)
From: chambers@klamath (Craig Chambers)
To: spin-comp@cs
Subject: Tempo workshop

FYI.  I'll be in France then visiting Consel.  Or at least I thought I was
until I got this message.  Maybe Consel is pulling a disappearing trick again?

-- Craig


----- Begin Included Message -----

From Renaud.Marlet@compose.irisa.fr  Wed Jan 21 08:28:17 1998
Delivery-Date: Wed, 21 Jan 1998 08:28:18 PST
From: Renaud Marlet <Renaud.Marlet@irisa.fr>
Date: Wed, 21 Jan 1998 17:28:05 +0100
To: chambers@cs.washington.edu

Dear Craig,

We are pleased to invite you to the first Tempo workshop that will
be held at OGI (Portland, Oregon), April 1-3 1998.  The aim of this
workshop is to present a three-day tutorial on Tempo, our partial
evaluator for C programs, and its applications to real size
programs.

This workshop is the culmination of a three-year research project
at IRISA and in collaboration with OGI.  Tempo has been used to
dramatically improve the performance of a wide range of commodity
operating systems components, including Sun's RPC, Unix signal
delivery, and the Berkeley packet filter.  Tempo has also been
successfully applied to scientific programs, interpreters and
software engineering.

Specialization is an approach aimed at reconciling generality and
performance.  It is based on a program transformation technique called
partial evaluation which consists in adapting programs with respect to
a known context.  Exploiting the context allows a general system to be
instantiated for a particular environment.  The instantiated system is
optimized in the sense that all the operations that depended on the
context have been performed.

During the workshop we will make available the first public release of
Tempo.  Attendees will be given a full Tempo package.  More information
on specialization, partial evaluation and Tempo can be found at URL:
  http://www.irisa.fr/compose

A preliminary program of the workshop is listed below.  Workshop
registration fee and local arrangements are to be announced. More
information about the workshop will be available at URL:
  http://www.irisa.fr/compose/tempo/workshop/

If you are interested, please send us a mail (to compose-contact@irisa.fr)
before the end of January, because of limited attendance.  We look forward
to seeing you, or one of your colleagues/students in April.

Charles Consel
Renaud Marlet
Gilles Muller

-----------------------------------------------------------
IRISA                      E-mail:  compose-contact@irisa.fr   
Campus de Beaulieu         Tel :    02 99 84 72 06
35042 RENNES CEDEX         Fax :    02 99 84 71 71
http://www.irisa.fr/compose
-----------------------------------------------------------



------------------------------------------------------------
		TEMPO'98: Preliminary Program
------------------------------------------------------------

-------------------------------------
- Introduction to Partial Evaluation
-------------------------------------

        * The idea

        * An example

        * Definition of PE

        * Applications

        * Principles of PE

        * State of the art

------------------------------------------------
- How to go about partially evaluating a program
------------------------------------------------

        * Identifying specialization opportunities

        * Specializing

        * Managing:
                . Invariants (stable/unstable)
                . Specialized code

        * Measuring the effect of specialization

-------------------
- Tutorial on Tempo
-------------------

        * Overview of Tempo

        * Compile-time specialization

        * Run-time specialization

        * Advanced features

--------------
- Lab Sessions
--------------

	* Various programs will be examined.

-------------------
- Research Projects
-------------------

        * Operating systems

        * Domain-specific languages

	* Software architectures


The workshop will end at 18:00 on the third day, after a open
discussion where participants will be able to express ideas and
have feed back on possible applications of Tempo in their area
of work.



----- End Included Message -----


Date: Wed, 21 Jan 1998 13:15:13 -0800
From: eggers@yakima (Susan Eggers)
To: spin-comp@cs, chambers@klamath
Subject: Re: Tempo workshop


You all do remember that Consel decided to go to MIT the week I
was visiting him.  :-)

I got one of these too.  Craig and I are chewing over whether it
would be worthwhile to send one of you.  Does it sound too elementary,
or would it give us a better feel for comparing our work to theirs.

Susan

To: eggers@yakima (Susan Eggers)
cc: spin-comp@thistle.cs.washington.edu
Subject: Re: Tempo workshop 
Date: Wed, 21 Jan 1998 15:39:32 PST
From: Brian Grant <grant@thistle.cs.washington.edu>

>> Does it sound too elementary,
>> or would it give us a better feel for comparing our work to theirs.

Most of the workshop sounds boring.  We might pick up a few tidbits of how
Tempo is used with Synthetix, and possibly a few features not mentioned
(at least in detail) in their papers.  However, we don't need the intro to
PE, the intro to Tempo, or a recap of their recent summary papers.  Obviously,
the main thing we'd get out of it is Tempo itself, but the rest seems like
a waste of time.

--Brian


To: spin-comp@thistle.cs.washington.edu
Subject: sent fixed up PLDI submission to Consel
Date: Thu, 22 Jan 1998 12:21:37 PST
From: Brian Grant <grant@thistle.cs.washington.edu>

I fixed typos and other minor errors in our PLDI submission, dropped in our
latest numbers, and put in a reference to the discussion of the results on
our web page.  This version of the submission can be found at:
/afs/cs/project/dyncomp/grant/Papers/pldi98/final.doc

I just sent a copy of this version to Consel with a warning that we
haven't had time to make all of the corrections and additions we would like
and a request that he not distribute it outside his group.

--Brian

To: spin-comp@franklin.cs.washington.edu
Subject: Draft of TCS paper
Date: Fri, 23 Jan 1998 14:22:03 PST
From: Matthai Philipose <matthai@franklin.cs.washington.edu>

A draft of the TCS paper is now available in:
	~grant/Papers/jtcs98/dc.doc

on the gws machines.
		Matthai

Date: Fri, 23 Jan 1998 14:27:11 -0800 (PST)
From: Markus Mock <mock@apex.cs.washington.edu>
To: Matthai Philipose <matthai@cs.washington.edu>
cc: spin-comp@franklin.cs.washington.edu
Subject: Re: Draft of TCS paper

Actually it's in:

/afs/cs.washington.edu/project/dyncomp/grant/Papers/jtcs98/dc.doc,
I also put a postscript version dc.ps there.


	-- Markus



Date: Fri, 23 Jan 1998 15:54:50 -0800
From: eggers@yakima (Susan Eggers)
To: matthai@cs.washington.edu, mock@apex.cs.washington.edu
Subject: Re: Draft of TCS paper
Cc: spin-comp@franklin.cs.washington.edu


Matthai also pointed me to a 3rd location.
Can one of you get back with the one I'm really supposed to read?

Susan

Date: Mon, 26 Jan 1998 12:03:18 -0800
From: eggers@yakima (Susan Eggers)
To: spin-comp@cs
Subject: forgot to say to the whole group

I have the lock on the paper.

Susan

To: eggers@yakima (Susan Eggers)
cc: spin-comp@thistle.cs.washington.edu
Subject: Re: forgot to say to the whole group 
Date: Mon, 26 Jan 1998 12:08:10 PST
From: Brian Grant <grant@thistle.cs.washington.edu>

I have made modifications to the master copy under AFS.  If there is another
copy, perhaps we should make it the master copy?  Anyway, I made changes to
sections 7 & 8 in /afs/cs/project/dyncomp/grant/Papers/jtcs98/dc.doc.

--Brian


Date: Mon, 26 Jan 1998 13:25:53 -0800 (PST)
From: chambers@klamath (Craig Chambers)
To: spin-comp@cs
Subject: TOPLAS 1940

?

----- Begin Included Message -----

From toplas@cs.umd.edu  Mon Jan 26 12:36:29 1998
Delivery-Date: Mon, 26 Jan 1998 12:36:30 PST
Action: remind
To: chambers@cs.washington.edu (Craig Chambers)
Subject: TOPLAS 1940
Date: Mon, 26 Jan 1998 15:36:24 -0500
From: ACM TOPLAS <toplas@cs.umd.edu>

Please let me know the status of your review for this paper as soon
as possible.

Thanks,
Yvette


NUMBER 1940
TITLE 'C and tcc: A language and Compiler for Dynamic Code Generation
AUTHOR Massimilano Poletto, Wilson C. Hsieh, Dawson R. Engler, and
M. Frans Kaasshoek



----- End Included Message -----


Date: Mon, 26 Jan 1998 14:02:52 -0800
From: eggers@yakima (Susan Eggers)
To: spin-comp@cs
Subject: my pass over the paper

Mostly what I did was try to get the language less formal, by:
	using the active voice more.
	eliminating redundant words and phrases.
	changing participles to infinitives or something else.
	breaking up run-on sentences into several, simpler ones.

I left a couple of markers in places where someone else should make the call.

Because this is going so slowly, I've written what I've done (sections
1 and 2) in /tmp_mnt/homes/gws/matthai/papers/tcs/98/sections12.doc.

I did not check any figures.

Susan

Date: Mon, 26 Jan 1998 14:55:10 -0800
From: eggers@yakima (Susan Eggers)
To: spin-comp@cs
Subject: sections 1-3

sections12.doc and section3.doc are in Matthai's directory.

Susan

Date: Mon, 26 Jan 1998 15:17:50 -0800
From: eggers@yakima (Susan Eggers)
To: spin-comp@cs, eggers@yakima
Subject: Re: sections 1-3


A changed section 4, along with the previous sections, is in
sections14.doc.

Date: Mon, 26 Jan 1998 16:55:31 -0800
From: eggers@yakima (Susan Eggers)
To: spin-comp@cs, eggers@yakima
Subject: Re: sections 1-3

A changed section 5, along with the previous sections, is in
sections15.doc.

Date: Tue, 27 Jan 1998 01:13:15 -0800
From: mock@cs.washington.edu (Markus U. Mock)
To: spin-comp@cs.washington.edu
Subject: Register Allocation works

I finally managed to get the little interpreter that we used as an
example in our PLDI submission through our system with register
allocation done at the source code. 

First the good news: in the produced source code the operations on the
register array have been register allocated.

The bad news is, that the speedup compared to the original unhacked C
program improves only minimally by about 5% to a total of
3.85 (3.66 w/o register allocation).
However, the code that we generate is far from optimal, there are lots
of unnecessary branches and some register moves that we could probably
remove, which may improve speedup.

So here more details:
1) How the source code was rewritten
2) How the produced object code looks like
3) What timings I got and how I timed

---------------------------------------------------------------------
1) Source Code

original in: 

/afs/cs.washington.edu/project/dyncomp/mock/DyC/regression/interpreter/interpreter.DyC
rewritten:

/afs/cs.washington.edu/project/dyncomp/mock/DyC/regression/interpreter-regs2/interpreter-regs2.DyC


I allocated r1, r2, and r31 that are the 3 registers used in the
factorial program to registers as follows:

essentially a reference to reg[i] was replaced by	
	switch(i) {
	case 1: temp = r1; break;
	case 2: temp = r2; break
	case 31: temp = r31;break
	default: temp = reg[i]
	}
	
(for rvalues) and lvalues (eg reg[i] in  reg[i] = expr)
as follows:

	temp = expr;
	switch(i) {
	case 1: r1 = temp; break;
	case 2: r2 = tempt; break;
	case 31: r31 = temp; break;
	default: reg[i] = temp; break;
	}

for example:

reg[rt] = offset;

was replaced by
      
      trt = offset;
      switch(rt) {
      case 1: r1 = trt; break;
      case 2: r2 = trt; break;
      case 31: r31 = trt; break;
      default: reg[rt] = trt; break;
      }


In addition, instead of doing a switch in each case of the interpreter
Opcode switch, I hoisted teh references to reg[rt], reg[rs] and
reg[rd]. Take a  look at the source code for details.

----------------------------------------------------------------
2) Object Code:

This is the opbject code produces for the register-allocated version.

(In the paper we show the optimal result as:
ldl r1, 416(sp)  # reg[1] = arg 
lda r2, 1(zero)  # LI r31, 1 
lda r3, 0(zero)  # LI r2, 0 
L0: cmpeq r1, r3, r25 # IF_GOTO r1, r2, L1 
bne r25, L1 
mull r1, r2, r2 # MUL r31, r1, r31 
lda r1, -1(r1)  # SUBI r1, r1, 1 
br L0 # GOTO L0 
L1: or r2, zero, r0 # RET ldq ra, 128(sp) 
fnop lda sp, 544(sp) 
ret zero, (ra), 1



0x1400172e0 <DyCRT_CodeSpace+32>:	
    	a05e0170	ldl	t1, 368(sp)
0x1400172e4 <DyCRT_CodeSpace+36>:	
    	a01e0150	ldl	v0, 336(sp)
0x1400172e8 <DyCRT_CodeSpace+40>:	
    	a03e0158	ldl	t0, 344(sp)
0x1400172ec <DyCRT_CodeSpace+44>:	
    	a71e0178	ldq	t10, 376(sp)
0x1400172f0 <DyCRT_CodeSpace+48>:	
    	a3780000	ldl	t12, 0(t10)
0x1400172f4 <DyCRT_CodeSpace+52>:	
    	441f0419	or	v0, zero, t11
0x1400172f8 <DyCRT_CodeSpace+56>:	
    	c3e00000	br	 0x1400172fc <DyCRT_CodeSpace+60>
0x1400172fc <DyCRT_CodeSpace+60>:	
    	201f0001	lda	v0, 1(zero)
0x140017300 <DyCRT_CodeSpace+64>:	
    	c3e00000	br	 0x140017304 <DyCRT_CodeSpace+68>
0x140017304 <DyCRT_CodeSpace+68>:	
    	a3780000	ldl	t12, 0(t10)
0x140017308 <DyCRT_CodeSpace+72>:	
    	443f0419	or	t0, zero, t11
0x14001730c <DyCRT_CodeSpace+76>:	
    	c3e00000	br	 0x140017310 <DyCRT_CodeSpace+80>
0x140017310 <DyCRT_CodeSpace+80>:	
    	203f0000	lda	t0, 0(zero)
0x140017314 <DyCRT_CodeSpace+84>:	
    	c3e00000	br	 0x140017318 <DyCRT_CodeSpace+88>
0x140017318 <DyCRT_CodeSpace+88>:	
    	443f041b	or	t0, zero, t12
0x14001731c <DyCRT_CodeSpace+92>:	
    	c3e00000	br	 0x140017320 <DyCRT_CodeSpace+96>
0x140017320 <DyCRT_CodeSpace+96>:	
    	445f0419	or	t1, zero, t11
0x140017324 <DyCRT_CodeSpace+100>:	
    	c3e00000	br	 0x140017328 <DyCRT_CodeSpace+104>
0x140017328 <DyCRT_CodeSpace+104>:	
    	437905b9	cmpeq	t12, t11, t11
0x14001732c <DyCRT_CodeSpace+108>:	
    	f7200012	bne	t11, 0x140017378 <DyCRT_CodeSpace+184>
0x140017330 <DyCRT_CodeSpace+112>:	
    	441f041b	or	v0, zero, t12
0x140017334 <DyCRT_CodeSpace+116>:	
    	c3e00000	br	 0x140017338 <DyCRT_CodeSpace+120>
0x140017338 <DyCRT_CodeSpace+120>:	
    	445f0419	or	t1, zero, t11
0x14001733c <DyCRT_CodeSpace+124>:	
    	c3e00000	br	 0x140017340 <DyCRT_CodeSpace+128>
0x140017340 <DyCRT_CodeSpace+128>:	
    	4f3b001b	mull	t11, t12, t12
0x140017344 <DyCRT_CodeSpace+132>:	
    	477f0400	or	t12, zero, v0
0x140017348 <DyCRT_CodeSpace+136>:	
    	c3e00000	br	 0x14001734c <DyCRT_CodeSpace+140>
0x14001734c <DyCRT_CodeSpace+140>:	
    	445f041b	or	t1, zero, t12
0x140017350 <DyCRT_CodeSpace+144>:	
    	c3e00000	br	 0x140017354 <DyCRT_CodeSpace+148>
0x140017354 <DyCRT_CodeSpace+148>:	
    	445f0419	or	t1, zero, t11
0x140017358 <DyCRT_CodeSpace+152>:	
    	c3e00000	br	 0x14001735c <DyCRT_CodeSpace+156>
0x14001735c <DyCRT_CodeSpace+156>:	
    	237bffff	lda	t12, -1(t12)
0x140017360 <DyCRT_CodeSpace+160>:		5fff041f	fnop
0x140017364 <DyCRT_CodeSpace+164>:	
    	477f0402	or	t12, zero, t1
0x140017368 <DyCRT_CodeSpace+168>:	
    	c3e00000	br	 0x14001736c <DyCRT_CodeSpace+172>
0x14001736c <DyCRT_CodeSpace+172>:	
    	a3780000	ldl	t12, 0(t10)
0x140017370 <DyCRT_CodeSpace+176>:	
    	a3380000	ldl	t11, 0(t10)
0x140017374 <DyCRT_CodeSpace+180>:	
    	c3ffffe8	br	 0x140017318 <DyCRT_CodeSpace+88>
0x140017378 <DyCRT_CodeSpace+184>:	
    	a3780000	ldl	t12, 0(t10)
0x14001737c <DyCRT_CodeSpace+188>:	
    	a3380000	ldl	t11, 0(t10)
0x140017380 <DyCRT_CodeSpace+192>:	
    	a75e0080	ldq	ra, 128(sp)
0x140017384 <DyCRT_CodeSpace+196>:		5fff041f	fnop
0x140017388 <DyCRT_CodeSpace+200>:	
    	23de01c0	lda	sp, 448(sp)
0x14001738c <DyCRT_CodeSpace+204>:	
    	6bfa8001	ret	zero, (ra), 1
0x140017390 <DyCRT_CodeSpace+208>:		0


However, we have a lot of unnecessary br's and also unnecessary
ldls. If we could get rid of them the code would look like:

0x1400172e0 <DyCRT_CodeSpace+32>:	
    	a05e0170	ldl	t1, 368(sp)
0x1400172e4 <DyCRT_CodeSpace+36>:	
    	a01e0150	ldl	v0, 336(sp)
0x1400172e8 <DyCRT_CodeSpace+40>:	
    	a03e0158	ldl	t0, 344(sp)
0x1400172ec <DyCRT_CodeSpace+44>:	
    	a71e0178	ldq	t10, 376(sp)
0x1400172f0 <DyCRT_CodeSpace+48>:	
    	a3780000	ldl	t12, 0(t10)
0x1400172f4 <DyCRT_CodeSpace+52>:	
    	441f0419	or	v0, zero, t11
0x1400172fc <DyCRT_CodeSpace+60>:	
    	201f0001	lda	v0, 1(zero)
0x140017304 <DyCRT_CodeSpace+68>:	
    	a3780000	ldl	t12, 0(t10)
0x140017308 <DyCRT_CodeSpace+72>:	
    	443f0419	or	t0, zero, t11
0x140017310 <DyCRT_CodeSpace+80>:	
    	203f0000	lda	t0, 0(zero)
0x140017318 <DyCRT_CodeSpace+88>:	
    	443f041b	or	t0, zero, t12
0x140017320 <DyCRT_CodeSpace+96>:	
    	445f0419	or	t1, zero, t11
0x140017328 <DyCRT_CodeSpace+104>:	
    	437905b9	cmpeq	t12, t11, t11
0x14001732c <DyCRT_CodeSpace+108>:	
    	f7200012	bne	t11, 0x140017378 <DyCRT_CodeSpace+184>
0x140017330 <DyCRT_CodeSpace+112>:	
    	441f041b	or	v0, zero, t12
0x140017338 <DyCRT_CodeSpace+120>:	
    	445f0419	or	t1, zero, t11
0x140017340 <DyCRT_CodeSpace+128>:	
    	4f3b001b	mull	t11, t12, t12
0x140017344 <DyCRT_CodeSpace+132>:	
    	477f0400	or	t12, zero, v0
0x14001734c <DyCRT_CodeSpace+140>:	
    	445f041b	or	t1, zero, t12
0x140017354 <DyCRT_CodeSpace+148>:	
    	445f0419	or	t1, zero, t11
0x14001735c <DyCRT_CodeSpace+156>:	
    	237bffff	lda	t12, -1(t12)
0x140017360 <DyCRT_CodeSpace+160>:		5fff041f	fnop
0x140017364 <DyCRT_CodeSpace+164>:	
    	477f0402	or	t12, zero, t1
0x14001736c <DyCRT_CodeSpace+172>:	
    	a3780000	ldl	t12, 0(t10)
0x140017370 <DyCRT_CodeSpace+176>:	
    	a3380000	ldl	t11, 0(t10)
0x140017374 <DyCRT_CodeSpace+180>:	
    	c3ffffe8	br	 0x140017318 <DyCRT_CodeSpace+88>
0x140017378 <DyCRT_CodeSpace+184>:	
    	a3780000	ldl	t12, 0(t10)
0x14001737c <DyCRT_CodeSpace+188>:	
    	a3380000	ldl	t11, 0(t10)
0x140017380 <DyCRT_CodeSpace+192>:	
    	a75e0080	ldq	ra, 128(sp)
0x140017384 <DyCRT_CodeSpace+196>:		5fff041f	fnop
0x140017388 <DyCRT_CodeSpace+200>:	
    	23de01c0	lda	sp, 448(sp)
0x14001738c <DyCRT_CodeSpace+204>:	
    	6bfa8001	ret	zero, (ra), 1
0x140017390 <DyCRT_CodeSpace+208>:		0


for comparison, without register allocation we have operations through
memory (ldl's and stl's):


0x140012e80 <DyCRT_CodeSpace+32>:	
    	a71e0168	ldq	t10, 360(sp)
0x140012e84 <DyCRT_CodeSpace+36>:	
    	a25e0160	ldl	a2, 352(sp)
0x140012e88 <DyCRT_CodeSpace+40>:	
    	b2580004	stl	a2, 4(t10)
0x140012e8c <DyCRT_CodeSpace+44>:		5fff041f	fnop
0x140012e90 <DyCRT_CodeSpace+48>:	
    	a71e0168	ldq	t10, 360(sp)
0x140012e94 <DyCRT_CodeSpace+52>:	
    	237f007c	lda	t12, 124(zero)
0x140012e98 <DyCRT_CodeSpace+56>:	
    	233f0001	lda	t11, 1(zero)
0x140012e9c <DyCRT_CodeSpace+60>:	
    	431b041b	addq	t10, t12, t12
0x140012ea0 <DyCRT_CodeSpace+64>:	
    	b33b0000	stl	t11, 0(t12)
0x140012ea4 <DyCRT_CodeSpace+68>:	
    	237f0008	lda	t12, 8(zero)
0x140012ea8 <DyCRT_CodeSpace+72>:	
    	233f0000	lda	t11, 0(zero)
0x140012eac <DyCRT_CodeSpace+76>:	
    	431b041b	addq	t10, t12, t12
0x140012eb0 <DyCRT_CodeSpace+80>:	
    	b33b0000	stl	t11, 0(t12)
0x140012eb4 <DyCRT_CodeSpace+84>:	
    	a3780008	ldl	t12, 8(t10)
0x140012eb8 <DyCRT_CodeSpace+88>:	
    	a3380004	ldl	t11, 4(t10)
0x140012ebc <DyCRT_CodeSpace+92>:	
    	437905b9	cmpeq	t12, t11, t11
0x140012ec0 <DyCRT_CodeSpace+96>:	
    	f7200008	bne	t11, 0x140012ee4 <DyCRT_CodeSpace+132>
0x140012ec4 <DyCRT_CodeSpace+100>:	
    	a3780004	ldl	t12, 4(t10)
0x140012ec8 <DyCRT_CodeSpace+104>:	
    	a338007c	ldl	t11, 124(t10)
0x140012ecc <DyCRT_CodeSpace+108>:	
    	4f790019	mull	t12, t11, t11
0x140012ed0 <DyCRT_CodeSpace+112>:	
    	b338007c	stl	t11, 124(t10)
0x140012ed4 <DyCRT_CodeSpace+116>:	
    	a3780004	ldl	t12, 4(t10)
0x140012ed8 <DyCRT_CodeSpace+120>:	
    	237bffff	lda	t12, -1(t12)
0x140012edc <DyCRT_CodeSpace+124>:	
    	b3780004	stl	t12, 4(t10)
0x140012ee0 <DyCRT_CodeSpace+128>:	
    	c3fffff4	br	 0x140012eb4 <DyCRT_CodeSpace+84>
0x140012ee4 <DyCRT_CodeSpace+132>:	
    	a018007c	ldl	v0, 124(t10)
0x140012ee8 <DyCRT_CodeSpace+136>:	
    	a75e0080	ldq	ra, 128(sp)
0x140012eec <DyCRT_CodeSpace+140>:		5fff041f	fnop
0x140012ef0 <DyCRT_CodeSpace+144>:	
    	23de01a0	lda	sp, 416(sp)
0x140012ef4 <DyCRT_CodeSpace+148>:	
    	6bfa8001	ret	zero, (ra), 1










----------------------------------------------------------------
3) Timings


Here are the raw results for the two versions:

NON-ALLOCATED VERSION (i.e. the original interpreter version with all
operations through memory)

factorial of  10, 
------------------
        DyC:    Median = 8840511                Mean = 8830456.6
                Median Overhead = 2742955.5     Mean Overhead = 2744569
                Instructions Generated = 30
                Median cycles per instruction generated = 91431.85
        Noop:   Median = 22297060.5             Mean = 22270555.4
        Asymptotic Speedup: 3.65672120573564
        Breakeven Point: 1693.06482170289

ALLOCATED version (version rewritten by inserting the switc-statements to
select r1, r2, and r31) 

factorial of  10, 
------------------
        DyC:    Median = 8556888.5              Mean = 8547878.1
                Median Overhead = 2759554.5     Mean Overhead = 2757109
                Instructions Generated = 44
                Median cycles per instruction generated = 62717.1477272727
        Noop:   Median = 45044050.5             Mean = 45061268.2
        Asymptotic Speedup: 7.76978702624344
        Breakeven Point: 703.05971826968


Each time the program was run 11 times and median times are used to
calculate the speedups / breakevens. The specialized
interpreter was called 10000 times in each program run.
The speedup for the rewritten version is much higher, since the
baseline is slowed down quite a bit by the introduction of the
switch-statements. 

Since we actually have to compare to the original version, speedup and
breakeven are:

The real asymptotic speedup computes to:
22297060.5    / (8556888.5  - 2759554.5 )
=  3.8460
=============

and breakeven

(10000 * 2759554.5 ) / (22297060.5 - 8556888.5 + 2759554.5)
= 1672.4849
============


To: mock@thistle.cs.washington.edu
cc: spin-comp-archive@cs
Subject: demotions, BTA equations
Date: Tue, 27 Jan 1998 09:35:38 PST
From: Brian Grant <grant@thistle.cs.washington.edu>

What changes did you make to the BTA equations, other than adding demotions
and changing the use of reachability conditions?  I find it difficult to
compare the two sets of equations.  What about the problems of dead root
variables while derived variables are still live?  Do we kill the derived
variables from StaticVarInfo, or keep the roots in StaticVarInfo?

On demotions:
	1) We need to put in empty sets wherever DivisionInfo tuples are built
	   from scratch (4 places?), to reflect that it is now a 4-tuple.
	2) How are demotions computed at merges? I didn't see that in the
	   equations.
	3) I'll put in a sentence or two about hoisting.

--Brian

Date: Tue, 27 Jan 1998 09:53:38 -0800 (PST)
From: Markus Mock <mock@apex.cs.washington.edu>
To: spin-comp@apex.cs.washington.edu
Subject: Submission  589223649 to PLDI 98 (fwd)

Bad news.

	-- Markus

---------- Forwarded message ----------
Date: Tue, 27 Jan 1998 11:50:03 -0600 (CST)
From: Keith Cooper <keith@cs.rice.edu>
To: cooper@cs.rice.edu.edu, mock@cs.washington.edu
Subject: Submission  589223649 to PLDI 98


Dear  Markus Mock:


This note is in regard to your paper with title

 DyC: An Expressive, Annotation-Based Dynamic 

which was received with confirmation  589223649 for
consideration at PLDI '98

I regret to inform you that the above paper was not accepted by the 
PLDI '98 program committee.

As always, the competition this year was tough.  Many papers worthy 
of publication could not be accepted.

We continue the PLDI tradition of providing reviews of your paper
which we hope will offer you guidance in revising or retargetting
your paper.  Reviews should follow within two weeks.

Written comments will be sent to you within 2 weeks

Thank you for your submission to PLDI 98


   Sincerely
   Keith D. Cooper, Program Chair


Date: Tue, 27 Jan 1998 09:59:34 -0800
From: eggers@yakima (Susan Eggers)
To: spin-comp@apex.cs.washington.edu, mock@apex.cs.washington.edu
Subject: Re: Submission  589223649 to PLDI 98 (fwd)


Oh bummer.

Date: Tue, 27 Jan 1998 16:39:04 -0800
From: eggers@yakima (Susan Eggers)
To: spin-comp@cs, eggers@yakima
Subject: Re: sections 1-3

Changed sections 6 and 7, with multiple markers in 6,
as before along with the previous sections, is in
sections17.doc.



To: spin-comp@thistle.cs.washington.edu
Subject: TCS paper draft complete!
Date: Wed, 28 Jan 1998 12:51:25 PST
From: Brian Grant <grant@thistle.cs.washington.edu>

The master document is in:
/homes/gws/matthai/papers/tcs/98/master.doc

I no longer have the lock.  The only remaining change bars are for hosed or incomplete references and for the @ call annotation in the grammar in the back.  Also, cross references probably need to be updated.  Someone please take care of these problems.

I think I have fixed all other formatting problems, including out-of-flow figures, out-of-order figures, clipped text, inconsistent fonts, etc.  I made changes to every section of the paper, but the significant changes are in sections 6-8.  I removed all of the markers I found and tried to clarify the marked sentences.  If you have time, please read it all the way through.  If not, sections 7 and 6 (in that order) are the most important to read.  I restructured the experience and future work section somewhat.  I think it flows better and the structure makes more sense.

--Brian

To: spin-comp@thistle.cs.washington.edu
Subject: found a couple more remaining problems with the draft
Date: Wed, 28 Jan 1998 13:22:31 PST
From: Brian Grant <grant@thistle.cs.washington.edu>

1) The policy table in section 4 is broken badly (again).

2) The Schism paragraph in section 8 (related work) needs to be fixed.

--Brian

To: spin-comp@thistle.cs.washington.edu
Subject: 2-columns vs. 1-column
Date: Wed, 28 Jan 1998 14:25:45 PST
From: Brian Grant <grant@thistle.cs.washington.edu>

I suggest we format the paper nicely in the 2-column format and make that
the TR.  When we have the text the way we like, then we can attempt
to reformat it for the submission.

--Brian

Date: Wed, 28 Jan 1998 18:34:38 -0800 (PST)
From: Markus Mock <mock@apex.cs.washington.edu>
To: spin-comp@apex.cs.washington.edu
Subject: tcs paper

I fixed a number of typos throughout the paper, particularly in sections 6
and 7 and added some missing figure references.
I also change the introduction a bit.

I am giving up the lock now, so you can make your changes (Matthai: can
you put in the missing bibliographical references?)


	-- Markus


To: Markus Mock <mock@apex.cs.washington.edu>
cc: spin-comp@thistle.cs.washington.edu
Subject: Re: tcs paper 
Date: Thu, 29 Jan 1998 09:13:43 PST
From: Brian Grant <grant@thistle.cs.washington.edu>

I spell-checked the document and fixed remaining typos, munged the next-to-last
paragraph of the intro a little more, added @ calls to the grammar, attempted
to fix the Schism paragraph by splitting it into two, and made a few other
minor changes.

What still remains to be done is fixing the references.  Bibframe doesn't seem
to work for me...

--Brian

Date: Thu, 29 Jan 1998 09:36:00 -0800 (PST)
From: chambers@klamath (Craig Chambers)
To: spin-comp@cs
Subject: tcs paper

I read over the whole paper last night, and found a number of glitches.
(Markus may have already found & fixed some.)  But I don't have time to put
in my edits myself; can someone get them from me?  Thanks.

-- Craig

Date: Thu, 29 Jan 1998 10:32:59 -0800
From: eggers@yakima (Susan Eggers)
To: spin-comp@cs
Subject: the paper

Let me know when Craig's changes are in, and I'll take that copy.

Susan

Date: Thu, 29 Jan 1998 15:13:51 -0800 (PST)
From: chambers@klamath (Craig Chambers)
To: spin-comp@cs
Subject: another benchmark?

FYI, we're building a bytecode interpreter for Cecil (and later, the Whirlwind
IR).  It occurred to me last night that this might be an interesting benchmark
for our DC stuff, at least for our Alpha port.  And it would be a benchmark
that we actually use and benefit from....

-- Craig

To: chambers@klamath (Craig Chambers)
cc: spin-comp@franklin.cs.washington.edu
Subject: Re: another benchmark? 
Date: Thu, 29 Jan 1998 15:22:06 PST
From: Matthai Philipose <matthai@franklin.cs.washington.edu>

> FYI, we're building a bytecode interpreter for Cecil (and later, the Whirlwind
> IR).  It occurred to me last night that this might be an interesting benchmark
> for our DC stuff, at least for our Alpha port.  And it would be a benchmark
> that we actually use and benefit from....
> 
> -- Craig
> 

Certainly sounds handy! The other aspect of this is that if the interpreter is written in a "dynamic compilation aware" fashion, it would make a big difference for our system. I am specifically thinking of the way our PLDI/tcs interpreter has the GOSUB opcode implemented as a recursive call to the interpreter, thus enabling conditional specialization using our infrastructure (when it reaches full functionality).

BTW, I've downloaded the publicly available version of OpenGL (it's called Mesa and is in our examples directory), and will start playing around with it after I finish munging the tcs paper.	
		Matthai

Date: Thu, 29 Jan 1998 18:57:44 -0800
From: eggers@yakima (Susan Eggers)
To: spin-comp@cs
Subject: TCS paper

Where is the latest copy, in Matthai's directory?

Susan

To: spin-comp@thistle.cs.washington.edu
Subject: nearly finished with Craig's comments
Date: Fri, 30 Jan 1998 01:41:27 PST
From: Brian Grant <grant@thistle.cs.washington.edu>

I think we're nearly finished implementing Craig's suggested changes.  The
only remaining one, I believe, is to rewrite the intro to section 7
(experiences).  I'll make a pass at that first thing in the morning.

Additional discussion of other approaches, such as binary-translation
systems or PDGs, probably won't make it in.

Changes I made tonight include:

	1) Changing the BTA equations to attempt a proper fix to the UsedVars
	   problem (see ForgetDeadVars).

	2) Changing the run-time specializer in section 3 to properly
	   implement one-time lazy edges (corresponding to lazy branch
	   successors).

--Brian

ps. References still need to be fixed, too.

To: spin-comp@franklin.cs.washington.edu
Subject: Complete draft of paper ready
Date: Fri, 30 Jan 1998 12:32:50 PST
From: Matthai Philipose <matthai@franklin.cs.washington.edu>

~matthai/papers/tcs/98/master.[doc,ps]  contain a draft of the TCS paper with all suggestions incorporated and all fixes we agreed on.

Please take a look at it, provide feedback and/or make any changes you'd like to.

Markus figures that we should probably send the paper in before 3pm so that it is received by Friday French time.
		Matthai

Date: Fri, 30 Jan 1998 12:56:16 -0800 (PST)
From: chambers@klamath (Craig Chambers)
To: spin-comp@cs
Subject: tcs submission as TR?

I assume we're going to make our TCS submission into a TR?  Do we want to make
our PLDI submission at TR, too?  Then at least it's available to others, and
listable on CVs and activity reports and the like.

We shouldn't do anything with the PLDI submission until we get reviewers
comments back and can think about making any changes.

The TCS thingy I think we could TR-ize as soon as we want.

-- Craig

To: chambers@klamath (Craig Chambers)
cc: spin-comp@thistle.cs.washington.edu
Subject: Re: tcs submission as TR? 
Date: Fri, 30 Jan 1998 13:02:40 PST
From: Brian Grant <grant@thistle.cs.washington.edu>

>> The TCS thingy I think we could TR-ize as soon as we want.

What does this entail?  We have a number that was supposed to be the expanded
PEPM paper.  Should we just use that?

Should we add a cover page to the doc or just add the tech. report number and
date under the title?

After it is finished, do we just send the new title and postscript to Scott?

--Brian

Date: Fri, 30 Jan 1998 13:09:56 -0800 (PST)
From: chambers@klamath (Craig Chambers)
To: grant@thistle.cs.washington.edu
Subject: Re: tcs submission as TR?
Cc: spin-comp@thistle.cs.washington.edu

> >> The TCS thingy I think we could TR-ize as soon as we want.
> 
> What does this entail?  We have a number that was supposed to be the expanded
> PEPM paper.  Should we just use that?

Sure.

> 
> Should we add a cover page to the doc or just add the tech. report number and
> date under the title?

I don't particularly care.  Since hardcopies aren't made any more, the cover
page is more ugly than helpful, IMHO.  So I'd say just add a line to the first
page giving the TR number, and add a footnote that this is an expanded version
of a PEPM'97 paper.

> 
> After it is finished, do we just send the new title and postscript to Scott?

Yes, and maybe the abstract too.  Fred Videon may want these things too.

-- Craig

Date: Fri, 30 Jan 1998 13:12:37 -0800
From: eggers@yakima (Susan Eggers)
To: matthai@cs.washington.edu, spin-comp@franklin.cs.washington.edu
Subject: Re:  Complete draft of paper ready

I'm about to fax you changes in language for the first 4 sections.
I'll send the rest in a bit.

Susan

Date: Fri, 30 Jan 1998 13:24:48 -0800
From: eggers@yakima (Susan Eggers)
To: spin-comp@cs
Subject: it's faxing now

but I forgot to include a header -- it's just the paper pages.

Susan

Date: Fri, 30 Jan 1998 14:13:22 -0800
From: eggers@yakima (Susan Eggers)
To: spin-comp@cs
Subject: submitting

Did the call say we had to submit by a particular time or a particular
day?  If only the latter, let's submit when it's done.  I can't imagine
anyone will handle this before Monday.

Susan

Date: Fri, 30 Jan 1998 14:21:59 -0800 (PST)
From: Markus Mock <mock@apex.cs.washington.edu>
To: Matthai Philipose <matthai@cs.washington.edu>
cc: spin-comp@franklin.cs.washington.edu
Subject: Re: Complete draft of paper ready

I fixed a few typos in the last 3 sections, the lock is released if anyone
wants to make some other changes.

There was no fax at the fax machine, did anyone pick it up?
I don't think there was an exact time for the submission, but Brian should
have Charles' mail.

	-- Markus


Date: Fri, 30 Jan 1998 14:38:23 -0800 (PST)
From: Markus Mock <mock@apex.cs.washington.edu>
To: Brian Grant <grant@cs>, spin-comp-archive@cs
Subject: Expression ( !ShouldPatch ) evaluated to FALSE at (file:line) p2dyc/setup.C:3323

Is there something wrt igoto's missing?

	-- Markus


Date: Fri, 30 Jan 1998 15:45:30 -0800 (PST)
From: chambers@klamath (Craig Chambers)
To: spin-comp@cs
Subject: Whirlwind grant proposal

FYI, if you're interested in reading the Whirlwind grant proposal I sent out
mid-January, it's in ~chambers/grants/nsf/whirlwind/proposal.ps.

-- Craig

Date: Fri, 30 Jan 1998 15:46:46 -0800 (PST)
From: chambers@klamath (Craig Chambers)
To: spin-comp@cs
Subject: Re: Whirlwind grant proposal


> From chambers@klamath  Fri Jan 30 15:45:33 1998
> Delivery-Date: Fri, 30 Jan 1998 15:45:34 PST
> Date: Fri, 30 Jan 1998 15:45:30 -0800 (PST)
> From: chambers@klamath (Craig Chambers)
> To: spin-comp@cs
> Subject: Whirlwind grant proposal
> X-Sun-Charset: US-ASCII
> 
> FYI, if you're interested in reading the Whirlwind grant proposal I sent out
> mid-January, it's in ~chambers/grants/nsf/whirlwind/proposal.ps.
> 
> -- Craig
> 

Actually, see it in ~chambers/research/whirlwind/proposal.ps.

-- Craig

To: spin-comp@thistle.cs.washington.edu
Subject: submission sent!
Date: Fri, 30 Jan 1998 16:26:40 PST
From: Brian Grant <grant@thistle.cs.washington.edu>

I finished with Susan's edits and fired it off to Consel.

--Brian

To: spin-comp@thistle.cs.washington.edu
Subject: TR version on web page
Date: Fri, 30 Jan 1998 17:00:38 PST
From: Brian Grant <grant@thistle.cs.washington.edu>

I made a TR version, sent it to Scott, and put it on our web page.

--Brian

Date: Mon, 2 Feb 1998 15:47:36 -0800 (PST)
From: chambers@klamath (Craig Chambers)
To: spin-comp@cs
Subject: Scout release

Maybe there are DC applications here?

-- Craig


----- Begin Included Message -----

From llp@baskerville.CS.Arizona.EDU  Mon Feb  2 15:30:35 1998
Delivery-Date: Mon, 02 Feb 1998 15:30:36 PST
Date: Mon, 2 Feb 1998 16:29:11 -0700 (MST)
From: Larry Peterson <llp@baskerville.CS.Arizona.EDU>
To: quorum_pi@snap.org, activenets_wire@ittc.ukans.edu
Subject: Scout release

Version 1.0 of the Scout operating system is now available
from the University of Arizona. You can retrieve it from

    ftp://ftp.cs.arizona.edu/scout/scout.tar.gz

or you can follow the links from the Scout home page at

    http://www.cs.arizona.edu/scout

Scout is a communication-oriented operating system targeted
at network appliances (e.g., network-attached devices, set-top 
boxes, hand-held devices, and so on). Version 1.0 runs on
Alpha and Pentium processors, and includes the modules and
configuration files needed to build the following appliances:

  - NetTV: receive, decode and display MPEG video
  - NetCAM: capture, compress, and transmit MPEG video
  - Joust: a small, fast JavaOS
  - IP Router with QoS support (includes both IPv4 and IPv6)
  - TCP Forwarder: foundation for firewalls and web proxies
  - Test Kernel: exercises TCP/IP protocol stack
  - NetBoot: used to boot other kernels

Note: Joust depends on a Java bytecode compiler availalable at
http://www.cs.arizona.edu/sumatra. Sumatra currently supports
Java 1.0.2.

Direct questions and comments to scout-help@cs.arizona.edu.

Larry


----- End Included Message -----


Date: Mon, 2 Feb 1998 16:12:00 -0800
From: eggers@yakima (Susan Eggers)
To: spin-comp@cs, chambers@klamath
Subject: Re: Scout release

Was just thinking the same thing...

There should be -- their web page talks about optimizing for commonly
used paths.

Susan

To: spin-comp@thistle.cs.washington.edu
Subject: TR installed
Date: Wed, 04 Feb 1998 12:01:22 PST
From: Brian Grant <grant@thistle.cs.washington.edu>

Under the TR number 97-03-03.  I found it in NCSTRL.

--Brian

------- Forwarded Message

From: fred@cs.washington.edu
To: grant@cs.washington.edu, sjdakins@cs
Subject: RE: Tech. report (finally) ready
Date: Wed, 4 Feb 1998 11:51:46 -0800 

It has now been copied to the on-line archives.

--------

Date: Thu, 5 Feb 1998 13:32:41 -0800 (PST)
From: Markus Mock <mock@apex.cs.washington.edu>
To: Matthai Philipose <matthai@cs>, spin-comp-archive@cs
Subject: pms-file

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.
  Send mail to mime@docserver.cac.washington.edu for more info.

---2141257447-93009857-886714361=:18674
Content-Type: TEXT/PLAIN; charset=US-ASCII

It's in  interpreter-regs.pms and I am also attaching it. The version with
-time still crashes in schedule_vn but the code not compiled with -time
shows the same branches (in fact the code is identical, so I think that
should suffice).


	-- Markus

---2141257447-93009857-886714361=:18674
Content-Type: APPLICATION/octet-stream; name="interpreter-regs.pms"
Content-Transfer-Encoding: BASE64
Content-ID: <Pine.A32.3.96.980205133240.18674I@apex.cs.washington.edu>
Content-Description: 

XyQxVEVNUExBVEVQQUNLRVQuMyA9IDB4MApfJDFURU1QTEFURVBBQ0tFVC4x
MyA9IDB4MApfJDFURU1QTEFURVBBQ0tFVC4xMSA9IDB4MApfJDFURU1QTEFU
RVBBQ0tFVC45ID0gMHgwCl8kMVRFTVBMQVRFUEFDS0VULjEyID0gMHgwCl8k
MVBBQ0tFVC42ID0gMHgwCiQyLjEkMnJhc19wID0gMHg4MAokMi4xJDJzcGls
bF9wID0gMHg4OAokMi4xJDJhdXRvX3NpemUgPSAweDIyMAokMi4yJDJyYXNf
cCA9IDB4MAokMi4yJDJzcGlsbF9wID0gMHg4CiQyLjIkMmF1dG9fc2l6ZSA9
IDB4NDAKLmRhdGEKCS5zZXQgbm9yZW9yZGVyLCBub21hY3JvLCBub21vdmUs
IG5vYXQKICN0YXJnZXQgY2x1c3RlcnMoMSksbWVtY2FyZHMoNCksbWVtYmFu
a3MoMzIpLHJlZmFsaWduKDgpOwogIyBWU1NBRCBUcmFjZSBTY2hlZHVsaW5n
IEFscGhhIENvbXBpbGVyIC0tIFRhcmdldGluZyBFVjQKICNtYXJrX2Rlc2Ny
aXB0aW9uICJWU1NBRC9NdWx0aWZsb3cgVHJhY2UgU2NoZWR1bGluZyBDIENv
bXBpbGVyXHRWZXJzaW9uIDAuMSogKHByaXZhdGUpXHRCdWlsdCBXZWQgRmVi
IDQgMjA6MTY6MjYgUFNUIDE5OTggb24gbWVpdG5lci5jcy53YXNoaW5ndG9u
LmVkdSBpbiAvYWZzL2NzLndhc2hpbmd0b24uZWR1L3Byb2plY3QvZHluY29t
cC9tb2NrL0R5Qy9tZmxvd1x0IC1kaXIgL3Byb2plY3RzL3RyYWNlMS9tZmxv
dy91c3IvdnNzYWQvcmVsZWFzZS9tb2NrIC1vc2ZfYWxwaGEgLURfX2FscGhh
IC1Edm9sYXRpbGU9IC1EX0JTRCAtd2lkdGggNyAtbUdMT0JfbWFjaGluZV90
eXBlPUdMT0JfTUFDSElORV9UWVBFX0FMUEhBIC1tQVMgLW1QMUNPUFRfc3Fy
dF9pbnN0cnVjdGlvbj1GQUxTRSAtbVAxRk9QVF9zcXJ0X2luc3RydWN0aW9u
PUZBTFNFIC1tUDNPUFRfdXNlX3Nob3J0X2JyYW5jaGVzIC1tUDNPUFRfc2hv
cnRfYnJhbmNoX3RyYWNlX2xpbWl0PS0xIC1tUDFGT1BUX3Nob3J0X2JyYW5j
aF9tYXhfc3RhdHM9LTEgLW1HTE9CX2FyZ19pbnRlZ2VyX3JlZ3M9MTYgLW1H
TE9CX2FyZ19mbG9hdGluZ19yZWdzPTE2IC1tR0xPQl9yZXRfaW50ZWdlcl9y
ZWdzPTE2IC1tR0xPQl9yZXRfZmxvYXRpbmdfcmVncz0xNiAtbVAyT1BUX2xv
YWRfY29uc3RhbnRzPVRSVUUgLW1QMk9QVF9jb21iaW5lXzY0X2JpdF9jb25z
dGFudHM9RkFMU0UgLW1QMkRZQ19nZW5lcmF0ZV9zZWxlY3RzPWZhbHNlIC1t
UDJPUFRfc2VsX2lmX2NvbnZlcnRfbmV2ZXI9dHJ1ZSAtbVAxQ09QVF9nZW5l
cmF0ZV9zZWxlY3RzPWZhbHNlIC1tR0xPQl9hcmdfaW50ZWdlcl9yZWdzPTYg
LW1HTE9CX2FyZ19mbG9hdGluZ19yZWdzPTYgLW1HTE9CX3JldF9pbnRlZ2Vy
X3JlZ3M9MSAtbUdMT0JfcmV0X2Zsb2F0aW5nX3JlZ3M9MiAtbUdMT0JfbWFj
aGluZV93b3JkX3NpemU9NjQgLW1QMU9QVF9jYWxsX2RlZmF1bHQ9UDFPUFRf
Q0FMTF9ERUZBVUxUX1JFR1MgLW1QMU9QVF9lbnRyeV9kZWZhdWx0PVAxT1BU
X0VOVFJZX0RFRkFVTFRfUkVHUyAtbUdMT0JfYXNfdHlwZT1vc2YgLW1QMUNP
UFRfYW5zaSAtRF9fTEFOR1VBR0VfQ19fIC1Ec2lnbmVkPSAtSS9wcm9qZWN0
cy90cmFjZTEvbWZsb3cvdXNyL3Zzc2FkL3JlbGVhc2UvZ2FycmV0dC91c3Iv
dXNyX2luY2x1ZGVfYWxwaGEgLW1NQUlOX1ByaW50T3B0aW9ucz10cnVlIC1t
UDJEWUNfcGVlbF93b3JrbGlzdF9sb29wPXRydWUgLW1QMk9QVF91bnJvbGxf
YW1vdW50X2Rlc2lyZWQ9MCAtbVAyT1BUX3Vucm9sbF9icmFuY2hfY291bnRf
Y2VpbGluZz0wIC1tUDJPUFRfdW5yb2xsX2Rlc2lyZWRfcHJlY29uZGl0aW9u
X2Ftb3VudD0wIC1tUDJPUFRfdW5yb2xsX2ZpcnN0X2Ftb3VudF9jZWlsaW5n
PTAgLW1QMk9QVF91bnJvbGxfZmlyc3RfYW1vdW50X2Zsb29yPTAgLW1QMk9Q
VF91bnJvbGxfc3RhdF9jb3VudF9jZWlsaW5nPTAgLVMgLW8gaW50ZXJwcmV0
ZXItcmVncy5wbXMgLW1QMU9QVF9pZnByb2Jfc291cmNlX2ZpbGVfbmFtZT1p
bnRlcnByZXRlci1yZWdzLmMiOwouZmlsZQkyICJpbnRlcnByZXRlci1yZWdz
LmMiCgkuYWxpZ24gNQoJLmFsaWduIDUKCS5hbGlnbiAzCkNTJDE6CgkuYnl0
ZQkweGYwCgkuYnl0ZQkweGYwCgkuYnl0ZQkweGYwCgkuYnl0ZQkweGYwLCAw
eGYyLCAweGYzLCAweGY2LCAweGY3LCAweGY4CgkuYnl0ZQkweGYwLCAweGY3
LCAweGY5CgkuYnl0ZQkweGYwLCAweGZiCgkuYnl0ZQkweGYwLCAweGYxCgku
Ynl0ZQkweGYwLCAweGYxCgkuYnl0ZQkweGYwLCAweGY4CgkuYnl0ZQkweGYw
LCAweGY3LCAweGY5CgkuYnl0ZQkweGYwLCAweGYyLCAweGY4LCAweGY5LCAw
eGZhLCAweGZmCgkuYnl0ZQkweGYwLCAweGY3LCAweGY5CgkuYnl0ZQkweGYw
LCAweGYyLCAweGZlCgkuYnl0ZQkweGYwLCAweGZjLCAweGZlCgkuYnl0ZQkw
eGYwLCAweGYxCgkuYnl0ZQkweGYwLCAweGYyLCAweGY4LCAweGY5LCAweGZh
LCAweGZmCgkuYnl0ZQkweGYwCgkuYnl0ZQkweGYwLCAweGY3LCAweGY5Cgku
Ynl0ZQkweGYwCgkuYnl0ZQkweGYwLCAweGYyLCAweGZlCgkuYnl0ZQkweGYw
LCAweGZjLCAweGZlCgkuYnl0ZQkweGYwLCAweGYxLCAweGY4LCAweGZhCgku
Ynl0ZQkweGYwLCAweGYxLCAweGYyLCAweGY3LCAweGZjLCAweGZmCgkuYnl0
ZQkweGYwLCAweGYzLCAweGY0CgkuYnl0ZQkweGYwLCAweGY3LCAweGY5Cgku
Ynl0ZQkweGYwLCAweGYyLCAweGZlCgkuYnl0ZQkweGYwLCAweGZjLCAweGZl
CgkuYnl0ZQkweGYwLCAweGYxLCAweGZlCgkuYnl0ZQkweGYwLCAweGYxLCAw
eGYyLCAweGYzLCAweGY0LCAweGY1CgkuYnl0ZQkweGYwLCAweGYyLCAweGYz
LCAweGY0LCAweGY1LCAweGY2LCAweGY3CgkuYnl0ZQkweGYwLCAweGYyLCAw
eGYzLCAweGY0LCAweGY1LCAweGY2LCAweGY3CgkuYnl0ZQkweGYwLCAweGYx
LCAweGY0CgkuYnl0ZQkwLCAwLCAwLCAwLCAwLCAwLCAwCgkuYWxpZ24gNQpp
bnRlcnByZXRlciQyRFlDLlNXSVRDSENPUFkuVEFHUEFDS0VULjAuMDoKCS5x
dWFkCV8kMS5pbnRlcnByZXRlci5UQUcuNy4wLmR5Y19jb3B5LjAKCS5xdWFk
CV8kMS5pbnRlcnByZXRlci5UQUcuNy4xLmR5Y19jb3B5LjAKCS5xdWFkCV8k
MS5pbnRlcnByZXRlci5UQUcuNy5ERUZBVUxULmR5Y19jb3B5LjAKCS5xdWFk
CV8kMS5pbnRlcnByZXRlci5UQUcuNy5ERUZBVUxULmR5Y19jb3B5LjAKCS5x
dWFkCV8kMS5pbnRlcnByZXRlci5UQUcuNy5ERUZBVUxULmR5Y19jb3B5LjAK
CS5xdWFkCV8kMS5pbnRlcnByZXRlci5UQUcuNy5ERUZBVUxULmR5Y19jb3B5
LjAKCS5xdWFkCV8kMS5pbnRlcnByZXRlci5UQUcuNy5ERUZBVUxULmR5Y19j
b3B5LjAKCS5xdWFkCV8kMS5pbnRlcnByZXRlci5UQUcuNy5ERUZBVUxULmR5
Y19jb3B5LjAKCS5xdWFkCV8kMS5pbnRlcnByZXRlci5UQUcuNy5ERUZBVUxU
LmR5Y19jb3B5LjAKCS5xdWFkCV8kMS5pbnRlcnByZXRlci5UQUcuNy5ERUZB
VUxULmR5Y19jb3B5LjAKCS5xdWFkCV8kMS5pbnRlcnByZXRlci5UQUcuNy5E
RUZBVUxULmR5Y19jb3B5LjAKCS5xdWFkCV8kMS5pbnRlcnByZXRlci5UQUcu
Ny5ERUZBVUxULmR5Y19jb3B5LjAKCS5xdWFkCV8kMS5pbnRlcnByZXRlci5U
QUcuNy5ERUZBVUxULmR5Y19jb3B5LjAKCS5xdWFkCV8kMS5pbnRlcnByZXRl
ci5UQUcuNy5ERUZBVUxULmR5Y19jb3B5LjAKCS5xdWFkCV8kMS5pbnRlcnBy
ZXRlci5UQUcuNy5ERUZBVUxULmR5Y19jb3B5LjAKCS5xdWFkCV8kMS5pbnRl
cnByZXRlci5UQUcuNy5ERUZBVUxULmR5Y19jb3B5LjAKCS5xdWFkCV8kMS5p
bnRlcnByZXRlci5UQUcuNy5ERUZBVUxULmR5Y19jb3B5LjAKCS5xdWFkCV8k
MS5pbnRlcnByZXRlci5UQUcuNy5ERUZBVUxULmR5Y19jb3B5LjAKCS5xdWFk
CV8kMS5pbnRlcnByZXRlci5UQUcuNy5ERUZBVUxULmR5Y19jb3B5LjAKCS5x
dWFkCV8kMS5pbnRlcnByZXRlci5UQUcuNy5ERUZBVUxULmR5Y19jb3B5LjAK
CS5xdWFkCV8kMS5pbnRlcnByZXRlci5UQUcuNy5ERUZBVUxULmR5Y19jb3B5
LjAKCS5xdWFkCV8kMS5pbnRlcnByZXRlci5UQUcuNy5ERUZBVUxULmR5Y19j
b3B5LjAKCS5xdWFkCV8kMS5pbnRlcnByZXRlci5UQUcuNy5ERUZBVUxULmR5
Y19jb3B5LjAKCS5xdWFkCV8kMS5pbnRlcnByZXRlci5UQUcuNy5ERUZBVUxU
LmR5Y19jb3B5LjAKCS5xdWFkCV8kMS5pbnRlcnByZXRlci5UQUcuNy5ERUZB
VUxULmR5Y19jb3B5LjAKCS5xdWFkCV8kMS5pbnRlcnByZXRlci5UQUcuNy5E
RUZBVUxULmR5Y19jb3B5LjAKCS5xdWFkCV8kMS5pbnRlcnByZXRlci5UQUcu
Ny5ERUZBVUxULmR5Y19jb3B5LjAKCS5xdWFkCV8kMS5pbnRlcnByZXRlci5U
QUcuNy5ERUZBVUxULmR5Y19jb3B5LjAKCS5xdWFkCV8kMS5pbnRlcnByZXRl
ci5UQUcuNy5ERUZBVUxULmR5Y19jb3B5LjAKCS5xdWFkCV8kMS5pbnRlcnBy
ZXRlci5UQUcuNy5ERUZBVUxULmR5Y19jb3B5LjAKCS5xdWFkCV8kMS5pbnRl
cnByZXRlci5UQUcuNy4yLmR5Y19jb3B5LjAKaW50ZXJwcmV0ZXIkMkRZQy5T
V0lUQ0hDT1BZLlRBR1BBQ0tFVC4xLjA6CgkucXVhZAlfJDEuaW50ZXJwcmV0
ZXIuVEFHLjYuMC5keWNfY29weS4wCgkucXVhZAlfJDEuaW50ZXJwcmV0ZXIu
VEFHLjYuMS5keWNfY29weS4wCgkucXVhZAlfJDEuaW50ZXJwcmV0ZXIuVEFH
LjYuREVGQVVMVC5keWNfY29weS4wCgkucXVhZAlfJDEuaW50ZXJwcmV0ZXIu
VEFHLjYuREVGQVVMVC5keWNfY29weS4wCgkucXVhZAlfJDEuaW50ZXJwcmV0
ZXIuVEFHLjYuREVGQVVMVC5keWNfY29weS4wCgkucXVhZAlfJDEuaW50ZXJw
cmV0ZXIuVEFHLjYuREVGQVVMVC5keWNfY29weS4wCgkucXVhZAlfJDEuaW50
ZXJwcmV0ZXIuVEFHLjYuREVGQVVMVC5keWNfY29weS4wCgkucXVhZAlfJDEu
aW50ZXJwcmV0ZXIuVEFHLjYuREVGQVVMVC5keWNfY29weS4wCgkucXVhZAlf
JDEuaW50ZXJwcmV0ZXIuVEFHLjYuREVGQVVMVC5keWNfY29weS4wCgkucXVh
ZAlfJDEuaW50ZXJwcmV0ZXIuVEFHLjYuREVGQVVMVC5keWNfY29weS4wCgku
cXVhZAlfJDEuaW50ZXJwcmV0ZXIuVEFHLjYuREVGQVVMVC5keWNfY29weS4w
CgkucXVhZAlfJDEuaW50ZXJwcmV0ZXIuVEFHLjYuREVGQVVMVC5keWNfY29w
eS4wCgkucXVhZAlfJDEuaW50ZXJwcmV0ZXIuVEFHLjYuREVGQVVMVC5keWNf
Y29weS4wCgkucXVhZAlfJDEuaW50ZXJwcmV0ZXIuVEFHLjYuREVGQVVMVC5k
eWNfY29weS4wCgkucXVhZAlfJDEuaW50ZXJwcmV0ZXIuVEFHLjYuREVGQVVM
VC5keWNfY29weS4wCgkucXVhZAlfJDEuaW50ZXJwcmV0ZXIuVEFHLjYuREVG
QVVMVC5keWNfY29weS4wCgkucXVhZAlfJDEuaW50ZXJwcmV0ZXIuVEFHLjYu
REVGQVVMVC5keWNfY29weS4wCgkucXVhZAlfJDEuaW50ZXJwcmV0ZXIuVEFH
LjYuREVGQVVMVC5keWNfY29weS4wCgkucXVhZAlfJDEuaW50ZXJwcmV0ZXIu
VEFHLjYuREVGQVVMVC5keWNfY29weS4wCgkucXVhZAlfJDEuaW50ZXJwcmV0
ZXIuVEFHLjYuREVGQVVMVC5keWNfY29weS4wCgkucXVhZAlfJDEuaW50ZXJw
cmV0ZXIuVEFHLjYuREVGQVVMVC5keWNfY29weS4wCgkucXVhZAlfJDEuaW50
ZXJwcmV0ZXIuVEFHLjYuREVGQVVMVC5keWNfY29weS4wCgkucXVhZAlfJDEu
aW50ZXJwcmV0ZXIuVEFHLjYuREVGQVVMVC5keWNfY29weS4wCgkucXVhZAlf
JDEuaW50ZXJwcmV0ZXIuVEFHLjYuREVGQVVMVC5keWNfY29weS4wCgkucXVh
ZAlfJDEuaW50ZXJwcmV0ZXIuVEFHLjYuREVGQVVMVC5keWNfY29weS4wCgku
cXVhZAlfJDEuaW50ZXJwcmV0ZXIuVEFHLjYuREVGQVVMVC5keWNfY29weS4w
CgkucXVhZAlfJDEuaW50ZXJwcmV0ZXIuVEFHLjYuREVGQVVMVC5keWNfY29w
eS4wCgkucXVhZAlfJDEuaW50ZXJwcmV0ZXIuVEFHLjYuREVGQVVMVC5keWNf
Y29weS4wCgkucXVhZAlfJDEuaW50ZXJwcmV0ZXIuVEFHLjYuREVGQVVMVC5k
eWNfY29weS4wCgkucXVhZAlfJDEuaW50ZXJwcmV0ZXIuVEFHLjYuREVGQVVM
VC5keWNfY29weS4wCgkucXVhZAlfJDEuaW50ZXJwcmV0ZXIuVEFHLjYuMi5k
eWNfY29weS4wCmludGVycHJldGVyJDJEWUMuU1dJVENIQ09QWS5UQUdQQUNL
RVQuMy4wOgoJLnF1YWQJXyQxLmludGVycHJldGVyLlRBRy4wLjAuZHljX2Nv
cHkuMAoJLnF1YWQJXyQxLmludGVycHJldGVyLlRBRy4wLjEuZHljX2NvcHku
MAoJLnF1YWQJXyQxLmludGVycHJldGVyLlRBRy4wLkRFRkFVTFQuZHljX2Nv
cHkuMAoJLnF1YWQJXyQxLmludGVycHJldGVyLlRBRy4wLkRFRkFVTFQuZHlj
X2NvcHkuMAoJLnF1YWQJXyQxLmludGVycHJldGVyLlRBRy4wLkRFRkFVTFQu
ZHljX2NvcHkuMAoJLnF1YWQJXyQxLmludGVycHJldGVyLlRBRy4wLkRFRkFV
TFQuZHljX2NvcHkuMAoJLnF1YWQJXyQxLmludGVycHJldGVyLlRBRy4wLkRF
RkFVTFQuZHljX2NvcHkuMAoJLnF1YWQJXyQxLmludGVycHJldGVyLlRBRy4w
LkRFRkFVTFQuZHljX2NvcHkuMAoJLnF1YWQJXyQxLmludGVycHJldGVyLlRB
Ry4wLkRFRkFVTFQuZHljX2NvcHkuMAoJLnF1YWQJXyQxLmludGVycHJldGVy
LlRBRy4wLkRFRkFVTFQuZHljX2NvcHkuMAoJLnF1YWQJXyQxLmludGVycHJl
dGVyLlRBRy4wLkRFRkFVTFQuZHljX2NvcHkuMAoJLnF1YWQJXyQxLmludGVy
cHJldGVyLlRBRy4wLkRFRkFVTFQuZHljX2NvcHkuMAoJLnF1YWQJXyQxLmlu
dGVycHJldGVyLlRBRy4wLkRFRkFVTFQuZHljX2NvcHkuMAoJLnF1YWQJXyQx
LmludGVycHJldGVyLlRBRy4wLkRFRkFVTFQuZHljX2NvcHkuMAoJLnF1YWQJ
XyQxLmludGVycHJldGVyLlRBRy4wLkRFRkFVTFQuZHljX2NvcHkuMAoJLnF1
YWQJXyQxLmludGVycHJldGVyLlRBRy4wLkRFRkFVTFQuZHljX2NvcHkuMAoJ
LnF1YWQJXyQxLmludGVycHJldGVyLlRBRy4wLkRFRkFVTFQuZHljX2NvcHku
MAoJLnF1YWQJXyQxLmludGVycHJldGVyLlRBRy4wLkRFRkFVTFQuZHljX2Nv
cHkuMAoJLnF1YWQJXyQxLmludGVycHJldGVyLlRBRy4wLkRFRkFVTFQuZHlj
X2NvcHkuMAoJLnF1YWQJXyQxLmludGVycHJldGVyLlRBRy4wLkRFRkFVTFQu
ZHljX2NvcHkuMAoJLnF1YWQJXyQxLmludGVycHJldGVyLlRBRy4wLkRFRkFV
TFQuZHljX2NvcHkuMAoJLnF1YWQJXyQxLmludGVycHJldGVyLlRBRy4wLkRF
RkFVTFQuZHljX2NvcHkuMAoJLnF1YWQJXyQxLmludGVycHJldGVyLlRBRy4w
LkRFRkFVTFQuZHljX2NvcHkuMAoJLnF1YWQJXyQxLmludGVycHJldGVyLlRB
Ry4wLkRFRkFVTFQuZHljX2NvcHkuMAoJLnF1YWQJXyQxLmludGVycHJldGVy
LlRBRy4wLkRFRkFVTFQuZHljX2NvcHkuMAoJLnF1YWQJXyQxLmludGVycHJl
dGVyLlRBRy4wLkRFRkFVTFQuZHljX2NvcHkuMAoJLnF1YWQJXyQxLmludGVy
cHJldGVyLlRBRy4wLkRFRkFVTFQuZHljX2NvcHkuMAoJLnF1YWQJXyQxLmlu
dGVycHJldGVyLlRBRy4wLkRFRkFVTFQuZHljX2NvcHkuMAoJLnF1YWQJXyQx
LmludGVycHJldGVyLlRBRy4wLkRFRkFVTFQuZHljX2NvcHkuMAoJLnF1YWQJ
XyQxLmludGVycHJldGVyLlRBRy4wLkRFRkFVTFQuZHljX2NvcHkuMAoJLnF1
YWQJXyQxLmludGVycHJldGVyLlRBRy4wLjIuZHljX2NvcHkuMAppbnRlcnBy
ZXRlciQyRFlDLlNXSVRDSENPUFkuVEFHUEFDS0VULjIuMDoKCS5xdWFkCV8k
MS5pbnRlcnByZXRlci5UQUcuNS4wLmR5Y19jb3B5LjAKCS5xdWFkCV8kMS5p
bnRlcnByZXRlci5UQUcuNS4xLmR5Y19jb3B5LjAKCS5xdWFkCV8kMS5pbnRl
cnByZXRlci5UQUcuNS5ERUZBVUxULmR5Y19jb3B5LjAKCS5xdWFkCV8kMS5p
bnRlcnByZXRlci5UQUcuNS5ERUZBVUxULmR5Y19jb3B5LjAKCS5xdWFkCV8k
MS5pbnRlcnByZXRlci5UQUcuNS5ERUZBVUxULmR5Y19jb3B5LjAKCS5xdWFk
CV8kMS5pbnRlcnByZXRlci5UQUcuNS5ERUZBVUxULmR5Y19jb3B5LjAKCS5x
dWFkCV8kMS5pbnRlcnByZXRlci5UQUcuNS5ERUZBVUxULmR5Y19jb3B5LjAK
CS5xdWFkCV8kMS5pbnRlcnByZXRlci5UQUcuNS5ERUZBVUxULmR5Y19jb3B5
LjAKCS5xdWFkCV8kMS5pbnRlcnByZXRlci5UQUcuNS5ERUZBVUxULmR5Y19j
b3B5LjAKCS5xdWFkCV8kMS5pbnRlcnByZXRlci5UQUcuNS5ERUZBVUxULmR5
Y19jb3B5LjAKCS5xdWFkCV8kMS5pbnRlcnByZXRlci5UQUcuNS5ERUZBVUxU
LmR5Y19jb3B5LjAKCS5xdWFkCV8kMS5pbnRlcnByZXRlci5UQUcuNS5ERUZB
VUxULmR5Y19jb3B5LjAKCS5xdWFkCV8kMS5pbnRlcnByZXRlci5UQUcuNS5E
RUZBVUxULmR5Y19jb3B5LjAKCS5xdWFkCV8kMS5pbnRlcnByZXRlci5UQUcu
NS5ERUZBVUxULmR5Y19jb3B5LjAKCS5xdWFkCV8kMS5pbnRlcnByZXRlci5U
QUcuNS5ERUZBVUxULmR5Y19jb3B5LjAKCS5xdWFkCV8kMS5pbnRlcnByZXRl
ci5UQUcuNS5ERUZBVUxULmR5Y19jb3B5LjAKCS5xdWFkCV8kMS5pbnRlcnBy
ZXRlci5UQUcuNS5ERUZBVUxULmR5Y19jb3B5LjAKCS5xdWFkCV8kMS5pbnRl
cnByZXRlci5UQUcuNS5ERUZBVUxULmR5Y19jb3B5LjAKCS5xdWFkCV8kMS5p
bnRlcnByZXRlci5UQUcuNS5ERUZBVUxULmR5Y19jb3B5LjAKCS5xdWFkCV8k
MS5pbnRlcnByZXRlci5UQUcuNS5ERUZBVUxULmR5Y19jb3B5LjAKCS5xdWFk
CV8kMS5pbnRlcnByZXRlci5UQUcuNS5ERUZBVUxULmR5Y19jb3B5LjAKCS5x
dWFkCV8kMS5pbnRlcnByZXRlci5UQUcuNS5ERUZBVUxULmR5Y19jb3B5LjAK
CS5xdWFkCV8kMS5pbnRlcnByZXRlci5UQUcuNS5ERUZBVUxULmR5Y19jb3B5
LjAKCS5xdWFkCV8kMS5pbnRlcnByZXRlci5UQUcuNS5ERUZBVUxULmR5Y19j
b3B5LjAKCS5xdWFkCV8kMS5pbnRlcnByZXRlci5UQUcuNS5ERUZBVUxULmR5
Y19jb3B5LjAKCS5xdWFkCV8kMS5pbnRlcnByZXRlci5UQUcuNS5ERUZBVUxU
LmR5Y19jb3B5LjAKCS5xdWFkCV8kMS5pbnRlcnByZXRlci5UQUcuNS5ERUZB
VUxULmR5Y19jb3B5LjAKCS5xdWFkCV8kMS5pbnRlcnByZXRlci5UQUcuNS5E
RUZBVUxULmR5Y19jb3B5LjAKCS5xdWFkCV8kMS5pbnRlcnByZXRlci5UQUcu
NS5ERUZBVUxULmR5Y19jb3B5LjAKCS5xdWFkCV8kMS5pbnRlcnByZXRlci5U
QUcuNS5ERUZBVUxULmR5Y19jb3B5LjAKCS5xdWFkCV8kMS5pbnRlcnByZXRl
ci5UQUcuNS4yLmR5Y19jb3B5LjAKaW50ZXJwcmV0ZXIkMkRZQy5TV0lUQ0hD
T1BZLlRBR1BBQ0tFVC43LjA6CgkucXVhZAlfJDEuaW50ZXJwcmV0ZXIuVEFH
LjIuMC5keWNfY29weS4wCgkucXVhZAlfJDEuaW50ZXJwcmV0ZXIuVEFHLjIu
MS5keWNfY29weS4wCgkucXVhZAlfJDEuaW50ZXJwcmV0ZXIuVEFHLjIuREVG
QVVMVC5keWNfY29weS4wCgkucXVhZAlfJDEuaW50ZXJwcmV0ZXIuVEFHLjIu
REVGQVVMVC5keWNfY29weS4wCgkucXVhZAlfJDEuaW50ZXJwcmV0ZXIuVEFH
LjIuREVGQVVMVC5keWNfY29weS4wCgkucXVhZAlfJDEuaW50ZXJwcmV0ZXIu
VEFHLjIuREVGQVVMVC5keWNfY29weS4wCgkucXVhZAlfJDEuaW50ZXJwcmV0
ZXIuVEFHLjIuREVGQVVMVC5keWNfY29weS4wCgkucXVhZAlfJDEuaW50ZXJw
cmV0ZXIuVEFHLjIuREVGQVVMVC5keWNfY29weS4wCgkucXVhZAlfJDEuaW50
ZXJwcmV0ZXIuVEFHLjIuREVGQVVMVC5keWNfY29weS4wCgkucXVhZAlfJDEu
aW50ZXJwcmV0ZXIuVEFHLjIuREVGQVVMVC5keWNfY29weS4wCgkucXVhZAlf
JDEuaW50ZXJwcmV0ZXIuVEFHLjIuREVGQVVMVC5keWNfY29weS4wCgkucXVh
ZAlfJDEuaW50ZXJwcmV0ZXIuVEFHLjIuREVGQVVMVC5keWNfY29weS4wCgku
cXVhZAlfJDEuaW50ZXJwcmV0ZXIuVEFHLjIuREVGQVVMVC5keWNfY29weS4w
CgkucXVhZAlfJDEuaW50ZXJwcmV0ZXIuVEFHLjIuREVGQVVMVC5keWNfY29w
eS4wCgkucXVhZAlfJDEuaW50ZXJwcmV0ZXIuVEFHLjIuREVGQVVMVC5keWNf
Y29weS4wCgkucXVhZAlfJDEuaW50ZXJwcmV0ZXIuVEFHLjIuREVGQVVMVC5k
eWNfY29weS4wCgkucXVhZAlfJDEuaW50ZXJwcmV0ZXIuVEFHLjIuREVGQVVM
VC5keWNfY29weS4wCgkucXVhZAlfJDEuaW50ZXJwcmV0ZXIuVEFHLjIuREVG
QVVMVC5keWNfY29weS4wCgkucXVhZAlfJDEuaW50ZXJwcmV0ZXIuVEFHLjIu
REVGQVVMVC5keWNfY29weS4wCgkucXVhZAlfJDEuaW50ZXJwcmV0ZXIuVEFH
LjIuREVGQVVMVC5keWNfY29weS4wCgkucXVhZAlfJDEuaW50ZXJwcmV0ZXIu
VEFHLjIuREVGQVVMVC5keWNfY29weS4wCgkucXVhZAlfJDEuaW50ZXJwcmV0
ZXIuVEFHLjIuREVGQVVMVC5keWNfY29weS4wCgkucXVhZAlfJDEuaW50ZXJw
cmV0ZXIuVEFHLjIuREVGQVVMVC5keWNfY29weS4wCgkucXVhZAlfJDEuaW50
ZXJwcmV0ZXIuVEFHLjIuREVGQVVMVC5keWNfY29weS4wCgkucXVhZAlfJDEu
aW50ZXJwcmV0ZXIuVEFHLjIuREVGQVVMVC5keWNfY29weS4wCgkucXVhZAlf
JDEuaW50ZXJwcmV0ZXIuVEFHLjIuREVGQVVMVC5keWNfY29weS4wCgkucXVh
ZAlfJDEuaW50ZXJwcmV0ZXIuVEFHLjIuREVGQVVMVC5keWNfY29weS4wCgku
cXVhZAlfJDEuaW50ZXJwcmV0ZXIuVEFHLjIuREVGQVVMVC5keWNfY29weS4w
CgkucXVhZAlfJDEuaW50ZXJwcmV0ZXIuVEFHLjIuREVGQVVMVC5keWNfY29w
eS4wCgkucXVhZAlfJDEuaW50ZXJwcmV0ZXIuVEFHLjIuREVGQVVMVC5keWNf
Y29weS4wCgkucXVhZAlfJDEuaW50ZXJwcmV0ZXIuVEFHLjIuMi5keWNfY29w
eS4wCmludGVycHJldGVyJDJEWUMuU1dJVENIQ09QWS5UQUdQQUNLRVQuNC4w
OgoJLnF1YWQJXyQxLmludGVycHJldGVyLlRBRy40LjAuZHljX2NvcHkuMAoJ
LnF1YWQJXyQxLmludGVycHJldGVyLlRBRy40LjEuZHljX2NvcHkuMAoJLnF1
YWQJXyQxLmludGVycHJldGVyLlRBRy40LkRFRkFVTFQuZHljX2NvcHkuMAoJ
LnF1YWQJXyQxLmludGVycHJldGVyLlRBRy40LkRFRkFVTFQuZHljX2NvcHku
MAoJLnF1YWQJXyQxLmludGVycHJldGVyLlRBRy40LkRFRkFVTFQuZHljX2Nv
cHkuMAoJLnF1YWQJXyQxLmludGVycHJldGVyLlRBRy40LkRFRkFVTFQuZHlj
X2NvcHkuMAoJLnF1YWQJXyQxLmludGVycHJldGVyLlRBRy40LkRFRkFVTFQu
ZHljX2NvcHkuMAoJLnF1YWQJXyQxLmludGVycHJldGVyLlRBRy40LkRFRkFV
TFQuZHljX2NvcHkuMAoJLnF1YWQJXyQxLmludGVycHJldGVyLlRBRy40LkRF
RkFVTFQuZHljX2NvcHkuMAoJLnF1YWQJXyQxLmludGVycHJldGVyLlRBRy40
LkRFRkFVTFQuZHljX2NvcHkuMAoJLnF1YWQJXyQxLmludGVycHJldGVyLlRB
Ry40LkRFRkFVTFQuZHljX2NvcHkuMAoJLnF1YWQJXyQxLmludGVycHJldGVy
LlRBRy40LkRFRkFVTFQuZHljX2NvcHkuMAoJLnF1YWQJXyQxLmludGVycHJl
dGVyLlRBRy40LkRFRkFVTFQuZHljX2NvcHkuMAoJLnF1YWQJXyQxLmludGVy
cHJldGVyLlRBRy40LkRFRkFVTFQuZHljX2NvcHkuMAoJLnF1YWQJXyQxLmlu
dGVycHJldGVyLlRBRy40LkRFRkFVTFQuZHljX2NvcHkuMAoJLnF1YWQJXyQx
LmludGVycHJldGVyLlRBRy40LkRFRkFVTFQuZHljX2NvcHkuMAoJLnF1YWQJ
XyQxLmludGVycHJldGVyLlRBRy40LkRFRkFVTFQuZHljX2NvcHkuMAoJLnF1
YWQJXyQxLmludGVycHJldGVyLlRBRy40LkRFRkFVTFQuZHljX2NvcHkuMAoJ
LnF1YWQJXyQxLmludGVycHJldGVyLlRBRy40LkRFRkFVTFQuZHljX2NvcHku
MAoJLnF1YWQJXyQxLmludGVycHJldGVyLlRBRy40LkRFRkFVTFQuZHljX2Nv
cHkuMAoJLnF1YWQJXyQxLmludGVycHJldGVyLlRBRy40LkRFRkFVTFQuZHlj
X2NvcHkuMAoJLnF1YWQJXyQxLmludGVycHJldGVyLlRBRy40LkRFRkFVTFQu
ZHljX2NvcHkuMAoJLnF1YWQJXyQxLmludGVycHJldGVyLlRBRy40LkRFRkFV
TFQuZHljX2NvcHkuMAoJLnF1YWQJXyQxLmludGVycHJldGVyLlRBRy40LkRF
RkFVTFQuZHljX2NvcHkuMAoJLnF1YWQJXyQxLmludGVycHJldGVyLlRBRy40
LkRFRkFVTFQuZHljX2NvcHkuMAoJLnF1YWQJXyQxLmludGVycHJldGVyLlRB
Ry40LkRFRkFVTFQuZHljX2NvcHkuMAoJLnF1YWQJXyQxLmludGVycHJldGVy
LlRBRy40LkRFRkFVTFQuZHljX2NvcHkuMAoJLnF1YWQJXyQxLmludGVycHJl
dGVyLlRBRy40LkRFRkFVTFQuZHljX2NvcHkuMAoJLnF1YWQJXyQxLmludGVy
cHJldGVyLlRBRy40LkRFRkFVTFQuZHljX2NvcHkuMAoJLnF1YWQJXyQxLmlu
dGVycHJldGVyLlRBRy40LkRFRkFVTFQuZHljX2NvcHkuMAoJLnF1YWQJXyQx
LmludGVycHJldGVyLlRBRy40LjIuZHljX2NvcHkuMAppbnRlcnByZXRlciQy
RFlDLlNXSVRDSENPUFkuVEFHUEFDS0VULjUuMDoKCS5xdWFkCV8kMS5pbnRl
cnByZXRlci5UQUcuOC4wLmR5Y19jb3B5LjAKCS5xdWFkCV8kMS5pbnRlcnBy
ZXRlci5UQUcuOC4xLmR5Y19jb3B5LjAKCS5xdWFkCV8kMS5pbnRlcnByZXRl
ci5UQUcuOC4yLmR5Y19jb3B5LjAKCS5xdWFkCV8kMS5pbnRlcnByZXRlci5U
QUcuOC4zLmR5Y19jb3B5LjAKCS5xdWFkCV8kMS5pbnRlcnByZXRlci5UQUcu
OC40LmR5Y19jb3B5LjAKCS5xdWFkCV8kMS5pbnRlcnByZXRlci5UQUcuOC41
LmR5Y19jb3B5LjAKaW50ZXJwcmV0ZXIkMkRZQy5TV0lUQ0hDT1BZLlRBR1BB
Q0tFVC44LjA6CgkucXVhZAlfJDEuaW50ZXJwcmV0ZXIuVEFHLjEuMC5keWNf
Y29weS4wCgkucXVhZAlfJDEuaW50ZXJwcmV0ZXIuVEFHLjEuMS5keWNfY29w
eS4wCgkucXVhZAlfJDEuaW50ZXJwcmV0ZXIuVEFHLjEuREVGQVVMVC5keWNf
Y29weS4wCgkucXVhZAlfJDEuaW50ZXJwcmV0ZXIuVEFHLjEuREVGQVVMVC5k
eWNfY29weS4wCgkucXVhZAlfJDEuaW50ZXJwcmV0ZXIuVEFHLjEuREVGQVVM
VC5keWNfY29weS4wCgkucXVhZAlfJDEuaW50ZXJwcmV0ZXIuVEFHLjEuREVG
QVVMVC5keWNfY29weS4wCgkucXVhZAlfJDEuaW50ZXJwcmV0ZXIuVEFHLjEu
REVGQVVMVC5keWNfY29weS4wCgkucXVhZAlfJDEuaW50ZXJwcmV0ZXIuVEFH
LjEuREVGQVVMVC5keWNfY29weS4wCgkucXVhZAlfJDEuaW50ZXJwcmV0ZXIu
VEFHLjEuREVGQVVMVC5keWNfY29weS4wCgkucXVhZAlfJDEuaW50ZXJwcmV0
ZXIuVEFHLjEuREVGQVVMVC5keWNfY29weS4wCgkucXVhZAlfJDEuaW50ZXJw
cmV0ZXIuVEFHLjEuREVGQVVMVC5keWNfY29weS4wCgkucXVhZAlfJDEuaW50
ZXJwcmV0ZXIuVEFHLjEuREVGQVVMVC5keWNfY29weS4wCgkucXVhZAlfJDEu
aW50ZXJwcmV0ZXIuVEFHLjEuREVGQVVMVC5keWNfY29weS4wCgkucXVhZAlf
JDEuaW50ZXJwcmV0ZXIuVEFHLjEuREVGQVVMVC5keWNfY29weS4wCgkucXVh
ZAlfJDEuaW50ZXJwcmV0ZXIuVEFHLjEuREVGQVVMVC5keWNfY29weS4wCgku
cXVhZAlfJDEuaW50ZXJwcmV0ZXIuVEFHLjEuREVGQVVMVC5keWNfY29weS4w
CgkucXVhZAlfJDEuaW50ZXJwcmV0ZXIuVEFHLjEuREVGQVVMVC5keWNfY29w
eS4wCgkucXVhZAlfJDEuaW50ZXJwcmV0ZXIuVEFHLjEuREVGQVVMVC5keWNf
Y29weS4wCgkucXVhZAlfJDEuaW50ZXJwcmV0ZXIuVEFHLjEuREVGQVVMVC5k
eWNfY29weS4wCgkucXVhZAlfJDEuaW50ZXJwcmV0ZXIuVEFHLjEuREVGQVVM
VC5keWNfY29weS4wCgkucXVhZAlfJDEuaW50ZXJwcmV0ZXIuVEFHLjEuREVG
QVVMVC5keWNfY29weS4wCgkucXVhZAlfJDEuaW50ZXJwcmV0ZXIuVEFHLjEu
REVGQVVMVC5keWNfY29weS4wCgkucXVhZAlfJDEuaW50ZXJwcmV0ZXIuVEFH
LjEuREVGQVVMVC5keWNfY29weS4wCgkucXVhZAlfJDEuaW50ZXJwcmV0ZXIu
VEFHLjEuREVGQVVMVC5keWNfY29weS4wCgkucXVhZAlfJDEuaW50ZXJwcmV0
ZXIuVEFHLjEuREVGQVVMVC5keWNfY29weS4wCgkucXVhZAlfJDEuaW50ZXJw
cmV0ZXIuVEFHLjEuREVGQVVMVC5keWNfY29weS4wCgkucXVhZAlfJDEuaW50
ZXJwcmV0ZXIuVEFHLjEuREVGQVVMVC5keWNfY29weS4wCgkucXVhZAlfJDEu
aW50ZXJwcmV0ZXIuVEFHLjEuREVGQVVMVC5keWNfY29weS4wCgkucXVhZAlf
JDEuaW50ZXJwcmV0ZXIuVEFHLjEuREVGQVVMVC5keWNfY29weS4wCgkucXVh
ZAlfJDEuaW50ZXJwcmV0ZXIuVEFHLjEuREVGQVVMVC5keWNfY29weS4wCgku
cXVhZAlfJDEuaW50ZXJwcmV0ZXIuVEFHLjEuMi5keWNfY29weS4wCmludGVy
cHJldGVyJDJEWUMuU1dJVENIQ09QWS5UQUdQQUNLRVQuNi4wOgoJLnF1YWQJ
XyQxLmludGVycHJldGVyLlRBRy4zLjAuZHljX2NvcHkuMAoJLnF1YWQJXyQx
LmludGVycHJldGVyLlRBRy4zLjEuZHljX2NvcHkuMAoJLnF1YWQJXyQxLmlu
dGVycHJldGVyLlRBRy4zLkRFRkFVTFQuZHljX2NvcHkuMAoJLnF1YWQJXyQx
LmludGVycHJldGVyLlRBRy4zLkRFRkFVTFQuZHljX2NvcHkuMAoJLnF1YWQJ
XyQxLmludGVycHJldGVyLlRBRy4zLkRFRkFVTFQuZHljX2NvcHkuMAoJLnF1
YWQJXyQxLmludGVycHJldGVyLlRBRy4zLkRFRkFVTFQuZHljX2NvcHkuMAoJ
LnF1YWQJXyQxLmludGVycHJldGVyLlRBRy4zLkRFRkFVTFQuZHljX2NvcHku
MAoJLnF1YWQJXyQxLmludGVycHJldGVyLlRBRy4zLkRFRkFVTFQuZHljX2Nv
cHkuMAoJLnF1YWQJXyQxLmludGVycHJldGVyLlRBRy4zLkRFRkFVTFQuZHlj
X2NvcHkuMAoJLnF1YWQJXyQxLmludGVycHJldGVyLlRBRy4zLkRFRkFVTFQu
ZHljX2NvcHkuMAoJLnF1YWQJXyQxLmludGVycHJldGVyLlRBRy4zLkRFRkFV
TFQuZHljX2NvcHkuMAoJLnF1YWQJXyQxLmludGVycHJldGVyLlRBRy4zLkRF
RkFVTFQuZHljX2NvcHkuMAoJLnF1YWQJXyQxLmludGVycHJldGVyLlRBRy4z
LkRFRkFVTFQuZHljX2NvcHkuMAoJLnF1YWQJXyQxLmludGVycHJldGVyLlRB
Ry4zLkRFRkFVTFQuZHljX2NvcHkuMAoJLnF1YWQJXyQxLmludGVycHJldGVy
LlRBRy4zLkRFRkFVTFQuZHljX2NvcHkuMAoJLnF1YWQJXyQxLmludGVycHJl
dGVyLlRBRy4zLkRFRkFVTFQuZHljX2NvcHkuMAoJLnF1YWQJXyQxLmludGVy
cHJldGVyLlRBRy4zLkRFRkFVTFQuZHljX2NvcHkuMAoJLnF1YWQJXyQxLmlu
dGVycHJldGVyLlRBRy4zLkRFRkFVTFQuZHljX2NvcHkuMAoJLnF1YWQJXyQx
LmludGVycHJldGVyLlRBRy4zLkRFRkFVTFQuZHljX2NvcHkuMAoJLnF1YWQJ
XyQxLmludGVycHJldGVyLlRBRy4zLkRFRkFVTFQuZHljX2NvcHkuMAoJLnF1
YWQJXyQxLmludGVycHJldGVyLlRBRy4zLkRFRkFVTFQuZHljX2NvcHkuMAoJ
LnF1YWQJXyQxLmludGVycHJldGVyLlRBRy4zLkRFRkFVTFQuZHljX2NvcHku
MAoJLnF1YWQJXyQxLmludGVycHJldGVyLlRBRy4zLkRFRkFVTFQuZHljX2Nv
cHkuMAoJLnF1YWQJXyQxLmludGVycHJldGVyLlRBRy4zLkRFRkFVTFQuZHlj
X2NvcHkuMAoJLnF1YWQJXyQxLmludGVycHJldGVyLlRBRy4zLkRFRkFVTFQu
ZHljX2NvcHkuMAoJLnF1YWQJXyQxLmludGVycHJldGVyLlRBRy4zLkRFRkFV
TFQuZHljX2NvcHkuMAoJLnF1YWQJXyQxLmludGVycHJldGVyLlRBRy4zLkRF
RkFVTFQuZHljX2NvcHkuMAoJLnF1YWQJXyQxLmludGVycHJldGVyLlRBRy4z
LkRFRkFVTFQuZHljX2NvcHkuMAoJLnF1YWQJXyQxLmludGVycHJldGVyLlRB
Ry4zLkRFRkFVTFQuZHljX2NvcHkuMAoJLnF1YWQJXyQxLmludGVycHJldGVy
LlRBRy4zLkRFRkFVTFQuZHljX2NvcHkuMAoJLnF1YWQJXyQxLmludGVycHJl
dGVyLlRBRy4zLjIuZHljX2NvcHkuMAoJLnNwYWNlCTE2CgkuYWxpZ24gMwpD
UyQyOgoJLmJ5dGUJMHhmMCwgMHhmNAoJLmJ5dGUJMHhmMCwgMHhmYSwgMHhm
YgoJLmJ5dGUJMCwgMCwgMAoJLmFsaWduIDUKXyQxU1RSSU5HUEFDS0VULjI6
CgkuYnl0ZQk1MAoJLmJ5dGUJMzIKCS5ieXRlCTk3CgkuYnl0ZQkxMTQKCS5i
eXRlCTEwMwoJLmJ5dGUJMTE3CgkuYnl0ZQkxMDkKCS5ieXRlCTEwMQoJLmJ5
dGUJMTEwCgkuYnl0ZQkxMTYKCS5ieXRlCTExNQoJLmJ5dGUJMzIKCS5ieXRl
CTExMAoJLmJ5dGUJMTAxCgkuYnl0ZQkxMDEKCS5ieXRlCTEwMAoJLmJ5dGUJ
MTAxCgkuYnl0ZQkxMDAKCS5ieXRlCTU4CgkuYnl0ZQkzMgoJLmJ5dGUJMzcK
CS5ieXRlCTExNQoJLmJ5dGUJMzIKCS5ieXRlCTM3CgkuYnl0ZQkzNwoJLmJ5
dGUJMTAwCgkuYnl0ZQkzMgoJLmJ5dGUJMzcKCS5ieXRlCTM3CgkuYnl0ZQkx
MDAKCS5ieXRlCTEwCgkuYnl0ZQkwCl8kMVNUUklOR1BBQ0tFVC4zOgoJLmJ5
dGUJNzMKCS5ieXRlCTExMAoJLmJ5dGUJMTE4CgkuYnl0ZQk5NwoJLmJ5dGUJ
MTA4CgkuYnl0ZQkxMDUKCS5ieXRlCTEwMAoJLmJ5dGUJMzIKCS5ieXRlCTEx
MAoJLmJ5dGUJMTE3CgkuYnl0ZQkxMDkKCS5ieXRlCTk4CgkuYnl0ZQkxMDEK
CS5ieXRlCTExNAoJLmJ5dGUJMzIKCS5ieXRlCTExMQoJLmJ5dGUJMTAyCgku
Ynl0ZQkzMgoJLmJ5dGUJMTE0CgkuYnl0ZQkxMTcKCS5ieXRlCTExMAoJLmJ5
dGUJMTE1CgkuYnl0ZQkzMgoJLmJ5dGUJMTE1CgkuYnl0ZQkxMTIKCS5ieXRl
CTEwMQoJLmJ5dGUJOTkKCS5ieXRlCTEwNQoJLmJ5dGUJMTAyCgkuYnl0ZQkx
MDUKCS5ieXRlCTEwMQoJLmJ5dGUJMTAwCgkuYnl0ZQk1OAoJLmJ5dGUJMzIK
CS5ieXRlCTM3CgkuYnl0ZQkxMDAKCS5ieXRlCTEwCgkuYnl0ZQkwCgkuc3Bh
Y2UJMgpfJDFTVFJJTkdQQUNLRVQuNDoKCS5ieXRlCTY1CgkuYnl0ZQkxMTAK
CS5ieXRlCTExNQoJLmJ5dGUJMTE5CgkuYnl0ZQkxMDEKCS5ieXRlCTExNAoJ
LmJ5dGUJNDQKCS5ieXRlCTMyCgkuYnl0ZQkzNwoJLmJ5dGUJMTAwCgkuYnl0
ZQk0NAoJLmJ5dGUJMzIKCS5ieXRlCTMyCgkuYnl0ZQkxMDAKCS5ieXRlCTEx
MQoJLmJ5dGUJMTAxCgkuYnl0ZQkxMTUKCS5ieXRlCTExMAoJLmJ5dGUJMzkK
CS5ieXRlCTExNgoJLmJ5dGUJMzIKCS5ieXRlCTEwOQoJLmJ5dGUJOTcKCS5i
eXRlCTExNgoJLmJ5dGUJOTkKCS5ieXRlCTEwNAoJLmJ5dGUJMzIKCS5ieXRl
CTEwMgoJLmJ5dGUJMTA1CgkuYnl0ZQkxMTQKCS5ieXRlCTExNQoJLmJ5dGUJ
MTE2CgkuYnl0ZQkzMgoJLmJ5dGUJMTE0CgkuYnl0ZQkxMDEKCS5ieXRlCTEx
NQoJLmJ5dGUJMTE3CgkuYnl0ZQkxMDgKCS5ieXRlCTExNgoJLmJ5dGUJNTgK
CS5ieXRlCTMyCgkuYnl0ZQkzNwoJLmJ5dGUJMTAwCgkuYnl0ZQkxMAoJLmJ5
dGUJMAoJLnNwYWNlCTMKXyQxUEFDS0VULjc5OgoJLmxvbmcJNjkxNDA0ODEK
CS5sb25nCTY3MjM5OTM2CgkubG9uZwkyMDU1ODY0MzYKCS5sb25nCTE5OTM1
ODQ2NAoJLmxvbmcJMzM3NzA3MDA5CgkubG9uZwk0MDI2NTMxODYKCS5sb25n
CTI2ODQzNTQ1NgpfJDFTVFJJTkdQQUNLRVQuNToKCS5ieXRlCTY1CgkuYnl0
ZQkxMTAKCS5ieXRlCTExNQoJLmJ5dGUJMTE5CgkuYnl0ZQkxMDEKCS5ieXRl
CTExNAoJLmJ5dGUJMTE1CgkuYnl0ZQkzMgoJLmJ5dGUJMTA5CgkuYnl0ZQk5
NwoJLmJ5dGUJMTE2CgkuYnl0ZQk5OQoJLmJ5dGUJMTA0CgkuYnl0ZQk1OAoJ
LmJ5dGUJMzIKCS5ieXRlCTM3CgkuYnl0ZQkxMDAKCS5ieXRlCTEwCgkuYnl0
ZQkwCgkuc3BhY2UJMjUKLmV4dGVybglEeUNSVF9EdW1teUdsb2JhbAkgIyBz
aXplIDgsIGFsaWduIDMKLmV4dGVybglEeUNSVF9Cb2d1c0xTVkdsb2JhbAkg
IyBzaXplIDgsIGFsaWduIDMKLmV4dGVybglEeUNfTWVtb3J5TG9jYXRpb24J
ICMgc2l6ZSA4LCBhbGlnbiAzCi5leHRlcm4JRHlDUlRfUGFkZGVkQnl0ZXMJ
ICMgc2l6ZSA4LCBhbGlnbiAzCi5leHRlcm4JRHlDUlRfQnVpbGRUYWJsZVBv
aW50ZXIJICMgc2l6ZSA4LCBhbGlnbiAyCi5leHRlcm4JRHlDUlRfTGFzdEJy
YW5jaDIJICMgc2l6ZSA4LCBhbGlnbiAzCi5leHRlcm4JRHlDUlRfTGFzdEJy
YW5jaAkgIyBzaXplIDgsIGFsaWduIDMKLmV4dGVybglEeUNSVF9CcmFuY2hJ
bmRleAkgIyBzaXplIDgsIGFsaWduIDIKLmV4dGVybglEeUNSVF9Xb3JrTGlz
dEZyZWVMaXN0CSAjIHNpemUgOCwgYWxpZ24gMwouZXh0ZXJuCUR5Q1JUX1dv
cmtMaXN0CSAjIHNpemUgOCwgYWxpZ24gMwouZXh0ZXJuCUR5Q1JUX1NWVElu
ZGV4CSAjIHNpemUgOCwgYWxpZ24gMgouZXh0ZXJuCUR5Q1JUX1N0YXRpY1Zh
bHVlVGFibGUJICMgc2l6ZSA4LCBhbGlnbiAzCi5leHRlcm4JRHlDUlRfU3Rp
dGNoTG9jYXRpb24JICMgc2l6ZSA4LCBhbGlnbiAzCi5leHRlcm4JRHlDUlRf
VGVtcExvY2F0aW9uCSAjIHNpemUgOCwgYWxpZ24gMwouZXh0ZXJuCUR5Q1JU
X1RhYmxlTG9jYXRpb24JICMgc2l6ZSA4LCBhbGlnbiAzCi5leHRlcm4JRHlD
UlRfQ29kZUxvY2F0aW9uCSAjIHNpemUgOCwgYWxpZ24gMwouZXh0ZXJuCUR5
Q1JUX1RhYmxlUG9pbnRlckluZGV4CSAjIHNpemUgOCwgYWxpZ24gMgouc2Rh
dGEKCS5hbGlnbiA1CgkuYWxpZ24gNQoJLmFsaWduIDUKaW50ZXJwcmV0ZXIu
TFNWRnJlZUxpc3QuMjoKCS5zcGFjZQk4CmludGVycHJldGVyLkNhY2hlLjI6
Cgkuc3BhY2UJOAppbnRlcnByZXRlci5DYWNoZS4zOgoJLnNwYWNlCTgKaW50
ZXJwcmV0ZXIuTFNWRnJlZUxpc3QuMToKCS5zcGFjZQk4CmludGVycHJldGVy
LkxTVkZyZWVMaXN0LjQ6Cgkuc3BhY2UJOAppbnRlcnByZXRlci5DYWNoZS40
OgoJLnNwYWNlCTgKaW50ZXJwcmV0ZXIuTFNWRnJlZUxpc3QuMzoKCS5zcGFj
ZQk4Cgkuc3BhY2UJOAoJLmFsaWduIDUKaW50ZXJwcmV0ZXIuQ2FjaGUuMToK
CS5xdWFkCWludGVycHJldGVyLkRZQy5MQVpZX0VER0VfVEFSR0VULjAKXyQx
U1RSSU5HUEFDS0VULjE6CgkuYnl0ZQk3MwoJLmJ5dGUJMTA4CgkuYnl0ZQkx
MDgKCS5ieXRlCTEwMQoJLmJ5dGUJMTAzCgkuYnl0ZQk5NwoJLmJ5dGUJMTA4
CgkuYnl0ZQkzMgoJLmJ5dGUJMTExCgkuYnl0ZQkxMTIKCS5ieXRlCTk5Cgku
Ynl0ZQkxMTEKCS5ieXRlCTEwMAoJLmJ5dGUJMTAxCgkuYnl0ZQkxMAoJLmJ5
dGUJMAoJLnNwYWNlCTgKLnRleHQKICNtYXJrX2JlZ2luOwogI21hcmtfZW50
cnkgY2FsbGVyX3NhdmVzLCByZWdzLCBhdHlwZXMobjY0LG4zMixuMzIpOwoJ
LmVudAlpbnRlcnByZXRlcgoJLmdsb2JsCWludGVycHJldGVyCmludGVycHJl
dGVyOgogI21hcmtfdHJhY2UgMTExOwogI2luc3RyCi5sb2MgMiAyNgoJbGRh
CSRzcCwtJDIuMSQyYXV0b19zaXplKCRzcCkJICNjbGFzcyBzb3VyY2UJICMg
bGluZSAyNiwgPD50NTMzLCAkMi4xJDJhdXRvX3NpemUoSTMyKQoJbGRxCSQy
NyxpbnRlcnByZXRlci5DYWNoZS4xCSAjY2xhc3Mgc291cmNlCSAjIGxpbmUg
MCwgPD50MTEwMywgPD50NTM2LCBhZGRyKGludGVycHJldGVyLkNhY2hlLlZB
Ui4xKShQNjQpCiAjaW5zdHIKLmxvYyAyIDIwCglhZGRxCSRzcCxfJDFQQUNL
RVQuNiwkMQkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDIwLCA8PnQwLCA8PnQ1
MzMsIG9mZnNldChfcmVnJDEuMik9MHgwKFA2NCkKCWNweXMJJGYzMSwkZjMx
LCRmMzEJIyBwYWQKICNpbnN0cgoJc3RxCSQyNiwkMi4xJDJyYXNfcCgkc3Ap
CSAjY2xhc3MgZG1vdmUsZG1fc3BpbGwJICMgPD50NTMyCglvcgkkMjYsJDMx
LCQwCSAjY2xhc3MgZG1vdmUsZG1fcmVnaXN0ZXIJICMgPD50NTMyCgkgIyBz
dGFsbCAJMQogI2luc3RyCglqbXAJJDMxLCgkMjcpCSAjY2xhc3Mgc291cmNl
CSAjIGxpbmUgMCwgPD50MTEwMwogI21hcmtfdHJhY2UgMTY0OwppbnRlcnBy
ZXRlci5EWUMuVU5JVF9IRUFELlRFTVBMQVRFLjE6CmludGVycHJldGVyLmR5
bl90ZW1wbGF0ZV9iZWdpbl8wOgogI2luc3RyCi5sb2MgMiAyOQoJb3IJJDE4
LCQzMSwkMTgJICNjbGFzcyBzb3VyY2UJICMgbGluZSAyOSwgPF9tdWx0MSQx
LjI+dDEsIDxfYXJnJDEuMT50NDUzCgkgIyBzdGFsbCAJMQogI2luc3RyCglz
dHEJJDMxLER5Q1JUX0R1bW15R2xvYmFsCSAjY2xhc3Mgc291cmNlCSAjIGxp
bmUgMCwgMHgwKFA2NCksIDw+dDUzNiwgYWRkcihfRHlDUlRfRHVtbXlHbG9i
YWwkMS45KShQNjQpLCAwKEkzMiksIDAoSTMyKSwgMChJMzIpLCAwKEkzMikK
CSAjIHN0YWxsIAkxCmludGVycHJldGVyLkRZQy5OT19CUkFOQ0guRC4yLkIu
MTYzOgppbnRlcnByZXRlci5keW5fdGVtcGxhdGVfZW5kXzBfbjoKICNpbnN0
cgoJc3RxCSQzMSxEeUNSVF9EdW1teUdsb2JhbAkgI2NsYXNzIHNvdXJjZQkg
IyBsaW5lIDAsIDB4MChQNjQpLCA8PnQ1MzYsIGFkZHIoX0R5Q1JUX0R1bW15
R2xvYmFsJDEuOSkoUDY0KSwgMChJMzIpLCAwKEkzMiksIDAoSTMyKSwgMChJ
MzIpCiAjbWFya190cmFjZSAxNjU7CiAjaW5zdHIKCXN0cQkkMCwkMi4xJDJy
YXNfcCgkc3ApCSAjY2xhc3MgZG1vdmUsZG1fc3BpbGwJICMgPD50NTMyCgls
ZGEJJDI3LGludGVycHJldGVyLnN0YXRpY19icmFuY2hfMV8wKCQzMSkJICNj
bGFzcyBkbW92ZSxkbV9jb25zdGFudAkgIyBpbnRlcnByZXRlci5zdGF0aWNf
YnJhbmNoXzFfMAogI2luc3RyCglsZGEJJDI1LGludGVycHJldGVyLnN0YXRp
Y19icmFuY2hfM18wKCQzMSkJICNjbGFzcyBkbW92ZSxkbV9jb25zdGFudAkg
IyBpbnRlcnByZXRlci5zdGF0aWNfYnJhbmNoXzNfMAogI2luc3RyCglvcgkk
MSwkMzEsJDIyCSAjY2xhc3MgZG1vdmUsZG1fcmVnaXN0ZXIJICMgPD50MAog
I2luc3RyCglvcgkkMTgsJDMxLCQxCSAjY2xhc3MgZG1vdmUsZG1fcmVnaXN0
ZXIJICMgPF9tdWx0MSQxLjI+dDEKICNpbnN0cgoJbGRhCSQyNCxpbnRlcnBy
ZXRlci5zdGF0aWNfYnJhbmNoXzRfMCgkMzEpCSAjY2xhc3MgZG1vdmUsZG1f
Y29uc3RhbnQJICMgaW50ZXJwcmV0ZXIuc3RhdGljX2JyYW5jaF80XzAKICNp
bnN0cgoJbGRhCSQyMyxpbnRlcnByZXRlci5zdGF0aWNfYnJhbmNoXzZfMCgk
MzEpCSAjY2xhc3MgZG1vdmUsZG1fY29uc3RhbnQJICMgaW50ZXJwcmV0ZXIu
c3RhdGljX2JyYW5jaF82XzAKICNpbnN0cgoJb3IJJDIxLCQzMSwkMAkgI2Ns
YXNzIGRtb3ZlLGRtX3JlZ2lzdGVyCSAjIDxfbXVsdDIkMS4yPnQzCgkgIyBz
dGFsbCAJMQogI21hcmtfdHJhY2UgMjc7CkwwJDM6CmludGVycHJldGVyLkRZ
Qy5VTklUX0hFQUQuVEVNUExBVEUuMjoKaW50ZXJwcmV0ZXIuZHluX3RlbXBs
YXRlX2JlZ2luXzE6CiAjaW5zdHIKCXN0cQkkMzEsRHlDUlRfRHVtbXlHbG9i
YWwJICNjbGFzcyBzb3VyY2UJICMgbGluZSAwLCAweDAoUDY0KSwgPD50NTM2
LCBhZGRyKF9EeUNSVF9EdW1teUdsb2JhbCQxLjkpKFA2NCksIDAoSTMyKSwg
MChJMzIpLCAwKEkzMiksIDAoSTMyKQoJICMgc3RhbGwgCTEKICNpbnN0cgoJ
c3RxCSQzMSxEeUNSVF9EdW1teUdsb2JhbAkgI2NsYXNzIHNvdXJjZQkgIyBs
aW5lIDAsIDB4MChQNjQpLCA8PnQ1MzYsIGFkZHIoX0R5Q1JUX0R1bW15R2xv
YmFsJDEuOSkoUDY0KSwgMChJMzIpLCAwKEkzMiksIDAoSTMyKSwgMChJMzIp
CgkgIyBzdGFsbCAJMQppbnRlcnByZXRlci5EWUMuU1RBVElDX0JSQU5DSC5C
LjE2MjoKaW50ZXJwcmV0ZXIuZHluX3RlbXBsYXRlX2VuZF8xX246CiAjaW5z
dHIKLmxvYyAyIDExMgoJc3RhdGljX2JyYW5jaDogYm5lCSQyNyxMMSQzCSAj
Y2xhc3Mgc291cmNlCSAjIGxpbmUgMTEyLCBpbnRlcnByZXRlci5zdGF0aWNf
YnJhbmNoXzFfMAppbnRlcnByZXRlci5keW5fdGVtcGxhdGVfYmVnaW5fMzoK
ICNpbnN0cgogI2luc3RyCglzdHEJJDMxLER5Q1JUX0R1bW15R2xvYmFsCSAj
Y2xhc3Mgc291cmNlCSAjIGxpbmUgMCwgMHgwKFA2NCksIDw+dDUzNiwgYWRk
cihfRHlDUlRfRHVtbXlHbG9iYWwkMS45KShQNjQpLCAwKEkzMiksIDAoSTMy
KSwgMChJMzIpLCAwKEkzMikKCSAjIHN0YWxsIAkxCiAjaW5zdHIKCXN0cQkk
MzEsRHlDUlRfRHVtbXlHbG9iYWwJICNjbGFzcyBzb3VyY2UJICMgbGluZSAw
LCAweDAoUDY0KSwgPD50NTM2LCBhZGRyKF9EeUNSVF9EdW1teUdsb2JhbCQx
LjkpKFA2NCksIDAoSTMyKSwgMChJMzIpLCAwKEkzMiksIDAoSTMyKQoJICMg
c3RhbGwgCTEKaW50ZXJwcmV0ZXIuRFlDLlNUQVRJQ19CUkFOQ0guQi4xNjE6
CmludGVycHJldGVyLmR5bl90ZW1wbGF0ZV9lbmRfM19uOgogI2luc3RyCi5s
b2MgMiAxMTIKCXN0YXRpY19icmFuY2g6IGptcAkkMzEsKCQyNSkJICNjbGFz
cyBzb3VyY2UJICMgbGluZSAxMTIsIGludGVycHJldGVyLnN0YXRpY19icmFu
Y2hfM18wCl8kMS5pbnRlcnByZXRlci5UQUcuOC4wOgppbnRlcnByZXRlci5k
eW5fdGVtcGxhdGVfYmVnaW5fNDoKICNpbnN0cgogI2luc3RyCglzdHEJJDMx
LER5Q1JUX0R1bW15R2xvYmFsCSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMCwg
MHgwKFA2NCksIDw+dDUzNiwgYWRkcihfRHlDUlRfRHVtbXlHbG9iYWwkMS45
KShQNjQpLCAwKEkzMiksIDAoSTMyKSwgMChJMzIpLCAwKEkzMikKCSAjIHN0
YWxsIAkxCiAjaW5zdHIKCXN0cQkkMzEsRHlDUlRfRHVtbXlHbG9iYWwJICNj
bGFzcyBzb3VyY2UJICMgbGluZSAwLCAweDAoUDY0KSwgPD50NTM2LCBhZGRy
KF9EeUNSVF9EdW1teUdsb2JhbCQxLjkpKFA2NCksIDAoSTMyKSwgMChJMzIp
LCAwKEkzMiksIDAoSTMyKQoJICMgc3RhbGwgCTEKaW50ZXJwcmV0ZXIuRFlD
LlNUQVRJQ19CUkFOQ0guQi4xMzk6CmludGVycHJldGVyLmR5bl90ZW1wbGF0
ZV9lbmRfNF9uOgogI2luc3RyCi5sb2MgMiA0NgoJc3RhdGljX2JyYW5jaDog
Ym5lCSQyNCxMMiQzCSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgNDYsIGludGVy
cHJldGVyLnN0YXRpY19icmFuY2hfNF8wCmludGVycHJldGVyLmR5bl90ZW1w
bGF0ZV9iZWdpbl82OgogI2luc3RyCiAjaW5zdHIKCXN0cQkkMzEsRHlDUlRf
RHVtbXlHbG9iYWwJICNjbGFzcyBzb3VyY2UJICMgbGluZSAwLCAweDAoUDY0
KSwgPD50NTM2LCBhZGRyKF9EeUNSVF9EdW1teUdsb2JhbCQxLjkpKFA2NCks
IDAoSTMyKSwgMChJMzIpLCAwKEkzMiksIDAoSTMyKQoJICMgc3RhbGwgCTEK
ICNpbnN0cgoJc3RxCSQzMSxEeUNSVF9EdW1teUdsb2JhbAkgI2NsYXNzIHNv
dXJjZQkgIyBsaW5lIDAsIDB4MChQNjQpLCA8PnQ1MzYsIGFkZHIoX0R5Q1JU
X0R1bW15R2xvYmFsJDEuOSkoUDY0KSwgMChJMzIpLCAwKEkzMiksIDAoSTMy
KSwgMChJMzIpCgkgIyBzdGFsbCAJMQppbnRlcnByZXRlci5EWUMuU1RBVElD
X0JSQU5DSC5CLjI2NToKaW50ZXJwcmV0ZXIuZHluX3RlbXBsYXRlX2VuZF82
X246CiAjaW5zdHIKLmxvYyAyIDQ2CglzdGF0aWNfYnJhbmNoOiBqbXAJJDMx
LCgkMjMpCSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgNDYsIGludGVycHJldGVy
LnN0YXRpY19icmFuY2hfNl8wCl8kMS5pbnRlcnByZXRlci5UQUcuMC5ERUZB
VUxUOgppbnRlcnByZXRlci5keW5fdGVtcGxhdGVfYmVnaW5fNzoKICNpbnN0
cgogI2luc3RyCglzdHEJJDMxLER5Q1JUX0R1bW15R2xvYmFsCSAjY2xhc3Mg
c291cmNlCSAjIGxpbmUgMCwgMHgwKFA2NCksIDw+dDUzNiwgYWRkcihfRHlD
UlRfRHVtbXlHbG9iYWwkMS45KShQNjQpLCAwKEkzMiksIDAoSTMyKSwgMChJ
MzIpLCAwKEkzMikKCSAjIHN0YWxsIAkxCmludGVycHJldGVyLmR5bl90ZW1w
bGF0ZV9lbmRfN19uOgogI2luc3RyCglzdHEJJDMxLER5Q1JUX0R1bW15R2xv
YmFsCSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMCwgMHgwKFA2NCksIDw+dDUz
NiwgYWRkcihfRHlDUlRfRHVtbXlHbG9iYWwkMS45KShQNjQpLCAwKEkzMiks
IDAoSTMyKSwgMChJMzIpLCAwKEkzMikKTDMkMzoKaW50ZXJwcmV0ZXIuZHlu
X3RlbXBsYXRlX2JlZ2luXzg6CiAjaW5zdHIKICNpbnN0cgoJbGRhCSQyNyxp
bnRlcnByZXRlci5ydGNvbnN0XzhfMCgkMzEpCSAjY2xhc3Mgc291cmNlCSAj
IGxpbmUgMCwgPD50NjAxLCBpbnRlcnByZXRlci5ydGNvbnN0XzhfMAoJICMg
c3RhbGwgCTEKICNpbnN0cgoubG9jIDIgNDUKCWFkZHEJJDIyLCQyNywkMjcJ
ICNjbGFzcyBzb3VyY2UJICMgbGluZSA0NSwgPD50MTAxOSwgPD50MCwgPD50
NjAxCiAjaW5zdHIKLmxvYyAyIDQ1CglsZGEJJDI1LGludGVycHJldGVyLnJ0
Y29uc3RfOF8yKCQzMSkJICNjbGFzcyBzb3VyY2UJICMgbGluZSA0NSwgPD50
MTAxOCwgMChJMzIpLCBpbnRlcnByZXRlci5ydGNvbnN0XzhfMgoJICMgc3Rh
bGwgCTEKaW50ZXJwcmV0ZXIuZHluX3RlbXBsYXRlX2VuZF84X246CiAjaW5z
dHIKLmxvYyAyIDQ1CglzdGwJJDI1LDAoJDI3KQkgI2NsYXNzIHNvdXJjZQkg
IyBsaW5lIDQ1LCA8PnQxMDE4LCA8PnQxMDE5LCAwKEk2NCksIDAoSTMyKSwg
MChJMzIpLCAwKEkzMiksIDAoSTMyKQpMNCQzOgppbnRlcnByZXRlci5keW5f
dGVtcGxhdGVfYmVnaW5fMTI6CiAjaW5zdHIKICNpbnN0cgoJc3RxCSQzMSxE
eUNSVF9EdW1teUdsb2JhbAkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDAsIDB4
MChQNjQpLCA8PnQ1MzYsIGFkZHIoX0R5Q1JUX0R1bW15R2xvYmFsJDEuOSko
UDY0KSwgMChJMzIpLCAwKEkzMiksIDAoSTMyKSwgMChJMzIpCgkgIyBzdGFs
bCAJMQppbnRlcnByZXRlci5EWUMuTk9fQlJBTkNILkQuMi5CLjI1MzoKaW50
ZXJwcmV0ZXIuZHluX3RlbXBsYXRlX2VuZF8xMl9uOgogI2luc3RyCglzdHEJ
JDMxLER5Q1JUX0R1bW15R2xvYmFsCSAjY2xhc3Mgc291cmNlCSAjIGxpbmUg
MCwgMHgwKFA2NCksIDw+dDUzNiwgYWRkcihfRHlDUlRfRHVtbXlHbG9iYWwk
MS45KShQNjQpLCAwKEkzMiksIDAoSTMyKSwgMChJMzIpLCAwKEkzMikKICNt
YXJrX3RyYWNlIDI5OwogI2luc3RyCglsZGEJJDI3LGludGVycHJldGVyLnN0
YXRpY19icmFuY2hfMV8wKCQzMSkJICNjbGFzcyBkbW92ZSxkbV9jb25zdGFu
dAkgIyBpbnRlcnByZXRlci5zdGF0aWNfYnJhbmNoXzFfMAogI2luc3RyCgls
ZGEJJDI1LGludGVycHJldGVyLnN0YXRpY19icmFuY2hfM18wKCQzMSkJICNj
bGFzcyBkbW92ZSxkbV9jb25zdGFudAkgIyBpbnRlcnByZXRlci5zdGF0aWNf
YnJhbmNoXzNfMAogI2luc3RyCglsZGEJJDI0LGludGVycHJldGVyLnN0YXRp
Y19icmFuY2hfNF8wKCQzMSkJICNjbGFzcyBkbW92ZSxkbV9jb25zdGFudAkg
IyBpbnRlcnByZXRlci5zdGF0aWNfYnJhbmNoXzRfMAogI2luc3RyCglsZGEJ
JDIzLGludGVycHJldGVyLnN0YXRpY19icmFuY2hfNl8wKCQzMSkJICNjbGFz
cyBkbW92ZSxkbV9jb25zdGFudAkgIyBpbnRlcnByZXRlci5zdGF0aWNfYnJh
bmNoXzZfMAogI2luc3RyCglicgkkMzEsTDAkMwogI21hcmtfdHJhY2UgNjQ7
Cl8kMS5pbnRlcnByZXRlci5UQUcuMC4yOgppbnRlcnByZXRlci5keW5fdGVt
cGxhdGVfYmVnaW5fMTE6CiAjaW5zdHIKCXN0cQkkMzEsRHlDUlRfRHVtbXlH
bG9iYWwJICNjbGFzcyBzb3VyY2UJICMgbGluZSAwLCAweDAoUDY0KSwgPD50
NTM2LCBhZGRyKF9EeUNSVF9EdW1teUdsb2JhbCQxLjkpKFA2NCksIDAoSTMy
KSwgMChJMzIpLCAwKEkzMiksIDAoSTMyKQoJICMgc3RhbGwgCTEKICNpbnN0
cgoJc3RxCSQzMSxEeUNSVF9EdW1teUdsb2JhbAkgI2NsYXNzIHNvdXJjZQkg
IyBsaW5lIDAsIDB4MChQNjQpLCA8PnQ1MzYsIGFkZHIoX0R5Q1JUX0R1bW15
R2xvYmFsJDEuOSkoUDY0KSwgMChJMzIpLCAwKEkzMiksIDAoSTMyKSwgMChJ
MzIpCgkgIyBzdGFsbCAJMQogI2luc3RyCglsZGEJJDAsaW50ZXJwcmV0ZXIu
cnRjb25zdF8xMV8wKCQzMSkJICNjbGFzcyBzb3VyY2UJICMgbGluZSAwLCA8
X211bHQyJDEuMj50MywgaW50ZXJwcmV0ZXIucnRjb25zdF8xMV8wCmludGVy
cHJldGVyLmR5bl90ZW1wbGF0ZV9lbmRfMTFfbjoKICNpbnN0cgoJYnIJJDMx
LEw0JDMKICNtYXJrX3RyYWNlIDYwOwpfJDEuaW50ZXJwcmV0ZXIuVEFHLjAu
MToKaW50ZXJwcmV0ZXIuZHluX3RlbXBsYXRlX2JlZ2luXzEwOgogI2luc3Ry
CglzdHEJJDMxLER5Q1JUX0R1bW15R2xvYmFsCSAjY2xhc3Mgc291cmNlCSAj
IGxpbmUgMCwgMHgwKFA2NCksIDw+dDUzNiwgYWRkcihfRHlDUlRfRHVtbXlH
bG9iYWwkMS45KShQNjQpLCAwKEkzMiksIDAoSTMyKSwgMChJMzIpLCAwKEkz
MikKCSAjIHN0YWxsIAkxCiAjaW5zdHIKCXN0cQkkMzEsRHlDUlRfRHVtbXlH
bG9iYWwJICNjbGFzcyBzb3VyY2UJICMgbGluZSAwLCAweDAoUDY0KSwgPD50
NTM2LCBhZGRyKF9EeUNSVF9EdW1teUdsb2JhbCQxLjkpKFA2NCksIDAoSTMy
KSwgMChJMzIpLCAwKEkzMiksIDAoSTMyKQoJICMgc3RhbGwgCTEKICNpbnN0
cgoJbGRhCSQyLGludGVycHJldGVyLnJ0Y29uc3RfMTBfMCgkMzEpCSAjY2xh
c3Mgc291cmNlCSAjIGxpbmUgMCwgPF9tdWx0MSQxLjI+dDIsIGludGVycHJl
dGVyLnJ0Y29uc3RfMTBfMAppbnRlcnByZXRlci5keW5fdGVtcGxhdGVfZW5k
XzEwX246CiAjaW5zdHIKCWJyCSQzMSxMNCQzCiAjbWFya190cmFjZSA1ODsK
XyQxLmludGVycHJldGVyLlRBRy4wLjA6CmludGVycHJldGVyLmR5bl90ZW1w
bGF0ZV9iZWdpbl85OgogI2luc3RyCglzdHEJJDMxLER5Q1JUX0R1bW15R2xv
YmFsCSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMCwgMHgwKFA2NCksIDw+dDUz
NiwgYWRkcihfRHlDUlRfRHVtbXlHbG9iYWwkMS45KShQNjQpLCAwKEkzMiks
IDAoSTMyKSwgMChJMzIpLCAwKEkzMikKCSAjIHN0YWxsIAkxCiAjaW5zdHIK
CXN0cQkkMzEsRHlDUlRfRHVtbXlHbG9iYWwJICNjbGFzcyBzb3VyY2UJICMg
bGluZSAwLCAweDAoUDY0KSwgPD50NTM2LCBhZGRyKF9EeUNSVF9EdW1teUds
b2JhbCQxLjkpKFA2NCksIDAoSTMyKSwgMChJMzIpLCAwKEkzMiksIDAoSTMy
KQoJICMgc3RhbGwgCTEKICNpbnN0cgoJbGRhCSQxLGludGVycHJldGVyLnJ0
Y29uc3RfOV8wKCQzMSkJICNjbGFzcyBzb3VyY2UJICMgbGluZSAwLCA8X211
bHQxJDEuMj50MSwgaW50ZXJwcmV0ZXIucnRjb25zdF85XzAKaW50ZXJwcmV0
ZXIuZHluX3RlbXBsYXRlX2VuZF85X246CiAjaW5zdHIKCWJyCSQzMSxMNCQz
CiAjbWFya190cmFjZSAxMDY7CkwyJDM6CmludGVycHJldGVyLmR5bl90ZW1w
bGF0ZV9iZWdpbl81OgogI2luc3RyCglzdHEJJDMxLER5Q1JUX0R1bW15R2xv
YmFsCSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMCwgMHgwKFA2NCksIDw+dDUz
NiwgYWRkcihfRHlDUlRfRHVtbXlHbG9iYWwkMS45KShQNjQpLCAwKEkzMiks
IDAoSTMyKSwgMChJMzIpLCAwKEkzMikKCSAjIHN0YWxsIAkxCmludGVycHJl
dGVyLmR5bl90ZW1wbGF0ZV9lbmRfNV9uOgogI2luc3RyCglzdHEJJDMxLER5
Q1JUX0R1bW15R2xvYmFsCSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMCwgMHgw
KFA2NCksIDw+dDUzNiwgYWRkcihfRHlDUlRfRHVtbXlHbG9iYWwkMS45KShQ
NjQpLCAwKEkzMiksIDAoSTMyKSwgMChJMzIpLCAwKEkzMikKICNpbnN0cgoJ
YnIJJDMxLEwzJDMKICNtYXJrX3RyYWNlIDM1OwpfJDEuaW50ZXJwcmV0ZXIu
VEFHLjguNToKaW50ZXJwcmV0ZXIuZHluX3RlbXBsYXRlX2JlZ2luXzc1Ogog
I2luc3RyCglzdHEJJDMxLER5Q1JUX0R1bW15R2xvYmFsCSAjY2xhc3Mgc291
cmNlCSAjIGxpbmUgMCwgMHgwKFA2NCksIDw+dDUzNiwgYWRkcihfRHlDUlRf
RHVtbXlHbG9iYWwkMS45KShQNjQpLCAwKEkzMiksIDAoSTMyKSwgMChJMzIp
LCAwKEkzMikKCSAjIHN0YWxsIAkxCmludGVycHJldGVyLkRZQy5OT19CUkFO
Q0guRC4yLkIuMTY3OgppbnRlcnByZXRlci5keW5fdGVtcGxhdGVfZW5kXzc1
X246CiAjaW5zdHIKCXN0cQkkMzEsRHlDUlRfRHVtbXlHbG9iYWwJICNjbGFz
cyBzb3VyY2UJICMgbGluZSAwLCAweDAoUDY0KSwgPD50NTM2LCBhZGRyKF9E
eUNSVF9EdW1teUdsb2JhbCQxLjkpKFA2NCksIDAoSTMyKSwgMChJMzIpLCAw
KEkzMiksIDAoSTMyKQogI21hcmtfdHJhY2UgMzI7CiAjaW5zdHIKCWxkYQkk
MjcsaW50ZXJwcmV0ZXIuc3RhdGljX2JyYW5jaF8xXzAoJDMxKQkgI2NsYXNz
IGRtb3ZlLGRtX2NvbnN0YW50CSAjIGludGVycHJldGVyLnN0YXRpY19icmFu
Y2hfMV8wCiAjaW5zdHIKCWxkYQkkMjUsaW50ZXJwcmV0ZXIuc3RhdGljX2Jy
YW5jaF8zXzAoJDMxKQkgI2NsYXNzIGRtb3ZlLGRtX2NvbnN0YW50CSAjIGlu
dGVycHJldGVyLnN0YXRpY19icmFuY2hfM18wCiAjaW5zdHIKCWxkYQkkMjQs
aW50ZXJwcmV0ZXIuc3RhdGljX2JyYW5jaF80XzAoJDMxKQkgI2NsYXNzIGRt
b3ZlLGRtX2NvbnN0YW50CSAjIGludGVycHJldGVyLnN0YXRpY19icmFuY2hf
NF8wCiAjaW5zdHIKCWxkYQkkMjMsaW50ZXJwcmV0ZXIuc3RhdGljX2JyYW5j
aF82XzAoJDMxKQkgI2NsYXNzIGRtb3ZlLGRtX2NvbnN0YW50CSAjIGludGVy
cHJldGVyLnN0YXRpY19icmFuY2hfNl8wCiAjaW5zdHIKCWJyCSQzMSxMMCQz
CgliaXMJJDMxLCQzMSwkMzEJIyBwYWQKICNtYXJrX3RyYWNlIDM3OwpfJDEu
aW50ZXJwcmV0ZXIuVEFHLjguNDoKaW50ZXJwcmV0ZXIuZHluX3RlbXBsYXRl
X2JlZ2luXzU4OgogI2luc3RyCglzdHEJJDMxLER5Q1JUX0R1bW15R2xvYmFs
CSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMCwgMHgwKFA2NCksIDw+dDUzNiwg
YWRkcihfRHlDUlRfRHVtbXlHbG9iYWwkMS45KShQNjQpLCAwKEkzMiksIDAo
STMyKSwgMChJMzIpLCAwKEkzMikKCWxkYQkkMjcsaW50ZXJwcmV0ZXIuc3Rh
dGljX2JyYW5jaF81OF8wKCQzMSkJICNjbGFzcyBkbW92ZSxkbV9jb25zdGFu
dAkgIyBpbnRlcnByZXRlci5zdGF0aWNfYnJhbmNoXzU4XzAKICNpbnN0cgoJ
bGRhCSQyNSxpbnRlcnByZXRlci5zdGF0aWNfYnJhbmNoXzYwXzAoJDMxKQkg
I2NsYXNzIGRtb3ZlLGRtX2NvbnN0YW50CSAjIGludGVycHJldGVyLnN0YXRp
Y19icmFuY2hfNjBfMAoJY3B5cwkkZjMxLCRmMzEsJGYzMQkjIHBhZAogI2lu
c3RyCglzdHEJJDMxLER5Q1JUX0R1bW15R2xvYmFsCSAjY2xhc3Mgc291cmNl
CSAjIGxpbmUgMCwgMHgwKFA2NCksIDw+dDUzNiwgYWRkcihfRHlDUlRfRHVt
bXlHbG9iYWwkMS45KShQNjQpLCAwKEkzMiksIDAoSTMyKSwgMChJMzIpLCAw
KEkzMikKCWxkYQkkMjQsaW50ZXJwcmV0ZXIuc3RhdGljX2JyYW5jaF82Nl8w
KCQzMSkJICNjbGFzcyBkbW92ZSxkbV9jb25zdGFudAkgIyBpbnRlcnByZXRl
ci5zdGF0aWNfYnJhbmNoXzY2XzAKICNpbnN0cgoJbGRhCSQyMyxpbnRlcnBy
ZXRlci5zdGF0aWNfYnJhbmNoXzY4XzAoJDMxKQkgI2NsYXNzIGRtb3ZlLGRt
X2NvbnN0YW50CSAjIGludGVycHJldGVyLnN0YXRpY19icmFuY2hfNjhfMApp
bnRlcnByZXRlci5EWUMuU1RBVElDX0JSQU5DSC5CLjE2MDoKaW50ZXJwcmV0
ZXIuZHluX3RlbXBsYXRlX2VuZF81OF9uOgogI2luc3RyCi5sb2MgMiA3NwoJ
c3RhdGljX2JyYW5jaDogYm5lCSQyNyxMNSQzCSAjY2xhc3Mgc291cmNlCSAj
IGxpbmUgNzcsIGludGVycHJldGVyLnN0YXRpY19icmFuY2hfNThfMAppbnRl
cnByZXRlci5keW5fdGVtcGxhdGVfYmVnaW5fNjA6CiAjaW5zdHIKICNpbnN0
cgoJc3RxCSQzMSxEeUNSVF9EdW1teUdsb2JhbAkgI2NsYXNzIHNvdXJjZQkg
IyBsaW5lIDAsIDB4MChQNjQpLCA8PnQ1MzYsIGFkZHIoX0R5Q1JUX0R1bW15
R2xvYmFsJDEuOSkoUDY0KSwgMChJMzIpLCAwKEkzMiksIDAoSTMyKSwgMChJ
MzIpCgkgIyBzdGFsbCAJMQogI2luc3RyCglzdHEJJDMxLER5Q1JUX0R1bW15
R2xvYmFsCSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMCwgMHgwKFA2NCksIDw+
dDUzNiwgYWRkcihfRHlDUlRfRHVtbXlHbG9iYWwkMS45KShQNjQpLCAwKEkz
MiksIDAoSTMyKSwgMChJMzIpLCAwKEkzMikKCSAjIHN0YWxsIAkxCmludGVy
cHJldGVyLkRZQy5TVEFUSUNfQlJBTkNILkIuMTU5OgppbnRlcnByZXRlci5k
eW5fdGVtcGxhdGVfZW5kXzYwX246CiAjaW5zdHIKLmxvYyAyIDc3CglzdGF0
aWNfYnJhbmNoOiBqbXAJJDMxLCgkMjUpCSAjY2xhc3Mgc291cmNlCSAjIGxp
bmUgNzcsIGludGVycHJldGVyLnN0YXRpY19icmFuY2hfNjBfMApfJDEuaW50
ZXJwcmV0ZXIuVEFHLjQuREVGQVVMVDoKaW50ZXJwcmV0ZXIuZHluX3RlbXBs
YXRlX2JlZ2luXzYxOgogI2luc3RyCiAjaW5zdHIKCXN0cQkkMzEsRHlDUlRf
RHVtbXlHbG9iYWwJICNjbGFzcyBzb3VyY2UJICMgbGluZSAwLCAweDAoUDY0
KSwgPD50NTM2LCBhZGRyKF9EeUNSVF9EdW1teUdsb2JhbCQxLjkpKFA2NCks
IDAoSTMyKSwgMChJMzIpLCAwKEkzMiksIDAoSTMyKQoJICMgc3RhbGwgCTEK
aW50ZXJwcmV0ZXIuZHluX3RlbXBsYXRlX2VuZF82MV9uOgogI2luc3RyCglz
dHEJJDMxLER5Q1JUX0R1bW15R2xvYmFsCSAjY2xhc3Mgc291cmNlCSAjIGxp
bmUgMCwgMHgwKFA2NCksIDw+dDUzNiwgYWRkcihfRHlDUlRfRHVtbXlHbG9i
YWwkMS45KShQNjQpLCAwKEkzMiksIDAoSTMyKSwgMChJMzIpLCAwKEkzMikK
TDYkMzoKaW50ZXJwcmV0ZXIuZHluX3RlbXBsYXRlX2JlZ2luXzYyOgogI2lu
c3RyCiAjaW5zdHIKLmxvYyAyIDc2CglsZGwJJDI3LGludGVycHJldGVyLnJ0
Y29uc3RfNjJfMSgkMjIpCSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgNzYsIDxf
c3VidDEkMS4yPnQ1MjQsIDw+dDAsIGludGVycHJldGVyLnJ0Y29uc3RfNjJf
MQoJICMgc3RhbGwgCTEKaW50ZXJwcmV0ZXIuZHluX3RlbXBsYXRlX2VuZF82
Ml9uOgogI2luc3RyCglzdHEJJDMxLER5Q1JUX0R1bW15R2xvYmFsCSAjY2xh
c3Mgc291cmNlCSAjIGxpbmUgMCwgMHgwKFA2NCksIDw+dDUzNiwgYWRkcihf
RHlDUlRfRHVtbXlHbG9iYWwkMS45KShQNjQpLCAwKEkzMiksIDAoSTMyKSwg
MChJMzIpLCAwKEkzMikKTDckMzoKaW50ZXJwcmV0ZXIuZHluX3RlbXBsYXRl
X2JlZ2luXzY2OgogI2luc3RyCiAjaW5zdHIKCXN0cQkkMzEsRHlDUlRfRHVt
bXlHbG9iYWwJICNjbGFzcyBzb3VyY2UJICMgbGluZSAwLCAweDAoUDY0KSwg
PD50NTM2LCBhZGRyKF9EeUNSVF9EdW1teUdsb2JhbCQxLjkpKFA2NCksIDAo
STMyKSwgMChJMzIpLCAwKEkzMiksIDAoSTMyKQoJICMgc3RhbGwgCTEKaW50
ZXJwcmV0ZXIuRFlDLlNUQVRJQ19CUkFOQ0guQi4xNTY6CmludGVycHJldGVy
LmR5bl90ZW1wbGF0ZV9lbmRfNjZfbjoKICNpbnN0cgoubG9jIDIgODMKCXN0
YXRpY19icmFuY2g6IGJuZQkkMjQsTDgkMwkgI2NsYXNzIHNvdXJjZQkgIyBs
aW5lIDgzLCBpbnRlcnByZXRlci5zdGF0aWNfYnJhbmNoXzY2XzAKaW50ZXJw
cmV0ZXIuZHluX3RlbXBsYXRlX2JlZ2luXzY4OgogI2luc3RyCiAjaW5zdHIK
CXN0cQkkMzEsRHlDUlRfRHVtbXlHbG9iYWwJICNjbGFzcyBzb3VyY2UJICMg
bGluZSAwLCAweDAoUDY0KSwgPD50NTM2LCBhZGRyKF9EeUNSVF9EdW1teUds
b2JhbCQxLjkpKFA2NCksIDAoSTMyKSwgMChJMzIpLCAwKEkzMiksIDAoSTMy
KQoJICMgc3RhbGwgCTEKICNpbnN0cgoJc3RxCSQzMSxEeUNSVF9EdW1teUds
b2JhbAkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDAsIDB4MChQNjQpLCA8PnQ1
MzYsIGFkZHIoX0R5Q1JUX0R1bW15R2xvYmFsJDEuOSkoUDY0KSwgMChJMzIp
LCAwKEkzMiksIDAoSTMyKSwgMChJMzIpCgkgIyBzdGFsbCAJMQppbnRlcnBy
ZXRlci5EWUMuU1RBVElDX0JSQU5DSC5CLjE1NToKaW50ZXJwcmV0ZXIuZHlu
X3RlbXBsYXRlX2VuZF82OF9uOgogI2luc3RyCi5sb2MgMiA4MwoJc3RhdGlj
X2JyYW5jaDogam1wCSQzMSwoJDIzKQkgI2NsYXNzIHNvdXJjZQkgIyBsaW5l
IDgzLCBpbnRlcnByZXRlci5zdGF0aWNfYnJhbmNoXzY4XzAKXyQxLmludGVy
cHJldGVyLlRBRy41LkRFRkFVTFQ6CmludGVycHJldGVyLmR5bl90ZW1wbGF0
ZV9iZWdpbl82OToKICNpbnN0cgogI2luc3RyCglzdHEJJDMxLER5Q1JUX0R1
bW15R2xvYmFsCSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMCwgMHgwKFA2NCks
IDw+dDUzNiwgYWRkcihfRHlDUlRfRHVtbXlHbG9iYWwkMS45KShQNjQpLCAw
KEkzMiksIDAoSTMyKSwgMChJMzIpLCAwKEkzMikKCSAjIHN0YWxsIAkxCmlu
dGVycHJldGVyLmR5bl90ZW1wbGF0ZV9lbmRfNjlfbjoKICNpbnN0cgoJc3Rx
CSQzMSxEeUNSVF9EdW1teUdsb2JhbAkgI2NsYXNzIHNvdXJjZQkgIyBsaW5l
IDAsIDB4MChQNjQpLCA8PnQ1MzYsIGFkZHIoX0R5Q1JUX0R1bW15R2xvYmFs
JDEuOSkoUDY0KSwgMChJMzIpLCAwKEkzMiksIDAoSTMyKSwgMChJMzIpCkw5
JDM6CmludGVycHJldGVyLmR5bl90ZW1wbGF0ZV9iZWdpbl83MDoKICNpbnN0
cgogI2luc3RyCi5sb2MgMiA4MgoJbGRhCSQyNywtaW50ZXJwcmV0ZXIucnRj
b25zdF83MF8wKCQyNykJICNjbGFzcyBzb3VyY2UJICMgbGluZSA4MiwgPD50
NDA0LCA8X3N1YnQxJDEuMj50NTI0LCBpbnRlcnByZXRlci5ydGNvbnN0Xzcw
XzAKCSAjIHN0YWxsIAkxCmludGVycHJldGVyLmR5bl90ZW1wbGF0ZV9lbmRf
NzBfbjoKICNpbnN0cgoubG9jIDIgODIKCXN0bAkkMjcsaW50ZXJwcmV0ZXIu
cnRjb25zdF83MF8yKCQyMikJICNjbGFzcyBzb3VyY2UJICMgbGluZSA4Miwg
PD50NDA0LCA8PnQwLCBpbnRlcnByZXRlci5ydGNvbnN0XzcwXzIsIDAoSTMy
KSwgMChJMzIpLCAwKEkzMiksIDAoSTMyKQpMMTAkMzoKaW50ZXJwcmV0ZXIu
ZHluX3RlbXBsYXRlX2JlZ2luXzc0OgogI2luc3RyCiAjaW5zdHIKCXN0cQkk
MzEsRHlDUlRfRHVtbXlHbG9iYWwJICNjbGFzcyBzb3VyY2UJICMgbGluZSAw
LCAweDAoUDY0KSwgPD50NTM2LCBhZGRyKF9EeUNSVF9EdW1teUdsb2JhbCQx
LjkpKFA2NCksIDAoSTMyKSwgMChJMzIpLCAwKEkzMiksIDAoSTMyKQoJICMg
c3RhbGwgCTEKaW50ZXJwcmV0ZXIuRFlDLk5PX0JSQU5DSC5ELjIuQi4xNzc6
CmludGVycHJldGVyLmR5bl90ZW1wbGF0ZV9lbmRfNzRfbjoKICNpbnN0cgoJ
c3RxCSQzMSxEeUNSVF9EdW1teUdsb2JhbAkgI2NsYXNzIHNvdXJjZQkgIyBs
aW5lIDAsIDB4MChQNjQpLCA8PnQ1MzYsIGFkZHIoX0R5Q1JUX0R1bW15R2xv
YmFsJDEuOSkoUDY0KSwgMChJMzIpLCAwKEkzMiksIDAoSTMyKSwgMChJMzIp
CiAjbWFya190cmFjZSAzMTsKICNpbnN0cgoJbGRhCSQyNyxpbnRlcnByZXRl
ci5zdGF0aWNfYnJhbmNoXzFfMCgkMzEpCSAjY2xhc3MgZG1vdmUsZG1fY29u
c3RhbnQJICMgaW50ZXJwcmV0ZXIuc3RhdGljX2JyYW5jaF8xXzAKICNpbnN0
cgoJbGRhCSQyNSxpbnRlcnByZXRlci5zdGF0aWNfYnJhbmNoXzNfMCgkMzEp
CSAjY2xhc3MgZG1vdmUsZG1fY29uc3RhbnQJICMgaW50ZXJwcmV0ZXIuc3Rh
dGljX2JyYW5jaF8zXzAKICNpbnN0cgoJbGRhCSQyNCxpbnRlcnByZXRlci5z
dGF0aWNfYnJhbmNoXzRfMCgkMzEpCSAjY2xhc3MgZG1vdmUsZG1fY29uc3Rh
bnQJICMgaW50ZXJwcmV0ZXIuc3RhdGljX2JyYW5jaF80XzAKICNpbnN0cgoJ
bGRhCSQyMyxpbnRlcnByZXRlci5zdGF0aWNfYnJhbmNoXzZfMCgkMzEpCSAj
Y2xhc3MgZG1vdmUsZG1fY29uc3RhbnQJICMgaW50ZXJwcmV0ZXIuc3RhdGlj
X2JyYW5jaF82XzAKICNpbnN0cgoJYnIJJDMxLEwwJDMKICNtYXJrX3RyYWNl
IDUzOwpfJDEuaW50ZXJwcmV0ZXIuVEFHLjUuMjoKaW50ZXJwcmV0ZXIuZHlu
X3RlbXBsYXRlX2JlZ2luXzczOgogI2luc3RyCi5sb2MgMiA4MQoJbGRhCSQw
LC1pbnRlcnByZXRlci5ydGNvbnN0XzczXzAoJDI3KQkgI2NsYXNzIHNvdXJj
ZQkgIyBsaW5lIDgxLCA8X211bHQyJDEuMj50MywgPF9zdWJ0MSQxLjI+dDUy
NCwgaW50ZXJwcmV0ZXIucnRjb25zdF83M18wCmludGVycHJldGVyLmR5bl90
ZW1wbGF0ZV9lbmRfNzNfbjoKICNpbnN0cgoJYnIJJDMxLEwxMCQzCiAjbWFy
a190cmFjZSA3MTsKXyQxLmludGVycHJldGVyLlRBRy41LjE6CmludGVycHJl
dGVyLmR5bl90ZW1wbGF0ZV9iZWdpbl83MjoKICNpbnN0cgoubG9jIDIgODAK
CWxkYQkkMiwtaW50ZXJwcmV0ZXIucnRjb25zdF83Ml8wKCQyNykJICNjbGFz
cyBzb3VyY2UJICMgbGluZSA4MCwgPF9tdWx0MSQxLjI+dDIsIDxfc3VidDEk
MS4yPnQ1MjQsIGludGVycHJldGVyLnJ0Y29uc3RfNzJfMAppbnRlcnByZXRl
ci5keW5fdGVtcGxhdGVfZW5kXzcyX246CiAjaW5zdHIKCWJyCSQzMSxMMTAk
MwogI21hcmtfdHJhY2UgNjg7Cl8kMS5pbnRlcnByZXRlci5UQUcuNS4wOgpp
bnRlcnByZXRlci5keW5fdGVtcGxhdGVfYmVnaW5fNzE6CiAjaW5zdHIKLmxv
YyAyIDc5CglsZGEJJDEsLWludGVycHJldGVyLnJ0Y29uc3RfNzFfMCgkMjcp
CSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgNzksIDxfbXVsdDEkMS4yPnQxLCA8
X3N1YnQxJDEuMj50NTI0LCBpbnRlcnByZXRlci5ydGNvbnN0XzcxXzAKaW50
ZXJwcmV0ZXIuZHluX3RlbXBsYXRlX2VuZF83MV9uOgogI2luc3RyCglicgkk
MzEsTDEwJDMKICNtYXJrX3RyYWNlIDEwNTsKTDgkMzoKaW50ZXJwcmV0ZXIu
ZHluX3RlbXBsYXRlX2JlZ2luXzY3OgogI2luc3RyCglzdHEJJDMxLER5Q1JU
X0R1bW15R2xvYmFsCSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMCwgMHgwKFA2
NCksIDw+dDUzNiwgYWRkcihfRHlDUlRfRHVtbXlHbG9iYWwkMS45KShQNjQp
LCAwKEkzMiksIDAoSTMyKSwgMChJMzIpLCAwKEkzMikKCSAjIHN0YWxsIAkx
CmludGVycHJldGVyLmR5bl90ZW1wbGF0ZV9lbmRfNjdfbjoKICNpbnN0cgoJ
c3RxCSQzMSxEeUNSVF9EdW1teUdsb2JhbAkgI2NsYXNzIHNvdXJjZQkgIyBs
aW5lIDAsIDB4MChQNjQpLCA8PnQ1MzYsIGFkZHIoX0R5Q1JUX0R1bW15R2xv
YmFsJDEuOSkoUDY0KSwgMChJMzIpLCAwKEkzMiksIDAoSTMyKSwgMChJMzIp
CiAjaW5zdHIKCWJyCSQzMSxMOSQzCiAjbWFya190cmFjZSA1MDsKXyQxLmlu
dGVycHJldGVyLlRBRy40LjI6CmludGVycHJldGVyLmR5bl90ZW1wbGF0ZV9i
ZWdpbl82NToKICNpbnN0cgoubG9jIDIgNzUKCW9yCSQwLCQzMSwkMjcJICNj
bGFzcyBzb3VyY2UJICMgbGluZSA3NSwgPF9zdWJ0MSQxLjI+dDUyNCwgPF9t
dWx0MiQxLjI+dDMKCSAjIHN0YWxsIAkxCmludGVycHJldGVyLmR5bl90ZW1w
bGF0ZV9lbmRfNjVfbjoKICNpbnN0cgoJc3RxCSQzMSxEeUNSVF9EdW1teUds
b2JhbAkgI2NsYXNzIHNvdXJjZSxyZWpvaW5fY29weQkgIyBsaW5lIDAsIDB4
MChQNjQpLCA8PnQ1MzYsIGFkZHIoX0R5Q1JUX0R1bW15R2xvYmFsJDEuOSko
UDY0KSwgMChJMzIpLCAwKEkzMiksIDAoSTMyKSwgMChJMzIpCiAjaW5zdHIK
CWJyCSQzMSxMNyQzCiAjbWFya190cmFjZSA3MDsKXyQxLmludGVycHJldGVy
LlRBRy40LjE6CmludGVycHJldGVyLmR5bl90ZW1wbGF0ZV9iZWdpbl82NDoK
ICNpbnN0cgoubG9jIDIgNzQKCW9yCSQyLCQzMSwkMjcJICNjbGFzcyBzb3Vy
Y2UJICMgbGluZSA3NCwgPF9zdWJ0MSQxLjI+dDUyNCwgPF9tdWx0MSQxLjI+
dDIKCSAjIHN0YWxsIAkxCmludGVycHJldGVyLmR5bl90ZW1wbGF0ZV9lbmRf
NjRfbjoKICNpbnN0cgoJc3RxCSQzMSxEeUNSVF9EdW1teUdsb2JhbAkgI2Ns
YXNzIHNvdXJjZSxyZWpvaW5fY29weQkgIyBsaW5lIDAsIDB4MChQNjQpLCA8
PnQ1MzYsIGFkZHIoX0R5Q1JUX0R1bW15R2xvYmFsJDEuOSkoUDY0KSwgMChJ
MzIpLCAwKEkzMiksIDAoSTMyKSwgMChJMzIpCiAjaW5zdHIKCWJyCSQzMSxM
NyQzCiAjbWFya190cmFjZSA1NjsKXyQxLmludGVycHJldGVyLlRBRy40LjA6
CmludGVycHJldGVyLmR5bl90ZW1wbGF0ZV9iZWdpbl82MzoKICNpbnN0cgou
bG9jIDIgNzMKCW9yCSQxLCQzMSwkMjcJICNjbGFzcyBzb3VyY2UJICMgbGlu
ZSA3MywgPF9zdWJ0MSQxLjI+dDUyNCwgPF9tdWx0MSQxLjI+dDEKCSAjIHN0
YWxsIAkxCmludGVycHJldGVyLmR5bl90ZW1wbGF0ZV9lbmRfNjNfbjoKICNp
bnN0cgoJc3RxCSQzMSxEeUNSVF9EdW1teUdsb2JhbAkgI2NsYXNzIHNvdXJj
ZSxyZWpvaW5fY29weQkgIyBsaW5lIDAsIDB4MChQNjQpLCA8PnQ1MzYsIGFk
ZHIoX0R5Q1JUX0R1bW15R2xvYmFsJDEuOSkoUDY0KSwgMChJMzIpLCAwKEkz
MiksIDAoSTMyKSwgMChJMzIpCiAjaW5zdHIKCWJyCSQzMSxMNyQzCiAjbWFy
a190cmFjZSAxMDk7Ckw1JDM6CmludGVycHJldGVyLmR5bl90ZW1wbGF0ZV9i
ZWdpbl81OToKICNpbnN0cgoJc3RxCSQzMSxEeUNSVF9EdW1teUdsb2JhbAkg
I2NsYXNzIHNvdXJjZQkgIyBsaW5lIDAsIDB4MChQNjQpLCA8PnQ1MzYsIGFk
ZHIoX0R5Q1JUX0R1bW15R2xvYmFsJDEuOSkoUDY0KSwgMChJMzIpLCAwKEkz
MiksIDAoSTMyKSwgMChJMzIpCgkgIyBzdGFsbCAJMQppbnRlcnByZXRlci5k
eW5fdGVtcGxhdGVfZW5kXzU5X246CiAjaW5zdHIKCXN0cQkkMzEsRHlDUlRf
RHVtbXlHbG9iYWwJICNjbGFzcyBzb3VyY2UJICMgbGluZSAwLCAweDAoUDY0
KSwgPD50NTM2LCBhZGRyKF9EeUNSVF9EdW1teUdsb2JhbCQxLjkpKFA2NCks
IDAoSTMyKSwgMChJMzIpLCAwKEkzMiksIDAoSTMyKQogI2luc3RyCglicgkk
MzEsTDYkMwogI21hcmtfdHJhY2UgMzY7Cl8kMS5pbnRlcnByZXRlci5UQUcu
OC4zOgppbnRlcnByZXRlci5keW5fdGVtcGxhdGVfYmVnaW5fNTc6CiAjaW5z
dHIKCXN0cQkkMzEsRHlDUlRfRHVtbXlHbG9iYWwJICNjbGFzcyBzb3VyY2UJ
ICMgbGluZSAwLCAweDAoUDY0KSwgPD50NTM2LCBhZGRyKF9EeUNSVF9EdW1t
eUdsb2JhbCQxLjkpKFA2NCksIDAoSTMyKSwgMChJMzIpLCAwKEkzMiksIDAo
STMyKQogI2luc3RyCglsZHEJJDI2LCQyLjEkMnJhc19wKCRzcCkJICNjbGFz
cyBkbW92ZSxkbV9yZXN0b3JlCSAjIDw+dDUzMgogI2luc3RyCglzdHEJJDMx
LER5Q1JUX0R1bW15R2xvYmFsCSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMCwg
MHgwKFA2NCksIDw+dDUzNiwgYWRkcihfRHlDUlRfRHVtbXlHbG9iYWwkMS45
KShQNjQpLCAwKEkzMiksIDAoSTMyKSwgMChJMzIpLCAwKEkzMikKCWNweXMJ
JGYzMSwkZjMxLCRmMzEJIyBwYWQKCSAjIHN0YWxsIAkxCmludGVycHJldGVy
LmR5bl90ZW1wbGF0ZV9lbmRfNTdfbjoKICNtYXJrX3JldHVybiBydHlwZXMo
bjMyKTsKICNpbnN0cgoubG9jIDIgMTA5CglsZGEJJHNwLCQyLjEkMmF1dG9f
c2l6ZSgkc3ApCglyZXQJJDMxLCgkMjYpLDEJICNjbGFzcyBzb3VyY2UJICMg
bGluZSAxMDksIDw+dDUzMywgJDIuMSQyYXV0b19zaXplKEkzMiksIDw+dDUz
MgogI21hcmtfdHJhY2UgMzQ7Cl8kMS5pbnRlcnByZXRlci5UQUcuOC4yOgpp
bnRlcnByZXRlci5keW5fdGVtcGxhdGVfYmVnaW5fMzg6CiAjaW5zdHIKCXN0
cQkkMzEsRHlDUlRfRHVtbXlHbG9iYWwJICNjbGFzcyBzb3VyY2UJICMgbGlu
ZSAwLCAweDAoUDY0KSwgPD50NTM2LCBhZGRyKF9EeUNSVF9EdW1teUdsb2Jh
bCQxLjkpKFA2NCksIDAoSTMyKSwgMChJMzIpLCAwKEkzMiksIDAoSTMyKQoJ
bGRhCSQyNyxpbnRlcnByZXRlci5zdGF0aWNfYnJhbmNoXzM4XzAoJDMxKQkg
I2NsYXNzIGRtb3ZlLGRtX2NvbnN0YW50CSAjIGludGVycHJldGVyLnN0YXRp
Y19icmFuY2hfMzhfMAogI2luc3RyCglsZGEJJDI1LGludGVycHJldGVyLnN0
YXRpY19icmFuY2hfNDBfMCgkMzEpCSAjY2xhc3MgZG1vdmUsZG1fY29uc3Rh
bnQJICMgaW50ZXJwcmV0ZXIuc3RhdGljX2JyYW5jaF80MF8wCgljcHlzCSRm
MzEsJGYzMSwkZjMxCSMgcGFkCiAjaW5zdHIKCXN0cQkkMzEsRHlDUlRfRHVt
bXlHbG9iYWwJICNjbGFzcyBzb3VyY2UJICMgbGluZSAwLCAweDAoUDY0KSwg
PD50NTM2LCBhZGRyKF9EeUNSVF9EdW1teUdsb2JhbCQxLjkpKFA2NCksIDAo
STMyKSwgMChJMzIpLCAwKEkzMiksIDAoSTMyKQoJbGRhCSQyNCxpbnRlcnBy
ZXRlci5zdGF0aWNfYnJhbmNoXzQ2XzAoJDMxKQkgI2NsYXNzIGRtb3ZlLGRt
X2NvbnN0YW50CSAjIGludGVycHJldGVyLnN0YXRpY19icmFuY2hfNDZfMAog
I2luc3RyCglsZGEJJDIzLGludGVycHJldGVyLnN0YXRpY19icmFuY2hfNDhf
MCgkMzEpCSAjY2xhc3MgZG1vdmUsZG1fY29uc3RhbnQJICMgaW50ZXJwcmV0
ZXIuc3RhdGljX2JyYW5jaF80OF8wCmludGVycHJldGVyLkRZQy5TVEFUSUNf
QlJBTkNILkIuMTU0OgppbnRlcnByZXRlci5keW5fdGVtcGxhdGVfZW5kXzM4
X246CiAjaW5zdHIKLmxvYyAyIDkzCglzdGF0aWNfYnJhbmNoOiBibmUJJDI3
LEwxMSQzCSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgOTMsIGludGVycHJldGVy
LnN0YXRpY19icmFuY2hfMzhfMAppbnRlcnByZXRlci5keW5fdGVtcGxhdGVf
YmVnaW5fNDA6CiAjaW5zdHIKICNpbnN0cgoJc3RxCSQzMSxEeUNSVF9EdW1t
eUdsb2JhbAkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDAsIDB4MChQNjQpLCA8
PnQ1MzYsIGFkZHIoX0R5Q1JUX0R1bW15R2xvYmFsJDEuOSkoUDY0KSwgMChJ
MzIpLCAwKEkzMiksIDAoSTMyKSwgMChJMzIpCgkgIyBzdGFsbCAJMQogI2lu
c3RyCglzdHEJJDMxLER5Q1JUX0R1bW15R2xvYmFsCSAjY2xhc3Mgc291cmNl
CSAjIGxpbmUgMCwgMHgwKFA2NCksIDw+dDUzNiwgYWRkcihfRHlDUlRfRHVt
bXlHbG9iYWwkMS45KShQNjQpLCAwKEkzMiksIDAoSTMyKSwgMChJMzIpLCAw
KEkzMikKCSAjIHN0YWxsIAkxCmludGVycHJldGVyLkRZQy5TVEFUSUNfQlJB
TkNILkIuMjYyOgppbnRlcnByZXRlci5keW5fdGVtcGxhdGVfZW5kXzQwX246
CiAjaW5zdHIKLmxvYyAyIDkzCglzdGF0aWNfYnJhbmNoOiBqbXAJJDMxLCgk
MjUpCSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgOTMsIGludGVycHJldGVyLnN0
YXRpY19icmFuY2hfNDBfMApfJDEuaW50ZXJwcmV0ZXIuVEFHLjYuREVGQVVM
VDoKaW50ZXJwcmV0ZXIuZHluX3RlbXBsYXRlX2JlZ2luXzQxOgogI2luc3Ry
CiAjaW5zdHIKCXN0cQkkMzEsRHlDUlRfRHVtbXlHbG9iYWwJICNjbGFzcyBz
b3VyY2UJICMgbGluZSAwLCAweDAoUDY0KSwgPD50NTM2LCBhZGRyKF9EeUNS
VF9EdW1teUdsb2JhbCQxLjkpKFA2NCksIDAoSTMyKSwgMChJMzIpLCAwKEkz
MiksIDAoSTMyKQoJICMgc3RhbGwgCTEKaW50ZXJwcmV0ZXIuZHluX3RlbXBs
YXRlX2VuZF80MV9uOgogI2luc3RyCglzdHEJJDMxLER5Q1JUX0R1bW15R2xv
YmFsCSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMCwgMHgwKFA2NCksIDw+dDUz
NiwgYWRkcihfRHlDUlRfRHVtbXlHbG9iYWwkMS45KShQNjQpLCAwKEkzMiks
IDAoSTMyKSwgMChJMzIpLCAwKEkzMikKTDEyJDM6CmludGVycHJldGVyLmR5
bl90ZW1wbGF0ZV9iZWdpbl80MjoKICNpbnN0cgogI2luc3RyCi5sb2MgMiA5
MgoJbGRsCSQyNyxpbnRlcnByZXRlci5ydGNvbnN0XzQyXzEoJDIyKQkgI2Ns
YXNzIHNvdXJjZQkgIyBsaW5lIDkyLCA8X2JldDEkMS4yPnQ1MjMsIDw+dDAs
IGludGVycHJldGVyLnJ0Y29uc3RfNDJfMQoJICMgc3RhbGwgCTEKaW50ZXJw
cmV0ZXIuZHluX3RlbXBsYXRlX2VuZF80Ml9uOgogI2luc3RyCglzdHEJJDMx
LER5Q1JUX0R1bW15R2xvYmFsCSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMCwg
MHgwKFA2NCksIDw+dDUzNiwgYWRkcihfRHlDUlRfRHVtbXlHbG9iYWwkMS45
KShQNjQpLCAwKEkzMiksIDAoSTMyKSwgMChJMzIpLCAwKEkzMikKTDEzJDM6
CmludGVycHJldGVyLmR5bl90ZW1wbGF0ZV9iZWdpbl80NjoKICNpbnN0cgog
I2luc3RyCglzdHEJJDMxLER5Q1JUX0R1bW15R2xvYmFsCSAjY2xhc3Mgc291
cmNlCSAjIGxpbmUgMCwgMHgwKFA2NCksIDw+dDUzNiwgYWRkcihfRHlDUlRf
RHVtbXlHbG9iYWwkMS45KShQNjQpLCAwKEkzMiksIDAoSTMyKSwgMChJMzIp
LCAwKEkzMikKCSAjIHN0YWxsIAkxCmludGVycHJldGVyLkRZQy5TVEFUSUNf
QlJBTkNILkIuMTUzOgppbnRlcnByZXRlci5keW5fdGVtcGxhdGVfZW5kXzQ2
X246CiAjaW5zdHIKLmxvYyAyIDk5CglzdGF0aWNfYnJhbmNoOiBibmUJJDI0
LEwxNCQzCSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgOTksIGludGVycHJldGVy
LnN0YXRpY19icmFuY2hfNDZfMAppbnRlcnByZXRlci5keW5fdGVtcGxhdGVf
YmVnaW5fNDg6CiAjaW5zdHIKICNpbnN0cgoJc3RxCSQzMSxEeUNSVF9EdW1t
eUdsb2JhbAkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDAsIDB4MChQNjQpLCA8
PnQ1MzYsIGFkZHIoX0R5Q1JUX0R1bW15R2xvYmFsJDEuOSkoUDY0KSwgMChJ
MzIpLCAwKEkzMiksIDAoSTMyKSwgMChJMzIpCgkgIyBzdGFsbCAJMQogI2lu
c3RyCglzdHEJJDMxLER5Q1JUX0R1bW15R2xvYmFsCSAjY2xhc3Mgc291cmNl
CSAjIGxpbmUgMCwgMHgwKFA2NCksIDw+dDUzNiwgYWRkcihfRHlDUlRfRHVt
bXlHbG9iYWwkMS45KShQNjQpLCAwKEkzMiksIDAoSTMyKSwgMChJMzIpLCAw
KEkzMikKCSAjIHN0YWxsIAkxCmludGVycHJldGVyLkRZQy5TVEFUSUNfQlJB
TkNILkIuMTQ5OgppbnRlcnByZXRlci5keW5fdGVtcGxhdGVfZW5kXzQ4X246
CiAjaW5zdHIKLmxvYyAyIDk5CglzdGF0aWNfYnJhbmNoOiBqbXAJJDMxLCgk
MjMpCSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgOTksIGludGVycHJldGVyLnN0
YXRpY19icmFuY2hfNDhfMApfJDEuaW50ZXJwcmV0ZXIuVEFHLjcuREVGQVVM
VDoKaW50ZXJwcmV0ZXIuZHluX3RlbXBsYXRlX2JlZ2luXzQ5OgogI2luc3Ry
CiAjaW5zdHIKCXN0cQkkMzEsRHlDUlRfRHVtbXlHbG9iYWwJICNjbGFzcyBz
b3VyY2UJICMgbGluZSAwLCAweDAoUDY0KSwgPD50NTM2LCBhZGRyKF9EeUNS
VF9EdW1teUdsb2JhbCQxLjkpKFA2NCksIDAoSTMyKSwgMChJMzIpLCAwKEkz
MiksIDAoSTMyKQoJICMgc3RhbGwgCTEKaW50ZXJwcmV0ZXIuZHluX3RlbXBs
YXRlX2VuZF80OV9uOgogI2luc3RyCglzdHEJJDMxLER5Q1JUX0R1bW15R2xv
YmFsCSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMCwgMHgwKFA2NCksIDw+dDUz
NiwgYWRkcihfRHlDUlRfRHVtbXlHbG9iYWwkMS45KShQNjQpLCAwKEkzMiks
IDAoSTMyKSwgMChJMzIpLCAwKEkzMikKTDE1JDM6CmludGVycHJldGVyLmR5
bl90ZW1wbGF0ZV9iZWdpbl81MDoKICNpbnN0cgogI2luc3RyCi5sb2MgMiA5
OAoJbGRsCSQyNSxpbnRlcnByZXRlci5ydGNvbnN0XzUwXzEoJDIyKQkgI2Ns
YXNzIHNvdXJjZQkgIyBsaW5lIDk4LCA8PnQ0MjcsIDw+dDAsIGludGVycHJl
dGVyLnJ0Y29uc3RfNTBfMQoJICMgc3RhbGwgCTIKICNpbnN0cgoubG9jIDIg
OTgKCWNtcGVxCSQyNSwkMjcsJDI3CSAjY2xhc3Mgc291cmNlCSAjIGxpbmUg
OTgsIDxfYmV0MyQxLjI+dDUyMiwgPD50NDI3LCA8X2JldDEkMS4yPnQ1MjMK
aW50ZXJwcmV0ZXIuZHluX3RlbXBsYXRlX2VuZF81MF9uOgogI2luc3RyCkwx
NiQzOgppbnRlcnByZXRlci5keW5fdGVtcGxhdGVfYmVnaW5fNTQ6CiAjaW5z
dHIKCXN0cQkkMzEsRHlDUlRfRHVtbXlHbG9iYWwJICNjbGFzcyBzb3VyY2UJ
ICMgbGluZSAwLCAweDAoUDY0KSwgPD50NTM2LCBhZGRyKF9EeUNSVF9EdW1t
eUdsb2JhbCQxLjkpKFA2NCksIDAoSTMyKSwgMChJMzIpLCAwKEkzMiksIDAo
STMyKQoJICMgc3RhbGwgCTEKICNpbnN0cgoJc3RxCSQzMSxEeUNSVF9EdW1t
eUdsb2JhbAkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDAsIDB4MChQNjQpLCA8
PnQ1MzYsIGFkZHIoX0R5Q1JUX0R1bW15R2xvYmFsJDEuOSkoUDY0KSwgMChJ
MzIpLCAwKEkzMiksIDAoSTMyKSwgMChJMzIpCgkgIyBzdGFsbCAJMQppbnRl
cnByZXRlci5EWUMuRFlOQU1JQ19CUkFOQ0guRC4zLkQuNC5CLjIwMToKaW50
ZXJwcmV0ZXIuZHluX3RlbXBsYXRlX2VuZF81NF9uOgogI2luc3RyCi5sb2Mg
MiAxMDEKCWJuZQkkMjcsTDE3JDMJICNjbGFzcyBzb3VyY2UJICMgbGluZSAx
MDEsIDxfYmV0MyQxLjI+dDUyMgogI21hcmtfdHJhY2UgNDI7CmludGVycHJl
dGVyLkRZQy5VTklUX0hFQUQuVEVNUExBVEUuNDoKaW50ZXJwcmV0ZXIuZHlu
X3RlbXBsYXRlX2JlZ2luXzU2OgogI2luc3RyCglzdHEJJDMxLER5Q1JUX0R1
bW15R2xvYmFsCSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMCwgMHgwKFA2NCks
IDw+dDUzNiwgYWRkcihfRHlDUlRfRHVtbXlHbG9iYWwkMS45KShQNjQpLCAw
KEkzMiksIDAoSTMyKSwgMChJMzIpLCAwKEkzMikKCSAjIHN0YWxsIAkxCmlu
dGVycHJldGVyLkRZQy5OT19CUkFOQ0guRC4yLkIuMjAyOgppbnRlcnByZXRl
ci5keW5fdGVtcGxhdGVfZW5kXzU2X246CiAjaW5zdHIKCXN0cQkkMzEsRHlD
UlRfRHVtbXlHbG9iYWwJICNjbGFzcyBzb3VyY2UJICMgbGluZSAwLCAweDAo
UDY0KSwgPD50NTM2LCBhZGRyKF9EeUNSVF9EdW1teUdsb2JhbCQxLjkpKFA2
NCksIDAoSTMyKSwgMChJMzIpLCAwKEkzMiksIDAoSTMyKQogI21hcmtfdHJh
Y2UgMzk7CiAjaW5zdHIKCWxkYQkkMjcsaW50ZXJwcmV0ZXIuc3RhdGljX2Jy
YW5jaF8xXzAoJDMxKQkgI2NsYXNzIGRtb3ZlLGRtX2NvbnN0YW50CSAjIGlu
dGVycHJldGVyLnN0YXRpY19icmFuY2hfMV8wCiAjaW5zdHIKCWxkYQkkMjUs
aW50ZXJwcmV0ZXIuc3RhdGljX2JyYW5jaF8zXzAoJDMxKQkgI2NsYXNzIGRt
b3ZlLGRtX2NvbnN0YW50CSAjIGludGVycHJldGVyLnN0YXRpY19icmFuY2hf
M18wCiAjaW5zdHIKCWxkYQkkMjQsaW50ZXJwcmV0ZXIuc3RhdGljX2JyYW5j
aF80XzAoJDMxKQkgI2NsYXNzIGRtb3ZlLGRtX2NvbnN0YW50CSAjIGludGVy
cHJldGVyLnN0YXRpY19icmFuY2hfNF8wCiAjaW5zdHIKCWxkYQkkMjMsaW50
ZXJwcmV0ZXIuc3RhdGljX2JyYW5jaF82XzAoJDMxKQkgI2NsYXNzIGRtb3Zl
LGRtX2NvbnN0YW50CSAjIGludGVycHJldGVyLnN0YXRpY19icmFuY2hfNl8w
CiAjaW5zdHIKCWJyCSQzMSxMMCQzCiAjbWFya190cmFjZSA0MTsKTDE3JDM6
CmludGVycHJldGVyLkRZQy5VTklUX0hFQUQuVEVNUExBVEUuMzoKaW50ZXJw
cmV0ZXIuZHluX3RlbXBsYXRlX2JlZ2luXzU1OgogI2luc3RyCglzdHEJJDMx
LER5Q1JUX0R1bW15R2xvYmFsCSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMCwg
MHgwKFA2NCksIDw+dDUzNiwgYWRkcihfRHlDUlRfRHVtbXlHbG9iYWwkMS45
KShQNjQpLCAwKEkzMiksIDAoSTMyKSwgMChJMzIpLCAwKEkzMikKCSAjIHN0
YWxsIAkxCmludGVycHJldGVyLkRZQy5OT19CUkFOQ0guRC4yLkIuMjAzOgpp
bnRlcnByZXRlci5keW5fdGVtcGxhdGVfZW5kXzU1X246CiAjaW5zdHIKCXN0
cQkkMzEsRHlDUlRfRHVtbXlHbG9iYWwJICNjbGFzcyBzb3VyY2UJICMgbGlu
ZSAwLCAweDAoUDY0KSwgPD50NTM2LCBhZGRyKF9EeUNSVF9EdW1teUdsb2Jh
bCQxLjkpKFA2NCksIDAoSTMyKSwgMChJMzIpLCAwKEkzMiksIDAoSTMyKQog
I21hcmtfdHJhY2UgNDA7CiAjaW5zdHIKCWxkYQkkMjcsaW50ZXJwcmV0ZXIu
c3RhdGljX2JyYW5jaF8xXzAoJDMxKQkgI2NsYXNzIGRtb3ZlLGRtX2NvbnN0
YW50CSAjIGludGVycHJldGVyLnN0YXRpY19icmFuY2hfMV8wCiAjaW5zdHIK
CWxkYQkkMjUsaW50ZXJwcmV0ZXIuc3RhdGljX2JyYW5jaF8zXzAoJDMxKQkg
I2NsYXNzIGRtb3ZlLGRtX2NvbnN0YW50CSAjIGludGVycHJldGVyLnN0YXRp
Y19icmFuY2hfM18wCiAjaW5zdHIKCWxkYQkkMjQsaW50ZXJwcmV0ZXIuc3Rh
dGljX2JyYW5jaF80XzAoJDMxKQkgI2NsYXNzIGRtb3ZlLGRtX2NvbnN0YW50
CSAjIGludGVycHJldGVyLnN0YXRpY19icmFuY2hfNF8wCiAjaW5zdHIKCWxk
YQkkMjMsaW50ZXJwcmV0ZXIuc3RhdGljX2JyYW5jaF82XzAoJDMxKQkgI2Ns
YXNzIGRtb3ZlLGRtX2NvbnN0YW50CSAjIGludGVycHJldGVyLnN0YXRpY19i
cmFuY2hfNl8wCiAjaW5zdHIKCWJyCSQzMSxMMCQzCiAjbWFya190cmFjZSA1
MjsKXyQxLmludGVycHJldGVyLlRBRy43LjI6CmludGVycHJldGVyLmR5bl90
ZW1wbGF0ZV9iZWdpbl81MzoKICNpbnN0cgoubG9jIDIgOTcKCWNtcGVxCSQw
LCQyNywkMjcJICNjbGFzcyBzb3VyY2UJICMgbGluZSA5NywgPF9iZXQzJDEu
Mj50NTIyLCA8X211bHQyJDEuMj50MywgPF9iZXQxJDEuMj50NTIzCmludGVy
cHJldGVyLmR5bl90ZW1wbGF0ZV9lbmRfNTNfbjoKICNpbnN0cgoJYnIJJDMx
LEwxNiQzCiAjbWFya190cmFjZSA1NzsKXyQxLmludGVycHJldGVyLlRBRy43
LjE6CmludGVycHJldGVyLmR5bl90ZW1wbGF0ZV9iZWdpbl81MjoKICNpbnN0
cgoubG9jIDIgOTYKCWNtcGVxCSQyLCQyNywkMjcJICNjbGFzcyBzb3VyY2UJ
ICMgbGluZSA5NiwgPF9iZXQzJDEuMj50NTIyLCA8X211bHQxJDEuMj50Miwg
PF9iZXQxJDEuMj50NTIzCmludGVycHJldGVyLmR5bl90ZW1wbGF0ZV9lbmRf
NTJfbjoKICNpbnN0cgoJYnIJJDMxLEwxNiQzCiAjbWFya190cmFjZSA1MTsK
XyQxLmludGVycHJldGVyLlRBRy43LjA6CmludGVycHJldGVyLmR5bl90ZW1w
bGF0ZV9iZWdpbl81MToKICNpbnN0cgoubG9jIDIgOTUKCWNtcGVxCSQxLCQy
NywkMjcJICNjbGFzcyBzb3VyY2UJICMgbGluZSA5NSwgPF9iZXQzJDEuMj50
NTIyLCA8X211bHQxJDEuMj50MSwgPF9iZXQxJDEuMj50NTIzCmludGVycHJl
dGVyLmR5bl90ZW1wbGF0ZV9lbmRfNTFfbjoKICNpbnN0cgoJYnIJJDMxLEwx
NiQzCiAjbWFya190cmFjZSAxMDI7CkwxNCQzOgppbnRlcnByZXRlci5keW5f
dGVtcGxhdGVfYmVnaW5fNDc6CiAjaW5zdHIKCXN0cQkkMzEsRHlDUlRfRHVt
bXlHbG9iYWwJICNjbGFzcyBzb3VyY2UJICMgbGluZSAwLCAweDAoUDY0KSwg
PD50NTM2LCBhZGRyKF9EeUNSVF9EdW1teUdsb2JhbCQxLjkpKFA2NCksIDAo
STMyKSwgMChJMzIpLCAwKEkzMiksIDAoSTMyKQoJICMgc3RhbGwgCTEKaW50
ZXJwcmV0ZXIuZHluX3RlbXBsYXRlX2VuZF80N19uOgogI2luc3RyCglzdHEJ
JDMxLER5Q1JUX0R1bW15R2xvYmFsCSAjY2xhc3Mgc291cmNlCSAjIGxpbmUg
MCwgMHgwKFA2NCksIDw+dDUzNiwgYWRkcihfRHlDUlRfRHVtbXlHbG9iYWwk
MS45KShQNjQpLCAwKEkzMiksIDAoSTMyKSwgMChJMzIpLCAwKEkzMikKICNp
bnN0cgoJYnIJJDMxLEwxNSQzCiAjbWFya190cmFjZSA2NTsKXyQxLmludGVy
cHJldGVyLlRBRy42LjI6CmludGVycHJldGVyLmR5bl90ZW1wbGF0ZV9iZWdp
bl80NToKICNpbnN0cgoubG9jIDIgOTEKCW9yCSQwLCQzMSwkMjcJICNjbGFz
cyBzb3VyY2UJICMgbGluZSA5MSwgPF9iZXQxJDEuMj50NTIzLCA8X211bHQy
JDEuMj50MwoJICMgc3RhbGwgCTEKaW50ZXJwcmV0ZXIuZHluX3RlbXBsYXRl
X2VuZF80NV9uOgogI2luc3RyCglzdHEJJDMxLER5Q1JUX0R1bW15R2xvYmFs
CSAjY2xhc3Mgc291cmNlLHJlam9pbl9jb3B5CSAjIGxpbmUgMCwgMHgwKFA2
NCksIDw+dDUzNiwgYWRkcihfRHlDUlRfRHVtbXlHbG9iYWwkMS45KShQNjQp
LCAwKEkzMiksIDAoSTMyKSwgMChJMzIpLCAwKEkzMikKICNpbnN0cgoJYnIJ
JDMxLEwxMyQzCiAjbWFya190cmFjZSA2NzsKXyQxLmludGVycHJldGVyLlRB
Ry42LjE6CmludGVycHJldGVyLmR5bl90ZW1wbGF0ZV9iZWdpbl80NDoKICNp
bnN0cgoubG9jIDIgOTAKCW9yCSQyLCQzMSwkMjcJICNjbGFzcyBzb3VyY2UJ
ICMgbGluZSA5MCwgPF9iZXQxJDEuMj50NTIzLCA8X211bHQxJDEuMj50MgoJ
ICMgc3RhbGwgCTEKaW50ZXJwcmV0ZXIuZHluX3RlbXBsYXRlX2VuZF80NF9u
OgogI2luc3RyCglzdHEJJDMxLER5Q1JUX0R1bW15R2xvYmFsCSAjY2xhc3Mg
c291cmNlLHJlam9pbl9jb3B5CSAjIGxpbmUgMCwgMHgwKFA2NCksIDw+dDUz
NiwgYWRkcihfRHlDUlRfRHVtbXlHbG9iYWwkMS45KShQNjQpLCAwKEkzMiks
IDAoSTMyKSwgMChJMzIpLCAwKEkzMikKICNpbnN0cgoJYnIJJDMxLEwxMyQz
CiAjbWFya190cmFjZSA2OTsKXyQxLmludGVycHJldGVyLlRBRy42LjA6Cmlu
dGVycHJldGVyLmR5bl90ZW1wbGF0ZV9iZWdpbl80MzoKICNpbnN0cgoubG9j
IDIgODkKCW9yCSQxLCQzMSwkMjcJICNjbGFzcyBzb3VyY2UJICMgbGluZSA4
OSwgPF9iZXQxJDEuMj50NTIzLCA8X211bHQxJDEuMj50MQoJICMgc3RhbGwg
CTEKaW50ZXJwcmV0ZXIuZHluX3RlbXBsYXRlX2VuZF80M19uOgogI2luc3Ry
CglzdHEJJDMxLER5Q1JUX0R1bW15R2xvYmFsCSAjY2xhc3Mgc291cmNlLHJl
am9pbl9jb3B5CSAjIGxpbmUgMCwgMHgwKFA2NCksIDw+dDUzNiwgYWRkcihf
RHlDUlRfRHVtbXlHbG9iYWwkMS45KShQNjQpLCAwKEkzMiksIDAoSTMyKSwg
MChJMzIpLCAwKEkzMikKICNpbnN0cgoJYnIJJDMxLEwxMyQzCiAjbWFya190
cmFjZSAxMDM7CkwxMSQzOgppbnRlcnByZXRlci5keW5fdGVtcGxhdGVfYmVn
aW5fMzk6CiAjaW5zdHIKCXN0cQkkMzEsRHlDUlRfRHVtbXlHbG9iYWwJICNj
bGFzcyBzb3VyY2UJICMgbGluZSAwLCAweDAoUDY0KSwgPD50NTM2LCBhZGRy
KF9EeUNSVF9EdW1teUdsb2JhbCQxLjkpKFA2NCksIDAoSTMyKSwgMChJMzIp
LCAwKEkzMiksIDAoSTMyKQoJICMgc3RhbGwgCTEKaW50ZXJwcmV0ZXIuZHlu
X3RlbXBsYXRlX2VuZF8zOV9uOgogI2luc3RyCglzdHEJJDMxLER5Q1JUX0R1
bW15R2xvYmFsCSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMCwgMHgwKFA2NCks
IDw+dDUzNiwgYWRkcihfRHlDUlRfRHVtbXlHbG9iYWwkMS45KShQNjQpLCAw
KEkzMiksIDAoSTMyKSwgMChJMzIpLCAwKEkzMikKICNpbnN0cgoJYnIJJDMx
LEwxMiQzCiAjbWFya190cmFjZSAzMzsKXyQxLmludGVycHJldGVyLlRBRy44
LjE6CmludGVycHJldGVyLmR5bl90ZW1wbGF0ZV9iZWdpbl8xMzoKICNpbnN0
cgoJc3RxCSQzMSxEeUNSVF9EdW1teUdsb2JhbAkgI2NsYXNzIHNvdXJjZQkg
IyBsaW5lIDAsIDB4MChQNjQpLCA8PnQ1MzYsIGFkZHIoX0R5Q1JUX0R1bW15
R2xvYmFsJDEuOSkoUDY0KSwgMChJMzIpLCAwKEkzMiksIDAoSTMyKSwgMChJ
MzIpCglsZGEJJDI3LGludGVycHJldGVyLnN0YXRpY19icmFuY2hfMTNfMCgk
MzEpCSAjY2xhc3MgZG1vdmUsZG1fY29uc3RhbnQJICMgaW50ZXJwcmV0ZXIu
c3RhdGljX2JyYW5jaF8xM18wCiAjaW5zdHIKCWxkYQkkMjUsaW50ZXJwcmV0
ZXIuc3RhdGljX2JyYW5jaF8xNV8wKCQzMSkJICNjbGFzcyBkbW92ZSxkbV9j
b25zdGFudAkgIyBpbnRlcnByZXRlci5zdGF0aWNfYnJhbmNoXzE1XzAKCWNw
eXMJJGYzMSwkZjMxLCRmMzEJIyBwYWQKICNpbnN0cgoJc3RxCSQzMSxEeUNS
VF9EdW1teUdsb2JhbAkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDAsIDB4MChQ
NjQpLCA8PnQ1MzYsIGFkZHIoX0R5Q1JUX0R1bW15R2xvYmFsJDEuOSkoUDY0
KSwgMChJMzIpLCAwKEkzMiksIDAoSTMyKSwgMChJMzIpCglsZGEJJDI0LGlu
dGVycHJldGVyLnN0YXRpY19icmFuY2hfMjFfMCgkMzEpCSAjY2xhc3MgZG1v
dmUsZG1fY29uc3RhbnQJICMgaW50ZXJwcmV0ZXIuc3RhdGljX2JyYW5jaF8y
MV8wCiAjaW5zdHIKCWxkYQkkMjMsaW50ZXJwcmV0ZXIuc3RhdGljX2JyYW5j
aF8yM18wKCQzMSkJICNjbGFzcyBkbW92ZSxkbV9jb25zdGFudAkgIyBpbnRl
cnByZXRlci5zdGF0aWNfYnJhbmNoXzIzXzAKCWNweXMJJGYzMSwkZjMxLCRm
MzEJIyBwYWQKaW50ZXJwcmV0ZXIuRFlDLlNUQVRJQ19CUkFOQ0guQi4xNDg6
CmludGVycHJldGVyLmR5bl90ZW1wbGF0ZV9lbmRfMTNfbjoKICNpbnN0cgoJ
bGRhCSQyMSxpbnRlcnByZXRlci5zdGF0aWNfYnJhbmNoXzI5XzAoJDMxKQkg
I2NsYXNzIGRtb3ZlLGRtX2NvbnN0YW50CSAjIGludGVycHJldGVyLnN0YXRp
Y19icmFuY2hfMjlfMAoubG9jIDIgNTQKCXN0YXRpY19icmFuY2g6IGJuZQkk
MjcsTDE4JDMJICNjbGFzcyBzb3VyY2UJICMgbGluZSA1NCwgaW50ZXJwcmV0
ZXIuc3RhdGljX2JyYW5jaF8xM18wCmludGVycHJldGVyLmR5bl90ZW1wbGF0
ZV9iZWdpbl8xNToKICNpbnN0cgoJbGRhCSQyMCxpbnRlcnByZXRlci5zdGF0
aWNfYnJhbmNoXzMxXzAoJDMxKQkgI2NsYXNzIGRtb3ZlLGRtX2NvbnN0YW50
CSAjIGludGVycHJldGVyLnN0YXRpY19icmFuY2hfMzFfMAogI2luc3RyCglz
dHEJJDMxLER5Q1JUX0R1bW15R2xvYmFsCSAjY2xhc3Mgc291cmNlCSAjIGxp
bmUgMCwgMHgwKFA2NCksIDw+dDUzNiwgYWRkcihfRHlDUlRfRHVtbXlHbG9i
YWwkMS45KShQNjQpLCAwKEkzMiksIDAoSTMyKSwgMChJMzIpLCAwKEkzMikK
CSAjIHN0YWxsIAkxCiAjaW5zdHIKCXN0cQkkMzEsRHlDUlRfRHVtbXlHbG9i
YWwJICNjbGFzcyBzb3VyY2UJICMgbGluZSAwLCAweDAoUDY0KSwgPD50NTM2
LCBhZGRyKF9EeUNSVF9EdW1teUdsb2JhbCQxLjkpKFA2NCksIDAoSTMyKSwg
MChJMzIpLCAwKEkzMiksIDAoSTMyKQoJICMgc3RhbGwgCTEKaW50ZXJwcmV0
ZXIuRFlDLlNUQVRJQ19CUkFOQ0guQi4xNDU6CmludGVycHJldGVyLmR5bl90
ZW1wbGF0ZV9lbmRfMTVfbjoKICNpbnN0cgoubG9jIDIgNTQKCXN0YXRpY19i
cmFuY2g6IGptcAkkMzEsKCQyNSkJICNjbGFzcyBzb3VyY2UJICMgbGluZSA1
NCwgaW50ZXJwcmV0ZXIuc3RhdGljX2JyYW5jaF8xNV8wCl8kMS5pbnRlcnBy
ZXRlci5UQUcuMS5ERUZBVUxUOgppbnRlcnByZXRlci5keW5fdGVtcGxhdGVf
YmVnaW5fMTY6CiAjaW5zdHIKICNpbnN0cgoJc3RxCSQzMSxEeUNSVF9EdW1t
eUdsb2JhbAkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDAsIDB4MChQNjQpLCA8
PnQ1MzYsIGFkZHIoX0R5Q1JUX0R1bW15R2xvYmFsJDEuOSkoUDY0KSwgMChJ
MzIpLCAwKEkzMiksIDAoSTMyKSwgMChJMzIpCgkgIyBzdGFsbCAJMQppbnRl
cnByZXRlci5keW5fdGVtcGxhdGVfZW5kXzE2X246CiAjaW5zdHIKCXN0cQkk
MzEsRHlDUlRfRHVtbXlHbG9iYWwJICNjbGFzcyBzb3VyY2UJICMgbGluZSAw
LCAweDAoUDY0KSwgPD50NTM2LCBhZGRyKF9EeUNSVF9EdW1teUdsb2JhbCQx
LjkpKFA2NCksIDAoSTMyKSwgMChJMzIpLCAwKEkzMiksIDAoSTMyKQpMMTkk
MzoKaW50ZXJwcmV0ZXIuZHluX3RlbXBsYXRlX2JlZ2luXzE3OgogI2luc3Ry
CiAjaW5zdHIKLmxvYyAyIDUzCglsZGwJJDI3LGludGVycHJldGVyLnJ0Y29u
c3RfMTdfMSgkMjIpCSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgNTMsIDxfbXVs
dDEkMS4yPnQ1MjYsIDw+dDAsIGludGVycHJldGVyLnJ0Y29uc3RfMTdfMQoJ
ICMgc3RhbGwgCTEKaW50ZXJwcmV0ZXIuZHluX3RlbXBsYXRlX2VuZF8xN19u
OgogI2luc3RyCglzdHEJJDMxLER5Q1JUX0R1bW15R2xvYmFsCSAjY2xhc3Mg
c291cmNlCSAjIGxpbmUgMCwgMHgwKFA2NCksIDw+dDUzNiwgYWRkcihfRHlD
UlRfRHVtbXlHbG9iYWwkMS45KShQNjQpLCAwKEkzMiksIDAoSTMyKSwgMChJ
MzIpLCAwKEkzMikKTDIwJDM6CmludGVycHJldGVyLmR5bl90ZW1wbGF0ZV9i
ZWdpbl8yMToKICNpbnN0cgogI2luc3RyCglzdHEJJDMxLER5Q1JUX0R1bW15
R2xvYmFsCSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMCwgMHgwKFA2NCksIDw+
dDUzNiwgYWRkcihfRHlDUlRfRHVtbXlHbG9iYWwkMS45KShQNjQpLCAwKEkz
MiksIDAoSTMyKSwgMChJMzIpLCAwKEkzMikKCSAjIHN0YWxsIAkxCmludGVy
cHJldGVyLkRZQy5TVEFUSUNfQlJBTkNILkIuMTQ0OgppbnRlcnByZXRlci5k
eW5fdGVtcGxhdGVfZW5kXzIxX246CiAjaW5zdHIKLmxvYyAyIDYwCglzdGF0
aWNfYnJhbmNoOiBibmUJJDI0LEwyMSQzCSAjY2xhc3Mgc291cmNlCSAjIGxp
bmUgNjAsIGludGVycHJldGVyLnN0YXRpY19icmFuY2hfMjFfMAppbnRlcnBy
ZXRlci5keW5fdGVtcGxhdGVfYmVnaW5fMjM6CiAjaW5zdHIKICNpbnN0cgoJ
c3RxCSQzMSxEeUNSVF9EdW1teUdsb2JhbAkgI2NsYXNzIHNvdXJjZQkgIyBs
aW5lIDAsIDB4MChQNjQpLCA8PnQ1MzYsIGFkZHIoX0R5Q1JUX0R1bW15R2xv
YmFsJDEuOSkoUDY0KSwgMChJMzIpLCAwKEkzMiksIDAoSTMyKSwgMChJMzIp
CgkgIyBzdGFsbCAJMQogI2luc3RyCglzdHEJJDMxLER5Q1JUX0R1bW15R2xv
YmFsCSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMCwgMHgwKFA2NCksIDw+dDUz
NiwgYWRkcihfRHlDUlRfRHVtbXlHbG9iYWwkMS45KShQNjQpLCAwKEkzMiks
IDAoSTMyKSwgMChJMzIpLCAwKEkzMikKCSAjIHN0YWxsIAkxCmludGVycHJl
dGVyLkRZQy5TVEFUSUNfQlJBTkNILkIuMjYzOgppbnRlcnByZXRlci5keW5f
dGVtcGxhdGVfZW5kXzIzX246CiAjaW5zdHIKLmxvYyAyIDYwCglzdGF0aWNf
YnJhbmNoOiBqbXAJJDMxLCgkMjMpCSAjY2xhc3Mgc291cmNlCSAjIGxpbmUg
NjAsIGludGVycHJldGVyLnN0YXRpY19icmFuY2hfMjNfMApfJDEuaW50ZXJw
cmV0ZXIuVEFHLjIuREVGQVVMVDoKaW50ZXJwcmV0ZXIuZHluX3RlbXBsYXRl
X2JlZ2luXzI0OgogI2luc3RyCiAjaW5zdHIKCXN0cQkkMzEsRHlDUlRfRHVt
bXlHbG9iYWwJICNjbGFzcyBzb3VyY2UJICMgbGluZSAwLCAweDAoUDY0KSwg
PD50NTM2LCBhZGRyKF9EeUNSVF9EdW1teUdsb2JhbCQxLjkpKFA2NCksIDAo
STMyKSwgMChJMzIpLCAwKEkzMiksIDAoSTMyKQoJICMgc3RhbGwgCTEKaW50
ZXJwcmV0ZXIuZHluX3RlbXBsYXRlX2VuZF8yNF9uOgogI2luc3RyCglzdHEJ
JDMxLER5Q1JUX0R1bW15R2xvYmFsCSAjY2xhc3Mgc291cmNlCSAjIGxpbmUg
MCwgMHgwKFA2NCksIDw+dDUzNiwgYWRkcihfRHlDUlRfRHVtbXlHbG9iYWwk
MS45KShQNjQpLCAwKEkzMiksIDAoSTMyKSwgMChJMzIpLCAwKEkzMikKTDIy
JDM6CmludGVycHJldGVyLmR5bl90ZW1wbGF0ZV9iZWdpbl8yNToKICNpbnN0
cgogI2luc3RyCi5sb2MgMiA1OQoJbGRsCSQyNSxpbnRlcnByZXRlci5ydGNv
bnN0XzI1XzEoJDIyKQkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDU5LCA8X211
bHQyJDEuMj50NTI1LCA8PnQwLCBpbnRlcnByZXRlci5ydGNvbnN0XzI1XzEK
CSAjIHN0YWxsIAkxCmludGVycHJldGVyLmR5bl90ZW1wbGF0ZV9lbmRfMjVf
bjoKICNpbnN0cgoJc3RxCSQzMSxEeUNSVF9EdW1teUdsb2JhbAkgI2NsYXNz
IHNvdXJjZQkgIyBsaW5lIDAsIDB4MChQNjQpLCA8PnQ1MzYsIGFkZHIoX0R5
Q1JUX0R1bW15R2xvYmFsJDEuOSkoUDY0KSwgMChJMzIpLCAwKEkzMiksIDAo
STMyKSwgMChJMzIpCkwyMyQzOgppbnRlcnByZXRlci5keW5fdGVtcGxhdGVf
YmVnaW5fMjk6CiAjaW5zdHIKLmxvYyAyIDY1CgltdWxsCSQyNSwkMjcsJDI0
CSAjY2xhc3Mgc291cmNlLGNzcGVjCSAjIGxpbmUgNjUsIDw+dDM3NywgPF9t
dWx0MiQxLjI+dDUyNSwgPF9tdWx0MSQxLjI+dDUyNgogI2luc3RyCglzdHEJ
JDMxLER5Q1JUX0R1bW15R2xvYmFsCSAjY2xhc3Mgc291cmNlCSAjIGxpbmUg
MCwgMHgwKFA2NCksIDw+dDUzNiwgYWRkcihfRHlDUlRfRHVtbXlHbG9iYWwk
MS45KShQNjQpLCAwKEkzMiksIDAoSTMyKSwgMChJMzIpLCAwKEkzMikKCSAj
IHN0YWxsIAkxCmludGVycHJldGVyLkRZQy5TVEFUSUNfQlJBTkNILkIuMTQz
OgppbnRlcnByZXRlci5keW5fdGVtcGxhdGVfZW5kXzI5X246CiAjaW5zdHIK
LmxvYyAyIDY2CglzdGF0aWNfYnJhbmNoOiBibmUJJDIxLEwyNCQzCSAjY2xh
c3Mgc291cmNlCSAjIGxpbmUgNjYsIGludGVycHJldGVyLnN0YXRpY19icmFu
Y2hfMjlfMAppbnRlcnByZXRlci5keW5fdGVtcGxhdGVfYmVnaW5fMzE6CiAj
aW5zdHIKICNpbnN0cgoJc3RxCSQzMSxEeUNSVF9EdW1teUdsb2JhbAkgI2Ns
YXNzIHNvdXJjZQkgIyBsaW5lIDAsIDB4MChQNjQpLCA8PnQ1MzYsIGFkZHIo
X0R5Q1JUX0R1bW15R2xvYmFsJDEuOSkoUDY0KSwgMChJMzIpLCAwKEkzMiks
IDAoSTMyKSwgMChJMzIpCgkgIyBzdGFsbCAJMQogI2luc3RyCglzdHEJJDMx
LER5Q1JUX0R1bW15R2xvYmFsCSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMCwg
MHgwKFA2NCksIDw+dDUzNiwgYWRkcihfRHlDUlRfRHVtbXlHbG9iYWwkMS45
KShQNjQpLCAwKEkzMiksIDAoSTMyKSwgMChJMzIpLCAwKEkzMikKCSAjIHN0
YWxsIAkxCmludGVycHJldGVyLkRZQy5TVEFUSUNfQlJBTkNILkIuMTQwOgpp
bnRlcnByZXRlci5keW5fdGVtcGxhdGVfZW5kXzMxX246CiAjaW5zdHIKLmxv
YyAyIDY2CglzdGF0aWNfYnJhbmNoOiBqbXAJJDMxLCgkMjApCSAjY2xhc3Mg
c291cmNlCSAjIGxpbmUgNjYsIGludGVycHJldGVyLnN0YXRpY19icmFuY2hf
MzFfMApfJDEuaW50ZXJwcmV0ZXIuVEFHLjMuREVGQVVMVDoKaW50ZXJwcmV0
ZXIuZHluX3RlbXBsYXRlX2JlZ2luXzMyOgogI2luc3RyCiAjaW5zdHIKCXN0
cQkkMzEsRHlDUlRfRHVtbXlHbG9iYWwJICNjbGFzcyBzb3VyY2UJICMgbGlu
ZSAwLCAweDAoUDY0KSwgPD50NTM2LCBhZGRyKF9EeUNSVF9EdW1teUdsb2Jh
bCQxLjkpKFA2NCksIDAoSTMyKSwgMChJMzIpLCAwKEkzMiksIDAoSTMyKQoJ
ICMgc3RhbGwgCTEKICNpbnN0cgoJc3RxCSQzMSxEeUNSVF9EdW1teUdsb2Jh
bAkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDAsIDB4MChQNjQpLCA8PnQ1MzYs
IGFkZHIoX0R5Q1JUX0R1bW15R2xvYmFsJDEuOSkoUDY0KSwgMChJMzIpLCAw
KEkzMiksIDAoSTMyKSwgMChJMzIpCmludGVycHJldGVyLmR5bl90ZW1wbGF0
ZV9lbmRfMzJfbjoKICNpbnN0cgpMMjUkMzoKaW50ZXJwcmV0ZXIuZHluX3Rl
bXBsYXRlX2JlZ2luXzMzOgogI2luc3RyCgkgIyBzdGFsbCAJMwppbnRlcnBy
ZXRlci5keW5fdGVtcGxhdGVfZW5kXzMzX246CiAjaW5zdHIKLmxvYyAyIDY1
CglzdGwJJDI0LGludGVycHJldGVyLnJ0Y29uc3RfMzNfMSgkMjIpCSAjY2xh
c3Mgc291cmNlCSAjIGxpbmUgNjUsIDw+dDM3NywgPD50MCwgaW50ZXJwcmV0
ZXIucnRjb25zdF8zM18xLCAwKEkzMiksIDAoSTMyKSwgMChJMzIpLCAwKEkz
MikKTDI2JDM6CmludGVycHJldGVyLmR5bl90ZW1wbGF0ZV9iZWdpbl8zNzoK
ICNpbnN0cgogI2luc3RyCglzdHEJJDMxLER5Q1JUX0R1bW15R2xvYmFsCSAj
Y2xhc3Mgc291cmNlCSAjIGxpbmUgMCwgMHgwKFA2NCksIDw+dDUzNiwgYWRk
cihfRHlDUlRfRHVtbXlHbG9iYWwkMS45KShQNjQpLCAwKEkzMiksIDAoSTMy
KSwgMChJMzIpLCAwKEkzMikKCSAjIHN0YWxsIAkxCmludGVycHJldGVyLkRZ
Qy5OT19CUkFOQ0guRC4yLkIuMjI5OgppbnRlcnByZXRlci5keW5fdGVtcGxh
dGVfZW5kXzM3X246CiAjaW5zdHIKCXN0cQkkMzEsRHlDUlRfRHVtbXlHbG9i
YWwJICNjbGFzcyBzb3VyY2UJICMgbGluZSAwLCAweDAoUDY0KSwgPD50NTM2
LCBhZGRyKF9EeUNSVF9EdW1teUdsb2JhbCQxLjkpKFA2NCksIDAoSTMyKSwg
MChJMzIpLCAwKEkzMiksIDAoSTMyKQogI21hcmtfdHJhY2UgMzA7CiAjaW5z
dHIKCWxkYQkkMjcsaW50ZXJwcmV0ZXIuc3RhdGljX2JyYW5jaF8xXzAoJDMx
KQkgI2NsYXNzIGRtb3ZlLGRtX2NvbnN0YW50CSAjIGludGVycHJldGVyLnN0
YXRpY19icmFuY2hfMV8wCiAjaW5zdHIKCWxkYQkkMjUsaW50ZXJwcmV0ZXIu
c3RhdGljX2JyYW5jaF8zXzAoJDMxKQkgI2NsYXNzIGRtb3ZlLGRtX2NvbnN0
YW50CSAjIGludGVycHJldGVyLnN0YXRpY19icmFuY2hfM18wCiAjaW5zdHIK
CWxkYQkkMjQsaW50ZXJwcmV0ZXIuc3RhdGljX2JyYW5jaF80XzAoJDMxKQkg
I2NsYXNzIGRtb3ZlLGRtX2NvbnN0YW50CSAjIGludGVycHJldGVyLnN0YXRp
Y19icmFuY2hfNF8wCiAjaW5zdHIKCWxkYQkkMjMsaW50ZXJwcmV0ZXIuc3Rh
dGljX2JyYW5jaF82XzAoJDMxKQkgI2NsYXNzIGRtb3ZlLGRtX2NvbnN0YW50
CSAjIGludGVycHJldGVyLnN0YXRpY19icmFuY2hfNl8wCiAjaW5zdHIKCWJy
CSQzMSxMMCQzCiAjbWFya190cmFjZSA2NjsKXyQxLmludGVycHJldGVyLlRB
Ry4zLjI6CmludGVycHJldGVyLmR5bl90ZW1wbGF0ZV9iZWdpbl8zNjoKICNp
bnN0cgoJICMgc3RhbGwgCTYKICNpbnN0cgoubG9jIDIgNjQKCW11bGwJJDI1
LCQyNywkMAkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDY0LCA8X211bHQyJDEu
Mj50MywgPF9tdWx0MiQxLjI+dDUyNSwgPF9tdWx0MSQxLjI+dDUyNgoJICMg
c3RhbGwgCTEzCmludGVycHJldGVyLmR5bl90ZW1wbGF0ZV9lbmRfMzZfbjoK
ICNpbnN0cgoJYnIJJDMxLEwyNiQzCiAjbWFya190cmFjZSA2MTsKXyQxLmlu
dGVycHJldGVyLlRBRy4zLjE6CmludGVycHJldGVyLmR5bl90ZW1wbGF0ZV9i
ZWdpbl8zNToKICNpbnN0cgoJICMgc3RhbGwgCTYKICNpbnN0cgoubG9jIDIg
NjMKCW11bGwJJDI1LCQyNywkMgkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDYz
LCA8X211bHQxJDEuMj50MiwgPF9tdWx0MiQxLjI+dDUyNSwgPF9tdWx0MSQx
LjI+dDUyNgoJICMgc3RhbGwgCTEzCmludGVycHJldGVyLmR5bl90ZW1wbGF0
ZV9lbmRfMzVfbjoKICNpbnN0cgoJYnIJJDMxLEwyNiQzCiAjbWFya190cmFj
ZSA3MjsKXyQxLmludGVycHJldGVyLlRBRy4zLjA6CmludGVycHJldGVyLmR5
bl90ZW1wbGF0ZV9iZWdpbl8zNDoKICNpbnN0cgoJICMgc3RhbGwgCTYKICNp
bnN0cgoubG9jIDIgNjIKCW11bGwJJDI1LCQyNywkMQkgI2NsYXNzIHNvdXJj
ZQkgIyBsaW5lIDYyLCA8X211bHQxJDEuMj50MSwgPF9tdWx0MiQxLjI+dDUy
NSwgPF9tdWx0MSQxLjI+dDUyNgoJICMgc3RhbGwgCTEzCmludGVycHJldGVy
LmR5bl90ZW1wbGF0ZV9lbmRfMzRfbjoKICNpbnN0cgoJYnIJJDMxLEwyNiQz
CiAjbWFya190cmFjZSAxMDc7CkwyNCQzOgppbnRlcnByZXRlci5keW5fdGVt
cGxhdGVfYmVnaW5fMzA6CiAjaW5zdHIKCXN0cQkkMzEsRHlDUlRfRHVtbXlH
bG9iYWwJICNjbGFzcyBzb3VyY2UJICMgbGluZSAwLCAweDAoUDY0KSwgPD50
NTM2LCBhZGRyKF9EeUNSVF9EdW1teUdsb2JhbCQxLjkpKFA2NCksIDAoSTMy
KSwgMChJMzIpLCAwKEkzMiksIDAoSTMyKQoJICMgc3RhbGwgCTEKICNpbnN0
cgoJc3RxCSQzMSxEeUNSVF9EdW1teUdsb2JhbAkgI2NsYXNzIHNvdXJjZQkg
IyBsaW5lIDAsIDB4MChQNjQpLCA8PnQ1MzYsIGFkZHIoX0R5Q1JUX0R1bW15
R2xvYmFsJDEuOSkoUDY0KSwgMChJMzIpLCAwKEkzMiksIDAoSTMyKSwgMChJ
MzIpCgkgIyBzdGFsbCAJMTQKICNpbnN0cgoubG9jIDIgNjUKCW11bGwJJDI1
LCQyNywkMjQJICNjbGFzcyBzb3VyY2UsY3NwZWMJICMgbGluZSA2NSwgPD50
Mzc3LCA8X211bHQyJDEuMj50NTI1LCA8X211bHQxJDEuMj50NTI2CgkgIyBz
dGFsbCAJMTMKaW50ZXJwcmV0ZXIuZHluX3RlbXBsYXRlX2VuZF8zMF9uOgog
I2luc3RyCglicgkkMzEsTDI1JDMKICNtYXJrX3RyYWNlIDYzOwpfJDEuaW50
ZXJwcmV0ZXIuVEFHLjIuMjoKaW50ZXJwcmV0ZXIuZHluX3RlbXBsYXRlX2Jl
Z2luXzI4OgogI2luc3RyCi5sb2MgMiA1OAoJb3IJJDAsJDMxLCQyNQkgI2Ns
YXNzIHNvdXJjZQkgIyBsaW5lIDU4LCA8X211bHQyJDEuMj50NTI1LCA8X211
bHQyJDEuMj50MwoJICMgc3RhbGwgCTEKaW50ZXJwcmV0ZXIuZHluX3RlbXBs
YXRlX2VuZF8yOF9uOgogI2luc3RyCglzdHEJJDMxLER5Q1JUX0R1bW15R2xv
YmFsCSAjY2xhc3Mgc291cmNlLHJlam9pbl9jb3B5CSAjIGxpbmUgMCwgMHgw
KFA2NCksIDw+dDUzNiwgYWRkcihfRHlDUlRfRHVtbXlHbG9iYWwkMS45KShQ
NjQpLCAwKEkzMiksIDAoSTMyKSwgMChJMzIpLCAwKEkzMikKICNpbnN0cgoJ
YnIJJDMxLEwyMyQzCiAjbWFya190cmFjZSA1NTsKXyQxLmludGVycHJldGVy
LlRBRy4yLjE6CmludGVycHJldGVyLmR5bl90ZW1wbGF0ZV9iZWdpbl8yNzoK
ICNpbnN0cgoubG9jIDIgNTcKCW9yCSQyLCQzMSwkMjUJICNjbGFzcyBzb3Vy
Y2UJICMgbGluZSA1NywgPF9tdWx0MiQxLjI+dDUyNSwgPF9tdWx0MSQxLjI+
dDIKCSAjIHN0YWxsIAkxCmludGVycHJldGVyLmR5bl90ZW1wbGF0ZV9lbmRf
MjdfbjoKICNpbnN0cgoJc3RxCSQzMSxEeUNSVF9EdW1teUdsb2JhbAkgI2Ns
YXNzIHNvdXJjZSxyZWpvaW5fY29weQkgIyBsaW5lIDAsIDB4MChQNjQpLCA8
PnQ1MzYsIGFkZHIoX0R5Q1JUX0R1bW15R2xvYmFsJDEuOSkoUDY0KSwgMChJ
MzIpLCAwKEkzMiksIDAoSTMyKSwgMChJMzIpCiAjaW5zdHIKCWJyCSQzMSxM
MjMkMwogI21hcmtfdHJhY2UgNjI7Cl8kMS5pbnRlcnByZXRlci5UQUcuMi4w
OgppbnRlcnByZXRlci5keW5fdGVtcGxhdGVfYmVnaW5fMjY6CiAjaW5zdHIK
LmxvYyAyIDU2CglvcgkkMSwkMzEsJDI1CSAjY2xhc3Mgc291cmNlCSAjIGxp
bmUgNTYsIDxfbXVsdDIkMS4yPnQ1MjUsIDxfbXVsdDEkMS4yPnQxCgkgIyBz
dGFsbCAJMQppbnRlcnByZXRlci5keW5fdGVtcGxhdGVfZW5kXzI2X246CiAj
aW5zdHIKCXN0cQkkMzEsRHlDUlRfRHVtbXlHbG9iYWwJICNjbGFzcyBzb3Vy
Y2UscmVqb2luX2NvcHkJICMgbGluZSAwLCAweDAoUDY0KSwgPD50NTM2LCBh
ZGRyKF9EeUNSVF9EdW1teUdsb2JhbCQxLjkpKFA2NCksIDAoSTMyKSwgMChJ
MzIpLCAwKEkzMiksIDAoSTMyKQogI2luc3RyCglicgkkMzEsTDIzJDMKICNt
YXJrX3RyYWNlIDEwODsKTDIxJDM6CmludGVycHJldGVyLmR5bl90ZW1wbGF0
ZV9iZWdpbl8yMjoKICNpbnN0cgoJc3RxCSQzMSxEeUNSVF9EdW1teUdsb2Jh
bAkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDAsIDB4MChQNjQpLCA8PnQ1MzYs
IGFkZHIoX0R5Q1JUX0R1bW15R2xvYmFsJDEuOSkoUDY0KSwgMChJMzIpLCAw
KEkzMiksIDAoSTMyKSwgMChJMzIpCgkgIyBzdGFsbCAJMQppbnRlcnByZXRl
ci5keW5fdGVtcGxhdGVfZW5kXzIyX246CiAjaW5zdHIKCXN0cQkkMzEsRHlD
UlRfRHVtbXlHbG9iYWwJICNjbGFzcyBzb3VyY2UJICMgbGluZSAwLCAweDAo
UDY0KSwgPD50NTM2LCBhZGRyKF9EeUNSVF9EdW1teUdsb2JhbCQxLjkpKFA2
NCksIDAoSTMyKSwgMChJMzIpLCAwKEkzMiksIDAoSTMyKQogI2luc3RyCgli
cgkkMzEsTDIyJDMKICNtYXJrX3RyYWNlIDU5OwpfJDEuaW50ZXJwcmV0ZXIu
VEFHLjEuMjoKaW50ZXJwcmV0ZXIuZHluX3RlbXBsYXRlX2JlZ2luXzIwOgog
I2luc3RyCi5sb2MgMiA1MgoJb3IJJDAsJDMxLCQyNwkgI2NsYXNzIHNvdXJj
ZQkgIyBsaW5lIDUyLCA8X211bHQxJDEuMj50NTI2LCA8X211bHQyJDEuMj50
MwoJICMgc3RhbGwgCTEKaW50ZXJwcmV0ZXIuZHluX3RlbXBsYXRlX2VuZF8y
MF9uOgogI2luc3RyCglzdHEJJDMxLER5Q1JUX0R1bW15R2xvYmFsCSAjY2xh
c3Mgc291cmNlLHJlam9pbl9jb3B5CSAjIGxpbmUgMCwgMHgwKFA2NCksIDw+
dDUzNiwgYWRkcihfRHlDUlRfRHVtbXlHbG9iYWwkMS45KShQNjQpLCAwKEkz
MiksIDAoSTMyKSwgMChJMzIpLCAwKEkzMikKICNpbnN0cgoJYnIJJDMxLEwy
MCQzCiAjbWFya190cmFjZSA1NDsKXyQxLmludGVycHJldGVyLlRBRy4xLjE6
CmludGVycHJldGVyLmR5bl90ZW1wbGF0ZV9iZWdpbl8xOToKICNpbnN0cgou
bG9jIDIgNTEKCW9yCSQyLCQzMSwkMjcJICNjbGFzcyBzb3VyY2UJICMgbGlu
ZSA1MSwgPF9tdWx0MSQxLjI+dDUyNiwgPF9tdWx0MSQxLjI+dDIKCSAjIHN0
YWxsIAkxCmludGVycHJldGVyLmR5bl90ZW1wbGF0ZV9lbmRfMTlfbjoKICNp
bnN0cgoJc3RxCSQzMSxEeUNSVF9EdW1teUdsb2JhbAkgI2NsYXNzIHNvdXJj
ZSxyZWpvaW5fY29weQkgIyBsaW5lIDAsIDB4MChQNjQpLCA8PnQ1MzYsIGFk
ZHIoX0R5Q1JUX0R1bW15R2xvYmFsJDEuOSkoUDY0KSwgMChJMzIpLCAwKEkz
MiksIDAoSTMyKSwgMChJMzIpCiAjaW5zdHIKCWJyCSQzMSxMMjAkMwogI21h
cmtfdHJhY2UgNzM7Cl8kMS5pbnRlcnByZXRlci5UQUcuMS4wOgppbnRlcnBy
ZXRlci5keW5fdGVtcGxhdGVfYmVnaW5fMTg6CiAjaW5zdHIKLmxvYyAyIDUw
CglvcgkkMSwkMzEsJDI3CSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgNTAsIDxf
bXVsdDEkMS4yPnQ1MjYsIDxfbXVsdDEkMS4yPnQxCgkgIyBzdGFsbCAJMQpp
bnRlcnByZXRlci5keW5fdGVtcGxhdGVfZW5kXzE4X246CiAjaW5zdHIKCXN0
cQkkMzEsRHlDUlRfRHVtbXlHbG9iYWwJICNjbGFzcyBzb3VyY2UscmVqb2lu
X2NvcHkJICMgbGluZSAwLCAweDAoUDY0KSwgPD50NTM2LCBhZGRyKF9EeUNS
VF9EdW1teUdsb2JhbCQxLjkpKFA2NCksIDAoSTMyKSwgMChJMzIpLCAwKEkz
MiksIDAoSTMyKQogI2luc3RyCglicgkkMzEsTDIwJDMKICNtYXJrX3RyYWNl
IDEwNDsKTDE4JDM6CmludGVycHJldGVyLmR5bl90ZW1wbGF0ZV9iZWdpbl8x
NDoKICNpbnN0cgoJc3RxCSQzMSxEeUNSVF9EdW1teUdsb2JhbAkgI2NsYXNz
IHNvdXJjZQkgIyBsaW5lIDAsIDB4MChQNjQpLCA8PnQ1MzYsIGFkZHIoX0R5
Q1JUX0R1bW15R2xvYmFsJDEuOSkoUDY0KSwgMChJMzIpLCAwKEkzMiksIDAo
STMyKSwgMChJMzIpCglsZGEJJDIwLGludGVycHJldGVyLnN0YXRpY19icmFu
Y2hfMzFfMCgkMzEpCSAjY2xhc3MgZG1vdmUsZG1fY29uc3RhbnQJICMgaW50
ZXJwcmV0ZXIuc3RhdGljX2JyYW5jaF8zMV8wCgkgIyBzdGFsbCAJMQppbnRl
cnByZXRlci5keW5fdGVtcGxhdGVfZW5kXzE0X246CiAjaW5zdHIKCXN0cQkk
MzEsRHlDUlRfRHVtbXlHbG9iYWwJICNjbGFzcyBzb3VyY2UJICMgbGluZSAw
LCAweDAoUDY0KSwgPD50NTM2LCBhZGRyKF9EeUNSVF9EdW1teUdsb2JhbCQx
LjkpKFA2NCksIDAoSTMyKSwgMChJMzIpLCAwKEkzMiksIDAoSTMyKQogI2lu
c3RyCglicgkkMzEsTDE5JDMKICNtYXJrX3RyYWNlIDIwMjsKTDEkMzoKaW50
ZXJwcmV0ZXIuZHluX3RlbXBsYXRlX2JlZ2luXzI6CiAjaW5zdHIKLmxvYyAy
IDExMQoJbGRhCSQxNixfaW9iKzExMgkgI2NsYXNzIHNvdXJjZQkgIyBsaW5l
IDExMSwgPD50MTAyMCwgPD50NTM2LCAoYWRkcihfX2lvYiQxLjApKFA2NCkg
KyAweDcwKEk2NCkpKFA2NCkKICNpbnN0cgoubG9jIDIgMTExCglsZGEJJDE3
LF8kMVNUUklOR1BBQ0tFVC4xCSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMTEx
LCA8PnQxMDIxLCA8PnQ1MzYsIGFkZHIoXyQxU1RSSU5HVkFSLjEpKFA2NCkK
ICNtYXJrX2NhbGwgY2FsbGVyX3NhdmVzLCByZWdzLCBhdHlwZXMobjY0LG42
NCksIHJ0eXBlcyhuMzIpOwogI2luc3RyCglvcgkkMzEsJDMxLCQzMQkgI2Ns
YXNzIGRtb3ZlLGRtX3JlZ2lzdGVyCSAjIDw+dDUzMwoubG9jIDIgMTExCglq
c3IJJDI2LGZwcmludGYKCWJyCSQyNixGQUtFMzQKRkFLRTM0OglsZGdwCSRn
cCwwKCQyNikJICNjbGFzcyBzb3VyY2UJICMgbGluZSAxMTEsIHJhZGRyKGZw
cmludGYpKFA2NCksIDw+dDUzMywgPD50MTAyMCwgPD50MTAyMQoJICMgc3Rh
bGwgCTEKICNpbnN0cgoJbGRxCSQyNiwkMi4xJDJyYXNfcCgkc3ApCSAjY2xh
c3MgZG1vdmUsZG1fcmVzdG9yZQkgIyA8PnQ1MzIKCW9yCSQzMSwkMzEsJDAJ
ICNjbGFzcyBkbW92ZSxkbV9jb25zdGFudAkgIyAwKFNJMzIpCiAjaW5zdHIK
CXN0cQkkMzEsRHlDUlRfRHVtbXlHbG9iYWwJICNjbGFzcyBzb3VyY2UJICMg
bGluZSAwLCAweDAoUDY0KSwgPD50NTM2LCBhZGRyKF9EeUNSVF9EdW1teUds
b2JhbCQxLjkpKFA2NCksIDAoSTMyKSwgMChJMzIpLCAwKEkzMiksIDAoSTMy
KQoJICMgc3RhbGwgCTEKICNpbnN0cgoJc3RxCSQzMSxEeUNSVF9EdW1teUds
b2JhbAkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDAsIDB4MChQNjQpLCA8PnQ1
MzYsIGFkZHIoX0R5Q1JUX0R1bW15R2xvYmFsJDEuOSkoUDY0KSwgMChJMzIp
LCAwKEkzMiksIDAoSTMyKSwgMChJMzIpCgkgIyBzdGFsbCAJMQppbnRlcnBy
ZXRlci5keW5fdGVtcGxhdGVfZW5kXzJfbjoKICNtYXJrX3JldHVybiBydHlw
ZXMobjMyKTsKICNpbnN0cgoubG9jIDIgMTExCglsZGEJJHNwLCQyLjEkMmF1
dG9fc2l6ZSgkc3ApCglyZXQJJDMxLCgkMjYpLDEJICNjbGFzcyBzb3VyY2UJ
ICMgbGluZSAxMTEsIDw+dDUzMywgJDIuMSQyYXV0b19zaXplKEkzMiksIDw+
dDUzMgogI21hcmtfdHJhY2UgMTcxOwppbnRlcnByZXRlci5EWUMuTEFaWV9F
REdFX1RBUkdFVC4wOgogI2luc3RyCglzdHEJJDAsJDIuMSQycmFzX3AoJHNw
KQkgI2NsYXNzIGRtb3ZlLGRtX3NwaWxsCSAjIDw+dDUzMgoubG9jIDIgMjYK
CWxkYQkkMjUsaW50ZXJwcmV0ZXIuRFlDLkdFX0VOVFJZLkNBTEwuMS4xMzkJ
ICNjbGFzcyBzb3VyY2UsY3NwZWMJICMgbGluZSAyNiwgPD50NzAxLCA8PnQ1
MzYsIHRhZyhpbnRlcnByZXRlci5EWUMuR0VfRU5UUlkuQ0FMTC4xLjEzOSko
UDY0KQogI2luc3RyCglzdGwJJDE4LCQyLjEkMnNwaWxsX3AgKyAzMzYoJHNw
KQkgI2NsYXNzIGRtb3ZlLGRtX3NwaWxsCSAjIDxfYXJnJDEuMT50NDUzCglv
cgkkMzEsJDMxLCQzMQkgI2NsYXNzIGRtb3ZlLGRtX3JlZ2lzdGVyCSAjIDw+
dDUzMwogI2luc3RyCglzdGwJJDIxLCQyLjEkMnNwaWxsX3AgKyAzNDQoJHNw
KQkgI2NsYXNzIGRtb3ZlLGRtX3NwaWxsCSAjIDxfbXVsdDIkMS4yPnQzCiAj
aW5zdHIKCXN0bAkkMiwkMi4xJDJzcGlsbF9wICsgMzUyKCRzcCkJICNjbGFz
cyBkbW92ZSxkbV9zcGlsbAkgIyA8X211bHQxJDEuMj50MgogI2luc3RyCglz
dHEJJDEsJDIuMSQyc3BpbGxfcCArIDM2MCgkc3ApCSAjY2xhc3MgZG1vdmUs
ZG1fc3BpbGwJICMgPD50MAogI2luc3RyCi5sb2MgMiAyNgoJbGRxCSQyNCxp
bnRlcnByZXRlci5MU1ZGcmVlTGlzdC4xCSAjY2xhc3Mgc291cmNlCSAjIGxp
bmUgMjYsIDw+dDExMDQsIDw+dDUzNiwgYWRkcihpbnRlcnByZXRlci5MU1ZG
cmVlTGlzdC5WQVIuMSkoUDY0KQoJICMgc3RhbGwgCTIKICNpbnN0cgoubG9j
IDIgMjYKCWJuZQkkMjQsTDI3JDMJICNjbGFzcyBzb3VyY2UJICMgbGluZSAy
NiwgPD50MTEwNAogI2luc3RyCi5sb2MgMiAyNgoJbGRxCSQzLER5Q1JUX1Rl
bXBMb2NhdGlvbgkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDI2LCA8PnQxMTAx
LCA8PnQ1MzYsIGFkZHIoX0R5Q1JUX1RlbXBMb2NhdGlvbiQxLjApKFA2NCkK
ICNpbnN0cgoJc3RxCSQzMSxEeUNSVF9Xb3JrTGlzdAkgI2NsYXNzIHNvdXJj
ZQkgIyBsaW5lIDAsIDB4MChQNjQpLCA8PnQ1MzYsIGFkZHIoX0R5Q1JUX1dv
cmtMaXN0JDEuMCkoUDY0KSwgMChJMzIpLCAwKEkzMiksIDAoSTMyKSwgMChJ
MzIpCgljcHlzCSRmMzEsJGYzMSwkZjMxCSMgcGFkCgkgIyBzdGFsbCAJMQog
I2luc3RyCglzdHEJJDMsJDIuMSQyc3BpbGxfcCArIDM2OCgkc3ApCSAjY2xh
c3MgZG1vdmUsZG1fc3BpbGwJICMgPD50MTEwMQoubG9jIDIgMjYKCWFkZHEJ
JDMsMTYsJDI0CSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMjYsIDxfRHlDUlRf
VGVtcExvY2F0aW9uJDEuMD50MTEwNiwgPD50MTEwMSwgMTYoSTMyKQogI2lu
c3RyCglzdHEJJDE2LDgoJDMpCSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMCwg
PF9ieXRlY29kZXMkMS4xPnQxMTA4LCA8PnQxMTAxLCA4KFNJMzIpLCAwKEkz
MiksIDAoSTMyKSwgMChJMzIpLCAwKEkzMikKCWNweXMJJGYzMSwkZjMxLCRm
MzEJIyBwYWQKICNpbnN0cgoJc3RsCSQzMSw0KCQzKQkgI2NsYXNzIHNvdXJj
ZQkgIyBsaW5lIDAsIDAoU0kzMiksIDw+dDExMDEsIDQoU0kzMiksIDAoSTMy
KSwgMChJMzIpLCAwKEkzMiksIDAoSTMyKQoJb3IJJDI1LCQzMSwkMTYJICNj
bGFzcyBkbW92ZSxkbV9yZWdpc3RlcgkgIyA8PnQ3MDEKICNpbnN0cgoJc3Rs
CSQxNywwKCQzKQkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDAsIDxfcGMkMS4x
PnQxMTA5LCA8PnQxMTAxLCAwKFNJMzIpLCAwKEkzMiksIDAoSTMyKSwgMChJ
MzIpLCAwKEkzMikKICNpbnN0cgoubG9jIDIgMjYKCXN0cQkkMjQsRHlDUlRf
VGVtcExvY2F0aW9uCSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMjYsIDxfRHlD
UlRfVGVtcExvY2F0aW9uJDEuMD50MTEwNiwgPD50NTM2LCBhZGRyKF9EeUNS
VF9UZW1wTG9jYXRpb24kMS4wKShQNjQpLCAwKEkzMiksIDAoSTMyKSwgMChJ
MzIpLCAwKEkzMikKTDI4JDM6CiAjbWFya19jYWxsIGNhbGxlcl9zYXZlcywg
cmVncywgYXR5cGVzKG42NCksIHJ0eXBlcyhuNjQpOwogI2luc3RyCi5sb2Mg
MiAyNgoJanNyCSQyNixEeUNSVF9DYWxsR2VuZXJhdGluZ0V4dGVuc2lvbgoJ
YnIJJDI2LEZBS0UzMwpGQUtFMzM6CWxkZ3AJJGdwLDAoJDI2KQkgI2NsYXNz
IHNvdXJjZQkgIyBsaW5lIDI2LCByYWRkcihEeUNSVF9DYWxsR2VuZXJhdGlu
Z0V4dGVuc2lvbikoUDY0KSwgPD50NTMzLCA8PnQ3MDEKICNpbnN0cgoJbGRx
CSQxLCQyLjEkMnNwaWxsX3AgKyAzNjAoJHNwKQkgI2NsYXNzIGRtb3ZlLGRt
X3Jlc3RvcmUJICMgPD50MAogI2luc3RyCglsZGwJJDIsJDIuMSQyc3BpbGxf
cCArIDM1Migkc3ApCSAjY2xhc3MgZG1vdmUsZG1fcmVzdG9yZQkgIyA8X211
bHQxJDEuMj50MgogI2luc3RyCglsZGwJJDIxLCQyLjEkMnNwaWxsX3AgKyAz
NDQoJHNwKQkgI2NsYXNzIGRtb3ZlLGRtX3Jlc3RvcmUJICMgPF9tdWx0MiQx
LjI+dDMKICNpbnN0cgoJbGRsCSQxOCwkMi4xJDJzcGlsbF9wICsgMzM2KCRz
cCkJICNjbGFzcyBkbW92ZSxkbV9yZXN0b3JlCSAjIDxfYXJnJDEuMT50NDUz
CgljcHlzCSRmMzEsJGYzMSwkZjMxCSMgcGFkCiAjaW5zdHIKCW9yCSQwLCQz
MSwkMjUJICNjbGFzcyBkbW92ZSxkbV9yZWdpc3RlcgkgIyA8PnQ1ODAKCWxk
cQkkMywkMi4xJDJzcGlsbF9wICsgMzY4KCRzcCkJICNjbGFzcyBkbW92ZSxk
bV9yZXN0b3JlCSAjIDw+dDExMDEKCSAjIHN0YWxsIAkxCiAjaW5zdHIKCWxk
cQkkMCwkMi4xJDJyYXNfcCgkc3ApCSAjY2xhc3MgZG1vdmUsZG1fcmVzdG9y
ZQkgIyA8PnQ1MzIKCSAjIHN0YWxsIAkxCiAjaW5zdHIKCWptcAkkMzEsKCQy
NSkJICNjbGFzcyBzb3VyY2UJICMgbGluZSAwLCA8PnQ1ODAKICNtYXJrX3Ry
YWNlIDIwNDsKaW50ZXJwcmV0ZXIuRFlDLkdFX0VOVFJZLkNBTEwuMS4xMzk6
CiAjaW5zdHIKLmxvYyAyIDI2CglsZHEJJDIxLER5Q1JUX0NvZGVMb2NhdGlv
bgkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDI2LCA8PnQxMTA1LCA8PnQ1MzYs
IGFkZHIoX0R5Q1JUX0NvZGVMb2NhdGlvbiQxLjApKFA2NCkKLmxvYyAyIDI2
CglzdWJxCSQzMSwzMiwkMjAJICNjbGFzcyBzb3VyY2UJICMgbGluZSAyNiwg
PF9BbGlnbmVkQWRkcmVzcyQxLjU4PnQxMDMyLCAwKEk2NCksIDMyKFNJNjQp
CiAjaW5zdHIKLmxvYyAyIDI2CglsZHEJJDE5LER5Q1JUX1BhZGRlZEJ5dGVz
CSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMjYsIDxfRHlDUlRfUGFkZGVkQnl0
ZXMkMS4wPnQxMDk4LCA8PnQ1MzYsIGFkZHIoX0R5Q1JUX1BhZGRlZEJ5dGVz
JDEuMCkoUDY0KQoJb3IJJDMxLCQzMSwkMjUJICNjbGFzcyBzb3VyY2UJICMg
bGluZSAwLCA8PnQ1ODcsIDAoSTMyKQogI2luc3RyCglzdHEJJDMxLER5Q1JU
X0R1bW15R2xvYmFsCSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMCwgMHgwKFA2
NCksIDw+dDUzNiwgYWRkcihfRHlDUlRfRHVtbXlHbG9iYWwkMS45KShQNjQp
LCAwKEkzMiksIDAoSTMyKSwgMChJMzIpLCAwKEkzMikKCWxkYWgJJDI3LDEo
JDMxKQkgI2NsYXNzIGRtb3ZlLGRtX2NvbnN0YW50CSAjIDY1NTM2KEkzMikK
ICNpbnN0cgoubG9jIDIgMjYKCWFkZHEJJDIxLDYzLCQxOAkgI2NsYXNzIHNv
dXJjZQkgIyBsaW5lIDI2LCA8PnQxMTAwLCA8PnQxMTA1LCA2MyhTSTY0KQoJ
bGRsCSQyMiwwKCQzKQkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDAsIDxfcGMk
MS4xPnQ0NTQsIDw+dDExMDEsIDAoU0kzMikKICNpbnN0cgoubG9jIDIgMjYK
CWFuZAkkMTgsJDIwLCQyMAkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDI2LCA8
X0FsaWduZWRBZGRyZXNzJDEuNTg+dDEwOTksIDw+dDExMDAsIDxfQWxpZ25l
ZEFkZHJlc3MkMS41OD50MTAzMgoJbGRxCSQyMyw4KCQzKQkgI2NsYXNzIHNv
dXJjZQkgIyBsaW5lIDAsIDxfYnl0ZWNvZGVzJDEuMT50NDU1LCA8PnQxMTAx
LCA4KFNJMzIpCiAjaW5zdHIKLmxvYyAyIDI2CglzdWJxCSQyMCwkMjEsJDIx
CSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMjYsIDxfRHlDUlRfUGFkZGVkQnl0
ZXMkMS4wPnQxMDMzLCA8X0FsaWduZWRBZGRyZXNzJDEuNTg+dDEwOTksIDw+
dDExMDUKCXN0cQkkMjAsaW50ZXJwcmV0ZXIuQ2FjaGUuMQkgI2NsYXNzIHNv
dXJjZQkgIyBsaW5lIDAsIDxfQWxpZ25lZEFkZHJlc3MkMS41OD50MTA5OSwg
PD50NTM2LCBhZGRyKGludGVycHJldGVyLkNhY2hlLlZBUi4xKShQNjQpLCAw
KEkzMiksIDAoSTMyKSwgMChJMzIpLCAwKEkzMikKICNpbnN0cgoubG9jIDIg
MjYKCWFkZHEJJDIxLCQxOSwkMTkJICNjbGFzcyBzb3VyY2UJICMgbGluZSAy
NiwgPF9EeUNSVF9QYWRkZWRCeXRlcyQxLjA+dDEwOTcsIDxfRHlDUlRfUGFk
ZGVkQnl0ZXMkMS4wPnQxMDMzLCA8X0R5Q1JUX1BhZGRlZEJ5dGVzJDEuMD50
MTA5OAoubG9jIDIgMjYKCXN0cQkkMTksRHlDUlRfUGFkZGVkQnl0ZXMJICNj
bGFzcyBzb3VyY2UJICMgbGluZSAyNiwgPF9EeUNSVF9QYWRkZWRCeXRlcyQx
LjA+dDEwOTcsIDw+dDUzNiwgYWRkcihfRHlDUlRfUGFkZGVkQnl0ZXMkMS4w
KShQNjQpLCAwKEkzMiksIDAoSTMyKSwgMChJMzIpLCAwKEkzMikKICNpbnN0
cgoubG9jIDIgMjYKCWxkcQkkMjEsaW50ZXJwcmV0ZXIuTFNWRnJlZUxpc3Qu
MQkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDI2LCA8PnQxMDk2LCA8PnQ1MzYs
IGFkZHIoaW50ZXJwcmV0ZXIuTFNWRnJlZUxpc3QuVkFSLjEpKFA2NCkKCW9y
CSQyMCwkMzEsJDI0CSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMCwgPD50NTc3
LCA8X0FsaWduZWRBZGRyZXNzJDEuNTg+dDEwOTkKICNpbnN0cgoJbGRhCSQx
OSwxKCQzMSkJICNjbGFzcyBkbW92ZSxkbV9jb25zdGFudAkgIyAxKEkzMikK
CSAjIHN0YWxsIAkxCiAjaW5zdHIKLmxvYyAyIDI2CglzdHEJJDIxLDAoJDMp
CSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMjYsIDw+dDEwOTYsIDw+dDExMDEs
IDAoSTY0KSwgMChJMzIpLCAwKEkzMiksIDAoSTMyKSwgMChJMzIpCiAjaW5z
dHIKLmxvYyAyIDI2CglzdHEJJDMsaW50ZXJwcmV0ZXIuTFNWRnJlZUxpc3Qu
MQkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDI2LCA8PnQxMTAxLCA8PnQ1MzYs
IGFkZHIoaW50ZXJwcmV0ZXIuTFNWRnJlZUxpc3QuVkFSLjEpKFA2NCksIDAo
STMyKSwgMChJMzIpLCAwKEkzMiksIDAoSTMyKQogI2luc3RyCglzdHEJJDIw
LER5Q1JUX1N0aXRjaExvY2F0aW9uCSAjY2xhc3Mgc291cmNlCSAjIGxpbmUg
MCwgPF9BbGlnbmVkQWRkcmVzcyQxLjU4PnQxMDk5LCA8PnQ1MzYsIGFkZHIo
X0R5Q1JUX1N0aXRjaExvY2F0aW9uJDEuMCkoUDY0KSwgMChJMzIpLCAwKEkz
MiksIDAoSTMyKSwgMChJMzIpCiAjaW5zdHIKCWxkcQkkMjEsRHlDUlRfU3Rh
dGljVmFsdWVUYWJsZQkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDAsIDw+dDEw
OTUsIDw+dDUzNiwgYWRkcihfRHlDUlRfU3RhdGljVmFsdWVUYWJsZSQxLjAp
KFA2NCkKCSAjIHN0YWxsIAkyCiAjaW5zdHIKCWJlcQkkMjEsTDI5JDMJICNj
bGFzcyBzb3VyY2UJICMgbGluZSAwLCA8PnQxMDk1CiAjaW5zdHIKCWxkbAkk
MjEsRHlDUlRfU1ZUSW5kZXgJICNjbGFzcyBzb3VyY2UJICMgbGluZSAwLCA8
PnQxMDk0LCA8PnQ1MzYsIGFkZHIoX0R5Q1JUX1NWVEluZGV4JDEuMCkoUDY0
KQoJICMgc3RhbGwgCTIKICNpbnN0cgoJYWRkbAkkMjEsMTYsJDIxCSAjY2xh
c3Mgc291cmNlCSAjIGxpbmUgMCwgPD50MTA5MiwgPD50MTA5NCwgMTYoU0kz
MikKICNpbnN0cgoJY21wbGUJJDIxLCQyNywkMjAJICNjbGFzcyBzb3VyY2UJ
ICMgbGluZSAwLCA8PnQ3MDQsIDw+dDEwOTIsIDY1NTM2KEkzMikKCSAjIHN0
YWxsIAkxCiAjaW5zdHIKCWJlcQkkMjAsTDI5JDMJICNjbGFzcyBzb3VyY2UJ
ICMgbGluZSAwLCA8PnQ3MDQKICNpbnN0cgoJc3RsCSQxOSxEeUNSVF9CdWls
ZFRhYmxlUG9pbnRlcgkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDAsIDEoSTMy
KSwgPD50NTM2LCBhZGRyKF9EeUNSVF9CdWlsZFRhYmxlUG9pbnRlciQxLjAp
KFA2NCksIDAoSTMyKSwgMChJMzIpLCAwKEkzMiksIDAoSTMyKQogI21hcmtf
dHJhY2UgMjIzOwogI2luc3RyCglzdGwJJDIyLCQyLjEkMnNwaWxsX3AgKyA5
Nigkc3ApCSAjY2xhc3MgZG1vdmUsZG1fc3BpbGwJICMgPF9wYyQxLjE+dDQ1
NAogI2luc3RyCglzdHEJJDIzLCQyLjEkMnNwaWxsX3AgKyA4OCgkc3ApCSAj
Y2xhc3MgZG1vdmUsZG1fc3BpbGwJICMgPF9ieXRlY29kZXMkMS4xPnQ0NTUK
ICNpbnN0cgoJc3RxCSQyNCwkMi4xJDJzcGlsbF9wICsgMTYoJHNwKQkgI2Ns
YXNzIGRtb3ZlLGRtX3NwaWxsCSAjIDw+dDU3NwogI2luc3RyCglzdGwJJDI1
LCQyLjEkMnNwaWxsX3AoJHNwKQkgI2NsYXNzIGRtb3ZlLGRtX3NwaWxsCSAj
IDw+dDU4NwogI2luc3RyCglicgkkMzEsTDMwJDMKICNtYXJrX3RyYWNlIDIw
NTsKTDMxJDM6CmludGVycHJldGVyLkRZQy5VTklUX0hFQUQuU0VUVVAuMToK
aW50ZXJwcmV0ZXIuZHluX3NldHVwX2JlZ2luXzBfMDoKICNpbnN0cgoJc3Rx
CSQzMSxEeUNSVF9EdW1teUdsb2JhbAkgI2NsYXNzIHNvdXJjZQkgIyBsaW5l
IDAsIDB4MChQNjQpLCA8PnQ1MzYsIGFkZHIoX0R5Q1JUX0R1bW15R2xvYmFs
JDEuOSkoUDY0KSwgMChJMzIpLCAwKEkzMiksIDAoSTMyKSwgMChJMzIpCglv
cgkkMzEsJDMxLCQzMQkgI2NsYXNzIGRtb3ZlLGRtX3JlZ2lzdGVyCSAjIDw+
dDUzMwoJICMgc3RhbGwgCTEKICNpbnN0cgoJc3RxCSQzMSxEeUNSVF9EdW1t
eUdsb2JhbAkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDAsIDB4MChQNjQpLCA8
PnQ1MzYsIGFkZHIoX0R5Q1JUX0R1bW15R2xvYmFsJDEuOSkoUDY0KSwgMChJ
MzIpLCAwKEkzMiksIDAoSTMyKSwgMChJMzIpCiAjbWFya19jYWxsIGNhbGxl
cl9zYXZlcywgcmVncywgYXR5cGVzKCksIHJ0eXBlcygpOwogI2luc3RyCi5s
b2MgMiAyNgoJanNyCSQyNixEeUNSVF9QYXRjaEludHJhVW5pdEJyYW5jaGVz
CglicgkkMjYsRkFLRTM1CkZBS0UzNToJbGRncAkkZ3AsMCgkMjYpCSAjY2xh
c3Mgc291cmNlCSAjIGxpbmUgMjYsIHJhZGRyKER5Q1JUX1BhdGNoSW50cmFV
bml0QnJhbmNoZXMpKFA2NCksIDw+dDUzMwogI2luc3RyCglzdHEJJDMxLER5
Q1JUX0NvZGVMb2NhdGlvbgkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDAsIDB4
MChQNjQpLCA8PnQ1MzYsIGFkZHIoX0R5Q1JUX0NvZGVMb2NhdGlvbiQxLjAp
KFA2NCksIDAoSTMyKSwgMChJMzIpLCAwKEkzMiksIDAoSTMyKQoJbGRhCSQx
OCwxKCQzMSkJICNjbGFzcyBkbW92ZSxkbV9jb25zdGFudAkgIyAxKFNJMzIp
CiAjaW5zdHIKCWxkcQkkMjEsRHlDUlRfTGFzdEJyYW5jaAkgI2NsYXNzIHNv
dXJjZQkgIyBsaW5lIDAsIDw+dDEwODYsIDw+dDUzNiwgYWRkcihfRHlDUlRf
TGFzdEJyYW5jaCQxLjApKFA2NCkKCW9yCSQzMSwkMzEsJDMxCSAjY2xhc3Mg
ZG1vdmUsZG1fcmVnaXN0ZXIJICMgPD50NTMzCiAjaW5zdHIKLmxvYyAyIDI2
CglsZHEJJDIwLGludGVycHJldGVyLkxTVkZyZWVMaXN0LjIJICNjbGFzcyBz
b3VyY2UJICMgbGluZSAyNiwgPD50MTA4NSwgPD50NTM2LCBhZGRyKGludGVy
cHJldGVyLkxTVkZyZWVMaXN0LlZBUi4yKShQNjQpCiAjaW5zdHIKCWxkbAkk
MjIsJDIuMSQyc3BpbGxfcCArIDk2KCRzcCkJICNjbGFzcyBkbW92ZSxkbV9y
ZXN0b3JlCSAjIDxfcGMkMS4xPnQ0NTQKICNpbnN0cgoJc3RxCSQyMSwkMi4x
JDJzcGlsbF9wICsgMzc2KCRzcCkJICNjbGFzcyBkbW92ZSxkbV9zcGlsbAkg
IyA8PnQxMDg2CgljcHlzCSRmMzEsJGYzMSwkZjMxCSMgcGFkCmludGVycHJl
dGVyLmR5bl9zZXR1cF9lbmRfMF8wOgogI2luc3RyCglsZHEJJDIzLCQyLjEk
MnNwaWxsX3AgKyA4OCgkc3ApCSAjY2xhc3MgZG1vdmUsZG1fcmVzdG9yZQkg
IyA8X2J5dGVjb2RlcyQxLjE+dDQ1NQoubG9jIDIgMjYKCWJuZQkkMjAsTDMy
JDMJICNjbGFzcyBzb3VyY2UJICMgbGluZSAyNiwgPD50MTA4NQogI2luc3Ry
Ci5sb2MgMiAyNgoJbGRxCSQxNyxEeUNSVF9UZW1wTG9jYXRpb24JICNjbGFz
cyBzb3VyY2UJICMgbGluZSAyNiwgPD50MTA4MSwgPD50NTM2LCBhZGRyKF9E
eUNSVF9UZW1wTG9jYXRpb24kMS4wKShQNjQpCiAjaW5zdHIKCWxkcQkkMTYs
aW50ZXJwcmV0ZXIuQ2FjaGUuMgkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDAs
IDw+dDEwODAsIDw+dDUzNiwgYWRkcihpbnRlcnByZXRlci5DYWNoZS5WQVIu
MikoUDY0KQoJICMgc3RhbGwgCTEKICNpbnN0cgoJc3RxCSQxNywkMi4xJDJz
cGlsbF9wICsgMzg0KCRzcCkJICNjbGFzcyBkbW92ZSxkbV9zcGlsbAkgIyA8
PnQxMDgxCi5sb2MgMiAyNgoJYWRkcQkkMTcsMTYsJDIxCSAjY2xhc3Mgc291
cmNlCSAjIGxpbmUgMjYsIDxfRHlDUlRfVGVtcExvY2F0aW9uJDEuMD50MTA4
MiwgPD50MTA4MSwgMTYoSTMyKQogI2luc3RyCglzdHEJJDE2LCQyLjEkMnNw
aWxsX3AgKyAzOTIoJHNwKQkgI2NsYXNzIGRtb3ZlLGRtX3NwaWxsCSAjIDw+
dDEwODAKICNpbnN0cgoubG9jIDIgMjYKCXN0cQkkMjEsRHlDUlRfVGVtcExv
Y2F0aW9uCSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMjYsIDxfRHlDUlRfVGVt
cExvY2F0aW9uJDEuMD50MTA4MiwgPD50NTM2LCBhZGRyKF9EeUNSVF9UZW1w
TG9jYXRpb24kMS4wKShQNjQpLCAwKEkzMiksIDAoSTMyKSwgMChJMzIpLCAw
KEkzMikKTDMzJDM6CiAjaW5zdHIKCXN0bAkkMjIsMCgkMTcpCSAjY2xhc3Mg
c291cmNlCSAjIGxpbmUgMCwgPF9wYyQxLjE+dDQ1NCwgPD50MTA4MSwgMChT
STMyKSwgMChJMzIpLCAwKEkzMiksIDAoSTMyKSwgMChJMzIpCiAjaW5zdHIK
CXN0bAkkMzEsNCgkMTcpCSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMCwgMChT
STMyKSwgPD50MTA4MSwgNChTSTMyKSwgMChJMzIpLCAwKEkzMiksIDAoSTMy
KSwgMChJMzIpCiAjaW5zdHIKCXN0cQkkMjMsOCgkMTcpCSAjY2xhc3Mgc291
cmNlCSAjIGxpbmUgMCwgPF9ieXRlY29kZXMkMS4xPnQ0NTUsIDw+dDEwODEs
IDgoU0kzMiksIDAoSTMyKSwgMChJMzIpLCAwKEkzMiksIDAoSTMyKQoJICMg
c3RhbGwgCTEKICNpbnN0cgoJYmVxCSQxNixMMzQkMwkgI2NsYXNzIHNvdXJj
ZQkgIyBsaW5lIDAsIDw+dDEwODAKTDM1JDM6CiAjbWFya19jYWxsIGNhbGxl
cl9zYXZlcywgcmVncywgYXR5cGVzKG42NCxuNjQsbjMyKSwgcnR5cGVzKG42
NCk7CiAjaW5zdHIKCWJpcwkkMzEsJDMxLCQzMQkjIHBhZAoubG9jIDIgMjYK
CWpzcgkkMjYsRFlDX0NBQ0hFX2xvb2t1cAoJYnIJJDI2LEZBS0UzNgpGQUtF
MzY6CWxkZ3AJJGdwLDAoJDI2KQkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDI2
LCByYWRkcihEWUNfQ0FDSEVfbG9va3VwKShQNjQpLCA8PnQ1MzMsIDw+dDEw
ODAsIDw+dDEwODEsIDEoU0kzMikKICNpbnN0cgoJbGRxCSQyMSwkMi4xJDJz
cGlsbF9wICsgMzc2KCRzcCkJICNjbGFzcyBkbW92ZSxkbV9yZXN0b3JlCSAj
IDw+dDEwODYKCWxkYQkkMTgsMSgkMzEpCSAjY2xhc3MgZG1vdmUsZG1fY29u
c3RhbnQJICMgMShTSTMyKQogI2luc3RyCglsZHEJJDI0LCQyLjEkMnNwaWxs
X3AgKyAxNigkc3ApCSAjY2xhc3MgZG1vdmUsZG1fcmVzdG9yZQkgIyA8PnQ1
NzcKCW9yCSQzMSwkMzEsJDMxCSAjY2xhc3MgZG1vdmUsZG1fcmVnaXN0ZXIJ
ICMgPD50NTMzCiAjaW5zdHIKCWxkcQkkMTcsJDIuMSQyc3BpbGxfcCArIDM4
NCgkc3ApCSAjY2xhc3MgZG1vdmUsZG1fcmVzdG9yZQkgIyA8PnQxMDgxCgli
bmUJJDAsTDM2JDMJICNjbGFzcyBzb3VyY2UJICMgbGluZSAwLCA8PnQxMDc5
CiAjaW5zdHIKCW9yCSQzMSwkMzEsJDI1CSAjY2xhc3Mgc291cmNlCSAjIGxp
bmUgMCwgPD50NTg3LCAwKEkzMikKLmxvYyAyIDI2CglsZHEJJDIwLER5Q1JU
X0NvZGVMb2NhdGlvbgkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDI2LCA8PnQx
MDYzLCA8PnQ1MzYsIGFkZHIoX0R5Q1JUX0NvZGVMb2NhdGlvbiQxLjApKFA2
NCkKICNpbnN0cgoJYWRkcQkkMjEsMHg0LCQyMQkgI2NsYXNzIHNvdXJjZQkg
IyBsaW5lIDAsIDw+dDYwNCwgPD50MTA4NiwgMHg0KFA2NCkKCWxkcQkkMTYs
JDIuMSQyc3BpbGxfcCArIDM5Migkc3ApCSAjY2xhc3MgZG1vdmUsZG1fcmVz
dG9yZQkgIyA8PnQxMDgwCiAjaW5zdHIKCXN0bAkkMjUsJDIuMSQyc3BpbGxf
cCgkc3ApCSAjY2xhc3MgZG1vdmUsZG1fc3BpbGwJICMgPD50NTg3CiAjaW5z
dHIKCWNtcGVxCSQyMCwkMjEsJDIxCSAjY2xhc3Mgc291cmNlCSAjIGxpbmUg
MCwgPD50NzE2LCA8PnQxMDYzLCA8PnQ2MDQKCSAjIHN0YWxsIAkxCiAjaW5z
dHIKCWJlcQkkMjEsTDM3JDMJICNjbGFzcyBzb3VyY2UJICMgbGluZSAwLCA8
PnQ3MTYKICNpbnN0cgoJbGRxCSQxOSwkMi4xJDJzcGlsbF9wICsgMzc2KCRz
cCkJICNjbGFzcyBzb3VyY2UJICMgbGluZSAwLCA8PnQxMDYzLCA8PnQxMDg2
CgkgIyBzdGFsbCAJMQogI2luc3RyCgliZXEJJDI0LEwzOCQzCSAjY2xhc3Mg
c291cmNlCSAjIGxpbmUgMCwgPD50NTc3CkwzOSQzOgogI2luc3RyCglzdHEJ
JDE5LCQyLjEkMnNwaWxsX3AgKyA0MDAoJHNwKQkgI2NsYXNzIGRtb3ZlLGRt
X3NwaWxsCSAjIDw+dDEwNjMKICNtYXJrX2NhbGwgY2FsbGVyX3NhdmVzLCBy
ZWdzLCBhdHlwZXMobjY0LG42NCxuMzIsbjY0KSwgcnR5cGVzKCk7CiAjaW5z
dHIKCWJpcwkkMzEsJDMxLCQzMQkjIHBhZAoubG9jIDIgMjYKCWpzcgkkMjYs
RFlDX0NBQ0hFX2luc2VydAoJYnIJJDI2LEZBS0UzNwpGQUtFMzc6CWxkZ3AJ
JGdwLDAoJDI2KQkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDI2LCByYWRkcihE
WUNfQ0FDSEVfaW5zZXJ0KShQNjQpLCA8PnQ1MzMsIDw+dDEwODAsIDw+dDEw
ODEsIDEoU0kzMiksIDw+dDEwNjMKICNpbnN0cgoJbGRxCSQyMCwkMi4xJDJz
cGlsbF9wICsgNDAwKCRzcCkJICNjbGFzcyBkbW92ZSxkbV9yZXN0b3JlCSAj
IDw+dDEwNjMKCWxkYWgJJDI3LDEoJDMxKQkgI2NsYXNzIGRtb3ZlLGRtX2Nv
bnN0YW50CSAjIDY1NTM2KEkzMikKICNpbnN0cgoJbGRxCSQyMSxEeUNSVF9T
dGF0aWNWYWx1ZVRhYmxlCSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMCwgPD50
MTA2MiwgPD50NTM2LCBhZGRyKF9EeUNSVF9TdGF0aWNWYWx1ZVRhYmxlJDEu
MCkoUDY0KQoJbGRhCSQxOSwxKCQzMSkJICNjbGFzcyBkbW92ZSxkbV9jb25z
dGFudAkgIyAxKEkzMikKCSAjIHN0YWxsIAkxCiAjaW5zdHIKCXN0cQkkMjAs
RHlDUlRfU3RpdGNoTG9jYXRpb24JICNjbGFzcyBzb3VyY2UJICMgbGluZSAw
LCA8PnQxMDYzLCA8PnQ1MzYsIGFkZHIoX0R5Q1JUX1N0aXRjaExvY2F0aW9u
JDEuMCkoUDY0KSwgMChJMzIpLCAwKEkzMiksIDAoSTMyKSwgMChJMzIpCgkg
IyBzdGFsbCAJMQogI2luc3RyCgliZXEJJDIxLEw0MCQzCSAjY2xhc3Mgc291
cmNlCSAjIGxpbmUgMCwgPD50MTA2MgogI2luc3RyCglsZGwJJDIxLER5Q1JU
X1NWVEluZGV4CSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMCwgPD50MTA2MSwg
PD50NTM2LCBhZGRyKF9EeUNSVF9TVlRJbmRleCQxLjApKFA2NCkKCSAjIHN0
YWxsIAkyCiAjaW5zdHIKCWFkZGwJJDIxLDIxNiwkMjEJICNjbGFzcyBzb3Vy
Y2UJICMgbGluZSAwLCA8PnQxMDYwLCA8PnQxMDYxLCAyMTYoU0kzMikKICNp
bnN0cgoJY21wbGUJJDIxLCQyNywkMjAJICNjbGFzcyBzb3VyY2UJICMgbGlu
ZSAwLCA8PnQ3MjIsIDw+dDEwNjAsIDY1NTM2KEkzMikKCSAjIHN0YWxsIAkx
CiAjaW5zdHIKCWJlcQkkMjAsTDQwJDMJICNjbGFzcyBzb3VyY2UJICMgbGlu
ZSAwLCA8PnQ3MjIKICNpbnN0cgoJc3RsCSQxOSxEeUNSVF9CdWlsZFRhYmxl
UG9pbnRlcgkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDAsIDEoSTMyKSwgPD50
NTM2LCBhZGRyKF9EeUNSVF9CdWlsZFRhYmxlUG9pbnRlciQxLjApKFA2NCks
IDAoSTMyKSwgMChJMzIpLCAwKEkzMiksIDAoSTMyKQoJY3B5cwkkZjMxLCRm
MzEsJGYzMQkjIHBhZAogI21hcmtfdHJhY2UgMjI2OwogI2luc3RyCglsZGFo
CSQxNywxKCQzMSkJICNjbGFzcyBkbW92ZSxkbV9jb25zdGFudAkgIyA2NTUz
NihJMzIpCglsZGwJJDIyLCQyLjEkMnNwaWxsX3AgKyA5Nigkc3ApCSAjY2xh
c3MgZG1vdmUsZG1fcmVzdG9yZQkgIyA8X3BjJDEuMT50NDU0CiAjaW5zdHIK
CWxkYQkkMTgsMTEoJDMxKQkgI2NsYXNzIGRtb3ZlLGRtX2NvbnN0YW50CSAj
IDExKFNJNjQpCiAjaW5zdHIKCWxkYQkkMTksMTYoJDMxKQkgI2NsYXNzIGRt
b3ZlLGRtX2NvbnN0YW50CSAjIDE2KFNJNjQpCiAjaW5zdHIKCWxkYQkkMjAs
MjEoJDMxKQkgI2NsYXNzIGRtb3ZlLGRtX2NvbnN0YW50CSAjIDIxKFNJNjQp
CgljcHlzCSRmMzEsJGYzMSwkZjMxCSMgcGFkCiAjaW5zdHIKCWxkYQkkMjEs
NCgkMzEpCSAjY2xhc3MgZG1vdmUsZG1fY29uc3RhbnQJICMgNChJNjQpCgls
ZHEJJDIzLCQyLjEkMnNwaWxsX3AgKyA4OCgkc3ApCSAjY2xhc3MgZG1vdmUs
ZG1fcmVzdG9yZQkgIyA8X2J5dGVjb2RlcyQxLjE+dDQ1NQogI2luc3RyCgls
ZGEJJDE2LDI2KCQzMSkJICNjbGFzcyBkbW92ZSxkbV9jb25zdGFudAkgIyAy
NihTSTY0KQoJYnIJJDMxLEw0MSQzCiAjbWFya190cmFjZSAyODsKTDQyJDM6
CmludGVycHJldGVyLkRZQy5VTklUX0hFQUQuU0VUVVAuMjoKaW50ZXJwcmV0
ZXIuZHluX3NldHVwX2JlZ2luXzFfMDoKICNpbnN0cgoubG9jIDIgMzIKCXM0
YWRkbAkkMjIsJDMxLCQyNwkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDMyLCA8
PnQzMjIsIDxfcGMkMS4xPnQ0NTQsIDAoSTY0KQogI2luc3RyCi5sb2MgMiAz
MgoJYWRkcQkkMjcsJDIzLCQxMQkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDMy
LCA8PnQzMjQsIDw+dDMyMiwgPF9ieXRlY29kZXMkMS4xPnQ0NTUKICNpbnN0
cgoubG9jIDIgMzYKCWxkYQkkMTcsLTEoJDE3KQkgI2NsYXNzIHNvdXJjZQkg
IyBsaW5lIDM2LCA8X29mZnNldCQxLjI+dDkyMCwgNjU1MzYoSTMyKSwgLTEo
U0k2NCkKCWNweXMJJGYzMSwkZjMxLCRmMzEJIyBwYWQKICNpbnN0cgoubG9j
IDIgMzIKCWxkbAkkMTEsMCgkMTEpCSAjY2xhc3Mgc291cmNlCSAjIGxpbmUg
MzIsIDxfaW5zdCQxLjI+dDMzNywgPD50MzI0LCAwKEk2NCkKCW9yCSQzMSwk
MzEsJDMxCSAjY2xhc3MgZG1vdmUsZG1fcmVnaXN0ZXIJICMgPD50NTMzCgkg
IyBzdGFsbCAJMgogI2luc3RyCi5sb2MgMiAzMwoJbXNrbGwJJDExLCQyMSwk
MjEJICNjbGFzcyBzb3VyY2UJICMgbGluZSAzMywgPD50NTQ4LCA8X2luc3Qk
MS4yPnQzMzcsIDQoSTY0KQogI2luc3RyCi5sb2MgMiAzNgoJYW5kCSQxMSwk
MTcsJDE3CSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMzYsIDxfb2Zmc2V0JDEu
Mj50NTI3LCA8X2luc3QkMS4yPnQzMzcsIDxfb2Zmc2V0JDEuMj50OTIwCiAj
aW5zdHIKLmxvYyAyIDMzCglzcmwJJDIxLCQyMCwkMjAJICNjbGFzcyBzb3Vy
Y2UJICMgbGluZSAzMywgPD50MzI3LCA8PnQ1NDgsIDIxKFNJNjQpCiAjaW5z
dHIKLmxvYyAyIDM0CglzcmwJJDIxLCQxOSwkMTkJICNjbGFzcyBzb3VyY2UJ
ICMgbGluZSAzNCwgPD50MzMwLCA8PnQ1NDgsIDE2KFNJNjQpCiAjaW5zdHIK
LmxvYyAyIDMzCglhbmQJJDIwLDMxLCQyMAkgI2NsYXNzIHNvdXJjZQkgIyBs
aW5lIDMzLCA8X3JzJDEuMj50NTMwLCA8PnQzMjcsIDMxKEkzMikKICNpbnN0
cgoubG9jIDIgMzQKCWFuZAkkMTksMzEsJDE5CSAjY2xhc3Mgc291cmNlCSAj
IGxpbmUgMzQsIDxfcnQkMS4yPnQ1MjksIDw+dDMzMCwgMzEoSTMyKQogI2lu
c3RyCi5sb2MgMiAzNQoJc3JsCSQyMSwkMTgsJDE4CSAjY2xhc3Mgc291cmNl
CSAjIGxpbmUgMzUsIDw+dDMzMywgPD50NTQ4LCAxMShTSTY0KQogI2luc3Ry
Ci5sb2MgMiAzOQoJc3JsCSQyMSwkMTYsJDE2CSAjY2xhc3Mgc291cmNlCSAj
IGxpbmUgMzksIDw+dDMzOCwgPD50NTQ4LCAyNihTSTY0KQogI2luc3RyCi5s
b2MgMiAzNQoJYW5kCSQxOCwzMSwkMTgJICNjbGFzcyBzb3VyY2UJICMgbGlu
ZSAzNSwgPF9yZCQxLjI+dDUyOCwgPD50MzMzLCAzMShJMzIpCiAjaW5zdHIK
LmxvYyAyIDExMgoJY21wbHQJJDE2LCQxNCwkMjcJICNjbGFzcyBzb3VyY2UJ
ICMgbGluZSAxMTIsIDw+dDQ0NiwgPD50MzM4LCAxKFNJNjQpCiAjaW5zdHIK
LmxvYyAyIDExMgoJY21wbHQJJDEzLCQxNiwkMTMJICNjbGFzcyBzb3VyY2UJ
ICMgbGluZSAxMTIsIDw+dDQ0NywgNihTSTY0KSwgPD50MzM4CiAjaW5zdHIK
LmxvYyAyIDExMgoJczhhZGRsCSQxNiwkMzEsJDIxCSAjY2xhc3Mgc291cmNl
LGNzcGVjCSAjIGxpbmUgMTEyLCA8PnQ5MTksIDw+dDMzOCwgMChJNjQpCiAj
aW5zdHIKLmxvYyAyIDExMgoJb3IJJDI3LCQxMywkMTMJICNjbGFzcyBzb3Vy
Y2UJICMgbGluZSAxMTIsIDw+dDU2NSwgPD50NDQ2LCA8PnQ0NDcKICNpbnN0
cgoubG9jIDIgNDYKCWNtcGx0CSQxOSwkMTQsJDE0CSAjY2xhc3Mgc291cmNl
LGNzcGVjCSAjIGxpbmUgNDYsIDw+dDM0NSwgPF9ydCQxLjI+dDUyOSwgMShT
STY0KQppbnRlcnByZXRlci5keW5fc2V0dXBfZW5kXzFfMDoKICNpbnN0cgou
bG9jIDIgNDYKCWNtcGx0CSQxMiwkMTksJDEyCSAjY2xhc3Mgc291cmNlLGNz
cGVjCSAjIGxpbmUgNDYsIDw+dDM0NiwgMzEoU0k2NCksIDxfcnQkMS4yPnQ1
MjkKLmxvYyAyIDExMgoJYm5lCSQxMyxMNDMkMwkgI2NsYXNzIHNvdXJjZQkg
IyBsaW5lIDExMiwgPD50NTY1CmludGVycHJldGVyLmR5bl9zZXR1cF9iZWdp
bl8zXzA6CiAjaW5zdHIKLmxvYyAyIDExMgoJbGRxCSQyMSxpbnRlcnByZXRl
ciQyRFlDLlNXSVRDSENPUFkuVEFHUEFDS0VULjUuMC04KCQyMSkJICNjbGFz
cyBzb3VyY2UJICMgbGluZSAxMTIsIDw+dDQ0OSwgPD50OTE5LCAoYWRkcihp
bnRlcnByZXRlciQyRFlDLlNXSVRDSENPUFkuVEFHQVJSQVkuNS4wKShQNjQp
IC0gMHg4KEk2NCkpKFA2NCkKLmxvYyAyIDQ2CglzOGFkZGwJJDE5LCQzMSwk
MjcJICNjbGFzcyBzb3VyY2UsY3NwZWMJICMgbGluZSA0NiwgPD50OTE3LCA8
X3J0JDEuMj50NTI5LCAwKEk2NCkKICNpbnN0cgoubG9jIDIgNDYKCW9yCSQx
NCwkMTIsJDEyCSAjY2xhc3Mgc291cmNlLGNzcGVjCSAjIGxpbmUgNDYsIDw+
dDU3MywgPD50MzQ1LCA8PnQzNDYKICNpbnN0cgoubG9jIDIgNDUKCXM0YWRk
bAkkMTksJDMxLCQxNgkgI2NsYXNzIHNvdXJjZSxjc3BlYwkgIyBsaW5lIDQ1
LCA8PnQ1NDQsIDxfcnQkMS4yPnQ1MjksIDAoSTY0KQppbnRlcnByZXRlci5k
eW5fc2V0dXBfZW5kXzNfMDoKICNpbnN0cgoubG9jIDIgMTEyCglqbXAJJDMx
LCgkMjEpCSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMTEyLCA8PnQ0NDkKXyQx
LmludGVycHJldGVyLlRBRy44LjAuZHljX2NvcHkuMDoKaW50ZXJwcmV0ZXIu
ZHluX3NldHVwX2JlZ2luXzRfMDoKICNpbnN0cgppbnRlcnByZXRlci5keW5f
c2V0dXBfZW5kXzRfMDoKICNpbnN0cgoubG9jIDIgNDYKCWJuZQkkMTIsTDQ0
JDMJICNjbGFzcyBzb3VyY2UJICMgbGluZSA0NiwgPD50NTczCmludGVycHJl
dGVyLmR5bl9zZXR1cF9iZWdpbl82XzA6CiAjaW5zdHIKLmxvYyAyIDQ2Cgls
ZHEJJDI3LGludGVycHJldGVyJDJEWUMuU1dJVENIQ09QWS5UQUdQQUNLRVQu
My4wLTgoJDI3KQkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDQ2LCA8PnQzNDgs
IDw+dDkxNywgKGFkZHIoaW50ZXJwcmV0ZXIkMkRZQy5TV0lUQ0hDT1BZLlRB
R0FSUkFZLjMuMCkoUDY0KSAtIDB4OChJNjQpKShQNjQpCgkgIyBzdGFsbCAJ
MgppbnRlcnByZXRlci5keW5fc2V0dXBfZW5kXzZfMDoKICNpbnN0cgoubG9j
IDIgNDYKCWptcAkkMzEsKCQyNykJICNjbGFzcyBzb3VyY2UJICMgbGluZSA0
NiwgPD50MzQ4Cl8kMS5pbnRlcnByZXRlci5UQUcuMC5ERUZBVUxULmR5Y19j
b3B5LjA6CmludGVycHJldGVyLmR5bl9zZXR1cF9iZWdpbl83XzA6CiAjaW5z
dHIKLmxvYyAyIDQ3CglhZGRsCSQyMiwxLCQyMgkgI2NsYXNzIHNvdXJjZQkg
IyBsaW5lIDQ3LCA8X3BjJDEuMT50NDU0LCA8X3BjJDEuMT50NDU0LCAxKFNJ
MzIpCglzdGwJJDIyLCQyLjEkMnNwaWxsX3AgKyA5Nigkc3ApCSAjY2xhc3Mg
ZG1vdmUsZG1fc3BpbGwJICMgPF9wYyQxLjE+dDQ1NAogI2luc3RyCglzdHEJ
JDMxLER5Q1JUX0R1bW15R2xvYmFsCSAjY2xhc3Mgc291cmNlCSAjIGxpbmUg
MCwgMHgwKFA2NCksIDw+dDUzNiwgYWRkcihfRHlDUlRfRHVtbXlHbG9iYWwk
MS45KShQNjQpLCAwKEkzMiksIDAoSTMyKSwgMChJMzIpLCAwKEkzMikKCSAj
IHN0YWxsIAkxCmludGVycHJldGVyLmR5bl9zZXR1cF9lbmRfN18wOgogI2lu
c3RyCglzdHEJJDMxLER5Q1JUX0R1bW15R2xvYmFsCSAjY2xhc3Mgc291cmNl
CSAjIGxpbmUgMCwgMHgwKFA2NCksIDw+dDUzNiwgYWRkcihfRHlDUlRfRHVt
bXlHbG9iYWwkMS45KShQNjQpLCAwKEkzMiksIDAoSTMyKSwgMChJMzIpLCAw
KEkzMikKTDQ1JDM6CmludGVycHJldGVyLmR5bl9zZXR1cF9iZWdpbl84XzA6
CiAjaW5zdHIKICNpbnN0cgoJc3RxCSQxNixpbnRlcnByZXRlci5ydGNvbnN0
XzhfMF8wKCQzMSkJICNjbGFzcyBzb3VyY2UJICMgbGluZSAwLCA8PnQ1NDQs
IDB4MChQNjQpLCBpbnRlcnByZXRlci5ydGNvbnN0XzhfMF8wLCAwKEkzMiks
IDAoSTMyKSwgMChJMzIpLCAwKEkzMikKCSAjIHN0YWxsIAkxCiAjaW5zdHIK
CXN0bAkkMTksaW50ZXJwcmV0ZXIucnRjb25zdF84XzBfMSgkMzEpCSAjY2xh
c3Mgc291cmNlCSAjIGxpbmUgMCwgPF9ydCQxLjI+dDUyOSwgMHgwKFA2NCks
IGludGVycHJldGVyLnJ0Y29uc3RfOF8wXzEsIDAoSTMyKSwgMChJMzIpLCAw
KEkzMiksIDAoSTMyKQoJICMgc3RhbGwgCTEKaW50ZXJwcmV0ZXIuZHluX3Nl
dHVwX2VuZF84XzA6CiAjaW5zdHIKCXN0bAkkMTcsaW50ZXJwcmV0ZXIucnRj
b25zdF84XzBfMigkMzEpCSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMCwgPF9v
ZmZzZXQkMS4yPnQ1MjcsIDB4MChQNjQpLCBpbnRlcnByZXRlci5ydGNvbnN0
XzhfMF8yLCAwKEkzMiksIDAoSTMyKSwgMChJMzIpLCAwKEkzMikKTDQ2JDM6
CmludGVycHJldGVyLmR5bl9zZXR1cF9iZWdpbl8xMl8wOgogI21hcmtfY2Fs
bCBjYWxsZXJfc2F2ZXMsIHJlZ3MsIGF0eXBlcygpLCBydHlwZXMoKTsKICNp
bnN0cgoubG9jIDIgMjYKCWpzcgkkMjYsRHlDUlRfUGF0Y2hJbnRyYVVuaXRC
cmFuY2hlcwoJYnIJJDI2LEZBS0U2CkZBS0U2OglsZGdwCSRncCwwKCQyNikJ
ICNjbGFzcyBzb3VyY2UJICMgbGluZSAyNiwgcmFkZHIoRHlDUlRfUGF0Y2hJ
bnRyYVVuaXRCcmFuY2hlcykoUDY0KSwgPD50NTMzCiAjaW5zdHIKCXN0cQkk
MzEsRHlDUlRfQ29kZUxvY2F0aW9uCSAjY2xhc3Mgc291cmNlCSAjIGxpbmUg
MCwgMHgwKFA2NCksIDw+dDUzNiwgYWRkcihfRHlDUlRfQ29kZUxvY2F0aW9u
JDEuMCkoUDY0KSwgMChJMzIpLCAwKEkzMiksIDAoSTMyKSwgMChJMzIpCgls
ZGEJJDE4LDEoJDMxKQkgI2NsYXNzIGRtb3ZlLGRtX2NvbnN0YW50CSAjIDEo
U0kzMikKICNpbnN0cgoJbGRxCSQyNyxEeUNSVF9MYXN0QnJhbmNoCSAjY2xh
c3Mgc291cmNlCSAjIGxpbmUgMCwgPD50MTIzMiwgPD50NTM2LCBhZGRyKF9E
eUNSVF9MYXN0QnJhbmNoJDEuMCkoUDY0KQoJb3IJJDMxLCQzMSwkMzEJICNj
bGFzcyBkbW92ZSxkbV9yZWdpc3RlcgkgIyA8PnQ1MzMKICNpbnN0cgoubG9j
IDIgMjYKCWxkcQkkMjEsaW50ZXJwcmV0ZXIuTFNWRnJlZUxpc3QuMgkgI2Ns
YXNzIHNvdXJjZQkgIyBsaW5lIDI2LCA8PnQxMjMzLCA8PnQ1MzYsIGFkZHIo
aW50ZXJwcmV0ZXIuTFNWRnJlZUxpc3QuVkFSLjIpKFA2NCkKICNpbnN0cgoJ
bGRsCSQyMiwkMi4xJDJzcGlsbF9wICsgOTYoJHNwKQkgI2NsYXNzIGRtb3Zl
LGRtX3Jlc3RvcmUJICMgPF9wYyQxLjE+dDQ1NAogI2luc3RyCglzdHEJJDI3
LCQyLjEkMnNwaWxsX3AgKyAxMjgoJHNwKQkgI2NsYXNzIGRtb3ZlLGRtX3Nw
aWxsCSAjIDw+dDEyMzIKCWNweXMJJGYzMSwkZjMxLCRmMzEJIyBwYWQKaW50
ZXJwcmV0ZXIuZHluX3NldHVwX2VuZF8xMl8wOgogI2luc3RyCglsZHEJJDIz
LCQyLjEkMnNwaWxsX3AgKyA4OCgkc3ApCSAjY2xhc3MgZG1vdmUsZG1fcmVz
dG9yZQkgIyA8X2J5dGVjb2RlcyQxLjE+dDQ1NQoubG9jIDIgMjYKCWJuZQkk
MjEsTDQ3JDMJICNjbGFzcyBzb3VyY2UJICMgbGluZSAyNiwgPD50MTIzMwog
I2luc3RyCi5sb2MgMiAyNgoJbGRxCSQxNyxEeUNSVF9UZW1wTG9jYXRpb24J
ICNjbGFzcyBzb3VyY2UJICMgbGluZSAyNiwgPD50MTIzNCwgPD50NTM2LCBh
ZGRyKF9EeUNSVF9UZW1wTG9jYXRpb24kMS4wKShQNjQpCiAjaW5zdHIKCWxk
cQkkMTYsaW50ZXJwcmV0ZXIuQ2FjaGUuMgkgI2NsYXNzIHNvdXJjZQkgIyBs
aW5lIDAsIDw+dDEyMzcsIDw+dDUzNiwgYWRkcihpbnRlcnByZXRlci5DYWNo
ZS5WQVIuMikoUDY0KQoJICMgc3RhbGwgCTEKICNpbnN0cgoJc3RxCSQxNywk
Mi4xJDJzcGlsbF9wICsgMTM2KCRzcCkJICNjbGFzcyBkbW92ZSxkbV9zcGls
bAkgIyA8PnQxMjM0Ci5sb2MgMiAyNgoJYWRkcQkkMTcsMTYsJDI3CSAjY2xh
c3Mgc291cmNlCSAjIGxpbmUgMjYsIDxfRHlDUlRfVGVtcExvY2F0aW9uJDEu
MD50MTIzNiwgPD50MTIzNCwgMTYoSTMyKQogI2luc3RyCglzdHEJJDE2LCQy
LjEkMnNwaWxsX3AgKyAxNDQoJHNwKQkgI2NsYXNzIGRtb3ZlLGRtX3NwaWxs
CSAjIDw+dDEyMzcKICNpbnN0cgoubG9jIDIgMjYKCXN0cQkkMjcsRHlDUlRf
VGVtcExvY2F0aW9uCSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMjYsIDxfRHlD
UlRfVGVtcExvY2F0aW9uJDEuMD50MTIzNiwgPD50NTM2LCBhZGRyKF9EeUNS
VF9UZW1wTG9jYXRpb24kMS4wKShQNjQpLCAwKEkzMiksIDAoSTMyKSwgMChJ
MzIpLCAwKEkzMikKTDQ4JDM6CiAjaW5zdHIKCXN0bAkkMjIsMCgkMTcpCSAj
Y2xhc3Mgc291cmNlCSAjIGxpbmUgMCwgPF9wYyQxLjE+dDQ1NCwgPD50MTIz
NCwgMChTSTMyKSwgMChJMzIpLCAwKEkzMiksIDAoSTMyKSwgMChJMzIpCiAj
aW5zdHIKCXN0bAkkMzEsNCgkMTcpCSAjY2xhc3Mgc291cmNlCSAjIGxpbmUg
MCwgMChTSTMyKSwgPD50MTIzNCwgNChTSTMyKSwgMChJMzIpLCAwKEkzMiks
IDAoSTMyKSwgMChJMzIpCiAjaW5zdHIKCXN0cQkkMjMsOCgkMTcpCSAjY2xh
c3Mgc291cmNlCSAjIGxpbmUgMCwgPF9ieXRlY29kZXMkMS4xPnQ0NTUsIDw+
dDEyMzQsIDgoU0kzMiksIDAoSTMyKSwgMChJMzIpLCAwKEkzMiksIDAoSTMy
KQoJICMgc3RhbGwgCTEKICNpbnN0cgoJYmVxCSQxNixMNDkkMwkgI2NsYXNz
IHNvdXJjZQkgIyBsaW5lIDAsIDw+dDEyMzcKTDUwJDM6CiAjbWFya19jYWxs
IGNhbGxlcl9zYXZlcywgcmVncywgYXR5cGVzKG42NCxuNjQsbjMyKSwgcnR5
cGVzKG42NCk7CiAjaW5zdHIKCWJpcwkkMzEsJDMxLCQzMQkjIHBhZAoubG9j
IDIgMjYKCWpzcgkkMjYsRFlDX0NBQ0hFX2xvb2t1cAoJYnIJJDI2LEZBS0U3
CkZBS0U3OglsZGdwCSRncCwwKCQyNikJICNjbGFzcyBzb3VyY2UJICMgbGlu
ZSAyNiwgcmFkZHIoRFlDX0NBQ0hFX2xvb2t1cCkoUDY0KSwgPD50NTMzLCA8
PnQxMjM3LCA8PnQxMjM0LCAxKFNJMzIpCiAjaW5zdHIKCWxkbAkkMjUsJDIu
MSQyc3BpbGxfcCgkc3ApCSAjY2xhc3MgZG1vdmUsZG1fcmVzdG9yZQkgIyA8
PnQ1ODcKLmxvYyAyIDI2CglzdWJxCSQzMSwzMiwkMjcJICNjbGFzcyBzb3Vy
Y2UsY3NwZWMJICMgbGluZSAyNiwgPF9BbGlnbmVkQWRkcmVzcyQxLjU4PnQ4
MjIsIDAoSTY0KSwgMzIoU0k2NCkKICNpbnN0cgoJbGRxCSQyMSwkMi4xJDJz
cGlsbF9wICsgMTI4KCRzcCkJICNjbGFzcyBkbW92ZSxkbV9yZXN0b3JlCSAj
IDw+dDEyMzIKCWxkYQkkMTgsMSgkMzEpCSAjY2xhc3MgZG1vdmUsZG1fY29u
c3RhbnQJICMgMShTSTMyKQogI2luc3RyCglsZHEJJDI0LCQyLjEkMnNwaWxs
X3AgKyAxNigkc3ApCSAjY2xhc3MgZG1vdmUsZG1fcmVzdG9yZQkgIyA8PnQ1
NzcKCWJuZQkkMCxMNTEkMwkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDAsIDw+
dDEyMzgKICNpbnN0cgoubG9jIDIgMjYKCWxkcQkkMjAsRHlDUlRfQ29kZUxv
Y2F0aW9uCSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMjYsIDw+dDEyNDcsIDw+
dDUzNiwgYWRkcihfRHlDUlRfQ29kZUxvY2F0aW9uJDEuMCkoUDY0KQoJb3IJ
JDMxLCQzMSwkMzEJICNjbGFzcyBkbW92ZSxkbV9yZWdpc3RlcgkgIyA8PnQ1
MzMKICNpbnN0cgoJYWRkcQkkMjEsMHg0LCQyMQkgI2NsYXNzIHNvdXJjZSxj
c3BlYwkgIyBsaW5lIDAsIDw+dDYwOSwgPD50MTIzMiwgMHg0KFA2NCkKCWxk
cQkkMTcsJDIuMSQyc3BpbGxfcCArIDEzNigkc3ApCSAjY2xhc3MgZG1vdmUs
ZG1fcmVzdG9yZQkgIyA8PnQxMjM0CiAjaW5zdHIKCW9yCSQzMSwkMzEsJDE0
CSAjY2xhc3Mgc291cmNlLGNzcGVjCSAjIGxpbmUgMCwgPD50NTg3LCAwKEkz
MikKLmxvYyAyIDI2CgliZXEJJDI1LEw1MiQzCSAjY2xhc3Mgc291cmNlCSAj
IGxpbmUgMjYsIDw+dDU4NwogI2luc3RyCi5sb2MgMiAyNgoJbGRxCSQxMyxE
eUNSVF9QYWRkZWRCeXRlcwkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDI2LCA8
X0R5Q1JUX1BhZGRlZEJ5dGVzJDEuMD50MTI1MCwgPD50NTM2LCBhZGRyKF9E
eUNSVF9QYWRkZWRCeXRlcyQxLjApKFA2NCkKLmxvYyAyIDI2CglhZGRxCSQy
MCw2MywkMTIJICNjbGFzcyBzb3VyY2UJICMgbGluZSAyNiwgPD50MTI0OCwg
PD50MTI0NywgNjMoU0k2NCkKICNpbnN0cgoJc3RsCSQxNCwkMi4xJDJzcGls
bF9wKCRzcCkJICNjbGFzcyBkbW92ZSxkbV9zcGlsbAkgIyA8PnQ1ODcKLmxv
YyAyIDI2CglhbmQJJDEyLCQyNywkMjcJICNjbGFzcyBzb3VyY2UJICMgbGlu
ZSAyNiwgPF9BbGlnbmVkQWRkcmVzcyQxLjU4PnQxMjQ5LCA8PnQxMjQ4LCA8
X0FsaWduZWRBZGRyZXNzJDEuNTg+dDgyMgogI2luc3RyCi5sb2MgMiAyNgoJ
c3VicQkkMjcsJDIwLCQyMAkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDI2LCA8
X0R5Q1JUX1BhZGRlZEJ5dGVzJDEuMD50ODIzLCA8X0FsaWduZWRBZGRyZXNz
JDEuNTg+dDEyNDksIDw+dDEyNDcKCWxkcQkkMTYsJDIuMSQyc3BpbGxfcCAr
IDE0NCgkc3ApCSAjY2xhc3MgZG1vdmUsZG1fcmVzdG9yZQkgIyA8PnQxMjM3
CiAjaW5zdHIKLmxvYyAyIDI2CglhZGRxCSQyMCwkMTMsJDEzCSAjY2xhc3Mg
c291cmNlCSAjIGxpbmUgMjYsIDxfRHlDUlRfUGFkZGVkQnl0ZXMkMS4wPnQx
MjUxLCA8X0R5Q1JUX1BhZGRlZEJ5dGVzJDEuMD50ODIzLCA8X0R5Q1JUX1Bh
ZGRlZEJ5dGVzJDEuMD50MTI1MAoubG9jIDIgMjYKCXN0cQkkMTMsRHlDUlRf
UGFkZGVkQnl0ZXMJICNjbGFzcyBzb3VyY2UJICMgbGluZSAyNiwgPF9EeUNS
VF9QYWRkZWRCeXRlcyQxLjA+dDEyNTEsIDw+dDUzNiwgYWRkcihfRHlDUlRf
UGFkZGVkQnl0ZXMkMS4wKShQNjQpLCAwKEkzMiksIDAoSTMyKSwgMChJMzIp
LCAwKEkzMikKICNpbnN0cgoubG9jIDIgMjYKCW9yCSQyNywkMzEsJDI3CSAj
Y2xhc3Mgc291cmNlCSAjIGxpbmUgMjYsIDw+dDEyNDcsIDxfQWxpZ25lZEFk
ZHJlc3MkMS41OD50MTI0OQoJICMgc3RhbGwgCTEKTDUzJDM6CiAjaW5zdHIK
CWNtcGVxCSQyNywkMjEsJDIxCSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMCwg
PD50ODIxLCA8PnQxMjQ3LCA8PnQ2MDkKCSAjIHN0YWxsIAkxCiAjaW5zdHIK
CWJlcQkkMjEsTDU0JDMJICNjbGFzcyBzb3VyY2UJICMgbGluZSAwLCA8PnQ4
MjEKICNpbnN0cgoJbGRxCSQxOSwkMi4xJDJzcGlsbF9wICsgMTI4KCRzcCkJ
ICNjbGFzcyBzb3VyY2UJICMgbGluZSAwLCA8PnQxMjQ3LCA8PnQxMjMyCgkg
IyBzdGFsbCAJMQogI2luc3RyCgliZXEJJDI0LEw1NSQzCSAjY2xhc3Mgc291
cmNlCSAjIGxpbmUgMCwgPD50NTc3Ckw1NiQzOgogI2luc3RyCglzdHEJJDE5
LCQyLjEkMnNwaWxsX3AgKyAxNTIoJHNwKQkgI2NsYXNzIGRtb3ZlLGRtX3Nw
aWxsCSAjIDw+dDEyNDcKICNtYXJrX2NhbGwgY2FsbGVyX3NhdmVzLCByZWdz
LCBhdHlwZXMobjY0LG42NCxuMzIsbjY0KSwgcnR5cGVzKCk7CiAjaW5zdHIK
CWJpcwkkMzEsJDMxLCQzMQkjIHBhZAoubG9jIDIgMjYKCWpzcgkkMjYsRFlD
X0NBQ0hFX2luc2VydAoJYnIJJDI2LEZBS0U4CkZBS0U4OglsZGdwCSRncCww
KCQyNikJICNjbGFzcyBzb3VyY2UJICMgbGluZSAyNiwgcmFkZHIoRFlDX0NB
Q0hFX2luc2VydCkoUDY0KSwgPD50NTMzLCA8PnQxMjM3LCA8PnQxMjM0LCAx
KFNJMzIpLCA8PnQxMjQ3CiAjaW5zdHIKCWxkcQkkMjAsJDIuMSQyc3BpbGxf
cCArIDE1Migkc3ApCSAjY2xhc3MgZG1vdmUsZG1fcmVzdG9yZQkgIyA8PnQx
MjQ3CglsZGFoCSQyNywxKCQzMSkJICNjbGFzcyBkbW92ZSxkbV9jb25zdGFu
dAkgIyA2NTUzNihJMzIpCiAjaW5zdHIKCWxkcQkkMjEsRHlDUlRfU3RhdGlj
VmFsdWVUYWJsZQkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDAsIDw+dDEyNTks
IDw+dDUzNiwgYWRkcihfRHlDUlRfU3RhdGljVmFsdWVUYWJsZSQxLjApKFA2
NCkKCWxkYQkkMTksMSgkMzEpCSAjY2xhc3MgZG1vdmUsZG1fY29uc3RhbnQJ
ICMgMShJMzIpCgkgIyBzdGFsbCAJMQogI2luc3RyCglzdHEJJDIwLER5Q1JU
X1N0aXRjaExvY2F0aW9uCSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMCwgPD50
MTI0NywgPD50NTM2LCBhZGRyKF9EeUNSVF9TdGl0Y2hMb2NhdGlvbiQxLjAp
KFA2NCksIDAoSTMyKSwgMChJMzIpLCAwKEkzMiksIDAoSTMyKQoJICMgc3Rh
bGwgCTEKICNpbnN0cgoJYmVxCSQyMSxMNTckMwkgI2NsYXNzIHNvdXJjZQkg
IyBsaW5lIDAsIDw+dDEyNTkKICNpbnN0cgoJbGRsCSQyMSxEeUNSVF9TVlRJ
bmRleAkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDAsIDw+dDEyNjAsIDw+dDUz
NiwgYWRkcihfRHlDUlRfU1ZUSW5kZXgkMS4wKShQNjQpCgkgIyBzdGFsbCAJ
MgogI2luc3RyCglhZGRsCSQyMSwyMTYsJDIxCSAjY2xhc3Mgc291cmNlCSAj
IGxpbmUgMCwgPD50MTI2MSwgPD50MTI2MCwgMjE2KFNJMzIpCiAjaW5zdHIK
CWNtcGxlCSQyMSwkMjcsJDI3CSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMCwg
PD50ODI5LCA8PnQxMjYxLCA2NTUzNihJMzIpCgkgIyBzdGFsbCAJMQogI2lu
c3RyCgliZXEJJDI3LEw1NyQzCSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMCwg
PD50ODI5CiAjaW5zdHIKCXN0bAkkMTksRHlDUlRfQnVpbGRUYWJsZVBvaW50
ZXIJICNjbGFzcyBzb3VyY2UJICMgbGluZSAwLCAxKEkzMiksIDw+dDUzNiwg
YWRkcihfRHlDUlRfQnVpbGRUYWJsZVBvaW50ZXIkMS4wKShQNjQpLCAwKEkz
MiksIDAoSTMyKSwgMChJMzIpLCAwKEkzMikKCWNweXMJJGYzMSwkZjMxLCRm
MzEJIyBwYWQKICNtYXJrX3RyYWNlIDE4OTsKICNpbnN0cgoJbGRhaAkkMTcs
MSgkMzEpCSAjY2xhc3MgZG1vdmUsZG1fY29uc3RhbnQJICMgNjU1MzYoSTMy
KQoJbGRsCSQyMiwkMi4xJDJzcGlsbF9wICsgOTYoJHNwKQkgI2NsYXNzIGRt
b3ZlLGRtX3Jlc3RvcmUJICMgPF9wYyQxLjE+dDQ1NAogI2luc3RyCglsZGEJ
JDE4LDExKCQzMSkJICNjbGFzcyBkbW92ZSxkbV9jb25zdGFudAkgIyAxMShT
STY0KQogI2luc3RyCglsZGEJJDE5LDE2KCQzMSkJICNjbGFzcyBkbW92ZSxk
bV9jb25zdGFudAkgIyAxNihTSTY0KQogI2luc3RyCglsZGEJJDIwLDIxKCQz
MSkJICNjbGFzcyBkbW92ZSxkbV9jb25zdGFudAkgIyAyMShTSTY0KQoJY3B5
cwkkZjMxLCRmMzEsJGYzMQkjIHBhZAogI2luc3RyCglsZGEJJDIxLDQoJDMx
KQkgI2NsYXNzIGRtb3ZlLGRtX2NvbnN0YW50CSAjIDQoSTY0KQoJbGRxCSQy
MywkMi4xJDJzcGlsbF9wICsgODgoJHNwKQkgI2NsYXNzIGRtb3ZlLGRtX3Jl
c3RvcmUJICMgPF9ieXRlY29kZXMkMS4xPnQ0NTUKICNpbnN0cgoJbGRhCSQx
NiwyNigkMzEpCSAjY2xhc3MgZG1vdmUsZG1fY29uc3RhbnQJICMgMjYoU0k2
NCkKCWJyCSQzMSxMNTgkMwogI21hcmtfdHJhY2UgNzg7Ckw1NyQzOgogI2lu
c3RyCi5sb2MgMiAyNgoJbGRxCSQxNSxEeUNSVF9UYWJsZUxvY2F0aW9uCSAj
Y2xhc3Mgc291cmNlCSAjIGxpbmUgMjYsIDw+dDEyNjIsIDw+dDUzNiwgYWRk
cihfRHlDUlRfVGFibGVMb2NhdGlvbiQxLjApKFA2NCkKCWxkYWgJJDE3LDEo
JDMxKQkgI2NsYXNzIGRtb3ZlLGRtX2NvbnN0YW50CSAjIDY1NTM2KEkzMikK
ICNpbnN0cgoubG9jIDIgMjYKCWxkbAkkMTEsRHlDUlRfVGFibGVQb2ludGVy
SW5kZXgJICNjbGFzcyBzb3VyY2UJICMgbGluZSAyNiwgPF9EeUNSVF9UYWJs
ZVBvaW50ZXJJbmRleCQxLjA+dDEyNjYsIDw+dDUzNiwgYWRkcihfRHlDUlRf
VGFibGVQb2ludGVySW5kZXgkMS4wKShQNjQpCi5sb2MgMiAyNgoJbGRhCSQ4
LER5Q1JUX1RhYmxlUG9pbnRlcnMrOAkgI2NsYXNzIHNvdXJjZQkgIyBsaW5l
IDI2LCA8PnQ4MzUsIDw+dDUzNiwgKGFkZHIoX0R5Q1JUX1RhYmxlUG9pbnRl
cnMkMS4wKShQNjQpICsgMHg4KEk2NCkpKFA2NCkKICNpbnN0cgoJbGRhCSQ3
LC0zMjc2OCgkMTcpCSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMCwgPD50ODMy
LCA2NTUzNihJMzIpLCAtMzI3NjgoU0k2NCkKCXN0bAkkMTksRHlDUlRfQnVp
bGRUYWJsZVBvaW50ZXIJICNjbGFzcyBzb3VyY2UJICMgbGluZSAwLCAxKEkz
MiksIDw+dDUzNiwgYWRkcihfRHlDUlRfQnVpbGRUYWJsZVBvaW50ZXIkMS4w
KShQNjQpLCAwKEkzMiksIDAoSTMyKSwgMChJMzIpLCAwKEkzMikKICNpbnN0
cgoJYWRkcQkkMTUsJDcsJDYJICNjbGFzcyBzb3VyY2UJICMgbGluZSAwLCA8
PnQxMjY0LCA8PnQxMjYyLCA8PnQ4MzIKCXN0cQkkNixEeUNSVF9TdGF0aWNW
YWx1ZVRhYmxlCSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMCwgPD50MTI2NCwg
PD50NTM2LCBhZGRyKF9EeUNSVF9TdGF0aWNWYWx1ZVRhYmxlJDEuMCkoUDY0
KSwgMChJMzIpLCAwKEkzMiksIDAoSTMyKSwgMChJMzIpCiAjaW5zdHIKLmxv
YyAyIDI2CglhZGRxCSQxMSwkOCwkOAkgI2NsYXNzIHNvdXJjZQkgIyBsaW5l
IDI2LCA8PnQxMjY4LCA8X0R5Q1JUX1RhYmxlUG9pbnRlckluZGV4JDEuMD50
MTI2NiwgPD50ODM1CglzdHEJJDMxLER5Q1JUX1NWVEluZGV4CSAjY2xhc3Mg
c291cmNlCSAjIGxpbmUgMCwgMHgwKFA2NCksIDw+dDUzNiwgYWRkcihfRHlD
UlRfU1ZUSW5kZXgkMS4wKShQNjQpLCAwKEkzMiksIDAoSTMyKSwgMChJMzIp
LCAwKEkzMikKICNpbnN0cgoubG9jIDIgMjYKCWFkZHEJJDE1LDY1NTM2LCQx
NQkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDI2LCA8X0R5Q1JUX1RhYmxlTG9j
YXRpb24kMS4wPnQxMjYzLCA8PnQxMjYyLCA2NTUzNihJMzIpCi5sb2MgMiAy
NgoJc3RxCSQxNSxEeUNSVF9UYWJsZUxvY2F0aW9uCSAjY2xhc3Mgc291cmNl
CSAjIGxpbmUgMjYsIDxfRHlDUlRfVGFibGVMb2NhdGlvbiQxLjA+dDEyNjMs
IDw+dDUzNiwgYWRkcihfRHlDUlRfVGFibGVMb2NhdGlvbiQxLjApKFA2NCks
IDAoSTMyKSwgMChJMzIpLCAwKEkzMiksIDAoSTMyKQogI2luc3RyCi5sb2Mg
MiAyNgoJc3RxCSQ2LDAoJDgpCSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMjYs
IDw+dDEyNjQsIDw+dDEyNjgsIDAoSTY0KSwgMChJMzIpLCAwKEkzMiksIDAo
STMyKSwgMChJMzIpCi5sb2MgMiAyNgoJYWRkbAkkMTEsOCwkMTEJICNjbGFz
cyBzb3VyY2UJICMgbGluZSAyNiwgPF9EeUNSVF9UYWJsZVBvaW50ZXJJbmRl
eCQxLjA+dDEyNjcsIDxfRHlDUlRfVGFibGVQb2ludGVySW5kZXgkMS4wPnQx
MjY2LCA4KEkzMikKICNpbnN0cgoubG9jIDIgMjYKCXN0bAkkMTEsRHlDUlRf
VGFibGVQb2ludGVySW5kZXgJICNjbGFzcyBzb3VyY2UJICMgbGluZSAyNiwg
PF9EeUNSVF9UYWJsZVBvaW50ZXJJbmRleCQxLjA+dDEyNjcsIDw+dDUzNiwg
YWRkcihfRHlDUlRfVGFibGVQb2ludGVySW5kZXgkMS4wKShQNjQpLCAwKEkz
MiksIDAoSTMyKSwgMChJMzIpLCAwKEkzMikKCWxkYQkkMjEsNCgkMzEpCSAj
Y2xhc3MgZG1vdmUsZG1fY29uc3RhbnQJICMgNChJNjQpCiAjaW5zdHIKLmxv
YyAyIDI2CglsZHEJJDE1LER5Q1JUX1dvcmtMaXN0CSAjY2xhc3Mgc291cmNl
CSAjIGxpbmUgMjYsIDxfRHlDX1RlbXAkMS40OD50MTI2NSwgPD50NTM2LCBh
ZGRyKF9EeUNSVF9Xb3JrTGlzdCQxLjApKFA2NCkKCWxkYQkkMjAsMjEoJDMx
KQkgI2NsYXNzIGRtb3ZlLGRtX2NvbnN0YW50CSAjIDIxKFNJNjQpCiAjaW5z
dHIKCWxkbAkkMjIsJDIuMSQyc3BpbGxfcCArIDk2KCRzcCkJICNjbGFzcyBk
bW92ZSxkbV9yZXN0b3JlCSAjIDxfcGMkMS4xPnQ0NTQKCWxkYQkkMTksMTYo
JDMxKQkgI2NsYXNzIGRtb3ZlLGRtX2NvbnN0YW50CSAjIDE2KFNJNjQpCiAj
aW5zdHIKCWxkcQkkMjMsJDIuMSQyc3BpbGxfcCArIDg4KCRzcCkJICNjbGFz
cyBkbW92ZSxkbV9yZXN0b3JlCSAjIDxfYnl0ZWNvZGVzJDEuMT50NDU1Cgls
ZGEJJDE4LDExKCQzMSkJICNjbGFzcyBkbW92ZSxkbV9jb25zdGFudAkgIyAx
MShTSTY0KQogI2luc3RyCglsZGEJJDE2LDI2KCQzMSkJICNjbGFzcyBkbW92
ZSxkbV9jb25zdGFudAkgIyAyNihTSTY0KQoubG9jIDIgMjYKCWJuZQkkMTUs
TDU5JDMJICNjbGFzcyBzb3VyY2UJICMgbGluZSAyNiwgPF9EeUNfVGVtcCQx
LjQ4PnQxMjY1Ckw1OCQzOgogI2luc3RyCglzdHEJJDMxLER5Q1JUX0JyYW5j
aEluZGV4CSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMCwgMHgwKFA2NCksIDw+
dDUzNiwgYWRkcihfRHlDUlRfQnJhbmNoSW5kZXgkMS4wKShQNjQpLCAwKEkz
MiksIDAoSTMyKSwgMChJMzIpLCAwKEkzMikKCWxkYQkkMTQsMSgkMzEpCSAj
Y2xhc3MgZG1vdmUsZG1fY29uc3RhbnQJICMgMShTSTY0KQogI2luc3RyCgls
ZGEJJDEzLDYoJDMxKQkgI2NsYXNzIGRtb3ZlLGRtX2NvbnN0YW50CSAjIDYo
U0k2NCkKICNpbnN0cgoJbGRhCSQxMiwzMSgkMzEpCSAjY2xhc3MgZG1vdmUs
ZG1fY29uc3RhbnQJICMgMzEoU0k2NCkKICNpbnN0cgoJYnIJJDMxLEw0MiQz
CiAjbWFya190cmFjZSAxNjY7Ckw1OSQzOgogI2luc3RyCglsZGEJJDI1LDMo
JDMxKQkgI2NsYXNzIGRtb3ZlLGRtX2NvbnN0YW50CSAjIDMoU0kzMikKCSAj
IHN0YWxsIAkxCiAjaW5zdHIKLmxvYyAyIDI2CglzdGwJJDI1LDMyKCQxNSkJ
ICNjbGFzcyBzb3VyY2UJICMgbGluZSAyNiwgMyhTSTMyKSwgPF9EeUNfVGVt
cCQxLjQ4PnQxMjY1LCAzMihJNjQpLCAwKEkzMiksIDAoSTMyKSwgMChJMzIp
LCAwKEkzMikKICNpbnN0cgoJbGRxCSQyMywkMi4xJDJzcGlsbF9wICsgODgo
JHNwKQkgI2NsYXNzIGRtb3ZlLGRtX3Jlc3RvcmUJICMgPF9ieXRlY29kZXMk
MS4xPnQ0NTUKICNpbnN0cgoJbGRhCSQxNiwyNigkMzEpCSAjY2xhc3MgZG1v
dmUsZG1fY29uc3RhbnQJICMgMjYoU0k2NCkKCWJyCSQzMSxMNTgkMwogI21h
cmtfdHJhY2UgMTE4OwpMNTUkMzoKICNpbnN0cgoJb3IJJDE5LCQzMSwkMjQJ
ICNjbGFzcyBzb3VyY2UJICMgbGluZSAwLCA8PnQ1NzcsIDw+dDEyNDcKICNp
bnN0cgoJb3IJJDMxLCQzMSwkMzEJICNjbGFzcyBkbW92ZSxkbV9yZWdpc3Rl
cgkgIyA8PnQ1MzMKICNpbnN0cgoJc3RxCSQyNCwkMi4xJDJzcGlsbF9wICsg
MTYoJHNwKQkgI2NsYXNzIGRtb3ZlLGRtX3NwaWxsCSAjIDw+dDU3NwogI2lu
c3RyCglicgkkMzEsTDU2JDMKICNtYXJrX3RyYWNlIDExNjsKTDU0JDM6CiAj
aW5zdHIKCWxkcQkkMjEsJDIuMSQyc3BpbGxfcCArIDEyOCgkc3ApCSAjY2xh
c3MgZG1vdmUsZG1fcmVzdG9yZQkgIyA8PnQxMjMyCglsZGEJJDE5LDIoJDMx
KQkgI2NsYXNzIGRtb3ZlLGRtX2NvbnN0YW50CSAjIDIoU0k2NCkKICNpbnN0
cgoJbGRhaAkkMjMsMzIoJDMxKQkgI2NsYXNzIGRtb3ZlLGRtX2NvbnN0YW50
CSAjIDIwOTcxNTIoSTMyKQogI2luc3RyCglsZGFoCSQxOCwtMzIoJDMxKQkg
I2NsYXNzIGRtb3ZlLGRtX2NvbnN0YW50CSAjIDQyOTI4NzAxNDQoSTMyKQog
I2luc3RyCi5sb2MgMiAyNgoJYWRkcQkkMjEsNCwkMTUJICNjbGFzcyBzb3Vy
Y2UJICMgbGluZSAyNiwgPD50MTI1MiwgPD50MTIzMiwgNChTSTMyKQoubG9j
IDIgMjYKCWxkbAkkMTQsMCgkMjEpCSAjY2xhc3Mgc291cmNlCSAjIGxpbmUg
MjYsIDw+dDEyNTYsIDw+dDEyMzIsIDAoSTY0KQogI2luc3RyCi5sb2MgMiAy
NgoJc3VicQkkMjcsJDE1LCQxMwkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDI2
LCA8PnQxMjUzLCA8PnQxMjQ3LCA8PnQxMjUyCiAjaW5zdHIKLmxvYyAyIDI2
CglhZGRsCSQxMywzLCQxNQkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDI2LCA8
PnQ2MzUsIDw+dDEyNTMsIDMoU0kzMikKICNpbnN0cgoubG9jIDIgMjYKCWNt
b3ZnZQkkMTMsJDEzLCQxNQkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDI2LCA8
PnQ2MzYsIDw+dDEyNTMsIDw+dDEyNTMsIDw+dDYzNQogI2luc3RyCi5sb2Mg
MiAyNgoJbGRhCSQxMywtMSgkMjMpCSAjY2xhc3Mgc291cmNlCSAjIGxpbmUg
MjYsIDw+dDgyNSwgMjA5NzE1MihJMzIpLCAtMShTSTY0KQogI2luc3RyCi5s
b2MgMiAyNgoJc3JhCSQxNSwkMTksJDE1CSAjY2xhc3Mgc291cmNlCSAjIGxp
bmUgMjYsIDw+dDEyNTQsIDw+dDYzNiwgMihTSTY0KQogI2luc3RyCi5sb2Mg
MiAyNgoJYW5kCSQxNCwkMTgsJDE0CSAjY2xhc3Mgc291cmNlCSAjIGxpbmUg
MjYsIDw+dDEyNTcsIDw+dDEyNTYsIDQyOTI4NzAxNDQoSTMyKQogI2luc3Ry
Ci5sb2MgMiAyNgoJYW5kCSQxNSwkMTMsJDEzCSAjY2xhc3Mgc291cmNlCSAj
IGxpbmUgMjYsIDw+dDEyNTUsIDw+dDEyNTQsIDw+dDgyNQoJY3B5cwkkZjMx
LCRmMzEsJGYzMQkjIHBhZAogI2luc3RyCi5sb2MgMiAyNgoJb3IJJDEzLCQx
NCwkMTQJICNjbGFzcyBzb3VyY2UJICMgbGluZSAyNiwgPD50MTI1OCwgPD50
MTI1NSwgPD50MTI1NwoubG9jIDIgMjYKCXN0bAkkMTQsMCgkMjEpCSAjY2xh
c3Mgc291cmNlCSAjIGxpbmUgMjYsIDw+dDEyNTgsIDw+dDEyMzIsIDAoSTY0
KSwgMChJMzIpLCAwKEkzMiksIDAoSTMyKSwgMChJMzIpCgkgIyBzdGFsbCAJ
MQogI2luc3RyCglibmUJJDI0LEw2MCQzCSAjY2xhc3Mgc291cmNlLHJlam9p
bl9jb3B5CSAjIGxpbmUgMCwgPD50NTc3CiAjbWFya190cmFjZSAxNzg7CiAj
aW5zdHIKCW9yCSQyNywkMzEsJDE5CSAjY2xhc3MgZG1vdmUsZG1fcmVnaXN0
ZXIJICMgPD50MTI0NwogI2luc3RyCglsZGEJJDE4LDEoJDMxKQkgI2NsYXNz
IGRtb3ZlLGRtX2NvbnN0YW50CSAjIDEoU0kzMikKICNpbnN0cgoJYnIJJDMx
LEw1NSQzCiAjbWFya190cmFjZSAxODY7Ckw2MCQzOgogI2luc3RyCglzdHEJ
JDI0LCQyLjEkMnNwaWxsX3AgKyAxNigkc3ApCSAjY2xhc3MgZG1vdmUsZG1f
c3BpbGwJICMgPD50NTc3CglsZGEJJDE4LDEoJDMxKQkgI2NsYXNzIGRtb3Zl
LGRtX2NvbnN0YW50CSAjIDEoU0kzMikKICNpbnN0cgoJb3IJJDMxLCQzMSwk
MzEJICNjbGFzcyBkbW92ZSxkbV9yZWdpc3RlcgkgIyA8PnQ1MzMKICNpbnN0
cgoJb3IJJDI3LCQzMSwkMTkJICNjbGFzcyBkbW92ZSxkbV9yZWdpc3Rlcgkg
IyA8PnQxMjQ3CiAjaW5zdHIKCWJyCSQzMSxMNTYkMwoJYmlzCSQzMSwkMzEs
JDMxCSMgcGFkCiAjbWFya190cmFjZSAxNDQ7Ckw1MiQzOgogI2luc3RyCglv
cgkkMzEsJDMxLCQyNQkgI2NsYXNzIHNvdXJjZSxyZWpvaW5fY29weQkgIyBs
aW5lIDAsIDw+dDU4NywgMChJMzIpCglsZHEJJDIzLCQyLjEkMnNwaWxsX3Ag
KyAxMjgoJHNwKQkgI2NsYXNzIGRtb3ZlLGRtX3Jlc3RvcmUJICMgPD50MTIz
MgogI2luc3RyCglsZHEJJDE2LCQyLjEkMnNwaWxsX3AgKyAxNDQoJHNwKQkg
I2NsYXNzIGRtb3ZlLGRtX3Jlc3RvcmUJICMgPD50MTIzNwoJb3IJJDMxLCQz
MSwkMzEJICNjbGFzcyBkbW92ZSxkbV9yZWdpc3RlcgkgIyA8PnQ1MzMKICNp
bnN0cgoJc3RsCSQyNSwkMi4xJDJzcGlsbF9wKCRzcCkJICNjbGFzcyBkbW92
ZSxkbV9zcGlsbAkgIyA8PnQ1ODcKCW9yCSQyMCwkMzEsJDI3CSAjY2xhc3Mg
ZG1vdmUsZG1fcmVnaXN0ZXIJICMgPD50MTI0NwogI2luc3RyCglhZGRxCSQy
MywweDQsJDIxCSAjY2xhc3Mgc291cmNlLHJlam9pbl9jb3B5CSAjIGxpbmUg
MCwgPD50NjA5LCA8PnQxMjMyLCAweDQoUDY0KQogI2luc3RyCglicgkkMzEs
TDUzJDMKICNtYXJrX3RyYWNlIDg0OwpMNTEkMzoKICNpbnN0cgoJbGRhCSQy
MywyKCQzMSkJICNjbGFzcyBkbW92ZSxkbV9jb25zdGFudAkgIyAyKFNJNjQp
CglsZHEJJDE3LCQyLjEkMnNwaWxsX3AgKyAxMzYoJHNwKQkgI2NsYXNzIGRt
b3ZlLGRtX3Jlc3RvcmUJICMgPD50MTIzNAogI2luc3RyCi5sb2MgMiAyNgoJ
YWRkcQkkMjEsNCwkMjIJICNjbGFzcyBzb3VyY2UJICMgbGluZSAyNiwgPD50
MTI0MCwgPD50MTIzMiwgNChTSTMyKQoubG9jIDIgMjYKCWxkbAkkMjAsMCgk
MjEpCSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMjYsIDw+dDEyNDQsIDw+dDEy
MzIsIDAoSTY0KQogI2luc3RyCi5sb2MgMiAyNgoJc3VicQkkMCwkMjIsJDE5
CSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMjYsIDw+dDEyNDEsIDw+dDEyMzgs
IDw+dDEyNDAKICNpbnN0cgoubG9jIDIgMjYKCWFkZGwJJDE5LDMsJDIyCSAj
Y2xhc3Mgc291cmNlCSAjIGxpbmUgMjYsIDw+dDYzMywgPD50MTI0MSwgMyhT
STMyKQogI2luc3RyCi5sb2MgMiAyNgoJY21vdmdlCSQxOSwkMTksJDIyCSAj
Y2xhc3Mgc291cmNlCSAjIGxpbmUgMjYsIDw+dDYzNCwgPD50MTI0MSwgPD50
MTI0MSwgPD50NjMzCiAjaW5zdHIKCWxkYWgJJDE5LDMyKCQzMSkJICNjbGFz
cyBkbW92ZSxkbV9jb25zdGFudAkgIyAyMDk3MTUyKEkzMikKICNpbnN0cgou
bG9jIDIgMjYKCXNyYQkkMjIsJDIzLCQyMgkgI2NsYXNzIHNvdXJjZQkgIyBs
aW5lIDI2LCA8PnQxMjQyLCA8PnQ2MzQsIDIoU0k2NCkKICNpbnN0cgoubG9j
IDIgMjYKCWxkYQkkMTksLTEoJDE5KQkgI2NsYXNzIHNvdXJjZQkgIyBsaW5l
IDI2LCA8PnQ4MTksIDIwOTcxNTIoSTMyKSwgLTEoU0k2NCkKICNpbnN0cgou
bG9jIDIgMjYKCWFuZAkkMjIsJDE5LCQyMgkgI2NsYXNzIHNvdXJjZQkgIyBs
aW5lIDI2LCA8PnQxMjQzLCA8PnQxMjQyLCA8PnQ4MTkKICNpbnN0cgoJbGRh
aAkkMjcsLTMyKCQzMSkJICNjbGFzcyBkbW92ZSxkbV9jb25zdGFudAkgIyA0
MjkyODcwMTQ0KEkzMikKICNpbnN0cgoJbGRhCSQyNSwzKCQzMSkJICNjbGFz
cyBkbW92ZSxkbV9jb25zdGFudAkgIyAzKFNJMzIpCiAjaW5zdHIKLmxvYyAy
IDI2CglhbmQJJDIwLCQyNywkMjAJICNjbGFzcyBzb3VyY2UJICMgbGluZSAy
NiwgPD50MTI0NSwgPD50MTI0NCwgNDI5Mjg3MDE0NChJMzIpCiAjaW5zdHIK
LmxvYyAyIDI2CglvcgkkMjIsJDIwLCQyMgkgI2NsYXNzIHNvdXJjZQkgIyBs
aW5lIDI2LCA8PnQxMjQ2LCA8PnQxMjQzLCA8PnQxMjQ1Ci5sb2MgMiAyNgoJ
c3RsCSQyMiwwKCQyMSkJICNjbGFzcyBzb3VyY2UJICMgbGluZSAyNiwgPD50
MTI0NiwgPD50MTIzMiwgMChJNjQpLCAwKEkzMiksIDAoSTMyKSwgMChJMzIp
LCAwKEkzMikKICNpbnN0cgoubG9jIDIgMjYKCWxkcQkkMjMsaW50ZXJwcmV0
ZXIuTFNWRnJlZUxpc3QuMgkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDI2LCA8
PnQxMjM5LCA8PnQ1MzYsIGFkZHIoaW50ZXJwcmV0ZXIuTFNWRnJlZUxpc3Qu
VkFSLjIpKFA2NCkKCSAjIHN0YWxsIAkyCiAjaW5zdHIKLmxvYyAyIDI2Cglz
dHEJJDIzLDAoJDE3KQkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDI2LCA8PnQx
MjM5LCA8PnQxMjM0LCAwKEk2NCksIDAoSTMyKSwgMChJMzIpLCAwKEkzMiks
IDAoSTMyKQogI2luc3RyCi5sb2MgMiAyNgoJc3RxCSQxNyxpbnRlcnByZXRl
ci5MU1ZGcmVlTGlzdC4yCSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMjYsIDw+
dDEyMzQsIDw+dDUzNiwgYWRkcihpbnRlcnByZXRlci5MU1ZGcmVlTGlzdC5W
QVIuMikoUDY0KSwgMChJMzIpLCAwKEkzMiksIDAoSTMyKSwgMChJMzIpCgkg
IyBzdGFsbCAJMQogI2luc3RyCgliZXEJJDI0LEw2MSQzCSAjY2xhc3Mgc291
cmNlCSAjIGxpbmUgMCwgPD50NTc3CiAjbWFya190cmFjZSAxOwpMNjIkMzoK
aW50ZXJwcmV0ZXIuRFlDLldPUktMSVNUUE9QOgogI2luc3RyCi5sb2MgMiAy
NgoJbGRxCSQyNyxEeUNSVF9Xb3JrTGlzdAkgI2NsYXNzIHNvdXJjZQkgIyBs
aW5lIDI2LCA8PnQ1NjMsIDw+dDUzNiwgYWRkcihfRHlDUlRfV29ya0xpc3Qk
MS4wKShQNjQpCglsZGEJJDE4LDEoJDMxKQkgI2NsYXNzIGRtb3ZlLGRtX2Nv
bnN0YW50CSAjIDEoU0kzMikKICNpbnN0cgoJb3IJJDMxLCQzMSwkMzEJICNj
bGFzcyBkbW92ZSxkbV9yZWdpc3RlcgkgIyA8PnQ1MzMKCSAjIHN0YWxsIAkx
CiAjaW5zdHIKLmxvYyAyIDI2CgliZXEJJDI3LEw2MyQzCSAjY2xhc3Mgc291
cmNlCSAjIGxpbmUgMjYsIDw+dDU2MwogI2luc3RyCi5sb2MgMiAyNgoJbGRx
CSQyNCw0MCgkMjcpCSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMjYsIDxfRHlD
X1RlbXAkMS40Mj50NDgwLCA8PnQ1NjMsIDQwKEk2NCkKICNpbnN0cgoubG9j
IDIgMjYKCWxkbAkkMjMsMzIoJDI3KQkgI2NsYXNzIHNvdXJjZQkgIyBsaW5l
IDI2LCA8PnQ1ODgsIDw+dDU2MywgMzIoSTY0KQogI2luc3RyCi5sb2MgMiAy
NgoJbGRsCSQyMiwyOCgkMjcpCSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMjYs
IDw+dDU4NSwgPD50NTYzLCAyOChJNjQpCgljcHlzCSRmMzEsJGYzMSwkZjMx
CSMgcGFkCiAjaW5zdHIKLmxvYyAyIDI2CglsZGwJJDIxLDI0KCQyNykJICNj
bGFzcyBzb3VyY2UJICMgbGluZSAyNiwgPD50NTg0LCA8PnQ1NjMsIDI0KEk2
NCkKLmxvYyAyIDI2CgljbXBlcQkkMjQsJDMxLCQyMAkgI2NsYXNzIHNvdXJj
ZQkgIyBsaW5lIDI2LCA8PnQ4OTIsIDxfRHlDX1RlbXAkMS40Mj50NDgwLCAw
eDAoUDY0KQogI2luc3RyCi5sb2MgMiAyNgoJbGRxCSQxOSwxNigkMjcpCSAj
Y2xhc3Mgc291cmNlCSAjIGxpbmUgMjYsIDw+dDEzNjksIDw+dDU2MywgMTYo
STY0KQoubG9jIDIgMjYKCWNtcGVxCSQyMywzLCQyMwkgI2NsYXNzIHNvdXJj
ZQkgIyBsaW5lIDI2LCA8PnQyMTcsIDw+dDU4OCwgMyhTSTMyKQogI2luc3Ry
CglzdGwJJDIyLCQyLjEkMnNwaWxsX3AgKyAyNCgkc3ApCSAjY2xhc3MgZG1v
dmUsZG1fc3BpbGwJICMgPD50NTg1Ci5sb2MgMiAyNgoJY21wZXEJJDMxLCQy
MCwkMjAJICNjbGFzcyBzb3VyY2UJICMgbGluZSAyNiwgPD50ODkzLCAwKEk2
NCksIDw+dDg5MgogI2luc3RyCglzdGwJJDIxLCQyLjEkMnNwaWxsX3AgKyAz
Migkc3ApCSAjY2xhc3MgZG1vdmUsZG1fc3BpbGwJICMgPD50NTg0CgljcHlz
CSRmMzEsJGYzMSwkZjMxCSMgcGFkCiAjaW5zdHIKCXN0cQkkMTksJDIuMSQy
c3BpbGxfcCArIDQwKCRzcCkJICNjbGFzcyBkbW92ZSxkbV9zcGlsbAkgIyA8
PnQxMzY5Ci5sb2MgMiAyNgoJY21wdWx0CSQzMSwkMjAsJDIwCSAjY2xhc3Mg
c291cmNlCSAjIGxpbmUgMjYsIDw+dDIxNSwgMChJNjQpLCA8PnQ4OTMKICNp
bnN0cgoubG9jIDIgMjYKCWxkcQkkMTcsOCgkMjcpCSAjY2xhc3Mgc291cmNl
CSAjIGxpbmUgMjYsIDw+dDEzNjgsIDw+dDU2MywgOChJNjQpCgljcHlzCSRm
MzEsJGYzMSwkZjMxCSMgcGFkCiAjaW5zdHIKLmxvYyAyIDI2CglsZHEJJDIy
LDAoJDI3KQkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDI2LCA8PnQ1NzUsIDw+
dDU2MywgMChJNjQpCi5sb2MgMiAyNgoJYW5kCSQyMCwkMjMsJDIzCSAjY2xh
c3Mgc291cmNlCSAjIGxpbmUgMjYsIDw+dDg5NCwgPD50MjE1LCA8PnQyMTcK
ICNpbnN0cgoubG9jIDIgMjYKCXN0cQkkMjQsRHlDUlRfV29ya0xpc3QJICNj
bGFzcyBzb3VyY2UJICMgbGluZSAyNiwgPF9EeUNfVGVtcCQxLjQyPnQ0ODAs
IDw+dDUzNiwgYWRkcihfRHlDUlRfV29ya0xpc3QkMS4wKShQNjQpLCAwKEkz
MiksIDAoSTMyKSwgMChJMzIpLCAwKEkzMikKICNpbnN0cgoJc3RxCSQxNywk
Mi4xJDJzcGlsbF9wICsgNDgoJHNwKQkgI2NsYXNzIGRtb3ZlLGRtX3NwaWxs
CSAjIDw+dDEzNjgKICNpbnN0cgoubG9jIDIgMjYKCWJlcQkkMjMsTDY0JDMJ
ICNjbGFzcyBzb3VyY2UJICMgbGluZSAyNiwgPD50ODk0CiAjaW5zdHIKLmxv
YyAyIDI2CglzdGwJJDI1LDMyKCQyNCkJICNjbGFzcyBzb3VyY2UJICMgbGlu
ZSAyNiwgMyhTSTMyKSwgPF9EeUNfVGVtcCQxLjQyPnQ0ODAsIDMyKEk2NCks
IDAoSTMyKSwgMChJMzIpLCAwKEkzMiksIDAoSTMyKQpMNjUkMzoKICNpbnN0
cgoJc3RxCSQxNyxEeUNSVF9Cb2d1c0xTVkdsb2JhbAkgI2NsYXNzIHNvdXJj
ZQkgIyBsaW5lIDAsIDw+dDEzNjgsIDw+dDUzNiwgYWRkcihfRHlDUlRfQm9n
dXNMU1ZHbG9iYWwkMS43KShQNjQpLCAwKEkzMiksIDAoSTMyKSwgMChJMzIp
LCAwKEkzMikKICNpbnN0cgoubG9jIDIgMjYKCWxkcQkkMjUsRHlDUlRfV29y
a0xpc3RGcmVlTGlzdAkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDI2LCA8PnQx
MzcwLCA8PnQ1MzYsIGFkZHIoX0R5Q1JUX1dvcmtMaXN0RnJlZUxpc3QkMS4w
KShQNjQpCgkgIyBzdGFsbCAJMgogI2luc3RyCi5sb2MgMiAyNgoJc3RxCSQy
NSwwKCQyNykJICNjbGFzcyBzb3VyY2UJICMgbGluZSAyNiwgPD50MTM3MCwg
PD50NTYzLCAwKEk2NCksIDAoSTMyKSwgMChJMzIpLCAwKEkzMiksIDAoSTMy
KQogI2luc3RyCi5sb2MgMiAyNgoJc3RxCSQyNyxEeUNSVF9Xb3JrTGlzdEZy
ZWVMaXN0CSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMjYsIDw+dDU2MywgPD50
NTM2LCBhZGRyKF9EeUNSVF9Xb3JrTGlzdEZyZWVMaXN0JDEuMCkoUDY0KSwg
MChJMzIpLCAwKEkzMiksIDAoSTMyKSwgMChJMzIpCgkgIyBzdGFsbCAJMQog
I2luc3RyCglqbXAJJDMxLCgkMjIpCSAjY2xhc3Mgc291cmNlCSAjIGxpbmUg
MCwgPD50NTc1CmludGVycHJldGVyLkRZQy5HRV9FTlRSWS5FQUdFUi4zOgog
I2luc3RyCglsZHEJJDE2LGludGVycHJldGVyLkNhY2hlLjMJICNjbGFzcyBz
b3VyY2UJICMgbGluZSAwLCA8PnQxMDgzLCA8PnQ1MzYsIGFkZHIoaW50ZXJw
cmV0ZXIuQ2FjaGUuVkFSLjMpKFA2NCkKCSAjIHN0YWxsIAkyCiAjaW5zdHIK
CXN0cQkkMTYsJDIuMSQyc3BpbGxfcCArIDU2KCRzcCkJICNjbGFzcyBkbW92
ZSxkbV9zcGlsbAkgIyA8PnQxMDgzCiAjaW5zdHIKCWJlcQkkMTYsTDY2JDMJ
ICNjbGFzcyBzb3VyY2UJICMgbGluZSAwLCA8PnQxMDgzCkw2NyQzOgogI21h
cmtfY2FsbCBjYWxsZXJfc2F2ZXMsIHJlZ3MsIGF0eXBlcyhuNjQsbjY0LG4z
MiksIHJ0eXBlcyhuNjQpOwogI2luc3RyCgliaXMJJDMxLCQzMSwkMzEJIyBw
YWQKLmxvYyAyIDI2Cglqc3IJJDI2LERZQ19DQUNIRV9sb29rdXAKCWJyCSQy
NixGQUtFMApGQUtFMDoJbGRncAkkZ3AsMCgkMjYpCSAjY2xhc3Mgc291cmNl
CSAjIGxpbmUgMjYsIHJhZGRyKERZQ19DQUNIRV9sb29rdXApKFA2NCksIDw+
dDUzMywgPD50MTA4MywgPD50MTM2OCwgMShTSTMyKQogI2luc3RyCglsZHEJ
JDE3LCQyLjEkMnNwaWxsX3AgKyA0OCgkc3ApCSAjY2xhc3MgZG1vdmUsZG1f
cmVzdG9yZQkgIyA8PnQxMzY4Ci5sb2MgMiAyNgoJc3VicQkkMzEsMzIsJDI3
CSAjY2xhc3Mgc291cmNlLGNzcGVjCSAjIGxpbmUgMjYsIDxfQWxpZ25lZEFk
ZHJlc3MkMS41OD50ODc2LCAwKEk2NCksIDMyKFNJNjQpCiAjaW5zdHIKCWxk
bAkkMjUsJDIuMSQyc3BpbGxfcCgkc3ApCSAjY2xhc3MgZG1vdmUsZG1fcmVz
dG9yZQkgIyA8PnQ1ODcKCWNweXMJJGYzMSwkZjMxLCRmMzEJIyBwYWQKICNp
bnN0cgoJbGRsCSQyMSwkMi4xJDJzcGlsbF9wICsgMzIoJHNwKQkgI2NsYXNz
IGRtb3ZlLGRtX3Jlc3RvcmUJICMgPD50NTg0CglibmUJJDAsTDY4JDMJICNj
bGFzcyBzb3VyY2UJICMgbGluZSAwLCA8PnQxMzM1CiAjaW5zdHIKCWxkbAkk
MjQsMCgkMTcpCSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMCwgPF9wYyQxLjE+
dDEzNDQsIDw+dDEzNjgsIDAoU0kzMikKICNpbnN0cgoJbGRxCSQyMyw4KCQx
NykJICNjbGFzcyBzb3VyY2UJICMgbGluZSAwLCA8X2J5dGVjb2RlcyQxLjE+
dDQ1NSwgPD50MTM2OCwgOChTSTMyKQogI2luc3RyCglsZGwJJDIyLDE2KCQx
NykJICNjbGFzcyBzb3VyY2UJICMgbGluZSAwLCA8X29mZnNldCQxLjI+dDEz
NDUsIDw+dDEzNjgsIDE2KFNJMzIpCiAjaW5zdHIKLmxvYyAyIDI2CglsZHEJ
JDIwLER5Q1JUX0NvZGVMb2NhdGlvbgkgI2NsYXNzIHNvdXJjZQkgIyBsaW5l
IDI2LCA8PnQxMzQ2LCA8PnQ1MzYsIGFkZHIoX0R5Q1JUX0NvZGVMb2NhdGlv
biQxLjApKFA2NCkKICNpbnN0cgoJbGRsCSQxOSwkMi4xJDJzcGlsbF9wICsg
MjQoJHNwKQkgI2NsYXNzIGRtb3ZlLGRtX3Jlc3RvcmUJICMgPD50NTg1Cglj
cHlzCSRmMzEsJGYzMSwkZjMxCSMgcGFkCiAjaW5zdHIKCW9yCSQzMSwkMzEs
JDE4CSAjY2xhc3Mgc291cmNlLGNzcGVjCSAjIGxpbmUgMCwgPD50NTg3LCAw
KEkzMikKLmxvYyAyIDI2CgliZXEJJDI1LEw2OSQzCSAjY2xhc3Mgc291cmNl
CSAjIGxpbmUgMjYsIDw+dDU4NwogI2luc3RyCi5sb2MgMiAyNgoJbGRxCSQx
NyxEeUNSVF9QYWRkZWRCeXRlcwkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDI2
LCA8X0R5Q1JUX1BhZGRlZEJ5dGVzJDEuMD50MTM0OSwgPD50NTM2LCBhZGRy
KF9EeUNSVF9QYWRkZWRCeXRlcyQxLjApKFA2NCkKLmxvYyAyIDI2CglhZGRx
CSQyMCw2MywkMTYJICNjbGFzcyBzb3VyY2UJICMgbGluZSAyNiwgPD50MTM0
NywgPD50MTM0NiwgNjMoU0k2NCkKICNpbnN0cgoubG9jIDIgMjYKCWFuZAkk
MTYsJDI3LCQyNwkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDI2LCA8X0FsaWdu
ZWRBZGRyZXNzJDEuNTg+dDEzNDgsIDw+dDEzNDcsIDxfQWxpZ25lZEFkZHJl
c3MkMS41OD50ODc2CglsZHEJJDI1LCQyLjEkMnNwaWxsX3AgKyA0MCgkc3Ap
CSAjY2xhc3MgZG1vdmUsZG1fcmVzdG9yZQkgIyA8PnQxMzY5CiAjaW5zdHIK
LmxvYyAyIDI2CglzdWJxCSQyNywkMjAsJDIwCSAjY2xhc3Mgc291cmNlCSAj
IGxpbmUgMjYsIDxfRHlDUlRfUGFkZGVkQnl0ZXMkMS4wPnQ4NzcsIDxfQWxp
Z25lZEFkZHJlc3MkMS41OD50MTM0OCwgPD50MTM0NgoJY3B5cwkkZjMxLCRm
MzEsJGYzMQkjIHBhZAogI2luc3RyCi5sb2MgMiAyNgoJYWRkcQkkMjAsJDE3
LCQxNwkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDI2LCA8X0R5Q1JUX1BhZGRl
ZEJ5dGVzJDEuMD50MTM1MCwgPF9EeUNSVF9QYWRkZWRCeXRlcyQxLjA+dDg3
NywgPF9EeUNSVF9QYWRkZWRCeXRlcyQxLjA+dDEzNDkKLmxvYyAyIDI2Cglz
dHEJJDE3LER5Q1JUX1BhZGRlZEJ5dGVzCSAjY2xhc3Mgc291cmNlCSAjIGxp
bmUgMjYsIDxfRHlDUlRfUGFkZGVkQnl0ZXMkMS4wPnQxMzUwLCA8PnQ1MzYs
IGFkZHIoX0R5Q1JUX1BhZGRlZEJ5dGVzJDEuMCkoUDY0KSwgMChJMzIpLCAw
KEkzMiksIDAoSTMyKSwgMChJMzIpCiAjaW5zdHIKLmxvYyAyIDI2Cglvcgkk
MjcsJDMxLCQyNwkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDI2LCA8PnQxMzQ2
LCA8X0FsaWduZWRBZGRyZXNzJDEuNTg+dDEzNDgKICNpbnN0cgoJYWRkcQkk
MjUsMHg0LCQyNQkgI2NsYXNzIHNvdXJjZSxjc3BlYwkgIyBsaW5lIDAsIDw+
dDYxMiwgPD50MTM2OSwgMHg0KFA2NCkKTDcwJDM6CiAjaW5zdHIKCWNtcGVx
CSQyNywkMjUsJDIwCSAjY2xhc3Mgc291cmNlLGNzcGVjCSAjIGxpbmUgMCwg
PD50ODgxLCA8PnQxMzQ2LCA8PnQ2MTIKLmxvYyAyIDI2CgliZXEJJDIxLEw3
MSQzCSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMjYsIDw+dDU4NAoJICMgc3Rh
bGwgCTEKICNpbnN0cgoubG9jIDIgMjYKCWJlcQkkMTksTDcyJDMJICNjbGFz
cyBzb3VyY2UJICMgbGluZSAyNiwgPD50NTg1CgkgIyBzdGFsbCAJMQogI2lu
c3RyCgliZXEJJDIwLEw3MyQzCSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMCwg
PD50ODgxCiAjaW5zdHIKCWxkcQkkMjAsJDIuMSQyc3BpbGxfcCArIDQwKCRz
cCkJICNjbGFzcyBzb3VyY2UJICMgbGluZSAwLCA8PnQxMzQ2LCA8PnQxMzY5
CgkgIyBzdGFsbCAJMQogI21hcmtfdHJhY2UgMjY7CiAjaW5zdHIKICNpbnN0
cgoJb3IJJDIwLCQzMSwkMjcJICNjbGFzcyBkbW92ZSxkbV9yZWdpc3Rlcgkg
IyA8PnQxMzQ2CgkgIyBzdGFsbCAJMQogI21hcmtfdHJhY2UgNTsKTDcxJDM6
CiAjaW5zdHIKCXN0cQkkMjcsJDIuMSQyc3BpbGxfcCArIDY0KCRzcCkJICNj
bGFzcyBkbW92ZSxkbV9zcGlsbAkgIyA8PnQxMzQ2CglvcgkkMjcsJDMxLCQx
OQkgI2NsYXNzIGRtb3ZlLGRtX3JlZ2lzdGVyCSAjIDw+dDEzNDYKICNpbnN0
cgoJc3RsCSQyMiwkMi4xJDJzcGlsbF9wICsgNzIoJHNwKQkgI2NsYXNzIGRt
b3ZlLGRtX3NwaWxsCSAjIDxfb2Zmc2V0JDEuMj50MTM0NQoJb3IJJDMxLCQz
MSwkMzEJICNjbGFzcyBkbW92ZSxkbV9yZWdpc3RlcgkgIyA8PnQ1MzMKICNp
bnN0cgoJc3RsCSQyNCwkMi4xJDJzcGlsbF9wICsgODAoJHNwKQkgI2NsYXNz
IGRtb3ZlLGRtX3NwaWxsCSAjIDxfcGMkMS4xPnQxMzQ0CiAjaW5zdHIKCXN0
bAkkMTgsJDIuMSQyc3BpbGxfcCgkc3ApCSAjY2xhc3MgZG1vdmUsZG1fc3Bp
bGwJICMgPD50NTg3CiAjaW5zdHIKCXN0cQkkMjMsJDIuMSQyc3BpbGxfcCAr
IDg4KCRzcCkJICNjbGFzcyBkbW92ZSxkbV9zcGlsbAkgIyA8X2J5dGVjb2Rl
cyQxLjE+dDQ1NQoJbGRhCSQxOCwxKCQzMSkJICNjbGFzcyBkbW92ZSxkbV9j
b25zdGFudAkgIyAxKFNJMzIpCiAjaW5zdHIKCWxkcQkkMjQsJDIuMSQyc3Bp
bGxfcCArIDE2KCRzcCkJICNjbGFzcyBkbW92ZSxkbV9yZXN0b3JlCSAjIDw+
dDU3NwogI2luc3RyCglsZHEJJDE3LCQyLjEkMnNwaWxsX3AgKyA0OCgkc3Ap
CSAjY2xhc3MgZG1vdmUsZG1fcmVzdG9yZQkgIyA8PnQxMzY4CiAjaW5zdHIK
CWxkcQkkMTYsJDIuMSQyc3BpbGxfcCArIDU2KCRzcCkJICNjbGFzcyBkbW92
ZSxkbV9yZXN0b3JlCSAjIDw+dDEwODMKICNpbnN0cgoJYmVxCSQyNCxMNzQk
MwkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDAsIDw+dDU3NwpMNzUkMzoKICNt
YXJrX2NhbGwgY2FsbGVyX3NhdmVzLCByZWdzLCBhdHlwZXMobjY0LG42NCxu
MzIsbjY0KSwgcnR5cGVzKCk7CiAjaW5zdHIKCWJpcwkkMzEsJDMxLCQzMQkj
IHBhZAoubG9jIDIgMjYKCWpzcgkkMjYsRFlDX0NBQ0hFX2luc2VydAoJYnIJ
JDI2LEZBS0UyCkZBS0UyOglsZGdwCSRncCwwKCQyNikJICNjbGFzcyBzb3Vy
Y2UJICMgbGluZSAyNiwgcmFkZHIoRFlDX0NBQ0hFX2luc2VydCkoUDY0KSwg
PD50NTMzLCA8PnQxMDgzLCA8PnQxMzY4LCAxKFNJMzIpLCA8PnQxMzQ2CiAj
aW5zdHIKCWxkcQkkMjAsJDIuMSQyc3BpbGxfcCArIDY0KCRzcCkJICNjbGFz
cyBkbW92ZSxkbV9yZXN0b3JlCSAjIDw+dDEzNDYKCWxkYWgJJDI3LDEoJDMx
KQkgI2NsYXNzIGRtb3ZlLGRtX2NvbnN0YW50CSAjIDY1NTM2KEkzMikKICNp
bnN0cgoJbGRxCSQyMSxEeUNSVF9TdGF0aWNWYWx1ZVRhYmxlCSAjY2xhc3Mg
c291cmNlCSAjIGxpbmUgMCwgPD50MTM1OCwgPD50NTM2LCBhZGRyKF9EeUNS
VF9TdGF0aWNWYWx1ZVRhYmxlJDEuMCkoUDY0KQoJbGRhCSQxOSwxKCQzMSkJ
ICNjbGFzcyBkbW92ZSxkbV9jb25zdGFudAkgIyAxKEkzMikKCSAjIHN0YWxs
IAkxCiAjaW5zdHIKCXN0cQkkMjAsRHlDUlRfU3RpdGNoTG9jYXRpb24JICNj
bGFzcyBzb3VyY2UJICMgbGluZSAwLCA8PnQxMzQ2LCA8PnQ1MzYsIGFkZHIo
X0R5Q1JUX1N0aXRjaExvY2F0aW9uJDEuMCkoUDY0KSwgMChJMzIpLCAwKEkz
MiksIDAoSTMyKSwgMChJMzIpCgkgIyBzdGFsbCAJMQogI2luc3RyCgliZXEJ
JDIxLEw3NiQzCSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMCwgPD50MTM1OAog
I2luc3RyCglsZGwJJDIxLER5Q1JUX1NWVEluZGV4CSAjY2xhc3Mgc291cmNl
CSAjIGxpbmUgMCwgPD50MTM1OSwgPD50NTM2LCBhZGRyKF9EeUNSVF9TVlRJ
bmRleCQxLjApKFA2NCkKCSAjIHN0YWxsIAkyCiAjaW5zdHIKCWFkZGwJJDIx
LDE2LCQyMQkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDAsIDw+dDEzNjAsIDw+
dDEzNTksIDE2KFNJMzIpCiAjaW5zdHIKCWNtcGxlCSQyMSwkMjcsJDI3CSAj
Y2xhc3Mgc291cmNlCSAjIGxpbmUgMCwgPD50ODg0LCA8PnQxMzYwLCA2NTUz
NihJMzIpCgkgIyBzdGFsbCAJMQogI2luc3RyCgliZXEJJDI3LEw3NiQzCSAj
Y2xhc3Mgc291cmNlCSAjIGxpbmUgMCwgPD50ODg0CiAjaW5zdHIKCXN0bAkk
MTksRHlDUlRfQnVpbGRUYWJsZVBvaW50ZXIJICNjbGFzcyBzb3VyY2UJICMg
bGluZSAwLCAxKEkzMiksIDw+dDUzNiwgYWRkcihfRHlDUlRfQnVpbGRUYWJs
ZVBvaW50ZXIkMS4wKShQNjQpLCAwKEkzMiksIDAoSTMyKSwgMChJMzIpLCAw
KEkzMikKICNpbnN0cgoJYnIJJDMxLEw3NyQzCiAjbWFya190cmFjZSA3OwpM
NzgkMzoKaW50ZXJwcmV0ZXIuRFlDLlVOSVRfSEVBRC5TRVRVUC4zOgppbnRl
cnByZXRlci5keW5fc2V0dXBfYmVnaW5fNTVfMDoKICNpbnN0cgoJbGRsCSQy
NCwkMi4xJDJzcGlsbF9wICsgODAoJHNwKQkgI2NsYXNzIGRtb3ZlLGRtX3Jl
c3RvcmUJICMgPF9wYyQxLjE+dDEzNDQKCW9yCSQzMSwkMzEsJDMxCSAjY2xh
c3MgZG1vdmUsZG1fcmVnaXN0ZXIJICMgPD50NTMzCiAjaW5zdHIKCWxkbAkk
MjIsJDIuMSQyc3BpbGxfcCArIDcyKCRzcCkJICNjbGFzcyBkbW92ZSxkbV9y
ZXN0b3JlCSAjIDxfb2Zmc2V0JDEuMj50MTM0NQoJY3B5cwkkZjMxLCRmMzEs
JGYzMQkjIHBhZAoJICMgc3RhbGwgCTIKICNpbnN0cgoubG9jIDIgMTAyCglh
ZGRsCSQyMiwkMjQsJDIyCSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMTAyLCA8
X3BjJDEuMT50NDU0LCA8X29mZnNldCQxLjI+dDEzNDUsIDxfcGMkMS4xPnQx
MzQ0CglzdGwJJDIyLCQyLjEkMnNwaWxsX3AgKyA5Nigkc3ApCSAjY2xhc3Mg
ZG1vdmUsZG1fc3BpbGwJICMgPF9wYyQxLjE+dDQ1NAogI21hcmtfY2FsbCBj
YWxsZXJfc2F2ZXMsIHJlZ3MsIGF0eXBlcygpLCBydHlwZXMoKTsKICNpbnN0
cgoJYmlzCSQzMSwkMzEsJDMxCSMgcGFkCi5sb2MgMiAyNgoJanNyCSQyNixE
eUNSVF9QYXRjaEludHJhVW5pdEJyYW5jaGVzCglicgkkMjYsRkFLRTMKRkFL
RTM6CWxkZ3AJJGdwLDAoJDI2KQkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDI2
LCByYWRkcihEeUNSVF9QYXRjaEludHJhVW5pdEJyYW5jaGVzKShQNjQpLCA8
PnQ1MzMKICNpbnN0cgoJc3RxCSQzMSxEeUNSVF9Db2RlTG9jYXRpb24JICNj
bGFzcyBzb3VyY2UJICMgbGluZSAwLCAweDAoUDY0KSwgPD50NTM2LCBhZGRy
KF9EeUNSVF9Db2RlTG9jYXRpb24kMS4wKShQNjQpLCAwKEkzMiksIDAoSTMy
KSwgMChJMzIpLCAwKEkzMikKCWxkYQkkMTgsMSgkMzEpCSAjY2xhc3MgZG1v
dmUsZG1fY29uc3RhbnQJICMgMShTSTMyKQogI2luc3RyCglsZHEJJDI3LER5
Q1JUX0xhc3RCcmFuY2gJICNjbGFzcyBzb3VyY2UJICMgbGluZSAwLCA8PnQx
MjY5LCA8PnQ1MzYsIGFkZHIoX0R5Q1JUX0xhc3RCcmFuY2gkMS4wKShQNjQp
CglvcgkkMzEsJDMxLCQzMQkgI2NsYXNzIGRtb3ZlLGRtX3JlZ2lzdGVyCSAj
IDw+dDUzMwogI2luc3RyCi5sb2MgMiAyNgoJbGRxCSQyMixpbnRlcnByZXRl
ci5MU1ZGcmVlTGlzdC4yCSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMjYsIDw+
dDEyNzAsIDw+dDUzNiwgYWRkcihpbnRlcnByZXRlci5MU1ZGcmVlTGlzdC5W
QVIuMikoUDY0KQogI2luc3RyCglsZGwJJDIxLCQyLjEkMnNwaWxsX3AgKyA5
Nigkc3ApCSAjY2xhc3MgZG1vdmUsZG1fcmVzdG9yZQkgIyA8X3BjJDEuMT50
NDU0CiAjaW5zdHIKCXN0cQkkMjcsJDIuMSQyc3BpbGxfcCArIDEwNCgkc3Ap
CSAjY2xhc3MgZG1vdmUsZG1fc3BpbGwJICMgPD50MTI2OQoJY3B5cwkkZjMx
LCRmMzEsJGYzMQkjIHBhZAppbnRlcnByZXRlci5keW5fc2V0dXBfZW5kXzU1
XzA6CiAjaW5zdHIKCWxkcQkkMjMsJDIuMSQyc3BpbGxfcCArIDg4KCRzcCkJ
ICNjbGFzcyBkbW92ZSxkbV9yZXN0b3JlCSAjIDxfYnl0ZWNvZGVzJDEuMT50
NDU1Ci5sb2MgMiAyNgoJYm5lCSQyMixMNzkkMwkgI2NsYXNzIHNvdXJjZQkg
IyBsaW5lIDI2LCA8PnQxMjcwCiAjaW5zdHIKLmxvYyAyIDI2CglsZHEJJDE3
LER5Q1JUX1RlbXBMb2NhdGlvbgkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDI2
LCA8PnQxMjcxLCA8PnQ1MzYsIGFkZHIoX0R5Q1JUX1RlbXBMb2NhdGlvbiQx
LjApKFA2NCkKICNpbnN0cgoJbGRxCSQxNixpbnRlcnByZXRlci5DYWNoZS4y
CSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMCwgPD50MTI3NCwgPD50NTM2LCBh
ZGRyKGludGVycHJldGVyLkNhY2hlLlZBUi4yKShQNjQpCgkgIyBzdGFsbCAJ
MQogI2luc3RyCglzdHEJJDE3LCQyLjEkMnNwaWxsX3AgKyAxMTIoJHNwKQkg
I2NsYXNzIGRtb3ZlLGRtX3NwaWxsCSAjIDw+dDEyNzEKLmxvYyAyIDI2Cglh
ZGRxCSQxNywxNiwkMjcJICNjbGFzcyBzb3VyY2UJICMgbGluZSAyNiwgPF9E
eUNSVF9UZW1wTG9jYXRpb24kMS4wPnQxMjczLCA8PnQxMjcxLCAxNihJMzIp
CiAjaW5zdHIKCXN0cQkkMTYsJDIuMSQyc3BpbGxfcCArIDEyMCgkc3ApCSAj
Y2xhc3MgZG1vdmUsZG1fc3BpbGwJICMgPD50MTI3NAogI2luc3RyCi5sb2Mg
MiAyNgoJc3RxCSQyNyxEeUNSVF9UZW1wTG9jYXRpb24JICNjbGFzcyBzb3Vy
Y2UJICMgbGluZSAyNiwgPF9EeUNSVF9UZW1wTG9jYXRpb24kMS4wPnQxMjcz
LCA8PnQ1MzYsIGFkZHIoX0R5Q1JUX1RlbXBMb2NhdGlvbiQxLjApKFA2NCks
IDAoSTMyKSwgMChJMzIpLCAwKEkzMiksIDAoSTMyKQpMODAkMzoKICNpbnN0
cgoJc3RsCSQyMSwwKCQxNykJICNjbGFzcyBzb3VyY2UJICMgbGluZSAwLCA8
X3BjJDEuMT50NDU0LCA8PnQxMjcxLCAwKFNJMzIpLCAwKEkzMiksIDAoSTMy
KSwgMChJMzIpLCAwKEkzMikKICNpbnN0cgoJc3RsCSQzMSw0KCQxNykJICNj
bGFzcyBzb3VyY2UJICMgbGluZSAwLCAwKFNJMzIpLCA8PnQxMjcxLCA0KFNJ
MzIpLCAwKEkzMiksIDAoSTMyKSwgMChJMzIpLCAwKEkzMikKICNpbnN0cgoJ
c3RxCSQyMyw4KCQxNykJICNjbGFzcyBzb3VyY2UJICMgbGluZSAwLCA8X2J5
dGVjb2RlcyQxLjE+dDQ1NSwgPD50MTI3MSwgOChTSTMyKSwgMChJMzIpLCAw
KEkzMiksIDAoSTMyKSwgMChJMzIpCgkgIyBzdGFsbCAJMQogI2luc3RyCgli
ZXEJJDE2LEw4MSQzCSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMCwgPD50MTI3
NApMODIkMzoKICNtYXJrX2NhbGwgY2FsbGVyX3NhdmVzLCByZWdzLCBhdHlw
ZXMobjY0LG42NCxuMzIpLCBydHlwZXMobjY0KTsKICNpbnN0cgoJYmlzCSQz
MSwkMzEsJDMxCSMgcGFkCi5sb2MgMiAyNgoJanNyCSQyNixEWUNfQ0FDSEVf
bG9va3VwCglicgkkMjYsRkFLRTQKRkFLRTQ6CWxkZ3AJJGdwLDAoJDI2KQkg
I2NsYXNzIHNvdXJjZQkgIyBsaW5lIDI2LCByYWRkcihEWUNfQ0FDSEVfbG9v
a3VwKShQNjQpLCA8PnQ1MzMsIDw+dDEyNzQsIDw+dDEyNzEsIDEoU0kzMikK
ICNpbnN0cgoJbGRxCSQyNywkMi4xJDJzcGlsbF9wICsgMTA0KCRzcCkJICNj
bGFzcyBkbW92ZSxkbV9yZXN0b3JlCSAjIDw+dDEyNjkKCWxkYWgJJDIyLC0z
MigkMzEpCSAjY2xhc3MgZG1vdmUsZG1fY29uc3RhbnQJICMgNDI5Mjg3MDE0
NChJMzIpCiAjaW5zdHIKCWxkYQkkMjEsMigkMzEpCSAjY2xhc3MgZG1vdmUs
ZG1fY29uc3RhbnQJICMgMihTSTY0KQoJbGRxCSQxNywkMi4xJDJzcGlsbF9w
ICsgMTEyKCRzcCkJICNjbGFzcyBkbW92ZSxkbV9yZXN0b3JlCSAjIDw+dDEy
NzEKICNpbnN0cgoJbGRhaAkkMjMsMzIoJDMxKQkgI2NsYXNzIGRtb3ZlLGRt
X2NvbnN0YW50CSAjIDIwOTcxNTIoSTMyKQoJYmVxCSQwLEw4MyQzCSAjY2xh
c3Mgc291cmNlCSAjIGxpbmUgMCwgPD50MTI3NQogI2luc3RyCi5sb2MgMiAy
NgoJbGRsCSQyMCwwKCQyNykJICNjbGFzcyBzb3VyY2UJICMgbGluZSAyNiwg
PD50MTI4MSwgPD50MTI2OSwgMChJNjQpCi5sb2MgMiAyNgoJYWRkcQkkMjcs
NCwkMTkJICNjbGFzcyBzb3VyY2UJICMgbGluZSAyNiwgPD50MTI3NywgPD50
MTI2OSwgNChTSTMyKQogI2luc3RyCi5sb2MgMiAyNgoJc3VicQkkMCwkMTks
JDE4CSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMjYsIDw+dDEyNzgsIDw+dDEy
NzUsIDw+dDEyNzcKCWxkcQkkMjQsJDIuMSQyc3BpbGxfcCArIDE2KCRzcCkJ
ICNjbGFzcyBkbW92ZSxkbV9yZXN0b3JlCSAjIDw+dDU3NwogI2luc3RyCi5s
b2MgMiAyNgoJYWRkbAkkMTgsMywkMTYJICNjbGFzcyBzb3VyY2UJICMgbGlu
ZSAyNiwgPD50NjM3LCA8PnQxMjc4LCAzKFNJMzIpCiAjaW5zdHIKLmxvYyAy
IDI2CglhbmQJJDIwLCQyMiwkMjAJICNjbGFzcyBzb3VyY2UJICMgbGluZSAy
NiwgPD50MTI4MiwgPD50MTI4MSwgNDI5Mjg3MDE0NChJMzIpCiAjaW5zdHIK
LmxvYyAyIDI2CgljbW92Z2UJJDE4LCQxOCwkMTYJICNjbGFzcyBzb3VyY2UJ
ICMgbGluZSAyNiwgPD50NjM4LCA8PnQxMjc4LCA8PnQxMjc4LCA8PnQ2MzcK
ICNpbnN0cgoubG9jIDIgMjYKCWxkYQkkMjIsLTEoJDIzKQkgI2NsYXNzIHNv
dXJjZQkgIyBsaW5lIDI2LCA8PnQ4MzksIDIwOTcxNTIoSTMyKSwgLTEoU0k2
NCkKICNpbnN0cgoubG9jIDIgMjYKCXNyYQkkMTYsJDIxLCQxNgkgI2NsYXNz
IHNvdXJjZQkgIyBsaW5lIDI2LCA8PnQxMjc5LCA8PnQ2MzgsIDIoU0k2NCkK
ICNpbnN0cgoJbGRhCSQyNSwzKCQzMSkJICNjbGFzcyBkbW92ZSxkbV9jb25z
dGFudAkgIyAzKFNJMzIpCiAjaW5zdHIKLmxvYyAyIDI2CglhbmQJJDE2LCQy
MiwkMjIJICNjbGFzcyBzb3VyY2UJICMgbGluZSAyNiwgPD50MTI4MCwgPD50
MTI3OSwgPD50ODM5CgljcHlzCSRmMzEsJGYzMSwkZjMxCSMgcGFkCiAjaW5z
dHIKLmxvYyAyIDI2CglvcgkkMjIsJDIwLCQyMAkgI2NsYXNzIHNvdXJjZQkg
IyBsaW5lIDI2LCA8PnQxMjgzLCA8PnQxMjgwLCA8PnQxMjgyCi5sb2MgMiAy
NgoJc3RsCSQyMCwwKCQyNykJICNjbGFzcyBzb3VyY2UJICMgbGluZSAyNiwg
PD50MTI4MywgPD50MTI2OSwgMChJNjQpLCAwKEkzMiksIDAoSTMyKSwgMChJ
MzIpLCAwKEkzMikKICNpbnN0cgoubG9jIDIgMjYKCWxkcQkkMjcsaW50ZXJw
cmV0ZXIuTFNWRnJlZUxpc3QuMgkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDI2
LCA8PnQxMjc2LCA8PnQ1MzYsIGFkZHIoaW50ZXJwcmV0ZXIuTFNWRnJlZUxp
c3QuVkFSLjIpKFA2NCkKCSAjIHN0YWxsIAkyCiAjaW5zdHIKLmxvYyAyIDI2
CglzdHEJJDI3LDAoJDE3KQkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDI2LCA8
PnQxMjc2LCA8PnQxMjcxLCAwKEk2NCksIDAoSTMyKSwgMChJMzIpLCAwKEkz
MiksIDAoSTMyKQogI2luc3RyCi5sb2MgMiAyNgoJc3RxCSQxNyxpbnRlcnBy
ZXRlci5MU1ZGcmVlTGlzdC4yCSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMjYs
IDw+dDEyNzEsIDw+dDUzNiwgYWRkcihpbnRlcnByZXRlci5MU1ZGcmVlTGlz
dC5WQVIuMikoUDY0KSwgMChJMzIpLCAwKEkzMiksIDAoSTMyKSwgMChJMzIp
CgkgIyBzdGFsbCAJMQogI2luc3RyCgliZXEJJDI0LEw4NCQzCSAjY2xhc3Mg
c291cmNlCSAjIGxpbmUgMCwgPD50NTc3CiAjaW5zdHIKCWJyCSQzMSxMNjIk
MwogI21hcmtfdHJhY2UgMTg7Ckw4NCQzOgogI2luc3RyCglvcgkkMCwkMzEs
JDI0CSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMCwgPD50NTc3LCA8PnQxMjc1
CgkgIyBzdGFsbCAJMQogI2luc3RyCglzdHEJJDI0LCQyLjEkMnNwaWxsX3Ag
KyAxNigkc3ApCSAjY2xhc3MgZG1vdmUsZG1fc3BpbGwJICMgPD50NTc3CiAj
bWFya190cmFjZSAxNzsKICNpbnN0cgoJbGRhCSQyNSwzKCQzMSkJICNjbGFz
cyBkbW92ZSxkbV9jb25zdGFudAkgIyAzKFNJMzIpCiAjaW5zdHIKCWJyCSQz
MSxMNjIkMwoJYmlzCSQzMSwkMzEsJDMxCSMgcGFkCiAjbWFya190cmFjZSA0
MzsKTDgzJDM6CiAjaW5zdHIKCW9yCSQzMSwkMzEsJDI1CSAjY2xhc3Mgc291
cmNlCSAjIGxpbmUgMCwgPD50NTg3LCAwKEkzMikKLmxvYyAyIDI2CglsZHEJ
JDExLER5Q1JUX0NvZGVMb2NhdGlvbgkgI2NsYXNzIHNvdXJjZQkgIyBsaW5l
IDI2LCA8PnQxMjg0LCA8PnQ1MzYsIGFkZHIoX0R5Q1JUX0NvZGVMb2NhdGlv
biQxLjApKFA2NCkKICNpbnN0cgoJYWRkcQkkMjcsMHg0LCQ4CSAjY2xhc3Mg
c291cmNlCSAjIGxpbmUgMCwgPD50NjEwLCA8PnQxMjY5LCAweDQoUDY0KQoJ
bGRxCSQyNCwkMi4xJDJzcGlsbF9wICsgMTYoJHNwKQkgI2NsYXNzIGRtb3Zl
LGRtX3Jlc3RvcmUJICMgPD50NTc3CiAjaW5zdHIKCXN0bAkkMjUsJDIuMSQy
c3BpbGxfcCgkc3ApCSAjY2xhc3MgZG1vdmUsZG1fc3BpbGwJICMgPD50NTg3
CglsZGEJJDE4LDEoJDMxKQkgI2NsYXNzIGRtb3ZlLGRtX2NvbnN0YW50CSAj
IDEoU0kzMikKICNpbnN0cgoJY21wZXEJJDExLCQ4LCQ4CSAjY2xhc3Mgc291
cmNlCSAjIGxpbmUgMCwgPD50ODQxLCA8PnQxMjg0LCA8PnQ2MTAKCWxkcQkk
MTYsJDIuMSQyc3BpbGxfcCArIDEyMCgkc3ApCSAjY2xhc3MgZG1vdmUsZG1f
cmVzdG9yZQkgIyA8PnQxMjc0CiAjaW5zdHIKCW9yCSQzMSwkMzEsJDMxCSAj
Y2xhc3MgZG1vdmUsZG1fcmVnaXN0ZXIJICMgPD50NTMzCiAjaW5zdHIKCWJl
cQkkOCxMODUkMwkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDAsIDw+dDg0MQog
I2luc3RyCglvcgkkMjcsJDMxLCQxOQkgI2NsYXNzIHNvdXJjZQkgIyBsaW5l
IDAsIDw+dDEyODQsIDw+dDEyNjkKCSAjIHN0YWxsIAkxCkw4NiQzOgogI2lu
c3RyCglzdHEJJDE5LCQyLjEkMnNwaWxsX3AgKyAxNjAoJHNwKQkgI2NsYXNz
IGRtb3ZlLGRtX3NwaWxsCSAjIDw+dDEyODQKICNpbnN0cgoJYmVxCSQyNCxM
ODckMwkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDAsIDw+dDU3NwpMODgkMzoK
ICNtYXJrX2NhbGwgY2FsbGVyX3NhdmVzLCByZWdzLCBhdHlwZXMobjY0LG42
NCxuMzIsbjY0KSwgcnR5cGVzKCk7CiAjaW5zdHIKLmxvYyAyIDI2Cglqc3IJ
JDI2LERZQ19DQUNIRV9pbnNlcnQKCWJyCSQyNixGQUtFOQpGQUtFOToJbGRn
cAkkZ3AsMCgkMjYpCSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMjYsIHJhZGRy
KERZQ19DQUNIRV9pbnNlcnQpKFA2NCksIDw+dDUzMywgPD50MTI3NCwgPD50
MTI3MSwgMShTSTMyKSwgPD50MTI4NAogI2luc3RyCglsZHEJJDExLCQyLjEk
MnNwaWxsX3AgKyAxNjAoJHNwKQkgI2NsYXNzIGRtb3ZlLGRtX3Jlc3RvcmUJ
ICMgPD50MTI4NAoJbGRhaAkkMTcsMSgkMzEpCSAjY2xhc3MgZG1vdmUsZG1f
Y29uc3RhbnQJICMgNjU1MzYoSTMyKQogI2luc3RyCglsZHEJJDE1LER5Q1JU
X1N0YXRpY1ZhbHVlVGFibGUJICNjbGFzcyBzb3VyY2UJICMgbGluZSAwLCA8
PnQxMjkyLCA8PnQ1MzYsIGFkZHIoX0R5Q1JUX1N0YXRpY1ZhbHVlVGFibGUk
MS4wKShQNjQpCi5sb2MgMiAyNgoJbGRhCSQ4LER5Q1JUX1RhYmxlUG9pbnRl
cnMrOAkgI2NsYXNzIHNvdXJjZSxjc3BlYwkgIyBsaW5lIDI2LCA8PnQ4NTMs
IDw+dDUzNiwgKGFkZHIoX0R5Q1JUX1RhYmxlUG9pbnRlcnMkMS4wKShQNjQp
ICsgMHg4KEk2NCkpKFA2NCkKICNpbnN0cgoJbGRhCSQ3LC0zMjc2OCgkMTcp
CSAjY2xhc3Mgc291cmNlLGNzcGVjCSAjIGxpbmUgMCwgPD50ODUwLCA2NTUz
NihJMzIpLCAtMzI3NjgoU0k2NCkKCWxkbAkkMjIsJDIuMSQyc3BpbGxfcCAr
IDk2KCRzcCkJICNjbGFzcyBkbW92ZSxkbV9yZXN0b3JlCSAjIDxfcGMkMS4x
PnQ0NTQKICNpbnN0cgoJc3RxCSQxMSxEeUNSVF9TdGl0Y2hMb2NhdGlvbgkg
I2NsYXNzIHNvdXJjZQkgIyBsaW5lIDAsIDw+dDEyODQsIDw+dDUzNiwgYWRk
cihfRHlDUlRfU3RpdGNoTG9jYXRpb24kMS4wKShQNjQpLCAwKEkzMiksIDAo
STMyKSwgMChJMzIpLCAwKEkzMikKCWxkYQkkNiwxKCQzMSkJICNjbGFzcyBk
bW92ZSxkbV9jb25zdGFudAkgIyAxKEkzMikKICNpbnN0cgoJbGRxCSQyMywk
Mi4xJDJzcGlsbF9wICsgODgoJHNwKQkgI2NsYXNzIGRtb3ZlLGRtX3Jlc3Rv
cmUJICMgPF9ieXRlY29kZXMkMS4xPnQ0NTUKCWxkYQkkMjEsNCgkMzEpCSAj
Y2xhc3MgZG1vdmUsZG1fY29uc3RhbnQJICMgNChJNjQpCiAjaW5zdHIKCWxk
YQkkMjAsMjEoJDMxKQkgI2NsYXNzIGRtb3ZlLGRtX2NvbnN0YW50CSAjIDIx
KFNJNjQpCglibmUJJDE1LEw4OSQzCSAjY2xhc3Mgc291cmNlCSAjIGxpbmUg
MCwgPD50MTI5MgpMOTAkMzoKICNpbnN0cgoubG9jIDIgMjYKCWxkcQkkMTUs
RHlDUlRfVGFibGVMb2NhdGlvbgkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDI2
LCA8PnQxMjk1LCA8PnQ1MzYsIGFkZHIoX0R5Q1JUX1RhYmxlTG9jYXRpb24k
MS4wKShQNjQpCglsZGEJJDE5LDE2KCQzMSkJICNjbGFzcyBkbW92ZSxkbV9j
b25zdGFudAkgIyAxNihTSTY0KQogI2luc3RyCi5sb2MgMiAyNgoJbGRsCSQx
MSxEeUNSVF9UYWJsZVBvaW50ZXJJbmRleAkgI2NsYXNzIHNvdXJjZQkgIyBs
aW5lIDI2LCA8X0R5Q1JUX1RhYmxlUG9pbnRlckluZGV4JDEuMD50MTI5OSwg
PD50NTM2LCBhZGRyKF9EeUNSVF9UYWJsZVBvaW50ZXJJbmRleCQxLjApKFA2
NCkKCWxkYQkkMTgsMTEoJDMxKQkgI2NsYXNzIGRtb3ZlLGRtX2NvbnN0YW50
CSAjIDExKFNJNjQpCiAjaW5zdHIKCXN0bAkkNixEeUNSVF9CdWlsZFRhYmxl
UG9pbnRlcgkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDAsIDEoSTMyKSwgPD50
NTM2LCBhZGRyKF9EeUNSVF9CdWlsZFRhYmxlUG9pbnRlciQxLjApKFA2NCks
IDAoSTMyKSwgMChJMzIpLCAwKEkzMiksIDAoSTMyKQoJbGRhCSQxNiwyNigk
MzEpCSAjY2xhc3MgZG1vdmUsZG1fY29uc3RhbnQJICMgMjYoU0k2NCkKICNp
bnN0cgoJYWRkcQkkMTUsJDcsJDcJICNjbGFzcyBzb3VyY2UJICMgbGluZSAw
LCA8PnQxMjk3LCA8PnQxMjk1LCA8PnQ4NTAKCXN0cQkkNyxEeUNSVF9TdGF0
aWNWYWx1ZVRhYmxlCSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMCwgPD50MTI5
NywgPD50NTM2LCBhZGRyKF9EeUNSVF9TdGF0aWNWYWx1ZVRhYmxlJDEuMCko
UDY0KSwgMChJMzIpLCAwKEkzMiksIDAoSTMyKSwgMChJMzIpCiAjaW5zdHIK
LmxvYyAyIDI2CglhZGRxCSQxMSwkOCwkOAkgI2NsYXNzIHNvdXJjZQkgIyBs
aW5lIDI2LCA8PnQxMzAxLCA8X0R5Q1JUX1RhYmxlUG9pbnRlckluZGV4JDEu
MD50MTI5OSwgPD50ODUzCglzdHEJJDMxLER5Q1JUX1NWVEluZGV4CSAjY2xh
c3Mgc291cmNlCSAjIGxpbmUgMCwgMHgwKFA2NCksIDw+dDUzNiwgYWRkcihf
RHlDUlRfU1ZUSW5kZXgkMS4wKShQNjQpLCAwKEkzMiksIDAoSTMyKSwgMChJ
MzIpLCAwKEkzMikKICNpbnN0cgoubG9jIDIgMjYKCWFkZHEJJDE1LDY1NTM2
LCQxNQkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDI2LCA8X0R5Q1JUX1RhYmxl
TG9jYXRpb24kMS4wPnQxMjk2LCA8PnQxMjk1LCA2NTUzNihJMzIpCi5sb2Mg
MiAyNgoJc3RxCSQxNSxEeUNSVF9UYWJsZUxvY2F0aW9uCSAjY2xhc3Mgc291
cmNlCSAjIGxpbmUgMjYsIDxfRHlDUlRfVGFibGVMb2NhdGlvbiQxLjA+dDEy
OTYsIDw+dDUzNiwgYWRkcihfRHlDUlRfVGFibGVMb2NhdGlvbiQxLjApKFA2
NCksIDAoSTMyKSwgMChJMzIpLCAwKEkzMiksIDAoSTMyKQogI2luc3RyCi5s
b2MgMiAyNgoJc3RxCSQ3LDAoJDgpCSAjY2xhc3Mgc291cmNlCSAjIGxpbmUg
MjYsIDw+dDEyOTcsIDw+dDEzMDEsIDAoSTY0KSwgMChJMzIpLCAwKEkzMiks
IDAoSTMyKSwgMChJMzIpCi5sb2MgMiAyNgoJYWRkbAkkMTEsOCwkMTEJICNj
bGFzcyBzb3VyY2UJICMgbGluZSAyNiwgPF9EeUNSVF9UYWJsZVBvaW50ZXJJ
bmRleCQxLjA+dDEzMDAsIDxfRHlDUlRfVGFibGVQb2ludGVySW5kZXgkMS4w
PnQxMjk5LCA4KEkzMikKICNpbnN0cgoubG9jIDIgMjYKCXN0bAkkMTEsRHlD
UlRfVGFibGVQb2ludGVySW5kZXgJICNjbGFzcyBzb3VyY2UJICMgbGluZSAy
NiwgPF9EeUNSVF9UYWJsZVBvaW50ZXJJbmRleCQxLjA+dDEzMDAsIDw+dDUz
NiwgYWRkcihfRHlDUlRfVGFibGVQb2ludGVySW5kZXgkMS4wKShQNjQpLCAw
KEkzMiksIDAoSTMyKSwgMChJMzIpLCAwKEkzMikKCWxkYQkkMTQsMSgkMzEp
CSAjY2xhc3MgZG1vdmUsZG1fY29uc3RhbnQJICMgMShTSTY0KQogI2luc3Ry
Ci5sb2MgMiAyNgoJbGRxCSQxNSxEeUNSVF9Xb3JrTGlzdAkgI2NsYXNzIHNv
dXJjZQkgIyBsaW5lIDI2LCA8X0R5Q19UZW1wJDEuNDg+dDEyOTgsIDw+dDUz
NiwgYWRkcihfRHlDUlRfV29ya0xpc3QkMS4wKShQNjQpCglsZGEJJDEzLDYo
JDMxKQkgI2NsYXNzIGRtb3ZlLGRtX2NvbnN0YW50CSAjIDYoU0k2NCkKICNp
bnN0cgoJbGRhCSQxMiwzMSgkMzEpCSAjY2xhc3MgZG1vdmUsZG1fY29uc3Rh
bnQJICMgMzEoU0k2NCkKCSAjIHN0YWxsIAkxCiAjaW5zdHIKLmxvYyAyIDI2
CglibmUJJDE1LEw5MSQzCSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMjYsIDxf
RHlDX1RlbXAkMS40OD50MTI5OApMOTIkMzoKICNpbnN0cgoJc3RxCSQzMSxE
eUNSVF9CcmFuY2hJbmRleAkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDAsIDB4
MChQNjQpLCA8PnQ1MzYsIGFkZHIoX0R5Q1JUX0JyYW5jaEluZGV4JDEuMCko
UDY0KSwgMChJMzIpLCAwKEkzMiksIDAoSTMyKSwgMChJMzIpCiAjaW5zdHIK
CWJyCSQzMSxMNDIkMwogI21hcmtfdHJhY2UgMTAxOwpMOTEkMzoKICNpbnN0
cgoJbGRhCSQyNSwzKCQzMSkJICNjbGFzcyBkbW92ZSxkbV9jb25zdGFudAkg
IyAzKFNJMzIpCgkgIyBzdGFsbCAJMQogI2luc3RyCi5sb2MgMiAyNgoJc3Rs
CSQyNSwzMigkMTUpCSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMjYsIDMoU0kz
MiksIDxfRHlDX1RlbXAkMS40OD50MTI5OCwgMzIoSTY0KSwgMChJMzIpLCAw
KEkzMiksIDAoSTMyKSwgMChJMzIpCiAjaW5zdHIKCWJyCSQzMSxMOTIkMwoJ
YmlzCSQzMSwkMzEsJDMxCSMgcGFkCiAjbWFya190cmFjZSA3NTsKTDg5JDM6
CiAjaW5zdHIKCWxkbAkkMTUsRHlDUlRfU1ZUSW5kZXgJICNjbGFzcyBzb3Vy
Y2UJICMgbGluZSAwLCA8PnQxMjkzLCA8PnQ1MzYsIGFkZHIoX0R5Q1JUX1NW
VEluZGV4JDEuMCkoUDY0KQoJbGRhCSQxMiwzMSgkMzEpCSAjY2xhc3MgZG1v
dmUsZG1fY29uc3RhbnQJICMgMzEoU0k2NCkKICNpbnN0cgoJbGRhCSQxMyw2
KCQzMSkJICNjbGFzcyBkbW92ZSxkbV9jb25zdGFudAkgIyA2KFNJNjQpCiAj
aW5zdHIKCWxkYQkkMTQsMSgkMzEpCSAjY2xhc3MgZG1vdmUsZG1fY29uc3Rh
bnQJICMgMShTSTY0KQogI2luc3RyCglhZGRsCSQxNSwyMTYsJDE1CSAjY2xh
c3Mgc291cmNlCSAjIGxpbmUgMCwgPD50MTI5NCwgPD50MTI5MywgMjE2KFNJ
MzIpCiAjaW5zdHIKCWNtcGxlCSQxNSwkMTcsJDExCSAjY2xhc3Mgc291cmNl
CSAjIGxpbmUgMCwgPD50ODQ3LCA8PnQxMjk0LCA2NTUzNihJMzIpCiAjaW5z
dHIKCWxkYQkkMTYsMjYoJDMxKQkgI2NsYXNzIGRtb3ZlLGRtX2NvbnN0YW50
CSAjIDI2KFNJNjQpCgljcHlzCSRmMzEsJGYzMSwkZjMxCSMgcGFkCiAjaW5z
dHIKCWxkYQkkMTgsMTEoJDMxKQkgI2NsYXNzIGRtb3ZlLGRtX2NvbnN0YW50
CSAjIDExKFNJNjQpCgliZXEJJDExLEw5MyQzCSAjY2xhc3Mgc291cmNlCSAj
IGxpbmUgMCwgPD50ODQ3CiAjaW5zdHIKCXN0bAkkNixEeUNSVF9CdWlsZFRh
YmxlUG9pbnRlcgkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDAsIDEoSTMyKSwg
PD50NTM2LCBhZGRyKF9EeUNSVF9CdWlsZFRhYmxlUG9pbnRlciQxLjApKFA2
NCksIDAoSTMyKSwgMChJMzIpLCAwKEkzMiksIDAoSTMyKQoJbGRhCSQxOSwx
NigkMzEpCSAjY2xhc3MgZG1vdmUsZG1fY29uc3RhbnQJICMgMTYoU0k2NCkK
ICNpbnN0cgoJYnIJJDMxLEw5MiQzCiAjbWFya190cmFjZSAxMTA7Ckw5MyQz
OgogI2luc3RyCglsZGEJJDcsLTMyNzY4KCQxNykJICNjbGFzcyBzb3VyY2Us
cmVqb2luX2NvcHkJICMgbGluZSAwLCA8PnQ4NTAsIDY1NTM2KEkzMiksIC0z
Mjc2OChTSTY0KQogI2luc3RyCi5sb2MgMiAyNgoJbGRhCSQ4LER5Q1JUX1Rh
YmxlUG9pbnRlcnMrOAkgI2NsYXNzIHNvdXJjZSxyZWpvaW5fY29weQkgIyBs
aW5lIDI2LCA8PnQ4NTMsIDw+dDUzNiwgKGFkZHIoX0R5Q1JUX1RhYmxlUG9p
bnRlcnMkMS4wKShQNjQpICsgMHg4KEk2NCkpKFA2NCkKCWxkcQkkMjMsJDIu
MSQyc3BpbGxfcCArIDg4KCRzcCkJICNjbGFzcyBkbW92ZSxkbV9yZXN0b3Jl
CSAjIDxfYnl0ZWNvZGVzJDEuMT50NDU1CiAjaW5zdHIKCWxkYQkkMjAsMjEo
JDMxKQkgI2NsYXNzIGRtb3ZlLGRtX2NvbnN0YW50CSAjIDIxKFNJNjQpCgli
cgkkMzEsTDkwJDMKICNtYXJrX3RyYWNlIDc3OwpMODckMzoKICNpbnN0cgoJ
b3IJJDE5LCQzMSwkMjQJICNjbGFzcyBzb3VyY2UJICMgbGluZSAwLCA8PnQ1
NzcsIDw+dDEyODQKICNpbnN0cgoJb3IJJDMxLCQzMSwkMzEJICNjbGFzcyBk
bW92ZSxkbV9yZWdpc3RlcgkgIyA8PnQ1MzMKICNpbnN0cgoJc3RxCSQyNCwk
Mi4xJDJzcGlsbF9wICsgMTYoJHNwKQkgI2NsYXNzIGRtb3ZlLGRtX3NwaWxs
CSAjIDw+dDU3NwogI2luc3RyCglicgkkMzEsTDg4JDMKICNtYXJrX3RyYWNl
IDc2OwpMODUkMzoKICNpbnN0cgoubG9jIDIgMjYKCWFkZHEJJDI3LDQsJDI1
CSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMjYsIDw+dDEyODUsIDw+dDEyNjks
IDQoU0kzMikKLmxvYyAyIDI2CglsZGwJJDIzLDAoJDI3KQkgI2NsYXNzIHNv
dXJjZQkgIyBsaW5lIDI2LCA8PnQxMjg5LCA8PnQxMjY5LCAwKEk2NCkKICNp
bnN0cgoubG9jIDIgMjYKCXN1YnEJJDExLCQyNSwkMjIJICNjbGFzcyBzb3Vy
Y2UJICMgbGluZSAyNiwgPD50MTI4NiwgPD50MTI4NCwgPD50MTI4NQogI2lu
c3RyCi5sb2MgMiAyNgoJYWRkbAkkMjIsMywkMjUJICNjbGFzcyBzb3VyY2UJ
ICMgbGluZSAyNiwgPD50NjM5LCA8PnQxMjg2LCAzKFNJMzIpCiAjaW5zdHIK
LmxvYyAyIDI2CgljbW92Z2UJJDIyLCQyMiwkMjUJICNjbGFzcyBzb3VyY2UJ
ICMgbGluZSAyNiwgPD50NjQwLCA8PnQxMjg2LCA8PnQxMjg2LCA8PnQ2MzkK
ICNpbnN0cgoJbGRhCSQyMiwyKCQzMSkJICNjbGFzcyBkbW92ZSxkbV9jb25z
dGFudAkgIyAyKFNJNjQpCiAjaW5zdHIKCWxkYWgJJDIxLDMyKCQzMSkJICNj
bGFzcyBkbW92ZSxkbV9jb25zdGFudAkgIyAyMDk3MTUyKEkzMikKICNpbnN0
cgoubG9jIDIgMjYKCXNyYQkkMjUsJDIyLCQyNQkgI2NsYXNzIHNvdXJjZQkg
IyBsaW5lIDI2LCA8PnQxMjg3LCA8PnQ2NDAsIDIoU0k2NCkKICNpbnN0cgou
bG9jIDIgMjYKCWxkYQkkMjEsLTEoJDIxKQkgI2NsYXNzIHNvdXJjZQkgIyBs
aW5lIDI2LCA8PnQ4NDMsIDIwOTcxNTIoSTMyKSwgLTEoU0k2NCkKICNpbnN0
cgoubG9jIDIgMjYKCWFuZAkkMjUsJDIxLCQyNQkgI2NsYXNzIHNvdXJjZQkg
IyBsaW5lIDI2LCA8PnQxMjg4LCA8PnQxMjg3LCA8PnQ4NDMKICNpbnN0cgoJ
bGRhaAkkMjIsLTMyKCQzMSkJICNjbGFzcyBkbW92ZSxkbV9jb25zdGFudAkg
IyA0MjkyODcwMTQ0KEkzMikKICNpbnN0cgoJb3IJJDMxLCQzMSwkMzEJICNj
bGFzcyBkbW92ZSxkbV9yZWdpc3RlcgkgIyA8PnQ1MzMKICNpbnN0cgoubG9j
IDIgMjYKCWFuZAkkMjMsJDIyLCQyMwkgI2NsYXNzIHNvdXJjZQkgIyBsaW5l
IDI2LCA8PnQxMjkwLCA8PnQxMjg5LCA0MjkyODcwMTQ0KEkzMikKCWNweXMJ
JGYzMSwkZjMxLCRmMzEJIyBwYWQKICNpbnN0cgoubG9jIDIgMjYKCW9yCSQy
NSwkMjMsJDI1CSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMjYsIDw+dDEyOTEs
IDw+dDEyODgsIDw+dDEyOTAKLmxvYyAyIDI2CglzdGwJJDI1LDAoJDI3KQkg
I2NsYXNzIHNvdXJjZQkgIyBsaW5lIDI2LCA8PnQxMjkxLCA8PnQxMjY5LCAw
KEk2NCksIDAoSTMyKSwgMChJMzIpLCAwKEkzMiksIDAoSTMyKQogI2luc3Ry
CglvcgkkMTEsJDMxLCQxOQkgI2NsYXNzIGRtb3ZlLGRtX3JlZ2lzdGVyCSAj
IDw+dDEyODQKICNpbnN0cgoJYnIJJDMxLEw4NiQzCiAjbWFya190cmFjZSAx
NDsKTDgxJDM6CiAjbWFya19jYWxsIGNhbGxlcl9zYXZlcywgcmVncywgYXR5
cGVzKCksIHJ0eXBlcyhuNjQpOwogI2luc3RyCglvcgkkMzEsJDMxLCQzMQkg
I2NsYXNzIGRtb3ZlLGRtX3JlZ2lzdGVyCSAjIDw+dDUzMwoubG9jIDIgMjYK
CWpzcgkkMjYsRFlDX0NBQ0hFX2NyZWF0ZQoJYnIJJDI2LEZBS0U1CkZBS0U1
OglsZGdwCSRncCwwKCQyNikJICNjbGFzcyBzb3VyY2UJICMgbGluZSAyNiwg
cmFkZHIoRFlDX0NBQ0hFX2NyZWF0ZSkoUDY0KSwgPD50NTMzCiAjaW5zdHIK
CXN0cQkkMCwkMi4xJDJzcGlsbF9wICsgMTIwKCRzcCkJICNjbGFzcyBkbW92
ZSxkbV9zcGlsbAkgIyA8PnQxMjc0CglvcgkkMCwkMzEsJDE2CSAjY2xhc3Mg
ZG1vdmUsZG1fcmVnaXN0ZXIJICMgPD50MTI3NAogI2luc3RyCglzdHEJJDAs
aW50ZXJwcmV0ZXIuQ2FjaGUuMgkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDAs
IDw+dDEyNzQsIDw+dDUzNiwgYWRkcihpbnRlcnByZXRlci5DYWNoZS5WQVIu
MikoUDY0KSwgMChJMzIpLCAwKEkzMiksIDAoSTMyKSwgMChJMzIpCglsZGEJ
JDE4LDEoJDMxKQkgI2NsYXNzIGRtb3ZlLGRtX2NvbnN0YW50CSAjIDEoU0kz
MikKICNpbnN0cgoJb3IJJDMxLCQzMSwkMzEJICNjbGFzcyBkbW92ZSxkbV9y
ZWdpc3RlcgkgIyA8PnQ1MzMKCWxkcQkkMTcsJDIuMSQyc3BpbGxfcCArIDEx
Migkc3ApCSAjY2xhc3MgZG1vdmUsZG1fcmVzdG9yZQkgIyA8PnQxMjcxCgkg
IyBzdGFsbCAJMQogI2luc3RyCglicgkkMzEsTDgyJDMKCWJpcwkkMzEsJDMx
LCQzMQkjIHBhZAogI21hcmtfdHJhY2UgMTM7Ckw3OSQzOgogI2luc3RyCi5s
b2MgMiAyNgoJbGRxCSQxNyxpbnRlcnByZXRlci5MU1ZGcmVlTGlzdC4yCSAj
Y2xhc3Mgc291cmNlCSAjIGxpbmUgMjYsIDw+dDEyNzEsIDw+dDUzNiwgYWRk
cihpbnRlcnByZXRlci5MU1ZGcmVlTGlzdC5WQVIuMikoUDY0KQoJb3IJJDMx
LCQzMSwkMzEJICNjbGFzcyBkbW92ZSxkbV9yZWdpc3RlcgkgIyA8PnQ1MzMK
ICNpbnN0cgoJbGRxCSQxNixpbnRlcnByZXRlci5DYWNoZS4yCSAjY2xhc3Mg
c291cmNlLHJlam9pbl9jb3B5CSAjIGxpbmUgMCwgPD50MTI3NCwgPD50NTM2
LCBhZGRyKGludGVycHJldGVyLkNhY2hlLlZBUi4yKShQNjQpCgkgIyBzdGFs
bCAJMQogI2luc3RyCglzdHEJJDE3LCQyLjEkMnNwaWxsX3AgKyAxMTIoJHNw
KQkgI2NsYXNzIGRtb3ZlLGRtX3NwaWxsCSAjIDw+dDEyNzEKICNpbnN0cgoJ
c3RxCSQxNiwkMi4xJDJzcGlsbF9wICsgMTIwKCRzcCkJICNjbGFzcyBkbW92
ZSxkbV9zcGlsbAkgIyA8PnQxMjc0CiAjaW5zdHIKLmxvYyAyIDI2CglsZHEJ
JDI3LDAoJDE3KQkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDI2LCA8PnQxMjcy
LCA8PnQxMjcxLCAwKEk2NCkKCSAjIHN0YWxsIAkyCiAjaW5zdHIKLmxvYyAy
IDI2CglzdHEJJDI3LGludGVycHJldGVyLkxTVkZyZWVMaXN0LjIJICNjbGFz
cyBzb3VyY2UJICMgbGluZSAyNiwgPD50MTI3MiwgPD50NTM2LCBhZGRyKGlu
dGVycHJldGVyLkxTVkZyZWVMaXN0LlZBUi4yKShQNjQpLCAwKEkzMiksIDAo
STMyKSwgMChJMzIpLCAwKEkzMikKICNpbnN0cgoJYnIJJDMxLEw4MCQzCiAj
bWFya190cmFjZSA2OwpMNzYkMzoKICNpbnN0cgoubG9jIDIgMjYKCWxkcQkk
MjcsRHlDUlRfVGFibGVMb2NhdGlvbgkgI2NsYXNzIHNvdXJjZQkgIyBsaW5l
IDI2LCA8PnQxMzYxLCA8PnQ1MzYsIGFkZHIoX0R5Q1JUX1RhYmxlTG9jYXRp
b24kMS4wKShQNjQpCglsZGFoCSQyMSwxKCQzMSkJICNjbGFzcyBkbW92ZSxk
bV9jb25zdGFudAkgIyA2NTUzNihJMzIpCiAjaW5zdHIKLmxvYyAyIDI2Cgls
ZGwJJDIwLER5Q1JUX1RhYmxlUG9pbnRlckluZGV4CSAjY2xhc3Mgc291cmNl
CSAjIGxpbmUgMjYsIDxfRHlDUlRfVGFibGVQb2ludGVySW5kZXgkMS4wPnQx
MzY1LCA8PnQ1MzYsIGFkZHIoX0R5Q1JUX1RhYmxlUG9pbnRlckluZGV4JDEu
MCkoUDY0KQoubG9jIDIgMjYKCWxkYQkkMTgsRHlDUlRfVGFibGVQb2ludGVy
cys4CSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMjYsIDw+dDg5MCwgPD50NTM2
LCAoYWRkcihfRHlDUlRfVGFibGVQb2ludGVycyQxLjApKFA2NCkgKyAweDgo
STY0KSkoUDY0KQogI2luc3RyCglsZGEJJDIxLC0zMjc2OCgkMjEpCSAjY2xh
c3Mgc291cmNlCSAjIGxpbmUgMCwgPD50ODg3LCA2NTUzNihJMzIpLCAtMzI3
NjgoU0k2NCkKCXN0bAkkMTksRHlDUlRfQnVpbGRUYWJsZVBvaW50ZXIJICNj
bGFzcyBzb3VyY2UJICMgbGluZSAwLCAxKEkzMiksIDw+dDUzNiwgYWRkcihf
RHlDUlRfQnVpbGRUYWJsZVBvaW50ZXIkMS4wKShQNjQpLCAwKEkzMiksIDAo
STMyKSwgMChJMzIpLCAwKEkzMikKICNpbnN0cgoJYWRkcQkkMjcsJDIxLCQx
OQkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDAsIDw+dDEzNjMsIDw+dDEzNjEs
IDw+dDg4NwoJc3RxCSQxOSxEeUNSVF9TdGF0aWNWYWx1ZVRhYmxlCSAjY2xh
c3Mgc291cmNlCSAjIGxpbmUgMCwgPD50MTM2MywgPD50NTM2LCBhZGRyKF9E
eUNSVF9TdGF0aWNWYWx1ZVRhYmxlJDEuMCkoUDY0KSwgMChJMzIpLCAwKEkz
MiksIDAoSTMyKSwgMChJMzIpCiAjaW5zdHIKLmxvYyAyIDI2CglhZGRxCSQy
MCwkMTgsJDE4CSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMjYsIDw+dDEzNjcs
IDxfRHlDUlRfVGFibGVQb2ludGVySW5kZXgkMS4wPnQxMzY1LCA8PnQ4OTAK
CXN0cQkkMzEsRHlDUlRfU1ZUSW5kZXgJICNjbGFzcyBzb3VyY2UJICMgbGlu
ZSAwLCAweDAoUDY0KSwgPD50NTM2LCBhZGRyKF9EeUNSVF9TVlRJbmRleCQx
LjApKFA2NCksIDAoSTMyKSwgMChJMzIpLCAwKEkzMiksIDAoSTMyKQogI2lu
c3RyCi5sb2MgMiAyNgoJYWRkcQkkMjcsNjU1MzYsJDI3CSAjY2xhc3Mgc291
cmNlCSAjIGxpbmUgMjYsIDxfRHlDUlRfVGFibGVMb2NhdGlvbiQxLjA+dDEz
NjIsIDw+dDEzNjEsIDY1NTM2KEkzMikKLmxvYyAyIDI2CglzdHEJJDI3LER5
Q1JUX1RhYmxlTG9jYXRpb24JICNjbGFzcyBzb3VyY2UJICMgbGluZSAyNiwg
PF9EeUNSVF9UYWJsZUxvY2F0aW9uJDEuMD50MTM2MiwgPD50NTM2LCBhZGRy
KF9EeUNSVF9UYWJsZUxvY2F0aW9uJDEuMCkoUDY0KSwgMChJMzIpLCAwKEkz
MiksIDAoSTMyKSwgMChJMzIpCiAjaW5zdHIKLmxvYyAyIDI2CglzdHEJJDE5
LDAoJDE4KQkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDI2LCA8PnQxMzYzLCA8
PnQxMzY3LCAwKEk2NCksIDAoSTMyKSwgMChJMzIpLCAwKEkzMiksIDAoSTMy
KQoubG9jIDIgMjYKCWFkZGwJJDIwLDgsJDIwCSAjY2xhc3Mgc291cmNlCSAj
IGxpbmUgMjYsIDxfRHlDUlRfVGFibGVQb2ludGVySW5kZXgkMS4wPnQxMzY2
LCA8X0R5Q1JUX1RhYmxlUG9pbnRlckluZGV4JDEuMD50MTM2NSwgOChJMzIp
CiAjaW5zdHIKLmxvYyAyIDI2CglzdGwJJDIwLER5Q1JUX1RhYmxlUG9pbnRl
ckluZGV4CSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMjYsIDxfRHlDUlRfVGFi
bGVQb2ludGVySW5kZXgkMS4wPnQxMzY2LCA8PnQ1MzYsIGFkZHIoX0R5Q1JU
X1RhYmxlUG9pbnRlckluZGV4JDEuMCkoUDY0KSwgMChJMzIpLCAwKEkzMiks
IDAoSTMyKSwgMChJMzIpCiAjaW5zdHIKLmxvYyAyIDI2CglsZHEJJDI3LER5
Q1JUX1dvcmtMaXN0CSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMjYsIDxfRHlD
X1RlbXAkMS40OD50MTM2NCwgPD50NTM2LCBhZGRyKF9EeUNSVF9Xb3JrTGlz
dCQxLjApKFA2NCkKCSAjIHN0YWxsIAkyCiAjaW5zdHIKLmxvYyAyIDI2Cgli
bmUJJDI3LEw5NCQzCSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMjYsIDxfRHlD
X1RlbXAkMS40OD50MTM2NApMNzckMzoKICNpbnN0cgoJc3RxCSQzMSxEeUNS
VF9CcmFuY2hJbmRleAkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDAsIDB4MChQ
NjQpLCA8PnQ1MzYsIGFkZHIoX0R5Q1JUX0JyYW5jaEluZGV4JDEuMCkoUDY0
KSwgMChJMzIpLCAwKEkzMiksIDAoSTMyKSwgMChJMzIpCiAjaW5zdHIKCWJy
CSQzMSxMNzgkMwogI21hcmtfdHJhY2UgMTk7Ckw5NCQzOgogI2luc3RyCgls
ZGEJJDI1LDMoJDMxKQkgI2NsYXNzIGRtb3ZlLGRtX2NvbnN0YW50CSAjIDMo
U0kzMikKCSAjIHN0YWxsIAkxCiAjaW5zdHIKLmxvYyAyIDI2CglzdGwJJDI1
LDMyKCQyNykJICNjbGFzcyBzb3VyY2UJICMgbGluZSAyNiwgMyhTSTMyKSwg
PF9EeUNfVGVtcCQxLjQ4PnQxMzY0LCAzMihJNjQpLCAwKEkzMiksIDAoSTMy
KSwgMChJMzIpLCAwKEkzMikKICNpbnN0cgoJYnIJJDMxLEw3NyQzCiAjbWFy
a190cmFjZSAxMjsKTDc0JDM6CiAjaW5zdHIKCW9yCSQxOSwkMzEsJDI0CSAj
Y2xhc3Mgc291cmNlCSAjIGxpbmUgMCwgPD50NTc3LCA8PnQxMzQ2CiAjaW5z
dHIKCW9yCSQzMSwkMzEsJDMxCSAjY2xhc3MgZG1vdmUsZG1fcmVnaXN0ZXIJ
ICMgPD50NTMzCiAjaW5zdHIKCXN0cQkkMjQsJDIuMSQyc3BpbGxfcCArIDE2
KCRzcCkJICNjbGFzcyBkbW92ZSxkbV9zcGlsbAkgIyA8PnQ1NzcKICNpbnN0
cgoJbGRxCSQxNiwkMi4xJDJzcGlsbF9wICsgNTYoJHNwKQkgI2NsYXNzIGRt
b3ZlLGRtX3Jlc3RvcmUJICMgPD50MTA4MwogI2luc3RyCglicgkkMzEsTDc1
JDMKCWJpcwkkMzEsJDMxLCQzMQkjIHBhZAogI21hcmtfdHJhY2UgMjU7Ckw3
MyQzOgogI2luc3RyCglsZHEJJDE5LCQyLjEkMnNwaWxsX3AgKyA0MCgkc3Ap
CSAjY2xhc3MgZG1vdmUsZG1fcmVzdG9yZQkgIyA8PnQxMzY5CglsZGEJJDI1
LDIoJDMxKQkgI2NsYXNzIGRtb3ZlLGRtX2NvbnN0YW50CSAjIDIoU0k2NCkK
ICNpbnN0cgoJbGRhaAkkMjEsMzIoJDMxKQkgI2NsYXNzIGRtb3ZlLGRtX2Nv
bnN0YW50CSAjIDIwOTcxNTIoSTMyKQogI2luc3RyCglsZGFoCSQyMCwtMzIo
JDMxKQkgI2NsYXNzIGRtb3ZlLGRtX2NvbnN0YW50CSAjIDQyOTI4NzAxNDQo
STMyKQogI2luc3RyCi5sb2MgMiAyNgoJYWRkcQkkMTksNCwkMTcJICNjbGFz
cyBzb3VyY2UJICMgbGluZSAyNiwgPD50MTM1MSwgPD50MTM2OSwgNChTSTMy
KQoubG9jIDIgMjYKCWxkbAkkMTYsMCgkMTkpCSAjY2xhc3Mgc291cmNlCSAj
IGxpbmUgMjYsIDw+dDEzNTUsIDw+dDEzNjksIDAoSTY0KQogI2luc3RyCi5s
b2MgMiAyNgoJc3VicQkkMjcsJDE3LCQxNQkgI2NsYXNzIHNvdXJjZQkgIyBs
aW5lIDI2LCA8PnQxMzUyLCA8PnQxMzQ2LCA8PnQxMzUxCiAjaW5zdHIKLmxv
YyAyIDI2CglhZGRsCSQxNSwzLCQxNwkgI2NsYXNzIHNvdXJjZQkgIyBsaW5l
IDI2LCA8PnQ2NDcsIDw+dDEzNTIsIDMoU0kzMikKICNpbnN0cgoubG9jIDIg
MjYKCWNtb3ZnZQkkMTUsJDE1LCQxNwkgI2NsYXNzIHNvdXJjZQkgIyBsaW5l
IDI2LCA8PnQ2NDgsIDw+dDEzNTIsIDw+dDEzNTIsIDw+dDY0NwogI2luc3Ry
Ci5sb2MgMiAyNgoJbGRhCSQyMSwtMSgkMjEpCSAjY2xhc3Mgc291cmNlCSAj
IGxpbmUgMjYsIDw+dDg3OSwgMjA5NzE1MihJMzIpLCAtMShTSTY0KQogI2lu
c3RyCi5sb2MgMiAyNgoJc3JhCSQxNywkMjUsJDE3CSAjY2xhc3Mgc291cmNl
CSAjIGxpbmUgMjYsIDw+dDEzNTMsIDw+dDY0OCwgMihTSTY0KQogI2luc3Ry
Ci5sb2MgMiAyNgoJYW5kCSQxNiwkMjAsJDE2CSAjY2xhc3Mgc291cmNlCSAj
IGxpbmUgMjYsIDw+dDEzNTYsIDw+dDEzNTUsIDQyOTI4NzAxNDQoSTMyKQog
I2luc3RyCi5sb2MgMiAyNgoJYW5kCSQxNywkMjEsJDIxCSAjY2xhc3Mgc291
cmNlCSAjIGxpbmUgMjYsIDw+dDEzNTQsIDw+dDEzNTMsIDw+dDg3OQoJY3B5
cwkkZjMxLCRmMzEsJGYzMQkjIHBhZAogI2luc3RyCi5sb2MgMiAyNgoJb3IJ
JDIxLCQxNiwkMTYJICNjbGFzcyBzb3VyY2UJICMgbGluZSAyNiwgPD50MTM1
NywgPD50MTM1NCwgPD50MTM1NgoubG9jIDIgMjYKCXN0bAkkMTYsMCgkMTkp
CSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMjYsIDw+dDEzNTcsIDw+dDEzNjks
IDAoSTY0KSwgMChJMzIpLCAwKEkzMiksIDAoSTMyKSwgMChJMzIpCiAjaW5z
dHIKCWJyCSQzMSxMNzEkMwogI21hcmtfdHJhY2UgMjE7Ckw3MiQzOgogI2lu
c3RyCglsZHEJJDE5LCQyLjEkMnNwaWxsX3AgKyA0MCgkc3ApCSAjY2xhc3Mg
ZG1vdmUsZG1fcmVzdG9yZQkgIyA8PnQxMzY5CgkgIyBzdGFsbCAJMgogI2lu
c3RyCi5sb2MgMiAyNgoJc3RxCSQyNywwKCQxOSkJICNjbGFzcyBzb3VyY2UJ
ICMgbGluZSAyNiwgPD50MTM0NiwgPD50MTM2OSwgMChJNjQpLCAwKEkzMiks
IDAoSTMyKSwgMChJMzIpLCAwKEkzMikKICNpbnN0cgoJYnIJJDMxLEw3MSQz
CiAjbWFya190cmFjZSAxNTsKTDY5JDM6CiAjaW5zdHIKCW9yCSQzMSwkMzEs
JDI1CSAjY2xhc3Mgc291cmNlLHJlam9pbl9jb3B5CSAjIGxpbmUgMCwgPD50
NTg3LCAwKEkzMikKCWNweXMJJGYzMSwkZjMxLCRmMzEJIyBwYWQKCSAjIHN0
YWxsIAkxCiAjbWFya190cmFjZSAxNjsKICNpbnN0cgoJb3IJJDI1LCQzMSwk
MTgJICNjbGFzcyBkbW92ZSxkbV9yZWdpc3RlcgkgIyA8PnQ1ODcKCWxkcQkk
MjUsJDIuMSQyc3BpbGxfcCArIDQwKCRzcCkJICNjbGFzcyBkbW92ZSxkbV9y
ZXN0b3JlCSAjIDw+dDEzNjkKICNpbnN0cgoJb3IJJDIwLCQzMSwkMjcJICNj
bGFzcyBkbW92ZSxkbV9yZWdpc3RlcgkgIyA8PnQxMzQ2CgljcHlzCSRmMzEs
JGYzMSwkZjMxCSMgcGFkCgkgIyBzdGFsbCAJMQogI2luc3RyCglhZGRxCSQy
NSwweDQsJDI1CSAjY2xhc3Mgc291cmNlLGNzcGVjCSAjIGxpbmUgMCwgPD50
NjEyLCA8PnQxMzY5LCAweDQoUDY0KQoJYnIJJDMxLEw3MCQzCiAjbWFya190
cmFjZSAzOwpMNjgkMzoKICNpbnN0cgoJbGRsCSQyMiwkMi4xJDJzcGlsbF9w
ICsgMjQoJHNwKQkgI2NsYXNzIGRtb3ZlLGRtX3Jlc3RvcmUJICMgPD50NTg1
CglsZGFoCSQyNywtMzIoJDMxKQkgI2NsYXNzIGRtb3ZlLGRtX2NvbnN0YW50
CSAjIDQyOTI4NzAxNDQoSTMyKQogI2luc3RyCglsZHEJJDE5LCQyLjEkMnNw
aWxsX3AgKyA0MCgkc3ApCSAjY2xhc3MgZG1vdmUsZG1fcmVzdG9yZQkgIyA8
PnQxMzY5CglsZGEJJDI0LDIoJDMxKQkgI2NsYXNzIGRtb3ZlLGRtX2NvbnN0
YW50CSAjIDIoU0k2NCkKICNpbnN0cgoJbGRhaAkkMjMsMzIoJDMxKQkgI2Ns
YXNzIGRtb3ZlLGRtX2NvbnN0YW50CSAjIDIwOTcxNTIoSTMyKQoubG9jIDIg
MjYKCWJlcQkkMjEsTDk1JDMJICNjbGFzcyBzb3VyY2UJICMgbGluZSAyNiwg
PD50NTg0CgkgIyBzdGFsbCAJMQogI2luc3RyCi5sb2MgMiAyNgoJYWRkcQkk
MTksNCwkMjEJICNjbGFzcyBzb3VyY2UsY3NwZWMJICMgbGluZSAyNiwgPD50
MTMzNywgPD50MTM2OSwgNChTSTMyKQoubG9jIDIgMjYKCWJlcQkkMjIsTDk2
JDMJICNjbGFzcyBzb3VyY2UJICMgbGluZSAyNiwgPD50NTg1CiAjaW5zdHIK
LmxvYyAyIDI2CglsZGwJJDIwLDAoJDE5KQkgI2NsYXNzIHNvdXJjZQkgIyBs
aW5lIDI2LCA8PnQxMzQxLCA8PnQxMzY5LCAwKEk2NCkKLmxvYyAyIDI2Cglz
dWJxCSQwLCQyMSwkMTgJICNjbGFzcyBzb3VyY2UJICMgbGluZSAyNiwgPD50
MTMzOCwgPD50MTMzNSwgPD50MTMzNwogI2luc3RyCi5sb2MgMiAyNgoJYWRk
bAkkMTgsMywkMjIJICNjbGFzcyBzb3VyY2UJICMgbGluZSAyNiwgPD50NjQ1
LCA8PnQxMzM4LCAzKFNJMzIpCiAjaW5zdHIKLmxvYyAyIDI2CgljbW92Z2UJ
JDE4LCQxOCwkMjIJICNjbGFzcyBzb3VyY2UJICMgbGluZSAyNiwgPD50NjQ2
LCA8PnQxMzM4LCA8PnQxMzM4LCA8PnQ2NDUKICNpbnN0cgoubG9jIDIgMjYK
CWFuZAkkMjAsJDI3LCQyMAkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDI2LCA8
PnQxMzQyLCA8PnQxMzQxLCA0MjkyODcwMTQ0KEkzMikKICNpbnN0cgoubG9j
IDIgMjYKCXNyYQkkMjIsJDI0LCQyMgkgI2NsYXNzIHNvdXJjZQkgIyBsaW5l
IDI2LCA8PnQxMzM5LCA8PnQ2NDYsIDIoU0k2NCkKICNpbnN0cgoubG9jIDIg
MjYKCWxkYQkkMjMsLTEoJDIzKQkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDI2
LCA8PnQ4NzQsIDIwOTcxNTIoSTMyKSwgLTEoU0k2NCkKICNpbnN0cgoubG9j
IDIgMjYKCWFuZAkkMjIsJDIzLCQyMgkgI2NsYXNzIHNvdXJjZQkgIyBsaW5l
IDI2LCA8PnQxMzQwLCA8PnQxMzM5LCA8PnQ4NzQKICNpbnN0cgoubG9jIDIg
MjYKCW9yCSQyMiwkMjAsJDIwCSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMjYs
IDw+dDEzNDMsIDw+dDEzNDAsIDw+dDEzNDIKLmxvYyAyIDI2CglzdGwJJDIw
LDAoJDE5KQkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDI2LCA8PnQxMzQzLCA8
PnQxMzY5LCAwKEk2NCksIDAoSTMyKSwgMChJMzIpLCAwKEkzMiksIDAoSTMy
KQogI21hcmtfdHJhY2UgNDsKTDk1JDM6CiAjaW5zdHIKCXN0bAkkMjUsJDIu
MSQyc3BpbGxfcCgkc3ApCSAjY2xhc3MgZG1vdmUsZG1fc3BpbGwJICMgPD50
NTg3CgljcHlzCSRmMzEsJGYzMSwkZjMxCSMgcGFkCiAjaW5zdHIKLmxvYyAy
IDI2CglsZHEJJDI3LGludGVycHJldGVyLkxTVkZyZWVMaXN0LjMJICNjbGFz
cyBzb3VyY2UJICMgbGluZSAyNiwgPD50MTMzNiwgPD50NTM2LCBhZGRyKGlu
dGVycHJldGVyLkxTVkZyZWVMaXN0LlZBUi4zKShQNjQpCglsZGEJJDI1LDMo
JDMxKQkgI2NsYXNzIGRtb3ZlLGRtX2NvbnN0YW50CSAjIDMoU0kzMikKICNp
bnN0cgoJbGRxCSQyNCwkMi4xJDJzcGlsbF9wICsgMTYoJHNwKQkgI2NsYXNz
IGRtb3ZlLGRtX3Jlc3RvcmUJICMgPD50NTc3CgkgIyBzdGFsbCAJMQogI2lu
c3RyCi5sb2MgMiAyNgoJc3RxCSQyNywwKCQxNykJICNjbGFzcyBzb3VyY2UJ
ICMgbGluZSAyNiwgPD50MTMzNiwgPD50MTM2OCwgMChJNjQpLCAwKEkzMiks
IDAoSTMyKSwgMChJMzIpLCAwKEkzMikKICNpbnN0cgoubG9jIDIgMjYKCXN0
cQkkMTcsaW50ZXJwcmV0ZXIuTFNWRnJlZUxpc3QuMwkgI2NsYXNzIHNvdXJj
ZQkgIyBsaW5lIDI2LCA8PnQxMzY4LCA8PnQ1MzYsIGFkZHIoaW50ZXJwcmV0
ZXIuTFNWRnJlZUxpc3QuVkFSLjMpKFA2NCksIDAoSTMyKSwgMChJMzIpLCAw
KEkzMiksIDAoSTMyKQoJICMgc3RhbGwgCTEKICNpbnN0cgoJYmVxCSQyNCxM
OTckMwkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDAsIDw+dDU3NwogI2luc3Ry
CglicgkkMzEsTDYyJDMKICNtYXJrX3RyYWNlIDExOwpMOTckMzoKICNpbnN0
cgoJb3IJJDAsJDMxLCQyNAkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDAsIDw+
dDU3NywgPD50MTMzNQoJICMgc3RhbGwgCTEKICNpbnN0cgoJc3RxCSQyNCwk
Mi4xJDJzcGlsbF9wICsgMTYoJHNwKQkgI2NsYXNzIGRtb3ZlLGRtX3NwaWxs
CSAjIDw+dDU3NwogI21hcmtfdHJhY2UgMTA7CiAjaW5zdHIKCWxkYQkkMjUs
MygkMzEpCSAjY2xhc3MgZG1vdmUsZG1fY29uc3RhbnQJICMgMyhTSTMyKQog
I2luc3RyCglicgkkMzEsTDYyJDMKICNtYXJrX3RyYWNlIDIwOwpMOTYkMzoK
ICNpbnN0cgoubG9jIDIgMjYKCXN0cQkkMCwwKCQxOSkJICNjbGFzcyBzb3Vy
Y2UJICMgbGluZSAyNiwgPD50MTMzNSwgPD50MTM2OSwgMChJNjQpLCAwKEkz
MiksIDAoSTMyKSwgMChJMzIpLCAwKEkzMikKICNpbnN0cgoJYnIJJDMxLEw5
NSQzCgliaXMJJDMxLCQzMSwkMzEJIyBwYWQKICNtYXJrX3RyYWNlIDI7Ckw2
NiQzOgogI21hcmtfY2FsbCBjYWxsZXJfc2F2ZXMsIHJlZ3MsIGF0eXBlcygp
LCBydHlwZXMobjY0KTsKICNpbnN0cgoJb3IJJDMxLCQzMSwkMzEJICNjbGFz
cyBkbW92ZSxkbV9yZWdpc3RlcgkgIyA8PnQ1MzMKLmxvYyAyIDI2Cglqc3IJ
JDI2LERZQ19DQUNIRV9jcmVhdGUKCWJyCSQyNixGQUtFMQpGQUtFMToJbGRn
cAkkZ3AsMCgkMjYpCSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMjYsIHJhZGRy
KERZQ19DQUNIRV9jcmVhdGUpKFA2NCksIDw+dDUzMwoJICMgc3RhbGwgCTEK
ICNpbnN0cgoJc3RxCSQwLGludGVycHJldGVyLkNhY2hlLjMJICNjbGFzcyBz
b3VyY2UJICMgbGluZSAwLCA8PnQxMDgzLCA8PnQ1MzYsIGFkZHIoaW50ZXJw
cmV0ZXIuQ2FjaGUuVkFSLjMpKFA2NCksIDAoSTMyKSwgMChJMzIpLCAwKEkz
MiksIDAoSTMyKQoJY3B5cwkkZjMxLCRmMzEsJGYzMQkjIHBhZAogI21hcmtf
dHJhY2UgOTsKICNpbnN0cgoJc3RxCSQwLCQyLjEkMnNwaWxsX3AgKyA1Nigk
c3ApCSAjY2xhc3MgZG1vdmUsZG1fc3BpbGwJICMgPD50MTA4MwoJbGRhCSQx
OCwxKCQzMSkJICNjbGFzcyBkbW92ZSxkbV9jb25zdGFudAkgIyAxKFNJMzIp
CiAjaW5zdHIKCW9yCSQzMSwkMzEsJDMxCSAjY2xhc3MgZG1vdmUsZG1fcmVn
aXN0ZXIJICMgPD50NTMzCglsZHEJJDE3LCQyLjEkMnNwaWxsX3AgKyA0OCgk
c3ApCSAjY2xhc3MgZG1vdmUsZG1fcmVzdG9yZQkgIyA8PnQxMzY4CiAjaW5z
dHIKCW9yCSQwLCQzMSwkMTYJICNjbGFzcyBkbW92ZSxkbV9yZWdpc3Rlcgkg
IyA8PnQxMDgzCiAjaW5zdHIKCWJyCSQzMSxMNjckMwogI21hcmtfdHJhY2Ug
ODsKTDY0JDM6CiAjaW5zdHIKCW9yCSQzMSwkMzEsJDMxCSAjY2xhc3MgZG1v
dmUsZG1fcmVnaXN0ZXIJICMgPD50NTMzCiAjaW5zdHIKCWJyCSQzMSxMNjUk
MwogI21hcmtfdHJhY2UgMzg7Ckw2MyQzOgogI2luc3RyCglpbnRlcnByZXRl
ci5EWUMuR0VSZXR1cm5BZGRyZXNzOmxkcQkkMjcsJDIuMSQyc3BpbGxfcCAr
IDgoJHNwKQkgI2NsYXNzIGRtb3ZlLGRtX3Jlc3RvcmUJICMgPD50MTM3MQog
I2luc3RyCglsZHEJJDAsJDIuMSQyc3BpbGxfcCArIDE2KCRzcCkJICNjbGFz
cyBkbW92ZSxkbV9yZXN0b3JlCSAjIDw+dDU3NwoJICMgc3RhbGwgCTEKaW50
ZXJwcmV0ZXIuRFlDLkdFX1JFVFVSTi4wLjA6CiAjbWFya19yZXR1cm4gcnR5
cGVzKG42NCk7CiAjaW5zdHIKCXJldAkkMzEsKCQyNyksMQkgI2NsYXNzIHNv
dXJjZQkgIyBsaW5lIDAsIDw+dDEzNzEKICNtYXJrX3RyYWNlIDExNDsKTDYx
JDM6CiAjaW5zdHIKCW9yCSQwLCQzMSwkMjQJICNjbGFzcyBzb3VyY2UJICMg
bGluZSAwLCA8PnQ1NzcsIDw+dDEyMzgKCSAjIHN0YWxsIAkxCiAjaW5zdHIK
CXN0cQkkMjQsJDIuMSQyc3BpbGxfcCArIDE2KCRzcCkJICNjbGFzcyBkbW92
ZSxkbV9zcGlsbAkgIyA8PnQ1NzcKICNpbnN0cgoJYnIJJDMxLEw2MiQzCgli
aXMJJDMxLCQzMSwkMzEJIyBwYWQKICNtYXJrX3RyYWNlIDgzOwpMNDkkMzoK
ICNtYXJrX2NhbGwgY2FsbGVyX3NhdmVzLCByZWdzLCBhdHlwZXMoKSwgcnR5
cGVzKG42NCk7CiAjaW5zdHIKCW9yCSQzMSwkMzEsJDMxCSAjY2xhc3MgZG1v
dmUsZG1fcmVnaXN0ZXIJICMgPD50NTMzCi5sb2MgMiAyNgoJanNyCSQyNixE
WUNfQ0FDSEVfY3JlYXRlCglicgkkMjYsRkFLRTI0CkZBS0UyNDoJbGRncAkk
Z3AsMCgkMjYpCSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMjYsIHJhZGRyKERZ
Q19DQUNIRV9jcmVhdGUpKFA2NCksIDw+dDUzMwogI2luc3RyCglzdHEJJDAs
JDIuMSQyc3BpbGxfcCArIDE0NCgkc3ApCSAjY2xhc3MgZG1vdmUsZG1fc3Bp
bGwJICMgPD50MTIzNwoJb3IJJDAsJDMxLCQxNgkgI2NsYXNzIGRtb3ZlLGRt
X3JlZ2lzdGVyCSAjIDw+dDEyMzcKICNpbnN0cgoJc3RxCSQwLGludGVycHJl
dGVyLkNhY2hlLjIJICNjbGFzcyBzb3VyY2UJICMgbGluZSAwLCA8PnQxMjM3
LCA8PnQ1MzYsIGFkZHIoaW50ZXJwcmV0ZXIuQ2FjaGUuVkFSLjIpKFA2NCks
IDAoSTMyKSwgMChJMzIpLCAwKEkzMiksIDAoSTMyKQoJbGRhCSQxOCwxKCQz
MSkJICNjbGFzcyBkbW92ZSxkbV9jb25zdGFudAkgIyAxKFNJMzIpCiAjaW5z
dHIKCW9yCSQzMSwkMzEsJDMxCSAjY2xhc3MgZG1vdmUsZG1fcmVnaXN0ZXIJ
ICMgPD50NTMzCglsZHEJJDE3LCQyLjEkMnNwaWxsX3AgKyAxMzYoJHNwKQkg
I2NsYXNzIGRtb3ZlLGRtX3Jlc3RvcmUJICMgPD50MTIzNAoJICMgc3RhbGwg
CTEKICNpbnN0cgoJYnIJJDMxLEw1MCQzCgliaXMJJDMxLCQzMSwkMzEJIyBw
YWQKICNtYXJrX3RyYWNlIDgyOwpMNDckMzoKICNpbnN0cgoubG9jIDIgMjYK
CWxkcQkkMTcsaW50ZXJwcmV0ZXIuTFNWRnJlZUxpc3QuMgkgI2NsYXNzIHNv
dXJjZQkgIyBsaW5lIDI2LCA8PnQxMjM0LCA8PnQ1MzYsIGFkZHIoaW50ZXJw
cmV0ZXIuTFNWRnJlZUxpc3QuVkFSLjIpKFA2NCkKCW9yCSQzMSwkMzEsJDMx
CSAjY2xhc3MgZG1vdmUsZG1fcmVnaXN0ZXIJICMgPD50NTMzCiAjaW5zdHIK
CWxkcQkkMTYsaW50ZXJwcmV0ZXIuQ2FjaGUuMgkgI2NsYXNzIHNvdXJjZSxy
ZWpvaW5fY29weQkgIyBsaW5lIDAsIDw+dDEyMzcsIDw+dDUzNiwgYWRkcihp
bnRlcnByZXRlci5DYWNoZS5WQVIuMikoUDY0KQoJICMgc3RhbGwgCTEKICNp
bnN0cgoJc3RxCSQxNywkMi4xJDJzcGlsbF9wICsgMTM2KCRzcCkJICNjbGFz
cyBkbW92ZSxkbV9zcGlsbAkgIyA8PnQxMjM0CiAjaW5zdHIKCXN0cQkkMTYs
JDIuMSQyc3BpbGxfcCArIDE0NCgkc3ApCSAjY2xhc3MgZG1vdmUsZG1fc3Bp
bGwJICMgPD50MTIzNwogI2luc3RyCi5sb2MgMiAyNgoJbGRxCSQyNywwKCQx
NykJICNjbGFzcyBzb3VyY2UJICMgbGluZSAyNiwgPD50MTIzNSwgPD50MTIz
NCwgMChJNjQpCgkgIyBzdGFsbCAJMgogI2luc3RyCi5sb2MgMiAyNgoJc3Rx
CSQyNyxpbnRlcnByZXRlci5MU1ZGcmVlTGlzdC4yCSAjY2xhc3Mgc291cmNl
CSAjIGxpbmUgMjYsIDw+dDEyMzUsIDw+dDUzNiwgYWRkcihpbnRlcnByZXRl
ci5MU1ZGcmVlTGlzdC5WQVIuMikoUDY0KSwgMChJMzIpLCAwKEkzMiksIDAo
STMyKSwgMChJMzIpCiAjaW5zdHIKCWJyCSQzMSxMNDgkMwogI21hcmtfdHJh
Y2UgMTU2OwpfJDEuaW50ZXJwcmV0ZXIuVEFHLjAuMi5keWNfY29weS4wOgpp
bnRlcnByZXRlci5keW5fc2V0dXBfYmVnaW5fMTFfMDoKICNpbnN0cgoJc3Rs
CSQxNyxpbnRlcnByZXRlci5ydGNvbnN0XzExXzBfMCgkMzEpCSAjY2xhc3Mg
c291cmNlCSAjIGxpbmUgMCwgPF9vZmZzZXQkMS4yPnQ1MjcsIDB4MChQNjQp
LCBpbnRlcnByZXRlci5ydGNvbnN0XzExXzBfMCwgMChJMzIpLCAwKEkzMiks
IDAoSTMyKSwgMChJMzIpCi5sb2MgMiA0NwoJYWRkbAkkMjIsMSwkMjIJICNj
bGFzcyBzb3VyY2UscmVqb2luX2NvcHkJICMgbGluZSA0NywgPF9wYyQxLjE+
dDQ1NCwgPF9wYyQxLjE+dDQ1NCwgMShTSTMyKQogI2luc3RyCglzdGwJJDIy
LCQyLjEkMnNwaWxsX3AgKyA5Nigkc3ApCSAjY2xhc3MgZG1vdmUsZG1fc3Bp
bGwJICMgPF9wYyQxLjE+dDQ1NAoJb3IJJDMxLCQzMSwkMzEJICNjbGFzcyBk
bW92ZSxkbV9yZWdpc3RlcgkgIyA8PnQ1MzMKaW50ZXJwcmV0ZXIuZHluX3Nl
dHVwX2VuZF8xMV8wOgogI2luc3RyCglicgkkMzEsTDQ2JDMKCWJpcwkkMzEs
JDMxLCQzMQkjIHBhZAogI21hcmtfdHJhY2UgMTUwOwpfJDEuaW50ZXJwcmV0
ZXIuVEFHLjAuMS5keWNfY29weS4wOgppbnRlcnByZXRlci5keW5fc2V0dXBf
YmVnaW5fMTBfMDoKICNpbnN0cgoJc3RsCSQxNyxpbnRlcnByZXRlci5ydGNv
bnN0XzEwXzBfMCgkMzEpCSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMCwgPF9v
ZmZzZXQkMS4yPnQ1MjcsIDB4MChQNjQpLCBpbnRlcnByZXRlci5ydGNvbnN0
XzEwXzBfMCwgMChJMzIpLCAwKEkzMiksIDAoSTMyKSwgMChJMzIpCi5sb2Mg
MiA0NwoJYWRkbAkkMjIsMSwkMjIJICNjbGFzcyBzb3VyY2UscmVqb2luX2Nv
cHkJICMgbGluZSA0NywgPF9wYyQxLjE+dDQ1NCwgPF9wYyQxLjE+dDQ1NCwg
MShTSTMyKQogI2luc3RyCglzdGwJJDIyLCQyLjEkMnNwaWxsX3AgKyA5Nigk
c3ApCSAjY2xhc3MgZG1vdmUsZG1fc3BpbGwJICMgPF9wYyQxLjE+dDQ1NAoJ
b3IJJDMxLCQzMSwkMzEJICNjbGFzcyBkbW92ZSxkbV9yZWdpc3RlcgkgIyA8
PnQ1MzMKaW50ZXJwcmV0ZXIuZHluX3NldHVwX2VuZF8xMF8wOgogI2luc3Ry
CglicgkkMzEsTDQ2JDMKCWJpcwkkMzEsJDMxLCQzMQkjIHBhZAogI21hcmtf
dHJhY2UgMTU1OwpfJDEuaW50ZXJwcmV0ZXIuVEFHLjAuMC5keWNfY29weS4w
OgppbnRlcnByZXRlci5keW5fc2V0dXBfYmVnaW5fOV8wOgogI2luc3RyCglz
dGwJJDE3LGludGVycHJldGVyLnJ0Y29uc3RfOV8wXzAoJDMxKQkgI2NsYXNz
IHNvdXJjZQkgIyBsaW5lIDAsIDxfb2Zmc2V0JDEuMj50NTI3LCAweDAoUDY0
KSwgaW50ZXJwcmV0ZXIucnRjb25zdF85XzBfMCwgMChJMzIpLCAwKEkzMiks
IDAoSTMyKSwgMChJMzIpCi5sb2MgMiA0NwoJYWRkbAkkMjIsMSwkMjIJICNj
bGFzcyBzb3VyY2UscmVqb2luX2NvcHkJICMgbGluZSA0NywgPF9wYyQxLjE+
dDQ1NCwgPF9wYyQxLjE+dDQ1NCwgMShTSTMyKQogI2luc3RyCglzdGwJJDIy
LCQyLjEkMnNwaWxsX3AgKyA5Nigkc3ApCSAjY2xhc3MgZG1vdmUsZG1fc3Bp
bGwJICMgPF9wYyQxLjE+dDQ1NAoJb3IJJDMxLCQzMSwkMzEJICNjbGFzcyBk
bW92ZSxkbV9yZWdpc3RlcgkgIyA8PnQ1MzMKaW50ZXJwcmV0ZXIuZHluX3Nl
dHVwX2VuZF85XzA6CiAjaW5zdHIKCWJyCSQzMSxMNDYkMwoJYmlzCSQzMSwk
MzEsJDMxCSMgcGFkCiAjbWFya190cmFjZSAxOTU7Ckw0NCQzOgppbnRlcnBy
ZXRlci5keW5fc2V0dXBfYmVnaW5fNV8wOgogI2luc3RyCglzdHEJJDMxLER5
Q1JUX0R1bW15R2xvYmFsCSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMCwgMHgw
KFA2NCksIDw+dDUzNiwgYWRkcihfRHlDUlRfRHVtbXlHbG9iYWwkMS45KShQ
NjQpLCAwKEkzMiksIDAoSTMyKSwgMChJMzIpLCAwKEkzMikKLmxvYyAyIDQ1
CglzNGFkZGwJJDE5LCQzMSwkMTYJICNjbGFzcyBzb3VyY2UscmVqb2luX2Nv
cHkJICMgbGluZSA0NSwgPD50NTQ0LCA8X3J0JDEuMj50NTI5LCAwKEk2NCkK
ICNpbnN0cgoubG9jIDIgNDcKCWFkZGwJJDIyLDEsJDIyCSAjY2xhc3Mgc291
cmNlLHJlam9pbl9jb3B5CSAjIGxpbmUgNDcsIDxfcGMkMS4xPnQ0NTQsIDxf
cGMkMS4xPnQ0NTQsIDEoU0kzMikKCXN0bAkkMjIsJDIuMSQyc3BpbGxfcCAr
IDk2KCRzcCkJICNjbGFzcyBkbW92ZSxkbV9zcGlsbAkgIyA8X3BjJDEuMT50
NDU0CiAjaW5zdHIKCXN0cQkkMzEsRHlDUlRfRHVtbXlHbG9iYWwJICNjbGFz
cyBzb3VyY2UJICMgbGluZSAwLCAweDAoUDY0KSwgPD50NTM2LCBhZGRyKF9E
eUNSVF9EdW1teUdsb2JhbCQxLjkpKFA2NCksIDAoSTMyKSwgMChJMzIpLCAw
KEkzMiksIDAoSTMyKQoJb3IJJDMxLCQzMSwkMzEJICNjbGFzcyBkbW92ZSxk
bV9yZWdpc3RlcgkgIyA8PnQ1MzMKaW50ZXJwcmV0ZXIuZHluX3NldHVwX2Vu
ZF81XzA6CiAjaW5zdHIKCWJyCSQzMSxMNDUkMwoJYmlzCSQzMSwkMzEsJDMx
CSMgcGFkCiAjbWFya190cmFjZSA0NDsKXyQxLmludGVycHJldGVyLlRBRy44
LjUuZHljX2NvcHkuMDoKaW50ZXJwcmV0ZXIuZHluX3NldHVwX2JlZ2luXzc1
XzA6CiAjaW5zdHIKCXN0bAkkMTcsJDIuMSQyc3BpbGxfcCArIDE2OCgkc3Ap
CSAjY2xhc3MgZG1vdmUsZG1fc3BpbGwJICMgPF9vZmZzZXQkMS4yPnQ1MjcK
LmxvYyAyIDEwNwoJb3IJJDE3LCQzMSwkMjIJICNjbGFzcyBzb3VyY2UJICMg
bGluZSAxMDcsIDxfcGMkMS4xPnQ0NTQsIDxfb2Zmc2V0JDEuMj50NTI3CiAj
aW5zdHIKCW9yCSQzMSwkMzEsJDMxCSAjY2xhc3MgZG1vdmUsZG1fcmVnaXN0
ZXIJICMgPD50NTMzCiAjaW5zdHIKCXN0bAkkMjIsJDIuMSQyc3BpbGxfcCAr
IDk2KCRzcCkJICNjbGFzcyBkbW92ZSxkbV9zcGlsbAkgIyA8X3BjJDEuMT50
NDU0CiAjbWFya19jYWxsIGNhbGxlcl9zYXZlcywgcmVncywgYXR5cGVzKCks
IHJ0eXBlcygpOwogI2luc3RyCgliaXMJJDMxLCQzMSwkMzEJIyBwYWQKLmxv
YyAyIDI2Cglqc3IJJDI2LER5Q1JUX1BhdGNoSW50cmFVbml0QnJhbmNoZXMK
CWJyCSQyNixGQUtFMTAKRkFLRTEwOglsZGdwCSRncCwwKCQyNikJICNjbGFz
cyBzb3VyY2UJICMgbGluZSAyNiwgcmFkZHIoRHlDUlRfUGF0Y2hJbnRyYVVu
aXRCcmFuY2hlcykoUDY0KSwgPD50NTMzCiAjaW5zdHIKCXN0cQkkMzEsRHlD
UlRfQ29kZUxvY2F0aW9uCSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMCwgMHgw
KFA2NCksIDw+dDUzNiwgYWRkcihfRHlDUlRfQ29kZUxvY2F0aW9uJDEuMCko
UDY0KSwgMChJMzIpLCAwKEkzMiksIDAoSTMyKSwgMChJMzIpCglsZGEJJDE4
LDEoJDMxKQkgI2NsYXNzIGRtb3ZlLGRtX2NvbnN0YW50CSAjIDEoU0kzMikK
ICNpbnN0cgoJbGRxCSQyMSxEeUNSVF9MYXN0QnJhbmNoCSAjY2xhc3Mgc291
cmNlCSAjIGxpbmUgMCwgPD50NTc4LCA8PnQ1MzYsIGFkZHIoX0R5Q1JUX0xh
c3RCcmFuY2gkMS4wKShQNjQpCglvcgkkMzEsJDMxLCQzMQkgI2NsYXNzIGRt
b3ZlLGRtX3JlZ2lzdGVyCSAjIDw+dDUzMwogI2luc3RyCi5sb2MgMiAyNgoJ
bGRxCSQyMCxpbnRlcnByZXRlci5MU1ZGcmVlTGlzdC4yCSAjY2xhc3Mgc291
cmNlCSAjIGxpbmUgMjYsIDw+dDI5NCwgPD50NTM2LCBhZGRyKGludGVycHJl
dGVyLkxTVkZyZWVMaXN0LlZBUi4yKShQNjQpCiAjaW5zdHIKCWxkbAkkMTks
JDIuMSQyc3BpbGxfcCArIDE2OCgkc3ApCSAjY2xhc3MgZG1vdmUsZG1fcmVz
dG9yZQkgIyA8X29mZnNldCQxLjI+dDUyNwogI2luc3RyCglzdHEJJDIxLCQy
LjEkMnNwaWxsX3AgKyAxNzYoJHNwKQkgI2NsYXNzIGRtb3ZlLGRtX3NwaWxs
CSAjIDw+dDU3OAoJY3B5cwkkZjMxLCRmMzEsJGYzMQkjIHBhZAppbnRlcnBy
ZXRlci5keW5fc2V0dXBfZW5kXzc1XzA6CiAjaW5zdHIKCWxkcQkkMjMsJDIu
MSQyc3BpbGxfcCArIDg4KCRzcCkJICNjbGFzcyBkbW92ZSxkbV9yZXN0b3Jl
CSAjIDxfYnl0ZWNvZGVzJDEuMT50NDU1Ci5sb2MgMiAyNgoJYm5lCSQyMCxM
OTgkMwkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDI2LCA8PnQyOTQKICNpbnN0
cgoubG9jIDIgMjYKCWxkcQkkMTcsRHlDUlRfVGVtcExvY2F0aW9uCSAjY2xh
c3Mgc291cmNlCSAjIGxpbmUgMjYsIDw+dDU4MiwgPD50NTM2LCBhZGRyKF9E
eUNSVF9UZW1wTG9jYXRpb24kMS4wKShQNjQpCiAjaW5zdHIKCWxkcQkkMTYs
aW50ZXJwcmV0ZXIuQ2FjaGUuMgkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDAs
IDw+dDU3NCwgPD50NTM2LCBhZGRyKGludGVycHJldGVyLkNhY2hlLlZBUi4y
KShQNjQpCgkgIyBzdGFsbCAJMQogI2luc3RyCglzdHEJJDE3LCQyLjEkMnNw
aWxsX3AgKyAxODQoJHNwKQkgI2NsYXNzIGRtb3ZlLGRtX3NwaWxsCSAjIDw+
dDU4MgoubG9jIDIgMjYKCWFkZHEJJDE3LDE2LCQyMQkgI2NsYXNzIHNvdXJj
ZQkgIyBsaW5lIDI2LCA8X0R5Q1JUX1RlbXBMb2NhdGlvbiQxLjA+dDI5OCwg
PD50NTgyLCAxNihJMzIpCiAjaW5zdHIKCXN0cQkkMTYsJDIuMSQyc3BpbGxf
cCArIDE5Migkc3ApCSAjY2xhc3MgZG1vdmUsZG1fc3BpbGwJICMgPD50NTc0
CiAjaW5zdHIKLmxvYyAyIDI2CglzdHEJJDIxLER5Q1JUX1RlbXBMb2NhdGlv
bgkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDI2LCA8X0R5Q1JUX1RlbXBMb2Nh
dGlvbiQxLjA+dDI5OCwgPD50NTM2LCBhZGRyKF9EeUNSVF9UZW1wTG9jYXRp
b24kMS4wKShQNjQpLCAwKEkzMiksIDAoSTMyKSwgMChJMzIpLCAwKEkzMikK
TDk5JDM6CiAjaW5zdHIKCXN0bAkkMTksMCgkMTcpCSAjY2xhc3Mgc291cmNl
CSAjIGxpbmUgMCwgPF9vZmZzZXQkMS4yPnQ1MjcsIDw+dDU4MiwgMChTSTMy
KSwgMChJMzIpLCAwKEkzMiksIDAoSTMyKSwgMChJMzIpCiAjaW5zdHIKCXN0
bAkkMzEsNCgkMTcpCSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMCwgMChTSTMy
KSwgPD50NTgyLCA0KFNJMzIpLCAwKEkzMiksIDAoSTMyKSwgMChJMzIpLCAw
KEkzMikKICNpbnN0cgoJc3RxCSQyMyw4KCQxNykJICNjbGFzcyBzb3VyY2UJ
ICMgbGluZSAwLCA8X2J5dGVjb2RlcyQxLjE+dDQ1NSwgPD50NTgyLCA4KFNJ
MzIpLCAwKEkzMiksIDAoSTMyKSwgMChJMzIpLCAwKEkzMikKCSAjIHN0YWxs
IAkxCiAjaW5zdHIKCWJlcQkkMTYsTDEwMCQzCSAjY2xhc3Mgc291cmNlCSAj
IGxpbmUgMCwgPD50NTc0CkwxMDEkMzoKICNtYXJrX2NhbGwgY2FsbGVyX3Nh
dmVzLCByZWdzLCBhdHlwZXMobjY0LG42NCxuMzIpLCBydHlwZXMobjY0KTsK
ICNpbnN0cgoJYmlzCSQzMSwkMzEsJDMxCSMgcGFkCi5sb2MgMiAyNgoJanNy
CSQyNixEWUNfQ0FDSEVfbG9va3VwCglicgkkMjYsRkFLRTExCkZBS0UxMToJ
bGRncAkkZ3AsMCgkMjYpCSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMjYsIHJh
ZGRyKERZQ19DQUNIRV9sb29rdXApKFA2NCksIDw+dDUzMywgPD50NTc0LCA8
PnQ1ODIsIDEoU0kzMikKICNpbnN0cgoJbGRsCSQyNSwkMi4xJDJzcGlsbF9w
KCRzcCkJICNjbGFzcyBkbW92ZSxkbV9yZXN0b3JlCSAjIDw+dDU4NwoubG9j
IDIgMjYKCXN1YnEJJDMxLDMyLCQyMQkgI2NsYXNzIHNvdXJjZSxjc3BlYwkg
IyBsaW5lIDI2LCA8X0FsaWduZWRBZGRyZXNzJDEuNTg+dDczNSwgMChJNjQp
LCAzMihTSTY0KQogI2luc3RyCglsZHEJJDIwLCQyLjEkMnNwaWxsX3AgKyAx
NzYoJHNwKQkgI2NsYXNzIGRtb3ZlLGRtX3Jlc3RvcmUJICMgPD50NTc4Cgls
ZGEJJDE4LDEoJDMxKQkgI2NsYXNzIGRtb3ZlLGRtX2NvbnN0YW50CSAjIDEo
U0kzMikKICNpbnN0cgoJbGRxCSQyNCwkMi4xJDJzcGlsbF9wICsgMTYoJHNw
KQkgI2NsYXNzIGRtb3ZlLGRtX3Jlc3RvcmUJICMgPD50NTc3CglibmUJJDAs
TDEwMiQzCSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMCwgPD50MTA1NAogI2lu
c3RyCi5sb2MgMiAyNgoJbGRxCSQxNCxEeUNSVF9Db2RlTG9jYXRpb24JICNj
bGFzcyBzb3VyY2UJICMgbGluZSAyNiwgPD50NTgzLCA8PnQ1MzYsIGFkZHIo
X0R5Q1JUX0NvZGVMb2NhdGlvbiQxLjApKFA2NCkKCW9yCSQzMSwkMzEsJDMx
CSAjY2xhc3MgZG1vdmUsZG1fcmVnaXN0ZXIJICMgPD50NTMzCiAjaW5zdHIK
CWFkZHEJJDIwLDB4NCwkMjAJICNjbGFzcyBzb3VyY2UsY3NwZWMJICMgbGlu
ZSAwLCA8PnQ2MDUsIDw+dDU3OCwgMHg0KFA2NCkKCWxkcQkkMTcsJDIuMSQy
c3BpbGxfcCArIDE4NCgkc3ApCSAjY2xhc3MgZG1vdmUsZG1fcmVzdG9yZQkg
IyA8PnQ1ODIKICNpbnN0cgoJb3IJJDMxLCQzMSwkMTMJICNjbGFzcyBzb3Vy
Y2UsY3NwZWMJICMgbGluZSAwLCA8PnQ1ODcsIDAoSTMyKQoubG9jIDIgMjYK
CWJlcQkkMjUsTDEwMyQzCSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMjYsIDw+
dDU4NwogI2luc3RyCi5sb2MgMiAyNgoJbGRxCSQxMixEeUNSVF9QYWRkZWRC
eXRlcwkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDI2LCA8X0R5Q1JUX1BhZGRl
ZEJ5dGVzJDEuMD50Mjc1LCA8PnQ1MzYsIGFkZHIoX0R5Q1JUX1BhZGRlZEJ5
dGVzJDEuMCkoUDY0KQoubG9jIDIgMjYKCWFkZHEJJDE0LDYzLCQxMQkgI2Ns
YXNzIHNvdXJjZQkgIyBsaW5lIDI2LCA8PnQyNzMsIDw+dDU4MywgNjMoU0k2
NCkKICNpbnN0cgoJc3RsCSQxMywkMi4xJDJzcGlsbF9wKCRzcCkJICNjbGFz
cyBkbW92ZSxkbV9zcGlsbAkgIyA8PnQ1ODcKLmxvYyAyIDI2CglhbmQJJDEx
LCQyMSwkMjEJICNjbGFzcyBzb3VyY2UJICMgbGluZSAyNiwgPF9BbGlnbmVk
QWRkcmVzcyQxLjU4PnQ1NTgsIDw+dDI3MywgPF9BbGlnbmVkQWRkcmVzcyQx
LjU4PnQ3MzUKICNpbnN0cgoubG9jIDIgMjYKCXN1YnEJJDIxLCQxNCwkMTQJ
ICNjbGFzcyBzb3VyY2UJICMgbGluZSAyNiwgPF9EeUNSVF9QYWRkZWRCeXRl
cyQxLjA+dDczNiwgPF9BbGlnbmVkQWRkcmVzcyQxLjU4PnQ1NTgsIDw+dDU4
MwoJbGRxCSQxNiwkMi4xJDJzcGlsbF9wICsgMTkyKCRzcCkJICNjbGFzcyBk
bW92ZSxkbV9yZXN0b3JlCSAjIDw+dDU3NAogI2luc3RyCi5sb2MgMiAyNgoJ
YWRkcQkkMTQsJDEyLCQxMgkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDI2LCA8
X0R5Q1JUX1BhZGRlZEJ5dGVzJDEuMD50Mjc4LCA8X0R5Q1JUX1BhZGRlZEJ5
dGVzJDEuMD50NzM2LCA8X0R5Q1JUX1BhZGRlZEJ5dGVzJDEuMD50Mjc1Ci5s
b2MgMiAyNgoJc3RxCSQxMixEeUNSVF9QYWRkZWRCeXRlcwkgI2NsYXNzIHNv
dXJjZQkgIyBsaW5lIDI2LCA8X0R5Q1JUX1BhZGRlZEJ5dGVzJDEuMD50Mjc4
LCA8PnQ1MzYsIGFkZHIoX0R5Q1JUX1BhZGRlZEJ5dGVzJDEuMCkoUDY0KSwg
MChJMzIpLCAwKEkzMiksIDAoSTMyKSwgMChJMzIpCiAjaW5zdHIKLmxvYyAy
IDI2CglvcgkkMjEsJDMxLCQyMQkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDI2
LCA8PnQ1ODMsIDxfQWxpZ25lZEFkZHJlc3MkMS41OD50NTU4CgkgIyBzdGFs
bCAJMQpMMTA0JDM6CiAjaW5zdHIKCWNtcGVxCSQyMSwkMjAsJDIwCSAjY2xh
c3Mgc291cmNlCSAjIGxpbmUgMCwgPD50NzM0LCA8PnQ1ODMsIDw+dDYwNQoJ
ICMgc3RhbGwgCTEKICNpbnN0cgoJYmVxCSQyMCxMMTA1JDMJICNjbGFzcyBz
b3VyY2UJICMgbGluZSAwLCA8PnQ3MzQKICNpbnN0cgoJbGRxCSQxOSwkMi4x
JDJzcGlsbF9wICsgMTc2KCRzcCkJICNjbGFzcyBzb3VyY2UJICMgbGluZSAw
LCA8PnQ1ODMsIDw+dDU3OAoJICMgc3RhbGwgCTEKICNpbnN0cgoJYmVxCSQy
NCxMMTA2JDMJICNjbGFzcyBzb3VyY2UJICMgbGluZSAwLCA8PnQ1NzcKTDEw
NyQzOgogI2luc3RyCglzdHEJJDE5LCQyLjEkMnNwaWxsX3AgKyAyMDAoJHNw
KQkgI2NsYXNzIGRtb3ZlLGRtX3NwaWxsCSAjIDw+dDU4MwogI21hcmtfY2Fs
bCBjYWxsZXJfc2F2ZXMsIHJlZ3MsIGF0eXBlcyhuNjQsbjY0LG4zMixuNjQp
LCBydHlwZXMoKTsKICNpbnN0cgoJYmlzCSQzMSwkMzEsJDMxCSMgcGFkCi5s
b2MgMiAyNgoJanNyCSQyNixEWUNfQ0FDSEVfaW5zZXJ0CglicgkkMjYsRkFL
RTEyCkZBS0UxMjoJbGRncAkkZ3AsMCgkMjYpCSAjY2xhc3Mgc291cmNlCSAj
IGxpbmUgMjYsIHJhZGRyKERZQ19DQUNIRV9pbnNlcnQpKFA2NCksIDw+dDUz
MywgPD50NTc0LCA8PnQ1ODIsIDEoU0kzMiksIDw+dDU4MwogI2luc3RyCgls
ZHEJJDE0LCQyLjEkMnNwaWxsX3AgKyAyMDAoJHNwKQkgI2NsYXNzIGRtb3Zl
LGRtX3Jlc3RvcmUJICMgPD50NTgzCglsZGFoCSQyNywxKCQzMSkJICNjbGFz
cyBkbW92ZSxkbV9jb25zdGFudAkgIyA2NTUzNihJMzIpCiAjaW5zdHIKCWxk
cQkkMjEsRHlDUlRfU3RhdGljVmFsdWVUYWJsZQkgI2NsYXNzIHNvdXJjZQkg
IyBsaW5lIDAsIDw+dDEwNDYsIDw+dDUzNiwgYWRkcihfRHlDUlRfU3RhdGlj
VmFsdWVUYWJsZSQxLjApKFA2NCkKCWxkYQkkMTksMSgkMzEpCSAjY2xhc3Mg
ZG1vdmUsZG1fY29uc3RhbnQJICMgMShJMzIpCgkgIyBzdGFsbCAJMQogI2lu
c3RyCglzdHEJJDE0LER5Q1JUX1N0aXRjaExvY2F0aW9uCSAjY2xhc3Mgc291
cmNlCSAjIGxpbmUgMCwgPD50NTgzLCA8PnQ1MzYsIGFkZHIoX0R5Q1JUX1N0
aXRjaExvY2F0aW9uJDEuMCkoUDY0KSwgMChJMzIpLCAwKEkzMiksIDAoSTMy
KSwgMChJMzIpCgkgIyBzdGFsbCAJMQogI2luc3RyCgliZXEJJDIxLEwxMDgk
MwkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDAsIDw+dDEwNDYKICNpbnN0cgoJ
bGRsCSQyMSxEeUNSVF9TVlRJbmRleAkgI2NsYXNzIHNvdXJjZQkgIyBsaW5l
IDAsIDw+dDEwNDUsIDw+dDUzNiwgYWRkcihfRHlDUlRfU1ZUSW5kZXgkMS4w
KShQNjQpCgkgIyBzdGFsbCAJMgogI2luc3RyCglhZGRsCSQyMSwyMTYsJDIx
CSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMCwgPD50NTg5LCA8PnQxMDQ1LCAy
MTYoU0kzMikKICNpbnN0cgoJY21wbGUJJDIxLCQyNywkMjAJICNjbGFzcyBz
b3VyY2UJICMgbGluZSAwLCA8PnQ3NDIsIDw+dDU4OSwgNjU1MzYoSTMyKQoJ
ICMgc3RhbGwgCTEKICNpbnN0cgoJYmVxCSQyMCxMMTA4JDMJICNjbGFzcyBz
b3VyY2UJICMgbGluZSAwLCA8PnQ3NDIKICNpbnN0cgoJc3RsCSQxOSxEeUNS
VF9CdWlsZFRhYmxlUG9pbnRlcgkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDAs
IDEoSTMyKSwgPD50NTM2LCBhZGRyKF9EeUNSVF9CdWlsZFRhYmxlUG9pbnRl
ciQxLjApKFA2NCksIDAoSTMyKSwgMChJMzIpLCAwKEkzMiksIDAoSTMyKQoJ
Y3B5cwkkZjMxLCRmMzEsJGYzMQkjIHBhZAogI21hcmtfdHJhY2UgMTczOwog
I2luc3RyCglsZGFoCSQxNywxKCQzMSkJICNjbGFzcyBkbW92ZSxkbV9jb25z
dGFudAkgIyA2NTUzNihJMzIpCglsZGwJJDIyLCQyLjEkMnNwaWxsX3AgKyA5
Nigkc3ApCSAjY2xhc3MgZG1vdmUsZG1fcmVzdG9yZQkgIyA8X3BjJDEuMT50
NDU0CiAjaW5zdHIKCWxkYQkkMTgsMTEoJDMxKQkgI2NsYXNzIGRtb3ZlLGRt
X2NvbnN0YW50CSAjIDExKFNJNjQpCiAjaW5zdHIKCWxkYQkkMTksMTYoJDMx
KQkgI2NsYXNzIGRtb3ZlLGRtX2NvbnN0YW50CSAjIDE2KFNJNjQpCiAjaW5z
dHIKCWxkYQkkMjAsMjEoJDMxKQkgI2NsYXNzIGRtb3ZlLGRtX2NvbnN0YW50
CSAjIDIxKFNJNjQpCgljcHlzCSRmMzEsJGYzMSwkZjMxCSMgcGFkCiAjaW5z
dHIKCWxkYQkkMjEsNCgkMzEpCSAjY2xhc3MgZG1vdmUsZG1fY29uc3RhbnQJ
ICMgNChJNjQpCglsZHEJJDIzLCQyLjEkMnNwaWxsX3AgKyA4OCgkc3ApCSAj
Y2xhc3MgZG1vdmUsZG1fcmVzdG9yZQkgIyA8X2J5dGVjb2RlcyQxLjE+dDQ1
NQogI2luc3RyCglsZGEJJDE2LDI2KCQzMSkJICNjbGFzcyBkbW92ZSxkbV9j
b25zdGFudAkgIyAyNihTSTY0KQoJYnIJJDMxLEwxMDkkMwogI21hcmtfdHJh
Y2UgNzk7CkwxMDgkMzoKICNpbnN0cgoubG9jIDIgMjYKCWxkcQkkMTUsRHlD
UlRfVGFibGVMb2NhdGlvbgkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDI2LCA8
PnQxMDQ0LCA8PnQ1MzYsIGFkZHIoX0R5Q1JUX1RhYmxlTG9jYXRpb24kMS4w
KShQNjQpCglsZGFoCSQxNywxKCQzMSkJICNjbGFzcyBkbW92ZSxkbV9jb25z
dGFudAkgIyA2NTUzNihJMzIpCiAjaW5zdHIKLmxvYyAyIDI2CglsZGwJJDEx
LER5Q1JUX1RhYmxlUG9pbnRlckluZGV4CSAjY2xhc3Mgc291cmNlCSAjIGxp
bmUgMjYsIDxfRHlDUlRfVGFibGVQb2ludGVySW5kZXgkMS4wPnQyMzYsIDw+
dDUzNiwgYWRkcihfRHlDUlRfVGFibGVQb2ludGVySW5kZXgkMS4wKShQNjQp
Ci5sb2MgMiAyNgoJbGRhCSQ4LER5Q1JUX1RhYmxlUG9pbnRlcnMrOAkgI2Ns
YXNzIHNvdXJjZQkgIyBsaW5lIDI2LCA8PnQ3NDgsIDw+dDUzNiwgKGFkZHIo
X0R5Q1JUX1RhYmxlUG9pbnRlcnMkMS4wKShQNjQpICsgMHg4KEk2NCkpKFA2
NCkKICNpbnN0cgoJbGRhCSQ3LC0zMjc2OCgkMTcpCSAjY2xhc3Mgc291cmNl
CSAjIGxpbmUgMCwgPD50NzQ1LCA2NTUzNihJMzIpLCAtMzI3NjgoU0k2NCkK
CXN0bAkkMTksRHlDUlRfQnVpbGRUYWJsZVBvaW50ZXIJICNjbGFzcyBzb3Vy
Y2UJICMgbGluZSAwLCAxKEkzMiksIDw+dDUzNiwgYWRkcihfRHlDUlRfQnVp
bGRUYWJsZVBvaW50ZXIkMS4wKShQNjQpLCAwKEkzMiksIDAoSTMyKSwgMChJ
MzIpLCAwKEkzMikKICNpbnN0cgoJYWRkcQkkMTUsJDcsJDYJICNjbGFzcyBz
b3VyY2UJICMgbGluZSAwLCA8PnQ1NzYsIDw+dDEwNDQsIDw+dDc0NQoJc3Rx
CSQ2LER5Q1JUX1N0YXRpY1ZhbHVlVGFibGUJICNjbGFzcyBzb3VyY2UJICMg
bGluZSAwLCA8PnQ1NzYsIDw+dDUzNiwgYWRkcihfRHlDUlRfU3RhdGljVmFs
dWVUYWJsZSQxLjApKFA2NCksIDAoSTMyKSwgMChJMzIpLCAwKEkzMiksIDAo
STMyKQogI2luc3RyCi5sb2MgMiAyNgoJYWRkcQkkMTEsJDgsJDgJICNjbGFz
cyBzb3VyY2UJICMgbGluZSAyNiwgPD50MTEwNywgPF9EeUNSVF9UYWJsZVBv
aW50ZXJJbmRleCQxLjA+dDIzNiwgPD50NzQ4CglzdHEJJDMxLER5Q1JUX1NW
VEluZGV4CSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMCwgMHgwKFA2NCksIDw+
dDUzNiwgYWRkcihfRHlDUlRfU1ZUSW5kZXgkMS4wKShQNjQpLCAwKEkzMiks
IDAoSTMyKSwgMChJMzIpLCAwKEkzMikKICNpbnN0cgoubG9jIDIgMjYKCWFk
ZHEJJDE1LDY1NTM2LCQxNQkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDI2LCA8
X0R5Q1JUX1RhYmxlTG9jYXRpb24kMS4wPnQyODcsIDw+dDEwNDQsIDY1NTM2
KEkzMikKLmxvYyAyIDI2CglzdHEJJDE1LER5Q1JUX1RhYmxlTG9jYXRpb24J
ICNjbGFzcyBzb3VyY2UJICMgbGluZSAyNiwgPF9EeUNSVF9UYWJsZUxvY2F0
aW9uJDEuMD50Mjg3LCA8PnQ1MzYsIGFkZHIoX0R5Q1JUX1RhYmxlTG9jYXRp
b24kMS4wKShQNjQpLCAwKEkzMiksIDAoSTMyKSwgMChJMzIpLCAwKEkzMikK
ICNpbnN0cgoubG9jIDIgMjYKCXN0cQkkNiwwKCQ4KQkgI2NsYXNzIHNvdXJj
ZQkgIyBsaW5lIDI2LCA8PnQ1NzYsIDw+dDExMDcsIDAoSTY0KSwgMChJMzIp
LCAwKEkzMiksIDAoSTMyKSwgMChJMzIpCi5sb2MgMiAyNgoJYWRkbAkkMTEs
OCwkMTEJICNjbGFzcyBzb3VyY2UJICMgbGluZSAyNiwgPF9EeUNSVF9UYWJs
ZVBvaW50ZXJJbmRleCQxLjA+dDExMTAsIDxfRHlDUlRfVGFibGVQb2ludGVy
SW5kZXgkMS4wPnQyMzYsIDgoSTMyKQogI2luc3RyCi5sb2MgMiAyNgoJc3Rs
CSQxMSxEeUNSVF9UYWJsZVBvaW50ZXJJbmRleAkgI2NsYXNzIHNvdXJjZQkg
IyBsaW5lIDI2LCA8X0R5Q1JUX1RhYmxlUG9pbnRlckluZGV4JDEuMD50MTEx
MCwgPD50NTM2LCBhZGRyKF9EeUNSVF9UYWJsZVBvaW50ZXJJbmRleCQxLjAp
KFA2NCksIDAoSTMyKSwgMChJMzIpLCAwKEkzMiksIDAoSTMyKQoJbGRhCSQy
MSw0KCQzMSkJICNjbGFzcyBkbW92ZSxkbV9jb25zdGFudAkgIyA0KEk2NCkK
ICNpbnN0cgoubG9jIDIgMjYKCWxkcQkkMTUsRHlDUlRfV29ya0xpc3QJICNj
bGFzcyBzb3VyY2UJICMgbGluZSAyNiwgPF9EeUNfVGVtcCQxLjQ4PnQ0NzIs
IDw+dDUzNiwgYWRkcihfRHlDUlRfV29ya0xpc3QkMS4wKShQNjQpCglsZGEJ
JDIwLDIxKCQzMSkJICNjbGFzcyBkbW92ZSxkbV9jb25zdGFudAkgIyAyMShT
STY0KQogI2luc3RyCglsZGwJJDIyLCQyLjEkMnNwaWxsX3AgKyA5Nigkc3Ap
CSAjY2xhc3MgZG1vdmUsZG1fcmVzdG9yZQkgIyA8X3BjJDEuMT50NDU0Cgls
ZGEJJDE5LDE2KCQzMSkJICNjbGFzcyBkbW92ZSxkbV9jb25zdGFudAkgIyAx
NihTSTY0KQogI2luc3RyCglsZHEJJDIzLCQyLjEkMnNwaWxsX3AgKyA4OCgk
c3ApCSAjY2xhc3MgZG1vdmUsZG1fcmVzdG9yZQkgIyA8X2J5dGVjb2RlcyQx
LjE+dDQ1NQoJbGRhCSQxOCwxMSgkMzEpCSAjY2xhc3MgZG1vdmUsZG1fY29u
c3RhbnQJICMgMTEoU0k2NCkKICNpbnN0cgoJbGRhCSQxNiwyNigkMzEpCSAj
Y2xhc3MgZG1vdmUsZG1fY29uc3RhbnQJICMgMjYoU0k2NCkKLmxvYyAyIDI2
CglibmUJJDE1LEwxMTAkMwkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDI2LCA8
X0R5Q19UZW1wJDEuNDg+dDQ3MgpMMTA5JDM6CiAjaW5zdHIKCXN0cQkkMzEs
RHlDUlRfQnJhbmNoSW5kZXgJICNjbGFzcyBzb3VyY2UJICMgbGluZSAwLCAw
eDAoUDY0KSwgPD50NTM2LCBhZGRyKF9EeUNSVF9CcmFuY2hJbmRleCQxLjAp
KFA2NCksIDAoSTMyKSwgMChJMzIpLCAwKEkzMiksIDAoSTMyKQoJbGRhCSQx
NCwxKCQzMSkJICNjbGFzcyBkbW92ZSxkbV9jb25zdGFudAkgIyAxKFNJNjQp
CiAjaW5zdHIKCWxkYQkkMTMsNigkMzEpCSAjY2xhc3MgZG1vdmUsZG1fY29u
c3RhbnQJICMgNihTSTY0KQogI2luc3RyCglsZGEJJDEyLDMxKCQzMSkJICNj
bGFzcyBkbW92ZSxkbV9jb25zdGFudAkgIyAzMShTSTY0KQogI2luc3RyCgli
cgkkMzEsTDQyJDMKICNtYXJrX3RyYWNlIDE2NzsKTDExMCQzOgogI2luc3Ry
CglsZGEJJDI1LDMoJDMxKQkgI2NsYXNzIGRtb3ZlLGRtX2NvbnN0YW50CSAj
IDMoU0kzMikKCSAjIHN0YWxsIAkxCiAjaW5zdHIKLmxvYyAyIDI2CglzdGwJ
JDI1LDMyKCQxNSkJICNjbGFzcyBzb3VyY2UJICMgbGluZSAyNiwgMyhTSTMy
KSwgPF9EeUNfVGVtcCQxLjQ4PnQ0NzIsIDMyKEk2NCksIDAoSTMyKSwgMChJ
MzIpLCAwKEkzMiksIDAoSTMyKQogI2luc3RyCglsZHEJJDIzLCQyLjEkMnNw
aWxsX3AgKyA4OCgkc3ApCSAjY2xhc3MgZG1vdmUsZG1fcmVzdG9yZQkgIyA8
X2J5dGVjb2RlcyQxLjE+dDQ1NQogI2luc3RyCglsZGEJJDE2LDI2KCQzMSkJ
ICNjbGFzcyBkbW92ZSxkbV9jb25zdGFudAkgIyAyNihTSTY0KQoJYnIJJDMx
LEwxMDkkMwogI21hcmtfdHJhY2UgMTQyOwpMMTA2JDM6CiAjaW5zdHIKCW9y
CSQxOSwkMzEsJDI0CSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMCwgPD50NTc3
LCA8PnQ1ODMKICNpbnN0cgoJb3IJJDMxLCQzMSwkMzEJICNjbGFzcyBkbW92
ZSxkbV9yZWdpc3RlcgkgIyA8PnQ1MzMKICNpbnN0cgoJc3RxCSQyNCwkMi4x
JDJzcGlsbF9wICsgMTYoJHNwKQkgI2NsYXNzIGRtb3ZlLGRtX3NwaWxsCSAj
IDw+dDU3NwogI2luc3RyCglicgkkMzEsTDEwNyQzCiAjbWFya190cmFjZSAx
NDU7CkwxMDUkMzoKICNpbnN0cgoJbGRxCSQyMCwkMi4xJDJzcGlsbF9wICsg
MTc2KCRzcCkJICNjbGFzcyBkbW92ZSxkbV9yZXN0b3JlCSAjIDw+dDU3OAoJ
bGRhCSQxMywyKCQzMSkJICNjbGFzcyBkbW92ZSxkbV9jb25zdGFudAkgIyAy
KFNJNjQpCiAjaW5zdHIKCWxkYWgJJDIzLDMyKCQzMSkJICNjbGFzcyBkbW92
ZSxkbV9jb25zdGFudAkgIyAyMDk3MTUyKEkzMikKICNpbnN0cgoJbGRhaAkk
MjcsLTMyKCQzMSkJICNjbGFzcyBkbW92ZSxkbV9jb25zdGFudAkgIyA0Mjky
ODcwMTQ0KEkzMikKICNpbnN0cgoubG9jIDIgMjYKCWFkZHEJJDIwLDQsJDEy
CSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMjYsIDw+dDI1MiwgPD50NTc4LCA0
KFNJMzIpCi5sb2MgMiAyNgoJbGRsCSQxMSwwKCQyMCkJICNjbGFzcyBzb3Vy
Y2UJICMgbGluZSAyNiwgPD50MjU4LCA8PnQ1NzgsIDAoSTY0KQogI2luc3Ry
Ci5sb2MgMiAyNgoJc3VicQkkMjEsJDEyLCQ4CSAjY2xhc3Mgc291cmNlCSAj
IGxpbmUgMjYsIDw+dDI1NCwgPD50NTgzLCA8PnQyNTIKICNpbnN0cgoubG9j
IDIgMjYKCWFkZGwJJDgsMywkMTIJICNjbGFzcyBzb3VyY2UJICMgbGluZSAy
NiwgPD50NjE5LCA8PnQyNTQsIDMoU0kzMikKICNpbnN0cgoubG9jIDIgMjYK
CWNtb3ZnZQkkOCwkOCwkMTIJICNjbGFzcyBzb3VyY2UJICMgbGluZSAyNiwg
PD50NjIwLCA8PnQyNTQsIDw+dDI1NCwgPD50NjE5CiAjaW5zdHIKLmxvYyAy
IDI2CglsZGEJJDgsLTEoJDIzKQkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDI2
LCA8PnQ3MzgsIDIwOTcxNTIoSTMyKSwgLTEoU0k2NCkKICNpbnN0cgoubG9j
IDIgMjYKCXNyYQkkMTIsJDEzLCQxMgkgI2NsYXNzIHNvdXJjZQkgIyBsaW5l
IDI2LCA8PnQyNTUsIDw+dDYyMCwgMihTSTY0KQogI2luc3RyCi5sb2MgMiAy
NgoJYW5kCSQxMSwkMjcsJDExCSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMjYs
IDw+dDI1OSwgPD50MjU4LCA0MjkyODcwMTQ0KEkzMikKICNpbnN0cgoubG9j
IDIgMjYKCWFuZAkkMTIsJDgsJDgJICNjbGFzcyBzb3VyY2UJICMgbGluZSAy
NiwgPD50MjU2LCA8PnQyNTUsIDw+dDczOAoJY3B5cwkkZjMxLCRmMzEsJGYz
MQkjIHBhZAogI2luc3RyCi5sb2MgMiAyNgoJb3IJJDgsJDExLCQxMQkgI2Ns
YXNzIHNvdXJjZQkgIyBsaW5lIDI2LCA8PnQyNjAsIDw+dDI1NiwgPD50MjU5
Ci5sb2MgMiAyNgoJc3RsCSQxMSwwKCQyMCkJICNjbGFzcyBzb3VyY2UJICMg
bGluZSAyNiwgPD50MjYwLCA8PnQ1NzgsIDAoSTY0KSwgMChJMzIpLCAwKEkz
MiksIDAoSTMyKSwgMChJMzIpCiAjaW5zdHIKCW9yCSQzMSwkMzEsJDMxCSAj
Y2xhc3MgZG1vdmUsZG1fcmVnaXN0ZXIJICMgPD50NTMzCgljcHlzCSRmMzEs
JGYzMSwkZjMxCSMgcGFkCiAjaW5zdHIKCW9yCSQyMSwkMzEsJDE5CSAjY2xh
c3MgZG1vdmUsZG1fcmVnaXN0ZXIJICMgPD50NTgzCgliZXEJJDI0LEwxMTEk
MwkgI2NsYXNzIHNvdXJjZSxyZWpvaW5fY29weQkgIyBsaW5lIDAsIDw+dDU3
NwogI2luc3RyCglicgkkMzEsTDEwNyQzCgliaXMJJDMxLCQzMSwkMzEJIyBw
YWQKICNtYXJrX3RyYWNlIDE5MDsKTDExMSQzOgogI2luc3RyCglicgkkMzEs
TDEwNiQzCgliaXMJJDMxLCQzMSwkMzEJIyBwYWQKICNtYXJrX3RyYWNlIDEz
ODsKTDEwMyQzOgogI2luc3RyCglvcgkkMzEsJDMxLCQyNQkgI2NsYXNzIHNv
dXJjZSxyZWpvaW5fY29weQkgIyBsaW5lIDAsIDw+dDU4NywgMChJMzIpCgls
ZHEJJDI3LCQyLjEkMnNwaWxsX3AgKyAxNzYoJHNwKQkgI2NsYXNzIGRtb3Zl
LGRtX3Jlc3RvcmUJICMgPD50NTc4CiAjaW5zdHIKCWxkcQkkMTYsJDIuMSQy
c3BpbGxfcCArIDE5Migkc3ApCSAjY2xhc3MgZG1vdmUsZG1fcmVzdG9yZQkg
IyA8PnQ1NzQKCW9yCSQzMSwkMzEsJDMxCSAjY2xhc3MgZG1vdmUsZG1fcmVn
aXN0ZXIJICMgPD50NTMzCiAjaW5zdHIKCXN0bAkkMjUsJDIuMSQyc3BpbGxf
cCgkc3ApCSAjY2xhc3MgZG1vdmUsZG1fc3BpbGwJICMgPD50NTg3Cglvcgkk
MTQsJDMxLCQyMQkgI2NsYXNzIGRtb3ZlLGRtX3JlZ2lzdGVyCSAjIDw+dDU4
MwogI2luc3RyCglhZGRxCSQyNywweDQsJDIwCSAjY2xhc3Mgc291cmNlLHJl
am9pbl9jb3B5CSAjIGxpbmUgMCwgPD50NjA1LCA8PnQ1NzgsIDB4NChQNjQp
CiAjaW5zdHIKCWJyCSQzMSxMMTA0JDMKICNtYXJrX3RyYWNlIDk0OwpMMTAy
JDM6CiAjaW5zdHIKCWxkYQkkMjMsMigkMzEpCSAjY2xhc3MgZG1vdmUsZG1f
Y29uc3RhbnQJICMgMihTSTY0KQoJbGRxCSQxNywkMi4xJDJzcGlsbF9wICsg
MTg0KCRzcCkJICNjbGFzcyBkbW92ZSxkbV9yZXN0b3JlCSAjIDw+dDU4Mgog
I2luc3RyCi5sb2MgMiAyNgoJYWRkcQkkMjAsNCwkMjIJICNjbGFzcyBzb3Vy
Y2UJICMgbGluZSAyNiwgPD50MTA1MywgPD50NTc4LCA0KFNJMzIpCi5sb2Mg
MiAyNgoJbGRsCSQyMSwwKCQyMCkJICNjbGFzcyBzb3VyY2UJICMgbGluZSAy
NiwgPD50MTA1MCwgPD50NTc4LCAwKEk2NCkKICNpbnN0cgoubG9jIDIgMjYK
CXN1YnEJJDAsJDIyLCQxOQkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDI2LCA8
PnQxMDUyLCA8PnQxMDU0LCA8PnQxMDUzCiAjaW5zdHIKLmxvYyAyIDI2Cglh
ZGRsCSQxOSwzLCQyMgkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDI2LCA8PnQ2
MTcsIDw+dDEwNTIsIDMoU0kzMikKICNpbnN0cgoubG9jIDIgMjYKCWNtb3Zn
ZQkkMTksJDE5LCQyMgkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDI2LCA8PnQ2
MTgsIDw+dDEwNTIsIDw+dDEwNTIsIDw+dDYxNwogI2luc3RyCglsZGFoCSQx
OSwzMigkMzEpCSAjY2xhc3MgZG1vdmUsZG1fY29uc3RhbnQJICMgMjA5NzE1
MihJMzIpCiAjaW5zdHIKLmxvYyAyIDI2CglzcmEJJDIyLCQyMywkMjIJICNj
bGFzcyBzb3VyY2UJICMgbGluZSAyNiwgPD50MTA0OSwgPD50NjE4LCAyKFNJ
NjQpCiAjaW5zdHIKLmxvYyAyIDI2CglsZGEJJDE5LC0xKCQxOSkJICNjbGFz
cyBzb3VyY2UJICMgbGluZSAyNiwgPD50NzMyLCAyMDk3MTUyKEkzMiksIC0x
KFNJNjQpCiAjaW5zdHIKLmxvYyAyIDI2CglhbmQJJDIyLCQxOSwkMjIJICNj
bGFzcyBzb3VyY2UJICMgbGluZSAyNiwgPD50MTA1MSwgPD50MTA0OSwgPD50
NzMyCiAjaW5zdHIKCWxkYWgJJDI3LC0zMigkMzEpCSAjY2xhc3MgZG1vdmUs
ZG1fY29uc3RhbnQJICMgNDI5Mjg3MDE0NChJMzIpCiAjaW5zdHIKCWxkYQkk
MjUsMygkMzEpCSAjY2xhc3MgZG1vdmUsZG1fY29uc3RhbnQJICMgMyhTSTMy
KQogI2luc3RyCi5sb2MgMiAyNgoJYW5kCSQyMSwkMjcsJDIxCSAjY2xhc3Mg
c291cmNlCSAjIGxpbmUgMjYsIDw+dDEwNDgsIDw+dDEwNTAsIDQyOTI4NzAx
NDQoSTMyKQogI2luc3RyCi5sb2MgMiAyNgoJb3IJJDIyLCQyMSwkMjIJICNj
bGFzcyBzb3VyY2UJICMgbGluZSAyNiwgPD50MTA0NywgPD50MTA1MSwgPD50
MTA0OAoubG9jIDIgMjYKCXN0bAkkMjIsMCgkMjApCSAjY2xhc3Mgc291cmNl
CSAjIGxpbmUgMjYsIDw+dDEwNDcsIDw+dDU3OCwgMChJNjQpLCAwKEkzMiks
IDAoSTMyKSwgMChJMzIpLCAwKEkzMikKICNpbnN0cgoubG9jIDIgMjYKCWxk
cQkkMjMsaW50ZXJwcmV0ZXIuTFNWRnJlZUxpc3QuMgkgI2NsYXNzIHNvdXJj
ZQkgIyBsaW5lIDI2LCA8PnQzMTEsIDw+dDUzNiwgYWRkcihpbnRlcnByZXRl
ci5MU1ZGcmVlTGlzdC5WQVIuMikoUDY0KQoJICMgc3RhbGwgCTIKICNpbnN0
cgoubG9jIDIgMjYKCXN0cQkkMjMsMCgkMTcpCSAjY2xhc3Mgc291cmNlCSAj
IGxpbmUgMjYsIDw+dDMxMSwgPD50NTgyLCAwKEk2NCksIDAoSTMyKSwgMChJ
MzIpLCAwKEkzMiksIDAoSTMyKQogI2luc3RyCi5sb2MgMiAyNgoJc3RxCSQx
NyxpbnRlcnByZXRlci5MU1ZGcmVlTGlzdC4yCSAjY2xhc3Mgc291cmNlCSAj
IGxpbmUgMjYsIDw+dDU4MiwgPD50NTM2LCBhZGRyKGludGVycHJldGVyLkxT
VkZyZWVMaXN0LlZBUi4yKShQNjQpLCAwKEkzMiksIDAoSTMyKSwgMChJMzIp
LCAwKEkzMikKCSAjIHN0YWxsIAkxCiAjaW5zdHIKCWJlcQkkMjQsTDExMiQz
CSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMCwgPD50NTc3CiAjaW5zdHIKCWJy
CSQzMSxMNjIkMwogI21hcmtfdHJhY2UgMTM3OwpMMTEyJDM6CiAjaW5zdHIK
CW9yCSQwLCQzMSwkMjQJICNjbGFzcyBzb3VyY2UJICMgbGluZSAwLCA8PnQ1
NzcsIDw+dDEwNTQKCSAjIHN0YWxsIAkxCiAjaW5zdHIKCXN0cQkkMjQsJDIu
MSQyc3BpbGxfcCArIDE2KCRzcCkJICNjbGFzcyBkbW92ZSxkbV9zcGlsbAkg
IyA8PnQ1NzcKICNpbnN0cgoJYnIJJDMxLEw2MiQzCiAjbWFya190cmFjZSAx
MDA7CkwxMDAkMzoKICNtYXJrX2NhbGwgY2FsbGVyX3NhdmVzLCByZWdzLCBh
dHlwZXMoKSwgcnR5cGVzKG42NCk7CiAjaW5zdHIKCW9yCSQzMSwkMzEsJDMx
CSAjY2xhc3MgZG1vdmUsZG1fcmVnaXN0ZXIJICMgPD50NTMzCi5sb2MgMiAy
NgoJanNyCSQyNixEWUNfQ0FDSEVfY3JlYXRlCglicgkkMjYsRkFLRTMxCkZB
S0UzMToJbGRncAkkZ3AsMCgkMjYpCSAjY2xhc3Mgc291cmNlCSAjIGxpbmUg
MjYsIHJhZGRyKERZQ19DQUNIRV9jcmVhdGUpKFA2NCksIDw+dDUzMwogI2lu
c3RyCglzdHEJJDAsJDIuMSQyc3BpbGxfcCArIDE5Migkc3ApCSAjY2xhc3Mg
ZG1vdmUsZG1fc3BpbGwJICMgPD50NTc0CglvcgkkMCwkMzEsJDE2CSAjY2xh
c3MgZG1vdmUsZG1fcmVnaXN0ZXIJICMgPD50NTc0CiAjaW5zdHIKCXN0cQkk
MCxpbnRlcnByZXRlci5DYWNoZS4yCSAjY2xhc3Mgc291cmNlCSAjIGxpbmUg
MCwgPD50NTc0LCA8PnQ1MzYsIGFkZHIoaW50ZXJwcmV0ZXIuQ2FjaGUuVkFS
LjIpKFA2NCksIDAoSTMyKSwgMChJMzIpLCAwKEkzMiksIDAoSTMyKQoJbGRh
CSQxOCwxKCQzMSkJICNjbGFzcyBkbW92ZSxkbV9jb25zdGFudAkgIyAxKFNJ
MzIpCiAjaW5zdHIKCW9yCSQzMSwkMzEsJDMxCSAjY2xhc3MgZG1vdmUsZG1f
cmVnaXN0ZXIJICMgPD50NTMzCglsZHEJJDE3LCQyLjEkMnNwaWxsX3AgKyAx
ODQoJHNwKQkgI2NsYXNzIGRtb3ZlLGRtX3Jlc3RvcmUJICMgPD50NTgyCgkg
IyBzdGFsbCAJMQogI2luc3RyCglicgkkMzEsTDEwMSQzCgliaXMJJDMxLCQz
MSwkMzEJIyBwYWQKICNtYXJrX3RyYWNlIDk4OwpMOTgkMzoKICNpbnN0cgou
bG9jIDIgMjYKCWxkcQkkMTcsaW50ZXJwcmV0ZXIuTFNWRnJlZUxpc3QuMgkg
I2NsYXNzIHNvdXJjZQkgIyBsaW5lIDI2LCA8PnQ1ODIsIDw+dDUzNiwgYWRk
cihpbnRlcnByZXRlci5MU1ZGcmVlTGlzdC5WQVIuMikoUDY0KQoJb3IJJDMx
LCQzMSwkMzEJICNjbGFzcyBkbW92ZSxkbV9yZWdpc3RlcgkgIyA8PnQ1MzMK
ICNpbnN0cgoJbGRxCSQxNixpbnRlcnByZXRlci5DYWNoZS4yCSAjY2xhc3Mg
c291cmNlLHJlam9pbl9jb3B5CSAjIGxpbmUgMCwgPD50NTc0LCA8PnQ1MzYs
IGFkZHIoaW50ZXJwcmV0ZXIuQ2FjaGUuVkFSLjIpKFA2NCkKCSAjIHN0YWxs
IAkxCiAjaW5zdHIKCXN0cQkkMTcsJDIuMSQyc3BpbGxfcCArIDE4NCgkc3Ap
CSAjY2xhc3MgZG1vdmUsZG1fc3BpbGwJICMgPD50NTgyCiAjaW5zdHIKCXN0
cQkkMTYsJDIuMSQyc3BpbGxfcCArIDE5Migkc3ApCSAjY2xhc3MgZG1vdmUs
ZG1fc3BpbGwJICMgPD50NTc0CiAjaW5zdHIKLmxvYyAyIDI2CglsZHEJJDI3
LDAoJDE3KQkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDI2LCA8PnQzMDMsIDw+
dDU4MiwgMChJNjQpCgkgIyBzdGFsbCAJMgogI2luc3RyCi5sb2MgMiAyNgoJ
c3RxCSQyNyxpbnRlcnByZXRlci5MU1ZGcmVlTGlzdC4yCSAjY2xhc3Mgc291
cmNlCSAjIGxpbmUgMjYsIDw+dDMwMywgPD50NTM2LCBhZGRyKGludGVycHJl
dGVyLkxTVkZyZWVMaXN0LlZBUi4yKShQNjQpLCAwKEkzMiksIDAoSTMyKSwg
MChJMzIpLCAwKEkzMikKICNpbnN0cgoJYnIJJDMxLEw5OSQzCiAjbWFya190
cmFjZSA0NTsKXyQxLmludGVycHJldGVyLlRBRy44LjQuZHljX2NvcHkuMDoK
aW50ZXJwcmV0ZXIuZHluX3NldHVwX2JlZ2luXzU4XzA6CiAjaW5zdHIKCWxk
YQkkMjEsMSgkMzEpCSAjY2xhc3MgZG1vdmUsZG1fY29uc3RhbnQJICMgMShT
STY0KQogI2luc3RyCglsZGEJJDE4LDMxKCQzMSkJICNjbGFzcyBkbW92ZSxk
bV9jb25zdGFudAkgIyAzMShTSTY0KQogI2luc3RyCi5sb2MgMiA3NwoJY21w
bHQJJDIwLCQyMSwkMjEJICNjbGFzcyBzb3VyY2UJICMgbGluZSA3NywgPD50
Mzg4LCA8X3JzJDEuMj50NTMwLCAxKFNJNjQpCiAjaW5zdHIKLmxvYyAyIDc3
CgljbXBsdAkkMTgsJDIwLCQxOAkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDc3
LCA8PnQzODksIDMxKFNJNjQpLCA8X3JzJDEuMj50NTMwCiAjaW5zdHIKLmxv
YyAyIDc3CglzOGFkZGwJJDIwLCQzMSwkMTYJICNjbGFzcyBzb3VyY2UsY3Nw
ZWMJICMgbGluZSA3NywgPD50OTE4LCA8X3JzJDEuMj50NTMwLCAwKEk2NCkK
ICNpbnN0cgoubG9jIDIgNzcKCW9yCSQyMSwkMTgsJDE4CSAjY2xhc3Mgc291
cmNlCSAjIGxpbmUgNzcsIDw+dDU2NiwgPD50Mzg4LCA8PnQzODkKICNpbnN0
cgoubG9jIDIgNzYKCXM0YWRkbAkkMjAsJDMxLCQxNAkgI2NsYXNzIHNvdXJj
ZSxjc3BlYwkgIyBsaW5lIDc2LCA8X3N1YnQxJDEuMj50NTM4LCA8X3JzJDEu
Mj50NTMwLCAwKEk2NCkKCWNweXMJJGYzMSwkZjMxLCRmMzEJIyBwYWQKaW50
ZXJwcmV0ZXIuZHluX3NldHVwX2VuZF81OF8wOgogI2luc3RyCglsZGEJJDIx
LDEoJDMxKQkgI2NsYXNzIGRtb3ZlLGRtX2NvbnN0YW50CSAjIDEoU0k2NCkK
LmxvYyAyIDc3CglibmUJJDE4LEwxMTMkMwkgI2NsYXNzIHNvdXJjZQkgIyBs
aW5lIDc3LCA8PnQ1NjYKaW50ZXJwcmV0ZXIuZHluX3NldHVwX2JlZ2luXzYw
XzA6CiAjaW5zdHIKLmxvYyAyIDc3CglsZHEJJDE2LGludGVycHJldGVyJDJE
WUMuU1dJVENIQ09QWS5UQUdQQUNLRVQuNC4wLTgoJDE2KQkgI2NsYXNzIHNv
dXJjZQkgIyBsaW5lIDc3LCA8PnQzOTEsIDw+dDkxOCwgKGFkZHIoaW50ZXJw
cmV0ZXIkMkRZQy5TV0lUQ0hDT1BZLlRBR0FSUkFZLjQuMCkoUDY0KSAtIDB4
OChJNjQpKShQNjQpCglsZGEJJDE4LDMxKCQzMSkJICNjbGFzcyBkbW92ZSxk
bV9jb25zdGFudAkgIyAzMShTSTY0KQogI2luc3RyCi5sb2MgMiA4MwoJY21w
bHQJJDE5LCQyMSwkMjEJICNjbGFzcyBzb3VyY2UsY3NwZWMJICMgbGluZSA4
MywgPD50NDA2LCA8X3J0JDEuMj50NTI5LCAxKFNJNjQpCiAjaW5zdHIKLmxv
YyAyIDgzCgljbXBsdAkkMTgsJDE5LCQxOAkgI2NsYXNzIHNvdXJjZSxjc3Bl
YwkgIyBsaW5lIDgzLCA8PnQ0MDcsIDMxKFNJNjQpLCA8X3J0JDEuMj50NTI5
CmludGVycHJldGVyLmR5bl9zZXR1cF9lbmRfNjBfMDoKICNpbnN0cgoubG9j
IDIgODMKCXM4YWRkbAkkMTksJDMxLCQxMwkgI2NsYXNzIHNvdXJjZSxjc3Bl
YwkgIyBsaW5lIDgzLCA8PnQ5MTIsIDxfcnQkMS4yPnQ1MjksIDAoSTY0KQou
bG9jIDIgNzcKCWptcAkkMzEsKCQxNikJICNjbGFzcyBzb3VyY2UJICMgbGlu
ZSA3NywgPD50MzkxCl8kMS5pbnRlcnByZXRlci5UQUcuNC5ERUZBVUxULmR5
Y19jb3B5LjA6CmludGVycHJldGVyLmR5bl9zZXR1cF9iZWdpbl82MV8wOgog
I2luc3RyCi5sb2MgMiA4MwoJb3IJJDIxLCQxOCwkMTgJICNjbGFzcyBzb3Vy
Y2UJICMgbGluZSA4MywgPD50NTY3LCA8PnQ0MDYsIDw+dDQwNwoJY3B5cwkk
ZjMxLCRmMzEsJGYzMQkjIHBhZAogI2luc3RyCglzdHEJJDMxLER5Q1JUX0R1
bW15R2xvYmFsCSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMCwgMHgwKFA2NCks
IDw+dDUzNiwgYWRkcihfRHlDUlRfRHVtbXlHbG9iYWwkMS45KShQNjQpLCAw
KEkzMiksIDAoSTMyKSwgMChJMzIpLCAwKEkzMikKLmxvYyAyIDgyCglzNGFk
ZGwJJDE5LCQzMSwkMTYJICNjbGFzcyBzb3VyY2UsY3NwZWMJICMgbGluZSA4
MiwgPD50NTM3LCA8X3J0JDEuMj50NTI5LCAwKEk2NCkKICNpbnN0cgoJb3IJ
JDMxLCQzMSwkMzEJICNjbGFzcyBkbW92ZSxkbV9yZWdpc3RlcgkgIyA8PnQ1
MzMKaW50ZXJwcmV0ZXIuZHluX3NldHVwX2VuZF82MV8wOgogI2luc3RyCglz
dHEJJDMxLER5Q1JUX0R1bW15R2xvYmFsCSAjY2xhc3Mgc291cmNlCSAjIGxp
bmUgMCwgMHgwKFA2NCksIDw+dDUzNiwgYWRkcihfRHlDUlRfRHVtbXlHbG9i
YWwkMS45KShQNjQpLCAwKEkzMiksIDAoSTMyKSwgMChJMzIpLCAwKEkzMikK
TDExNCQzOgppbnRlcnByZXRlci5keW5fc2V0dXBfYmVnaW5fNjJfMDoKICNp
bnN0cgogI2luc3RyCglzdGwJJDIwLGludGVycHJldGVyLnJ0Y29uc3RfNjJf
MF8wKCQzMSkJICNjbGFzcyBzb3VyY2UJICMgbGluZSAwLCA8X3JzJDEuMj50
NTMwLCAweDAoUDY0KSwgaW50ZXJwcmV0ZXIucnRjb25zdF82Ml8wXzAsIDAo
STMyKSwgMChJMzIpLCAwKEkzMiksIDAoSTMyKQoJICMgc3RhbGwgCTEKaW50
ZXJwcmV0ZXIuZHluX3NldHVwX2VuZF82Ml8wOgogI2luc3RyCglzdHEJJDE0
LGludGVycHJldGVyLnJ0Y29uc3RfNjJfMF8xKCQzMSkJICNjbGFzcyBzb3Vy
Y2UJICMgbGluZSAwLCA8X3N1YnQxJDEuMj50NTM4LCAweDAoUDY0KSwgaW50
ZXJwcmV0ZXIucnRjb25zdF82Ml8wXzEsIDAoSTMyKSwgMChJMzIpLCAwKEkz
MiksIDAoSTMyKQpMMTE1JDM6CmludGVycHJldGVyLmR5bl9zZXR1cF9iZWdp
bl82Nl8wOgogI2luc3RyCmludGVycHJldGVyLmR5bl9zZXR1cF9lbmRfNjZf
MDoKICNpbnN0cgoubG9jIDIgODMKCWJuZQkkMTgsTDExNiQzCSAjY2xhc3Mg
c291cmNlCSAjIGxpbmUgODMsIDw+dDU2NwppbnRlcnByZXRlci5keW5fc2V0
dXBfYmVnaW5fNjhfMDoKICNpbnN0cgoubG9jIDIgODMKCWxkcQkkMTMsaW50
ZXJwcmV0ZXIkMkRZQy5TV0lUQ0hDT1BZLlRBR1BBQ0tFVC4yLjAtOCgkMTMp
CSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgODMsIDw+dDQwOSwgPD50OTEyLCAo
YWRkcihpbnRlcnByZXRlciQyRFlDLlNXSVRDSENPUFkuVEFHQVJSQVkuMi4w
KShQNjQpIC0gMHg4KEk2NCkpKFA2NCkKCSAjIHN0YWxsIAkyCmludGVycHJl
dGVyLmR5bl9zZXR1cF9lbmRfNjhfMDoKICNpbnN0cgoJYmlzCSQzMSwkMzEs
JDMxCSMgcGFkCi5sb2MgMiA4MwoJam1wCSQzMSwoJDEzKQkgI2NsYXNzIHNv
dXJjZQkgIyBsaW5lIDgzLCA8PnQ0MDkKXyQxLmludGVycHJldGVyLlRBRy41
LkRFRkFVTFQuZHljX2NvcHkuMDoKaW50ZXJwcmV0ZXIuZHluX3NldHVwX2Jl
Z2luXzY5XzA6CiAjaW5zdHIKLmxvYyAyIDgzCglhZGRsCSQyMiwxLCQyMgkg
I2NsYXNzIHNvdXJjZQkgIyBsaW5lIDgzLCA8X3BjJDEuMT50NDU0LCA8X3Bj
JDEuMT50NDU0LCAxKFNJMzIpCglzdGwJJDIyLCQyLjEkMnNwaWxsX3AgKyA5
Nigkc3ApCSAjY2xhc3MgZG1vdmUsZG1fc3BpbGwJICMgPF9wYyQxLjE+dDQ1
NAogI2luc3RyCglzdHEJJDMxLER5Q1JUX0R1bW15R2xvYmFsCSAjY2xhc3Mg
c291cmNlCSAjIGxpbmUgMCwgMHgwKFA2NCksIDw+dDUzNiwgYWRkcihfRHlD
UlRfRHVtbXlHbG9iYWwkMS45KShQNjQpLCAwKEkzMiksIDAoSTMyKSwgMChJ
MzIpLCAwKEkzMikKCSAjIHN0YWxsIAkxCmludGVycHJldGVyLmR5bl9zZXR1
cF9lbmRfNjlfMDoKICNpbnN0cgoJc3RxCSQzMSxEeUNSVF9EdW1teUdsb2Jh
bAkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDAsIDB4MChQNjQpLCA8PnQ1MzYs
IGFkZHIoX0R5Q1JUX0R1bW15R2xvYmFsJDEuOSkoUDY0KSwgMChJMzIpLCAw
KEkzMiksIDAoSTMyKSwgMChJMzIpCkwxMTckMzoKaW50ZXJwcmV0ZXIuZHlu
X3NldHVwX2JlZ2luXzcwXzA6CiAjaW5zdHIKICNpbnN0cgoJc3RsCSQxNyxp
bnRlcnByZXRlci5ydGNvbnN0XzcwXzBfMCgkMzEpCSAjY2xhc3Mgc291cmNl
CSAjIGxpbmUgMCwgPF9vZmZzZXQkMS4yPnQ1MjcsIDB4MChQNjQpLCBpbnRl
cnByZXRlci5ydGNvbnN0XzcwXzBfMCwgMChJMzIpLCAwKEkzMiksIDAoSTMy
KSwgMChJMzIpCgkgIyBzdGFsbCAJMQogI2luc3RyCglzdGwJJDE5LGludGVy
cHJldGVyLnJ0Y29uc3RfNzBfMF8xKCQzMSkJICNjbGFzcyBzb3VyY2UJICMg
bGluZSAwLCA8X3J0JDEuMj50NTI5LCAweDAoUDY0KSwgaW50ZXJwcmV0ZXIu
cnRjb25zdF83MF8wXzEsIDAoSTMyKSwgMChJMzIpLCAwKEkzMiksIDAoSTMy
KQoJICMgc3RhbGwgCTEKaW50ZXJwcmV0ZXIuZHluX3NldHVwX2VuZF83MF8w
OgogI2luc3RyCglzdHEJJDE2LGludGVycHJldGVyLnJ0Y29uc3RfNzBfMF8y
KCQzMSkJICNjbGFzcyBzb3VyY2UJICMgbGluZSAwLCA8PnQ1MzcsIDB4MChQ
NjQpLCBpbnRlcnByZXRlci5ydGNvbnN0XzcwXzBfMiwgMChJMzIpLCAwKEkz
MiksIDAoSTMyKSwgMChJMzIpCkwxMTgkMzoKaW50ZXJwcmV0ZXIuZHluX3Nl
dHVwX2JlZ2luXzc0XzA6CiAjbWFya19jYWxsIGNhbGxlcl9zYXZlcywgcmVn
cywgYXR5cGVzKCksIHJ0eXBlcygpOwogI2luc3RyCi5sb2MgMiAyNgoJanNy
CSQyNixEeUNSVF9QYXRjaEludHJhVW5pdEJyYW5jaGVzCglicgkkMjYsRkFL
RTEzCkZBS0UxMzoJbGRncAkkZ3AsMCgkMjYpCSAjY2xhc3Mgc291cmNlCSAj
IGxpbmUgMjYsIHJhZGRyKER5Q1JUX1BhdGNoSW50cmFVbml0QnJhbmNoZXMp
KFA2NCksIDw+dDUzMwogI2luc3RyCglzdHEJJDMxLER5Q1JUX0NvZGVMb2Nh
dGlvbgkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDAsIDB4MChQNjQpLCA8PnQ1
MzYsIGFkZHIoX0R5Q1JUX0NvZGVMb2NhdGlvbiQxLjApKFA2NCksIDAoSTMy
KSwgMChJMzIpLCAwKEkzMiksIDAoSTMyKQoJbGRhCSQxOCwxKCQzMSkJICNj
bGFzcyBkbW92ZSxkbV9jb25zdGFudAkgIyAxKFNJMzIpCiAjaW5zdHIKCWxk
cQkkMjEsRHlDUlRfTGFzdEJyYW5jaAkgI2NsYXNzIHNvdXJjZQkgIyBsaW5l
IDAsIDw+dDExMTIsIDw+dDUzNiwgYWRkcihfRHlDUlRfTGFzdEJyYW5jaCQx
LjApKFA2NCkKCW9yCSQzMSwkMzEsJDMxCSAjY2xhc3MgZG1vdmUsZG1fcmVn
aXN0ZXIJICMgPD50NTMzCiAjaW5zdHIKLmxvYyAyIDI2CglsZHEJJDE0LGlu
dGVycHJldGVyLkxTVkZyZWVMaXN0LjIJICNjbGFzcyBzb3VyY2UJICMgbGlu
ZSAyNiwgPD50MTExMywgPD50NTM2LCBhZGRyKGludGVycHJldGVyLkxTVkZy
ZWVMaXN0LlZBUi4yKShQNjQpCiAjaW5zdHIKCWxkbAkkMjIsJDIuMSQyc3Bp
bGxfcCArIDk2KCRzcCkJICNjbGFzcyBkbW92ZSxkbV9yZXN0b3JlCSAjIDxf
cGMkMS4xPnQ0NTQKICNpbnN0cgoJc3RxCSQyMSwkMi4xJDJzcGlsbF9wICsg
MjA4KCRzcCkJICNjbGFzcyBkbW92ZSxkbV9zcGlsbAkgIyA8PnQxMTEyCglj
cHlzCSRmMzEsJGYzMSwkZjMxCSMgcGFkCmludGVycHJldGVyLmR5bl9zZXR1
cF9lbmRfNzRfMDoKICNpbnN0cgoJbGRxCSQyMywkMi4xJDJzcGlsbF9wICsg
ODgoJHNwKQkgI2NsYXNzIGRtb3ZlLGRtX3Jlc3RvcmUJICMgPF9ieXRlY29k
ZXMkMS4xPnQ0NTUKLmxvYyAyIDI2CglibmUJJDE0LEwxMTkkMwkgI2NsYXNz
IHNvdXJjZQkgIyBsaW5lIDI2LCA8PnQxMTEzCiAjaW5zdHIKLmxvYyAyIDI2
CglsZHEJJDE3LER5Q1JUX1RlbXBMb2NhdGlvbgkgI2NsYXNzIHNvdXJjZQkg
IyBsaW5lIDI2LCA8PnQxMTE0LCA8PnQ1MzYsIGFkZHIoX0R5Q1JUX1RlbXBM
b2NhdGlvbiQxLjApKFA2NCkKICNpbnN0cgoJbGRxCSQxNixpbnRlcnByZXRl
ci5DYWNoZS4yCSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMCwgPD50MTExNywg
PD50NTM2LCBhZGRyKGludGVycHJldGVyLkNhY2hlLlZBUi4yKShQNjQpCgkg
IyBzdGFsbCAJMQogI2luc3RyCglzdHEJJDE3LCQyLjEkMnNwaWxsX3AgKyAy
MTYoJHNwKQkgI2NsYXNzIGRtb3ZlLGRtX3NwaWxsCSAjIDw+dDExMTQKLmxv
YyAyIDI2CglhZGRxCSQxNywxNiwkMjEJICNjbGFzcyBzb3VyY2UJICMgbGlu
ZSAyNiwgPF9EeUNSVF9UZW1wTG9jYXRpb24kMS4wPnQxMTE2LCA8PnQxMTE0
LCAxNihJMzIpCiAjaW5zdHIKCXN0cQkkMTYsJDIuMSQyc3BpbGxfcCArIDIy
NCgkc3ApCSAjY2xhc3MgZG1vdmUsZG1fc3BpbGwJICMgPD50MTExNwogI2lu
c3RyCi5sb2MgMiAyNgoJc3RxCSQyMSxEeUNSVF9UZW1wTG9jYXRpb24JICNj
bGFzcyBzb3VyY2UJICMgbGluZSAyNiwgPF9EeUNSVF9UZW1wTG9jYXRpb24k
MS4wPnQxMTE2LCA8PnQ1MzYsIGFkZHIoX0R5Q1JUX1RlbXBMb2NhdGlvbiQx
LjApKFA2NCksIDAoSTMyKSwgMChJMzIpLCAwKEkzMiksIDAoSTMyKQpMMTIw
JDM6CiAjaW5zdHIKCXN0bAkkMjIsMCgkMTcpCSAjY2xhc3Mgc291cmNlCSAj
IGxpbmUgMCwgPF9wYyQxLjE+dDQ1NCwgPD50MTExNCwgMChTSTMyKSwgMChJ
MzIpLCAwKEkzMiksIDAoSTMyKSwgMChJMzIpCiAjaW5zdHIKCXN0bAkkMzEs
NCgkMTcpCSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMCwgMChTSTMyKSwgPD50
MTExNCwgNChTSTMyKSwgMChJMzIpLCAwKEkzMiksIDAoSTMyKSwgMChJMzIp
CiAjaW5zdHIKCXN0cQkkMjMsOCgkMTcpCSAjY2xhc3Mgc291cmNlCSAjIGxp
bmUgMCwgPF9ieXRlY29kZXMkMS4xPnQ0NTUsIDw+dDExMTQsIDgoU0kzMiks
IDAoSTMyKSwgMChJMzIpLCAwKEkzMiksIDAoSTMyKQoJICMgc3RhbGwgCTEK
ICNpbnN0cgoJYmVxCSQxNixMMTIxJDMJICNjbGFzcyBzb3VyY2UJICMgbGlu
ZSAwLCA8PnQxMTE3CkwxMjIkMzoKICNtYXJrX2NhbGwgY2FsbGVyX3NhdmVz
LCByZWdzLCBhdHlwZXMobjY0LG42NCxuMzIpLCBydHlwZXMobjY0KTsKICNp
bnN0cgoJYmlzCSQzMSwkMzEsJDMxCSMgcGFkCi5sb2MgMiAyNgoJanNyCSQy
NixEWUNfQ0FDSEVfbG9va3VwCglicgkkMjYsRkFLRTE0CkZBS0UxNDoJbGRn
cAkkZ3AsMCgkMjYpCSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMjYsIHJhZGRy
KERZQ19DQUNIRV9sb29rdXApKFA2NCksIDw+dDUzMywgPD50MTExNywgPD50
MTExNCwgMShTSTMyKQogI2luc3RyCglsZGwJJDI1LCQyLjEkMnNwaWxsX3Ao
JHNwKQkgI2NsYXNzIGRtb3ZlLGRtX3Jlc3RvcmUJICMgPD50NTg3Ci5sb2Mg
MiAyNgoJc3VicQkkMzEsMzIsJDIxCSAjY2xhc3Mgc291cmNlLGNzcGVjCSAj
IGxpbmUgMjYsIDxfQWxpZ25lZEFkZHJlc3MkMS41OD50NzU1LCAwKEk2NCks
IDMyKFNJNjQpCiAjaW5zdHIKCWxkcQkkMTQsJDIuMSQyc3BpbGxfcCArIDIw
OCgkc3ApCSAjY2xhc3MgZG1vdmUsZG1fcmVzdG9yZQkgIyA8PnQxMTEyCgls
ZGEJJDE4LDEoJDMxKQkgI2NsYXNzIGRtb3ZlLGRtX2NvbnN0YW50CSAjIDEo
U0kzMikKICNpbnN0cgoJbGRxCSQyNCwkMi4xJDJzcGlsbF9wICsgMTYoJHNw
KQkgI2NsYXNzIGRtb3ZlLGRtX3Jlc3RvcmUJICMgPD50NTc3CglibmUJJDAs
TDEyMyQzCSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMCwgPD50MTExOAogI2lu
c3RyCi5sb2MgMiAyNgoJbGRxCSQxMyxEeUNSVF9Db2RlTG9jYXRpb24JICNj
bGFzcyBzb3VyY2UJICMgbGluZSAyNiwgPD50MTEyNywgPD50NTM2LCBhZGRy
KF9EeUNSVF9Db2RlTG9jYXRpb24kMS4wKShQNjQpCglvcgkkMzEsJDMxLCQz
MQkgI2NsYXNzIGRtb3ZlLGRtX3JlZ2lzdGVyCSAjIDw+dDUzMwogI2luc3Ry
CglhZGRxCSQxNCwweDQsJDE0CSAjY2xhc3Mgc291cmNlLGNzcGVjCSAjIGxp
bmUgMCwgPD50NjA2LCA8PnQxMTEyLCAweDQoUDY0KQoJbGRxCSQxNywkMi4x
JDJzcGlsbF9wICsgMjE2KCRzcCkJICNjbGFzcyBkbW92ZSxkbV9yZXN0b3Jl
CSAjIDw+dDExMTQKICNpbnN0cgoJb3IJJDMxLCQzMSwkMTIJICNjbGFzcyBz
b3VyY2UsY3NwZWMJICMgbGluZSAwLCA8PnQ1ODcsIDAoSTMyKQoubG9jIDIg
MjYKCWJlcQkkMjUsTDEyNCQzCSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMjYs
IDw+dDU4NwogI2luc3RyCi5sb2MgMiAyNgoJbGRxCSQxMSxEeUNSVF9QYWRk
ZWRCeXRlcwkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDI2LCA8X0R5Q1JUX1Bh
ZGRlZEJ5dGVzJDEuMD50MTEzMCwgPD50NTM2LCBhZGRyKF9EeUNSVF9QYWRk
ZWRCeXRlcyQxLjApKFA2NCkKLmxvYyAyIDI2CglhZGRxCSQxMyw2MywkOAkg
I2NsYXNzIHNvdXJjZQkgIyBsaW5lIDI2LCA8PnQxMTI4LCA8PnQxMTI3LCA2
MyhTSTY0KQogI2luc3RyCglzdGwJJDEyLCQyLjEkMnNwaWxsX3AoJHNwKQkg
I2NsYXNzIGRtb3ZlLGRtX3NwaWxsCSAjIDw+dDU4NwoubG9jIDIgMjYKCWFu
ZAkkOCwkMjEsJDIxCSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMjYsIDxfQWxp
Z25lZEFkZHJlc3MkMS41OD50MTEyOSwgPD50MTEyOCwgPF9BbGlnbmVkQWRk
cmVzcyQxLjU4PnQ3NTUKICNpbnN0cgoubG9jIDIgMjYKCXN1YnEJJDIxLCQx
MywkMTMJICNjbGFzcyBzb3VyY2UJICMgbGluZSAyNiwgPF9EeUNSVF9QYWRk
ZWRCeXRlcyQxLjA+dDc1NiwgPF9BbGlnbmVkQWRkcmVzcyQxLjU4PnQxMTI5
LCA8PnQxMTI3CglsZHEJJDE2LCQyLjEkMnNwaWxsX3AgKyAyMjQoJHNwKQkg
I2NsYXNzIGRtb3ZlLGRtX3Jlc3RvcmUJICMgPD50MTExNwogI2luc3RyCi5s
b2MgMiAyNgoJYWRkcQkkMTMsJDExLCQxMQkgI2NsYXNzIHNvdXJjZQkgIyBs
aW5lIDI2LCA8X0R5Q1JUX1BhZGRlZEJ5dGVzJDEuMD50MTEzMSwgPF9EeUNS
VF9QYWRkZWRCeXRlcyQxLjA+dDc1NiwgPF9EeUNSVF9QYWRkZWRCeXRlcyQx
LjA+dDExMzAKLmxvYyAyIDI2CglzdHEJJDExLER5Q1JUX1BhZGRlZEJ5dGVz
CSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMjYsIDxfRHlDUlRfUGFkZGVkQnl0
ZXMkMS4wPnQxMTMxLCA8PnQ1MzYsIGFkZHIoX0R5Q1JUX1BhZGRlZEJ5dGVz
JDEuMCkoUDY0KSwgMChJMzIpLCAwKEkzMiksIDAoSTMyKSwgMChJMzIpCiAj
aW5zdHIKLmxvYyAyIDI2CglvcgkkMjEsJDMxLCQyMQkgI2NsYXNzIHNvdXJj
ZQkgIyBsaW5lIDI2LCA8PnQxMTI3LCA8X0FsaWduZWRBZGRyZXNzJDEuNTg+
dDExMjkKCSAjIHN0YWxsIAkxCkwxMjUkMzoKICNpbnN0cgoJY21wZXEJJDIx
LCQxNCwkMTQJICNjbGFzcyBzb3VyY2UJICMgbGluZSAwLCA8PnQ3NTQsIDw+
dDExMjcsIDw+dDYwNgoJICMgc3RhbGwgCTEKICNpbnN0cgoJYmVxCSQxNCxM
MTI2JDMJICNjbGFzcyBzb3VyY2UJICMgbGluZSAwLCA8PnQ3NTQKICNpbnN0
cgoJbGRxCSQxOSwkMi4xJDJzcGlsbF9wICsgMjA4KCRzcCkJICNjbGFzcyBz
b3VyY2UJICMgbGluZSAwLCA8PnQxMTI3LCA8PnQxMTEyCgkgIyBzdGFsbCAJ
MQogI2luc3RyCgliZXEJJDI0LEwxMjckMwkgI2NsYXNzIHNvdXJjZQkgIyBs
aW5lIDAsIDw+dDU3NwpMMTI4JDM6CiAjaW5zdHIKCXN0cQkkMTksJDIuMSQy
c3BpbGxfcCArIDIzMigkc3ApCSAjY2xhc3MgZG1vdmUsZG1fc3BpbGwJICMg
PD50MTEyNwogI21hcmtfY2FsbCBjYWxsZXJfc2F2ZXMsIHJlZ3MsIGF0eXBl
cyhuNjQsbjY0LG4zMixuNjQpLCBydHlwZXMoKTsKICNpbnN0cgoJYmlzCSQz
MSwkMzEsJDMxCSMgcGFkCi5sb2MgMiAyNgoJanNyCSQyNixEWUNfQ0FDSEVf
aW5zZXJ0CglicgkkMjYsRkFLRTE1CkZBS0UxNToJbGRncAkkZ3AsMCgkMjYp
CSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMjYsIHJhZGRyKERZQ19DQUNIRV9p
bnNlcnQpKFA2NCksIDw+dDUzMywgPD50MTExNywgPD50MTExNCwgMShTSTMy
KSwgPD50MTEyNwogI2luc3RyCglsZHEJJDEzLCQyLjEkMnNwaWxsX3AgKyAy
MzIoJHNwKQkgI2NsYXNzIGRtb3ZlLGRtX3Jlc3RvcmUJICMgPD50MTEyNwoJ
bGRhaAkkMjcsMSgkMzEpCSAjY2xhc3MgZG1vdmUsZG1fY29uc3RhbnQJICMg
NjU1MzYoSTMyKQogI2luc3RyCglsZHEJJDIxLER5Q1JUX1N0YXRpY1ZhbHVl
VGFibGUJICNjbGFzcyBzb3VyY2UJICMgbGluZSAwLCA8PnQxMTM5LCA8PnQ1
MzYsIGFkZHIoX0R5Q1JUX1N0YXRpY1ZhbHVlVGFibGUkMS4wKShQNjQpCgls
ZGEJJDE5LDEoJDMxKQkgI2NsYXNzIGRtb3ZlLGRtX2NvbnN0YW50CSAjIDEo
STMyKQoJICMgc3RhbGwgCTEKICNpbnN0cgoJc3RxCSQxMyxEeUNSVF9TdGl0
Y2hMb2NhdGlvbgkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDAsIDw+dDExMjcs
IDw+dDUzNiwgYWRkcihfRHlDUlRfU3RpdGNoTG9jYXRpb24kMS4wKShQNjQp
LCAwKEkzMiksIDAoSTMyKSwgMChJMzIpLCAwKEkzMikKCSAjIHN0YWxsIAkx
CiAjaW5zdHIKCWJlcQkkMjEsTDEyOSQzCSAjY2xhc3Mgc291cmNlCSAjIGxp
bmUgMCwgPD50MTEzOQogI2luc3RyCglsZGwJJDIxLER5Q1JUX1NWVEluZGV4
CSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMCwgPD50MTE0MCwgPD50NTM2LCBh
ZGRyKF9EeUNSVF9TVlRJbmRleCQxLjApKFA2NCkKCSAjIHN0YWxsIAkyCiAj
aW5zdHIKCWFkZGwJJDIxLDIxNiwkMjEJICNjbGFzcyBzb3VyY2UJICMgbGlu
ZSAwLCA8PnQxMTQxLCA8PnQxMTQwLCAyMTYoU0kzMikKICNpbnN0cgoJY21w
bGUJJDIxLCQyNywkMTgJICNjbGFzcyBzb3VyY2UJICMgbGluZSAwLCA8PnQ3
NjIsIDw+dDExNDEsIDY1NTM2KEkzMikKCSAjIHN0YWxsIAkxCiAjaW5zdHIK
CWJlcQkkMTgsTDEyOSQzCSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMCwgPD50
NzYyCiAjaW5zdHIKCXN0bAkkMTksRHlDUlRfQnVpbGRUYWJsZVBvaW50ZXIJ
ICNjbGFzcyBzb3VyY2UJICMgbGluZSAwLCAxKEkzMiksIDw+dDUzNiwgYWRk
cihfRHlDUlRfQnVpbGRUYWJsZVBvaW50ZXIkMS4wKShQNjQpLCAwKEkzMiks
IDAoSTMyKSwgMChJMzIpLCAwKEkzMikKCWNweXMJJGYzMSwkZjMxLCRmMzEJ
IyBwYWQKICNtYXJrX3RyYWNlIDE4MzsKICNpbnN0cgoJbGRhaAkkMTcsMSgk
MzEpCSAjY2xhc3MgZG1vdmUsZG1fY29uc3RhbnQJICMgNjU1MzYoSTMyKQoJ
bGRsCSQyMiwkMi4xJDJzcGlsbF9wICsgOTYoJHNwKQkgI2NsYXNzIGRtb3Zl
LGRtX3Jlc3RvcmUJICMgPF9wYyQxLjE+dDQ1NAogI2luc3RyCglsZGEJJDE4
LDExKCQzMSkJICNjbGFzcyBkbW92ZSxkbV9jb25zdGFudAkgIyAxMShTSTY0
KQogI2luc3RyCglsZGEJJDE5LDE2KCQzMSkJICNjbGFzcyBkbW92ZSxkbV9j
b25zdGFudAkgIyAxNihTSTY0KQogI2luc3RyCglsZGEJJDIwLDIxKCQzMSkJ
ICNjbGFzcyBkbW92ZSxkbV9jb25zdGFudAkgIyAyMShTSTY0KQoJY3B5cwkk
ZjMxLCRmMzEsJGYzMQkjIHBhZAogI2luc3RyCglsZGEJJDIxLDQoJDMxKQkg
I2NsYXNzIGRtb3ZlLGRtX2NvbnN0YW50CSAjIDQoSTY0KQoJbGRxCSQyMywk
Mi4xJDJzcGlsbF9wICsgODgoJHNwKQkgI2NsYXNzIGRtb3ZlLGRtX3Jlc3Rv
cmUJICMgPF9ieXRlY29kZXMkMS4xPnQ0NTUKICNpbnN0cgoJbGRhCSQxNiwy
NigkMzEpCSAjY2xhc3MgZG1vdmUsZG1fY29uc3RhbnQJICMgMjYoU0k2NCkK
CWJyCSQzMSxMMTMwJDMKICNtYXJrX3RyYWNlIDgxOwpMMTI5JDM6CiAjaW5z
dHIKLmxvYyAyIDI2CglsZHEJJDE1LER5Q1JUX1RhYmxlTG9jYXRpb24JICNj
bGFzcyBzb3VyY2UJICMgbGluZSAyNiwgPD50MTE0MiwgPD50NTM2LCBhZGRy
KF9EeUNSVF9UYWJsZUxvY2F0aW9uJDEuMCkoUDY0KQoJbGRhaAkkMTcsMSgk
MzEpCSAjY2xhc3MgZG1vdmUsZG1fY29uc3RhbnQJICMgNjU1MzYoSTMyKQog
I2luc3RyCi5sb2MgMiAyNgoJbGRsCSQxMSxEeUNSVF9UYWJsZVBvaW50ZXJJ
bmRleAkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDI2LCA8X0R5Q1JUX1RhYmxl
UG9pbnRlckluZGV4JDEuMD50MTE0NiwgPD50NTM2LCBhZGRyKF9EeUNSVF9U
YWJsZVBvaW50ZXJJbmRleCQxLjApKFA2NCkKLmxvYyAyIDI2CglsZGEJJDgs
RHlDUlRfVGFibGVQb2ludGVycys4CSAjY2xhc3Mgc291cmNlCSAjIGxpbmUg
MjYsIDw+dDc2OCwgPD50NTM2LCAoYWRkcihfRHlDUlRfVGFibGVQb2ludGVy
cyQxLjApKFA2NCkgKyAweDgoSTY0KSkoUDY0KQogI2luc3RyCglsZGEJJDcs
LTMyNzY4KCQxNykJICNjbGFzcyBzb3VyY2UJICMgbGluZSAwLCA8PnQ3NjUs
IDY1NTM2KEkzMiksIC0zMjc2OChTSTY0KQoJc3RsCSQxOSxEeUNSVF9CdWls
ZFRhYmxlUG9pbnRlcgkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDAsIDEoSTMy
KSwgPD50NTM2LCBhZGRyKF9EeUNSVF9CdWlsZFRhYmxlUG9pbnRlciQxLjAp
KFA2NCksIDAoSTMyKSwgMChJMzIpLCAwKEkzMiksIDAoSTMyKQogI2luc3Ry
CglhZGRxCSQxNSwkNywkNgkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDAsIDw+
dDExNDQsIDw+dDExNDIsIDw+dDc2NQoJc3RxCSQ2LER5Q1JUX1N0YXRpY1Zh
bHVlVGFibGUJICNjbGFzcyBzb3VyY2UJICMgbGluZSAwLCA8PnQxMTQ0LCA8
PnQ1MzYsIGFkZHIoX0R5Q1JUX1N0YXRpY1ZhbHVlVGFibGUkMS4wKShQNjQp
LCAwKEkzMiksIDAoSTMyKSwgMChJMzIpLCAwKEkzMikKICNpbnN0cgoubG9j
IDIgMjYKCWFkZHEJJDExLCQ4LCQ4CSAjY2xhc3Mgc291cmNlCSAjIGxpbmUg
MjYsIDw+dDExNDgsIDxfRHlDUlRfVGFibGVQb2ludGVySW5kZXgkMS4wPnQx
MTQ2LCA8PnQ3NjgKCXN0cQkkMzEsRHlDUlRfU1ZUSW5kZXgJICNjbGFzcyBz
b3VyY2UJICMgbGluZSAwLCAweDAoUDY0KSwgPD50NTM2LCBhZGRyKF9EeUNS
VF9TVlRJbmRleCQxLjApKFA2NCksIDAoSTMyKSwgMChJMzIpLCAwKEkzMiks
IDAoSTMyKQogI2luc3RyCi5sb2MgMiAyNgoJYWRkcQkkMTUsNjU1MzYsJDE1
CSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMjYsIDxfRHlDUlRfVGFibGVMb2Nh
dGlvbiQxLjA+dDExNDMsIDw+dDExNDIsIDY1NTM2KEkzMikKLmxvYyAyIDI2
CglzdHEJJDE1LER5Q1JUX1RhYmxlTG9jYXRpb24JICNjbGFzcyBzb3VyY2UJ
ICMgbGluZSAyNiwgPF9EeUNSVF9UYWJsZUxvY2F0aW9uJDEuMD50MTE0Mywg
PD50NTM2LCBhZGRyKF9EeUNSVF9UYWJsZUxvY2F0aW9uJDEuMCkoUDY0KSwg
MChJMzIpLCAwKEkzMiksIDAoSTMyKSwgMChJMzIpCiAjaW5zdHIKLmxvYyAy
IDI2CglzdHEJJDYsMCgkOCkJICNjbGFzcyBzb3VyY2UJICMgbGluZSAyNiwg
PD50MTE0NCwgPD50MTE0OCwgMChJNjQpLCAwKEkzMiksIDAoSTMyKSwgMChJ
MzIpLCAwKEkzMikKLmxvYyAyIDI2CglhZGRsCSQxMSw4LCQxMQkgI2NsYXNz
IHNvdXJjZQkgIyBsaW5lIDI2LCA8X0R5Q1JUX1RhYmxlUG9pbnRlckluZGV4
JDEuMD50MTE0NywgPF9EeUNSVF9UYWJsZVBvaW50ZXJJbmRleCQxLjA+dDEx
NDYsIDgoSTMyKQogI2luc3RyCi5sb2MgMiAyNgoJc3RsCSQxMSxEeUNSVF9U
YWJsZVBvaW50ZXJJbmRleAkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDI2LCA8
X0R5Q1JUX1RhYmxlUG9pbnRlckluZGV4JDEuMD50MTE0NywgPD50NTM2LCBh
ZGRyKF9EeUNSVF9UYWJsZVBvaW50ZXJJbmRleCQxLjApKFA2NCksIDAoSTMy
KSwgMChJMzIpLCAwKEkzMiksIDAoSTMyKQoJbGRhCSQyMSw0KCQzMSkJICNj
bGFzcyBkbW92ZSxkbV9jb25zdGFudAkgIyA0KEk2NCkKICNpbnN0cgoubG9j
IDIgMjYKCWxkcQkkMTUsRHlDUlRfV29ya0xpc3QJICNjbGFzcyBzb3VyY2UJ
ICMgbGluZSAyNiwgPF9EeUNfVGVtcCQxLjQ4PnQxMTQ1LCA8PnQ1MzYsIGFk
ZHIoX0R5Q1JUX1dvcmtMaXN0JDEuMCkoUDY0KQoJbGRhCSQyMCwyMSgkMzEp
CSAjY2xhc3MgZG1vdmUsZG1fY29uc3RhbnQJICMgMjEoU0k2NCkKICNpbnN0
cgoJbGRsCSQyMiwkMi4xJDJzcGlsbF9wICsgOTYoJHNwKQkgI2NsYXNzIGRt
b3ZlLGRtX3Jlc3RvcmUJICMgPF9wYyQxLjE+dDQ1NAoJbGRhCSQxOSwxNigk
MzEpCSAjY2xhc3MgZG1vdmUsZG1fY29uc3RhbnQJICMgMTYoU0k2NCkKICNp
bnN0cgoJbGRxCSQyMywkMi4xJDJzcGlsbF9wICsgODgoJHNwKQkgI2NsYXNz
IGRtb3ZlLGRtX3Jlc3RvcmUJICMgPF9ieXRlY29kZXMkMS4xPnQ0NTUKCWxk
YQkkMTgsMTEoJDMxKQkgI2NsYXNzIGRtb3ZlLGRtX2NvbnN0YW50CSAjIDEx
KFNJNjQpCiAjaW5zdHIKCWxkYQkkMTYsMjYoJDMxKQkgI2NsYXNzIGRtb3Zl
LGRtX2NvbnN0YW50CSAjIDI2KFNJNjQpCi5sb2MgMiAyNgoJYm5lCSQxNSxM
MTMxJDMJICNjbGFzcyBzb3VyY2UJICMgbGluZSAyNiwgPF9EeUNfVGVtcCQx
LjQ4PnQxMTQ1CkwxMzAkMzoKICNpbnN0cgoJc3RxCSQzMSxEeUNSVF9CcmFu
Y2hJbmRleAkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDAsIDB4MChQNjQpLCA8
PnQ1MzYsIGFkZHIoX0R5Q1JUX0JyYW5jaEluZGV4JDEuMCkoUDY0KSwgMChJ
MzIpLCAwKEkzMiksIDAoSTMyKSwgMChJMzIpCglsZGEJJDE0LDEoJDMxKQkg
I2NsYXNzIGRtb3ZlLGRtX2NvbnN0YW50CSAjIDEoU0k2NCkKICNpbnN0cgoJ
bGRhCSQxMyw2KCQzMSkJICNjbGFzcyBkbW92ZSxkbV9jb25zdGFudAkgIyA2
KFNJNjQpCiAjaW5zdHIKCWxkYQkkMTIsMzEoJDMxKQkgI2NsYXNzIGRtb3Zl
LGRtX2NvbnN0YW50CSAjIDMxKFNJNjQpCiAjaW5zdHIKCWJyCSQzMSxMNDIk
MwogI21hcmtfdHJhY2UgMTY5OwpMMTMxJDM6CiAjaW5zdHIKCWxkYQkkMjUs
MygkMzEpCSAjY2xhc3MgZG1vdmUsZG1fY29uc3RhbnQJICMgMyhTSTMyKQoJ
ICMgc3RhbGwgCTEKICNpbnN0cgoubG9jIDIgMjYKCXN0bAkkMjUsMzIoJDE1
KQkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDI2LCAzKFNJMzIpLCA8X0R5Q19U
ZW1wJDEuNDg+dDExNDUsIDMyKEk2NCksIDAoSTMyKSwgMChJMzIpLCAwKEkz
MiksIDAoSTMyKQogI2luc3RyCglsZHEJJDIzLCQyLjEkMnNwaWxsX3AgKyA4
OCgkc3ApCSAjY2xhc3MgZG1vdmUsZG1fcmVzdG9yZQkgIyA8X2J5dGVjb2Rl
cyQxLjE+dDQ1NQogI2luc3RyCglsZGEJJDE2LDI2KCQzMSkJICNjbGFzcyBk
bW92ZSxkbV9jb25zdGFudAkgIyAyNihTSTY0KQoJYnIJJDMxLEwxMzAkMwog
I21hcmtfdHJhY2UgMTE3OwpMMTI3JDM6CiAjaW5zdHIKCW9yCSQxOSwkMzEs
JDI0CSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMCwgPD50NTc3LCA8PnQxMTI3
CiAjaW5zdHIKCW9yCSQzMSwkMzEsJDMxCSAjY2xhc3MgZG1vdmUsZG1fcmVn
aXN0ZXIJICMgPD50NTMzCiAjaW5zdHIKCXN0cQkkMjQsJDIuMSQyc3BpbGxf
cCArIDE2KCRzcCkJICNjbGFzcyBkbW92ZSxkbV9zcGlsbAkgIyA8PnQ1NzcK
ICNpbnN0cgoJYnIJJDMxLEwxMjgkMwogI21hcmtfdHJhY2UgMTIyOwpMMTI2
JDM6CiAjaW5zdHIKCWxkcQkkMjAsJDIuMSQyc3BpbGxfcCArIDIwOCgkc3Ap
CSAjY2xhc3MgZG1vdmUsZG1fcmVzdG9yZQkgIyA8PnQxMTEyCglsZGEJJDE0
LDIoJDMxKQkgI2NsYXNzIGRtb3ZlLGRtX2NvbnN0YW50CSAjIDIoU0k2NCkK
ICNpbnN0cgoJbGRhaAkkMjMsMzIoJDMxKQkgI2NsYXNzIGRtb3ZlLGRtX2Nv
bnN0YW50CSAjIDIwOTcxNTIoSTMyKQogI2luc3RyCglsZGFoCSQyNywtMzIo
JDMxKQkgI2NsYXNzIGRtb3ZlLGRtX2NvbnN0YW50CSAjIDQyOTI4NzAxNDQo
STMyKQogI2luc3RyCi5sb2MgMiAyNgoJYWRkcQkkMjAsNCwkMTIJICNjbGFz
cyBzb3VyY2UJICMgbGluZSAyNiwgPD50MTEzMiwgPD50MTExMiwgNChTSTMy
KQoubG9jIDIgMjYKCWxkbAkkMTEsMCgkMjApCSAjY2xhc3Mgc291cmNlCSAj
IGxpbmUgMjYsIDw+dDExMzYsIDw+dDExMTIsIDAoSTY0KQogI2luc3RyCi5s
b2MgMiAyNgoJc3VicQkkMjEsJDEyLCQ4CSAjY2xhc3Mgc291cmNlCSAjIGxp
bmUgMjYsIDw+dDExMzMsIDw+dDExMjcsIDw+dDExMzIKICNpbnN0cgoubG9j
IDIgMjYKCWFkZGwJJDgsMywkMTIJICNjbGFzcyBzb3VyY2UJICMgbGluZSAy
NiwgPD50NjIzLCA8PnQxMTMzLCAzKFNJMzIpCiAjaW5zdHIKLmxvYyAyIDI2
CgljbW92Z2UJJDgsJDgsJDEyCSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMjYs
IDw+dDYyNCwgPD50MTEzMywgPD50MTEzMywgPD50NjIzCiAjaW5zdHIKLmxv
YyAyIDI2CglsZGEJJDgsLTEoJDIzKQkgI2NsYXNzIHNvdXJjZQkgIyBsaW5l
IDI2LCA8PnQ3NTgsIDIwOTcxNTIoSTMyKSwgLTEoU0k2NCkKICNpbnN0cgou
bG9jIDIgMjYKCXNyYQkkMTIsJDE0LCQxMgkgI2NsYXNzIHNvdXJjZQkgIyBs
aW5lIDI2LCA8PnQxMTM0LCA8PnQ2MjQsIDIoU0k2NCkKICNpbnN0cgoubG9j
IDIgMjYKCWFuZAkkMTEsJDI3LCQxMQkgI2NsYXNzIHNvdXJjZQkgIyBsaW5l
IDI2LCA8PnQxMTM3LCA8PnQxMTM2LCA0MjkyODcwMTQ0KEkzMikKICNpbnN0
cgoubG9jIDIgMjYKCWFuZAkkMTIsJDgsJDgJICNjbGFzcyBzb3VyY2UJICMg
bGluZSAyNiwgPD50MTEzNSwgPD50MTEzNCwgPD50NzU4CgljcHlzCSRmMzEs
JGYzMSwkZjMxCSMgcGFkCiAjaW5zdHIKLmxvYyAyIDI2CglvcgkkOCwkMTEs
JDExCSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMjYsIDw+dDExMzgsIDw+dDEx
MzUsIDw+dDExMzcKLmxvYyAyIDI2CglzdGwJJDExLDAoJDIwKQkgI2NsYXNz
IHNvdXJjZQkgIyBsaW5lIDI2LCA8PnQxMTM4LCA8PnQxMTEyLCAwKEk2NCks
IDAoSTMyKSwgMChJMzIpLCAwKEkzMiksIDAoSTMyKQogI2luc3RyCglvcgkk
MzEsJDMxLCQzMQkgI2NsYXNzIGRtb3ZlLGRtX3JlZ2lzdGVyCSAjIDw+dDUz
MwoJY3B5cwkkZjMxLCRmMzEsJGYzMQkjIHBhZAogI2luc3RyCglvcgkkMjEs
JDMxLCQxOQkgI2NsYXNzIGRtb3ZlLGRtX3JlZ2lzdGVyCSAjIDw+dDExMjcK
CWJlcQkkMjQsTDEzMiQzCSAjY2xhc3Mgc291cmNlLHJlam9pbl9jb3B5CSAj
IGxpbmUgMCwgPD50NTc3CiAjaW5zdHIKCWJyCSQzMSxMMTI4JDMKCWJpcwkk
MzEsJDMxLCQzMQkjIHBhZAogI21hcmtfdHJhY2UgMTgxOwpMMTMyJDM6CiAj
aW5zdHIKCWJyCSQzMSxMMTI3JDMKCWJpcwkkMzEsJDMxLCQzMQkjIHBhZAog
I21hcmtfdHJhY2UgMTI1OwpMMTI0JDM6CiAjaW5zdHIKCW9yCSQzMSwkMzEs
JDI1CSAjY2xhc3Mgc291cmNlLHJlam9pbl9jb3B5CSAjIGxpbmUgMCwgPD50
NTg3LCAwKEkzMikKCWxkcQkkMjcsJDIuMSQyc3BpbGxfcCArIDIwOCgkc3Ap
CSAjY2xhc3MgZG1vdmUsZG1fcmVzdG9yZQkgIyA8PnQxMTEyCiAjaW5zdHIK
CWxkcQkkMTYsJDIuMSQyc3BpbGxfcCArIDIyNCgkc3ApCSAjY2xhc3MgZG1v
dmUsZG1fcmVzdG9yZQkgIyA8PnQxMTE3CglvcgkkMzEsJDMxLCQzMQkgI2Ns
YXNzIGRtb3ZlLGRtX3JlZ2lzdGVyCSAjIDw+dDUzMwogI2luc3RyCglzdGwJ
JDI1LCQyLjEkMnNwaWxsX3AoJHNwKQkgI2NsYXNzIGRtb3ZlLGRtX3NwaWxs
CSAjIDw+dDU4NwoJb3IJJDEzLCQzMSwkMjEJICNjbGFzcyBkbW92ZSxkbV9y
ZWdpc3RlcgkgIyA8PnQxMTI3CiAjaW5zdHIKCWFkZHEJJDI3LDB4NCwkMTQJ
ICNjbGFzcyBzb3VyY2UscmVqb2luX2NvcHkJICMgbGluZSAwLCA8PnQ2MDYs
IDw+dDExMTIsIDB4NChQNjQpCiAjaW5zdHIKCWJyCSQzMSxMMTI1JDMKICNt
YXJrX3RyYWNlIDkyOwpMMTIzJDM6CiAjaW5zdHIKCWxkYQkkMjMsMigkMzEp
CSAjY2xhc3MgZG1vdmUsZG1fY29uc3RhbnQJICMgMihTSTY0KQoJbGRxCSQx
NywkMi4xJDJzcGlsbF9wICsgMjE2KCRzcCkJICNjbGFzcyBkbW92ZSxkbV9y
ZXN0b3JlCSAjIDw+dDExMTQKICNpbnN0cgoubG9jIDIgMjYKCWFkZHEJJDE0
LDQsJDIyCSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMjYsIDw+dDExMjAsIDw+
dDExMTIsIDQoU0kzMikKLmxvYyAyIDI2CglsZGwJJDIxLDAoJDE0KQkgI2Ns
YXNzIHNvdXJjZQkgIyBsaW5lIDI2LCA8PnQxMTI0LCA8PnQxMTEyLCAwKEk2
NCkKICNpbnN0cgoubG9jIDIgMjYKCXN1YnEJJDAsJDIyLCQyMAkgI2NsYXNz
IHNvdXJjZQkgIyBsaW5lIDI2LCA8PnQxMTIxLCA8PnQxMTE4LCA8PnQxMTIw
CiAjaW5zdHIKLmxvYyAyIDI2CglhZGRsCSQyMCwzLCQyMgkgI2NsYXNzIHNv
dXJjZQkgIyBsaW5lIDI2LCA8PnQ2MjEsIDw+dDExMjEsIDMoU0kzMikKICNp
bnN0cgoubG9jIDIgMjYKCWNtb3ZnZQkkMjAsJDIwLCQyMgkgI2NsYXNzIHNv
dXJjZQkgIyBsaW5lIDI2LCA8PnQ2MjIsIDw+dDExMjEsIDw+dDExMjEsIDw+
dDYyMQogI2luc3RyCglsZGFoCSQyMCwzMigkMzEpCSAjY2xhc3MgZG1vdmUs
ZG1fY29uc3RhbnQJICMgMjA5NzE1MihJMzIpCiAjaW5zdHIKLmxvYyAyIDI2
CglzcmEJJDIyLCQyMywkMjIJICNjbGFzcyBzb3VyY2UJICMgbGluZSAyNiwg
PD50MTEyMiwgPD50NjIyLCAyKFNJNjQpCiAjaW5zdHIKLmxvYyAyIDI2Cgls
ZGEJJDIwLC0xKCQyMCkJICNjbGFzcyBzb3VyY2UJICMgbGluZSAyNiwgPD50
NzUyLCAyMDk3MTUyKEkzMiksIC0xKFNJNjQpCiAjaW5zdHIKLmxvYyAyIDI2
CglhbmQJJDIyLCQyMCwkMjIJICNjbGFzcyBzb3VyY2UJICMgbGluZSAyNiwg
PD50MTEyMywgPD50MTEyMiwgPD50NzUyCiAjaW5zdHIKCWxkYWgJJDI3LC0z
MigkMzEpCSAjY2xhc3MgZG1vdmUsZG1fY29uc3RhbnQJICMgNDI5Mjg3MDE0
NChJMzIpCiAjaW5zdHIKCWxkYQkkMjUsMygkMzEpCSAjY2xhc3MgZG1vdmUs
ZG1fY29uc3RhbnQJICMgMyhTSTMyKQogI2luc3RyCi5sb2MgMiAyNgoJYW5k
CSQyMSwkMjcsJDIxCSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMjYsIDw+dDEx
MjUsIDw+dDExMjQsIDQyOTI4NzAxNDQoSTMyKQogI2luc3RyCi5sb2MgMiAy
NgoJb3IJJDIyLCQyMSwkMjIJICNjbGFzcyBzb3VyY2UJICMgbGluZSAyNiwg
PD50MTEyNiwgPD50MTEyMywgPD50MTEyNQoubG9jIDIgMjYKCXN0bAkkMjIs
MCgkMTQpCSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMjYsIDw+dDExMjYsIDw+
dDExMTIsIDAoSTY0KSwgMChJMzIpLCAwKEkzMiksIDAoSTMyKSwgMChJMzIp
CiAjaW5zdHIKLmxvYyAyIDI2CglsZHEJJDIzLGludGVycHJldGVyLkxTVkZy
ZWVMaXN0LjIJICNjbGFzcyBzb3VyY2UJICMgbGluZSAyNiwgPD50MTExOSwg
PD50NTM2LCBhZGRyKGludGVycHJldGVyLkxTVkZyZWVMaXN0LlZBUi4yKShQ
NjQpCgkgIyBzdGFsbCAJMgogI2luc3RyCi5sb2MgMiAyNgoJc3RxCSQyMyww
KCQxNykJICNjbGFzcyBzb3VyY2UJICMgbGluZSAyNiwgPD50MTExOSwgPD50
MTExNCwgMChJNjQpLCAwKEkzMiksIDAoSTMyKSwgMChJMzIpLCAwKEkzMikK
ICNpbnN0cgoubG9jIDIgMjYKCXN0cQkkMTcsaW50ZXJwcmV0ZXIuTFNWRnJl
ZUxpc3QuMgkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDI2LCA8PnQxMTE0LCA8
PnQ1MzYsIGFkZHIoaW50ZXJwcmV0ZXIuTFNWRnJlZUxpc3QuVkFSLjIpKFA2
NCksIDAoSTMyKSwgMChJMzIpLCAwKEkzMiksIDAoSTMyKQoJICMgc3RhbGwg
CTEKICNpbnN0cgoJYmVxCSQyNCxMMTMzJDMJICNjbGFzcyBzb3VyY2UJICMg
bGluZSAwLCA8PnQ1NzcKICNpbnN0cgoJYnIJJDMxLEw2MiQzCiAjbWFya190
cmFjZSAxMjE7CkwxMzMkMzoKICNpbnN0cgoJb3IJJDAsJDMxLCQyNAkgI2Ns
YXNzIHNvdXJjZQkgIyBsaW5lIDAsIDw+dDU3NywgPD50MTExOAoJICMgc3Rh
bGwgCTEKICNtYXJrX3RyYWNlIDEyODsKICNpbnN0cgoJc3RxCSQyNCwkMi4x
JDJzcGlsbF9wICsgMTYoJHNwKQkgI2NsYXNzIGRtb3ZlLGRtX3NwaWxsCSAj
IDw+dDU3NwoJbGRhCSQyNSwzKCQzMSkJICNjbGFzcyBkbW92ZSxkbV9jb25z
dGFudAkgIyAzKFNJMzIpCiAjaW5zdHIKCWJyCSQzMSxMNjIkMwoJYmlzCSQz
MSwkMzEsJDMxCSMgcGFkCiAjbWFya190cmFjZSA4NzsKTDEyMSQzOgogI21h
cmtfY2FsbCBjYWxsZXJfc2F2ZXMsIHJlZ3MsIGF0eXBlcygpLCBydHlwZXMo
bjY0KTsKICNpbnN0cgoJb3IJJDMxLCQzMSwkMzEJICNjbGFzcyBkbW92ZSxk
bV9yZWdpc3RlcgkgIyA8PnQ1MzMKLmxvYyAyIDI2Cglqc3IJJDI2LERZQ19D
QUNIRV9jcmVhdGUKCWJyCSQyNixGQUtFMjUKRkFLRTI1OglsZGdwCSRncCww
KCQyNikJICNjbGFzcyBzb3VyY2UJICMgbGluZSAyNiwgcmFkZHIoRFlDX0NB
Q0hFX2NyZWF0ZSkoUDY0KSwgPD50NTMzCiAjaW5zdHIKCXN0cQkkMCwkMi4x
JDJzcGlsbF9wICsgMjI0KCRzcCkJICNjbGFzcyBkbW92ZSxkbV9zcGlsbAkg
IyA8PnQxMTE3CglvcgkkMCwkMzEsJDE2CSAjY2xhc3MgZG1vdmUsZG1fcmVn
aXN0ZXIJICMgPD50MTExNwogI2luc3RyCglzdHEJJDAsaW50ZXJwcmV0ZXIu
Q2FjaGUuMgkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDAsIDw+dDExMTcsIDw+
dDUzNiwgYWRkcihpbnRlcnByZXRlci5DYWNoZS5WQVIuMikoUDY0KSwgMChJ
MzIpLCAwKEkzMiksIDAoSTMyKSwgMChJMzIpCglsZGEJJDE4LDEoJDMxKQkg
I2NsYXNzIGRtb3ZlLGRtX2NvbnN0YW50CSAjIDEoU0kzMikKICNpbnN0cgoJ
b3IJJDMxLCQzMSwkMzEJICNjbGFzcyBkbW92ZSxkbV9yZWdpc3RlcgkgIyA8
PnQ1MzMKCWxkcQkkMTcsJDIuMSQyc3BpbGxfcCArIDIxNigkc3ApCSAjY2xh
c3MgZG1vdmUsZG1fcmVzdG9yZQkgIyA8PnQxMTE0CgkgIyBzdGFsbCAJMQog
I2luc3RyCglicgkkMzEsTDEyMiQzCgliaXMJJDMxLCQzMSwkMzEJIyBwYWQK
ICNtYXJrX3RyYWNlIDk3OwpMMTE5JDM6CiAjaW5zdHIKLmxvYyAyIDI2Cgls
ZHEJJDE3LGludGVycHJldGVyLkxTVkZyZWVMaXN0LjIJICNjbGFzcyBzb3Vy
Y2UJICMgbGluZSAyNiwgPD50MTExNCwgPD50NTM2LCBhZGRyKGludGVycHJl
dGVyLkxTVkZyZWVMaXN0LlZBUi4yKShQNjQpCglvcgkkMzEsJDMxLCQzMQkg
I2NsYXNzIGRtb3ZlLGRtX3JlZ2lzdGVyCSAjIDw+dDUzMwogI2luc3RyCgls
ZHEJJDE2LGludGVycHJldGVyLkNhY2hlLjIJICNjbGFzcyBzb3VyY2UscmVq
b2luX2NvcHkJICMgbGluZSAwLCA8PnQxMTE3LCA8PnQ1MzYsIGFkZHIoaW50
ZXJwcmV0ZXIuQ2FjaGUuVkFSLjIpKFA2NCkKCSAjIHN0YWxsIAkxCiAjaW5z
dHIKCXN0cQkkMTcsJDIuMSQyc3BpbGxfcCArIDIxNigkc3ApCSAjY2xhc3Mg
ZG1vdmUsZG1fc3BpbGwJICMgPD50MTExNAogI2luc3RyCglzdHEJJDE2LCQy
LjEkMnNwaWxsX3AgKyAyMjQoJHNwKQkgI2NsYXNzIGRtb3ZlLGRtX3NwaWxs
CSAjIDw+dDExMTcKICNpbnN0cgoubG9jIDIgMjYKCWxkcQkkMjcsMCgkMTcp
CSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMjYsIDw+dDExMTUsIDw+dDExMTQs
IDAoSTY0KQoJICMgc3RhbGwgCTIKICNpbnN0cgoubG9jIDIgMjYKCXN0cQkk
MjcsaW50ZXJwcmV0ZXIuTFNWRnJlZUxpc3QuMgkgI2NsYXNzIHNvdXJjZQkg
IyBsaW5lIDI2LCA8PnQxMTE1LCA8PnQ1MzYsIGFkZHIoaW50ZXJwcmV0ZXIu
TFNWRnJlZUxpc3QuVkFSLjIpKFA2NCksIDAoSTMyKSwgMChJMzIpLCAwKEkz
MiksIDAoSTMyKQogI2luc3RyCglicgkkMzEsTDEyMCQzCiAjbWFya190cmFj
ZSAxNDk7Cl8kMS5pbnRlcnByZXRlci5UQUcuNS4yLmR5Y19jb3B5LjA6Cmlu
dGVycHJldGVyLmR5bl9zZXR1cF9iZWdpbl83M18wOgogI2luc3RyCglzdGwJ
JDE3LGludGVycHJldGVyLnJ0Y29uc3RfNzNfMF8wKCQzMSkJICNjbGFzcyBz
b3VyY2UJICMgbGluZSAwLCA8X29mZnNldCQxLjI+dDUyNywgMHgwKFA2NCks
IGludGVycHJldGVyLnJ0Y29uc3RfNzNfMF8wLCAwKEkzMiksIDAoSTMyKSwg
MChJMzIpLCAwKEkzMikKLmxvYyAyIDgzCglhZGRsCSQyMiwxLCQyMgkgI2Ns
YXNzIHNvdXJjZSxyZWpvaW5fY29weQkgIyBsaW5lIDgzLCA8X3BjJDEuMT50
NDU0LCA8X3BjJDEuMT50NDU0LCAxKFNJMzIpCiAjaW5zdHIKCXN0bAkkMjIs
JDIuMSQyc3BpbGxfcCArIDk2KCRzcCkJICNjbGFzcyBkbW92ZSxkbV9zcGls
bAkgIyA8X3BjJDEuMT50NDU0CglvcgkkMzEsJDMxLCQzMQkgI2NsYXNzIGRt
b3ZlLGRtX3JlZ2lzdGVyCSAjIDw+dDUzMwppbnRlcnByZXRlci5keW5fc2V0
dXBfZW5kXzczXzA6CiAjaW5zdHIKCWJyCSQzMSxMMTE4JDMKCWJpcwkkMzEs
JDMxLCQzMQkjIHBhZAogI21hcmtfdHJhY2UgMTYzOwpfJDEuaW50ZXJwcmV0
ZXIuVEFHLjUuMS5keWNfY29weS4wOgppbnRlcnByZXRlci5keW5fc2V0dXBf
YmVnaW5fNzJfMDoKICNpbnN0cgoJc3RsCSQxNyxpbnRlcnByZXRlci5ydGNv
bnN0XzcyXzBfMCgkMzEpCSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMCwgPF9v
ZmZzZXQkMS4yPnQ1MjcsIDB4MChQNjQpLCBpbnRlcnByZXRlci5ydGNvbnN0
XzcyXzBfMCwgMChJMzIpLCAwKEkzMiksIDAoSTMyKSwgMChJMzIpCi5sb2Mg
MiA4MwoJYWRkbAkkMjIsMSwkMjIJICNjbGFzcyBzb3VyY2UscmVqb2luX2Nv
cHkJICMgbGluZSA4MywgPF9wYyQxLjE+dDQ1NCwgPF9wYyQxLjE+dDQ1NCwg
MShTSTMyKQogI2luc3RyCglzdGwJJDIyLCQyLjEkMnNwaWxsX3AgKyA5Nigk
c3ApCSAjY2xhc3MgZG1vdmUsZG1fc3BpbGwJICMgPF9wYyQxLjE+dDQ1NAoJ
b3IJJDMxLCQzMSwkMzEJICNjbGFzcyBkbW92ZSxkbV9yZWdpc3RlcgkgIyA8
PnQ1MzMKaW50ZXJwcmV0ZXIuZHluX3NldHVwX2VuZF83Ml8wOgogI2luc3Ry
CglicgkkMzEsTDExOCQzCgliaXMJJDMxLCQzMSwkMzEJIyBwYWQKICNtYXJr
X3RyYWNlIDE1ODsKXyQxLmludGVycHJldGVyLlRBRy41LjAuZHljX2NvcHku
MDoKaW50ZXJwcmV0ZXIuZHluX3NldHVwX2JlZ2luXzcxXzA6CiAjaW5zdHIK
CXN0bAkkMTcsaW50ZXJwcmV0ZXIucnRjb25zdF83MV8wXzAoJDMxKQkgI2Ns
YXNzIHNvdXJjZQkgIyBsaW5lIDAsIDxfb2Zmc2V0JDEuMj50NTI3LCAweDAo
UDY0KSwgaW50ZXJwcmV0ZXIucnRjb25zdF83MV8wXzAsIDAoSTMyKSwgMChJ
MzIpLCAwKEkzMiksIDAoSTMyKQoubG9jIDIgODMKCWFkZGwJJDIyLDEsJDIy
CSAjY2xhc3Mgc291cmNlLHJlam9pbl9jb3B5CSAjIGxpbmUgODMsIDxfcGMk
MS4xPnQ0NTQsIDxfcGMkMS4xPnQ0NTQsIDEoU0kzMikKICNpbnN0cgoJc3Rs
CSQyMiwkMi4xJDJzcGlsbF9wICsgOTYoJHNwKQkgI2NsYXNzIGRtb3ZlLGRt
X3NwaWxsCSAjIDxfcGMkMS4xPnQ0NTQKCW9yCSQzMSwkMzEsJDMxCSAjY2xh
c3MgZG1vdmUsZG1fcmVnaXN0ZXIJICMgPD50NTMzCmludGVycHJldGVyLmR5
bl9zZXR1cF9lbmRfNzFfMDoKICNpbnN0cgoJYnIJJDMxLEwxMTgkMwoJYmlz
CSQzMSwkMzEsJDMxCSMgcGFkCiAjbWFya190cmFjZSAyMDE7CkwxMTYkMzoK
aW50ZXJwcmV0ZXIuZHluX3NldHVwX2JlZ2luXzY3XzA6CiAjaW5zdHIKCXN0
cQkkMzEsRHlDUlRfRHVtbXlHbG9iYWwJICNjbGFzcyBzb3VyY2UJICMgbGlu
ZSAwLCAweDAoUDY0KSwgPD50NTM2LCBhZGRyKF9EeUNSVF9EdW1teUdsb2Jh
bCQxLjkpKFA2NCksIDAoSTMyKSwgMChJMzIpLCAwKEkzMiksIDAoSTMyKQou
bG9jIDIgODIKCXM0YWRkbAkkMTksJDMxLCQxNgkgI2NsYXNzIHNvdXJjZSxy
ZWpvaW5fY29weQkgIyBsaW5lIDgyLCA8PnQ1MzcsIDxfcnQkMS4yPnQ1Mjks
IDAoSTY0KQogI2luc3RyCi5sb2MgMiA4MwoJYWRkbAkkMjIsMSwkMjIJICNj
bGFzcyBzb3VyY2UscmVqb2luX2NvcHkJICMgbGluZSA4MywgPF9wYyQxLjE+
dDQ1NCwgPF9wYyQxLjE+dDQ1NCwgMShTSTMyKQoJc3RsCSQyMiwkMi4xJDJz
cGlsbF9wICsgOTYoJHNwKQkgI2NsYXNzIGRtb3ZlLGRtX3NwaWxsCSAjIDxf
cGMkMS4xPnQ0NTQKICNpbnN0cgoJc3RxCSQzMSxEeUNSVF9EdW1teUdsb2Jh
bAkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDAsIDB4MChQNjQpLCA8PnQ1MzYs
IGFkZHIoX0R5Q1JUX0R1bW15R2xvYmFsJDEuOSkoUDY0KSwgMChJMzIpLCAw
KEkzMiksIDAoSTMyKSwgMChJMzIpCglvcgkkMzEsJDMxLCQzMQkgI2NsYXNz
IGRtb3ZlLGRtX3JlZ2lzdGVyCSAjIDw+dDUzMwppbnRlcnByZXRlci5keW5f
c2V0dXBfZW5kXzY3XzA6CiAjaW5zdHIKCWJyCSQzMSxMMTE3JDMKCWJpcwkk
MzEsJDMxLCQzMQkjIHBhZAogI21hcmtfdHJhY2UgMTI3OwpfJDEuaW50ZXJw
cmV0ZXIuVEFHLjQuMi5keWNfY29weS4wOgppbnRlcnByZXRlci5keW5fc2V0
dXBfYmVnaW5fNjVfMDoKICNpbnN0cgoJbGRhCSQyMSwxKCQzMSkJICNjbGFz
cyBkbW92ZSxkbV9jb25zdGFudAkgIyAxKFNJNjQpCglzdHEJJDMxLER5Q1JU
X0R1bW15R2xvYmFsCSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMCwgMHgwKFA2
NCksIDw+dDUzNiwgYWRkcihfRHlDUlRfRHVtbXlHbG9iYWwkMS45KShQNjQp
LCAwKEkzMiksIDAoSTMyKSwgMChJMzIpLCAwKEkzMikKICNpbnN0cgoJbGRh
CSQyNywzMSgkMzEpCSAjY2xhc3MgZG1vdmUsZG1fY29uc3RhbnQJICMgMzEo
U0k2NCkKCWNweXMJJGYzMSwkZjMxLCRmMzEJIyBwYWQKICNpbnN0cgoubG9j
IDIgODMKCWNtcGx0CSQxOSwkMjEsJDIxCSAjY2xhc3Mgc291cmNlLHJlam9p
bl9jb3B5CSAjIGxpbmUgODMsIDw+dDQwNiwgPF9ydCQxLjI+dDUyOSwgMShT
STY0KQoJc3RxCSQzMSxEeUNSVF9EdW1teUdsb2JhbAkgI2NsYXNzIHNvdXJj
ZQkgIyBsaW5lIDAsIDB4MChQNjQpLCA8PnQ1MzYsIGFkZHIoX0R5Q1JUX0R1
bW15R2xvYmFsJDEuOSkoUDY0KSwgMChJMzIpLCAwKEkzMiksIDAoSTMyKSwg
MChJMzIpCiAjaW5zdHIKLmxvYyAyIDgzCgljbXBsdAkkMjcsJDE5LCQyNwkg
I2NsYXNzIHNvdXJjZSxyZWpvaW5fY29weQkgIyBsaW5lIDgzLCA8PnQ0MDcs
IDMxKFNJNjQpLCA8X3J0JDEuMj50NTI5CiAjaW5zdHIKLmxvYyAyIDgzCglz
OGFkZGwJJDE5LCQzMSwkMTMJICNjbGFzcyBzb3VyY2UsY3NwZWMscmVqb2lu
X2NvcHkJICMgbGluZSA4MywgPD50OTEyLCA8X3J0JDEuMj50NTI5LCAwKEk2
NCkKICNpbnN0cgoubG9jIDIgODMKCW9yCSQyMSwkMjcsJDE4CSAjY2xhc3Mg
c291cmNlLHJlam9pbl9jb3B5CSAjIGxpbmUgODMsIDw+dDU2NywgPD50NDA2
LCA8PnQ0MDcKICNpbnN0cgoubG9jIDIgODIKCXM0YWRkbAkkMTksJDMxLCQx
NgkgI2NsYXNzIHNvdXJjZSxjc3BlYyxyZWpvaW5fY29weQkgIyBsaW5lIDgy
LCA8PnQ1MzcsIDxfcnQkMS4yPnQ1MjksIDAoSTY0KQogI2luc3RyCglvcgkk
MzEsJDMxLCQzMQkgI2NsYXNzIGRtb3ZlLGRtX3JlZ2lzdGVyCSAjIDw+dDUz
MwoJY3B5cwkkZjMxLCRmMzEsJGYzMQkjIHBhZAppbnRlcnByZXRlci5keW5f
c2V0dXBfZW5kXzY1XzA6CiAjaW5zdHIKCWJyCSQzMSxMMTE1JDMKCWJpcwkk
MzEsJDMxLCQzMQkjIHBhZAogI21hcmtfdHJhY2UgMTI2OwpfJDEuaW50ZXJw
cmV0ZXIuVEFHLjQuMS5keWNfY29weS4wOgppbnRlcnByZXRlci5keW5fc2V0
dXBfYmVnaW5fNjRfMDoKICNpbnN0cgoJbGRhCSQyMSwxKCQzMSkJICNjbGFz
cyBkbW92ZSxkbV9jb25zdGFudAkgIyAxKFNJNjQpCglzdHEJJDMxLER5Q1JU
X0R1bW15R2xvYmFsCSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMCwgMHgwKFA2
NCksIDw+dDUzNiwgYWRkcihfRHlDUlRfRHVtbXlHbG9iYWwkMS45KShQNjQp
LCAwKEkzMiksIDAoSTMyKSwgMChJMzIpLCAwKEkzMikKICNpbnN0cgoJbGRh
CSQyNywzMSgkMzEpCSAjY2xhc3MgZG1vdmUsZG1fY29uc3RhbnQJICMgMzEo
U0k2NCkKCWNweXMJJGYzMSwkZjMxLCRmMzEJIyBwYWQKICNpbnN0cgoubG9j
IDIgODMKCWNtcGx0CSQxOSwkMjEsJDIxCSAjY2xhc3Mgc291cmNlLHJlam9p
bl9jb3B5CSAjIGxpbmUgODMsIDw+dDQwNiwgPF9ydCQxLjI+dDUyOSwgMShT
STY0KQoJc3RxCSQzMSxEeUNSVF9EdW1teUdsb2JhbAkgI2NsYXNzIHNvdXJj
ZQkgIyBsaW5lIDAsIDB4MChQNjQpLCA8PnQ1MzYsIGFkZHIoX0R5Q1JUX0R1
bW15R2xvYmFsJDEuOSkoUDY0KSwgMChJMzIpLCAwKEkzMiksIDAoSTMyKSwg
MChJMzIpCiAjaW5zdHIKLmxvYyAyIDgzCgljbXBsdAkkMjcsJDE5LCQyNwkg
I2NsYXNzIHNvdXJjZSxyZWpvaW5fY29weQkgIyBsaW5lIDgzLCA8PnQ0MDcs
IDMxKFNJNjQpLCA8X3J0JDEuMj50NTI5CiAjaW5zdHIKLmxvYyAyIDgzCglz
OGFkZGwJJDE5LCQzMSwkMTMJICNjbGFzcyBzb3VyY2UsY3NwZWMscmVqb2lu
X2NvcHkJICMgbGluZSA4MywgPD50OTEyLCA8X3J0JDEuMj50NTI5LCAwKEk2
NCkKICNpbnN0cgoubG9jIDIgODMKCW9yCSQyMSwkMjcsJDE4CSAjY2xhc3Mg
c291cmNlLHJlam9pbl9jb3B5CSAjIGxpbmUgODMsIDw+dDU2NywgPD50NDA2
LCA8PnQ0MDcKICNpbnN0cgoubG9jIDIgODIKCXM0YWRkbAkkMTksJDMxLCQx
NgkgI2NsYXNzIHNvdXJjZSxjc3BlYyxyZWpvaW5fY29weQkgIyBsaW5lIDgy
LCA8PnQ1MzcsIDxfcnQkMS4yPnQ1MjksIDAoSTY0KQogI2luc3RyCglvcgkk
MzEsJDMxLCQzMQkgI2NsYXNzIGRtb3ZlLGRtX3JlZ2lzdGVyCSAjIDw+dDUz
MwoJY3B5cwkkZjMxLCRmMzEsJGYzMQkjIHBhZAppbnRlcnByZXRlci5keW5f
c2V0dXBfZW5kXzY0XzA6CiAjaW5zdHIKCWJyCSQzMSxMMTE1JDMKCWJpcwkk
MzEsJDMxLCQzMQkjIHBhZAogI21hcmtfdHJhY2UgMTMwOwpfJDEuaW50ZXJw
cmV0ZXIuVEFHLjQuMC5keWNfY29weS4wOgppbnRlcnByZXRlci5keW5fc2V0
dXBfYmVnaW5fNjNfMDoKICNpbnN0cgoJbGRhCSQyMSwxKCQzMSkJICNjbGFz
cyBkbW92ZSxkbV9jb25zdGFudAkgIyAxKFNJNjQpCglzdHEJJDMxLER5Q1JU
X0R1bW15R2xvYmFsCSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMCwgMHgwKFA2
NCksIDw+dDUzNiwgYWRkcihfRHlDUlRfRHVtbXlHbG9iYWwkMS45KShQNjQp
LCAwKEkzMiksIDAoSTMyKSwgMChJMzIpLCAwKEkzMikKICNpbnN0cgoJbGRh
CSQyNywzMSgkMzEpCSAjY2xhc3MgZG1vdmUsZG1fY29uc3RhbnQJICMgMzEo
U0k2NCkKCWNweXMJJGYzMSwkZjMxLCRmMzEJIyBwYWQKICNpbnN0cgoubG9j
IDIgODMKCWNtcGx0CSQxOSwkMjEsJDIxCSAjY2xhc3Mgc291cmNlLHJlam9p
bl9jb3B5CSAjIGxpbmUgODMsIDw+dDQwNiwgPF9ydCQxLjI+dDUyOSwgMShT
STY0KQoJc3RxCSQzMSxEeUNSVF9EdW1teUdsb2JhbAkgI2NsYXNzIHNvdXJj
ZQkgIyBsaW5lIDAsIDB4MChQNjQpLCA8PnQ1MzYsIGFkZHIoX0R5Q1JUX0R1
bW15R2xvYmFsJDEuOSkoUDY0KSwgMChJMzIpLCAwKEkzMiksIDAoSTMyKSwg
MChJMzIpCiAjaW5zdHIKLmxvYyAyIDgzCgljbXBsdAkkMjcsJDE5LCQyNwkg
I2NsYXNzIHNvdXJjZSxyZWpvaW5fY29weQkgIyBsaW5lIDgzLCA8PnQ0MDcs
IDMxKFNJNjQpLCA8X3J0JDEuMj50NTI5CiAjaW5zdHIKLmxvYyAyIDgzCglz
OGFkZGwJJDE5LCQzMSwkMTMJICNjbGFzcyBzb3VyY2UsY3NwZWMscmVqb2lu
X2NvcHkJICMgbGluZSA4MywgPD50OTEyLCA8X3J0JDEuMj50NTI5LCAwKEk2
NCkKICNpbnN0cgoubG9jIDIgODMKCW9yCSQyMSwkMjcsJDE4CSAjY2xhc3Mg
c291cmNlLHJlam9pbl9jb3B5CSAjIGxpbmUgODMsIDw+dDU2NywgPD50NDA2
LCA8PnQ0MDcKICNpbnN0cgoubG9jIDIgODIKCXM0YWRkbAkkMTksJDMxLCQx
NgkgI2NsYXNzIHNvdXJjZSxjc3BlYyxyZWpvaW5fY29weQkgIyBsaW5lIDgy
LCA8PnQ1MzcsIDxfcnQkMS4yPnQ1MjksIDAoSTY0KQogI2luc3RyCglvcgkk
MzEsJDMxLCQzMQkgI2NsYXNzIGRtb3ZlLGRtX3JlZ2lzdGVyCSAjIDw+dDUz
MwoJY3B5cwkkZjMxLCRmMzEsJGYzMQkjIHBhZAppbnRlcnByZXRlci5keW5f
c2V0dXBfZW5kXzYzXzA6CiAjaW5zdHIKCWJyCSQzMSxMMTE1JDMKCWJpcwkk
MzEsJDMxLCQzMQkjIHBhZAogI21hcmtfdHJhY2UgMTk5OwpMMTEzJDM6Cmlu
dGVycHJldGVyLmR5bl9zZXR1cF9iZWdpbl81OV8wOgogI2luc3RyCglsZGEJ
JDI3LDMxKCQzMSkJICNjbGFzcyBkbW92ZSxkbV9jb25zdGFudAkgIyAzMShT
STY0KQoJc3RxCSQzMSxEeUNSVF9EdW1teUdsb2JhbAkgI2NsYXNzIHNvdXJj
ZQkgIyBsaW5lIDAsIDB4MChQNjQpLCA8PnQ1MzYsIGFkZHIoX0R5Q1JUX0R1
bW15R2xvYmFsJDEuOSkoUDY0KSwgMChJMzIpLCAwKEkzMiksIDAoSTMyKSwg
MChJMzIpCiAjaW5zdHIKLmxvYyAyIDgzCgljbXBsdAkkMTksJDIxLCQyMQkg
I2NsYXNzIHNvdXJjZSxyZWpvaW5fY29weQkgIyBsaW5lIDgzLCA8PnQ0MDYs
IDxfcnQkMS4yPnQ1MjksIDEoU0k2NCkKCWNweXMJJGYzMSwkZjMxLCRmMzEJ
IyBwYWQKICNpbnN0cgoubG9jIDIgODMKCWNtcGx0CSQyNywkMTksJDI3CSAj
Y2xhc3Mgc291cmNlLHJlam9pbl9jb3B5CSAjIGxpbmUgODMsIDw+dDQwNywg
MzEoU0k2NCksIDxfcnQkMS4yPnQ1MjkKCXN0cQkkMzEsRHlDUlRfRHVtbXlH
bG9iYWwJICNjbGFzcyBzb3VyY2UJICMgbGluZSAwLCAweDAoUDY0KSwgPD50
NTM2LCBhZGRyKF9EeUNSVF9EdW1teUdsb2JhbCQxLjkpKFA2NCksIDAoSTMy
KSwgMChJMzIpLCAwKEkzMiksIDAoSTMyKQogI2luc3RyCi5sb2MgMiA3NgoJ
czRhZGRsCSQyMCwkMzEsJDE0CSAjY2xhc3Mgc291cmNlLHJlam9pbl9jb3B5
CSAjIGxpbmUgNzYsIDxfc3VidDEkMS4yPnQ1MzgsIDxfcnMkMS4yPnQ1MzAs
IDAoSTY0KQogI2luc3RyCi5sb2MgMiA4MwoJb3IJJDIxLCQyNywkMTgJICNj
bGFzcyBzb3VyY2UscmVqb2luX2NvcHkJICMgbGluZSA4MywgPD50NTY3LCA8
PnQ0MDYsIDw+dDQwNwogI2luc3RyCi5sb2MgMiA4MwoJczhhZGRsCSQxOSwk
MzEsJDEzCSAjY2xhc3Mgc291cmNlLGNzcGVjLHJlam9pbl9jb3B5CSAjIGxp
bmUgODMsIDw+dDkxMiwgPF9ydCQxLjI+dDUyOSwgMChJNjQpCiAjaW5zdHIK
LmxvYyAyIDgyCglzNGFkZGwJJDE5LCQzMSwkMTYJICNjbGFzcyBzb3VyY2Us
Y3NwZWMscmVqb2luX2NvcHkJICMgbGluZSA4MiwgPD50NTM3LCA8X3J0JDEu
Mj50NTI5LCAwKEk2NCkKICNpbnN0cgoJb3IJJDMxLCQzMSwkMzEJICNjbGFz
cyBkbW92ZSxkbV9yZWdpc3RlcgkgIyA8PnQ1MzMKCWNweXMJJGYzMSwkZjMx
LCRmMzEJIyBwYWQKaW50ZXJwcmV0ZXIuZHluX3NldHVwX2VuZF81OV8wOgog
I2luc3RyCglicgkkMzEsTDExNCQzCgliaXMJJDMxLCQzMSwkMzEJIyBwYWQK
ICNtYXJrX3RyYWNlIDQ5OwpfJDEuaW50ZXJwcmV0ZXIuVEFHLjguMy5keWNf
Y29weS4wOgppbnRlcnByZXRlci5keW5fc2V0dXBfYmVnaW5fNTdfMDoKICNp
bnN0cgoJc3RxCSQzMSxEeUNSVF9EdW1teUdsb2JhbAkgI2NsYXNzIHNvdXJj
ZQkgIyBsaW5lIDAsIDB4MChQNjQpLCA8PnQ1MzYsIGFkZHIoX0R5Q1JUX0R1
bW15R2xvYmFsJDEuOSkoUDY0KSwgMChJMzIpLCAwKEkzMiksIDAoSTMyKSwg
MChJMzIpCglvcgkkMzEsJDMxLCQzMQkgI2NsYXNzIGRtb3ZlLGRtX3JlZ2lz
dGVyCSAjIDw+dDUzMwoJICMgc3RhbGwgCTEKICNpbnN0cgoJc3RxCSQzMSxE
eUNSVF9EdW1teUdsb2JhbAkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDAsIDB4
MChQNjQpLCA8PnQ1MzYsIGFkZHIoX0R5Q1JUX0R1bW15R2xvYmFsJDEuOSko
UDY0KSwgMChJMzIpLCAwKEkzMiksIDAoSTMyKSwgMChJMzIpCiAjbWFya19j
YWxsIGNhbGxlcl9zYXZlcywgcmVncywgYXR5cGVzKCksIHJ0eXBlcygpOwog
I2luc3RyCi5sb2MgMiAyNgoJanNyCSQyNixEeUNSVF9QYXRjaEludHJhVW5p
dEJyYW5jaGVzCglicgkkMjYsRkFLRTIyCkZBS0UyMjoJbGRncAkkZ3AsMCgk
MjYpCSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMjYsIHJhZGRyKER5Q1JUX1Bh
dGNoSW50cmFVbml0QnJhbmNoZXMpKFA2NCksIDw+dDUzMwppbnRlcnByZXRl
ci5keW5fc2V0dXBfZW5kXzU3XzA6CiAjaW5zdHIKCXN0cQkkMzEsRHlDUlRf
Q29kZUxvY2F0aW9uCSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMCwgMHgwKFA2
NCksIDw+dDUzNiwgYWRkcihfRHlDUlRfQ29kZUxvY2F0aW9uJDEuMCkoUDY0
KSwgMChJMzIpLCAwKEkzMiksIDAoSTMyKSwgMChJMzIpCiAjbWFya190cmFj
ZSA0ODsKICNpbnN0cgoJbGRhCSQyNSwzKCQzMSkJICNjbGFzcyBkbW92ZSxk
bV9jb25zdGFudAkgIyAzKFNJMzIpCiAjaW5zdHIKCWJyCSQzMSxMNjIkMwoJ
YmlzCSQzMSwkMzEsJDMxCSMgcGFkCiAjbWFya190cmFjZSA0NjsKXyQxLmlu
dGVycHJldGVyLlRBRy44LjIuZHljX2NvcHkuMDoKaW50ZXJwcmV0ZXIuZHlu
X3NldHVwX2JlZ2luXzM4XzA6CiAjaW5zdHIKCXN0bAkkMTcsJDIuMSQyc3Bp
bGxfcCArIDE2OCgkc3ApCSAjY2xhc3MgZG1vdmUsZG1fc3BpbGwJICMgPF9v
ZmZzZXQkMS4yPnQ1MjcKCWxkYQkkMjEsMSgkMzEpCSAjY2xhc3MgZG1vdmUs
ZG1fY29uc3RhbnQJICMgMShTSTY0KQogI2luc3RyCglzdGwJJDIyLCQyLjEk
MnNwaWxsX3AgKyA5Nigkc3ApCSAjY2xhc3MgZG1vdmUsZG1fc3BpbGwJICMg
PF9wYyQxLjE+dDQ1NAoJbGRhCSQxOCwzMSgkMzEpCSAjY2xhc3MgZG1vdmUs
ZG1fY29uc3RhbnQJICMgMzEoU0k2NCkKICNpbnN0cgoubG9jIDIgOTMKCWNt
cGx0CSQyMCwkMjEsJDIxCSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgOTMsIDw+
dDQxNSwgPF9ycyQxLjI+dDUzMCwgMShTSTY0KQogI2luc3RyCi5sb2MgMiA5
MwoJY21wbHQJJDE4LCQyMCwkMTgJICNjbGFzcyBzb3VyY2UJICMgbGluZSA5
MywgPD50NDE2LCAzMShTSTY0KSwgPF9ycyQxLjI+dDUzMAogI2luc3RyCi5s
b2MgMiA5MwoJczhhZGRsCSQyMCwkMzEsJDE2CSAjY2xhc3Mgc291cmNlLGNz
cGVjCSAjIGxpbmUgOTMsIDw+dDkwMywgPF9ycyQxLjI+dDUzMCwgMChJNjQp
CiAjaW5zdHIKLmxvYyAyIDkzCglvcgkkMjEsJDE4LCQxOAkgI2NsYXNzIHNv
dXJjZQkgIyBsaW5lIDkzLCA8PnQ1NjgsIDw+dDQxNSwgPD50NDE2CiAjaW5z
dHIKLmxvYyAyIDkyCglzNGFkZGwJJDIwLCQzMSwkMTQJICNjbGFzcyBzb3Vy
Y2UsY3NwZWMJICMgbGluZSA5MiwgPF9iZXQxJDEuMj50NTQwLCA8X3JzJDEu
Mj50NTMwLCAwKEk2NCkKCWNweXMJJGYzMSwkZjMxLCRmMzEJIyBwYWQKaW50
ZXJwcmV0ZXIuZHluX3NldHVwX2VuZF8zOF8wOgogI2luc3RyCglsZGEJJDIx
LDEoJDMxKQkgI2NsYXNzIGRtb3ZlLGRtX2NvbnN0YW50CSAjIDEoU0k2NCkK
LmxvYyAyIDkzCglibmUJJDE4LEwxMzQkMwkgI2NsYXNzIHNvdXJjZQkgIyBs
aW5lIDkzLCA8PnQ1NjgKaW50ZXJwcmV0ZXIuZHluX3NldHVwX2JlZ2luXzQw
XzA6CiAjaW5zdHIKLmxvYyAyIDkzCglsZHEJJDE2LGludGVycHJldGVyJDJE
WUMuU1dJVENIQ09QWS5UQUdQQUNLRVQuMS4wLTgoJDE2KQkgI2NsYXNzIHNv
dXJjZQkgIyBsaW5lIDkzLCA8PnQ0MTgsIDw+dDkwMywgKGFkZHIoaW50ZXJw
cmV0ZXIkMkRZQy5TV0lUQ0hDT1BZLlRBR0FSUkFZLjEuMCkoUDY0KSAtIDB4
OChJNjQpKShQNjQpCglsZGEJJDE4LDMxKCQzMSkJICNjbGFzcyBkbW92ZSxk
bV9jb25zdGFudAkgIyAzMShTSTY0KQogI2luc3RyCi5sb2MgMiA5OQoJY21w
bHQJJDE5LCQyMSwkMjEJICNjbGFzcyBzb3VyY2UsY3NwZWMJICMgbGluZSA5
OSwgPD50NDMwLCA8X3J0JDEuMj50NTI5LCAxKFNJNjQpCiAjaW5zdHIKLmxv
YyAyIDk5CgljbXBsdAkkMTgsJDE5LCQxOAkgI2NsYXNzIHNvdXJjZSxjc3Bl
YwkgIyBsaW5lIDk5LCA8PnQ0MzEsIDMxKFNJNjQpLCA8X3J0JDEuMj50NTI5
CmludGVycHJldGVyLmR5bl9zZXR1cF9lbmRfNDBfMDoKICNpbnN0cgoubG9j
IDIgOTkKCXM4YWRkbAkkMTksJDMxLCQxMwkgI2NsYXNzIHNvdXJjZSxjc3Bl
YwkgIyBsaW5lIDk5LCA8PnQ4OTgsIDxfcnQkMS4yPnQ1MjksIDAoSTY0KQou
bG9jIDIgOTMKCWptcAkkMzEsKCQxNikJICNjbGFzcyBzb3VyY2UJICMgbGlu
ZSA5MywgPD50NDE4Cl8kMS5pbnRlcnByZXRlci5UQUcuNi5ERUZBVUxULmR5
Y19jb3B5LjA6CmludGVycHJldGVyLmR5bl9zZXR1cF9iZWdpbl80MV8wOgog
I2luc3RyCi5sb2MgMiA5OQoJb3IJJDIxLCQxOCwkMTgJICNjbGFzcyBzb3Vy
Y2UJICMgbGluZSA5OSwgPD50NTY5LCA8PnQ0MzAsIDw+dDQzMQoJY3B5cwkk
ZjMxLCRmMzEsJGYzMQkjIHBhZAogI2luc3RyCglzdHEJJDMxLER5Q1JUX0R1
bW15R2xvYmFsCSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMCwgMHgwKFA2NCks
IDw+dDUzNiwgYWRkcihfRHlDUlRfRHVtbXlHbG9iYWwkMS45KShQNjQpLCAw
KEkzMiksIDAoSTMyKSwgMChJMzIpLCAwKEkzMikKLmxvYyAyIDk4CglzNGFk
ZGwJJDE5LCQzMSwkMTYJICNjbGFzcyBzb3VyY2UsY3NwZWMJICMgbGluZSA5
OCwgPD50NTM5LCA8X3J0JDEuMj50NTI5LCAwKEk2NCkKICNpbnN0cgoJb3IJ
JDMxLCQzMSwkMzEJICNjbGFzcyBkbW92ZSxkbV9yZWdpc3RlcgkgIyA8PnQ1
MzMKaW50ZXJwcmV0ZXIuZHluX3NldHVwX2VuZF80MV8wOgogI2luc3RyCglz
dHEJJDMxLER5Q1JUX0R1bW15R2xvYmFsCSAjY2xhc3Mgc291cmNlCSAjIGxp
bmUgMCwgMHgwKFA2NCksIDw+dDUzNiwgYWRkcihfRHlDUlRfRHVtbXlHbG9i
YWwkMS45KShQNjQpLCAwKEkzMiksIDAoSTMyKSwgMChJMzIpLCAwKEkzMikK
TDEzNSQzOgppbnRlcnByZXRlci5keW5fc2V0dXBfYmVnaW5fNDJfMDoKICNp
bnN0cgogI2luc3RyCglzdGwJJDIwLGludGVycHJldGVyLnJ0Y29uc3RfNDJf
MF8wKCQzMSkJICNjbGFzcyBzb3VyY2UJICMgbGluZSAwLCA8X3JzJDEuMj50
NTMwLCAweDAoUDY0KSwgaW50ZXJwcmV0ZXIucnRjb25zdF80Ml8wXzAsIDAo
STMyKSwgMChJMzIpLCAwKEkzMiksIDAoSTMyKQoJICMgc3RhbGwgCTEKaW50
ZXJwcmV0ZXIuZHluX3NldHVwX2VuZF80Ml8wOgogI2luc3RyCglzdHEJJDE0
LGludGVycHJldGVyLnJ0Y29uc3RfNDJfMF8xKCQzMSkJICNjbGFzcyBzb3Vy
Y2UJICMgbGluZSAwLCA8X2JldDEkMS4yPnQ1NDAsIDB4MChQNjQpLCBpbnRl
cnByZXRlci5ydGNvbnN0XzQyXzBfMSwgMChJMzIpLCAwKEkzMiksIDAoSTMy
KSwgMChJMzIpCkwxMzYkMzoKaW50ZXJwcmV0ZXIuZHluX3NldHVwX2JlZ2lu
XzQ2XzA6CiAjaW5zdHIKaW50ZXJwcmV0ZXIuZHluX3NldHVwX2VuZF80Nl8w
OgogI2luc3RyCi5sb2MgMiA5OQoJYm5lCSQxOCxMMTM3JDMJICNjbGFzcyBz
b3VyY2UJICMgbGluZSA5OSwgPD50NTY5CmludGVycHJldGVyLmR5bl9zZXR1
cF9iZWdpbl80OF8wOgogI2luc3RyCi5sb2MgMiA5OQoJbGRxCSQxMyxpbnRl
cnByZXRlciQyRFlDLlNXSVRDSENPUFkuVEFHUEFDS0VULjAuMC04KCQxMykJ
ICNjbGFzcyBzb3VyY2UJICMgbGluZSA5OSwgPD50NDMzLCA8PnQ4OTgsIChh
ZGRyKGludGVycHJldGVyJDJEWUMuU1dJVENIQ09QWS5UQUdBUlJBWS4wLjAp
KFA2NCkgLSAweDgoSTY0KSkoUDY0KQoJICMgc3RhbGwgCTIKaW50ZXJwcmV0
ZXIuZHluX3NldHVwX2VuZF80OF8wOgogI2luc3RyCi5sb2MgMiA5OQoJam1w
CSQzMSwoJDEzKQkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDk5LCA8PnQ0MzMK
XyQxLmludGVycHJldGVyLlRBRy43LkRFRkFVTFQuZHljX2NvcHkuMDoKaW50
ZXJwcmV0ZXIuZHluX3NldHVwX2JlZ2luXzQ5XzA6CiAjaW5zdHIKICNpbnN0
cgoJc3RxCSQzMSxEeUNSVF9EdW1teUdsb2JhbAkgI2NsYXNzIHNvdXJjZQkg
IyBsaW5lIDAsIDB4MChQNjQpLCA8PnQ1MzYsIGFkZHIoX0R5Q1JUX0R1bW15
R2xvYmFsJDEuOSkoUDY0KSwgMChJMzIpLCAwKEkzMiksIDAoSTMyKSwgMChJ
MzIpCgkgIyBzdGFsbCAJMQppbnRlcnByZXRlci5keW5fc2V0dXBfZW5kXzQ5
XzA6CiAjaW5zdHIKCXN0cQkkMzEsRHlDUlRfRHVtbXlHbG9iYWwJICNjbGFz
cyBzb3VyY2UJICMgbGluZSAwLCAweDAoUDY0KSwgPD50NTM2LCBhZGRyKF9E
eUNSVF9EdW1teUdsb2JhbCQxLjkpKFA2NCksIDAoSTMyKSwgMChJMzIpLCAw
KEkzMiksIDAoSTMyKQpMMTM4JDM6CmludGVycHJldGVyLmR5bl9zZXR1cF9i
ZWdpbl81MF8wOgogI2luc3RyCiAjaW5zdHIKCXN0bAkkMTksaW50ZXJwcmV0
ZXIucnRjb25zdF81MF8wXzAoJDMxKQkgI2NsYXNzIHNvdXJjZQkgIyBsaW5l
IDAsIDxfcnQkMS4yPnQ1MjksIDB4MChQNjQpLCBpbnRlcnByZXRlci5ydGNv
bnN0XzUwXzBfMCwgMChJMzIpLCAwKEkzMiksIDAoSTMyKSwgMChJMzIpCgkg
IyBzdGFsbCAJMQppbnRlcnByZXRlci5keW5fc2V0dXBfZW5kXzUwXzA6CiAj
aW5zdHIKCXN0cQkkMTYsaW50ZXJwcmV0ZXIucnRjb25zdF81MF8wXzEoJDMx
KQkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDAsIDw+dDUzOSwgMHgwKFA2NCks
IGludGVycHJldGVyLnJ0Y29uc3RfNTBfMF8xLCAwKEkzMiksIDAoSTMyKSwg
MChJMzIpLCAwKEkzMikKTDEzOSQzOgppbnRlcnByZXRlci5keW5fc2V0dXBf
YmVnaW5fNTRfMDoKICNpbnN0cgogI2luc3RyCglzdHEJJDMxLER5Q1JUX0R1
bW15R2xvYmFsCSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMCwgMHgwKFA2NCks
IDw+dDUzNiwgYWRkcihfRHlDUlRfRHVtbXlHbG9iYWwkMS45KShQNjQpLCAw
KEkzMiksIDAoSTMyKSwgMChJMzIpLCAwKEkzMikKCSAjIHN0YWxsIAkxCiAj
aW5zdHIKCXN0cQkkMzEsRHlDUlRfRHVtbXlHbG9iYWwJICNjbGFzcyBzb3Vy
Y2UJICMgbGluZSAwLCAweDAoUDY0KSwgPD50NTM2LCBhZGRyKF9EeUNSVF9E
dW1teUdsb2JhbCQxLjkpKFA2NCksIDAoSTMyKSwgMChJMzIpLCAwKEkzMiks
IDAoSTMyKQogI21hcmtfY2FsbCBjYWxsZXJfc2F2ZXMsIHJlZ3MsIGF0eXBl
cygpLCBydHlwZXMoKTsKICNpbnN0cgoubG9jIDIgMjYKCWpzcgkkMjYsRHlD
UlRfUGF0Y2hJbnRyYVVuaXRCcmFuY2hlcwoJYnIJJDI2LEZBS0UxNgpGQUtF
MTY6CWxkZ3AJJGdwLDAoJDI2KQkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDI2
LCByYWRkcihEeUNSVF9QYXRjaEludHJhVW5pdEJyYW5jaGVzKShQNjQpLCA8
PnQ1MzMKICNpbnN0cgoJc3RxCSQzMSxEeUNSVF9Db2RlTG9jYXRpb24JICNj
bGFzcyBzb3VyY2UJICMgbGluZSAwLCAweDAoUDY0KSwgPD50NTM2LCBhZGRy
KF9EeUNSVF9Db2RlTG9jYXRpb24kMS4wKShQNjQpLCAwKEkzMiksIDAoSTMy
KSwgMChJMzIpLCAwKEkzMikKCWxkYQkkMTksMSgkMzEpCSAjY2xhc3MgZG1v
dmUsZG1fY29uc3RhbnQJICMgMShJMzIpCiAjaW5zdHIKLmxvYyAyIDI2Cgls
ZHEJJDIxLGludGVycHJldGVyLkxTVkZyZWVMaXN0LjMJICNjbGFzcyBzb3Vy
Y2UJICMgbGluZSAyNiwgPD50MTE4NiwgPD50NTM2LCBhZGRyKGludGVycHJl
dGVyLkxTVkZyZWVMaXN0LlZBUi4zKShQNjQpCi5sb2MgMiAyNgoJbGRhCSQx
NCxpbnRlcnByZXRlci5EWUMuR0VfRU5UUlkuRUFHRVIuMwkgI2NsYXNzIHNv
dXJjZSxjc3BlYwkgIyBsaW5lIDI2LCA8PnQ3OTMsIDw+dDUzNiwgdGFnKGlu
dGVycHJldGVyLkRZQy5HRV9FTlRSWS5FQUdFUi4zKShQNjQpCiAjaW5zdHIK
CWxkbAkkMjIsJDIuMSQyc3BpbGxfcCArIDk2KCRzcCkJICNjbGFzcyBkbW92
ZSxkbV9yZXN0b3JlCSAjIDxfcGMkMS4xPnQ0NTQKCWxkYQkkMTgsMSgkMzEp
CSAjY2xhc3MgZG1vdmUsZG1fY29uc3RhbnQJICMgMShTSTMyKQogI2luc3Ry
CglsZHEJJDIzLCQyLjEkMnNwaWxsX3AgKyA4OCgkc3ApCSAjY2xhc3MgZG1v
dmUsZG1fcmVzdG9yZQkgIyA8X2J5dGVjb2RlcyQxLjE+dDQ1NQoJb3IJJDMx
LCQzMSwkMzEJICNjbGFzcyBkbW92ZSxkbV9yZWdpc3RlcgkgIyA8PnQ1MzMK
aW50ZXJwcmV0ZXIuZHluX3NldHVwX2VuZF81NF8wOgogI2luc3RyCglsZGwJ
JDEzLCQyLjEkMnNwaWxsX3AgKyAxNjgoJHNwKQkgI2NsYXNzIGRtb3ZlLGRt
X3Jlc3RvcmUJICMgPF9vZmZzZXQkMS4yPnQ1MjcKLmxvYyAyIDI2CglibmUJ
JDIxLEwxNDAkMwkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDI2LCA8PnQxMTg2
CiAjaW5zdHIKLmxvYyAyIDI2CglsZHEJJDIxLER5Q1JUX1RlbXBMb2NhdGlv
bgkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDI2LCA8PnQxMTg3LCA8PnQ1MzYs
IGFkZHIoX0R5Q1JUX1RlbXBMb2NhdGlvbiQxLjApKFA2NCkKCWNweXMJJGYz
MSwkZjMxLCRmMzEJIyBwYWQKCSAjIHN0YWxsIAkyCiAjaW5zdHIKLmxvYyAy
IDI2CglhZGRxCSQyMSwyNCwkMTIJICNjbGFzcyBzb3VyY2UJICMgbGluZSAy
NiwgPF9EeUNSVF9UZW1wTG9jYXRpb24kMS4wPnQxMTg5LCA8PnQxMTg3LCAy
NChJMzIpCi5sb2MgMiAyNgoJc3RxCSQxMixEeUNSVF9UZW1wTG9jYXRpb24J
ICNjbGFzcyBzb3VyY2UJICMgbGluZSAyNiwgPF9EeUNSVF9UZW1wTG9jYXRp
b24kMS4wPnQxMTg5LCA8PnQ1MzYsIGFkZHIoX0R5Q1JUX1RlbXBMb2NhdGlv
biQxLjApKFA2NCksIDAoSTMyKSwgMChJMzIpLCAwKEkzMiksIDAoSTMyKQpM
MTQxJDM6CiAjaW5zdHIKCXN0bAkkMjIsMCgkMjEpCSAjY2xhc3Mgc291cmNl
CSAjIGxpbmUgMCwgPF9wYyQxLjE+dDQ1NCwgPD50MTE4NywgMChTSTMyKSwg
MChJMzIpLCAwKEkzMiksIDAoSTMyKSwgMChJMzIpCiAjaW5zdHIKCXN0bAkk
MzEsNCgkMjEpCSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMCwgMChTSTMyKSwg
PD50MTE4NywgNChTSTMyKSwgMChJMzIpLCAwKEkzMiksIDAoSTMyKSwgMChJ
MzIpCiAjaW5zdHIKCXN0cQkkMjMsOCgkMjEpCSAjY2xhc3Mgc291cmNlCSAj
IGxpbmUgMCwgPF9ieXRlY29kZXMkMS4xPnQ0NTUsIDw+dDExODcsIDgoU0kz
MiksIDAoSTMyKSwgMChJMzIpLCAwKEkzMiksIDAoSTMyKQogI2luc3RyCglz
dGwJJDEzLDE2KCQyMSkJICNjbGFzcyBzb3VyY2UJICMgbGluZSAwLCA8X29m
ZnNldCQxLjI+dDUyNywgPD50MTE4NywgMTYoU0kzMiksIDAoSTMyKSwgMChJ
MzIpLCAwKEkzMiksIDAoSTMyKQogI2luc3RyCglzdGwJJDMxLDIwKCQyMSkJ
ICNjbGFzcyBzb3VyY2UJICMgbGluZSAwLCAwKFNJMzIpLCA8PnQxMTg3LCAy
MChTSTMyKSwgMChJMzIpLCAwKEkzMiksIDAoSTMyKSwgMChJMzIpCiAjaW5z
dHIKLmxvYyAyIDI2CglsZHEJJDEyLER5Q1JUX1dvcmtMaXN0RnJlZUxpc3QJ
ICNjbGFzcyBzb3VyY2UJICMgbGluZSAyNiwgPD50MTE5MCwgPD50NTM2LCBh
ZGRyKF9EeUNSVF9Xb3JrTGlzdEZyZWVMaXN0JDEuMCkoUDY0KQoJICMgc3Rh
bGwgCTIKICNpbnN0cgoubG9jIDIgMjYKCWJuZQkkMTIsTDE0MiQzCSAjY2xh
c3Mgc291cmNlCSAjIGxpbmUgMjYsIDw+dDExOTAKICNpbnN0cgoubG9jIDIg
MjYKCWxkcQkkMTIsRHlDUlRfVGVtcExvY2F0aW9uCSAjY2xhc3Mgc291cmNl
CSAjIGxpbmUgMjYsIDw+dDExOTEsIDw+dDUzNiwgYWRkcihfRHlDUlRfVGVt
cExvY2F0aW9uJDEuMCkoUDY0KQogI2luc3RyCglsZHEJJDExLER5Q1JUX0xh
c3RCcmFuY2gJICNjbGFzcyBzb3VyY2UJICMgbGluZSAwLCA8PnQxMTk0LCA8
PnQ1MzYsIGFkZHIoX0R5Q1JUX0xhc3RCcmFuY2gkMS4wKShQNjQpCgljcHlz
CSRmMzEsJGYzMSwkZjMxCSMgcGFkCgkgIyBzdGFsbCAJMQogI2luc3RyCi5s
b2MgMiAyNgoJYWRkcQkkMTIsNDgsJDgJICNjbGFzcyBzb3VyY2UJICMgbGlu
ZSAyNiwgPF9EeUNSVF9UZW1wTG9jYXRpb24kMS4wPnQxMTkzLCA8PnQxMTkx
LCA0OChTSTMyKQoubG9jIDIgMjYKCXN0cQkkOCxEeUNSVF9UZW1wTG9jYXRp
b24JICNjbGFzcyBzb3VyY2UJICMgbGluZSAyNiwgPF9EeUNSVF9UZW1wTG9j
YXRpb24kMS4wPnQxMTkzLCA8PnQ1MzYsIGFkZHIoX0R5Q1JUX1RlbXBMb2Nh
dGlvbiQxLjApKFA2NCksIDAoSTMyKSwgMChJMzIpLCAwKEkzMiksIDAoSTMy
KQpMMTQzJDM6CiAjaW5zdHIKLmxvYyAyIDI2CglzdGwJJDE5LDMyKCQxMikJ
ICNjbGFzcyBzb3VyY2UJICMgbGluZSAyNiwgMShJMzIpLCA8PnQxMTkxLCAz
MihJNjQpLCAwKEkzMiksIDAoSTMyKSwgMChJMzIpLCAwKEkzMikKICNpbnN0
cgoubG9jIDIgMjYKCXN0bAkkMTksMjgoJDEyKQkgI2NsYXNzIHNvdXJjZQkg
IyBsaW5lIDI2LCAxKEkzMiksIDw+dDExOTEsIDI4KEk2NCksIDAoSTMyKSwg
MChJMzIpLCAwKEkzMiksIDAoSTMyKQogI2luc3RyCi5sb2MgMiAyNgoJc3Rs
CSQxOSwyNCgkMTIpCSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMjYsIDEoSTMy
KSwgPD50MTE5MSwgMjQoSTY0KSwgMChJMzIpLCAwKEkzMiksIDAoSTMyKSwg
MChJMzIpCiAjaW5zdHIKLmxvYyAyIDI2CglzdHEJJDIxLDgoJDEyKQkgI2Ns
YXNzIHNvdXJjZQkgIyBsaW5lIDI2LCA8PnQxMTg3LCA8PnQxMTkxLCA4KEk2
NCksIDAoSTMyKSwgMChJMzIpLCAwKEkzMiksIDAoSTMyKQogI2luc3RyCi5s
b2MgMiAyNgoJc3RxCSQxNCwwKCQxMikJICNjbGFzcyBzb3VyY2UJICMgbGlu
ZSAyNiwgPD50NzkzLCA8PnQxMTkxLCAwKEk2NCksIDAoSTMyKSwgMChJMzIp
LCAwKEkzMiksIDAoSTMyKQogI2luc3RyCi5sb2MgMiAyNgoJc3RxCSQxMSwx
NigkMTIpCSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMjYsIDw+dDExOTQsIDw+
dDExOTEsIDE2KEk2NCksIDAoSTMyKSwgMChJMzIpLCAwKEkzMiksIDAoSTMy
KQogI2luc3RyCi5sb2MgMiAyNgoJbGRxCSQyMSxEeUNSVF9Xb3JrTGlzdAkg
I2NsYXNzIHNvdXJjZQkgIyBsaW5lIDI2LCA8X0R5Q1JUX1dvcmtMaXN0JDEu
MD50MTgxLCA8PnQ1MzYsIGFkZHIoX0R5Q1JUX1dvcmtMaXN0JDEuMCkoUDY0
KQoJICMgc3RhbGwgCTIKICNpbnN0cgoubG9jIDIgMjYKCXN0cQkkMjEsNDAo
JDEyKQkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDI2LCA8X0R5Q1JUX1dvcmtM
aXN0JDEuMD50MTgxLCA8PnQxMTkxLCA0MChJNjQpLCAwKEkzMiksIDAoSTMy
KSwgMChJMzIpLCAwKEkzMikKICNpbnN0cgoubG9jIDIgMjYKCXN0cQkkMTIs
RHlDUlRfV29ya0xpc3QJICNjbGFzcyBzb3VyY2UJICMgbGluZSAyNiwgPD50
MTE5MSwgPD50NTM2LCBhZGRyKF9EeUNSVF9Xb3JrTGlzdCQxLjApKFA2NCks
IDAoSTMyKSwgMChJMzIpLCAwKEkzMiksIDAoSTMyKQogI2luc3RyCglsZHEJ
JDIxLER5Q1JUX0xhc3RCcmFuY2gyCSAjY2xhc3Mgc291cmNlCSAjIGxpbmUg
MCwgPD50MTE0OSwgPD50NTM2LCBhZGRyKF9EeUNSVF9MYXN0QnJhbmNoMiQx
LjApKFA2NCkKICNpbnN0cgoubG9jIDIgMjYKCWxkcQkkMTQsaW50ZXJwcmV0
ZXIuTFNWRnJlZUxpc3QuNAkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDI2LCA8
PnQxMTUwLCA8PnQ1MzYsIGFkZHIoaW50ZXJwcmV0ZXIuTFNWRnJlZUxpc3Qu
VkFSLjQpKFA2NCkKCSAjIHN0YWxsIAkxCiAjaW5zdHIKCXN0cQkkMjEsJDIu
MSQyc3BpbGxfcCArIDI0MCgkc3ApCSAjY2xhc3MgZG1vdmUsZG1fc3BpbGwJ
ICMgPD50MTE0OQogI2luc3RyCi5sb2MgMiAyNgoJYm5lCSQxNCxMMTQ0JDMJ
ICNjbGFzcyBzb3VyY2UJICMgbGluZSAyNiwgPD50MTE1MAogI2luc3RyCi5s
b2MgMiAyNgoJbGRxCSQxNyxEeUNSVF9UZW1wTG9jYXRpb24JICNjbGFzcyBz
b3VyY2UJICMgbGluZSAyNiwgPD50MTE1MSwgPD50NTM2LCBhZGRyKF9EeUNS
VF9UZW1wTG9jYXRpb24kMS4wKShQNjQpCiAjaW5zdHIKCWxkcQkkMTYsaW50
ZXJwcmV0ZXIuQ2FjaGUuNAkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDAsIDw+
dDExNTQsIDw+dDUzNiwgYWRkcihpbnRlcnByZXRlci5DYWNoZS5WQVIuNCko
UDY0KQoJY3B5cwkkZjMxLCRmMzEsJGYzMQkjIHBhZAoJICMgc3RhbGwgCTEK
ICNpbnN0cgoJc3RxCSQxNywkMi4xJDJzcGlsbF9wICsgMjQ4KCRzcCkJICNj
bGFzcyBkbW92ZSxkbV9zcGlsbAkgIyA8PnQxMTUxCi5sb2MgMiAyNgoJYWRk
cQkkMTcsMjQsJDIxCSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMjYsIDxfRHlD
UlRfVGVtcExvY2F0aW9uJDEuMD50MTE1MywgPD50MTE1MSwgMjQoSTMyKQog
I2luc3RyCglzdHEJJDE2LCQyLjEkMnNwaWxsX3AgKyAyNTYoJHNwKQkgI2Ns
YXNzIGRtb3ZlLGRtX3NwaWxsCSAjIDw+dDExNTQKICNpbnN0cgoubG9jIDIg
MjYKCXN0cQkkMjEsRHlDUlRfVGVtcExvY2F0aW9uCSAjY2xhc3Mgc291cmNl
CSAjIGxpbmUgMjYsIDxfRHlDUlRfVGVtcExvY2F0aW9uJDEuMD50MTE1Mywg
PD50NTM2LCBhZGRyKF9EeUNSVF9UZW1wTG9jYXRpb24kMS4wKShQNjQpLCAw
KEkzMiksIDAoSTMyKSwgMChJMzIpLCAwKEkzMikKTDE0NSQzOgogI2luc3Ry
CglzdGwJJDIyLDAoJDE3KQkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDAsIDxf
cGMkMS4xPnQ0NTQsIDw+dDExNTEsIDAoU0kzMiksIDAoSTMyKSwgMChJMzIp
LCAwKEkzMiksIDAoSTMyKQogI2luc3RyCglzdGwJJDMxLDQoJDE3KQkgI2Ns
YXNzIHNvdXJjZQkgIyBsaW5lIDAsIDAoU0kzMiksIDw+dDExNTEsIDQoU0kz
MiksIDAoSTMyKSwgMChJMzIpLCAwKEkzMiksIDAoSTMyKQogI2luc3RyCglz
dHEJJDIzLDgoJDE3KQkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDAsIDxfYnl0
ZWNvZGVzJDEuMT50NDU1LCA8PnQxMTUxLCA4KFNJMzIpLCAwKEkzMiksIDAo
STMyKSwgMChJMzIpLCAwKEkzMikKICNpbnN0cgoJc3RsCSQxMywxNigkMTcp
CSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMCwgPF9vZmZzZXQkMS4yPnQ1Mjcs
IDw+dDExNTEsIDE2KFNJMzIpLCAwKEkzMiksIDAoSTMyKSwgMChJMzIpLCAw
KEkzMikKICNpbnN0cgoJc3RsCSQzMSwyMCgkMTcpCSAjY2xhc3Mgc291cmNl
CSAjIGxpbmUgMCwgMChTSTMyKSwgPD50MTE1MSwgMjAoU0kzMiksIDAoSTMy
KSwgMChJMzIpLCAwKEkzMiksIDAoSTMyKQoJICMgc3RhbGwgCTEKICNpbnN0
cgoJYmVxCSQxNixMMTQ2JDMJICNjbGFzcyBzb3VyY2UJICMgbGluZSAwLCA8
PnQxMTU0CkwxNDckMzoKICNtYXJrX2NhbGwgY2FsbGVyX3NhdmVzLCByZWdz
LCBhdHlwZXMobjY0LG42NCxuMzIpLCBydHlwZXMobjY0KTsKICNpbnN0cgoJ
YmlzCSQzMSwkMzEsJDMxCSMgcGFkCi5sb2MgMiAyNgoJanNyCSQyNixEWUNf
Q0FDSEVfbG9va3VwCglicgkkMjYsRkFLRTE3CkZBS0UxNzoJbGRncAkkZ3As
MCgkMjYpCSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMjYsIHJhZGRyKERZQ19D
QUNIRV9sb29rdXApKFA2NCksIDw+dDUzMywgPD50MTE1NCwgPD50MTE1MSwg
MShTSTMyKQogI2luc3RyCglsZGwJJDI1LCQyLjEkMnNwaWxsX3AoJHNwKQkg
I2NsYXNzIGRtb3ZlLGRtX3Jlc3RvcmUJICMgPD50NTg3Ci5sb2MgMiAyNgoJ
c3VicQkkMzEsMzIsJDIxCSAjY2xhc3Mgc291cmNlLGNzcGVjCSAjIGxpbmUg
MjYsIDxfQWxpZ25lZEFkZHJlc3MkMS41OD50Nzc2LCAwKEk2NCksIDMyKFNJ
NjQpCiAjaW5zdHIKCWxkcQkkMTQsJDIuMSQyc3BpbGxfcCArIDI0MCgkc3Ap
CSAjY2xhc3MgZG1vdmUsZG1fcmVzdG9yZQkgIyA8PnQxMTQ5CglsZGEJJDE4
LDEoJDMxKQkgI2NsYXNzIGRtb3ZlLGRtX2NvbnN0YW50CSAjIDEoU0kzMikK
ICNpbnN0cgoJbGRxCSQyNCwkMi4xJDJzcGlsbF9wICsgMTYoJHNwKQkgI2Ns
YXNzIGRtb3ZlLGRtX3Jlc3RvcmUJICMgPD50NTc3CglibmUJJDAsTDE0OCQz
CSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMCwgPD50MTE1NQogI2luc3RyCi5s
b2MgMiAyNgoJbGRxCSQxMyxEeUNSVF9Db2RlTG9jYXRpb24JICNjbGFzcyBz
b3VyY2UJICMgbGluZSAyNiwgPD50MTE2NCwgPD50NTM2LCBhZGRyKF9EeUNS
VF9Db2RlTG9jYXRpb24kMS4wKShQNjQpCglvcgkkMzEsJDMxLCQzMQkgI2Ns
YXNzIGRtb3ZlLGRtX3JlZ2lzdGVyCSAjIDw+dDUzMwogI2luc3RyCglhZGRx
CSQxNCwweDQsJDE0CSAjY2xhc3Mgc291cmNlLGNzcGVjCSAjIGxpbmUgMCwg
PD50NjA3LCA8PnQxMTQ5LCAweDQoUDY0KQoJbGRxCSQxNywkMi4xJDJzcGls
bF9wICsgMjQ4KCRzcCkJICNjbGFzcyBkbW92ZSxkbV9yZXN0b3JlCSAjIDw+
dDExNTEKICNpbnN0cgoJb3IJJDMxLCQzMSwkMTIJICNjbGFzcyBzb3VyY2Us
Y3NwZWMJICMgbGluZSAwLCA8PnQ1ODcsIDAoSTMyKQoubG9jIDIgMjYKCWJl
cQkkMjUsTDE0OSQzCSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMjYsIDw+dDU4
NwogI2luc3RyCi5sb2MgMiAyNgoJbGRxCSQxMSxEeUNSVF9QYWRkZWRCeXRl
cwkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDI2LCA8X0R5Q1JUX1BhZGRlZEJ5
dGVzJDEuMD50MTE2NywgPD50NTM2LCBhZGRyKF9EeUNSVF9QYWRkZWRCeXRl
cyQxLjApKFA2NCkKLmxvYyAyIDI2CglhZGRxCSQxMyw2MywkOAkgI2NsYXNz
IHNvdXJjZQkgIyBsaW5lIDI2LCA8PnQxMTY1LCA8PnQxMTY0LCA2MyhTSTY0
KQogI2luc3RyCglzdGwJJDEyLCQyLjEkMnNwaWxsX3AoJHNwKQkgI2NsYXNz
IGRtb3ZlLGRtX3NwaWxsCSAjIDw+dDU4NwoubG9jIDIgMjYKCWFuZAkkOCwk
MjEsJDIxCSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMjYsIDxfQWxpZ25lZEFk
ZHJlc3MkMS41OD50MTE2NiwgPD50MTE2NSwgPF9BbGlnbmVkQWRkcmVzcyQx
LjU4PnQ3NzYKICNpbnN0cgoubG9jIDIgMjYKCXN1YnEJJDIxLCQxMywkMTMJ
ICNjbGFzcyBzb3VyY2UJICMgbGluZSAyNiwgPF9EeUNSVF9QYWRkZWRCeXRl
cyQxLjA+dDc3NywgPF9BbGlnbmVkQWRkcmVzcyQxLjU4PnQxMTY2LCA8PnQx
MTY0CglsZHEJJDE2LCQyLjEkMnNwaWxsX3AgKyAyNTYoJHNwKQkgI2NsYXNz
IGRtb3ZlLGRtX3Jlc3RvcmUJICMgPD50MTE1NAogI2luc3RyCi5sb2MgMiAy
NgoJYWRkcQkkMTMsJDExLCQxMQkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDI2
LCA8X0R5Q1JUX1BhZGRlZEJ5dGVzJDEuMD50MTE2OCwgPF9EeUNSVF9QYWRk
ZWRCeXRlcyQxLjA+dDc3NywgPF9EeUNSVF9QYWRkZWRCeXRlcyQxLjA+dDEx
NjcKLmxvYyAyIDI2CglzdHEJJDExLER5Q1JUX1BhZGRlZEJ5dGVzCSAjY2xh
c3Mgc291cmNlCSAjIGxpbmUgMjYsIDxfRHlDUlRfUGFkZGVkQnl0ZXMkMS4w
PnQxMTY4LCA8PnQ1MzYsIGFkZHIoX0R5Q1JUX1BhZGRlZEJ5dGVzJDEuMCko
UDY0KSwgMChJMzIpLCAwKEkzMiksIDAoSTMyKSwgMChJMzIpCiAjaW5zdHIK
LmxvYyAyIDI2CglvcgkkMjEsJDMxLCQyMQkgI2NsYXNzIHNvdXJjZQkgIyBs
aW5lIDI2LCA8PnQxMTY0LCA8X0FsaWduZWRBZGRyZXNzJDEuNTg+dDExNjYK
CSAjIHN0YWxsIAkxCkwxNTAkMzoKICNpbnN0cgoJY21wZXEJJDIxLCQxNCwk
MTQJICNjbGFzcyBzb3VyY2UJICMgbGluZSAwLCA8PnQ3NzUsIDw+dDExNjQs
IDw+dDYwNwoJICMgc3RhbGwgCTEKICNpbnN0cgoJYmVxCSQxNCxMMTUxJDMJ
ICNjbGFzcyBzb3VyY2UJICMgbGluZSAwLCA8PnQ3NzUKICNpbnN0cgoJbGRx
CSQxOSwkMi4xJDJzcGlsbF9wICsgMjQwKCRzcCkJICNjbGFzcyBzb3VyY2UJ
ICMgbGluZSAwLCA8PnQxMTY0LCA8PnQxMTQ5CgkgIyBzdGFsbCAJMQogI2lu
c3RyCgliZXEJJDI0LEwxNTIkMwkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDAs
IDw+dDU3NwpMMTUzJDM6CiAjaW5zdHIKCXN0cQkkMTksJDIuMSQyc3BpbGxf
cCArIDI2NCgkc3ApCSAjY2xhc3MgZG1vdmUsZG1fc3BpbGwJICMgPD50MTE2
NAogI21hcmtfY2FsbCBjYWxsZXJfc2F2ZXMsIHJlZ3MsIGF0eXBlcyhuNjQs
bjY0LG4zMixuNjQpLCBydHlwZXMoKTsKICNpbnN0cgoJYmlzCSQzMSwkMzEs
JDMxCSMgcGFkCi5sb2MgMiAyNgoJanNyCSQyNixEWUNfQ0FDSEVfaW5zZXJ0
CglicgkkMjYsRkFLRTE4CkZBS0UxODoJbGRncAkkZ3AsMCgkMjYpCSAjY2xh
c3Mgc291cmNlCSAjIGxpbmUgMjYsIHJhZGRyKERZQ19DQUNIRV9pbnNlcnQp
KFA2NCksIDw+dDUzMywgPD50MTE1NCwgPD50MTE1MSwgMShTSTMyKSwgPD50
MTE2NAogI2luc3RyCglsZHEJJDEzLCQyLjEkMnNwaWxsX3AgKyAyNjQoJHNw
KQkgI2NsYXNzIGRtb3ZlLGRtX3Jlc3RvcmUJICMgPD50MTE2NAoJbGRhaAkk
MjcsMSgkMzEpCSAjY2xhc3MgZG1vdmUsZG1fY29uc3RhbnQJICMgNjU1MzYo
STMyKQogI2luc3RyCglsZHEJJDIxLER5Q1JUX1N0YXRpY1ZhbHVlVGFibGUJ
ICNjbGFzcyBzb3VyY2UJICMgbGluZSAwLCA8PnQxMTc2LCA8PnQ1MzYsIGFk
ZHIoX0R5Q1JUX1N0YXRpY1ZhbHVlVGFibGUkMS4wKShQNjQpCglsZGEJJDE5
LDEoJDMxKQkgI2NsYXNzIGRtb3ZlLGRtX2NvbnN0YW50CSAjIDEoSTMyKQoJ
ICMgc3RhbGwgCTEKICNpbnN0cgoJc3RxCSQxMyxEeUNSVF9TdGl0Y2hMb2Nh
dGlvbgkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDAsIDw+dDExNjQsIDw+dDUz
NiwgYWRkcihfRHlDUlRfU3RpdGNoTG9jYXRpb24kMS4wKShQNjQpLCAwKEkz
MiksIDAoSTMyKSwgMChJMzIpLCAwKEkzMikKCSAjIHN0YWxsIAkxCiAjaW5z
dHIKCWJlcQkkMjEsTDE1NCQzCSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMCwg
PD50MTE3NgogI2luc3RyCglsZGwJJDIxLER5Q1JUX1NWVEluZGV4CSAjY2xh
c3Mgc291cmNlCSAjIGxpbmUgMCwgPD50MTE3NywgPD50NTM2LCBhZGRyKF9E
eUNSVF9TVlRJbmRleCQxLjApKFA2NCkKCSAjIHN0YWxsIAkyCiAjaW5zdHIK
CWFkZGwJJDIxLDE2LCQyMQkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDAsIDw+
dDExNzgsIDw+dDExNzcsIDE2KFNJMzIpCiAjaW5zdHIKCWNtcGxlCSQyMSwk
MjcsJDE4CSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMCwgPD50NzgzLCA8PnQx
MTc4LCA2NTUzNihJMzIpCgkgIyBzdGFsbCAJMQogI2luc3RyCgliZXEJJDE4
LEwxNTQkMwkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDAsIDw+dDc4MwogI2lu
c3RyCglzdGwJJDE5LER5Q1JUX0J1aWxkVGFibGVQb2ludGVyCSAjY2xhc3Mg
c291cmNlCSAjIGxpbmUgMCwgMShJMzIpLCA8PnQ1MzYsIGFkZHIoX0R5Q1JU
X0J1aWxkVGFibGVQb2ludGVyJDEuMCkoUDY0KSwgMChJMzIpLCAwKEkzMiks
IDAoSTMyKSwgMChJMzIpCiAjbWFya190cmFjZSAxOTM7CiAjaW5zdHIKCWxk
bAkkMjIsJDIuMSQyc3BpbGxfcCArIDk2KCRzcCkJICNjbGFzcyBkbW92ZSxk
bV9yZXN0b3JlCSAjIDxfcGMkMS4xPnQ0NTQKICNpbnN0cgoJYnIJJDMxLEwx
NTUkMwoJYmlzCSQzMSwkMzEsJDMxCSMgcGFkCiAjbWFya190cmFjZSA4ODsK
TDE1NiQzOgppbnRlcnByZXRlci5EWUMuVU5JVF9IRUFELlNFVFVQLjQ6Cmlu
dGVycHJldGVyLmR5bl9zZXR1cF9iZWdpbl81Nl8wOgogI2luc3RyCi5sb2Mg
MiAxMDQKCWFkZGwJJDIyLDEsJDIyCSAjY2xhc3Mgc291cmNlCSAjIGxpbmUg
MTA0LCA8X3BjJDEuMT50NDU0LCA8X3BjJDEuMT50NDU0LCAxKFNJMzIpCglz
dGwJJDIyLCQyLjEkMnNwaWxsX3AgKyA5Nigkc3ApCSAjY2xhc3MgZG1vdmUs
ZG1fc3BpbGwJICMgPF9wYyQxLjE+dDQ1NAogI21hcmtfY2FsbCBjYWxsZXJf
c2F2ZXMsIHJlZ3MsIGF0eXBlcygpLCBydHlwZXMoKTsKICNpbnN0cgoJb3IJ
JDMxLCQzMSwkMzEJICNjbGFzcyBkbW92ZSxkbV9yZWdpc3RlcgkgIyA8PnQ1
MzMKLmxvYyAyIDI2Cglqc3IJJDI2LER5Q1JUX1BhdGNoSW50cmFVbml0QnJh
bmNoZXMKCWJyCSQyNixGQUtFMjYKRkFLRTI2OglsZGdwCSRncCwwKCQyNikJ
ICNjbGFzcyBzb3VyY2UJICMgbGluZSAyNiwgcmFkZHIoRHlDUlRfUGF0Y2hJ
bnRyYVVuaXRCcmFuY2hlcykoUDY0KSwgPD50NTMzCgkgIyBzdGFsbCAJMQog
I2luc3RyCglzdHEJJDMxLER5Q1JUX0NvZGVMb2NhdGlvbgkgI2NsYXNzIHNv
dXJjZQkgIyBsaW5lIDAsIDB4MChQNjQpLCA8PnQ1MzYsIGFkZHIoX0R5Q1JU
X0NvZGVMb2NhdGlvbiQxLjApKFA2NCksIDAoSTMyKSwgMChJMzIpLCAwKEkz
MiksIDAoSTMyKQoJbGRhCSQxOCwxKCQzMSkJICNjbGFzcyBkbW92ZSxkbV9j
b25zdGFudAkgIyAxKFNJMzIpCiAjaW5zdHIKCWxkcQkkMjEsRHlDUlRfTGFz
dEJyYW5jaAkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDAsIDw+dDEzMDIsIDw+
dDUzNiwgYWRkcihfRHlDUlRfTGFzdEJyYW5jaCQxLjApKFA2NCkKCW9yCSQz
MSwkMzEsJDMxCSAjY2xhc3MgZG1vdmUsZG1fcmVnaXN0ZXIJICMgPD50NTMz
CiAjaW5zdHIKLmxvYyAyIDI2CglsZHEJJDIwLGludGVycHJldGVyLkxTVkZy
ZWVMaXN0LjIJICNjbGFzcyBzb3VyY2UJICMgbGluZSAyNiwgPD50MTMwMywg
PD50NTM2LCBhZGRyKGludGVycHJldGVyLkxTVkZyZWVMaXN0LlZBUi4yKShQ
NjQpCiAjaW5zdHIKCWxkbAkkMjIsJDIuMSQyc3BpbGxfcCArIDk2KCRzcCkJ
ICNjbGFzcyBkbW92ZSxkbV9yZXN0b3JlCSAjIDxfcGMkMS4xPnQ0NTQKICNp
bnN0cgoJc3RxCSQyMSwkMi4xJDJzcGlsbF9wICsgMzA0KCRzcCkJICNjbGFz
cyBkbW92ZSxkbV9zcGlsbAkgIyA8PnQxMzAyCgljcHlzCSRmMzEsJGYzMSwk
ZjMxCSMgcGFkCmludGVycHJldGVyLmR5bl9zZXR1cF9lbmRfNTZfMDoKICNp
bnN0cgoJbGRxCSQyMywkMi4xJDJzcGlsbF9wICsgODgoJHNwKQkgI2NsYXNz
IGRtb3ZlLGRtX3Jlc3RvcmUJICMgPF9ieXRlY29kZXMkMS4xPnQ0NTUKLmxv
YyAyIDI2CglibmUJJDIwLEwxNTckMwkgI2NsYXNzIHNvdXJjZQkgIyBsaW5l
IDI2LCA8PnQxMzAzCiAjaW5zdHIKLmxvYyAyIDI2CglsZHEJJDE3LER5Q1JU
X1RlbXBMb2NhdGlvbgkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDI2LCA8PnQx
MzA0LCA8PnQ1MzYsIGFkZHIoX0R5Q1JUX1RlbXBMb2NhdGlvbiQxLjApKFA2
NCkKICNpbnN0cgoJbGRxCSQxNixpbnRlcnByZXRlci5DYWNoZS4yCSAjY2xh
c3Mgc291cmNlCSAjIGxpbmUgMCwgPD50MTMwNywgPD50NTM2LCBhZGRyKGlu
dGVycHJldGVyLkNhY2hlLlZBUi4yKShQNjQpCgkgIyBzdGFsbCAJMQogI2lu
c3RyCglzdHEJJDE3LCQyLjEkMnNwaWxsX3AgKyAzMTIoJHNwKQkgI2NsYXNz
IGRtb3ZlLGRtX3NwaWxsCSAjIDw+dDEzMDQKLmxvYyAyIDI2CglhZGRxCSQx
NywxNiwkMjEJICNjbGFzcyBzb3VyY2UJICMgbGluZSAyNiwgPF9EeUNSVF9U
ZW1wTG9jYXRpb24kMS4wPnQxMzA2LCA8PnQxMzA0LCAxNihJMzIpCiAjaW5z
dHIKCXN0cQkkMTYsJDIuMSQyc3BpbGxfcCArIDMyMCgkc3ApCSAjY2xhc3Mg
ZG1vdmUsZG1fc3BpbGwJICMgPD50MTMwNwogI2luc3RyCi5sb2MgMiAyNgoJ
c3RxCSQyMSxEeUNSVF9UZW1wTG9jYXRpb24JICNjbGFzcyBzb3VyY2UJICMg
bGluZSAyNiwgPF9EeUNSVF9UZW1wTG9jYXRpb24kMS4wPnQxMzA2LCA8PnQ1
MzYsIGFkZHIoX0R5Q1JUX1RlbXBMb2NhdGlvbiQxLjApKFA2NCksIDAoSTMy
KSwgMChJMzIpLCAwKEkzMiksIDAoSTMyKQpMMTU4JDM6CiAjaW5zdHIKCXN0
bAkkMjIsMCgkMTcpCSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMCwgPF9wYyQx
LjE+dDQ1NCwgPD50MTMwNCwgMChTSTMyKSwgMChJMzIpLCAwKEkzMiksIDAo
STMyKSwgMChJMzIpCiAjaW5zdHIKCXN0bAkkMzEsNCgkMTcpCSAjY2xhc3Mg
c291cmNlCSAjIGxpbmUgMCwgMChTSTMyKSwgPD50MTMwNCwgNChTSTMyKSwg
MChJMzIpLCAwKEkzMiksIDAoSTMyKSwgMChJMzIpCiAjaW5zdHIKCXN0cQkk
MjMsOCgkMTcpCSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMCwgPF9ieXRlY29k
ZXMkMS4xPnQ0NTUsIDw+dDEzMDQsIDgoU0kzMiksIDAoSTMyKSwgMChJMzIp
LCAwKEkzMiksIDAoSTMyKQoJICMgc3RhbGwgCTEKICNpbnN0cgoJYmVxCSQx
NixMMTU5JDMJICNjbGFzcyBzb3VyY2UJICMgbGluZSAwLCA8PnQxMzA3Ckwx
NjAkMzoKICNtYXJrX2NhbGwgY2FsbGVyX3NhdmVzLCByZWdzLCBhdHlwZXMo
bjY0LG42NCxuMzIpLCBydHlwZXMobjY0KTsKICNpbnN0cgoJYmlzCSQzMSwk
MzEsJDMxCSMgcGFkCi5sb2MgMiAyNgoJanNyCSQyNixEWUNfQ0FDSEVfbG9v
a3VwCglicgkkMjYsRkFLRTI3CkZBS0UyNzoJbGRncAkkZ3AsMCgkMjYpCSAj
Y2xhc3Mgc291cmNlCSAjIGxpbmUgMjYsIHJhZGRyKERZQ19DQUNIRV9sb29r
dXApKFA2NCksIDw+dDUzMywgPD50MTMwNywgPD50MTMwNCwgMShTSTMyKQog
I2luc3RyCglsZHEJJDIxLCQyLjEkMnNwaWxsX3AgKyAzMDQoJHNwKQkgI2Ns
YXNzIGRtb3ZlLGRtX3Jlc3RvcmUJICMgPD50MTMwMgoJbGRhCSQxOCwxKCQz
MSkJICNjbGFzcyBkbW92ZSxkbV9jb25zdGFudAkgIyAxKFNJMzIpCiAjaW5z
dHIKCWxkcQkkMjQsJDIuMSQyc3BpbGxfcCArIDE2KCRzcCkJICNjbGFzcyBk
bW92ZSxkbV9yZXN0b3JlCSAjIDw+dDU3NwoJb3IJJDMxLCQzMSwkMzEJICNj
bGFzcyBkbW92ZSxkbV9yZWdpc3RlcgkgIyA8PnQ1MzMKICNpbnN0cgoJbGRx
CSQxNywkMi4xJDJzcGlsbF9wICsgMzEyKCRzcCkJICNjbGFzcyBkbW92ZSxk
bV9yZXN0b3JlCSAjIDw+dDEzMDQKCWJuZQkkMCxMMTYxJDMJICNjbGFzcyBz
b3VyY2UJICMgbGluZSAwLCA8PnQxMzA4CiAjaW5zdHIKCW9yCSQzMSwkMzEs
JDI1CSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMCwgPD50NTg3LCAwKEkzMikK
LmxvYyAyIDI2CglsZHEJJDIwLER5Q1JUX0NvZGVMb2NhdGlvbgkgI2NsYXNz
IHNvdXJjZQkgIyBsaW5lIDI2LCA8PnQxMzE3LCA8PnQ1MzYsIGFkZHIoX0R5
Q1JUX0NvZGVMb2NhdGlvbiQxLjApKFA2NCkKICNpbnN0cgoJYWRkcQkkMjEs
MHg0LCQyMQkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDAsIDw+dDYxMSwgPD50
MTMwMiwgMHg0KFA2NCkKCWxkcQkkMTYsJDIuMSQyc3BpbGxfcCArIDMyMCgk
c3ApCSAjY2xhc3MgZG1vdmUsZG1fcmVzdG9yZQkgIyA8PnQxMzA3CiAjaW5z
dHIKCXN0bAkkMjUsJDIuMSQyc3BpbGxfcCgkc3ApCSAjY2xhc3MgZG1vdmUs
ZG1fc3BpbGwJICMgPD50NTg3CiAjaW5zdHIKCWNtcGVxCSQyMCwkMjEsJDIx
CSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMCwgPD50ODU5LCA8PnQxMzE3LCA8
PnQ2MTEKCSAjIHN0YWxsIAkxCiAjaW5zdHIKCWJlcQkkMjEsTDE2MiQzCSAj
Y2xhc3Mgc291cmNlCSAjIGxpbmUgMCwgPD50ODU5CiAjaW5zdHIKCWxkcQkk
MTksJDIuMSQyc3BpbGxfcCArIDMwNCgkc3ApCSAjY2xhc3Mgc291cmNlCSAj
IGxpbmUgMCwgPD50MTMxNywgPD50MTMwMgoJICMgc3RhbGwgCTEKICNpbnN0
cgoJYmVxCSQyNCxMMTYzJDMJICNjbGFzcyBzb3VyY2UJICMgbGluZSAwLCA8
PnQ1NzcKTDE2NCQzOgogI2luc3RyCglzdHEJJDE5LCQyLjEkMnNwaWxsX3Ag
KyAzMjgoJHNwKQkgI2NsYXNzIGRtb3ZlLGRtX3NwaWxsCSAjIDw+dDEzMTcK
ICNtYXJrX2NhbGwgY2FsbGVyX3NhdmVzLCByZWdzLCBhdHlwZXMobjY0LG42
NCxuMzIsbjY0KSwgcnR5cGVzKCk7CiAjaW5zdHIKCWJpcwkkMzEsJDMxLCQz
MQkjIHBhZAoubG9jIDIgMjYKCWpzcgkkMjYsRFlDX0NBQ0hFX2luc2VydAoJ
YnIJJDI2LEZBS0UyOApGQUtFMjg6CWxkZ3AJJGdwLDAoJDI2KQkgI2NsYXNz
IHNvdXJjZQkgIyBsaW5lIDI2LCByYWRkcihEWUNfQ0FDSEVfaW5zZXJ0KShQ
NjQpLCA8PnQ1MzMsIDw+dDEzMDcsIDw+dDEzMDQsIDEoU0kzMiksIDw+dDEz
MTcKICNpbnN0cgoJbGRxCSQyMCwkMi4xJDJzcGlsbF9wICsgMzI4KCRzcCkJ
ICNjbGFzcyBkbW92ZSxkbV9yZXN0b3JlCSAjIDw+dDEzMTcKCWxkYWgJJDI3
LDEoJDMxKQkgI2NsYXNzIGRtb3ZlLGRtX2NvbnN0YW50CSAjIDY1NTM2KEkz
MikKICNpbnN0cgoJbGRxCSQyMSxEeUNSVF9TdGF0aWNWYWx1ZVRhYmxlCSAj
Y2xhc3Mgc291cmNlCSAjIGxpbmUgMCwgPD50MTMyNSwgPD50NTM2LCBhZGRy
KF9EeUNSVF9TdGF0aWNWYWx1ZVRhYmxlJDEuMCkoUDY0KQoJbGRhCSQxOSwx
KCQzMSkJICNjbGFzcyBkbW92ZSxkbV9jb25zdGFudAkgIyAxKEkzMikKCSAj
IHN0YWxsIAkxCiAjaW5zdHIKCXN0cQkkMjAsRHlDUlRfU3RpdGNoTG9jYXRp
b24JICNjbGFzcyBzb3VyY2UJICMgbGluZSAwLCA8PnQxMzE3LCA8PnQ1MzYs
IGFkZHIoX0R5Q1JUX1N0aXRjaExvY2F0aW9uJDEuMCkoUDY0KSwgMChJMzIp
LCAwKEkzMiksIDAoSTMyKSwgMChJMzIpCgkgIyBzdGFsbCAJMQogI2luc3Ry
CgliZXEJJDIxLEwxNjUkMwkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDAsIDw+
dDEzMjUKICNpbnN0cgoJbGRsCSQyMSxEeUNSVF9TVlRJbmRleAkgI2NsYXNz
IHNvdXJjZQkgIyBsaW5lIDAsIDw+dDEzMjYsIDw+dDUzNiwgYWRkcihfRHlD
UlRfU1ZUSW5kZXgkMS4wKShQNjQpCgkgIyBzdGFsbCAJMgogI2luc3RyCglh
ZGRsCSQyMSwyMTYsJDIxCSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMCwgPD50
MTMyNywgPD50MTMyNiwgMjE2KFNJMzIpCiAjaW5zdHIKCWNtcGxlCSQyMSwk
MjcsJDIwCSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMCwgPD50ODY1LCA8PnQx
MzI3LCA2NTUzNihJMzIpCgkgIyBzdGFsbCAJMQogI2luc3RyCgliZXEJJDIw
LEwxNjUkMwkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDAsIDw+dDg2NQogI2lu
c3RyCglzdGwJJDE5LER5Q1JUX0J1aWxkVGFibGVQb2ludGVyCSAjY2xhc3Mg
c291cmNlCSAjIGxpbmUgMCwgMShJMzIpLCA8PnQ1MzYsIGFkZHIoX0R5Q1JU
X0J1aWxkVGFibGVQb2ludGVyJDEuMCkoUDY0KSwgMChJMzIpLCAwKEkzMiks
IDAoSTMyKSwgMChJMzIpCgljcHlzCSRmMzEsJGYzMSwkZjMxCSMgcGFkCiAj
bWFya190cmFjZSAyMTA7CiAjaW5zdHIKCWxkYWgJJDE3LDEoJDMxKQkgI2Ns
YXNzIGRtb3ZlLGRtX2NvbnN0YW50CSAjIDY1NTM2KEkzMikKCWxkbAkkMjIs
JDIuMSQyc3BpbGxfcCArIDk2KCRzcCkJICNjbGFzcyBkbW92ZSxkbV9yZXN0
b3JlCSAjIDxfcGMkMS4xPnQ0NTQKICNpbnN0cgoJbGRhCSQxOCwxMSgkMzEp
CSAjY2xhc3MgZG1vdmUsZG1fY29uc3RhbnQJICMgMTEoU0k2NCkKICNpbnN0
cgoJbGRhCSQxOSwxNigkMzEpCSAjY2xhc3MgZG1vdmUsZG1fY29uc3RhbnQJ
ICMgMTYoU0k2NCkKICNpbnN0cgoJbGRhCSQyMCwyMSgkMzEpCSAjY2xhc3Mg
ZG1vdmUsZG1fY29uc3RhbnQJICMgMjEoU0k2NCkKCWNweXMJJGYzMSwkZjMx
LCRmMzEJIyBwYWQKICNpbnN0cgoJbGRhCSQyMSw0KCQzMSkJICNjbGFzcyBk
bW92ZSxkbV9jb25zdGFudAkgIyA0KEk2NCkKCWxkcQkkMjMsJDIuMSQyc3Bp
bGxfcCArIDg4KCRzcCkJICNjbGFzcyBkbW92ZSxkbV9yZXN0b3JlCSAjIDxf
Ynl0ZWNvZGVzJDEuMT50NDU1CiAjaW5zdHIKCWxkYQkkMTYsMjYoJDMxKQkg
I2NsYXNzIGRtb3ZlLGRtX2NvbnN0YW50CSAjIDI2KFNJNjQpCglicgkkMzEs
TDE2NiQzCiAjbWFya190cmFjZSAxMTI7CkwxNjUkMzoKICNpbnN0cgoubG9j
IDIgMjYKCWxkcQkkMTUsRHlDUlRfVGFibGVMb2NhdGlvbgkgI2NsYXNzIHNv
dXJjZQkgIyBsaW5lIDI2LCA8PnQxMzI4LCA8PnQ1MzYsIGFkZHIoX0R5Q1JU
X1RhYmxlTG9jYXRpb24kMS4wKShQNjQpCglsZGFoCSQxNywxKCQzMSkJICNj
bGFzcyBkbW92ZSxkbV9jb25zdGFudAkgIyA2NTUzNihJMzIpCiAjaW5zdHIK
LmxvYyAyIDI2CglsZGwJJDExLER5Q1JUX1RhYmxlUG9pbnRlckluZGV4CSAj
Y2xhc3Mgc291cmNlCSAjIGxpbmUgMjYsIDxfRHlDUlRfVGFibGVQb2ludGVy
SW5kZXgkMS4wPnQxMzMyLCA8PnQ1MzYsIGFkZHIoX0R5Q1JUX1RhYmxlUG9p
bnRlckluZGV4JDEuMCkoUDY0KQoubG9jIDIgMjYKCWxkYQkkOCxEeUNSVF9U
YWJsZVBvaW50ZXJzKzgJICNjbGFzcyBzb3VyY2UJICMgbGluZSAyNiwgPD50
ODcxLCA8PnQ1MzYsIChhZGRyKF9EeUNSVF9UYWJsZVBvaW50ZXJzJDEuMCko
UDY0KSArIDB4OChJNjQpKShQNjQpCiAjaW5zdHIKCWxkYQkkNywtMzI3Njgo
JDE3KQkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDAsIDw+dDg2OCwgNjU1MzYo
STMyKSwgLTMyNzY4KFNJNjQpCglzdGwJJDE5LER5Q1JUX0J1aWxkVGFibGVQ
b2ludGVyCSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMCwgMShJMzIpLCA8PnQ1
MzYsIGFkZHIoX0R5Q1JUX0J1aWxkVGFibGVQb2ludGVyJDEuMCkoUDY0KSwg
MChJMzIpLCAwKEkzMiksIDAoSTMyKSwgMChJMzIpCiAjaW5zdHIKCWFkZHEJ
JDE1LCQ3LCQ2CSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMCwgPD50MTMzMCwg
PD50MTMyOCwgPD50ODY4CglzdHEJJDYsRHlDUlRfU3RhdGljVmFsdWVUYWJs
ZQkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDAsIDw+dDEzMzAsIDw+dDUzNiwg
YWRkcihfRHlDUlRfU3RhdGljVmFsdWVUYWJsZSQxLjApKFA2NCksIDAoSTMy
KSwgMChJMzIpLCAwKEkzMiksIDAoSTMyKQogI2luc3RyCi5sb2MgMiAyNgoJ
YWRkcQkkMTEsJDgsJDgJICNjbGFzcyBzb3VyY2UJICMgbGluZSAyNiwgPD50
MTMzNCwgPF9EeUNSVF9UYWJsZVBvaW50ZXJJbmRleCQxLjA+dDEzMzIsIDw+
dDg3MQoJc3RxCSQzMSxEeUNSVF9TVlRJbmRleAkgI2NsYXNzIHNvdXJjZQkg
IyBsaW5lIDAsIDB4MChQNjQpLCA8PnQ1MzYsIGFkZHIoX0R5Q1JUX1NWVElu
ZGV4JDEuMCkoUDY0KSwgMChJMzIpLCAwKEkzMiksIDAoSTMyKSwgMChJMzIp
CiAjaW5zdHIKLmxvYyAyIDI2CglhZGRxCSQxNSw2NTUzNiwkMTUJICNjbGFz
cyBzb3VyY2UJICMgbGluZSAyNiwgPF9EeUNSVF9UYWJsZUxvY2F0aW9uJDEu
MD50MTMyOSwgPD50MTMyOCwgNjU1MzYoSTMyKQoubG9jIDIgMjYKCXN0cQkk
MTUsRHlDUlRfVGFibGVMb2NhdGlvbgkgI2NsYXNzIHNvdXJjZQkgIyBsaW5l
IDI2LCA8X0R5Q1JUX1RhYmxlTG9jYXRpb24kMS4wPnQxMzI5LCA8PnQ1MzYs
IGFkZHIoX0R5Q1JUX1RhYmxlTG9jYXRpb24kMS4wKShQNjQpLCAwKEkzMiks
IDAoSTMyKSwgMChJMzIpLCAwKEkzMikKICNpbnN0cgoubG9jIDIgMjYKCXN0
cQkkNiwwKCQ4KQkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDI2LCA8PnQxMzMw
LCA8PnQxMzM0LCAwKEk2NCksIDAoSTMyKSwgMChJMzIpLCAwKEkzMiksIDAo
STMyKQoubG9jIDIgMjYKCWFkZGwJJDExLDgsJDExCSAjY2xhc3Mgc291cmNl
CSAjIGxpbmUgMjYsIDxfRHlDUlRfVGFibGVQb2ludGVySW5kZXgkMS4wPnQx
MzMzLCA8X0R5Q1JUX1RhYmxlUG9pbnRlckluZGV4JDEuMD50MTMzMiwgOChJ
MzIpCiAjaW5zdHIKLmxvYyAyIDI2CglzdGwJJDExLER5Q1JUX1RhYmxlUG9p
bnRlckluZGV4CSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMjYsIDxfRHlDUlRf
VGFibGVQb2ludGVySW5kZXgkMS4wPnQxMzMzLCA8PnQ1MzYsIGFkZHIoX0R5
Q1JUX1RhYmxlUG9pbnRlckluZGV4JDEuMCkoUDY0KSwgMChJMzIpLCAwKEkz
MiksIDAoSTMyKSwgMChJMzIpCglsZGEJJDIxLDQoJDMxKQkgI2NsYXNzIGRt
b3ZlLGRtX2NvbnN0YW50CSAjIDQoSTY0KQogI2luc3RyCi5sb2MgMiAyNgoJ
bGRxCSQxNSxEeUNSVF9Xb3JrTGlzdAkgI2NsYXNzIHNvdXJjZQkgIyBsaW5l
IDI2LCA8X0R5Q19UZW1wJDEuNDg+dDEzMzEsIDw+dDUzNiwgYWRkcihfRHlD
UlRfV29ya0xpc3QkMS4wKShQNjQpCglsZGEJJDIwLDIxKCQzMSkJICNjbGFz
cyBkbW92ZSxkbV9jb25zdGFudAkgIyAyMShTSTY0KQogI2luc3RyCglsZGwJ
JDIyLCQyLjEkMnNwaWxsX3AgKyA5Nigkc3ApCSAjY2xhc3MgZG1vdmUsZG1f
cmVzdG9yZQkgIyA8X3BjJDEuMT50NDU0CglsZGEJJDE5LDE2KCQzMSkJICNj
bGFzcyBkbW92ZSxkbV9jb25zdGFudAkgIyAxNihTSTY0KQogI2luc3RyCgls
ZHEJJDIzLCQyLjEkMnNwaWxsX3AgKyA4OCgkc3ApCSAjY2xhc3MgZG1vdmUs
ZG1fcmVzdG9yZQkgIyA8X2J5dGVjb2RlcyQxLjE+dDQ1NQoJbGRhCSQxOCwx
MSgkMzEpCSAjY2xhc3MgZG1vdmUsZG1fY29uc3RhbnQJICMgMTEoU0k2NCkK
ICNpbnN0cgoJbGRhCSQxNiwyNigkMzEpCSAjY2xhc3MgZG1vdmUsZG1fY29u
c3RhbnQJICMgMjYoU0k2NCkKLmxvYyAyIDI2CglibmUJJDE1LEwxNjckMwkg
I2NsYXNzIHNvdXJjZQkgIyBsaW5lIDI2LCA8X0R5Q19UZW1wJDEuNDg+dDEz
MzEKTDE2NiQzOgogI2luc3RyCglzdHEJJDMxLER5Q1JUX0JyYW5jaEluZGV4
CSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMCwgMHgwKFA2NCksIDw+dDUzNiwg
YWRkcihfRHlDUlRfQnJhbmNoSW5kZXgkMS4wKShQNjQpLCAwKEkzMiksIDAo
STMyKSwgMChJMzIpLCAwKEkzMikKCWxkYQkkMTQsMSgkMzEpCSAjY2xhc3Mg
ZG1vdmUsZG1fY29uc3RhbnQJICMgMShTSTY0KQogI2luc3RyCglsZGEJJDEz
LDYoJDMxKQkgI2NsYXNzIGRtb3ZlLGRtX2NvbnN0YW50CSAjIDYoU0k2NCkK
ICNpbnN0cgoJbGRhCSQxMiwzMSgkMzEpCSAjY2xhc3MgZG1vdmUsZG1fY29u
c3RhbnQJICMgMzEoU0k2NCkKICNpbnN0cgoJYnIJJDMxLEw0MiQzCiAjbWFy
a190cmFjZSAyMDM7CkwxNjckMzoKICNpbnN0cgoJbGRhCSQyNSwzKCQzMSkJ
ICNjbGFzcyBkbW92ZSxkbV9jb25zdGFudAkgIyAzKFNJMzIpCgkgIyBzdGFs
bCAJMQogI2luc3RyCi5sb2MgMiAyNgoJc3RsCSQyNSwzMigkMTUpCSAjY2xh
c3Mgc291cmNlCSAjIGxpbmUgMjYsIDMoU0kzMiksIDxfRHlDX1RlbXAkMS40
OD50MTMzMSwgMzIoSTY0KSwgMChJMzIpLCAwKEkzMiksIDAoSTMyKSwgMChJ
MzIpCiAjaW5zdHIKCWxkcQkkMjMsJDIuMSQyc3BpbGxfcCArIDg4KCRzcCkJ
ICNjbGFzcyBkbW92ZSxkbV9yZXN0b3JlCSAjIDxfYnl0ZWNvZGVzJDEuMT50
NDU1CiAjaW5zdHIKCWxkYQkkMTYsMjYoJDMxKQkgI2NsYXNzIGRtb3ZlLGRt
X2NvbnN0YW50CSAjIDI2KFNJNjQpCglicgkkMzEsTDE2NiQzCiAjbWFya190
cmFjZSAxOTI7CkwxNjMkMzoKICNpbnN0cgoJb3IJJDE5LCQzMSwkMjQJICNj
bGFzcyBzb3VyY2UJICMgbGluZSAwLCA8PnQ1NzcsIDw+dDEzMTcKICNpbnN0
cgoJb3IJJDMxLCQzMSwkMzEJICNjbGFzcyBkbW92ZSxkbV9yZWdpc3Rlcgkg
IyA8PnQ1MzMKICNpbnN0cgoJc3RxCSQyNCwkMi4xJDJzcGlsbF9wICsgMTYo
JHNwKQkgI2NsYXNzIGRtb3ZlLGRtX3NwaWxsCSAjIDw+dDU3NwogI2luc3Ry
CglicgkkMzEsTDE2NCQzCiAjbWFya190cmFjZSAxODU7CkwxNjIkMzoKICNp
bnN0cgoJbGRxCSQyMSwkMi4xJDJzcGlsbF9wICsgMzA0KCRzcCkJICNjbGFz
cyBkbW92ZSxkbV9yZXN0b3JlCSAjIDw+dDEzMDIKCWxkYQkkMTksMigkMzEp
CSAjY2xhc3MgZG1vdmUsZG1fY29uc3RhbnQJICMgMihTSTY0KQogI2luc3Ry
CglsZGFoCSQyMywzMigkMzEpCSAjY2xhc3MgZG1vdmUsZG1fY29uc3RhbnQJ
ICMgMjA5NzE1MihJMzIpCiAjaW5zdHIKCWxkYWgJJDI3LC0zMigkMzEpCSAj
Y2xhc3MgZG1vdmUsZG1fY29uc3RhbnQJICMgNDI5Mjg3MDE0NChJMzIpCiAj
aW5zdHIKLmxvYyAyIDI2CglhZGRxCSQyMSw0LCQxOAkgI2NsYXNzIHNvdXJj
ZQkgIyBsaW5lIDI2LCA8PnQxMzE4LCA8PnQxMzAyLCA0KFNJMzIpCi5sb2Mg
MiAyNgoJbGRsCSQxNSwwKCQyMSkJICNjbGFzcyBzb3VyY2UJICMgbGluZSAy
NiwgPD50MTMyMiwgPD50MTMwMiwgMChJNjQpCiAjaW5zdHIKLmxvYyAyIDI2
CglzdWJxCSQyMCwkMTgsJDE0CSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMjYs
IDw+dDEzMTksIDw+dDEzMTcsIDw+dDEzMTgKICNpbnN0cgoubG9jIDIgMjYK
CWFkZGwJJDE0LDMsJDE4CSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMjYsIDw+
dDY0MywgPD50MTMxOSwgMyhTSTMyKQogI2luc3RyCi5sb2MgMiAyNgoJY21v
dmdlCSQxNCwkMTQsJDE4CSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMjYsIDw+
dDY0NCwgPD50MTMxOSwgPD50MTMxOSwgPD50NjQzCiAjaW5zdHIKLmxvYyAy
IDI2CglsZGEJJDE0LC0xKCQyMykJICNjbGFzcyBzb3VyY2UJICMgbGluZSAy
NiwgPD50ODYxLCAyMDk3MTUyKEkzMiksIC0xKFNJNjQpCiAjaW5zdHIKLmxv
YyAyIDI2CglzcmEJJDE4LCQxOSwkMTgJICNjbGFzcyBzb3VyY2UJICMgbGlu
ZSAyNiwgPD50MTMyMCwgPD50NjQ0LCAyKFNJNjQpCiAjaW5zdHIKLmxvYyAy
IDI2CglhbmQJJDE1LCQyNywkMTUJICNjbGFzcyBzb3VyY2UJICMgbGluZSAy
NiwgPD50MTMyMywgPD50MTMyMiwgNDI5Mjg3MDE0NChJMzIpCiAjaW5zdHIK
LmxvYyAyIDI2CglhbmQJJDE4LCQxNCwkMTQJICNjbGFzcyBzb3VyY2UJICMg
bGluZSAyNiwgPD50MTMyMSwgPD50MTMyMCwgPD50ODYxCgljcHlzCSRmMzEs
JGYzMSwkZjMxCSMgcGFkCiAjaW5zdHIKLmxvYyAyIDI2CglvcgkkMTQsJDE1
LCQxNQkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDI2LCA8PnQxMzI0LCA8PnQx
MzIxLCA8PnQxMzIzCi5sb2MgMiAyNgoJc3RsCSQxNSwwKCQyMSkJICNjbGFz
cyBzb3VyY2UJICMgbGluZSAyNiwgPD50MTMyNCwgPD50MTMwMiwgMChJNjQp
LCAwKEkzMiksIDAoSTMyKSwgMChJMzIpLCAwKEkzMikKCSAjIHN0YWxsIAkx
CiAjaW5zdHIKCWJuZQkkMjQsTDE2OCQzCSAjY2xhc3Mgc291cmNlLHJlam9p
bl9jb3B5CSAjIGxpbmUgMCwgPD50NTc3CiAjbWFya190cmFjZSAyMDg7CiAj
aW5zdHIKCW9yCSQyMCwkMzEsJDE5CSAjY2xhc3MgZG1vdmUsZG1fcmVnaXN0
ZXIJICMgPD50MTMxNwogI2luc3RyCglsZGEJJDE4LDEoJDMxKQkgI2NsYXNz
IGRtb3ZlLGRtX2NvbnN0YW50CSAjIDEoU0kzMikKICNpbnN0cgoJYnIJJDMx
LEwxNjMkMwogI21hcmtfdHJhY2UgMjA5OwpMMTY4JDM6CiAjaW5zdHIKCXN0
cQkkMjQsJDIuMSQyc3BpbGxfcCArIDE2KCRzcCkJICNjbGFzcyBkbW92ZSxk
bV9zcGlsbAkgIyA8PnQ1NzcKCWxkYQkkMTgsMSgkMzEpCSAjY2xhc3MgZG1v
dmUsZG1fY29uc3RhbnQJICMgMShTSTMyKQogI2luc3RyCglvcgkkMzEsJDMx
LCQzMQkgI2NsYXNzIGRtb3ZlLGRtX3JlZ2lzdGVyCSAjIDw+dDUzMwogI2lu
c3RyCglvcgkkMjAsJDMxLCQxOQkgI2NsYXNzIGRtb3ZlLGRtX3JlZ2lzdGVy
CSAjIDw+dDEzMTcKICNpbnN0cgoJYnIJJDMxLEwxNjQkMwoJYmlzCSQzMSwk
MzEsJDMxCSMgcGFkCiAjbWFya190cmFjZSAxMzk7CkwxNjEkMzoKICNpbnN0
cgoubG9jIDIgMjYKCWFkZHEJJDIxLDQsJDIzCSAjY2xhc3Mgc291cmNlCSAj
IGxpbmUgMjYsIDw+dDEzMTAsIDw+dDEzMDIsIDQoU0kzMikKLmxvYyAyIDI2
CglsZGwJJDIyLDAoJDIxKQkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDI2LCA8
PnQxMzE0LCA8PnQxMzAyLCAwKEk2NCkKICNpbnN0cgoubG9jIDIgMjYKCXN1
YnEJJDAsJDIzLCQyMAkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDI2LCA8PnQx
MzExLCA8PnQxMzA4LCA8PnQxMzEwCiAjaW5zdHIKLmxvYyAyIDI2CglhZGRs
CSQyMCwzLCQyMwkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDI2LCA8PnQ2NDEs
IDw+dDEzMTEsIDMoU0kzMikKICNpbnN0cgoubG9jIDIgMjYKCWNtb3ZnZQkk
MjAsJDIwLCQyMwkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDI2LCA8PnQ2NDIs
IDw+dDEzMTEsIDw+dDEzMTEsIDw+dDY0MQogI2luc3RyCglsZGEJJDIwLDIo
JDMxKQkgI2NsYXNzIGRtb3ZlLGRtX2NvbnN0YW50CSAjIDIoU0k2NCkKICNp
bnN0cgoJbGRhaAkkMTksMzIoJDMxKQkgI2NsYXNzIGRtb3ZlLGRtX2NvbnN0
YW50CSAjIDIwOTcxNTIoSTMyKQogI2luc3RyCi5sb2MgMiAyNgoJc3JhCSQy
MywkMjAsJDIzCSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMjYsIDw+dDEzMTIs
IDw+dDY0MiwgMihTSTY0KQogI2luc3RyCi5sb2MgMiAyNgoJbGRhCSQxOSwt
MSgkMTkpCSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMjYsIDw+dDg1NywgMjA5
NzE1MihJMzIpLCAtMShTSTY0KQogI2luc3RyCi5sb2MgMiAyNgoJYW5kCSQy
MywkMTksJDIzCSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMjYsIDw+dDEzMTMs
IDw+dDEzMTIsIDw+dDg1NwogI2luc3RyCglsZGFoCSQyNywtMzIoJDMxKQkg
I2NsYXNzIGRtb3ZlLGRtX2NvbnN0YW50CSAjIDQyOTI4NzAxNDQoSTMyKQoJ
ICMgc3RhbGwgCTEKICNpbnN0cgoubG9jIDIgMjYKCWFuZAkkMjIsJDI3LCQy
MgkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDI2LCA8PnQxMzE1LCA8PnQxMzE0
LCA0MjkyODcwMTQ0KEkzMikKICNpbnN0cgoubG9jIDIgMjYKCW9yCSQyMywk
MjIsJDIzCSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMjYsIDw+dDEzMTYsIDw+
dDEzMTMsIDw+dDEzMTUKLmxvYyAyIDI2CglzdGwJJDIzLDAoJDIxKQkgI2Ns
YXNzIHNvdXJjZQkgIyBsaW5lIDI2LCA8PnQxMzE2LCA8PnQxMzAyLCAwKEk2
NCksIDAoSTMyKSwgMChJMzIpLCAwKEkzMiksIDAoSTMyKQogI2luc3RyCi5s
b2MgMiAyNgoJbGRxCSQyMixpbnRlcnByZXRlci5MU1ZGcmVlTGlzdC4yCSAj
Y2xhc3Mgc291cmNlCSAjIGxpbmUgMjYsIDw+dDEzMDksIDw+dDUzNiwgYWRk
cihpbnRlcnByZXRlci5MU1ZGcmVlTGlzdC5WQVIuMikoUDY0KQoJICMgc3Rh
bGwgCTIKICNpbnN0cgoubG9jIDIgMjYKCXN0cQkkMjIsMCgkMTcpCSAjY2xh
c3Mgc291cmNlCSAjIGxpbmUgMjYsIDw+dDEzMDksIDw+dDEzMDQsIDAoSTY0
KSwgMChJMzIpLCAwKEkzMiksIDAoSTMyKSwgMChJMzIpCiAjaW5zdHIKLmxv
YyAyIDI2CglzdHEJJDE3LGludGVycHJldGVyLkxTVkZyZWVMaXN0LjIJICNj
bGFzcyBzb3VyY2UJICMgbGluZSAyNiwgPD50MTMwNCwgPD50NTM2LCBhZGRy
KGludGVycHJldGVyLkxTVkZyZWVMaXN0LlZBUi4yKShQNjQpLCAwKEkzMiks
IDAoSTMyKSwgMChJMzIpLCAwKEkzMikKCSAjIHN0YWxsIAkxCiAjaW5zdHIK
CWJlcQkkMjQsTDE2OSQzCSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMCwgPD50
NTc3CiAjbWFya190cmFjZSAxODc7CiAjaW5zdHIKCXN0cQkkMjQsJDIuMSQy
c3BpbGxfcCArIDE2KCRzcCkJICNjbGFzcyBkbW92ZSxkbV9zcGlsbAkgIyA8
PnQ1NzcKCWxkYQkkMjUsMygkMzEpCSAjY2xhc3MgZG1vdmUsZG1fY29uc3Rh
bnQJICMgMyhTSTMyKQogI2luc3RyCglicgkkMzEsTDYyJDMKICNtYXJrX3Ry
YWNlIDE3NzsKTDE2OSQzOgogI2luc3RyCglvcgkkMCwkMzEsJDI0CSAjY2xh
c3Mgc291cmNlCSAjIGxpbmUgMCwgPD50NTc3LCA8PnQxMzA4CgkgIyBzdGFs
bCAJMQogI21hcmtfdHJhY2UgMTg0OwogI2luc3RyCglzdHEJJDI0LCQyLjEk
MnNwaWxsX3AgKyAxNigkc3ApCSAjY2xhc3MgZG1vdmUsZG1fc3BpbGwJICMg
PD50NTc3CglsZGEJJDI1LDMoJDMxKQkgI2NsYXNzIGRtb3ZlLGRtX2NvbnN0
YW50CSAjIDMoU0kzMikKICNpbnN0cgoJYnIJJDMxLEw2MiQzCgliaXMJJDMx
LCQzMSwkMzEJIyBwYWQKICNtYXJrX3RyYWNlIDE0MzsKTDE1OSQzOgogI21h
cmtfY2FsbCBjYWxsZXJfc2F2ZXMsIHJlZ3MsIGF0eXBlcygpLCBydHlwZXMo
bjY0KTsKICNpbnN0cgoJb3IJJDMxLCQzMSwkMzEJICNjbGFzcyBkbW92ZSxk
bV9yZWdpc3RlcgkgIyA8PnQ1MzMKLmxvYyAyIDI2Cglqc3IJJDI2LERZQ19D
QUNIRV9jcmVhdGUKCWJyCSQyNixGQUtFMzIKRkFLRTMyOglsZGdwCSRncCww
KCQyNikJICNjbGFzcyBzb3VyY2UJICMgbGluZSAyNiwgcmFkZHIoRFlDX0NB
Q0hFX2NyZWF0ZSkoUDY0KSwgPD50NTMzCiAjaW5zdHIKCXN0cQkkMCwkMi4x
JDJzcGlsbF9wICsgMzIwKCRzcCkJICNjbGFzcyBkbW92ZSxkbV9zcGlsbAkg
IyA8PnQxMzA3CglvcgkkMCwkMzEsJDE2CSAjY2xhc3MgZG1vdmUsZG1fcmVn
aXN0ZXIJICMgPD50MTMwNwogI2luc3RyCglzdHEJJDAsaW50ZXJwcmV0ZXIu
Q2FjaGUuMgkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDAsIDw+dDEzMDcsIDw+
dDUzNiwgYWRkcihpbnRlcnByZXRlci5DYWNoZS5WQVIuMikoUDY0KSwgMChJ
MzIpLCAwKEkzMiksIDAoSTMyKSwgMChJMzIpCglsZGEJJDE4LDEoJDMxKQkg
I2NsYXNzIGRtb3ZlLGRtX2NvbnN0YW50CSAjIDEoU0kzMikKICNpbnN0cgoJ
b3IJJDMxLCQzMSwkMzEJICNjbGFzcyBkbW92ZSxkbV9yZWdpc3RlcgkgIyA8
PnQ1MzMKCWxkcQkkMTcsJDIuMSQyc3BpbGxfcCArIDMxMigkc3ApCSAjY2xh
c3MgZG1vdmUsZG1fcmVzdG9yZQkgIyA8PnQxMzA0CgkgIyBzdGFsbCAJMQog
I2luc3RyCglicgkkMzEsTDE2MCQzCgliaXMJJDMxLCQzMSwkMzEJIyBwYWQK
ICNtYXJrX3RyYWNlIDExMzsKTDE1NyQzOgogI2luc3RyCi5sb2MgMiAyNgoJ
bGRxCSQxNyxpbnRlcnByZXRlci5MU1ZGcmVlTGlzdC4yCSAjY2xhc3Mgc291
cmNlCSAjIGxpbmUgMjYsIDw+dDEzMDQsIDw+dDUzNiwgYWRkcihpbnRlcnBy
ZXRlci5MU1ZGcmVlTGlzdC5WQVIuMikoUDY0KQoJb3IJJDMxLCQzMSwkMzEJ
ICNjbGFzcyBkbW92ZSxkbV9yZWdpc3RlcgkgIyA8PnQ1MzMKICNpbnN0cgoJ
bGRxCSQxNixpbnRlcnByZXRlci5DYWNoZS4yCSAjY2xhc3Mgc291cmNlLHJl
am9pbl9jb3B5CSAjIGxpbmUgMCwgPD50MTMwNywgPD50NTM2LCBhZGRyKGlu
dGVycHJldGVyLkNhY2hlLlZBUi4yKShQNjQpCgkgIyBzdGFsbCAJMQogI2lu
c3RyCglzdHEJJDE3LCQyLjEkMnNwaWxsX3AgKyAzMTIoJHNwKQkgI2NsYXNz
IGRtb3ZlLGRtX3NwaWxsCSAjIDw+dDEzMDQKICNpbnN0cgoJc3RxCSQxNiwk
Mi4xJDJzcGlsbF9wICsgMzIwKCRzcCkJICNjbGFzcyBkbW92ZSxkbV9zcGls
bAkgIyA8PnQxMzA3CiAjaW5zdHIKLmxvYyAyIDI2CglsZHEJJDI3LDAoJDE3
KQkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDI2LCA8PnQxMzA1LCA8PnQxMzA0
LCAwKEk2NCkKCSAjIHN0YWxsIAkyCiAjaW5zdHIKLmxvYyAyIDI2CglzdHEJ
JDI3LGludGVycHJldGVyLkxTVkZyZWVMaXN0LjIJICNjbGFzcyBzb3VyY2UJ
ICMgbGluZSAyNiwgPD50MTMwNSwgPD50NTM2LCBhZGRyKGludGVycHJldGVy
LkxTVkZyZWVMaXN0LlZBUi4yKShQNjQpLCAwKEkzMiksIDAoSTMyKSwgMChJ
MzIpLCAwKEkzMikKICNpbnN0cgoJYnIJJDMxLEwxNTgkMwogI21hcmtfdHJh
Y2UgOTk7CkwxNTQkMzoKICNpbnN0cgoubG9jIDIgMjYKCWxkcQkkMjEsRHlD
UlRfVGFibGVMb2NhdGlvbgkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDI2LCA8
PnQxMTc5LCA8PnQ1MzYsIGFkZHIoX0R5Q1JUX1RhYmxlTG9jYXRpb24kMS4w
KShQNjQpCglsZGFoCSQyNywxKCQzMSkJICNjbGFzcyBkbW92ZSxkbV9jb25z
dGFudAkgIyA2NTUzNihJMzIpCiAjaW5zdHIKLmxvYyAyIDI2CglsZGwJJDIw
LER5Q1JUX1RhYmxlUG9pbnRlckluZGV4CSAjY2xhc3Mgc291cmNlCSAjIGxp
bmUgMjYsIDxfRHlDUlRfVGFibGVQb2ludGVySW5kZXgkMS4wPnQxMTgzLCA8
PnQ1MzYsIGFkZHIoX0R5Q1JUX1RhYmxlUG9pbnRlckluZGV4JDEuMCkoUDY0
KQoubG9jIDIgMjYKCWxkYQkkMTgsRHlDUlRfVGFibGVQb2ludGVycys4CSAj
Y2xhc3Mgc291cmNlCSAjIGxpbmUgMjYsIDw+dDc4OSwgPD50NTM2LCAoYWRk
cihfRHlDUlRfVGFibGVQb2ludGVycyQxLjApKFA2NCkgKyAweDgoSTY0KSko
UDY0KQogI2luc3RyCglsZGEJJDE3LC0zMjc2OCgkMjcpCSAjY2xhc3Mgc291
cmNlCSAjIGxpbmUgMCwgPD50Nzg2LCA2NTUzNihJMzIpLCAtMzI3NjgoU0k2
NCkKCXN0bAkkMTksRHlDUlRfQnVpbGRUYWJsZVBvaW50ZXIJICNjbGFzcyBz
b3VyY2UJICMgbGluZSAwLCAxKEkzMiksIDw+dDUzNiwgYWRkcihfRHlDUlRf
QnVpbGRUYWJsZVBvaW50ZXIkMS4wKShQNjQpLCAwKEkzMiksIDAoSTMyKSwg
MChJMzIpLCAwKEkzMikKICNpbnN0cgoJYWRkcQkkMjEsJDE3LCQxOQkgI2Ns
YXNzIHNvdXJjZQkgIyBsaW5lIDAsIDw+dDExODEsIDw+dDExNzksIDw+dDc4
NgoJc3RxCSQxOSxEeUNSVF9TdGF0aWNWYWx1ZVRhYmxlCSAjY2xhc3Mgc291
cmNlCSAjIGxpbmUgMCwgPD50MTE4MSwgPD50NTM2LCBhZGRyKF9EeUNSVF9T
dGF0aWNWYWx1ZVRhYmxlJDEuMCkoUDY0KSwgMChJMzIpLCAwKEkzMiksIDAo
STMyKSwgMChJMzIpCiAjaW5zdHIKLmxvYyAyIDI2CglhZGRxCSQyMCwkMTgs
JDE4CSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMjYsIDw+dDExODUsIDxfRHlD
UlRfVGFibGVQb2ludGVySW5kZXgkMS4wPnQxMTgzLCA8PnQ3ODkKCXN0cQkk
MzEsRHlDUlRfU1ZUSW5kZXgJICNjbGFzcyBzb3VyY2UJICMgbGluZSAwLCAw
eDAoUDY0KSwgPD50NTM2LCBhZGRyKF9EeUNSVF9TVlRJbmRleCQxLjApKFA2
NCksIDAoSTMyKSwgMChJMzIpLCAwKEkzMiksIDAoSTMyKQogI2luc3RyCi5s
b2MgMiAyNgoJYWRkcQkkMjEsNjU1MzYsJDIxCSAjY2xhc3Mgc291cmNlCSAj
IGxpbmUgMjYsIDxfRHlDUlRfVGFibGVMb2NhdGlvbiQxLjA+dDExODAsIDw+
dDExNzksIDY1NTM2KEkzMikKLmxvYyAyIDI2CglzdHEJJDIxLER5Q1JUX1Rh
YmxlTG9jYXRpb24JICNjbGFzcyBzb3VyY2UJICMgbGluZSAyNiwgPF9EeUNS
VF9UYWJsZUxvY2F0aW9uJDEuMD50MTE4MCwgPD50NTM2LCBhZGRyKF9EeUNS
VF9UYWJsZUxvY2F0aW9uJDEuMCkoUDY0KSwgMChJMzIpLCAwKEkzMiksIDAo
STMyKSwgMChJMzIpCiAjaW5zdHIKLmxvYyAyIDI2CglzdHEJJDE5LDAoJDE4
KQkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDI2LCA8PnQxMTgxLCA8PnQxMTg1
LCAwKEk2NCksIDAoSTMyKSwgMChJMzIpLCAwKEkzMiksIDAoSTMyKQoubG9j
IDIgMjYKCWFkZGwJJDIwLDgsJDIwCSAjY2xhc3Mgc291cmNlCSAjIGxpbmUg
MjYsIDxfRHlDUlRfVGFibGVQb2ludGVySW5kZXgkMS4wPnQxMTg0LCA8X0R5
Q1JUX1RhYmxlUG9pbnRlckluZGV4JDEuMD50MTE4MywgOChJMzIpCiAjaW5z
dHIKLmxvYyAyIDI2CglzdGwJJDIwLER5Q1JUX1RhYmxlUG9pbnRlckluZGV4
CSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMjYsIDxfRHlDUlRfVGFibGVQb2lu
dGVySW5kZXgkMS4wPnQxMTg0LCA8PnQ1MzYsIGFkZHIoX0R5Q1JUX1RhYmxl
UG9pbnRlckluZGV4JDEuMCkoUDY0KSwgMChJMzIpLCAwKEkzMiksIDAoSTMy
KSwgMChJMzIpCiAjaW5zdHIKLmxvYyAyIDI2CglsZHEJJDIxLER5Q1JUX1dv
cmtMaXN0CSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMjYsIDxfRHlDX1RlbXAk
MS40OD50MTE4MiwgPD50NTM2LCBhZGRyKF9EeUNSVF9Xb3JrTGlzdCQxLjAp
KFA2NCkKICNpbnN0cgoJbGRsCSQyMiwkMi4xJDJzcGlsbF9wICsgOTYoJHNw
KQkgI2NsYXNzIGRtb3ZlLGRtX3Jlc3RvcmUJICMgPF9wYyQxLjE+dDQ1NAoJ
ICMgc3RhbGwgCTEKICNpbnN0cgoubG9jIDIgMjYKCWJuZQkkMjEsTDE3MCQz
CSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMjYsIDxfRHlDX1RlbXAkMS40OD50
MTE4MgpMMTU1JDM6CiAjaW5zdHIKCXN0cQkkMzEsRHlDUlRfQnJhbmNoSW5k
ZXgJICNjbGFzcyBzb3VyY2UJICMgbGluZSAwLCAweDAoUDY0KSwgPD50NTM2
LCBhZGRyKF9EeUNSVF9CcmFuY2hJbmRleCQxLjApKFA2NCksIDAoSTMyKSwg
MChJMzIpLCAwKEkzMiksIDAoSTMyKQogI2luc3RyCglicgkkMzEsTDE1NiQz
CiAjbWFya190cmFjZSAxNzA7CkwxNzAkMzoKICNpbnN0cgoJbGRhCSQyNSwz
KCQzMSkJICNjbGFzcyBkbW92ZSxkbV9jb25zdGFudAkgIyAzKFNJMzIpCgkg
IyBzdGFsbCAJMQogI2luc3RyCi5sb2MgMiAyNgoJc3RsCSQyNSwzMigkMjEp
CSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMjYsIDMoU0kzMiksIDxfRHlDX1Rl
bXAkMS40OD50MTE4MiwgMzIoSTY0KSwgMChJMzIpLCAwKEkzMiksIDAoSTMy
KSwgMChJMzIpCiAjaW5zdHIKCWJyCSQzMSxMMTU1JDMKICNtYXJrX3RyYWNl
IDExNTsKTDE1MiQzOgogI2luc3RyCglvcgkkMTksJDMxLCQyNAkgI2NsYXNz
IHNvdXJjZQkgIyBsaW5lIDAsIDw+dDU3NywgPD50MTE2NAogI2luc3RyCglv
cgkkMzEsJDMxLCQzMQkgI2NsYXNzIGRtb3ZlLGRtX3JlZ2lzdGVyCSAjIDw+
dDUzMwogI2luc3RyCglzdHEJJDI0LCQyLjEkMnNwaWxsX3AgKyAxNigkc3Ap
CSAjY2xhc3MgZG1vdmUsZG1fc3BpbGwJICMgPD50NTc3CiAjaW5zdHIKCWJy
CSQzMSxMMTUzJDMKCWJpcwkkMzEsJDMxLCQzMQkjIHBhZAogI21hcmtfdHJh
Y2UgMTIzOwpMMTUxJDM6CiAjaW5zdHIKCWxkcQkkMjAsJDIuMSQyc3BpbGxf
cCArIDI0MCgkc3ApCSAjY2xhc3MgZG1vdmUsZG1fcmVzdG9yZQkgIyA8PnQx
MTQ5CglsZGEJJDE0LDIoJDMxKQkgI2NsYXNzIGRtb3ZlLGRtX2NvbnN0YW50
CSAjIDIoU0k2NCkKICNpbnN0cgoJbGRhaAkkMjMsMzIoJDMxKQkgI2NsYXNz
IGRtb3ZlLGRtX2NvbnN0YW50CSAjIDIwOTcxNTIoSTMyKQogI2luc3RyCgls
ZGFoCSQyNywtMzIoJDMxKQkgI2NsYXNzIGRtb3ZlLGRtX2NvbnN0YW50CSAj
IDQyOTI4NzAxNDQoSTMyKQogI2luc3RyCi5sb2MgMiAyNgoJYWRkcQkkMjAs
NCwkMTIJICNjbGFzcyBzb3VyY2UJICMgbGluZSAyNiwgPD50MTE2OSwgPD50
MTE0OSwgNChTSTMyKQoubG9jIDIgMjYKCWxkbAkkMTEsMCgkMjApCSAjY2xh
c3Mgc291cmNlCSAjIGxpbmUgMjYsIDw+dDExNzMsIDw+dDExNDksIDAoSTY0
KQogI2luc3RyCi5sb2MgMiAyNgoJc3VicQkkMjEsJDEyLCQ4CSAjY2xhc3Mg
c291cmNlCSAjIGxpbmUgMjYsIDw+dDExNzAsIDw+dDExNjQsIDw+dDExNjkK
ICNpbnN0cgoubG9jIDIgMjYKCWFkZGwJJDgsMywkMTIJICNjbGFzcyBzb3Vy
Y2UJICMgbGluZSAyNiwgPD50NjI3LCA8PnQxMTcwLCAzKFNJMzIpCiAjaW5z
dHIKLmxvYyAyIDI2CgljbW92Z2UJJDgsJDgsJDEyCSAjY2xhc3Mgc291cmNl
CSAjIGxpbmUgMjYsIDw+dDYyOCwgPD50MTE3MCwgPD50MTE3MCwgPD50NjI3
CiAjaW5zdHIKLmxvYyAyIDI2CglsZGEJJDgsLTEoJDIzKQkgI2NsYXNzIHNv
dXJjZQkgIyBsaW5lIDI2LCA8PnQ3NzksIDIwOTcxNTIoSTMyKSwgLTEoU0k2
NCkKICNpbnN0cgoubG9jIDIgMjYKCXNyYQkkMTIsJDE0LCQxMgkgI2NsYXNz
IHNvdXJjZQkgIyBsaW5lIDI2LCA8PnQxMTcxLCA8PnQ2MjgsIDIoU0k2NCkK
ICNpbnN0cgoubG9jIDIgMjYKCWFuZAkkMTEsJDI3LCQxMQkgI2NsYXNzIHNv
dXJjZQkgIyBsaW5lIDI2LCA8PnQxMTc0LCA8PnQxMTczLCA0MjkyODcwMTQ0
KEkzMikKICNpbnN0cgoubG9jIDIgMjYKCWFuZAkkMTIsJDgsJDgJICNjbGFz
cyBzb3VyY2UJICMgbGluZSAyNiwgPD50MTE3MiwgPD50MTE3MSwgPD50Nzc5
CgljcHlzCSRmMzEsJGYzMSwkZjMxCSMgcGFkCiAjaW5zdHIKLmxvYyAyIDI2
CglvcgkkOCwkMTEsJDExCSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMjYsIDw+
dDExNzUsIDw+dDExNzIsIDw+dDExNzQKLmxvYyAyIDI2CglzdGwJJDExLDAo
JDIwKQkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDI2LCA8PnQxMTc1LCA8PnQx
MTQ5LCAwKEk2NCksIDAoSTMyKSwgMChJMzIpLCAwKEkzMiksIDAoSTMyKQog
I2luc3RyCglvcgkkMzEsJDMxLCQzMQkgI2NsYXNzIGRtb3ZlLGRtX3JlZ2lz
dGVyCSAjIDw+dDUzMwoJY3B5cwkkZjMxLCRmMzEsJGYzMQkjIHBhZAogI2lu
c3RyCglvcgkkMjEsJDMxLCQxOQkgI2NsYXNzIGRtb3ZlLGRtX3JlZ2lzdGVy
CSAjIDw+dDExNjQKCWJlcQkkMjQsTDE3MSQzCSAjY2xhc3Mgc291cmNlLHJl
am9pbl9jb3B5CSAjIGxpbmUgMCwgPD50NTc3CiAjaW5zdHIKCWJyCSQzMSxM
MTUzJDMKCWJpcwkkMzEsJDMxLCQzMQkjIHBhZAogI21hcmtfdHJhY2UgMTc2
OwpMMTcxJDM6CiAjaW5zdHIKCWJyCSQzMSxMMTUyJDMKCWJpcwkkMzEsJDMx
LCQzMQkjIHBhZAogI21hcmtfdHJhY2UgMTMxOwpMMTQ5JDM6CiAjaW5zdHIK
CW9yCSQzMSwkMzEsJDI1CSAjY2xhc3Mgc291cmNlLHJlam9pbl9jb3B5CSAj
IGxpbmUgMCwgPD50NTg3LCAwKEkzMikKCWxkcQkkMjcsJDIuMSQyc3BpbGxf
cCArIDI0MCgkc3ApCSAjY2xhc3MgZG1vdmUsZG1fcmVzdG9yZQkgIyA8PnQx
MTQ5CiAjaW5zdHIKCWxkcQkkMTYsJDIuMSQyc3BpbGxfcCArIDI1Nigkc3Ap
CSAjY2xhc3MgZG1vdmUsZG1fcmVzdG9yZQkgIyA8PnQxMTU0CglvcgkkMzEs
JDMxLCQzMQkgI2NsYXNzIGRtb3ZlLGRtX3JlZ2lzdGVyCSAjIDw+dDUzMwog
I2luc3RyCglzdGwJJDI1LCQyLjEkMnNwaWxsX3AoJHNwKQkgI2NsYXNzIGRt
b3ZlLGRtX3NwaWxsCSAjIDw+dDU4NwoJb3IJJDEzLCQzMSwkMjEJICNjbGFz
cyBkbW92ZSxkbV9yZWdpc3RlcgkgIyA8PnQxMTY0CiAjaW5zdHIKCWFkZHEJ
JDI3LDB4NCwkMTQJICNjbGFzcyBzb3VyY2UscmVqb2luX2NvcHkJICMgbGlu
ZSAwLCA8PnQ2MDcsIDw+dDExNDksIDB4NChQNjQpCiAjaW5zdHIKCWJyCSQz
MSxMMTUwJDMKICNtYXJrX3RyYWNlIDg2OwpMMTQ4JDM6CiAjaW5zdHIKCWxk
YQkkMjMsMigkMzEpCSAjY2xhc3MgZG1vdmUsZG1fY29uc3RhbnQJICMgMihT
STY0KQoJbGRxCSQxNywkMi4xJDJzcGlsbF9wICsgMjQ4KCRzcCkJICNjbGFz
cyBkbW92ZSxkbV9yZXN0b3JlCSAjIDw+dDExNTEKICNpbnN0cgoubG9jIDIg
MjYKCWFkZHEJJDE0LDQsJDIyCSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMjYs
IDw+dDExNTcsIDw+dDExNDksIDQoU0kzMikKLmxvYyAyIDI2CglsZGwJJDIx
LDAoJDE0KQkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDI2LCA8PnQxMTYxLCA8
PnQxMTQ5LCAwKEk2NCkKICNpbnN0cgoubG9jIDIgMjYKCXN1YnEJJDAsJDIy
LCQyMAkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDI2LCA8PnQxMTU4LCA8PnQx
MTU1LCA8PnQxMTU3CiAjaW5zdHIKLmxvYyAyIDI2CglhZGRsCSQyMCwzLCQy
MgkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDI2LCA8PnQ2MjUsIDw+dDExNTgs
IDMoU0kzMikKICNpbnN0cgoubG9jIDIgMjYKCWNtb3ZnZQkkMjAsJDIwLCQy
MgkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDI2LCA8PnQ2MjYsIDw+dDExNTgs
IDw+dDExNTgsIDw+dDYyNQogI2luc3RyCglsZGFoCSQyMCwzMigkMzEpCSAj
Y2xhc3MgZG1vdmUsZG1fY29uc3RhbnQJICMgMjA5NzE1MihJMzIpCiAjaW5z
dHIKLmxvYyAyIDI2CglzcmEJJDIyLCQyMywkMjIJICNjbGFzcyBzb3VyY2UJ
ICMgbGluZSAyNiwgPD50MTE1OSwgPD50NjI2LCAyKFNJNjQpCiAjaW5zdHIK
LmxvYyAyIDI2CglsZGEJJDIwLC0xKCQyMCkJICNjbGFzcyBzb3VyY2UJICMg
bGluZSAyNiwgPD50NzczLCAyMDk3MTUyKEkzMiksIC0xKFNJNjQpCiAjaW5z
dHIKLmxvYyAyIDI2CglhbmQJJDIyLCQyMCwkMjIJICNjbGFzcyBzb3VyY2UJ
ICMgbGluZSAyNiwgPD50MTE2MCwgPD50MTE1OSwgPD50NzczCiAjaW5zdHIK
CWxkYWgJJDI3LC0zMigkMzEpCSAjY2xhc3MgZG1vdmUsZG1fY29uc3RhbnQJ
ICMgNDI5Mjg3MDE0NChJMzIpCgkgIyBzdGFsbCAJMQogI2luc3RyCi5sb2Mg
MiAyNgoJYW5kCSQyMSwkMjcsJDIxCSAjY2xhc3Mgc291cmNlCSAjIGxpbmUg
MjYsIDw+dDExNjIsIDw+dDExNjEsIDQyOTI4NzAxNDQoSTMyKQoJY3B5cwkk
ZjMxLCRmMzEsJGYzMQkjIHBhZAogI2luc3RyCi5sb2MgMiAyNgoJb3IJJDIy
LCQyMSwkMjIJICNjbGFzcyBzb3VyY2UJICMgbGluZSAyNiwgPD50MTE2Mywg
PD50MTE2MCwgPD50MTE2MgoubG9jIDIgMjYKCXN0bAkkMjIsMCgkMTQpCSAj
Y2xhc3Mgc291cmNlCSAjIGxpbmUgMjYsIDw+dDExNjMsIDw+dDExNDksIDAo
STY0KSwgMChJMzIpLCAwKEkzMiksIDAoSTMyKSwgMChJMzIpCiAjaW5zdHIK
LmxvYyAyIDI2CglsZHEJJDIzLGludGVycHJldGVyLkxTVkZyZWVMaXN0LjQJ
ICNjbGFzcyBzb3VyY2UJICMgbGluZSAyNiwgPD50MTE1NiwgPD50NTM2LCBh
ZGRyKGludGVycHJldGVyLkxTVkZyZWVMaXN0LlZBUi40KShQNjQpCgkgIyBz
dGFsbCAJMgogI2luc3RyCi5sb2MgMiAyNgoJc3RxCSQyMywwKCQxNykJICNj
bGFzcyBzb3VyY2UJICMgbGluZSAyNiwgPD50MTE1NiwgPD50MTE1MSwgMChJ
NjQpLCAwKEkzMiksIDAoSTMyKSwgMChJMzIpLCAwKEkzMikKICNpbnN0cgou
bG9jIDIgMjYKCXN0cQkkMTcsaW50ZXJwcmV0ZXIuTFNWRnJlZUxpc3QuNAkg
I2NsYXNzIHNvdXJjZQkgIyBsaW5lIDI2LCA8PnQxMTUxLCA8PnQ1MzYsIGFk
ZHIoaW50ZXJwcmV0ZXIuTFNWRnJlZUxpc3QuVkFSLjQpKFA2NCksIDAoSTMy
KSwgMChJMzIpLCAwKEkzMiksIDAoSTMyKQoJICMgc3RhbGwgCTEKICNpbnN0
cgoJYmVxCSQyNCxMMTcyJDMJICNjbGFzcyBzb3VyY2UJICMgbGluZSAwLCA8
PnQ1NzcKICNtYXJrX3RyYWNlIDEyNDsKICNpbnN0cgoJc3RxCSQyNCwkMi4x
JDJzcGlsbF9wICsgMTYoJHNwKQkgI2NsYXNzIGRtb3ZlLGRtX3NwaWxsCSAj
IDw+dDU3NwoJY3B5cwkkZjMxLCRmMzEsJGYzMQkjIHBhZAogI2luc3RyCglz
dGwJJDI1LCQyLjEkMnNwaWxsX3AoJHNwKQkgI2NsYXNzIGRtb3ZlLGRtX3Nw
aWxsCSAjIDw+dDU4NwoJbGRhCSQyNSwzKCQzMSkJICNjbGFzcyBkbW92ZSxk
bV9jb25zdGFudAkgIyAzKFNJMzIpCiAjaW5zdHIKCWJyCSQzMSxMNjIkMwoJ
YmlzCSQzMSwkMzEsJDMxCSMgcGFkCiAjbWFya190cmFjZSAxMzU7CkwxNzIk
MzoKICNpbnN0cgoJc3RsCSQyNSwkMi4xJDJzcGlsbF9wKCRzcCkJICNjbGFz
cyBkbW92ZSxkbV9zcGlsbAkgIyA8PnQ1ODcKCW9yCSQwLCQzMSwkMjQJICNj
bGFzcyBzb3VyY2UJICMgbGluZSAwLCA8PnQ1NzcsIDw+dDExNTUKICNpbnN0
cgoJbGRhCSQyNSwzKCQzMSkJICNjbGFzcyBkbW92ZSxkbV9jb25zdGFudAkg
IyAzKFNJMzIpCiAjaW5zdHIKCXN0cQkkMjQsJDIuMSQyc3BpbGxfcCArIDE2
KCRzcCkJICNjbGFzcyBkbW92ZSxkbV9zcGlsbAkgIyA8PnQ1NzcKICNpbnN0
cgoJYnIJJDMxLEw2MiQzCgliaXMJJDMxLCQzMSwkMzEJIyBwYWQKICNtYXJr
X3RyYWNlIDk1OwpMMTQ2JDM6CiAjbWFya19jYWxsIGNhbGxlcl9zYXZlcywg
cmVncywgYXR5cGVzKCksIHJ0eXBlcyhuNjQpOwogI2luc3RyCglvcgkkMzEs
JDMxLCQzMQkgI2NsYXNzIGRtb3ZlLGRtX3JlZ2lzdGVyCSAjIDw+dDUzMwou
bG9jIDIgMjYKCWpzcgkkMjYsRFlDX0NBQ0hFX2NyZWF0ZQoJYnIJJDI2LEZB
S0UzMApGQUtFMzA6CWxkZ3AJJGdwLDAoJDI2KQkgI2NsYXNzIHNvdXJjZQkg
IyBsaW5lIDI2LCByYWRkcihEWUNfQ0FDSEVfY3JlYXRlKShQNjQpLCA8PnQ1
MzMKICNpbnN0cgoJc3RxCSQwLCQyLjEkMnNwaWxsX3AgKyAyNTYoJHNwKQkg
I2NsYXNzIGRtb3ZlLGRtX3NwaWxsCSAjIDw+dDExNTQKCW9yCSQwLCQzMSwk
MTYJICNjbGFzcyBkbW92ZSxkbV9yZWdpc3RlcgkgIyA8PnQxMTU0CiAjaW5z
dHIKCXN0cQkkMCxpbnRlcnByZXRlci5DYWNoZS40CSAjY2xhc3Mgc291cmNl
CSAjIGxpbmUgMCwgPD50MTE1NCwgPD50NTM2LCBhZGRyKGludGVycHJldGVy
LkNhY2hlLlZBUi40KShQNjQpLCAwKEkzMiksIDAoSTMyKSwgMChJMzIpLCAw
KEkzMikKCWxkYQkkMTgsMSgkMzEpCSAjY2xhc3MgZG1vdmUsZG1fY29uc3Rh
bnQJICMgMShTSTMyKQogI2luc3RyCglvcgkkMzEsJDMxLCQzMQkgI2NsYXNz
IGRtb3ZlLGRtX3JlZ2lzdGVyCSAjIDw+dDUzMwoJbGRxCSQxNywkMi4xJDJz
cGlsbF9wICsgMjQ4KCRzcCkJICNjbGFzcyBkbW92ZSxkbV9yZXN0b3JlCSAj
IDw+dDExNTEKCSAjIHN0YWxsIAkxCiAjaW5zdHIKCWJyCSQzMSxMMTQ3JDMK
CWJpcwkkMzEsJDMxLCQzMQkjIHBhZAogI21hcmtfdHJhY2UgOTM7CkwxNDQk
MzoKICNpbnN0cgoubG9jIDIgMjYKCWxkcQkkMTcsaW50ZXJwcmV0ZXIuTFNW
RnJlZUxpc3QuNAkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDI2LCA8PnQxMTUx
LCA8PnQ1MzYsIGFkZHIoaW50ZXJwcmV0ZXIuTFNWRnJlZUxpc3QuVkFSLjQp
KFA2NCkKCW9yCSQzMSwkMzEsJDMxCSAjY2xhc3MgZG1vdmUsZG1fcmVnaXN0
ZXIJICMgPD50NTMzCiAjaW5zdHIKCWxkcQkkMTYsaW50ZXJwcmV0ZXIuQ2Fj
aGUuNAkgI2NsYXNzIHNvdXJjZSxyZWpvaW5fY29weQkgIyBsaW5lIDAsIDw+
dDExNTQsIDw+dDUzNiwgYWRkcihpbnRlcnByZXRlci5DYWNoZS5WQVIuNCko
UDY0KQoJICMgc3RhbGwgCTEKICNpbnN0cgoJc3RxCSQxNywkMi4xJDJzcGls
bF9wICsgMjQ4KCRzcCkJICNjbGFzcyBkbW92ZSxkbV9zcGlsbAkgIyA8PnQx
MTUxCiAjaW5zdHIKCXN0cQkkMTYsJDIuMSQyc3BpbGxfcCArIDI1Nigkc3Ap
CSAjY2xhc3MgZG1vdmUsZG1fc3BpbGwJICMgPD50MTE1NAogI2luc3RyCi5s
b2MgMiAyNgoJbGRxCSQyNywwKCQxNykJICNjbGFzcyBzb3VyY2UJICMgbGlu
ZSAyNiwgPD50MTE1MiwgPD50MTE1MSwgMChJNjQpCgkgIyBzdGFsbCAJMgog
I2luc3RyCi5sb2MgMiAyNgoJc3RxCSQyNyxpbnRlcnByZXRlci5MU1ZGcmVl
TGlzdC40CSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMjYsIDw+dDExNTIsIDw+
dDUzNiwgYWRkcihpbnRlcnByZXRlci5MU1ZGcmVlTGlzdC5WQVIuNCkoUDY0
KSwgMChJMzIpLCAwKEkzMiksIDAoSTMyKSwgMChJMzIpCiAjaW5zdHIKCWJy
CSQzMSxMMTQ1JDMKICNtYXJrX3RyYWNlIDkxOwpMMTQyJDM6CiAjaW5zdHIK
LmxvYyAyIDI2CglsZHEJJDEyLER5Q1JUX1dvcmtMaXN0RnJlZUxpc3QJICNj
bGFzcyBzb3VyY2UJICMgbGluZSAyNiwgPD50MTE5MSwgPD50NTM2LCBhZGRy
KF9EeUNSVF9Xb3JrTGlzdEZyZWVMaXN0JDEuMCkoUDY0KQoubG9jIDIgMjYK
CWxkYQkkMTQsaW50ZXJwcmV0ZXIuRFlDLkdFX0VOVFJZLkVBR0VSLjMJICNj
bGFzcyBzb3VyY2UscmVqb2luX2NvcHkJICMgbGluZSAyNiwgPD50NzkzLCA8
PnQ1MzYsIHRhZyhpbnRlcnByZXRlci5EWUMuR0VfRU5UUlkuRUFHRVIuMyko
UDY0KQogI2luc3RyCglvcgkkMzEsJDMxLCQzMQkgI2NsYXNzIGRtb3ZlLGRt
X3JlZ2lzdGVyCSAjIDw+dDUzMwoJICMgc3RhbGwgCTEKICNpbnN0cgoubG9j
IDIgMjYKCWxkcQkkMjcsMCgkMTIpCSAjY2xhc3Mgc291cmNlCSAjIGxpbmUg
MjYsIDw+dDExOTIsIDw+dDExOTEsIDAoSTY0KQoJICMgc3RhbGwgCTIKICNp
bnN0cgoubG9jIDIgMjYKCXN0cQkkMjcsRHlDUlRfV29ya0xpc3RGcmVlTGlz
dAkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDI2LCA8PnQxMTkyLCA8PnQ1MzYs
IGFkZHIoX0R5Q1JUX1dvcmtMaXN0RnJlZUxpc3QkMS4wKShQNjQpLCAwKEkz
MiksIDAoSTMyKSwgMChJMzIpLCAwKEkzMikKICNpbnN0cgoJbGRxCSQxMSxE
eUNSVF9MYXN0QnJhbmNoCSAjY2xhc3Mgc291cmNlLHJlam9pbl9jb3B5CSAj
IGxpbmUgMCwgPD50MTE5NCwgPD50NTM2LCBhZGRyKF9EeUNSVF9MYXN0QnJh
bmNoJDEuMCkoUDY0KQogI2luc3RyCglicgkkMzEsTDE0MyQzCgliaXMJJDMx
LCQzMSwkMzEJIyBwYWQKICNtYXJrX3RyYWNlIDg1OwpMMTQwJDM6CiAjaW5z
dHIKLmxvYyAyIDI2CglsZHEJJDIxLGludGVycHJldGVyLkxTVkZyZWVMaXN0
LjMJICNjbGFzcyBzb3VyY2UJICMgbGluZSAyNiwgPD50MTE4NywgPD50NTM2
LCBhZGRyKGludGVycHJldGVyLkxTVkZyZWVMaXN0LlZBUi4zKShQNjQpCi5s
b2MgMiAyNgoJbGRhCSQxNCxpbnRlcnByZXRlci5EWUMuR0VfRU5UUlkuRUFH
RVIuMwkgI2NsYXNzIHNvdXJjZSxjc3BlYyxyZWpvaW5fY29weQkgIyBsaW5l
IDI2LCA8PnQ3OTMsIDw+dDUzNiwgdGFnKGludGVycHJldGVyLkRZQy5HRV9F
TlRSWS5FQUdFUi4zKShQNjQpCiAjaW5zdHIKCW9yCSQzMSwkMzEsJDMxCSAj
Y2xhc3MgZG1vdmUsZG1fcmVnaXN0ZXIJICMgPD50NTMzCgkgIyBzdGFsbCAJ
MQogI2luc3RyCi5sb2MgMiAyNgoJbGRxCSQyNywwKCQyMSkJICNjbGFzcyBz
b3VyY2UJICMgbGluZSAyNiwgPD50MTE4OCwgPD50MTE4NywgMChJNjQpCgkg
IyBzdGFsbCAJMgogI2luc3RyCi5sb2MgMiAyNgoJc3RxCSQyNyxpbnRlcnBy
ZXRlci5MU1ZGcmVlTGlzdC4zCSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMjYs
IDw+dDExODgsIDw+dDUzNiwgYWRkcihpbnRlcnByZXRlci5MU1ZGcmVlTGlz
dC5WQVIuMykoUDY0KSwgMChJMzIpLCAwKEkzMiksIDAoSTMyKSwgMChJMzIp
CiAjaW5zdHIKCWJyCSQzMSxMMTQxJDMKICNtYXJrX3RyYWNlIDE1MjsKXyQx
LmludGVycHJldGVyLlRBRy43LjIuZHljX2NvcHkuMDoKaW50ZXJwcmV0ZXIu
ZHluX3NldHVwX2JlZ2luXzUzXzA6CiAjaW5zdHIKCXN0cQkkMzEsRHlDUlRf
RHVtbXlHbG9iYWwJICNjbGFzcyBzb3VyY2UJICMgbGluZSAwLCAweDAoUDY0
KSwgPD50NTM2LCBhZGRyKF9EeUNSVF9EdW1teUdsb2JhbCQxLjkpKFA2NCks
IDAoSTMyKSwgMChJMzIpLCAwKEkzMiksIDAoSTMyKQoJb3IJJDMxLCQzMSwk
MzEJICNjbGFzcyBkbW92ZSxkbV9yZWdpc3RlcgkgIyA8PnQ1MzMKCSAjIHN0
YWxsIAkxCmludGVycHJldGVyLmR5bl9zZXR1cF9lbmRfNTNfMDoKICNpbnN0
cgoJc3RxCSQzMSxEeUNSVF9EdW1teUdsb2JhbAkgI2NsYXNzIHNvdXJjZQkg
IyBsaW5lIDAsIDB4MChQNjQpLCA8PnQ1MzYsIGFkZHIoX0R5Q1JUX0R1bW15
R2xvYmFsJDEuOSkoUDY0KSwgMChJMzIpLCAwKEkzMiksIDAoSTMyKSwgMChJ
MzIpCiAjaW5zdHIKCWJyCSQzMSxMMTM5JDMKICNtYXJrX3RyYWNlIDE1NzsK
XyQxLmludGVycHJldGVyLlRBRy43LjEuZHljX2NvcHkuMDoKaW50ZXJwcmV0
ZXIuZHluX3NldHVwX2JlZ2luXzUyXzA6CiAjaW5zdHIKCXN0cQkkMzEsRHlD
UlRfRHVtbXlHbG9iYWwJICNjbGFzcyBzb3VyY2UJICMgbGluZSAwLCAweDAo
UDY0KSwgPD50NTM2LCBhZGRyKF9EeUNSVF9EdW1teUdsb2JhbCQxLjkpKFA2
NCksIDAoSTMyKSwgMChJMzIpLCAwKEkzMiksIDAoSTMyKQoJb3IJJDMxLCQz
MSwkMzEJICNjbGFzcyBkbW92ZSxkbV9yZWdpc3RlcgkgIyA8PnQ1MzMKCSAj
IHN0YWxsIAkxCmludGVycHJldGVyLmR5bl9zZXR1cF9lbmRfNTJfMDoKICNp
bnN0cgoJc3RxCSQzMSxEeUNSVF9EdW1teUdsb2JhbAkgI2NsYXNzIHNvdXJj
ZQkgIyBsaW5lIDAsIDB4MChQNjQpLCA8PnQ1MzYsIGFkZHIoX0R5Q1JUX0R1
bW15R2xvYmFsJDEuOSkoUDY0KSwgMChJMzIpLCAwKEkzMiksIDAoSTMyKSwg
MChJMzIpCiAjaW5zdHIKCWJyCSQzMSxMMTM5JDMKICNtYXJrX3RyYWNlIDE1
OTsKXyQxLmludGVycHJldGVyLlRBRy43LjAuZHljX2NvcHkuMDoKaW50ZXJw
cmV0ZXIuZHluX3NldHVwX2JlZ2luXzUxXzA6CiAjaW5zdHIKCXN0cQkkMzEs
RHlDUlRfRHVtbXlHbG9iYWwJICNjbGFzcyBzb3VyY2UJICMgbGluZSAwLCAw
eDAoUDY0KSwgPD50NTM2LCBhZGRyKF9EeUNSVF9EdW1teUdsb2JhbCQxLjkp
KFA2NCksIDAoSTMyKSwgMChJMzIpLCAwKEkzMiksIDAoSTMyKQoJb3IJJDMx
LCQzMSwkMzEJICNjbGFzcyBkbW92ZSxkbV9yZWdpc3RlcgkgIyA8PnQ1MzMK
CSAjIHN0YWxsIAkxCmludGVycHJldGVyLmR5bl9zZXR1cF9lbmRfNTFfMDoK
ICNpbnN0cgoJc3RxCSQzMSxEeUNSVF9EdW1teUdsb2JhbAkgI2NsYXNzIHNv
dXJjZQkgIyBsaW5lIDAsIDB4MChQNjQpLCA8PnQ1MzYsIGFkZHIoX0R5Q1JU
X0R1bW15R2xvYmFsJDEuOSkoUDY0KSwgMChJMzIpLCAwKEkzMiksIDAoSTMy
KSwgMChJMzIpCiAjaW5zdHIKCWJyCSQzMSxMMTM5JDMKICNtYXJrX3RyYWNl
IDE5NjsKTDEzNyQzOgppbnRlcnByZXRlci5keW5fc2V0dXBfYmVnaW5fNDdf
MDoKICNpbnN0cgoJc3RxCSQzMSxEeUNSVF9EdW1teUdsb2JhbAkgI2NsYXNz
IHNvdXJjZQkgIyBsaW5lIDAsIDB4MChQNjQpLCA8PnQ1MzYsIGFkZHIoX0R5
Q1JUX0R1bW15R2xvYmFsJDEuOSkoUDY0KSwgMChJMzIpLCAwKEkzMiksIDAo
STMyKSwgMChJMzIpCi5sb2MgMiA5OAoJczRhZGRsCSQxOSwkMzEsJDE2CSAj
Y2xhc3Mgc291cmNlLHJlam9pbl9jb3B5CSAjIGxpbmUgOTgsIDw+dDUzOSwg
PF9ydCQxLjI+dDUyOSwgMChJNjQpCiAjaW5zdHIKCW9yCSQzMSwkMzEsJDMx
CSAjY2xhc3MgZG1vdmUsZG1fcmVnaXN0ZXIJICMgPD50NTMzCmludGVycHJl
dGVyLmR5bl9zZXR1cF9lbmRfNDdfMDoKICNpbnN0cgoJc3RxCSQzMSxEeUNS
VF9EdW1teUdsb2JhbAkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDAsIDB4MChQ
NjQpLCA8PnQ1MzYsIGFkZHIoX0R5Q1JUX0R1bW15R2xvYmFsJDEuOSkoUDY0
KSwgMChJMzIpLCAwKEkzMiksIDAoSTMyKSwgMChJMzIpCiAjaW5zdHIKCWJy
CSQzMSxMMTM4JDMKCWJpcwkkMzEsJDMxLCQzMQkjIHBhZAogI21hcmtfdHJh
Y2UgMTQ2OwpfJDEuaW50ZXJwcmV0ZXIuVEFHLjYuMi5keWNfY29weS4wOgpp
bnRlcnByZXRlci5keW5fc2V0dXBfYmVnaW5fNDVfMDoKICNpbnN0cgoJbGRh
CSQyMSwxKCQzMSkJICNjbGFzcyBkbW92ZSxkbV9jb25zdGFudAkgIyAxKFNJ
NjQpCglzdHEJJDMxLER5Q1JUX0R1bW15R2xvYmFsCSAjY2xhc3Mgc291cmNl
CSAjIGxpbmUgMCwgMHgwKFA2NCksIDw+dDUzNiwgYWRkcihfRHlDUlRfRHVt
bXlHbG9iYWwkMS45KShQNjQpLCAwKEkzMiksIDAoSTMyKSwgMChJMzIpLCAw
KEkzMikKICNpbnN0cgoJbGRhCSQyNywzMSgkMzEpCSAjY2xhc3MgZG1vdmUs
ZG1fY29uc3RhbnQJICMgMzEoU0k2NCkKCWNweXMJJGYzMSwkZjMxLCRmMzEJ
IyBwYWQKICNpbnN0cgoubG9jIDIgOTkKCWNtcGx0CSQxOSwkMjEsJDIxCSAj
Y2xhc3Mgc291cmNlLHJlam9pbl9jb3B5CSAjIGxpbmUgOTksIDw+dDQzMCwg
PF9ydCQxLjI+dDUyOSwgMShTSTY0KQoJc3RxCSQzMSxEeUNSVF9EdW1teUds
b2JhbAkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDAsIDB4MChQNjQpLCA8PnQ1
MzYsIGFkZHIoX0R5Q1JUX0R1bW15R2xvYmFsJDEuOSkoUDY0KSwgMChJMzIp
LCAwKEkzMiksIDAoSTMyKSwgMChJMzIpCiAjaW5zdHIKLmxvYyAyIDk5Cglj
bXBsdAkkMjcsJDE5LCQyNwkgI2NsYXNzIHNvdXJjZSxyZWpvaW5fY29weQkg
IyBsaW5lIDk5LCA8PnQ0MzEsIDMxKFNJNjQpLCA8X3J0JDEuMj50NTI5CiAj
aW5zdHIKLmxvYyAyIDk5CglzOGFkZGwJJDE5LCQzMSwkMTMJICNjbGFzcyBz
b3VyY2UsY3NwZWMscmVqb2luX2NvcHkJICMgbGluZSA5OSwgPD50ODk4LCA8
X3J0JDEuMj50NTI5LCAwKEk2NCkKICNpbnN0cgoubG9jIDIgOTkKCW9yCSQy
MSwkMjcsJDE4CSAjY2xhc3Mgc291cmNlLHJlam9pbl9jb3B5CSAjIGxpbmUg
OTksIDw+dDU2OSwgPD50NDMwLCA8PnQ0MzEKICNpbnN0cgoubG9jIDIgOTgK
CXM0YWRkbAkkMTksJDMxLCQxNgkgI2NsYXNzIHNvdXJjZSxjc3BlYyxyZWpv
aW5fY29weQkgIyBsaW5lIDk4LCA8PnQ1MzksIDxfcnQkMS4yPnQ1MjksIDAo
STY0KQogI2luc3RyCglvcgkkMzEsJDMxLCQzMQkgI2NsYXNzIGRtb3ZlLGRt
X3JlZ2lzdGVyCSAjIDw+dDUzMwoJY3B5cwkkZjMxLCRmMzEsJGYzMQkjIHBh
ZAppbnRlcnByZXRlci5keW5fc2V0dXBfZW5kXzQ1XzA6CiAjaW5zdHIKCWJy
CSQzMSxMMTM2JDMKCWJpcwkkMzEsJDMxLCQzMQkjIHBhZAogI21hcmtfdHJh
Y2UgMTQ3OwpfJDEuaW50ZXJwcmV0ZXIuVEFHLjYuMS5keWNfY29weS4wOgpp
bnRlcnByZXRlci5keW5fc2V0dXBfYmVnaW5fNDRfMDoKICNpbnN0cgoJbGRh
CSQyMSwxKCQzMSkJICNjbGFzcyBkbW92ZSxkbV9jb25zdGFudAkgIyAxKFNJ
NjQpCglzdHEJJDMxLER5Q1JUX0R1bW15R2xvYmFsCSAjY2xhc3Mgc291cmNl
CSAjIGxpbmUgMCwgMHgwKFA2NCksIDw+dDUzNiwgYWRkcihfRHlDUlRfRHVt
bXlHbG9iYWwkMS45KShQNjQpLCAwKEkzMiksIDAoSTMyKSwgMChJMzIpLCAw
KEkzMikKICNpbnN0cgoJbGRhCSQyNywzMSgkMzEpCSAjY2xhc3MgZG1vdmUs
ZG1fY29uc3RhbnQJICMgMzEoU0k2NCkKCWNweXMJJGYzMSwkZjMxLCRmMzEJ
IyBwYWQKICNpbnN0cgoubG9jIDIgOTkKCWNtcGx0CSQxOSwkMjEsJDIxCSAj
Y2xhc3Mgc291cmNlLHJlam9pbl9jb3B5CSAjIGxpbmUgOTksIDw+dDQzMCwg
PF9ydCQxLjI+dDUyOSwgMShTSTY0KQoJc3RxCSQzMSxEeUNSVF9EdW1teUds
b2JhbAkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDAsIDB4MChQNjQpLCA8PnQ1
MzYsIGFkZHIoX0R5Q1JUX0R1bW15R2xvYmFsJDEuOSkoUDY0KSwgMChJMzIp
LCAwKEkzMiksIDAoSTMyKSwgMChJMzIpCiAjaW5zdHIKLmxvYyAyIDk5Cglj
bXBsdAkkMjcsJDE5LCQyNwkgI2NsYXNzIHNvdXJjZSxyZWpvaW5fY29weQkg
IyBsaW5lIDk5LCA8PnQ0MzEsIDMxKFNJNjQpLCA8X3J0JDEuMj50NTI5CiAj
aW5zdHIKLmxvYyAyIDk5CglzOGFkZGwJJDE5LCQzMSwkMTMJICNjbGFzcyBz
b3VyY2UsY3NwZWMscmVqb2luX2NvcHkJICMgbGluZSA5OSwgPD50ODk4LCA8
X3J0JDEuMj50NTI5LCAwKEk2NCkKICNpbnN0cgoubG9jIDIgOTkKCW9yCSQy
MSwkMjcsJDE4CSAjY2xhc3Mgc291cmNlLHJlam9pbl9jb3B5CSAjIGxpbmUg
OTksIDw+dDU2OSwgPD50NDMwLCA8PnQ0MzEKICNpbnN0cgoubG9jIDIgOTgK
CXM0YWRkbAkkMTksJDMxLCQxNgkgI2NsYXNzIHNvdXJjZSxjc3BlYyxyZWpv
aW5fY29weQkgIyBsaW5lIDk4LCA8PnQ1MzksIDxfcnQkMS4yPnQ1MjksIDAo
STY0KQogI2luc3RyCglvcgkkMzEsJDMxLCQzMQkgI2NsYXNzIGRtb3ZlLGRt
X3JlZ2lzdGVyCSAjIDw+dDUzMwoJY3B5cwkkZjMxLCRmMzEsJGYzMQkjIHBh
ZAppbnRlcnByZXRlci5keW5fc2V0dXBfZW5kXzQ0XzA6CiAjaW5zdHIKCWJy
CSQzMSxMMTM2JDMKCWJpcwkkMzEsJDMxLCQzMQkjIHBhZAogI21hcmtfdHJh
Y2UgMTQ4OwpfJDEuaW50ZXJwcmV0ZXIuVEFHLjYuMC5keWNfY29weS4wOgpp
bnRlcnByZXRlci5keW5fc2V0dXBfYmVnaW5fNDNfMDoKICNpbnN0cgoJbGRh
CSQyMSwxKCQzMSkJICNjbGFzcyBkbW92ZSxkbV9jb25zdGFudAkgIyAxKFNJ
NjQpCglzdHEJJDMxLER5Q1JUX0R1bW15R2xvYmFsCSAjY2xhc3Mgc291cmNl
CSAjIGxpbmUgMCwgMHgwKFA2NCksIDw+dDUzNiwgYWRkcihfRHlDUlRfRHVt
bXlHbG9iYWwkMS45KShQNjQpLCAwKEkzMiksIDAoSTMyKSwgMChJMzIpLCAw
KEkzMikKICNpbnN0cgoJbGRhCSQyNywzMSgkMzEpCSAjY2xhc3MgZG1vdmUs
ZG1fY29uc3RhbnQJICMgMzEoU0k2NCkKCWNweXMJJGYzMSwkZjMxLCRmMzEJ
IyBwYWQKICNpbnN0cgoubG9jIDIgOTkKCWNtcGx0CSQxOSwkMjEsJDIxCSAj
Y2xhc3Mgc291cmNlLHJlam9pbl9jb3B5CSAjIGxpbmUgOTksIDw+dDQzMCwg
PF9ydCQxLjI+dDUyOSwgMShTSTY0KQoJc3RxCSQzMSxEeUNSVF9EdW1teUds
b2JhbAkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDAsIDB4MChQNjQpLCA8PnQ1
MzYsIGFkZHIoX0R5Q1JUX0R1bW15R2xvYmFsJDEuOSkoUDY0KSwgMChJMzIp
LCAwKEkzMiksIDAoSTMyKSwgMChJMzIpCiAjaW5zdHIKLmxvYyAyIDk5Cglj
bXBsdAkkMjcsJDE5LCQyNwkgI2NsYXNzIHNvdXJjZSxyZWpvaW5fY29weQkg
IyBsaW5lIDk5LCA8PnQ0MzEsIDMxKFNJNjQpLCA8X3J0JDEuMj50NTI5CiAj
aW5zdHIKLmxvYyAyIDk5CglzOGFkZGwJJDE5LCQzMSwkMTMJICNjbGFzcyBz
b3VyY2UsY3NwZWMscmVqb2luX2NvcHkJICMgbGluZSA5OSwgPD50ODk4LCA8
X3J0JDEuMj50NTI5LCAwKEk2NCkKICNpbnN0cgoubG9jIDIgOTkKCW9yCSQy
MSwkMjcsJDE4CSAjY2xhc3Mgc291cmNlLHJlam9pbl9jb3B5CSAjIGxpbmUg
OTksIDw+dDU2OSwgPD50NDMwLCA8PnQ0MzEKICNpbnN0cgoubG9jIDIgOTgK
CXM0YWRkbAkkMTksJDMxLCQxNgkgI2NsYXNzIHNvdXJjZSxjc3BlYyxyZWpv
aW5fY29weQkgIyBsaW5lIDk4LCA8PnQ1MzksIDxfcnQkMS4yPnQ1MjksIDAo
STY0KQogI2luc3RyCglvcgkkMzEsJDMxLCQzMQkgI2NsYXNzIGRtb3ZlLGRt
X3JlZ2lzdGVyCSAjIDw+dDUzMwoJY3B5cwkkZjMxLCRmMzEsJGYzMQkjIHBh
ZAppbnRlcnByZXRlci5keW5fc2V0dXBfZW5kXzQzXzA6CiAjaW5zdHIKCWJy
CSQzMSxMMTM2JDMKCWJpcwkkMzEsJDMxLCQzMQkjIHBhZAogI21hcmtfdHJh
Y2UgMTk0OwpMMTM0JDM6CmludGVycHJldGVyLmR5bl9zZXR1cF9iZWdpbl8z
OV8wOgogI2luc3RyCglsZGEJJDI3LDMxKCQzMSkJICNjbGFzcyBkbW92ZSxk
bV9jb25zdGFudAkgIyAzMShTSTY0KQoJc3RxCSQzMSxEeUNSVF9EdW1teUds
b2JhbAkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDAsIDB4MChQNjQpLCA8PnQ1
MzYsIGFkZHIoX0R5Q1JUX0R1bW15R2xvYmFsJDEuOSkoUDY0KSwgMChJMzIp
LCAwKEkzMiksIDAoSTMyKSwgMChJMzIpCiAjaW5zdHIKLmxvYyAyIDk5Cglj
bXBsdAkkMTksJDIxLCQyMQkgI2NsYXNzIHNvdXJjZSxyZWpvaW5fY29weQkg
IyBsaW5lIDk5LCA8PnQ0MzAsIDxfcnQkMS4yPnQ1MjksIDEoU0k2NCkKCWNw
eXMJJGYzMSwkZjMxLCRmMzEJIyBwYWQKICNpbnN0cgoubG9jIDIgOTkKCWNt
cGx0CSQyNywkMTksJDI3CSAjY2xhc3Mgc291cmNlLHJlam9pbl9jb3B5CSAj
IGxpbmUgOTksIDw+dDQzMSwgMzEoU0k2NCksIDxfcnQkMS4yPnQ1MjkKCXN0
cQkkMzEsRHlDUlRfRHVtbXlHbG9iYWwJICNjbGFzcyBzb3VyY2UJICMgbGlu
ZSAwLCAweDAoUDY0KSwgPD50NTM2LCBhZGRyKF9EeUNSVF9EdW1teUdsb2Jh
bCQxLjkpKFA2NCksIDAoSTMyKSwgMChJMzIpLCAwKEkzMiksIDAoSTMyKQog
I2luc3RyCi5sb2MgMiA5MgoJczRhZGRsCSQyMCwkMzEsJDE0CSAjY2xhc3Mg
c291cmNlLHJlam9pbl9jb3B5CSAjIGxpbmUgOTIsIDxfYmV0MSQxLjI+dDU0
MCwgPF9ycyQxLjI+dDUzMCwgMChJNjQpCiAjaW5zdHIKLmxvYyAyIDk5Cglv
cgkkMjEsJDI3LCQxOAkgI2NsYXNzIHNvdXJjZSxyZWpvaW5fY29weQkgIyBs
aW5lIDk5LCA8PnQ1NjksIDw+dDQzMCwgPD50NDMxCiAjaW5zdHIKLmxvYyAy
IDk5CglzOGFkZGwJJDE5LCQzMSwkMTMJICNjbGFzcyBzb3VyY2UsY3NwZWMs
cmVqb2luX2NvcHkJICMgbGluZSA5OSwgPD50ODk4LCA8X3J0JDEuMj50NTI5
LCAwKEk2NCkKICNpbnN0cgoubG9jIDIgOTgKCXM0YWRkbAkkMTksJDMxLCQx
NgkgI2NsYXNzIHNvdXJjZSxjc3BlYyxyZWpvaW5fY29weQkgIyBsaW5lIDk4
LCA8PnQ1MzksIDxfcnQkMS4yPnQ1MjksIDAoSTY0KQogI2luc3RyCglvcgkk
MzEsJDMxLCQzMQkgI2NsYXNzIGRtb3ZlLGRtX3JlZ2lzdGVyCSAjIDw+dDUz
MwppbnRlcnByZXRlci5keW5fc2V0dXBfZW5kXzM5XzA6CiAjaW5zdHIKCWJy
CSQzMSxMMTM1JDMKICNtYXJrX3RyYWNlIDQ3OwpfJDEuaW50ZXJwcmV0ZXIu
VEFHLjguMS5keWNfY29weS4wOgppbnRlcnByZXRlci5keW5fc2V0dXBfYmVn
aW5fMTNfMDoKICNpbnN0cgoJbGRhCSQyMSwxKCQzMSkJICNjbGFzcyBkbW92
ZSxkbV9jb25zdGFudAkgIyAxKFNJNjQpCiAjaW5zdHIKCWxkYQkkMTcsMzEo
JDMxKQkgI2NsYXNzIGRtb3ZlLGRtX2NvbnN0YW50CSAjIDMxKFNJNjQpCiAj
aW5zdHIKLmxvYyAyIDU0CgljbXBsdAkkMjAsJDIxLCQyMQkgI2NsYXNzIHNv
dXJjZQkgIyBsaW5lIDU0LCA8PnQzNTQsIDxfcnMkMS4yPnQ1MzAsIDEoU0k2
NCkKICNpbnN0cgoubG9jIDIgNTQKCWNtcGx0CSQxNywkMjAsJDE3CSAjY2xh
c3Mgc291cmNlCSAjIGxpbmUgNTQsIDw+dDM1NSwgMzEoU0k2NCksIDxfcnMk
MS4yPnQ1MzAKICNpbnN0cgoubG9jIDIgNTQKCXM4YWRkbAkkMjAsJDMxLCQx
NgkgI2NsYXNzIHNvdXJjZSxjc3BlYwkgIyBsaW5lIDU0LCA8PnQ5NjEsIDxf
cnMkMS4yPnQ1MzAsIDAoSTY0KQogI2luc3RyCi5sb2MgMiA1NAoJb3IJJDIx
LCQxNywkMTcJICNjbGFzcyBzb3VyY2UJICMgbGluZSA1NCwgPD50NTcwLCA8
PnQzNTQsIDw+dDM1NQogI2luc3RyCi5sb2MgMiA1MwoJczRhZGRsCSQyMCwk
MzEsJDE0CSAjY2xhc3Mgc291cmNlLGNzcGVjCSAjIGxpbmUgNTMsIDxfbXVs
dDEkMS4yPnQ1NDMsIDxfcnMkMS4yPnQ1MzAsIDAoSTY0KQoJY3B5cwkkZjMx
LCRmMzEsJGYzMQkjIHBhZAppbnRlcnByZXRlci5keW5fc2V0dXBfZW5kXzEz
XzA6CiAjaW5zdHIKCWxkYQkkMjEsMSgkMzEpCSAjY2xhc3MgZG1vdmUsZG1f
Y29uc3RhbnQJICMgMShTSTY0KQoubG9jIDIgNTQKCWJuZQkkMTcsTDE3MyQz
CSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgNTQsIDw+dDU3MAppbnRlcnByZXRl
ci5keW5fc2V0dXBfYmVnaW5fMTVfMDoKICNpbnN0cgoubG9jIDIgNTQKCWxk
cQkkMTYsaW50ZXJwcmV0ZXIkMkRZQy5TV0lUQ0hDT1BZLlRBR1BBQ0tFVC44
LjAtOCgkMTYpCSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgNTQsIDw+dDM1Nywg
PD50OTYxLCAoYWRkcihpbnRlcnByZXRlciQyRFlDLlNXSVRDSENPUFkuVEFH
QVJSQVkuOC4wKShQNjQpIC0gMHg4KEk2NCkpKFA2NCkKCWxkYQkkMTcsMzEo
JDMxKQkgI2NsYXNzIGRtb3ZlLGRtX2NvbnN0YW50CSAjIDMxKFNJNjQpCiAj
aW5zdHIKLmxvYyAyIDYwCgljbXBsdAkkMTksJDIxLCQyMQkgI2NsYXNzIHNv
dXJjZSxjc3BlYwkgIyBsaW5lIDYwLCA8PnQzNjEsIDxfcnQkMS4yPnQ1Mjks
IDEoU0k2NCkKICNpbnN0cgoubG9jIDIgNjAKCWNtcGx0CSQxNywkMTksJDE3
CSAjY2xhc3Mgc291cmNlLGNzcGVjCSAjIGxpbmUgNjAsIDw+dDM2MiwgMzEo
U0k2NCksIDxfcnQkMS4yPnQ1MjkKaW50ZXJwcmV0ZXIuZHluX3NldHVwX2Vu
ZF8xNV8wOgogI2luc3RyCi5sb2MgMiA2MAoJczhhZGRsCSQxOSwkMzEsJDEz
CSAjY2xhc3Mgc291cmNlLGNzcGVjCSAjIGxpbmUgNjAsIDw+dDkzMiwgPF9y
dCQxLjI+dDUyOSwgMChJNjQpCi5sb2MgMiA1NAoJam1wCSQzMSwoJDE2KQkg
I2NsYXNzIHNvdXJjZQkgIyBsaW5lIDU0LCA8PnQzNTcKXyQxLmludGVycHJl
dGVyLlRBRy4xLkRFRkFVTFQuZHljX2NvcHkuMDoKaW50ZXJwcmV0ZXIuZHlu
X3NldHVwX2JlZ2luXzE2XzA6CiAjaW5zdHIKLmxvYyAyIDYwCglvcgkkMjEs
JDE3LCQxNwkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDYwLCA8PnQ1NzEsIDw+
dDM2MSwgPD50MzYyCgljcHlzCSRmMzEsJGYzMSwkZjMxCSMgcGFkCiAjaW5z
dHIKCXN0cQkkMzEsRHlDUlRfRHVtbXlHbG9iYWwJICNjbGFzcyBzb3VyY2UJ
ICMgbGluZSAwLCAweDAoUDY0KSwgPD50NTM2LCBhZGRyKF9EeUNSVF9EdW1t
eUdsb2JhbCQxLjkpKFA2NCksIDAoSTMyKSwgMChJMzIpLCAwKEkzMiksIDAo
STMyKQoubG9jIDIgNTkKCXM0YWRkbAkkMTksJDMxLCQxNgkgI2NsYXNzIHNv
dXJjZSxjc3BlYwkgIyBsaW5lIDU5LCA8X211bHQyJDEuMj50NTQyLCA8X3J0
JDEuMj50NTI5LCAwKEk2NCkKICNpbnN0cgoJbGRhCSQyMSwxKCQzMSkJICNj
bGFzcyBkbW92ZSxkbV9jb25zdGFudAkgIyAxKFNJNjQpCgljcHlzCSRmMzEs
JGYzMSwkZjMxCSMgcGFkCiAjaW5zdHIKCXN0cQkkMzEsRHlDUlRfRHVtbXlH
bG9iYWwJICNjbGFzcyBzb3VyY2UJICMgbGluZSAwLCAweDAoUDY0KSwgPD50
NTM2LCBhZGRyKF9EeUNSVF9EdW1teUdsb2JhbCQxLjkpKFA2NCksIDAoSTMy
KSwgMChJMzIpLCAwKEkzMiksIDAoSTMyKQoJbGRhCSQxMiwzMSgkMzEpCSAj
Y2xhc3MgZG1vdmUsZG1fY29uc3RhbnQJICMgMzEoU0k2NCkKaW50ZXJwcmV0
ZXIuZHluX3NldHVwX2VuZF8xNl8wOgogI2luc3RyCi5sb2MgMiA2NgoJY21w
bHQJJDE4LCQyMSwkMjEJICNjbGFzcyBzb3VyY2UsY3NwZWMJICMgbGluZSA2
NiwgPD50Mzc5LCA8X3JkJDEuMj50NTI4LCAxKFNJNjQpCgljcHlzCSRmMzEs
JGYzMSwkZjMxCSMgcGFkCkwxNzQkMzoKaW50ZXJwcmV0ZXIuZHluX3NldHVw
X2JlZ2luXzE3XzA6CiAjaW5zdHIKCXN0bAkkMjAsaW50ZXJwcmV0ZXIucnRj
b25zdF8xN18wXzAoJDMxKQkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDAsIDxf
cnMkMS4yPnQ1MzAsIDB4MChQNjQpLCBpbnRlcnByZXRlci5ydGNvbnN0XzE3
XzBfMCwgMChJMzIpLCAwKEkzMiksIDAoSTMyKSwgMChJMzIpCi5sb2MgMiA2
NgoJY21wbHQJJDEyLCQxOCwkMTIJICNjbGFzcyBzb3VyY2UsY3NwZWMJICMg
bGluZSA2NiwgPD50MzgwLCAzMShTSTY0KSwgPF9yZCQxLjI+dDUyOAogI2lu
c3RyCi5sb2MgMiA2NgoJczhhZGRsCSQxOCwkMzEsJDExCSAjY2xhc3Mgc291
cmNlLGNzcGVjCSAjIGxpbmUgNjYsIDw+dDkyNywgPF9yZCQxLjI+dDUyOCwg
MChJNjQpCgljcHlzCSRmMzEsJGYzMSwkZjMxCSMgcGFkCiAjaW5zdHIKCXN0
cQkkMTQsaW50ZXJwcmV0ZXIucnRjb25zdF8xN18wXzEoJDMxKQkgI2NsYXNz
IHNvdXJjZQkgIyBsaW5lIDAsIDxfbXVsdDEkMS4yPnQ1NDMsIDB4MChQNjQp
LCBpbnRlcnByZXRlci5ydGNvbnN0XzE3XzBfMSwgMChJMzIpLCAwKEkzMiks
IDAoSTMyKSwgMChJMzIpCi5sb2MgMiA2NgoJb3IJJDIxLCQxMiwkMTIJICNj
bGFzcyBzb3VyY2UsY3NwZWMJICMgbGluZSA2NiwgPD50NTcyLCA8PnQzNzks
IDw+dDM4MAppbnRlcnByZXRlci5keW5fc2V0dXBfZW5kXzE3XzA6CiAjaW5z
dHIKLmxvYyAyIDY1CglzNGFkZGwJJDE4LCQzMSwkMTQJICNjbGFzcyBzb3Vy
Y2UsY3NwZWMJICMgbGluZSA2NSwgPD50NTQxLCA8X3JkJDEuMj50NTI4LCAw
KEk2NCkKCWNweXMJJGYzMSwkZjMxLCRmMzEJIyBwYWQKTDE3NSQzOgppbnRl
cnByZXRlci5keW5fc2V0dXBfYmVnaW5fMjFfMDoKaW50ZXJwcmV0ZXIuZHlu
X3NldHVwX2VuZF8yMV8wOgogI2luc3RyCglvcgkkMzEsJDMxLCQzMQkgI2Ns
YXNzIGRtb3ZlLGRtX3JlZ2lzdGVyCSAjIDw+dDUzMwoubG9jIDIgNjAKCWJu
ZQkkMTcsTDE3NiQzCSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgNjAsIDw+dDU3
MQppbnRlcnByZXRlci5keW5fc2V0dXBfYmVnaW5fMjNfMDoKICNpbnN0cgou
bG9jIDIgNjAKCWxkcQkkMTMsaW50ZXJwcmV0ZXIkMkRZQy5TV0lUQ0hDT1BZ
LlRBR1BBQ0tFVC43LjAtOCgkMTMpCSAjY2xhc3Mgc291cmNlCSAjIGxpbmUg
NjAsIDw+dDM2NCwgPD50OTMyLCAoYWRkcihpbnRlcnByZXRlciQyRFlDLlNX
SVRDSENPUFkuVEFHQVJSQVkuNy4wKShQNjQpIC0gMHg4KEk2NCkpKFA2NCkK
CSAjIHN0YWxsIAkyCmludGVycHJldGVyLmR5bl9zZXR1cF9lbmRfMjNfMDoK
ICNpbnN0cgoubG9jIDIgNjAKCWptcAkkMzEsKCQxMykJICNjbGFzcyBzb3Vy
Y2UJICMgbGluZSA2MCwgPD50MzY0Cl8kMS5pbnRlcnByZXRlci5UQUcuMi5E
RUZBVUxULmR5Y19jb3B5LjA6CmludGVycHJldGVyLmR5bl9zZXR1cF9iZWdp
bl8yNF8wOgogI2luc3RyCiAjaW5zdHIKCXN0cQkkMzEsRHlDUlRfRHVtbXlH
bG9iYWwJICNjbGFzcyBzb3VyY2UJICMgbGluZSAwLCAweDAoUDY0KSwgPD50
NTM2LCBhZGRyKF9EeUNSVF9EdW1teUdsb2JhbCQxLjkpKFA2NCksIDAoSTMy
KSwgMChJMzIpLCAwKEkzMiksIDAoSTMyKQoJICMgc3RhbGwgCTEKaW50ZXJw
cmV0ZXIuZHluX3NldHVwX2VuZF8yNF8wOgogI2luc3RyCglzdHEJJDMxLER5
Q1JUX0R1bW15R2xvYmFsCSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMCwgMHgw
KFA2NCksIDw+dDUzNiwgYWRkcihfRHlDUlRfRHVtbXlHbG9iYWwkMS45KShQ
NjQpLCAwKEkzMiksIDAoSTMyKSwgMChJMzIpLCAwKEkzMikKTDE3NyQzOgpp
bnRlcnByZXRlci5keW5fc2V0dXBfYmVnaW5fMjVfMDoKICNpbnN0cgogI2lu
c3RyCglzdGwJJDE5LGludGVycHJldGVyLnJ0Y29uc3RfMjVfMF8wKCQzMSkJ
ICNjbGFzcyBzb3VyY2UJICMgbGluZSAwLCA8X3J0JDEuMj50NTI5LCAweDAo
UDY0KSwgaW50ZXJwcmV0ZXIucnRjb25zdF8yNV8wXzAsIDAoSTMyKSwgMChJ
MzIpLCAwKEkzMiksIDAoSTMyKQoJICMgc3RhbGwgCTEKaW50ZXJwcmV0ZXIu
ZHluX3NldHVwX2VuZF8yNV8wOgogI2luc3RyCglzdHEJJDE2LGludGVycHJl
dGVyLnJ0Y29uc3RfMjVfMF8xKCQzMSkJICNjbGFzcyBzb3VyY2UJICMgbGlu
ZSAwLCA8X211bHQyJDEuMj50NTQyLCAweDAoUDY0KSwgaW50ZXJwcmV0ZXIu
cnRjb25zdF8yNV8wXzEsIDAoSTMyKSwgMChJMzIpLCAwKEkzMiksIDAoSTMy
KQpMMTc4JDM6CmludGVycHJldGVyLmR5bl9zZXR1cF9iZWdpbl8yOV8wOgog
I2luc3RyCmludGVycHJldGVyLmR5bl9zZXR1cF9lbmRfMjlfMDoKICNpbnN0
cgoubG9jIDIgNjYKCWJuZQkkMTIsTDE3OSQzCSAjY2xhc3Mgc291cmNlCSAj
IGxpbmUgNjYsIDw+dDU3MgppbnRlcnByZXRlci5keW5fc2V0dXBfYmVnaW5f
MzFfMDoKICNpbnN0cgoubG9jIDIgNjYKCWxkcQkkMTEsaW50ZXJwcmV0ZXIk
MkRZQy5TV0lUQ0hDT1BZLlRBR1BBQ0tFVC42LjAtOCgkMTEpCSAjY2xhc3Mg
c291cmNlCSAjIGxpbmUgNjYsIDw+dDM4MiwgPD50OTI3LCAoYWRkcihpbnRl
cnByZXRlciQyRFlDLlNXSVRDSENPUFkuVEFHQVJSQVkuNi4wKShQNjQpIC0g
MHg4KEk2NCkpKFA2NCkKCSAjIHN0YWxsIAkyCmludGVycHJldGVyLmR5bl9z
ZXR1cF9lbmRfMzFfMDoKICNpbnN0cgoJYmlzCSQzMSwkMzEsJDMxCSMgcGFk
Ci5sb2MgMiA2NgoJam1wCSQzMSwoJDExKQkgI2NsYXNzIHNvdXJjZQkgIyBs
aW5lIDY2LCA8PnQzODIKXyQxLmludGVycHJldGVyLlRBRy4zLkRFRkFVTFQu
ZHljX2NvcHkuMDoKaW50ZXJwcmV0ZXIuZHluX3NldHVwX2JlZ2luXzMyXzA6
CiAjaW5zdHIKLmxvYyAyIDY3CglhZGRsCSQyMiwxLCQyMgkgI2NsYXNzIHNv
dXJjZQkgIyBsaW5lIDY3LCA8X3BjJDEuMT50NDU0LCA8X3BjJDEuMT50NDU0
LCAxKFNJMzIpCglzdGwJJDIyLCQyLjEkMnNwaWxsX3AgKyA5Nigkc3ApCSAj
Y2xhc3MgZG1vdmUsZG1fc3BpbGwJICMgPF9wYyQxLjE+dDQ1NAogI2luc3Ry
CglzdHEJJDMxLER5Q1JUX0R1bW15R2xvYmFsCSAjY2xhc3Mgc291cmNlCSAj
IGxpbmUgMCwgMHgwKFA2NCksIDw+dDUzNiwgYWRkcihfRHlDUlRfRHVtbXlH
bG9iYWwkMS45KShQNjQpLCAwKEkzMiksIDAoSTMyKSwgMChJMzIpLCAwKEkz
MikKCSAjIHN0YWxsIAkxCmludGVycHJldGVyLmR5bl9zZXR1cF9lbmRfMzJf
MDoKICNpbnN0cgoJc3RxCSQzMSxEeUNSVF9EdW1teUdsb2JhbAkgI2NsYXNz
IHNvdXJjZQkgIyBsaW5lIDAsIDB4MChQNjQpLCA8PnQ1MzYsIGFkZHIoX0R5
Q1JUX0R1bW15R2xvYmFsJDEuOSkoUDY0KSwgMChJMzIpLCAwKEkzMiksIDAo
STMyKSwgMChJMzIpCkwxODAkMzoKaW50ZXJwcmV0ZXIuZHluX3NldHVwX2Jl
Z2luXzMzXzA6CiAjaW5zdHIKICNpbnN0cgoJc3RsCSQxOCxpbnRlcnByZXRl
ci5ydGNvbnN0XzMzXzBfMCgkMzEpCSAjY2xhc3Mgc291cmNlCSAjIGxpbmUg
MCwgPF9yZCQxLjI+dDUyOCwgMHgwKFA2NCksIGludGVycHJldGVyLnJ0Y29u
c3RfMzNfMF8wLCAwKEkzMiksIDAoSTMyKSwgMChJMzIpLCAwKEkzMikKCSAj
IHN0YWxsIAkxCmludGVycHJldGVyLmR5bl9zZXR1cF9lbmRfMzNfMDoKICNp
bnN0cgoJc3RxCSQxNCxpbnRlcnByZXRlci5ydGNvbnN0XzMzXzBfMSgkMzEp
CSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMCwgPD50NTQxLCAweDAoUDY0KSwg
aW50ZXJwcmV0ZXIucnRjb25zdF8zM18wXzEsIDAoSTMyKSwgMChJMzIpLCAw
KEkzMiksIDAoSTMyKQpMMTgxJDM6CmludGVycHJldGVyLmR5bl9zZXR1cF9i
ZWdpbl8zN18wOgogI21hcmtfY2FsbCBjYWxsZXJfc2F2ZXMsIHJlZ3MsIGF0
eXBlcygpLCBydHlwZXMoKTsKICNpbnN0cgoJYmlzCSQzMSwkMzEsJDMxCSMg
cGFkCi5sb2MgMiAyNgoJanNyCSQyNixEeUNSVF9QYXRjaEludHJhVW5pdEJy
YW5jaGVzCglicgkkMjYsRkFLRTE5CkZBS0UxOToJbGRncAkkZ3AsMCgkMjYp
CSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMjYsIHJhZGRyKER5Q1JUX1BhdGNo
SW50cmFVbml0QnJhbmNoZXMpKFA2NCksIDw+dDUzMwogI2luc3RyCglzdHEJ
JDMxLER5Q1JUX0NvZGVMb2NhdGlvbgkgI2NsYXNzIHNvdXJjZQkgIyBsaW5l
IDAsIDB4MChQNjQpLCA8PnQ1MzYsIGFkZHIoX0R5Q1JUX0NvZGVMb2NhdGlv
biQxLjApKFA2NCksIDAoSTMyKSwgMChJMzIpLCAwKEkzMiksIDAoSTMyKQoJ
bGRhCSQxOCwxKCQzMSkJICNjbGFzcyBkbW92ZSxkbV9jb25zdGFudAkgIyAx
KFNJMzIpCiAjaW5zdHIKCWxkcQkkMjEsRHlDUlRfTGFzdEJyYW5jaAkgI2Ns
YXNzIHNvdXJjZQkgIyBsaW5lIDAsIDw+dDExOTUsIDw+dDUzNiwgYWRkcihf
RHlDUlRfTGFzdEJyYW5jaCQxLjApKFA2NCkKCW9yCSQzMSwkMzEsJDMxCSAj
Y2xhc3MgZG1vdmUsZG1fcmVnaXN0ZXIJICMgPD50NTMzCiAjaW5zdHIKLmxv
YyAyIDI2CglsZHEJJDE0LGludGVycHJldGVyLkxTVkZyZWVMaXN0LjIJICNj
bGFzcyBzb3VyY2UJICMgbGluZSAyNiwgPD50MTE5NiwgPD50NTM2LCBhZGRy
KGludGVycHJldGVyLkxTVkZyZWVMaXN0LlZBUi4yKShQNjQpCiAjaW5zdHIK
CWxkbAkkMjIsJDIuMSQyc3BpbGxfcCArIDk2KCRzcCkJICNjbGFzcyBkbW92
ZSxkbV9yZXN0b3JlCSAjIDxfcGMkMS4xPnQ0NTQKICNpbnN0cgoJc3RxCSQy
MSwkMi4xJDJzcGlsbF9wICsgMjcyKCRzcCkJICNjbGFzcyBkbW92ZSxkbV9z
cGlsbAkgIyA8PnQxMTk1CgljcHlzCSRmMzEsJGYzMSwkZjMxCSMgcGFkCmlu
dGVycHJldGVyLmR5bl9zZXR1cF9lbmRfMzdfMDoKICNpbnN0cgoJbGRxCSQy
MywkMi4xJDJzcGlsbF9wICsgODgoJHNwKQkgI2NsYXNzIGRtb3ZlLGRtX3Jl
c3RvcmUJICMgPF9ieXRlY29kZXMkMS4xPnQ0NTUKLmxvYyAyIDI2CglibmUJ
JDE0LEwxODIkMwkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDI2LCA8PnQxMTk2
CiAjaW5zdHIKLmxvYyAyIDI2CglsZHEJJDE3LER5Q1JUX1RlbXBMb2NhdGlv
bgkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDI2LCA8PnQxMTk3LCA8PnQ1MzYs
IGFkZHIoX0R5Q1JUX1RlbXBMb2NhdGlvbiQxLjApKFA2NCkKICNpbnN0cgoJ
bGRxCSQxNixpbnRlcnByZXRlci5DYWNoZS4yCSAjY2xhc3Mgc291cmNlCSAj
IGxpbmUgMCwgPD50MTIwMCwgPD50NTM2LCBhZGRyKGludGVycHJldGVyLkNh
Y2hlLlZBUi4yKShQNjQpCgkgIyBzdGFsbCAJMQogI2luc3RyCglzdHEJJDE3
LCQyLjEkMnNwaWxsX3AgKyAyODAoJHNwKQkgI2NsYXNzIGRtb3ZlLGRtX3Nw
aWxsCSAjIDw+dDExOTcKLmxvYyAyIDI2CglhZGRxCSQxNywxNiwkMjEJICNj
bGFzcyBzb3VyY2UJICMgbGluZSAyNiwgPF9EeUNSVF9UZW1wTG9jYXRpb24k
MS4wPnQxMTk5LCA8PnQxMTk3LCAxNihJMzIpCiAjaW5zdHIKCXN0cQkkMTYs
JDIuMSQyc3BpbGxfcCArIDI4OCgkc3ApCSAjY2xhc3MgZG1vdmUsZG1fc3Bp
bGwJICMgPD50MTIwMAogI2luc3RyCi5sb2MgMiAyNgoJc3RxCSQyMSxEeUNS
VF9UZW1wTG9jYXRpb24JICNjbGFzcyBzb3VyY2UJICMgbGluZSAyNiwgPF9E
eUNSVF9UZW1wTG9jYXRpb24kMS4wPnQxMTk5LCA8PnQ1MzYsIGFkZHIoX0R5
Q1JUX1RlbXBMb2NhdGlvbiQxLjApKFA2NCksIDAoSTMyKSwgMChJMzIpLCAw
KEkzMiksIDAoSTMyKQpMMTgzJDM6CiAjaW5zdHIKCXN0bAkkMjIsMCgkMTcp
CSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMCwgPF9wYyQxLjE+dDQ1NCwgPD50
MTE5NywgMChTSTMyKSwgMChJMzIpLCAwKEkzMiksIDAoSTMyKSwgMChJMzIp
CiAjaW5zdHIKCXN0bAkkMzEsNCgkMTcpCSAjY2xhc3Mgc291cmNlCSAjIGxp
bmUgMCwgMChTSTMyKSwgPD50MTE5NywgNChTSTMyKSwgMChJMzIpLCAwKEkz
MiksIDAoSTMyKSwgMChJMzIpCiAjaW5zdHIKCXN0cQkkMjMsOCgkMTcpCSAj
Y2xhc3Mgc291cmNlCSAjIGxpbmUgMCwgPF9ieXRlY29kZXMkMS4xPnQ0NTUs
IDw+dDExOTcsIDgoU0kzMiksIDAoSTMyKSwgMChJMzIpLCAwKEkzMiksIDAo
STMyKQoJICMgc3RhbGwgCTEKICNpbnN0cgoJYmVxCSQxNixMMTg0JDMJICNj
bGFzcyBzb3VyY2UJICMgbGluZSAwLCA8PnQxMjAwCkwxODUkMzoKICNtYXJr
X2NhbGwgY2FsbGVyX3NhdmVzLCByZWdzLCBhdHlwZXMobjY0LG42NCxuMzIp
LCBydHlwZXMobjY0KTsKICNpbnN0cgoJYmlzCSQzMSwkMzEsJDMxCSMgcGFk
Ci5sb2MgMiAyNgoJanNyCSQyNixEWUNfQ0FDSEVfbG9va3VwCglicgkkMjYs
RkFLRTIwCkZBS0UyMDoJbGRncAkkZ3AsMCgkMjYpCSAjY2xhc3Mgc291cmNl
CSAjIGxpbmUgMjYsIHJhZGRyKERZQ19DQUNIRV9sb29rdXApKFA2NCksIDw+
dDUzMywgPD50MTIwMCwgPD50MTE5NywgMShTSTMyKQogI2luc3RyCglsZGwJ
JDI1LCQyLjEkMnNwaWxsX3AoJHNwKQkgI2NsYXNzIGRtb3ZlLGRtX3Jlc3Rv
cmUJICMgPD50NTg3Ci5sb2MgMiAyNgoJc3VicQkkMzEsMzIsJDIxCSAjY2xh
c3Mgc291cmNlLGNzcGVjCSAjIGxpbmUgMjYsIDxfQWxpZ25lZEFkZHJlc3Mk
MS41OD50ODAyLCAwKEk2NCksIDMyKFNJNjQpCiAjaW5zdHIKCWxkcQkkMTQs
JDIuMSQyc3BpbGxfcCArIDI3Migkc3ApCSAjY2xhc3MgZG1vdmUsZG1fcmVz
dG9yZQkgIyA8PnQxMTk1CglsZGEJJDE4LDEoJDMxKQkgI2NsYXNzIGRtb3Zl
LGRtX2NvbnN0YW50CSAjIDEoU0kzMikKICNpbnN0cgoJbGRxCSQyNCwkMi4x
JDJzcGlsbF9wICsgMTYoJHNwKQkgI2NsYXNzIGRtb3ZlLGRtX3Jlc3RvcmUJ
ICMgPD50NTc3CglibmUJJDAsTDE4NiQzCSAjY2xhc3Mgc291cmNlCSAjIGxp
bmUgMCwgPD50MTIwMQogI2luc3RyCi5sb2MgMiAyNgoJbGRxCSQxMyxEeUNS
VF9Db2RlTG9jYXRpb24JICNjbGFzcyBzb3VyY2UJICMgbGluZSAyNiwgPD50
MTIxMCwgPD50NTM2LCBhZGRyKF9EeUNSVF9Db2RlTG9jYXRpb24kMS4wKShQ
NjQpCglvcgkkMzEsJDMxLCQzMQkgI2NsYXNzIGRtb3ZlLGRtX3JlZ2lzdGVy
CSAjIDw+dDUzMwogI2luc3RyCglhZGRxCSQxNCwweDQsJDE0CSAjY2xhc3Mg
c291cmNlLGNzcGVjCSAjIGxpbmUgMCwgPD50NjA4LCA8PnQxMTk1LCAweDQo
UDY0KQoJbGRxCSQxNywkMi4xJDJzcGlsbF9wICsgMjgwKCRzcCkJICNjbGFz
cyBkbW92ZSxkbV9yZXN0b3JlCSAjIDw+dDExOTcKICNpbnN0cgoJb3IJJDMx
LCQzMSwkMTIJICNjbGFzcyBzb3VyY2UsY3NwZWMJICMgbGluZSAwLCA8PnQ1
ODcsIDAoSTMyKQoubG9jIDIgMjYKCWJlcQkkMjUsTDE4NyQzCSAjY2xhc3Mg
c291cmNlCSAjIGxpbmUgMjYsIDw+dDU4NwogI2luc3RyCi5sb2MgMiAyNgoJ
bGRxCSQxMSxEeUNSVF9QYWRkZWRCeXRlcwkgI2NsYXNzIHNvdXJjZQkgIyBs
aW5lIDI2LCA8X0R5Q1JUX1BhZGRlZEJ5dGVzJDEuMD50MTIxMywgPD50NTM2
LCBhZGRyKF9EeUNSVF9QYWRkZWRCeXRlcyQxLjApKFA2NCkKLmxvYyAyIDI2
CglhZGRxCSQxMyw2MywkOAkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDI2LCA8
PnQxMjExLCA8PnQxMjEwLCA2MyhTSTY0KQogI2luc3RyCglzdGwJJDEyLCQy
LjEkMnNwaWxsX3AoJHNwKQkgI2NsYXNzIGRtb3ZlLGRtX3NwaWxsCSAjIDw+
dDU4NwoubG9jIDIgMjYKCWFuZAkkOCwkMjEsJDIxCSAjY2xhc3Mgc291cmNl
CSAjIGxpbmUgMjYsIDxfQWxpZ25lZEFkZHJlc3MkMS41OD50MTIxMiwgPD50
MTIxMSwgPF9BbGlnbmVkQWRkcmVzcyQxLjU4PnQ4MDIKICNpbnN0cgoubG9j
IDIgMjYKCXN1YnEJJDIxLCQxMywkMTMJICNjbGFzcyBzb3VyY2UJICMgbGlu
ZSAyNiwgPF9EeUNSVF9QYWRkZWRCeXRlcyQxLjA+dDgwMywgPF9BbGlnbmVk
QWRkcmVzcyQxLjU4PnQxMjEyLCA8PnQxMjEwCglsZHEJJDE2LCQyLjEkMnNw
aWxsX3AgKyAyODgoJHNwKQkgI2NsYXNzIGRtb3ZlLGRtX3Jlc3RvcmUJICMg
PD50MTIwMAogI2luc3RyCi5sb2MgMiAyNgoJYWRkcQkkMTMsJDExLCQxMQkg
I2NsYXNzIHNvdXJjZQkgIyBsaW5lIDI2LCA8X0R5Q1JUX1BhZGRlZEJ5dGVz
JDEuMD50MTIxNCwgPF9EeUNSVF9QYWRkZWRCeXRlcyQxLjA+dDgwMywgPF9E
eUNSVF9QYWRkZWRCeXRlcyQxLjA+dDEyMTMKLmxvYyAyIDI2CglzdHEJJDEx
LER5Q1JUX1BhZGRlZEJ5dGVzCSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMjYs
IDxfRHlDUlRfUGFkZGVkQnl0ZXMkMS4wPnQxMjE0LCA8PnQ1MzYsIGFkZHIo
X0R5Q1JUX1BhZGRlZEJ5dGVzJDEuMCkoUDY0KSwgMChJMzIpLCAwKEkzMiks
IDAoSTMyKSwgMChJMzIpCiAjaW5zdHIKLmxvYyAyIDI2CglvcgkkMjEsJDMx
LCQyMQkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDI2LCA8PnQxMjEwLCA8X0Fs
aWduZWRBZGRyZXNzJDEuNTg+dDEyMTIKCSAjIHN0YWxsIAkxCkwxODgkMzoK
ICNpbnN0cgoJY21wZXEJJDIxLCQxNCwkMTQJICNjbGFzcyBzb3VyY2UJICMg
bGluZSAwLCA8PnQ4MDEsIDw+dDEyMTAsIDw+dDYwOAoJICMgc3RhbGwgCTEK
ICNpbnN0cgoJYmVxCSQxNCxMMTg5JDMJICNjbGFzcyBzb3VyY2UJICMgbGlu
ZSAwLCA8PnQ4MDEKICNpbnN0cgoJbGRxCSQxOSwkMi4xJDJzcGlsbF9wICsg
MjcyKCRzcCkJICNjbGFzcyBzb3VyY2UJICMgbGluZSAwLCA8PnQxMjEwLCA8
PnQxMTk1CgkgIyBzdGFsbCAJMQogI2luc3RyCgliZXEJJDI0LEwxOTAkMwkg
I2NsYXNzIHNvdXJjZQkgIyBsaW5lIDAsIDw+dDU3NwpMMTkxJDM6CiAjaW5z
dHIKCXN0cQkkMTksJDIuMSQyc3BpbGxfcCArIDI5Nigkc3ApCSAjY2xhc3Mg
ZG1vdmUsZG1fc3BpbGwJICMgPD50MTIxMAogI21hcmtfY2FsbCBjYWxsZXJf
c2F2ZXMsIHJlZ3MsIGF0eXBlcyhuNjQsbjY0LG4zMixuNjQpLCBydHlwZXMo
KTsKICNpbnN0cgoJYmlzCSQzMSwkMzEsJDMxCSMgcGFkCi5sb2MgMiAyNgoJ
anNyCSQyNixEWUNfQ0FDSEVfaW5zZXJ0CglicgkkMjYsRkFLRTIxCkZBS0Uy
MToJbGRncAkkZ3AsMCgkMjYpCSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMjYs
IHJhZGRyKERZQ19DQUNIRV9pbnNlcnQpKFA2NCksIDw+dDUzMywgPD50MTIw
MCwgPD50MTE5NywgMShTSTMyKSwgPD50MTIxMAogI2luc3RyCglsZHEJJDEz
LCQyLjEkMnNwaWxsX3AgKyAyOTYoJHNwKQkgI2NsYXNzIGRtb3ZlLGRtX3Jl
c3RvcmUJICMgPD50MTIxMAoJbGRhaAkkMjcsMSgkMzEpCSAjY2xhc3MgZG1v
dmUsZG1fY29uc3RhbnQJICMgNjU1MzYoSTMyKQogI2luc3RyCglsZHEJJDIx
LER5Q1JUX1N0YXRpY1ZhbHVlVGFibGUJICNjbGFzcyBzb3VyY2UJICMgbGlu
ZSAwLCA8PnQxMjIyLCA8PnQ1MzYsIGFkZHIoX0R5Q1JUX1N0YXRpY1ZhbHVl
VGFibGUkMS4wKShQNjQpCglsZGEJJDE5LDEoJDMxKQkgI2NsYXNzIGRtb3Zl
LGRtX2NvbnN0YW50CSAjIDEoSTMyKQoJICMgc3RhbGwgCTEKICNpbnN0cgoJ
c3RxCSQxMyxEeUNSVF9TdGl0Y2hMb2NhdGlvbgkgI2NsYXNzIHNvdXJjZQkg
IyBsaW5lIDAsIDw+dDEyMTAsIDw+dDUzNiwgYWRkcihfRHlDUlRfU3RpdGNo
TG9jYXRpb24kMS4wKShQNjQpLCAwKEkzMiksIDAoSTMyKSwgMChJMzIpLCAw
KEkzMikKCSAjIHN0YWxsIAkxCiAjaW5zdHIKCWJlcQkkMjEsTDE5MiQzCSAj
Y2xhc3Mgc291cmNlCSAjIGxpbmUgMCwgPD50MTIyMgogI2luc3RyCglsZGwJ
JDIxLER5Q1JUX1NWVEluZGV4CSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMCwg
PD50MTIyMywgPD50NTM2LCBhZGRyKF9EeUNSVF9TVlRJbmRleCQxLjApKFA2
NCkKCSAjIHN0YWxsIAkyCiAjaW5zdHIKCWFkZGwJJDIxLDIxNiwkMjEJICNj
bGFzcyBzb3VyY2UJICMgbGluZSAwLCA8PnQxMjI0LCA8PnQxMjIzLCAyMTYo
U0kzMikKICNpbnN0cgoJY21wbGUJJDIxLCQyNywkMTcJICNjbGFzcyBzb3Vy
Y2UJICMgbGluZSAwLCA8PnQ4MDksIDw+dDEyMjQsIDY1NTM2KEkzMikKCSAj
IHN0YWxsIAkxCiAjaW5zdHIKCWJlcQkkMTcsTDE5MiQzCSAjY2xhc3Mgc291
cmNlCSAjIGxpbmUgMCwgPD50ODA5CiAjaW5zdHIKCXN0bAkkMTksRHlDUlRf
QnVpbGRUYWJsZVBvaW50ZXIJICNjbGFzcyBzb3VyY2UJICMgbGluZSAwLCAx
KEkzMiksIDw+dDUzNiwgYWRkcihfRHlDUlRfQnVpbGRUYWJsZVBvaW50ZXIk
MS4wKShQNjQpLCAwKEkzMiksIDAoSTMyKSwgMChJMzIpLCAwKEkzMikKCWNw
eXMJJGYzMSwkZjMxLCRmMzEJIyBwYWQKICNtYXJrX3RyYWNlIDE4MDsKICNp
bnN0cgoJbGRhaAkkMTcsMSgkMzEpCSAjY2xhc3MgZG1vdmUsZG1fY29uc3Rh
bnQJICMgNjU1MzYoSTMyKQoJbGRsCSQyMiwkMi4xJDJzcGlsbF9wICsgOTYo
JHNwKQkgI2NsYXNzIGRtb3ZlLGRtX3Jlc3RvcmUJICMgPF9wYyQxLjE+dDQ1
NAogI2luc3RyCglsZGEJJDE4LDExKCQzMSkJICNjbGFzcyBkbW92ZSxkbV9j
b25zdGFudAkgIyAxMShTSTY0KQogI2luc3RyCglsZGEJJDE5LDE2KCQzMSkJ
ICNjbGFzcyBkbW92ZSxkbV9jb25zdGFudAkgIyAxNihTSTY0KQogI2luc3Ry
CglsZGEJJDIwLDIxKCQzMSkJICNjbGFzcyBkbW92ZSxkbV9jb25zdGFudAkg
IyAyMShTSTY0KQoJY3B5cwkkZjMxLCRmMzEsJGYzMQkjIHBhZAogI2luc3Ry
CglsZGEJJDIxLDQoJDMxKQkgI2NsYXNzIGRtb3ZlLGRtX2NvbnN0YW50CSAj
IDQoSTY0KQoJbGRxCSQyMywkMi4xJDJzcGlsbF9wICsgODgoJHNwKQkgI2Ns
YXNzIGRtb3ZlLGRtX3Jlc3RvcmUJICMgPF9ieXRlY29kZXMkMS4xPnQ0NTUK
ICNpbnN0cgoJbGRhCSQxNiwyNigkMzEpCSAjY2xhc3MgZG1vdmUsZG1fY29u
c3RhbnQJICMgMjYoU0k2NCkKCWJyCSQzMSxMMTkzJDMKICNtYXJrX3RyYWNl
IDgwOwpMMTkyJDM6CiAjaW5zdHIKLmxvYyAyIDI2CglsZHEJJDE1LER5Q1JU
X1RhYmxlTG9jYXRpb24JICNjbGFzcyBzb3VyY2UJICMgbGluZSAyNiwgPD50
MTIyNSwgPD50NTM2LCBhZGRyKF9EeUNSVF9UYWJsZUxvY2F0aW9uJDEuMCko
UDY0KQoJbGRhaAkkMTcsMSgkMzEpCSAjY2xhc3MgZG1vdmUsZG1fY29uc3Rh
bnQJICMgNjU1MzYoSTMyKQogI2luc3RyCi5sb2MgMiAyNgoJbGRsCSQxMSxE
eUNSVF9UYWJsZVBvaW50ZXJJbmRleAkgI2NsYXNzIHNvdXJjZQkgIyBsaW5l
IDI2LCA8X0R5Q1JUX1RhYmxlUG9pbnRlckluZGV4JDEuMD50MTIyOSwgPD50
NTM2LCBhZGRyKF9EeUNSVF9UYWJsZVBvaW50ZXJJbmRleCQxLjApKFA2NCkK
LmxvYyAyIDI2CglsZGEJJDgsRHlDUlRfVGFibGVQb2ludGVycys4CSAjY2xh
c3Mgc291cmNlCSAjIGxpbmUgMjYsIDw+dDgxNSwgPD50NTM2LCAoYWRkcihf
RHlDUlRfVGFibGVQb2ludGVycyQxLjApKFA2NCkgKyAweDgoSTY0KSkoUDY0
KQogI2luc3RyCglsZGEJJDcsLTMyNzY4KCQxNykJICNjbGFzcyBzb3VyY2UJ
ICMgbGluZSAwLCA8PnQ4MTIsIDY1NTM2KEkzMiksIC0zMjc2OChTSTY0KQoJ
c3RsCSQxOSxEeUNSVF9CdWlsZFRhYmxlUG9pbnRlcgkgI2NsYXNzIHNvdXJj
ZQkgIyBsaW5lIDAsIDEoSTMyKSwgPD50NTM2LCBhZGRyKF9EeUNSVF9CdWls
ZFRhYmxlUG9pbnRlciQxLjApKFA2NCksIDAoSTMyKSwgMChJMzIpLCAwKEkz
MiksIDAoSTMyKQogI2luc3RyCglhZGRxCSQxNSwkNywkNgkgI2NsYXNzIHNv
dXJjZQkgIyBsaW5lIDAsIDw+dDEyMjcsIDw+dDEyMjUsIDw+dDgxMgoJc3Rx
CSQ2LER5Q1JUX1N0YXRpY1ZhbHVlVGFibGUJICNjbGFzcyBzb3VyY2UJICMg
bGluZSAwLCA8PnQxMjI3LCA8PnQ1MzYsIGFkZHIoX0R5Q1JUX1N0YXRpY1Zh
bHVlVGFibGUkMS4wKShQNjQpLCAwKEkzMiksIDAoSTMyKSwgMChJMzIpLCAw
KEkzMikKICNpbnN0cgoubG9jIDIgMjYKCWFkZHEJJDExLCQ4LCQ4CSAjY2xh
c3Mgc291cmNlCSAjIGxpbmUgMjYsIDw+dDEyMzEsIDxfRHlDUlRfVGFibGVQ
b2ludGVySW5kZXgkMS4wPnQxMjI5LCA8PnQ4MTUKCXN0cQkkMzEsRHlDUlRf
U1ZUSW5kZXgJICNjbGFzcyBzb3VyY2UJICMgbGluZSAwLCAweDAoUDY0KSwg
PD50NTM2LCBhZGRyKF9EeUNSVF9TVlRJbmRleCQxLjApKFA2NCksIDAoSTMy
KSwgMChJMzIpLCAwKEkzMiksIDAoSTMyKQogI2luc3RyCi5sb2MgMiAyNgoJ
YWRkcQkkMTUsNjU1MzYsJDE1CSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMjYs
IDxfRHlDUlRfVGFibGVMb2NhdGlvbiQxLjA+dDEyMjYsIDw+dDEyMjUsIDY1
NTM2KEkzMikKLmxvYyAyIDI2CglzdHEJJDE1LER5Q1JUX1RhYmxlTG9jYXRp
b24JICNjbGFzcyBzb3VyY2UJICMgbGluZSAyNiwgPF9EeUNSVF9UYWJsZUxv
Y2F0aW9uJDEuMD50MTIyNiwgPD50NTM2LCBhZGRyKF9EeUNSVF9UYWJsZUxv
Y2F0aW9uJDEuMCkoUDY0KSwgMChJMzIpLCAwKEkzMiksIDAoSTMyKSwgMChJ
MzIpCiAjaW5zdHIKLmxvYyAyIDI2CglzdHEJJDYsMCgkOCkJICNjbGFzcyBz
b3VyY2UJICMgbGluZSAyNiwgPD50MTIyNywgPD50MTIzMSwgMChJNjQpLCAw
KEkzMiksIDAoSTMyKSwgMChJMzIpLCAwKEkzMikKLmxvYyAyIDI2CglhZGRs
CSQxMSw4LCQxMQkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDI2LCA8X0R5Q1JU
X1RhYmxlUG9pbnRlckluZGV4JDEuMD50MTIzMCwgPF9EeUNSVF9UYWJsZVBv
aW50ZXJJbmRleCQxLjA+dDEyMjksIDgoSTMyKQogI2luc3RyCi5sb2MgMiAy
NgoJc3RsCSQxMSxEeUNSVF9UYWJsZVBvaW50ZXJJbmRleAkgI2NsYXNzIHNv
dXJjZQkgIyBsaW5lIDI2LCA8X0R5Q1JUX1RhYmxlUG9pbnRlckluZGV4JDEu
MD50MTIzMCwgPD50NTM2LCBhZGRyKF9EeUNSVF9UYWJsZVBvaW50ZXJJbmRl
eCQxLjApKFA2NCksIDAoSTMyKSwgMChJMzIpLCAwKEkzMiksIDAoSTMyKQoJ
bGRhCSQyMSw0KCQzMSkJICNjbGFzcyBkbW92ZSxkbV9jb25zdGFudAkgIyA0
KEk2NCkKICNpbnN0cgoubG9jIDIgMjYKCWxkcQkkMTUsRHlDUlRfV29ya0xp
c3QJICNjbGFzcyBzb3VyY2UJICMgbGluZSAyNiwgPF9EeUNfVGVtcCQxLjQ4
PnQxMjI4LCA8PnQ1MzYsIGFkZHIoX0R5Q1JUX1dvcmtMaXN0JDEuMCkoUDY0
KQoJbGRhCSQyMCwyMSgkMzEpCSAjY2xhc3MgZG1vdmUsZG1fY29uc3RhbnQJ
ICMgMjEoU0k2NCkKICNpbnN0cgoJbGRsCSQyMiwkMi4xJDJzcGlsbF9wICsg
OTYoJHNwKQkgI2NsYXNzIGRtb3ZlLGRtX3Jlc3RvcmUJICMgPF9wYyQxLjE+
dDQ1NAoJbGRhCSQxOSwxNigkMzEpCSAjY2xhc3MgZG1vdmUsZG1fY29uc3Rh
bnQJICMgMTYoU0k2NCkKICNpbnN0cgoJbGRxCSQyMywkMi4xJDJzcGlsbF9w
ICsgODgoJHNwKQkgI2NsYXNzIGRtb3ZlLGRtX3Jlc3RvcmUJICMgPF9ieXRl
Y29kZXMkMS4xPnQ0NTUKCWxkYQkkMTgsMTEoJDMxKQkgI2NsYXNzIGRtb3Zl
LGRtX2NvbnN0YW50CSAjIDExKFNJNjQpCiAjaW5zdHIKCWxkYQkkMTYsMjYo
JDMxKQkgI2NsYXNzIGRtb3ZlLGRtX2NvbnN0YW50CSAjIDI2KFNJNjQpCi5s
b2MgMiAyNgoJYm5lCSQxNSxMMTk0JDMJICNjbGFzcyBzb3VyY2UJICMgbGlu
ZSAyNiwgPF9EeUNfVGVtcCQxLjQ4PnQxMjI4CkwxOTMkMzoKICNpbnN0cgoJ
c3RxCSQzMSxEeUNSVF9CcmFuY2hJbmRleAkgI2NsYXNzIHNvdXJjZQkgIyBs
aW5lIDAsIDB4MChQNjQpLCA8PnQ1MzYsIGFkZHIoX0R5Q1JUX0JyYW5jaElu
ZGV4JDEuMCkoUDY0KSwgMChJMzIpLCAwKEkzMiksIDAoSTMyKSwgMChJMzIp
CglsZGEJJDE0LDEoJDMxKQkgI2NsYXNzIGRtb3ZlLGRtX2NvbnN0YW50CSAj
IDEoU0k2NCkKICNpbnN0cgoJbGRhCSQxMyw2KCQzMSkJICNjbGFzcyBkbW92
ZSxkbV9jb25zdGFudAkgIyA2KFNJNjQpCiAjaW5zdHIKCWxkYQkkMTIsMzEo
JDMxKQkgI2NsYXNzIGRtb3ZlLGRtX2NvbnN0YW50CSAjIDMxKFNJNjQpCiAj
aW5zdHIKCWJyCSQzMSxMNDIkMwogI21hcmtfdHJhY2UgMTY4OwpMMTk0JDM6
CiAjaW5zdHIKCWxkYQkkMjUsMygkMzEpCSAjY2xhc3MgZG1vdmUsZG1fY29u
c3RhbnQJICMgMyhTSTMyKQoJICMgc3RhbGwgCTEKICNpbnN0cgoubG9jIDIg
MjYKCXN0bAkkMjUsMzIoJDE1KQkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDI2
LCAzKFNJMzIpLCA8X0R5Q19UZW1wJDEuNDg+dDEyMjgsIDMyKEk2NCksIDAo
STMyKSwgMChJMzIpLCAwKEkzMiksIDAoSTMyKQogI2luc3RyCglsZHEJJDIz
LCQyLjEkMnNwaWxsX3AgKyA4OCgkc3ApCSAjY2xhc3MgZG1vdmUsZG1fcmVz
dG9yZQkgIyA8X2J5dGVjb2RlcyQxLjE+dDQ1NQogI2luc3RyCglsZGEJJDE2
LDI2KCQzMSkJICNjbGFzcyBkbW92ZSxkbV9jb25zdGFudAkgIyAyNihTSTY0
KQoJYnIJJDMxLEwxOTMkMwogI21hcmtfdHJhY2UgMTM0OwpMMTkwJDM6CiAj
aW5zdHIKCW9yCSQxOSwkMzEsJDI0CSAjY2xhc3Mgc291cmNlCSAjIGxpbmUg
MCwgPD50NTc3LCA8PnQxMjEwCiAjaW5zdHIKCW9yCSQzMSwkMzEsJDMxCSAj
Y2xhc3MgZG1vdmUsZG1fcmVnaXN0ZXIJICMgPD50NTMzCiAjaW5zdHIKCXN0
cQkkMjQsJDIuMSQyc3BpbGxfcCArIDE2KCRzcCkJICNjbGFzcyBkbW92ZSxk
bV9zcGlsbAkgIyA8PnQ1NzcKICNpbnN0cgoJYnIJJDMxLEwxOTEkMwogI21h
cmtfdHJhY2UgMTIwOwpMMTg5JDM6CiAjaW5zdHIKCWxkcQkkMjAsJDIuMSQy
c3BpbGxfcCArIDI3Migkc3ApCSAjY2xhc3MgZG1vdmUsZG1fcmVzdG9yZQkg
IyA8PnQxMTk1CglsZGEJJDE5LDIoJDMxKQkgI2NsYXNzIGRtb3ZlLGRtX2Nv
bnN0YW50CSAjIDIoU0k2NCkKICNpbnN0cgoJbGRhaAkkMjMsMzIoJDMxKQkg
I2NsYXNzIGRtb3ZlLGRtX2NvbnN0YW50CSAjIDIwOTcxNTIoSTMyKQogI2lu
c3RyCglsZGFoCSQyNywtMzIoJDMxKQkgI2NsYXNzIGRtb3ZlLGRtX2NvbnN0
YW50CSAjIDQyOTI4NzAxNDQoSTMyKQogI2luc3RyCi5sb2MgMiAyNgoJYWRk
cQkkMjAsNCwkMTgJICNjbGFzcyBzb3VyY2UJICMgbGluZSAyNiwgPD50MTIx
NSwgPD50MTE5NSwgNChTSTMyKQoubG9jIDIgMjYKCWxkbAkkMTUsMCgkMjAp
CSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMjYsIDw+dDEyMTksIDw+dDExOTUs
IDAoSTY0KQogI2luc3RyCi5sb2MgMiAyNgoJc3VicQkkMjEsJDE4LCQxNAkg
I2NsYXNzIHNvdXJjZQkgIyBsaW5lIDI2LCA8PnQxMjE2LCA8PnQxMjEwLCA8
PnQxMjE1CiAjaW5zdHIKLmxvYyAyIDI2CglhZGRsCSQxNCwzLCQxOAkgI2Ns
YXNzIHNvdXJjZQkgIyBsaW5lIDI2LCA8PnQ2MzEsIDw+dDEyMTYsIDMoU0kz
MikKICNpbnN0cgoubG9jIDIgMjYKCWNtb3ZnZQkkMTQsJDE0LCQxOAkgI2Ns
YXNzIHNvdXJjZQkgIyBsaW5lIDI2LCA8PnQ2MzIsIDw+dDEyMTYsIDw+dDEy
MTYsIDw+dDYzMQogI2luc3RyCi5sb2MgMiAyNgoJbGRhCSQxNCwtMSgkMjMp
CSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMjYsIDw+dDgwNSwgMjA5NzE1MihJ
MzIpLCAtMShTSTY0KQogI2luc3RyCi5sb2MgMiAyNgoJc3JhCSQxOCwkMTks
JDE4CSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMjYsIDw+dDEyMTcsIDw+dDYz
MiwgMihTSTY0KQogI2luc3RyCi5sb2MgMiAyNgoJYW5kCSQxNSwkMjcsJDE1
CSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMjYsIDw+dDEyMjAsIDw+dDEyMTks
IDQyOTI4NzAxNDQoSTMyKQogI2luc3RyCi5sb2MgMiAyNgoJYW5kCSQxOCwk
MTQsJDE0CSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMjYsIDw+dDEyMTgsIDw+
dDEyMTcsIDw+dDgwNQoJY3B5cwkkZjMxLCRmMzEsJGYzMQkjIHBhZAogI2lu
c3RyCi5sb2MgMiAyNgoJb3IJJDE0LCQxNSwkMTUJICNjbGFzcyBzb3VyY2UJ
ICMgbGluZSAyNiwgPD50MTIyMSwgPD50MTIxOCwgPD50MTIyMAoubG9jIDIg
MjYKCXN0bAkkMTUsMCgkMjApCSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMjYs
IDw+dDEyMjEsIDw+dDExOTUsIDAoSTY0KSwgMChJMzIpLCAwKEkzMiksIDAo
STMyKSwgMChJMzIpCgkgIyBzdGFsbCAJMQogI2luc3RyCglibmUJJDI0LEwx
OTUkMwkgI2NsYXNzIHNvdXJjZSxyZWpvaW5fY29weQkgIyBsaW5lIDAsIDw+
dDU3NwogI21hcmtfdHJhY2UgMTcyOwogI2luc3RyCglvcgkkMjEsJDMxLCQx
OQkgI2NsYXNzIGRtb3ZlLGRtX3JlZ2lzdGVyCSAjIDw+dDEyMTAKICNpbnN0
cgoJbGRhCSQxOCwxKCQzMSkJICNjbGFzcyBkbW92ZSxkbV9jb25zdGFudAkg
IyAxKFNJMzIpCiAjaW5zdHIKCWJyCSQzMSxMMTkwJDMKICNtYXJrX3RyYWNl
IDE3NTsKTDE5NSQzOgogI2luc3RyCglzdHEJJDI0LCQyLjEkMnNwaWxsX3Ag
KyAxNigkc3ApCSAjY2xhc3MgZG1vdmUsZG1fc3BpbGwJICMgPD50NTc3Cgls
ZGEJJDE4LDEoJDMxKQkgI2NsYXNzIGRtb3ZlLGRtX2NvbnN0YW50CSAjIDEo
U0kzMikKICNpbnN0cgoJb3IJJDMxLCQzMSwkMzEJICNjbGFzcyBkbW92ZSxk
bV9yZWdpc3RlcgkgIyA8PnQ1MzMKICNpbnN0cgoJb3IJJDIxLCQzMSwkMTkJ
ICNjbGFzcyBkbW92ZSxkbV9yZWdpc3RlcgkgIyA8PnQxMjEwCiAjaW5zdHIK
CWJyCSQzMSxMMTkxJDMKCWJpcwkkMzEsJDMxLCQzMQkjIHBhZAogI21hcmtf
dHJhY2UgMTMzOwpMMTg3JDM6CiAjaW5zdHIKCW9yCSQzMSwkMzEsJDI1CSAj
Y2xhc3Mgc291cmNlLHJlam9pbl9jb3B5CSAjIGxpbmUgMCwgPD50NTg3LCAw
KEkzMikKCWxkcQkkMjcsJDIuMSQyc3BpbGxfcCArIDI3Migkc3ApCSAjY2xh
c3MgZG1vdmUsZG1fcmVzdG9yZQkgIyA8PnQxMTk1CiAjaW5zdHIKCWxkcQkk
MTYsJDIuMSQyc3BpbGxfcCArIDI4OCgkc3ApCSAjY2xhc3MgZG1vdmUsZG1f
cmVzdG9yZQkgIyA8PnQxMjAwCglvcgkkMzEsJDMxLCQzMQkgI2NsYXNzIGRt
b3ZlLGRtX3JlZ2lzdGVyCSAjIDw+dDUzMwogI2luc3RyCglzdGwJJDI1LCQy
LjEkMnNwaWxsX3AoJHNwKQkgI2NsYXNzIGRtb3ZlLGRtX3NwaWxsCSAjIDw+
dDU4NwoJb3IJJDEzLCQzMSwkMjEJICNjbGFzcyBkbW92ZSxkbV9yZWdpc3Rl
cgkgIyA8PnQxMjEwCiAjaW5zdHIKCWFkZHEJJDI3LDB4NCwkMTQJICNjbGFz
cyBzb3VyY2UscmVqb2luX2NvcHkJICMgbGluZSAwLCA8PnQ2MDgsIDw+dDEx
OTUsIDB4NChQNjQpCiAjaW5zdHIKCWJyCSQzMSxMMTg4JDMKICNtYXJrX3Ry
YWNlIDg5OwpMMTg2JDM6CiAjaW5zdHIKCWxkYQkkMjMsMigkMzEpCSAjY2xh
c3MgZG1vdmUsZG1fY29uc3RhbnQJICMgMihTSTY0KQoJbGRxCSQxNywkMi4x
JDJzcGlsbF9wICsgMjgwKCRzcCkJICNjbGFzcyBkbW92ZSxkbV9yZXN0b3Jl
CSAjIDw+dDExOTcKICNpbnN0cgoubG9jIDIgMjYKCWFkZHEJJDE0LDQsJDIy
CSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMjYsIDw+dDEyMDMsIDw+dDExOTUs
IDQoU0kzMikKLmxvYyAyIDI2CglsZGwJJDIxLDAoJDE0KQkgI2NsYXNzIHNv
dXJjZQkgIyBsaW5lIDI2LCA8PnQxMjA3LCA8PnQxMTk1LCAwKEk2NCkKICNp
bnN0cgoubG9jIDIgMjYKCXN1YnEJJDAsJDIyLCQyMAkgI2NsYXNzIHNvdXJj
ZQkgIyBsaW5lIDI2LCA8PnQxMjA0LCA8PnQxMjAxLCA8PnQxMjAzCiAjaW5z
dHIKLmxvYyAyIDI2CglhZGRsCSQyMCwzLCQyMgkgI2NsYXNzIHNvdXJjZQkg
IyBsaW5lIDI2LCA8PnQ2MjksIDw+dDEyMDQsIDMoU0kzMikKICNpbnN0cgou
bG9jIDIgMjYKCWNtb3ZnZQkkMjAsJDIwLCQyMgkgI2NsYXNzIHNvdXJjZQkg
IyBsaW5lIDI2LCA8PnQ2MzAsIDw+dDEyMDQsIDw+dDEyMDQsIDw+dDYyOQog
I2luc3RyCglsZGFoCSQyMCwzMigkMzEpCSAjY2xhc3MgZG1vdmUsZG1fY29u
c3RhbnQJICMgMjA5NzE1MihJMzIpCiAjaW5zdHIKLmxvYyAyIDI2CglzcmEJ
JDIyLCQyMywkMjIJICNjbGFzcyBzb3VyY2UJICMgbGluZSAyNiwgPD50MTIw
NSwgPD50NjMwLCAyKFNJNjQpCiAjaW5zdHIKLmxvYyAyIDI2CglsZGEJJDIw
LC0xKCQyMCkJICNjbGFzcyBzb3VyY2UJICMgbGluZSAyNiwgPD50Nzk5LCAy
MDk3MTUyKEkzMiksIC0xKFNJNjQpCiAjaW5zdHIKLmxvYyAyIDI2CglhbmQJ
JDIyLCQyMCwkMjIJICNjbGFzcyBzb3VyY2UJICMgbGluZSAyNiwgPD50MTIw
NiwgPD50MTIwNSwgPD50Nzk5CiAjaW5zdHIKCWxkYWgJJDI3LC0zMigkMzEp
CSAjY2xhc3MgZG1vdmUsZG1fY29uc3RhbnQJICMgNDI5Mjg3MDE0NChJMzIp
CgkgIyBzdGFsbCAJMQogI2luc3RyCi5sb2MgMiAyNgoJYW5kCSQyMSwkMjcs
JDIxCSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMjYsIDw+dDEyMDgsIDw+dDEy
MDcsIDQyOTI4NzAxNDQoSTMyKQoJY3B5cwkkZjMxLCRmMzEsJGYzMQkjIHBh
ZAogI2luc3RyCi5sb2MgMiAyNgoJb3IJJDIyLCQyMSwkMjIJICNjbGFzcyBz
b3VyY2UJICMgbGluZSAyNiwgPD50MTIwOSwgPD50MTIwNiwgPD50MTIwOAou
bG9jIDIgMjYKCXN0bAkkMjIsMCgkMTQpCSAjY2xhc3Mgc291cmNlCSAjIGxp
bmUgMjYsIDw+dDEyMDksIDw+dDExOTUsIDAoSTY0KSwgMChJMzIpLCAwKEkz
MiksIDAoSTMyKSwgMChJMzIpCiAjaW5zdHIKLmxvYyAyIDI2CglsZHEJJDIz
LGludGVycHJldGVyLkxTVkZyZWVMaXN0LjIJICNjbGFzcyBzb3VyY2UJICMg
bGluZSAyNiwgPD50MTIwMiwgPD50NTM2LCBhZGRyKGludGVycHJldGVyLkxT
VkZyZWVMaXN0LlZBUi4yKShQNjQpCgkgIyBzdGFsbCAJMgogI2luc3RyCi5s
b2MgMiAyNgoJc3RxCSQyMywwKCQxNykJICNjbGFzcyBzb3VyY2UJICMgbGlu
ZSAyNiwgPD50MTIwMiwgPD50MTE5NywgMChJNjQpLCAwKEkzMiksIDAoSTMy
KSwgMChJMzIpLCAwKEkzMikKICNpbnN0cgoubG9jIDIgMjYKCXN0cQkkMTcs
aW50ZXJwcmV0ZXIuTFNWRnJlZUxpc3QuMgkgI2NsYXNzIHNvdXJjZQkgIyBs
aW5lIDI2LCA8PnQxMTk3LCA8PnQ1MzYsIGFkZHIoaW50ZXJwcmV0ZXIuTFNW
RnJlZUxpc3QuVkFSLjIpKFA2NCksIDAoSTMyKSwgMChJMzIpLCAwKEkzMiks
IDAoSTMyKQoJICMgc3RhbGwgCTEKICNpbnN0cgoJYmVxCSQyNCxMMTk2JDMJ
ICNjbGFzcyBzb3VyY2UJICMgbGluZSAwLCA8PnQ1NzcKICNtYXJrX3RyYWNl
IDExOTsKICNpbnN0cgoJc3RxCSQyNCwkMi4xJDJzcGlsbF9wICsgMTYoJHNw
KQkgI2NsYXNzIGRtb3ZlLGRtX3NwaWxsCSAjIDw+dDU3NwoJY3B5cwkkZjMx
LCRmMzEsJGYzMQkjIHBhZAogI2luc3RyCglzdGwJJDI1LCQyLjEkMnNwaWxs
X3AoJHNwKQkgI2NsYXNzIGRtb3ZlLGRtX3NwaWxsCSAjIDw+dDU4NwoJbGRh
CSQyNSwzKCQzMSkJICNjbGFzcyBkbW92ZSxkbV9jb25zdGFudAkgIyAzKFNJ
MzIpCiAjaW5zdHIKCWJyCSQzMSxMNjIkMwoJYmlzCSQzMSwkMzEsJDMxCSMg
cGFkCiAjbWFya190cmFjZSAxMzY7CkwxOTYkMzoKICNpbnN0cgoJc3RsCSQy
NSwkMi4xJDJzcGlsbF9wKCRzcCkJICNjbGFzcyBkbW92ZSxkbV9zcGlsbAkg
IyA8PnQ1ODcKCW9yCSQwLCQzMSwkMjQJICNjbGFzcyBzb3VyY2UJICMgbGlu
ZSAwLCA8PnQ1NzcsIDw+dDEyMDEKCSAjIHN0YWxsIAkxCiAjaW5zdHIKCXN0
cQkkMjQsJDIuMSQyc3BpbGxfcCArIDE2KCRzcCkJICNjbGFzcyBkbW92ZSxk
bV9zcGlsbAkgIyA8PnQ1NzcKICNtYXJrX3RyYWNlIDEyOTsKICNpbnN0cgoJ
bGRhCSQyNSwzKCQzMSkJICNjbGFzcyBkbW92ZSxkbV9jb25zdGFudAkgIyAz
KFNJMzIpCiAjaW5zdHIKCWJyCSQzMSxMNjIkMwoJYmlzCSQzMSwkMzEsJDMx
CSMgcGFkCiAjbWFya190cmFjZSA5MDsKTDE4NCQzOgogI21hcmtfY2FsbCBj
YWxsZXJfc2F2ZXMsIHJlZ3MsIGF0eXBlcygpLCBydHlwZXMobjY0KTsKICNp
bnN0cgoJb3IJJDMxLCQzMSwkMzEJICNjbGFzcyBkbW92ZSxkbV9yZWdpc3Rl
cgkgIyA8PnQ1MzMKLmxvYyAyIDI2Cglqc3IJJDI2LERZQ19DQUNIRV9jcmVh
dGUKCWJyCSQyNixGQUtFMjkKRkFLRTI5OglsZGdwCSRncCwwKCQyNikJICNj
bGFzcyBzb3VyY2UJICMgbGluZSAyNiwgcmFkZHIoRFlDX0NBQ0hFX2NyZWF0
ZSkoUDY0KSwgPD50NTMzCiAjaW5zdHIKCXN0cQkkMCwkMi4xJDJzcGlsbF9w
ICsgMjg4KCRzcCkJICNjbGFzcyBkbW92ZSxkbV9zcGlsbAkgIyA8PnQxMjAw
CglvcgkkMCwkMzEsJDE2CSAjY2xhc3MgZG1vdmUsZG1fcmVnaXN0ZXIJICMg
PD50MTIwMAogI2luc3RyCglzdHEJJDAsaW50ZXJwcmV0ZXIuQ2FjaGUuMgkg
I2NsYXNzIHNvdXJjZQkgIyBsaW5lIDAsIDw+dDEyMDAsIDw+dDUzNiwgYWRk
cihpbnRlcnByZXRlci5DYWNoZS5WQVIuMikoUDY0KSwgMChJMzIpLCAwKEkz
MiksIDAoSTMyKSwgMChJMzIpCglsZGEJJDE4LDEoJDMxKQkgI2NsYXNzIGRt
b3ZlLGRtX2NvbnN0YW50CSAjIDEoU0kzMikKICNpbnN0cgoJb3IJJDMxLCQz
MSwkMzEJICNjbGFzcyBkbW92ZSxkbV9yZWdpc3RlcgkgIyA8PnQ1MzMKCWxk
cQkkMTcsJDIuMSQyc3BpbGxfcCArIDI4MCgkc3ApCSAjY2xhc3MgZG1vdmUs
ZG1fcmVzdG9yZQkgIyA8PnQxMTk3CgkgIyBzdGFsbCAJMQogI2luc3RyCgli
cgkkMzEsTDE4NSQzCgliaXMJJDMxLCQzMSwkMzEJIyBwYWQKICNtYXJrX3Ry
YWNlIDk2OwpMMTgyJDM6CiAjaW5zdHIKLmxvYyAyIDI2CglsZHEJJDE3LGlu
dGVycHJldGVyLkxTVkZyZWVMaXN0LjIJICNjbGFzcyBzb3VyY2UJICMgbGlu
ZSAyNiwgPD50MTE5NywgPD50NTM2LCBhZGRyKGludGVycHJldGVyLkxTVkZy
ZWVMaXN0LlZBUi4yKShQNjQpCglvcgkkMzEsJDMxLCQzMQkgI2NsYXNzIGRt
b3ZlLGRtX3JlZ2lzdGVyCSAjIDw+dDUzMwogI2luc3RyCglsZHEJJDE2LGlu
dGVycHJldGVyLkNhY2hlLjIJICNjbGFzcyBzb3VyY2UscmVqb2luX2NvcHkJ
ICMgbGluZSAwLCA8PnQxMjAwLCA8PnQ1MzYsIGFkZHIoaW50ZXJwcmV0ZXIu
Q2FjaGUuVkFSLjIpKFA2NCkKCSAjIHN0YWxsIAkxCiAjaW5zdHIKCXN0cQkk
MTcsJDIuMSQyc3BpbGxfcCArIDI4MCgkc3ApCSAjY2xhc3MgZG1vdmUsZG1f
c3BpbGwJICMgPD50MTE5NwogI2luc3RyCglzdHEJJDE2LCQyLjEkMnNwaWxs
X3AgKyAyODgoJHNwKQkgI2NsYXNzIGRtb3ZlLGRtX3NwaWxsCSAjIDw+dDEy
MDAKICNpbnN0cgoubG9jIDIgMjYKCWxkcQkkMjcsMCgkMTcpCSAjY2xhc3Mg
c291cmNlCSAjIGxpbmUgMjYsIDw+dDExOTgsIDw+dDExOTcsIDAoSTY0KQoJ
ICMgc3RhbGwgCTIKICNpbnN0cgoubG9jIDIgMjYKCXN0cQkkMjcsaW50ZXJw
cmV0ZXIuTFNWRnJlZUxpc3QuMgkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDI2
LCA8PnQxMTk4LCA8PnQ1MzYsIGFkZHIoaW50ZXJwcmV0ZXIuTFNWRnJlZUxp
c3QuVkFSLjIpKFA2NCksIDAoSTMyKSwgMChJMzIpLCAwKEkzMiksIDAoSTMy
KQogI2luc3RyCglicgkkMzEsTDE4MyQzCiAjbWFya190cmFjZSAxNjI7Cl8k
MS5pbnRlcnByZXRlci5UQUcuMy4yLmR5Y19jb3B5LjA6CmludGVycHJldGVy
LmR5bl9zZXR1cF9iZWdpbl8zNl8wOgogI2luc3RyCglzdHEJJDMxLER5Q1JU
X0R1bW15R2xvYmFsCSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMCwgMHgwKFA2
NCksIDw+dDUzNiwgYWRkcihfRHlDUlRfRHVtbXlHbG9iYWwkMS45KShQNjQp
LCAwKEkzMiksIDAoSTMyKSwgMChJMzIpLCAwKEkzMikKLmxvYyAyIDY3Cglh
ZGRsCSQyMiwxLCQyMgkgI2NsYXNzIHNvdXJjZSxyZWpvaW5fY29weQkgIyBs
aW5lIDY3LCA8X3BjJDEuMT50NDU0LCA8X3BjJDEuMT50NDU0LCAxKFNJMzIp
CiAjaW5zdHIKCXN0bAkkMjIsJDIuMSQyc3BpbGxfcCArIDk2KCRzcCkJICNj
bGFzcyBkbW92ZSxkbV9zcGlsbAkgIyA8X3BjJDEuMT50NDU0CglvcgkkMzEs
JDMxLCQzMQkgI2NsYXNzIGRtb3ZlLGRtX3JlZ2lzdGVyCSAjIDw+dDUzMwpp
bnRlcnByZXRlci5keW5fc2V0dXBfZW5kXzM2XzA6CiAjaW5zdHIKCXN0cQkk
MzEsRHlDUlRfRHVtbXlHbG9iYWwJICNjbGFzcyBzb3VyY2UJICMgbGluZSAw
LCAweDAoUDY0KSwgPD50NTM2LCBhZGRyKF9EeUNSVF9EdW1teUdsb2JhbCQx
LjkpKFA2NCksIDAoSTMyKSwgMChJMzIpLCAwKEkzMiksIDAoSTMyKQogI2lu
c3RyCglicgkkMzEsTDE4MSQzCiAjbWFya190cmFjZSAxNTQ7Cl8kMS5pbnRl
cnByZXRlci5UQUcuMy4xLmR5Y19jb3B5LjA6CmludGVycHJldGVyLmR5bl9z
ZXR1cF9iZWdpbl8zNV8wOgogI2luc3RyCglzdHEJJDMxLER5Q1JUX0R1bW15
R2xvYmFsCSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMCwgMHgwKFA2NCksIDw+
dDUzNiwgYWRkcihfRHlDUlRfRHVtbXlHbG9iYWwkMS45KShQNjQpLCAwKEkz
MiksIDAoSTMyKSwgMChJMzIpLCAwKEkzMikKLmxvYyAyIDY3CglhZGRsCSQy
MiwxLCQyMgkgI2NsYXNzIHNvdXJjZSxyZWpvaW5fY29weQkgIyBsaW5lIDY3
LCA8X3BjJDEuMT50NDU0LCA8X3BjJDEuMT50NDU0LCAxKFNJMzIpCiAjaW5z
dHIKCXN0bAkkMjIsJDIuMSQyc3BpbGxfcCArIDk2KCRzcCkJICNjbGFzcyBk
bW92ZSxkbV9zcGlsbAkgIyA8X3BjJDEuMT50NDU0CglvcgkkMzEsJDMxLCQz
MQkgI2NsYXNzIGRtb3ZlLGRtX3JlZ2lzdGVyCSAjIDw+dDUzMwppbnRlcnBy
ZXRlci5keW5fc2V0dXBfZW5kXzM1XzA6CiAjaW5zdHIKCXN0cQkkMzEsRHlD
UlRfRHVtbXlHbG9iYWwJICNjbGFzcyBzb3VyY2UJICMgbGluZSAwLCAweDAo
UDY0KSwgPD50NTM2LCBhZGRyKF9EeUNSVF9EdW1teUdsb2JhbCQxLjkpKFA2
NCksIDAoSTMyKSwgMChJMzIpLCAwKEkzMiksIDAoSTMyKQogI2luc3RyCgli
cgkkMzEsTDE4MSQzCiAjbWFya190cmFjZSAxNTM7Cl8kMS5pbnRlcnByZXRl
ci5UQUcuMy4wLmR5Y19jb3B5LjA6CmludGVycHJldGVyLmR5bl9zZXR1cF9i
ZWdpbl8zNF8wOgogI2luc3RyCglzdHEJJDMxLER5Q1JUX0R1bW15R2xvYmFs
CSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMCwgMHgwKFA2NCksIDw+dDUzNiwg
YWRkcihfRHlDUlRfRHVtbXlHbG9iYWwkMS45KShQNjQpLCAwKEkzMiksIDAo
STMyKSwgMChJMzIpLCAwKEkzMikKLmxvYyAyIDY3CglhZGRsCSQyMiwxLCQy
MgkgI2NsYXNzIHNvdXJjZSxyZWpvaW5fY29weQkgIyBsaW5lIDY3LCA8X3Bj
JDEuMT50NDU0LCA8X3BjJDEuMT50NDU0LCAxKFNJMzIpCiAjaW5zdHIKCXN0
bAkkMjIsJDIuMSQyc3BpbGxfcCArIDk2KCRzcCkJICNjbGFzcyBkbW92ZSxk
bV9zcGlsbAkgIyA8X3BjJDEuMT50NDU0CglvcgkkMzEsJDMxLCQzMQkgI2Ns
YXNzIGRtb3ZlLGRtX3JlZ2lzdGVyCSAjIDw+dDUzMwppbnRlcnByZXRlci5k
eW5fc2V0dXBfZW5kXzM0XzA6CiAjaW5zdHIKCXN0cQkkMzEsRHlDUlRfRHVt
bXlHbG9iYWwJICNjbGFzcyBzb3VyY2UJICMgbGluZSAwLCAweDAoUDY0KSwg
PD50NTM2LCBhZGRyKF9EeUNSVF9EdW1teUdsb2JhbCQxLjkpKFA2NCksIDAo
STMyKSwgMChJMzIpLCAwKEkzMiksIDAoSTMyKQogI2luc3RyCglicgkkMzEs
TDE4MSQzCiAjbWFya190cmFjZSAyMDA7CkwxNzkkMzoKaW50ZXJwcmV0ZXIu
ZHluX3NldHVwX2JlZ2luXzMwXzA6CiAjaW5zdHIKCXN0cQkkMzEsRHlDUlRf
RHVtbXlHbG9iYWwJICNjbGFzcyBzb3VyY2UJICMgbGluZSAwLCAweDAoUDY0
KSwgPD50NTM2LCBhZGRyKF9EeUNSVF9EdW1teUdsb2JhbCQxLjkpKFA2NCks
IDAoSTMyKSwgMChJMzIpLCAwKEkzMiksIDAoSTMyKQoubG9jIDIgNjUKCXM0
YWRkbAkkMTgsJDMxLCQxNAkgI2NsYXNzIHNvdXJjZSxyZWpvaW5fY29weQkg
IyBsaW5lIDY1LCA8PnQ1NDEsIDxfcmQkMS4yPnQ1MjgsIDAoSTY0KQogI2lu
c3RyCi5sb2MgMiA2NwoJYWRkbAkkMjIsMSwkMjIJICNjbGFzcyBzb3VyY2Us
cmVqb2luX2NvcHkJICMgbGluZSA2NywgPF9wYyQxLjE+dDQ1NCwgPF9wYyQx
LjE+dDQ1NCwgMShTSTMyKQoJc3RsCSQyMiwkMi4xJDJzcGlsbF9wICsgOTYo
JHNwKQkgI2NsYXNzIGRtb3ZlLGRtX3NwaWxsCSAjIDxfcGMkMS4xPnQ0NTQK
ICNpbnN0cgoJc3RxCSQzMSxEeUNSVF9EdW1teUdsb2JhbAkgI2NsYXNzIHNv
dXJjZQkgIyBsaW5lIDAsIDB4MChQNjQpLCA8PnQ1MzYsIGFkZHIoX0R5Q1JU
X0R1bW15R2xvYmFsJDEuOSkoUDY0KSwgMChJMzIpLCAwKEkzMiksIDAoSTMy
KSwgMChJMzIpCglvcgkkMzEsJDMxLCQzMQkgI2NsYXNzIGRtb3ZlLGRtX3Jl
Z2lzdGVyCSAjIDw+dDUzMwppbnRlcnByZXRlci5keW5fc2V0dXBfZW5kXzMw
XzA6CiAjaW5zdHIKCWJyCSQzMSxMMTgwJDMKCWJpcwkkMzEsJDMxLCQzMQkj
IHBhZAogI21hcmtfdHJhY2UgMTYxOwpfJDEuaW50ZXJwcmV0ZXIuVEFHLjIu
Mi5keWNfY29weS4wOgppbnRlcnByZXRlci5keW5fc2V0dXBfYmVnaW5fMjhf
MDoKICNpbnN0cgoJbGRhCSQyMSwxKCQzMSkJICNjbGFzcyBkbW92ZSxkbV9j
b25zdGFudAkgIyAxKFNJNjQpCglzdHEJJDMxLER5Q1JUX0R1bW15R2xvYmFs
CSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMCwgMHgwKFA2NCksIDw+dDUzNiwg
YWRkcihfRHlDUlRfRHVtbXlHbG9iYWwkMS45KShQNjQpLCAwKEkzMiksIDAo
STMyKSwgMChJMzIpLCAwKEkzMikKICNpbnN0cgoJbGRhCSQyNywzMSgkMzEp
CSAjY2xhc3MgZG1vdmUsZG1fY29uc3RhbnQJICMgMzEoU0k2NCkKCWNweXMJ
JGYzMSwkZjMxLCRmMzEJIyBwYWQKICNpbnN0cgoubG9jIDIgNjYKCWNtcGx0
CSQxOCwkMjEsJDIxCSAjY2xhc3Mgc291cmNlLHJlam9pbl9jb3B5CSAjIGxp
bmUgNjYsIDw+dDM3OSwgPF9yZCQxLjI+dDUyOCwgMShTSTY0KQoJc3RxCSQz
MSxEeUNSVF9EdW1teUdsb2JhbAkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDAs
IDB4MChQNjQpLCA8PnQ1MzYsIGFkZHIoX0R5Q1JUX0R1bW15R2xvYmFsJDEu
OSkoUDY0KSwgMChJMzIpLCAwKEkzMiksIDAoSTMyKSwgMChJMzIpCiAjaW5z
dHIKLmxvYyAyIDY2CgljbXBsdAkkMjcsJDE4LCQyNwkgI2NsYXNzIHNvdXJj
ZSxyZWpvaW5fY29weQkgIyBsaW5lIDY2LCA8PnQzODAsIDMxKFNJNjQpLCA8
X3JkJDEuMj50NTI4CiAjaW5zdHIKLmxvYyAyIDY2CglzOGFkZGwJJDE4LCQz
MSwkMTEJICNjbGFzcyBzb3VyY2UsY3NwZWMscmVqb2luX2NvcHkJICMgbGlu
ZSA2NiwgPD50OTI3LCA8X3JkJDEuMj50NTI4LCAwKEk2NCkKICNpbnN0cgou
bG9jIDIgNjYKCW9yCSQyMSwkMjcsJDEyCSAjY2xhc3Mgc291cmNlLHJlam9p
bl9jb3B5CSAjIGxpbmUgNjYsIDw+dDU3MiwgPD50Mzc5LCA8PnQzODAKICNp
bnN0cgoubG9jIDIgNjUKCXM0YWRkbAkkMTgsJDMxLCQxNAkgI2NsYXNzIHNv
dXJjZSxjc3BlYyxyZWpvaW5fY29weQkgIyBsaW5lIDY1LCA8PnQ1NDEsIDxf
cmQkMS4yPnQ1MjgsIDAoSTY0KQogI2luc3RyCglvcgkkMzEsJDMxLCQzMQkg
I2NsYXNzIGRtb3ZlLGRtX3JlZ2lzdGVyCSAjIDw+dDUzMwoJY3B5cwkkZjMx
LCRmMzEsJGYzMQkjIHBhZAppbnRlcnByZXRlci5keW5fc2V0dXBfZW5kXzI4
XzA6CiAjaW5zdHIKCWJyCSQzMSxMMTc4JDMKCWJpcwkkMzEsJDMxLCQzMQkj
IHBhZAogI21hcmtfdHJhY2UgMTYwOwpfJDEuaW50ZXJwcmV0ZXIuVEFHLjIu
MS5keWNfY29weS4wOgppbnRlcnByZXRlci5keW5fc2V0dXBfYmVnaW5fMjdf
MDoKICNpbnN0cgoJbGRhCSQyMSwxKCQzMSkJICNjbGFzcyBkbW92ZSxkbV9j
b25zdGFudAkgIyAxKFNJNjQpCglzdHEJJDMxLER5Q1JUX0R1bW15R2xvYmFs
CSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMCwgMHgwKFA2NCksIDw+dDUzNiwg
YWRkcihfRHlDUlRfRHVtbXlHbG9iYWwkMS45KShQNjQpLCAwKEkzMiksIDAo
STMyKSwgMChJMzIpLCAwKEkzMikKICNpbnN0cgoJbGRhCSQyNywzMSgkMzEp
CSAjY2xhc3MgZG1vdmUsZG1fY29uc3RhbnQJICMgMzEoU0k2NCkKCWNweXMJ
JGYzMSwkZjMxLCRmMzEJIyBwYWQKICNpbnN0cgoubG9jIDIgNjYKCWNtcGx0
CSQxOCwkMjEsJDIxCSAjY2xhc3Mgc291cmNlLHJlam9pbl9jb3B5CSAjIGxp
bmUgNjYsIDw+dDM3OSwgPF9yZCQxLjI+dDUyOCwgMShTSTY0KQoJc3RxCSQz
MSxEeUNSVF9EdW1teUdsb2JhbAkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDAs
IDB4MChQNjQpLCA8PnQ1MzYsIGFkZHIoX0R5Q1JUX0R1bW15R2xvYmFsJDEu
OSkoUDY0KSwgMChJMzIpLCAwKEkzMiksIDAoSTMyKSwgMChJMzIpCiAjaW5z
dHIKLmxvYyAyIDY2CgljbXBsdAkkMjcsJDE4LCQyNwkgI2NsYXNzIHNvdXJj
ZSxyZWpvaW5fY29weQkgIyBsaW5lIDY2LCA8PnQzODAsIDMxKFNJNjQpLCA8
X3JkJDEuMj50NTI4CiAjaW5zdHIKLmxvYyAyIDY2CglzOGFkZGwJJDE4LCQz
MSwkMTEJICNjbGFzcyBzb3VyY2UsY3NwZWMscmVqb2luX2NvcHkJICMgbGlu
ZSA2NiwgPD50OTI3LCA8X3JkJDEuMj50NTI4LCAwKEk2NCkKICNpbnN0cgou
bG9jIDIgNjYKCW9yCSQyMSwkMjcsJDEyCSAjY2xhc3Mgc291cmNlLHJlam9p
bl9jb3B5CSAjIGxpbmUgNjYsIDw+dDU3MiwgPD50Mzc5LCA8PnQzODAKICNp
bnN0cgoubG9jIDIgNjUKCXM0YWRkbAkkMTgsJDMxLCQxNAkgI2NsYXNzIHNv
dXJjZSxjc3BlYyxyZWpvaW5fY29weQkgIyBsaW5lIDY1LCA8PnQ1NDEsIDxf
cmQkMS4yPnQ1MjgsIDAoSTY0KQogI2luc3RyCglvcgkkMzEsJDMxLCQzMQkg
I2NsYXNzIGRtb3ZlLGRtX3JlZ2lzdGVyCSAjIDw+dDUzMwoJY3B5cwkkZjMx
LCRmMzEsJGYzMQkjIHBhZAppbnRlcnByZXRlci5keW5fc2V0dXBfZW5kXzI3
XzA6CiAjaW5zdHIKCWJyCSQzMSxMMTc4JDMKCWJpcwkkMzEsJDMxLCQzMQkj
IHBhZAogI21hcmtfdHJhY2UgMTUxOwpfJDEuaW50ZXJwcmV0ZXIuVEFHLjIu
MC5keWNfY29weS4wOgppbnRlcnByZXRlci5keW5fc2V0dXBfYmVnaW5fMjZf
MDoKICNpbnN0cgoJbGRhCSQyMSwxKCQzMSkJICNjbGFzcyBkbW92ZSxkbV9j
b25zdGFudAkgIyAxKFNJNjQpCglzdHEJJDMxLER5Q1JUX0R1bW15R2xvYmFs
CSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMCwgMHgwKFA2NCksIDw+dDUzNiwg
YWRkcihfRHlDUlRfRHVtbXlHbG9iYWwkMS45KShQNjQpLCAwKEkzMiksIDAo
STMyKSwgMChJMzIpLCAwKEkzMikKICNpbnN0cgoJbGRhCSQyNywzMSgkMzEp
CSAjY2xhc3MgZG1vdmUsZG1fY29uc3RhbnQJICMgMzEoU0k2NCkKCWNweXMJ
JGYzMSwkZjMxLCRmMzEJIyBwYWQKICNpbnN0cgoubG9jIDIgNjYKCWNtcGx0
CSQxOCwkMjEsJDIxCSAjY2xhc3Mgc291cmNlLHJlam9pbl9jb3B5CSAjIGxp
bmUgNjYsIDw+dDM3OSwgPF9yZCQxLjI+dDUyOCwgMShTSTY0KQoJc3RxCSQz
MSxEeUNSVF9EdW1teUdsb2JhbAkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDAs
IDB4MChQNjQpLCA8PnQ1MzYsIGFkZHIoX0R5Q1JUX0R1bW15R2xvYmFsJDEu
OSkoUDY0KSwgMChJMzIpLCAwKEkzMiksIDAoSTMyKSwgMChJMzIpCiAjaW5z
dHIKLmxvYyAyIDY2CgljbXBsdAkkMjcsJDE4LCQyNwkgI2NsYXNzIHNvdXJj
ZSxyZWpvaW5fY29weQkgIyBsaW5lIDY2LCA8PnQzODAsIDMxKFNJNjQpLCA8
X3JkJDEuMj50NTI4CiAjaW5zdHIKLmxvYyAyIDY2CglzOGFkZGwJJDE4LCQz
MSwkMTEJICNjbGFzcyBzb3VyY2UsY3NwZWMscmVqb2luX2NvcHkJICMgbGlu
ZSA2NiwgPD50OTI3LCA8X3JkJDEuMj50NTI4LCAwKEk2NCkKICNpbnN0cgou
bG9jIDIgNjYKCW9yCSQyMSwkMjcsJDEyCSAjY2xhc3Mgc291cmNlLHJlam9p
bl9jb3B5CSAjIGxpbmUgNjYsIDw+dDU3MiwgPD50Mzc5LCA8PnQzODAKICNp
bnN0cgoubG9jIDIgNjUKCXM0YWRkbAkkMTgsJDMxLCQxNAkgI2NsYXNzIHNv
dXJjZSxjc3BlYyxyZWpvaW5fY29weQkgIyBsaW5lIDY1LCA8PnQ1NDEsIDxf
cmQkMS4yPnQ1MjgsIDAoSTY0KQogI2luc3RyCglvcgkkMzEsJDMxLCQzMQkg
I2NsYXNzIGRtb3ZlLGRtX3JlZ2lzdGVyCSAjIDw+dDUzMwoJY3B5cwkkZjMx
LCRmMzEsJGYzMQkjIHBhZAppbnRlcnByZXRlci5keW5fc2V0dXBfZW5kXzI2
XzA6CiAjaW5zdHIKCWJyCSQzMSxMMTc4JDMKCWJpcwkkMzEsJDMxLCQzMQkj
IHBhZAogI21hcmtfdHJhY2UgMTk3OwpMMTc2JDM6CmludGVycHJldGVyLmR5
bl9zZXR1cF9iZWdpbl8yMl8wOgogI2luc3RyCglsZGEJJDIxLDEoJDMxKQkg
I2NsYXNzIGRtb3ZlLGRtX2NvbnN0YW50CSAjIDEoU0k2NCkKCXN0cQkkMzEs
RHlDUlRfRHVtbXlHbG9iYWwJICNjbGFzcyBzb3VyY2UJICMgbGluZSAwLCAw
eDAoUDY0KSwgPD50NTM2LCBhZGRyKF9EeUNSVF9EdW1teUdsb2JhbCQxLjkp
KFA2NCksIDAoSTMyKSwgMChJMzIpLCAwKEkzMiksIDAoSTMyKQogI2luc3Ry
CglsZGEJJDI3LDMxKCQzMSkJICNjbGFzcyBkbW92ZSxkbV9jb25zdGFudAkg
IyAzMShTSTY0KQoJY3B5cwkkZjMxLCRmMzEsJGYzMQkjIHBhZAogI2luc3Ry
Ci5sb2MgMiA2NgoJY21wbHQJJDE4LCQyMSwkMjEJICNjbGFzcyBzb3VyY2Us
cmVqb2luX2NvcHkJICMgbGluZSA2NiwgPD50Mzc5LCA8X3JkJDEuMj50NTI4
LCAxKFNJNjQpCglzdHEJJDMxLER5Q1JUX0R1bW15R2xvYmFsCSAjY2xhc3Mg
c291cmNlCSAjIGxpbmUgMCwgMHgwKFA2NCksIDw+dDUzNiwgYWRkcihfRHlD
UlRfRHVtbXlHbG9iYWwkMS45KShQNjQpLCAwKEkzMiksIDAoSTMyKSwgMChJ
MzIpLCAwKEkzMikKICNpbnN0cgoubG9jIDIgNjYKCWNtcGx0CSQyNywkMTgs
JDI3CSAjY2xhc3Mgc291cmNlLHJlam9pbl9jb3B5CSAjIGxpbmUgNjYsIDw+
dDM4MCwgMzEoU0k2NCksIDxfcmQkMS4yPnQ1MjgKICNpbnN0cgoubG9jIDIg
NTkKCXM0YWRkbAkkMTksJDMxLCQxNgkgI2NsYXNzIHNvdXJjZSxyZWpvaW5f
Y29weQkgIyBsaW5lIDU5LCA8X211bHQyJDEuMj50NTQyLCA8X3J0JDEuMj50
NTI5LCAwKEk2NCkKICNpbnN0cgoubG9jIDIgNjYKCW9yCSQyMSwkMjcsJDEy
CSAjY2xhc3Mgc291cmNlLHJlam9pbl9jb3B5CSAjIGxpbmUgNjYsIDw+dDU3
MiwgPD50Mzc5LCA8PnQzODAKICNpbnN0cgoubG9jIDIgNjYKCXM4YWRkbAkk
MTgsJDMxLCQxMQkgI2NsYXNzIHNvdXJjZSxjc3BlYyxyZWpvaW5fY29weQkg
IyBsaW5lIDY2LCA8PnQ5MjcsIDxfcmQkMS4yPnQ1MjgsIDAoSTY0KQogI2lu
c3RyCi5sb2MgMiA2NQoJczRhZGRsCSQxOCwkMzEsJDE0CSAjY2xhc3Mgc291
cmNlLGNzcGVjLHJlam9pbl9jb3B5CSAjIGxpbmUgNjUsIDw+dDU0MSwgPF9y
ZCQxLjI+dDUyOCwgMChJNjQpCiAjaW5zdHIKCW9yCSQzMSwkMzEsJDMxCSAj
Y2xhc3MgZG1vdmUsZG1fcmVnaXN0ZXIJICMgPD50NTMzCmludGVycHJldGVy
LmR5bl9zZXR1cF9lbmRfMjJfMDoKICNpbnN0cgoJYnIJJDMxLEwxNzckMwoJ
YmlzCSQzMSwkMzEsJDMxCSMgcGFkCiAjbWFya190cmFjZSAxNDA7Cl8kMS5p
bnRlcnByZXRlci5UQUcuMS4yLmR5Y19jb3B5LjA6CmludGVycHJldGVyLmR5
bl9zZXR1cF9iZWdpbl8yMF8wOgogI2luc3RyCglsZGEJJDIxLDEoJDMxKQkg
I2NsYXNzIGRtb3ZlLGRtX2NvbnN0YW50CSAjIDEoU0k2NCkKCXN0cQkkMzEs
RHlDUlRfRHVtbXlHbG9iYWwJICNjbGFzcyBzb3VyY2UJICMgbGluZSAwLCAw
eDAoUDY0KSwgPD50NTM2LCBhZGRyKF9EeUNSVF9EdW1teUdsb2JhbCQxLjkp
KFA2NCksIDAoSTMyKSwgMChJMzIpLCAwKEkzMiksIDAoSTMyKQogI2luc3Ry
CglsZGEJJDI3LDMxKCQzMSkJICNjbGFzcyBkbW92ZSxkbV9jb25zdGFudAkg
IyAzMShTSTY0KQoJY3B5cwkkZjMxLCRmMzEsJGYzMQkjIHBhZAogI2luc3Ry
Ci5sb2MgMiA2MAoJY21wbHQJJDE5LCQyMSwkMjEJICNjbGFzcyBzb3VyY2Us
cmVqb2luX2NvcHkJICMgbGluZSA2MCwgPD50MzYxLCA8X3J0JDEuMj50NTI5
LCAxKFNJNjQpCglzdHEJJDMxLER5Q1JUX0R1bW15R2xvYmFsCSAjY2xhc3Mg
c291cmNlCSAjIGxpbmUgMCwgMHgwKFA2NCksIDw+dDUzNiwgYWRkcihfRHlD
UlRfRHVtbXlHbG9iYWwkMS45KShQNjQpLCAwKEkzMiksIDAoSTMyKSwgMChJ
MzIpLCAwKEkzMikKICNpbnN0cgoubG9jIDIgNjAKCWNtcGx0CSQyNywkMTks
JDI3CSAjY2xhc3Mgc291cmNlLHJlam9pbl9jb3B5CSAjIGxpbmUgNjAsIDw+
dDM2MiwgMzEoU0k2NCksIDxfcnQkMS4yPnQ1MjkKICNpbnN0cgoJbGRhCSQy
NSwxKCQzMSkJICNjbGFzcyBkbW92ZSxkbV9jb25zdGFudAkgIyAxKFNJNjQp
CiAjaW5zdHIKLmxvYyAyIDYwCglvcgkkMjEsJDI3LCQxNwkgI2NsYXNzIHNv
dXJjZSxyZWpvaW5fY29weQkgIyBsaW5lIDYwLCA8PnQ1NzEsIDw+dDM2MSwg
PD50MzYyCiAjaW5zdHIKLmxvYyAyIDY2CgljbXBsdAkkMTgsJDI1LCQyMQkg
I2NsYXNzIHNvdXJjZSxjc3BlYyxyZWpvaW5fY29weQkgIyBsaW5lIDY2LCA8
PnQzNzksIDxfcmQkMS4yPnQ1MjgsIDEoU0k2NCkKICNpbnN0cgoJbGRhCSQy
NywzMSgkMzEpCSAjY2xhc3MgZG1vdmUsZG1fY29uc3RhbnQJICMgMzEoU0k2
NCkKICNpbnN0cgoubG9jIDIgNjAKCXM4YWRkbAkkMTksJDMxLCQxMwkgI2Ns
YXNzIHNvdXJjZSxjc3BlYyxyZWpvaW5fY29weQkgIyBsaW5lIDYwLCA8PnQ5
MzIsIDxfcnQkMS4yPnQ1MjksIDAoSTY0KQogI2luc3RyCi5sb2MgMiA2NgoJ
Y21wbHQJJDI3LCQxOCwkMjcJICNjbGFzcyBzb3VyY2UsY3NwZWMscmVqb2lu
X2NvcHkJICMgbGluZSA2NiwgPD50MzgwLCAzMShTSTY0KSwgPF9yZCQxLjI+
dDUyOAogI2luc3RyCi5sb2MgMiA1OQoJczRhZGRsCSQxOSwkMzEsJDE2CSAj
Y2xhc3Mgc291cmNlLGNzcGVjLHJlam9pbl9jb3B5CSAjIGxpbmUgNTksIDxf
bXVsdDIkMS4yPnQ1NDIsIDxfcnQkMS4yPnQ1MjksIDAoSTY0KQogI2luc3Ry
Ci5sb2MgMiA2NgoJb3IJJDIxLCQyNywkMTIJICNjbGFzcyBzb3VyY2UsY3Nw
ZWMscmVqb2luX2NvcHkJICMgbGluZSA2NiwgPD50NTcyLCA8PnQzNzksIDw+
dDM4MAogI2luc3RyCi5sb2MgMiA2NgoJczhhZGRsCSQxOCwkMzEsJDExCSAj
Y2xhc3Mgc291cmNlLGNzcGVjLHJlam9pbl9jb3B5CSAjIGxpbmUgNjYsIDw+
dDkyNywgPF9yZCQxLjI+dDUyOCwgMChJNjQpCmludGVycHJldGVyLmR5bl9z
ZXR1cF9lbmRfMjBfMDoKICNpbnN0cgoubG9jIDIgNjUKCXM0YWRkbAkkMTgs
JDMxLCQxNAkgI2NsYXNzIHNvdXJjZSxjc3BlYwkgIyBsaW5lIDY1LCA8PnQ1
NDEsIDxfcmQkMS4yPnQ1MjgsIDAoSTY0KQoJYnIJJDMxLEwxNzUkMwogI21h
cmtfdHJhY2UgMTMyOwpfJDEuaW50ZXJwcmV0ZXIuVEFHLjEuMS5keWNfY29w
eS4wOgppbnRlcnByZXRlci5keW5fc2V0dXBfYmVnaW5fMTlfMDoKICNpbnN0
cgoJbGRhCSQyMSwxKCQzMSkJICNjbGFzcyBkbW92ZSxkbV9jb25zdGFudAkg
IyAxKFNJNjQpCglzdHEJJDMxLER5Q1JUX0R1bW15R2xvYmFsCSAjY2xhc3Mg
c291cmNlCSAjIGxpbmUgMCwgMHgwKFA2NCksIDw+dDUzNiwgYWRkcihfRHlD
UlRfRHVtbXlHbG9iYWwkMS45KShQNjQpLCAwKEkzMiksIDAoSTMyKSwgMChJ
MzIpLCAwKEkzMikKICNpbnN0cgoJbGRhCSQyNywzMSgkMzEpCSAjY2xhc3Mg
ZG1vdmUsZG1fY29uc3RhbnQJICMgMzEoU0k2NCkKCWNweXMJJGYzMSwkZjMx
LCRmMzEJIyBwYWQKICNpbnN0cgoubG9jIDIgNjAKCWNtcGx0CSQxOSwkMjEs
JDIxCSAjY2xhc3Mgc291cmNlLHJlam9pbl9jb3B5CSAjIGxpbmUgNjAsIDw+
dDM2MSwgPF9ydCQxLjI+dDUyOSwgMShTSTY0KQoJc3RxCSQzMSxEeUNSVF9E
dW1teUdsb2JhbAkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDAsIDB4MChQNjQp
LCA8PnQ1MzYsIGFkZHIoX0R5Q1JUX0R1bW15R2xvYmFsJDEuOSkoUDY0KSwg
MChJMzIpLCAwKEkzMiksIDAoSTMyKSwgMChJMzIpCiAjaW5zdHIKLmxvYyAy
IDYwCgljbXBsdAkkMjcsJDE5LCQyNwkgI2NsYXNzIHNvdXJjZSxyZWpvaW5f
Y29weQkgIyBsaW5lIDYwLCA8PnQzNjIsIDMxKFNJNjQpLCA8X3J0JDEuMj50
NTI5CiAjaW5zdHIKCWxkYQkkMjUsMSgkMzEpCSAjY2xhc3MgZG1vdmUsZG1f
Y29uc3RhbnQJICMgMShTSTY0KQogI2luc3RyCi5sb2MgMiA2MAoJb3IJJDIx
LCQyNywkMTcJICNjbGFzcyBzb3VyY2UscmVqb2luX2NvcHkJICMgbGluZSA2
MCwgPD50NTcxLCA8PnQzNjEsIDw+dDM2MgogI2luc3RyCi5sb2MgMiA2NgoJ
Y21wbHQJJDE4LCQyNSwkMjEJICNjbGFzcyBzb3VyY2UsY3NwZWMscmVqb2lu
X2NvcHkJICMgbGluZSA2NiwgPD50Mzc5LCA8X3JkJDEuMj50NTI4LCAxKFNJ
NjQpCiAjaW5zdHIKCWxkYQkkMjcsMzEoJDMxKQkgI2NsYXNzIGRtb3ZlLGRt
X2NvbnN0YW50CSAjIDMxKFNJNjQpCiAjaW5zdHIKLmxvYyAyIDYwCglzOGFk
ZGwJJDE5LCQzMSwkMTMJICNjbGFzcyBzb3VyY2UsY3NwZWMscmVqb2luX2Nv
cHkJICMgbGluZSA2MCwgPD50OTMyLCA8X3J0JDEuMj50NTI5LCAwKEk2NCkK
ICNpbnN0cgoubG9jIDIgNjYKCWNtcGx0CSQyNywkMTgsJDI3CSAjY2xhc3Mg
c291cmNlLGNzcGVjLHJlam9pbl9jb3B5CSAjIGxpbmUgNjYsIDw+dDM4MCwg
MzEoU0k2NCksIDxfcmQkMS4yPnQ1MjgKICNpbnN0cgoubG9jIDIgNTkKCXM0
YWRkbAkkMTksJDMxLCQxNgkgI2NsYXNzIHNvdXJjZSxjc3BlYyxyZWpvaW5f
Y29weQkgIyBsaW5lIDU5LCA8X211bHQyJDEuMj50NTQyLCA8X3J0JDEuMj50
NTI5LCAwKEk2NCkKICNpbnN0cgoubG9jIDIgNjYKCW9yCSQyMSwkMjcsJDEy
CSAjY2xhc3Mgc291cmNlLGNzcGVjLHJlam9pbl9jb3B5CSAjIGxpbmUgNjYs
IDw+dDU3MiwgPD50Mzc5LCA8PnQzODAKICNpbnN0cgoubG9jIDIgNjYKCXM4
YWRkbAkkMTgsJDMxLCQxMQkgI2NsYXNzIHNvdXJjZSxjc3BlYyxyZWpvaW5f
Y29weQkgIyBsaW5lIDY2LCA8PnQ5MjcsIDxfcmQkMS4yPnQ1MjgsIDAoSTY0
KQppbnRlcnByZXRlci5keW5fc2V0dXBfZW5kXzE5XzA6CiAjaW5zdHIKLmxv
YyAyIDY1CglzNGFkZGwJJDE4LCQzMSwkMTQJICNjbGFzcyBzb3VyY2UsY3Nw
ZWMJICMgbGluZSA2NSwgPD50NTQxLCA8X3JkJDEuMj50NTI4LCAwKEk2NCkK
CWJyCSQzMSxMMTc1JDMKICNtYXJrX3RyYWNlIDE0MTsKXyQxLmludGVycHJl
dGVyLlRBRy4xLjAuZHljX2NvcHkuMDoKaW50ZXJwcmV0ZXIuZHluX3NldHVw
X2JlZ2luXzE4XzA6CiAjaW5zdHIKCWxkYQkkMjEsMSgkMzEpCSAjY2xhc3Mg
ZG1vdmUsZG1fY29uc3RhbnQJICMgMShTSTY0KQoJc3RxCSQzMSxEeUNSVF9E
dW1teUdsb2JhbAkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDAsIDB4MChQNjQp
LCA8PnQ1MzYsIGFkZHIoX0R5Q1JUX0R1bW15R2xvYmFsJDEuOSkoUDY0KSwg
MChJMzIpLCAwKEkzMiksIDAoSTMyKSwgMChJMzIpCiAjaW5zdHIKCWxkYQkk
MjcsMzEoJDMxKQkgI2NsYXNzIGRtb3ZlLGRtX2NvbnN0YW50CSAjIDMxKFNJ
NjQpCgljcHlzCSRmMzEsJGYzMSwkZjMxCSMgcGFkCiAjaW5zdHIKLmxvYyAy
IDYwCgljbXBsdAkkMTksJDIxLCQyMQkgI2NsYXNzIHNvdXJjZSxyZWpvaW5f
Y29weQkgIyBsaW5lIDYwLCA8PnQzNjEsIDxfcnQkMS4yPnQ1MjksIDEoU0k2
NCkKCXN0cQkkMzEsRHlDUlRfRHVtbXlHbG9iYWwJICNjbGFzcyBzb3VyY2UJ
ICMgbGluZSAwLCAweDAoUDY0KSwgPD50NTM2LCBhZGRyKF9EeUNSVF9EdW1t
eUdsb2JhbCQxLjkpKFA2NCksIDAoSTMyKSwgMChJMzIpLCAwKEkzMiksIDAo
STMyKQogI2luc3RyCi5sb2MgMiA2MAoJY21wbHQJJDI3LCQxOSwkMjcJICNj
bGFzcyBzb3VyY2UscmVqb2luX2NvcHkJICMgbGluZSA2MCwgPD50MzYyLCAz
MShTSTY0KSwgPF9ydCQxLjI+dDUyOQogI2luc3RyCglsZGEJJDI1LDEoJDMx
KQkgI2NsYXNzIGRtb3ZlLGRtX2NvbnN0YW50CSAjIDEoU0k2NCkKICNpbnN0
cgoubG9jIDIgNjAKCW9yCSQyMSwkMjcsJDE3CSAjY2xhc3Mgc291cmNlLHJl
am9pbl9jb3B5CSAjIGxpbmUgNjAsIDw+dDU3MSwgPD50MzYxLCA8PnQzNjIK
ICNpbnN0cgoubG9jIDIgNjYKCWNtcGx0CSQxOCwkMjUsJDIxCSAjY2xhc3Mg
c291cmNlLGNzcGVjLHJlam9pbl9jb3B5CSAjIGxpbmUgNjYsIDw+dDM3OSwg
PF9yZCQxLjI+dDUyOCwgMShTSTY0KQogI2luc3RyCglsZGEJJDI3LDMxKCQz
MSkJICNjbGFzcyBkbW92ZSxkbV9jb25zdGFudAkgIyAzMShTSTY0KQogI2lu
c3RyCi5sb2MgMiA2MAoJczhhZGRsCSQxOSwkMzEsJDEzCSAjY2xhc3Mgc291
cmNlLGNzcGVjLHJlam9pbl9jb3B5CSAjIGxpbmUgNjAsIDw+dDkzMiwgPF9y
dCQxLjI+dDUyOSwgMChJNjQpCiAjaW5zdHIKLmxvYyAyIDY2CgljbXBsdAkk
MjcsJDE4LCQyNwkgI2NsYXNzIHNvdXJjZSxjc3BlYyxyZWpvaW5fY29weQkg
IyBsaW5lIDY2LCA8PnQzODAsIDMxKFNJNjQpLCA8X3JkJDEuMj50NTI4CiAj
aW5zdHIKLmxvYyAyIDU5CglzNGFkZGwJJDE5LCQzMSwkMTYJICNjbGFzcyBz
b3VyY2UsY3NwZWMscmVqb2luX2NvcHkJICMgbGluZSA1OSwgPF9tdWx0MiQx
LjI+dDU0MiwgPF9ydCQxLjI+dDUyOSwgMChJNjQpCiAjaW5zdHIKLmxvYyAy
IDY2CglvcgkkMjEsJDI3LCQxMgkgI2NsYXNzIHNvdXJjZSxjc3BlYyxyZWpv
aW5fY29weQkgIyBsaW5lIDY2LCA8PnQ1NzIsIDw+dDM3OSwgPD50MzgwCiAj
aW5zdHIKLmxvYyAyIDY2CglzOGFkZGwJJDE4LCQzMSwkMTEJICNjbGFzcyBz
b3VyY2UsY3NwZWMscmVqb2luX2NvcHkJICMgbGluZSA2NiwgPD50OTI3LCA8
X3JkJDEuMj50NTI4LCAwKEk2NCkKaW50ZXJwcmV0ZXIuZHluX3NldHVwX2Vu
ZF8xOF8wOgogI2luc3RyCi5sb2MgMiA2NQoJczRhZGRsCSQxOCwkMzEsJDE0
CSAjY2xhc3Mgc291cmNlLGNzcGVjCSAjIGxpbmUgNjUsIDw+dDU0MSwgPF9y
ZCQxLjI+dDUyOCwgMChJNjQpCglicgkkMzEsTDE3NSQzCiAjbWFya190cmFj
ZSAxOTg7CkwxNzMkMzoKaW50ZXJwcmV0ZXIuZHluX3NldHVwX2JlZ2luXzE0
XzA6CiAjaW5zdHIKCWxkYQkkMjcsMzEoJDMxKQkgI2NsYXNzIGRtb3ZlLGRt
X2NvbnN0YW50CSAjIDMxKFNJNjQpCglzdHEJJDMxLER5Q1JUX0R1bW15R2xv
YmFsCSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMCwgMHgwKFA2NCksIDw+dDUz
NiwgYWRkcihfRHlDUlRfRHVtbXlHbG9iYWwkMS45KShQNjQpLCAwKEkzMiks
IDAoSTMyKSwgMChJMzIpLCAwKEkzMikKICNpbnN0cgoubG9jIDIgNjAKCWNt
cGx0CSQxOSwkMjEsJDI1CSAjY2xhc3Mgc291cmNlLHJlam9pbl9jb3B5CSAj
IGxpbmUgNjAsIDw+dDM2MSwgPF9ydCQxLjI+dDUyOSwgMShTSTY0KQoJY3B5
cwkkZjMxLCRmMzEsJGYzMQkjIHBhZAogI2luc3RyCi5sb2MgMiA2MAoJY21w
bHQJJDI3LCQxOSwkMjcJICNjbGFzcyBzb3VyY2UscmVqb2luX2NvcHkJICMg
bGluZSA2MCwgPD50MzYyLCAzMShTSTY0KSwgPF9ydCQxLjI+dDUyOQoJc3Rx
CSQzMSxEeUNSVF9EdW1teUdsb2JhbAkgI2NsYXNzIHNvdXJjZQkgIyBsaW5l
IDAsIDB4MChQNjQpLCA8PnQ1MzYsIGFkZHIoX0R5Q1JUX0R1bW15R2xvYmFs
JDEuOSkoUDY0KSwgMChJMzIpLCAwKEkzMiksIDAoSTMyKSwgMChJMzIpCiAj
aW5zdHIKLmxvYyAyIDUzCglzNGFkZGwJJDIwLCQzMSwkMTQJICNjbGFzcyBz
b3VyY2UscmVqb2luX2NvcHkJICMgbGluZSA1MywgPF9tdWx0MSQxLjI+dDU0
MywgPF9ycyQxLjI+dDUzMCwgMChJNjQpCiAjaW5zdHIKLmxvYyAyIDYwCglv
cgkkMjUsJDI3LCQxNwkgI2NsYXNzIHNvdXJjZSxyZWpvaW5fY29weQkgIyBs
aW5lIDYwLCA8PnQ1NzEsIDw+dDM2MSwgPD50MzYyCiAjaW5zdHIKLmxvYyAy
IDYwCglzOGFkZGwJJDE5LCQzMSwkMTMJICNjbGFzcyBzb3VyY2UsY3NwZWMs
cmVqb2luX2NvcHkJICMgbGluZSA2MCwgPD50OTMyLCA8X3J0JDEuMj50NTI5
LCAwKEk2NCkKICNpbnN0cgoubG9jIDIgNTkKCXM0YWRkbAkkMTksJDMxLCQx
NgkgI2NsYXNzIHNvdXJjZSxjc3BlYyxyZWpvaW5fY29weQkgIyBsaW5lIDU5
LCA8X211bHQyJDEuMj50NTQyLCA8X3J0JDEuMj50NTI5LCAwKEk2NCkKICNp
bnN0cgoJbGRhCSQyMSwxKCQzMSkJICNjbGFzcyBkbW92ZSxkbV9jb25zdGFu
dAkgIyAxKFNJNjQpCiAjaW5zdHIKCWxkYQkkMTIsMzEoJDMxKQkgI2NsYXNz
IGRtb3ZlLGRtX2NvbnN0YW50CSAjIDMxKFNJNjQpCmludGVycHJldGVyLmR5
bl9zZXR1cF9lbmRfMTRfMDoKICNpbnN0cgoubG9jIDIgNjYKCWNtcGx0CSQx
OCwkMjEsJDIxCSAjY2xhc3Mgc291cmNlLGNzcGVjCSAjIGxpbmUgNjYsIDw+
dDM3OSwgPF9yZCQxLjI+dDUyOCwgMShTSTY0KQoJYnIJJDMxLEwxNzQkMwog
I21hcmtfdHJhY2UgNzQ7Ckw0MyQzOgppbnRlcnByZXRlci5keW5fc2V0dXBf
YmVnaW5fMl8wOgogI2luc3RyCglzdHEJJDMxLER5Q1JUX0R1bW15R2xvYmFs
CSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMCwgMHgwKFA2NCksIDw+dDUzNiwg
YWRkcihfRHlDUlRfRHVtbXlHbG9iYWwkMS45KShQNjQpLCAwKEkzMiksIDAo
STMyKSwgMChJMzIpLCAwKEkzMikKCW9yCSQzMSwkMzEsJDMxCSAjY2xhc3Mg
ZG1vdmUsZG1fcmVnaXN0ZXIJICMgPD50NTMzCgkgIyBzdGFsbCAJMQogI2lu
c3RyCglzdHEJJDMxLER5Q1JUX0R1bW15R2xvYmFsCSAjY2xhc3Mgc291cmNl
CSAjIGxpbmUgMCwgMHgwKFA2NCksIDw+dDUzNiwgYWRkcihfRHlDUlRfRHVt
bXlHbG9iYWwkMS45KShQNjQpLCAwKEkzMiksIDAoSTMyKSwgMChJMzIpLCAw
KEkzMikKICNtYXJrX2NhbGwgY2FsbGVyX3NhdmVzLCByZWdzLCBhdHlwZXMo
KSwgcnR5cGVzKCk7CiAjaW5zdHIKLmxvYyAyIDI2Cglqc3IJJDI2LER5Q1JU
X1BhdGNoSW50cmFVbml0QnJhbmNoZXMKCWJyCSQyNixGQUtFMjMKRkFLRTIz
OglsZGdwCSRncCwwKCQyNikJICNjbGFzcyBzb3VyY2UJICMgbGluZSAyNiwg
cmFkZHIoRHlDUlRfUGF0Y2hJbnRyYVVuaXRCcmFuY2hlcykoUDY0KSwgPD50
NTMzCiAjaW5zdHIKCXN0cQkkMzEsRHlDUlRfQ29kZUxvY2F0aW9uCSAjY2xh
c3Mgc291cmNlCSAjIGxpbmUgMCwgMHgwKFA2NCksIDw+dDUzNiwgYWRkcihf
RHlDUlRfQ29kZUxvY2F0aW9uJDEuMCkoUDY0KSwgMChJMzIpLCAwKEkzMiks
IDAoSTMyKSwgMChJMzIpCglsZGEJJDI1LDMoJDMxKQkgI2NsYXNzIGRtb3Zl
LGRtX2NvbnN0YW50CSAjIDMoU0kzMikKaW50ZXJwcmV0ZXIuZHluX3NldHVw
X2VuZF8yXzA6CiAjaW5zdHIKCWJyCSQzMSxMNjIkMwoJYmlzCSQzMSwkMzEs
JDMxCSMgcGFkCiAjbWFya190cmFjZSAyMTU7Ckw0MCQzOgogI2luc3RyCi5s
b2MgMiAyNgoJbGRxCSQxNSxEeUNSVF9UYWJsZUxvY2F0aW9uCSAjY2xhc3Mg
c291cmNlCSAjIGxpbmUgMjYsIDw+dDEwNTksIDw+dDUzNiwgYWRkcihfRHlD
UlRfVGFibGVMb2NhdGlvbiQxLjApKFA2NCkKCWxkYWgJJDE3LDEoJDMxKQkg
I2NsYXNzIGRtb3ZlLGRtX2NvbnN0YW50CSAjIDY1NTM2KEkzMikKICNpbnN0
cgoubG9jIDIgMjYKCWxkbAkkMTEsRHlDUlRfVGFibGVQb2ludGVySW5kZXgJ
ICNjbGFzcyBzb3VyY2UJICMgbGluZSAyNiwgPF9EeUNSVF9UYWJsZVBvaW50
ZXJJbmRleCQxLjA+dDEwNTYsIDw+dDUzNiwgYWRkcihfRHlDUlRfVGFibGVQ
b2ludGVySW5kZXgkMS4wKShQNjQpCi5sb2MgMiAyNgoJbGRhCSQ4LER5Q1JU
X1RhYmxlUG9pbnRlcnMrOAkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDI2LCA8
PnQ3MjgsIDw+dDUzNiwgKGFkZHIoX0R5Q1JUX1RhYmxlUG9pbnRlcnMkMS4w
KShQNjQpICsgMHg4KEk2NCkpKFA2NCkKICNpbnN0cgoJbGRhCSQ3LC0zMjc2
OCgkMTcpCSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMCwgPD50NzI1LCA2NTUz
NihJMzIpLCAtMzI3NjgoU0k2NCkKCXN0bAkkMTksRHlDUlRfQnVpbGRUYWJs
ZVBvaW50ZXIJICNjbGFzcyBzb3VyY2UJICMgbGluZSAwLCAxKEkzMiksIDw+
dDUzNiwgYWRkcihfRHlDUlRfQnVpbGRUYWJsZVBvaW50ZXIkMS4wKShQNjQp
LCAwKEkzMiksIDAoSTMyKSwgMChJMzIpLCAwKEkzMikKICNpbnN0cgoJYWRk
cQkkMTUsJDcsJDYJICNjbGFzcyBzb3VyY2UJICMgbGluZSAwLCA8PnQxMDU1
LCA8PnQxMDU5LCA8PnQ3MjUKCXN0cQkkNixEeUNSVF9TdGF0aWNWYWx1ZVRh
YmxlCSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMCwgPD50MTA1NSwgPD50NTM2
LCBhZGRyKF9EeUNSVF9TdGF0aWNWYWx1ZVRhYmxlJDEuMCkoUDY0KSwgMChJ
MzIpLCAwKEkzMiksIDAoSTMyKSwgMChJMzIpCiAjaW5zdHIKLmxvYyAyIDI2
CglhZGRxCSQxMSwkOCwkOAkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDI2LCA8
PnQyNDIsIDxfRHlDUlRfVGFibGVQb2ludGVySW5kZXgkMS4wPnQxMDU2LCA8
PnQ3MjgKCXN0cQkkMzEsRHlDUlRfU1ZUSW5kZXgJICNjbGFzcyBzb3VyY2UJ
ICMgbGluZSAwLCAweDAoUDY0KSwgPD50NTM2LCBhZGRyKF9EeUNSVF9TVlRJ
bmRleCQxLjApKFA2NCksIDAoSTMyKSwgMChJMzIpLCAwKEkzMiksIDAoSTMy
KQogI2luc3RyCi5sb2MgMiAyNgoJYWRkcQkkMTUsNjU1MzYsJDE1CSAjY2xh
c3Mgc291cmNlCSAjIGxpbmUgMjYsIDxfRHlDUlRfVGFibGVMb2NhdGlvbiQx
LjA+dDEwNTgsIDw+dDEwNTksIDY1NTM2KEkzMikKLmxvYyAyIDI2CglzdHEJ
JDE1LER5Q1JUX1RhYmxlTG9jYXRpb24JICNjbGFzcyBzb3VyY2UJICMgbGlu
ZSAyNiwgPF9EeUNSVF9UYWJsZUxvY2F0aW9uJDEuMD50MTA1OCwgPD50NTM2
LCBhZGRyKF9EeUNSVF9UYWJsZUxvY2F0aW9uJDEuMCkoUDY0KSwgMChJMzIp
LCAwKEkzMiksIDAoSTMyKSwgMChJMzIpCiAjaW5zdHIKLmxvYyAyIDI2Cglz
dHEJJDYsMCgkOCkJICNjbGFzcyBzb3VyY2UJICMgbGluZSAyNiwgPD50MTA1
NSwgPD50MjQyLCAwKEk2NCksIDAoSTMyKSwgMChJMzIpLCAwKEkzMiksIDAo
STMyKQoubG9jIDIgMjYKCWFkZGwJJDExLDgsJDExCSAjY2xhc3Mgc291cmNl
CSAjIGxpbmUgMjYsIDxfRHlDUlRfVGFibGVQb2ludGVySW5kZXgkMS4wPnQy
NDMsIDxfRHlDUlRfVGFibGVQb2ludGVySW5kZXgkMS4wPnQxMDU2LCA4KEkz
MikKICNpbnN0cgoubG9jIDIgMjYKCXN0bAkkMTEsRHlDUlRfVGFibGVQb2lu
dGVySW5kZXgJICNjbGFzcyBzb3VyY2UJICMgbGluZSAyNiwgPF9EeUNSVF9U
YWJsZVBvaW50ZXJJbmRleCQxLjA+dDI0MywgPD50NTM2LCBhZGRyKF9EeUNS
VF9UYWJsZVBvaW50ZXJJbmRleCQxLjApKFA2NCksIDAoSTMyKSwgMChJMzIp
LCAwKEkzMiksIDAoSTMyKQoJbGRhCSQyMSw0KCQzMSkJICNjbGFzcyBkbW92
ZSxkbV9jb25zdGFudAkgIyA0KEk2NCkKICNpbnN0cgoubG9jIDIgMjYKCWxk
cQkkMTUsRHlDUlRfV29ya0xpc3QJICNjbGFzcyBzb3VyY2UJICMgbGluZSAy
NiwgPF9EeUNfVGVtcCQxLjQ4PnQxMDU3LCA8PnQ1MzYsIGFkZHIoX0R5Q1JU
X1dvcmtMaXN0JDEuMCkoUDY0KQoJbGRhCSQyMCwyMSgkMzEpCSAjY2xhc3Mg
ZG1vdmUsZG1fY29uc3RhbnQJICMgMjEoU0k2NCkKICNpbnN0cgoJbGRsCSQy
MiwkMi4xJDJzcGlsbF9wICsgOTYoJHNwKQkgI2NsYXNzIGRtb3ZlLGRtX3Jl
c3RvcmUJICMgPF9wYyQxLjE+dDQ1NAoJbGRhCSQxOSwxNigkMzEpCSAjY2xh
c3MgZG1vdmUsZG1fY29uc3RhbnQJICMgMTYoU0k2NCkKICNpbnN0cgoJbGRx
CSQyMywkMi4xJDJzcGlsbF9wICsgODgoJHNwKQkgI2NsYXNzIGRtb3ZlLGRt
X3Jlc3RvcmUJICMgPF9ieXRlY29kZXMkMS4xPnQ0NTUKCWxkYQkkMTgsMTEo
JDMxKQkgI2NsYXNzIGRtb3ZlLGRtX2NvbnN0YW50CSAjIDExKFNJNjQpCiAj
aW5zdHIKCWxkYQkkMTYsMjYoJDMxKQkgI2NsYXNzIGRtb3ZlLGRtX2NvbnN0
YW50CSAjIDI2KFNJNjQpCi5sb2MgMiAyNgoJYm5lCSQxNSxMMTk3JDMJICNj
bGFzcyBzb3VyY2UJICMgbGluZSAyNiwgPF9EeUNfVGVtcCQxLjQ4PnQxMDU3
Ckw0MSQzOgogI2luc3RyCglzdHEJJDMxLER5Q1JUX0JyYW5jaEluZGV4CSAj
Y2xhc3Mgc291cmNlCSAjIGxpbmUgMCwgMHgwKFA2NCksIDw+dDUzNiwgYWRk
cihfRHlDUlRfQnJhbmNoSW5kZXgkMS4wKShQNjQpLCAwKEkzMiksIDAoSTMy
KSwgMChJMzIpLCAwKEkzMikKCWxkYQkkMTQsMSgkMzEpCSAjY2xhc3MgZG1v
dmUsZG1fY29uc3RhbnQJICMgMShTSTY0KQogI2luc3RyCglsZGEJJDEzLDYo
JDMxKQkgI2NsYXNzIGRtb3ZlLGRtX2NvbnN0YW50CSAjIDYoU0k2NCkKICNp
bnN0cgoJbGRhCSQxMiwzMSgkMzEpCSAjY2xhc3MgZG1vdmUsZG1fY29uc3Rh
bnQJICMgMzEoU0k2NCkKICNpbnN0cgoJYnIJJDMxLEw0MiQzCiAjbWFya190
cmFjZSAyMjQ7CkwxOTckMzoKICNpbnN0cgoJbGRhCSQyNSwzKCQzMSkJICNj
bGFzcyBkbW92ZSxkbV9jb25zdGFudAkgIyAzKFNJMzIpCgkgIyBzdGFsbCAJ
MQogI2luc3RyCi5sb2MgMiAyNgoJc3RsCSQyNSwzMigkMTUpCSAjY2xhc3Mg
c291cmNlCSAjIGxpbmUgMjYsIDMoU0kzMiksIDxfRHlDX1RlbXAkMS40OD50
MTA1NywgMzIoSTY0KSwgMChJMzIpLCAwKEkzMiksIDAoSTMyKSwgMChJMzIp
CiAjaW5zdHIKCWxkcQkkMjMsJDIuMSQyc3BpbGxfcCArIDg4KCRzcCkJICNj
bGFzcyBkbW92ZSxkbV9yZXN0b3JlCSAjIDxfYnl0ZWNvZGVzJDEuMT50NDU1
CiAjaW5zdHIKCWxkYQkkMTYsMjYoJDMxKQkgI2NsYXNzIGRtb3ZlLGRtX2Nv
bnN0YW50CSAjIDI2KFNJNjQpCglicgkkMzEsTDQxJDMKICNtYXJrX3RyYWNl
IDIxOTsKTDM4JDM6CiAjaW5zdHIKCW9yCSQxOSwkMzEsJDI0CSAjY2xhc3Mg
c291cmNlCSAjIGxpbmUgMCwgPD50NTc3LCA8PnQxMDYzCiAjaW5zdHIKCW9y
CSQzMSwkMzEsJDMxCSAjY2xhc3MgZG1vdmUsZG1fcmVnaXN0ZXIJICMgPD50
NTMzCiAjaW5zdHIKCXN0cQkkMjQsJDIuMSQyc3BpbGxfcCArIDE2KCRzcCkJ
ICNjbGFzcyBkbW92ZSxkbV9zcGlsbAkgIyA8PnQ1NzcKICNpbnN0cgoJYnIJ
JDMxLEwzOSQzCiAjbWFya190cmFjZSAyMjA7CkwzNyQzOgogI2luc3RyCgls
ZHEJJDIxLCQyLjEkMnNwaWxsX3AgKyAzNzYoJHNwKQkgI2NsYXNzIGRtb3Zl
LGRtX3Jlc3RvcmUJICMgPD50MTA4NgoJbGRhCSQxNCwyKCQzMSkJICNjbGFz
cyBkbW92ZSxkbV9jb25zdGFudAkgIyAyKFNJNjQpCiAjaW5zdHIKCWxkYWgJ
JDIzLDMyKCQzMSkJICNjbGFzcyBkbW92ZSxkbV9jb25zdGFudAkgIyAyMDk3
MTUyKEkzMikKICNpbnN0cgoJbGRhaAkkMjcsLTMyKCQzMSkJICNjbGFzcyBk
bW92ZSxkbV9jb25zdGFudAkgIyA0MjkyODcwMTQ0KEkzMikKICNpbnN0cgou
bG9jIDIgMjYKCWFkZHEJJDIxLDQsJDEzCSAjY2xhc3Mgc291cmNlCSAjIGxp
bmUgMjYsIDw+dDEwNzAsIDw+dDEwODYsIDQoU0kzMikKLmxvYyAyIDI2Cgls
ZGwJJDEyLDAoJDIxKQkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDI2LCA8PnQx
MDY2LCA8PnQxMDg2LCAwKEk2NCkKICNpbnN0cgoubG9jIDIgMjYKCXN1YnEJ
JDIwLCQxMywkMTEJICNjbGFzcyBzb3VyY2UJICMgbGluZSAyNiwgPD50MTA2
OSwgPD50MTA2MywgPD50MTA3MAogI2luc3RyCi5sb2MgMiAyNgoJYWRkbAkk
MTEsMywkMTMJICNjbGFzcyBzb3VyY2UJICMgbGluZSAyNiwgPD50NjE1LCA8
PnQxMDY5LCAzKFNJMzIpCiAjaW5zdHIKLmxvYyAyIDI2CgljbW92Z2UJJDEx
LCQxMSwkMTMJICNjbGFzcyBzb3VyY2UJICMgbGluZSAyNiwgPD50NjE2LCA8
PnQxMDY5LCA8PnQxMDY5LCA8PnQ2MTUKICNpbnN0cgoubG9jIDIgMjYKCWxk
YQkkMTEsLTEoJDIzKQkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDI2LCA8PnQ3
MTgsIDIwOTcxNTIoSTMyKSwgLTEoU0k2NCkKICNpbnN0cgoubG9jIDIgMjYK
CXNyYQkkMTMsJDE0LCQxMwkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDI2LCA8
PnQxMDY4LCA8PnQ2MTYsIDIoU0k2NCkKICNpbnN0cgoubG9jIDIgMjYKCWFu
ZAkkMTIsJDI3LCQxMgkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDI2LCA8PnQx
MDY1LCA8PnQxMDY2LCA0MjkyODcwMTQ0KEkzMikKICNpbnN0cgoubG9jIDIg
MjYKCWFuZAkkMTMsJDExLCQxMQkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDI2
LCA8PnQxMDY3LCA8PnQxMDY4LCA8PnQ3MTgKCWNweXMJJGYzMSwkZjMxLCRm
MzEJIyBwYWQKICNpbnN0cgoubG9jIDIgMjYKCW9yCSQxMSwkMTIsJDEyCSAj
Y2xhc3Mgc291cmNlCSAjIGxpbmUgMjYsIDw+dDEwNjQsIDw+dDEwNjcsIDw+
dDEwNjUKLmxvYyAyIDI2CglzdGwJJDEyLDAoJDIxKQkgI2NsYXNzIHNvdXJj
ZQkgIyBsaW5lIDI2LCA8PnQxMDY0LCA8PnQxMDg2LCAwKEk2NCksIDAoSTMy
KSwgMChJMzIpLCAwKEkzMiksIDAoSTMyKQogI2luc3RyCglvcgkkMzEsJDMx
LCQzMQkgI2NsYXNzIGRtb3ZlLGRtX3JlZ2lzdGVyCSAjIDw+dDUzMwoJY3B5
cwkkZjMxLCRmMzEsJGYzMQkjIHBhZAogI2luc3RyCglvcgkkMjAsJDMxLCQx
OQkgI2NsYXNzIGRtb3ZlLGRtX3JlZ2lzdGVyCSAjIDw+dDEwNjMKCWJlcQkk
MjQsTDE5OCQzCSAjY2xhc3Mgc291cmNlLHJlam9pbl9jb3B5CSAjIGxpbmUg
MCwgPD50NTc3CiAjaW5zdHIKCWJyCSQzMSxMMzkkMwoJYmlzCSQzMSwkMzEs
JDMxCSMgcGFkCiAjbWFya190cmFjZSAyMjc7CkwxOTgkMzoKICNpbnN0cgoJ
YnIJJDMxLEwzOCQzCgliaXMJJDMxLCQzMSwkMzEJIyBwYWQKICNtYXJrX3Ry
YWNlIDIxMjsKTDM2JDM6CiAjaW5zdHIKLmxvYyAyIDI2CglhZGRxCSQyMSw0
LCQyMwkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDI2LCA8PnQxMDc3LCA8PnQx
MDg2LCA0KFNJMzIpCi5sb2MgMiAyNgoJbGRsCSQyMiwwKCQyMSkJICNjbGFz
cyBzb3VyY2UJICMgbGluZSAyNiwgPD50MTA3MywgPD50MTA4NiwgMChJNjQp
CiAjaW5zdHIKLmxvYyAyIDI2CglzdWJxCSQwLCQyMywkMjAJICNjbGFzcyBz
b3VyY2UJICMgbGluZSAyNiwgPD50MTA3NiwgPD50MTA3OSwgPD50MTA3Nwog
I2luc3RyCi5sb2MgMiAyNgoJYWRkbAkkMjAsMywkMjMJICNjbGFzcyBzb3Vy
Y2UJICMgbGluZSAyNiwgPD50NjEzLCA8PnQxMDc2LCAzKFNJMzIpCiAjaW5z
dHIKLmxvYyAyIDI2CgljbW92Z2UJJDIwLCQyMCwkMjMJICNjbGFzcyBzb3Vy
Y2UJICMgbGluZSAyNiwgPD50NjE0LCA8PnQxMDc2LCA8PnQxMDc2LCA8PnQ2
MTMKICNpbnN0cgoJbGRhCSQyMCwyKCQzMSkJICNjbGFzcyBkbW92ZSxkbV9j
b25zdGFudAkgIyAyKFNJNjQpCiAjaW5zdHIKCWxkYWgJJDE5LDMyKCQzMSkJ
ICNjbGFzcyBkbW92ZSxkbV9jb25zdGFudAkgIyAyMDk3MTUyKEkzMikKICNp
bnN0cgoubG9jIDIgMjYKCXNyYQkkMjMsJDIwLCQyMwkgI2NsYXNzIHNvdXJj
ZQkgIyBsaW5lIDI2LCA8PnQxMDc1LCA8PnQ2MTQsIDIoU0k2NCkKICNpbnN0
cgoubG9jIDIgMjYKCWxkYQkkMTksLTEoJDE5KQkgI2NsYXNzIHNvdXJjZQkg
IyBsaW5lIDI2LCA8PnQ3MTQsIDIwOTcxNTIoSTMyKSwgLTEoU0k2NCkKICNp
bnN0cgoubG9jIDIgMjYKCWFuZAkkMjMsJDE5LCQyMwkgI2NsYXNzIHNvdXJj
ZQkgIyBsaW5lIDI2LCA8PnQxMDc0LCA8PnQxMDc1LCA8PnQ3MTQKICNpbnN0
cgoJbGRhaAkkMjcsLTMyKCQzMSkJICNjbGFzcyBkbW92ZSxkbV9jb25zdGFu
dAkgIyA0MjkyODcwMTQ0KEkzMikKCSAjIHN0YWxsIAkxCiAjaW5zdHIKLmxv
YyAyIDI2CglhbmQJJDIyLCQyNywkMjIJICNjbGFzcyBzb3VyY2UJICMgbGlu
ZSAyNiwgPD50MTA3MiwgPD50MTA3MywgNDI5Mjg3MDE0NChJMzIpCiAjaW5z
dHIKLmxvYyAyIDI2CglvcgkkMjMsJDIyLCQyMwkgI2NsYXNzIHNvdXJjZQkg
IyBsaW5lIDI2LCA8PnQxMDcxLCA8PnQxMDc0LCA8PnQxMDcyCi5sb2MgMiAy
NgoJc3RsCSQyMywwKCQyMSkJICNjbGFzcyBzb3VyY2UJICMgbGluZSAyNiwg
PD50MTA3MSwgPD50MTA4NiwgMChJNjQpLCAwKEkzMiksIDAoSTMyKSwgMChJ
MzIpLCAwKEkzMikKICNpbnN0cgoubG9jIDIgMjYKCWxkcQkkMjIsaW50ZXJw
cmV0ZXIuTFNWRnJlZUxpc3QuMgkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDI2
LCA8PnQxMDc4LCA8PnQ1MzYsIGFkZHIoaW50ZXJwcmV0ZXIuTFNWRnJlZUxp
c3QuVkFSLjIpKFA2NCkKCSAjIHN0YWxsIAkyCiAjaW5zdHIKLmxvYyAyIDI2
CglzdHEJJDIyLDAoJDE3KQkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDI2LCA8
PnQxMDc4LCA8PnQxMDgxLCAwKEk2NCksIDAoSTMyKSwgMChJMzIpLCAwKEkz
MiksIDAoSTMyKQogI2luc3RyCi5sb2MgMiAyNgoJc3RxCSQxNyxpbnRlcnBy
ZXRlci5MU1ZGcmVlTGlzdC4yCSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMjYs
IDw+dDEwODEsIDw+dDUzNiwgYWRkcihpbnRlcnByZXRlci5MU1ZGcmVlTGlz
dC5WQVIuMikoUDY0KSwgMChJMzIpLCAwKEkzMiksIDAoSTMyKSwgMChJMzIp
CgkgIyBzdGFsbCAJMQogI2luc3RyCgliZXEJJDI0LEwxOTkkMwkgI2NsYXNz
IHNvdXJjZQkgIyBsaW5lIDAsIDw+dDU3NwogI21hcmtfdHJhY2UgMjIxOwog
I2luc3RyCglzdHEJJDI0LCQyLjEkMnNwaWxsX3AgKyAxNigkc3ApCSAjY2xh
c3MgZG1vdmUsZG1fc3BpbGwJICMgPD50NTc3CglsZGEJJDI1LDMoJDMxKQkg
I2NsYXNzIGRtb3ZlLGRtX2NvbnN0YW50CSAjIDMoU0kzMikKICNpbnN0cgoJ
YnIJJDMxLEw2MiQzCiAjbWFya190cmFjZSAyMTc7CkwxOTkkMzoKICNpbnN0
cgoJb3IJJDAsJDMxLCQyNAkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDAsIDw+
dDU3NywgPD50MTA3OQoJICMgc3RhbGwgCTEKICNtYXJrX3RyYWNlIDIyMjsK
ICNpbnN0cgoJc3RxCSQyNCwkMi4xJDJzcGlsbF9wICsgMTYoJHNwKQkgI2Ns
YXNzIGRtb3ZlLGRtX3NwaWxsCSAjIDw+dDU3NwoJbGRhCSQyNSwzKCQzMSkJ
ICNjbGFzcyBkbW92ZSxkbV9jb25zdGFudAkgIyAzKFNJMzIpCiAjaW5zdHIK
CWJyCSQzMSxMNjIkMwoJYmlzCSQzMSwkMzEsJDMxCSMgcGFkCiAjbWFya190
cmFjZSAyMTM7CkwzNCQzOgogI21hcmtfY2FsbCBjYWxsZXJfc2F2ZXMsIHJl
Z3MsIGF0eXBlcygpLCBydHlwZXMobjY0KTsKICNpbnN0cgoJb3IJJDMxLCQz
MSwkMzEJICNjbGFzcyBkbW92ZSxkbV9yZWdpc3RlcgkgIyA8PnQ1MzMKLmxv
YyAyIDI2Cglqc3IJJDI2LERZQ19DQUNIRV9jcmVhdGUKCWJyCSQyNixGQUtF
MzgKRkFLRTM4OglsZGdwCSRncCwwKCQyNikJICNjbGFzcyBzb3VyY2UJICMg
bGluZSAyNiwgcmFkZHIoRFlDX0NBQ0hFX2NyZWF0ZSkoUDY0KSwgPD50NTMz
CiAjaW5zdHIKCXN0cQkkMCwkMi4xJDJzcGlsbF9wICsgMzkyKCRzcCkJICNj
bGFzcyBkbW92ZSxkbV9zcGlsbAkgIyA8PnQxMDgwCglvcgkkMCwkMzEsJDE2
CSAjY2xhc3MgZG1vdmUsZG1fcmVnaXN0ZXIJICMgPD50MTA4MAogI2luc3Ry
CglzdHEJJDAsaW50ZXJwcmV0ZXIuQ2FjaGUuMgkgI2NsYXNzIHNvdXJjZQkg
IyBsaW5lIDAsIDw+dDEwODAsIDw+dDUzNiwgYWRkcihpbnRlcnByZXRlci5D
YWNoZS5WQVIuMikoUDY0KSwgMChJMzIpLCAwKEkzMiksIDAoSTMyKSwgMChJ
MzIpCglsZGEJJDE4LDEoJDMxKQkgI2NsYXNzIGRtb3ZlLGRtX2NvbnN0YW50
CSAjIDEoU0kzMikKICNpbnN0cgoJb3IJJDMxLCQzMSwkMzEJICNjbGFzcyBk
bW92ZSxkbV9yZWdpc3RlcgkgIyA8PnQ1MzMKCWxkcQkkMTcsJDIuMSQyc3Bp
bGxfcCArIDM4NCgkc3ApCSAjY2xhc3MgZG1vdmUsZG1fcmVzdG9yZQkgIyA8
PnQxMDgxCgkgIyBzdGFsbCAJMQogI2luc3RyCglicgkkMzEsTDM1JDMKCWJp
cwkkMzEsJDMxLCQzMQkjIHBhZAogI21hcmtfdHJhY2UgMjE0OwpMMzIkMzoK
ICNpbnN0cgoubG9jIDIgMjYKCWxkcQkkMTcsaW50ZXJwcmV0ZXIuTFNWRnJl
ZUxpc3QuMgkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDI2LCA8PnQxMDgxLCA8
PnQ1MzYsIGFkZHIoaW50ZXJwcmV0ZXIuTFNWRnJlZUxpc3QuVkFSLjIpKFA2
NCkKCW9yCSQzMSwkMzEsJDMxCSAjY2xhc3MgZG1vdmUsZG1fcmVnaXN0ZXIJ
ICMgPD50NTMzCiAjaW5zdHIKCWxkcQkkMTYsaW50ZXJwcmV0ZXIuQ2FjaGUu
MgkgI2NsYXNzIHNvdXJjZSxyZWpvaW5fY29weQkgIyBsaW5lIDAsIDw+dDEw
ODAsIDw+dDUzNiwgYWRkcihpbnRlcnByZXRlci5DYWNoZS5WQVIuMikoUDY0
KQoJICMgc3RhbGwgCTEKICNpbnN0cgoJc3RxCSQxNywkMi4xJDJzcGlsbF9w
ICsgMzg0KCRzcCkJICNjbGFzcyBkbW92ZSxkbV9zcGlsbAkgIyA8PnQxMDgx
CiAjaW5zdHIKCXN0cQkkMTYsJDIuMSQyc3BpbGxfcCArIDM5Migkc3ApCSAj
Y2xhc3MgZG1vdmUsZG1fc3BpbGwJICMgPD50MTA4MAogI2luc3RyCi5sb2Mg
MiAyNgoJbGRxCSQyNywwKCQxNykJICNjbGFzcyBzb3VyY2UJICMgbGluZSAy
NiwgPD50MTA4NCwgPD50MTA4MSwgMChJNjQpCgkgIyBzdGFsbCAJMgogI2lu
c3RyCi5sb2MgMiAyNgoJc3RxCSQyNyxpbnRlcnByZXRlci5MU1ZGcmVlTGlz
dC4yCSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMjYsIDw+dDEwODQsIDw+dDUz
NiwgYWRkcihpbnRlcnByZXRlci5MU1ZGcmVlTGlzdC5WQVIuMikoUDY0KSwg
MChJMzIpLCAwKEkzMiksIDAoSTMyKSwgMChJMzIpCiAjaW5zdHIKCWJyCSQz
MSxMMzMkMwogI21hcmtfdHJhY2UgMjA3OwpMMjkkMzoKICNpbnN0cgoJc3Rs
CSQyNSwkMi4xJDJzcGlsbF9wKCRzcCkJICNjbGFzcyBkbW92ZSxkbV9zcGls
bAkgIyA8PnQ1ODcKCWxkYWgJJDI3LDEoJDMxKQkgI2NsYXNzIGRtb3ZlLGRt
X2NvbnN0YW50CSAjIDY1NTM2KEkzMikKICNpbnN0cgoJc3RxCSQyNCwkMi4x
JDJzcGlsbF9wICsgMTYoJHNwKQkgI2NsYXNzIGRtb3ZlLGRtX3NwaWxsCSAj
IDw+dDU3NwoubG9jIDIgMjYKCWxkYQkkMjEsRHlDUlRfVGFibGVQb2ludGVy
cys4CSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMjYsIDw+dDcxMCwgPD50NTM2
LCAoYWRkcihfRHlDUlRfVGFibGVQb2ludGVycyQxLjApKFA2NCkgKyAweDgo
STY0KSkoUDY0KQogI2luc3RyCglzdHEJJDIzLCQyLjEkMnNwaWxsX3AgKyA4
OCgkc3ApCSAjY2xhc3MgZG1vdmUsZG1fc3BpbGwJICMgPF9ieXRlY29kZXMk
MS4xPnQ0NTUKCWxkYQkkMjAsLTMyNzY4KCQyNykJICNjbGFzcyBzb3VyY2UJ
ICMgbGluZSAwLCA8PnQ3MDcsIDY1NTM2KEkzMiksIC0zMjc2OChTSTY0KQog
I2luc3RyCglzdGwJJDIyLCQyLjEkMnNwaWxsX3AgKyA5Nigkc3ApCSAjY2xh
c3MgZG1vdmUsZG1fc3BpbGwJICMgPF9wYyQxLjE+dDQ1NAogI2luc3RyCi5s
b2MgMiAyNgoJbGRxCSQxOCxEeUNSVF9UYWJsZUxvY2F0aW9uCSAjY2xhc3Mg
c291cmNlCSAjIGxpbmUgMjYsIDw+dDEwOTMsIDw+dDUzNiwgYWRkcihfRHlD
UlRfVGFibGVMb2NhdGlvbiQxLjApKFA2NCkKICNpbnN0cgoubG9jIDIgMjYK
CWxkbAkkMTcsRHlDUlRfVGFibGVQb2ludGVySW5kZXgJICNjbGFzcyBzb3Vy
Y2UJICMgbGluZSAyNiwgPF9EeUNSVF9UYWJsZVBvaW50ZXJJbmRleCQxLjA+
dDEwOTAsIDw+dDUzNiwgYWRkcihfRHlDUlRfVGFibGVQb2ludGVySW5kZXgk
MS4wKShQNjQpCiAjaW5zdHIKCXN0bAkkMTksRHlDUlRfQnVpbGRUYWJsZVBv
aW50ZXIJICNjbGFzcyBzb3VyY2UJICMgbGluZSAwLCAxKEkzMiksIDw+dDUz
NiwgYWRkcihfRHlDUlRfQnVpbGRUYWJsZVBvaW50ZXIkMS4wKShQNjQpLCAw
KEkzMiksIDAoSTMyKSwgMChJMzIpLCAwKEkzMikKICNpbnN0cgoJYWRkcQkk
MTgsJDIwLCQyMAkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDAsIDw+dDEwODcs
IDw+dDEwOTMsIDw+dDcwNwoJc3RxCSQyMCxEeUNSVF9TdGF0aWNWYWx1ZVRh
YmxlCSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMCwgPD50MTA4NywgPD50NTM2
LCBhZGRyKF9EeUNSVF9TdGF0aWNWYWx1ZVRhYmxlJDEuMCkoUDY0KSwgMChJ
MzIpLCAwKEkzMiksIDAoSTMyKSwgMChJMzIpCiAjaW5zdHIKLmxvYyAyIDI2
CglhZGRxCSQxNywkMjEsJDIxCSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMjYs
IDw+dDEwODgsIDxfRHlDUlRfVGFibGVQb2ludGVySW5kZXgkMS4wPnQxMDkw
LCA8PnQ3MTAKCXN0cQkkMzEsRHlDUlRfU1ZUSW5kZXgJICNjbGFzcyBzb3Vy
Y2UJICMgbGluZSAwLCAweDAoUDY0KSwgPD50NTM2LCBhZGRyKF9EeUNSVF9T
VlRJbmRleCQxLjApKFA2NCksIDAoSTMyKSwgMChJMzIpLCAwKEkzMiksIDAo
STMyKQogI2luc3RyCi5sb2MgMiAyNgoJYWRkcQkkMTgsNjU1MzYsJDE4CSAj
Y2xhc3Mgc291cmNlCSAjIGxpbmUgMjYsIDxfRHlDUlRfVGFibGVMb2NhdGlv
biQxLjA+dDExMTEsIDw+dDEwOTMsIDY1NTM2KEkzMikKLmxvYyAyIDI2Cglz
dHEJJDE4LER5Q1JUX1RhYmxlTG9jYXRpb24JICNjbGFzcyBzb3VyY2UJICMg
bGluZSAyNiwgPF9EeUNSVF9UYWJsZUxvY2F0aW9uJDEuMD50MTExMSwgPD50
NTM2LCBhZGRyKF9EeUNSVF9UYWJsZUxvY2F0aW9uJDEuMCkoUDY0KSwgMChJ
MzIpLCAwKEkzMiksIDAoSTMyKSwgMChJMzIpCiAjaW5zdHIKLmxvYyAyIDI2
CglzdHEJJDIwLDAoJDIxKQkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDI2LCA8
PnQxMDg3LCA8PnQxMDg4LCAwKEk2NCksIDAoSTMyKSwgMChJMzIpLCAwKEkz
MiksIDAoSTMyKQoubG9jIDIgMjYKCWFkZGwJJDE3LDgsJDE3CSAjY2xhc3Mg
c291cmNlCSAjIGxpbmUgMjYsIDxfRHlDUlRfVGFibGVQb2ludGVySW5kZXgk
MS4wPnQxMDg5LCA8X0R5Q1JUX1RhYmxlUG9pbnRlckluZGV4JDEuMD50MTA5
MCwgOChJMzIpCiAjaW5zdHIKLmxvYyAyIDI2CglzdGwJJDE3LER5Q1JUX1Rh
YmxlUG9pbnRlckluZGV4CSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMjYsIDxf
RHlDUlRfVGFibGVQb2ludGVySW5kZXgkMS4wPnQxMDg5LCA8PnQ1MzYsIGFk
ZHIoX0R5Q1JUX1RhYmxlUG9pbnRlckluZGV4JDEuMCkoUDY0KSwgMChJMzIp
LCAwKEkzMiksIDAoSTMyKSwgMChJMzIpCiAjaW5zdHIKLmxvYyAyIDI2Cgls
ZHEJJDIxLER5Q1JUX1dvcmtMaXN0CSAjY2xhc3Mgc291cmNlCSAjIGxpbmUg
MjYsIDxfRHlDX1RlbXAkMS40OD50MTA5MSwgPD50NTM2LCBhZGRyKF9EeUNS
VF9Xb3JrTGlzdCQxLjApKFA2NCkKCSAjIHN0YWxsIAkyCiAjaW5zdHIKLmxv
YyAyIDI2CglibmUJJDIxLEwyMDAkMwkgI2NsYXNzIHNvdXJjZQkgIyBsaW5l
IDI2LCA8X0R5Q19UZW1wJDEuNDg+dDEwOTEKTDMwJDM6CiAjaW5zdHIKCXN0
cQkkMzEsRHlDUlRfQnJhbmNoSW5kZXgJICNjbGFzcyBzb3VyY2UJICMgbGlu
ZSAwLCAweDAoUDY0KSwgPD50NTM2LCBhZGRyKF9EeUNSVF9CcmFuY2hJbmRl
eCQxLjApKFA2NCksIDAoSTMyKSwgMChJMzIpLCAwKEkzMiksIDAoSTMyKQog
I2luc3RyCglicgkkMzEsTDMxJDMKICNtYXJrX3RyYWNlIDIxNjsKTDIwMCQz
OgogI2luc3RyCglsZGEJJDI1LDMoJDMxKQkgI2NsYXNzIGRtb3ZlLGRtX2Nv
bnN0YW50CSAjIDMoU0kzMikKCSAjIHN0YWxsIAkxCiAjaW5zdHIKLmxvYyAy
IDI2CglzdGwJJDI1LDMyKCQyMSkJICNjbGFzcyBzb3VyY2UJICMgbGluZSAy
NiwgMyhTSTMyKSwgPF9EeUNfVGVtcCQxLjQ4PnQxMDkxLCAzMihJNjQpLCAw
KEkzMiksIDAoSTMyKSwgMChJMzIpLCAwKEkzMikKICNpbnN0cgoJYnIJJDMx
LEwzMCQzCiAjbWFya190cmFjZSAyMDY7CkwyNyQzOgogI2luc3RyCi5sb2Mg
MiAyNgoJbGRxCSQzLGludGVycHJldGVyLkxTVkZyZWVMaXN0LjEJICNjbGFz
cyBzb3VyY2UJICMgbGluZSAyNiwgPD50MTEwMSwgPD50NTM2LCBhZGRyKGlu
dGVycHJldGVyLkxTVkZyZWVMaXN0LlZBUi4xKShQNjQpCi5sb2MgMiAyNgoJ
bGRhCSQyNSxpbnRlcnByZXRlci5EWUMuR0VfRU5UUlkuQ0FMTC4xLjEzOQkg
I2NsYXNzIHNvdXJjZSxyZWpvaW5fY29weQkgIyBsaW5lIDI2LCA8PnQ3MDEs
IDw+dDUzNiwgdGFnKGludGVycHJldGVyLkRZQy5HRV9FTlRSWS5DQUxMLjEu
MTM5KShQNjQpCiAjaW5zdHIKCW9yCSQzMSwkMzEsJDMxCSAjY2xhc3MgZG1v
dmUsZG1fcmVnaXN0ZXIJICMgPD50NTMzCgkgIyBzdGFsbCAJMQogI2luc3Ry
CglzdHEJJDMsJDIuMSQyc3BpbGxfcCArIDM2OCgkc3ApCSAjY2xhc3MgZG1v
dmUsZG1fc3BpbGwJICMgPD50MTEwMQogI2luc3RyCi5sb2MgMiAyNgoJbGRx
CSQyNywwKCQzKQkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDI2LCA8PnQxMTAy
LCA8PnQxMTAxLCAwKEk2NCkKCSAjIHN0YWxsIAkyCiAjaW5zdHIKLmxvYyAy
IDI2CglzdHEJJDI3LGludGVycHJldGVyLkxTVkZyZWVMaXN0LjEJICNjbGFz
cyBzb3VyY2UJICMgbGluZSAyNiwgPD50MTEwMiwgPD50NTM2LCBhZGRyKGlu
dGVycHJldGVyLkxTVkZyZWVMaXN0LlZBUi4xKShQNjQpLCAwKEkzMiksIDAo
STMyKSwgMChJMzIpLCAwKEkzMikKICNpbnN0cgoJc3RxCSQxNiw4KCQzKQkg
I2NsYXNzIHNvdXJjZSxyZWpvaW5fY29weQkgIyBsaW5lIDAsIDxfYnl0ZWNv
ZGVzJDEuMT50MTEwOCwgPD50MTEwMSwgOChTSTMyKSwgMChJMzIpLCAwKEkz
MiksIDAoSTMyKSwgMChJMzIpCglvcgkkMjUsJDMxLCQxNgkgI2NsYXNzIGRt
b3ZlLGRtX3JlZ2lzdGVyCSAjIDw+dDcwMQogI2luc3RyCglzdGwJJDE3LDAo
JDMpCSAjY2xhc3Mgc291cmNlLHJlam9pbl9jb3B5CSAjIGxpbmUgMCwgPF9w
YyQxLjE+dDExMDksIDw+dDExMDEsIDAoU0kzMiksIDAoSTMyKSwgMChJMzIp
LCAwKEkzMiksIDAoSTMyKQogI2luc3RyCglzdGwJJDMxLDQoJDMpCSAjY2xh
c3Mgc291cmNlLHJlam9pbl9jb3B5CSAjIGxpbmUgMCwgMChTSTMyKSwgPD50
MTEwMSwgNChTSTMyKSwgMChJMzIpLCAwKEkzMiksIDAoSTMyKSwgMChJMzIp
CiAjaW5zdHIKCXN0cQkkMzEsRHlDUlRfV29ya0xpc3QJICNjbGFzcyBzb3Vy
Y2UscmVqb2luX2NvcHkJICMgbGluZSAwLCAweDAoUDY0KSwgPD50NTM2LCBh
ZGRyKF9EeUNSVF9Xb3JrTGlzdCQxLjApKFA2NCksIDAoSTMyKSwgMChJMzIp
LCAwKEkzMiksIDAoSTMyKQogI2luc3RyCglicgkkMzEsTDI4JDMKCS5lbmQK
ICNtYXJrX2JlZ2luOwogI21hcmtfZW50cnkgY2FsbGVyX3NhdmVzLCByZWdz
LCBhdHlwZXMobjMyLG42NCk7CgkuZW50CW1haW4KCS5nbG9ibAltYWluCm1h
aW46CiAjbWFya190cmFjZSA0OwogI2luc3RyCi5sb2MgMiAxMTcKCWxkYQkk
c3AsLSQyLjIkMmF1dG9fc2l6ZSgkc3ApCSAjY2xhc3Mgc291cmNlCSAjIGxp
bmUgMTE3LCA8PnQ2MCwgJDIuMiQyYXV0b19zaXplKEkzMikKICNpbnN0cgou
bG9jIDIgMTQ0CgljbXBlcQkkMTYsMywkMjQJICNjbGFzcyBzb3VyY2UJICMg
bGluZSAxNDQsIDw+dDY0LCA8X2FyZ2MkMS44MT50MSwgMyhTSTMyKQogI2lu
c3RyCglzdHEJJDI2LCQyLjIkMnJhc19wKCRzcCkJICNjbGFzcyBkbW92ZSxk
bV9zcGlsbAkgIyA8PnQ1OQoJb3IJJDMxLCQzMSwkMzEJICNjbGFzcyBkbW92
ZSxkbV9yZWdpc3RlcgkgIyA8PnQ2MAogI2luc3RyCglzdHEJJDE3LCQyLjIk
MnNwaWxsX3AgKyAzMigkc3ApCSAjY2xhc3MgZG1vdmUsZG1fc3BpbGwJICMg
PF9hcmd2JDEuODE+dDUyCiAjaW5zdHIKLmxvYyAyIDE0NAoJYmVxCSQyNCxM
MjAxJDMJICNjbGFzcyBzb3VyY2UJICMgbGluZSAxNDQsIDw+dDY0CkwyMDIk
MzoKICNpbnN0cgoubG9jIDIgMTQ5CglsZHEJJDE2LDgoJDE3KQkgI2NsYXNz
IHNvdXJjZQkgIyBsaW5lIDE0OSwgPD50MTMsIDxfYXJndiQxLjgxPnQ1Miwg
OChJNjQpCiAjbWFya19jYWxsIGNhbGxlcl9zYXZlcywgcmVncywgYXR5cGVz
KG42NCksIHJ0eXBlcyhuMzIpOwogI2luc3RyCi5sb2MgMiAxNDkKCWpzcgkk
MjYsYXRvaQoJYnIJJDI2LEZBS0U0MgpGQUtFNDI6CWxkZ3AJJGdwLDAoJDI2
KQkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDE0OSwgcmFkZHIoYXRvaSkoUDY0
KSwgPD50NjAsIDw+dDEzCiAjaW5zdHIKCXN0bAkkMCwkMi4yJDJzcGlsbF9w
KCRzcCkJICNjbGFzcyBkbW92ZSxkbV9zcGlsbAkgIyA8X25kYXRhJDEuODI+
dDEwCgljcHlzCSRmMzEsJGYzMSwkZjMxCSMgcGFkCiAjaW5zdHIKCWxkcQkk
MTcsJDIuMiQyc3BpbGxfcCArIDMyKCRzcCkJICNjbGFzcyBkbW92ZSxkbV9y
ZXN0b3JlCSAjIDxfYXJndiQxLjgxPnQ1MgoJb3IJJDMxLCQzMSwkMzEJICNj
bGFzcyBkbW92ZSxkbV9yZWdpc3RlcgkgIyA8PnQ2MAoJICMgc3RhbGwgCTIK
ICNpbnN0cgoubG9jIDIgMTUwCglsZHEJJDE2LDE2KCQxNykJICNjbGFzcyBz
b3VyY2UJICMgbGluZSAxNTAsIDw+dDE3LCA8X2FyZ3YkMS44MT50NTIsIDE2
KEk2NCkKICNtYXJrX2NhbGwgY2FsbGVyX3NhdmVzLCByZWdzLCBhdHlwZXMo
bjY0KSwgcnR5cGVzKG4zMik7CiAjaW5zdHIKLmxvYyAyIDE1MAoJanNyCSQy
NixhdG9pCglicgkkMjYsRkFLRTQzCkZBS0U0MzoJbGRncAkkZ3AsMCgkMjYp
CSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMTUwLCByYWRkcihhdG9pKShQNjQp
LCA8PnQ2MCwgPD50MTcKICNpbnN0cgoJb3IJJDAsJDMxLCQxOAkgI2NsYXNz
IGRtb3ZlLGRtX3JlZ2lzdGVyCSAjIDw+dDE0CiAjaW5zdHIKCWxkYQkkMjQs
LTEoJDMxKQkgI2NsYXNzIGRtb3ZlLGRtX2NvbnN0YW50CSAjIC0xKFNJMzIp
CiAjaW5zdHIKLmxvYyAyIDE1MgoJbGRhCSQxNixfaW9iKzExMgkgI2NsYXNz
IHNvdXJjZSxjc3BlYwkgIyBsaW5lIDE1MiwgPD50NzcsIDw+dDYzLCAoYWRk
cihfX2lvYiQxLjApKFA2NCkgKyAweDcwKEk2NCkpKFA2NCkKCWNweXMJJGYz
MSwkZjMxLCRmMzEJIyBwYWQKICNpbnN0cgoubG9jIDIgMTUwCglhZGRsCSQw
LCQyNCwkMjUJICNjbGFzcyBzb3VyY2UJICMgbGluZSAxNTAsIDxfbnJ1bnMk
MS44Mj50NTQsIDw+dDE0LCAtMShTSTMyKQoJc3RsCSQyNSwkMi4yJDJzcGls
bF9wICsgMTYoJHNwKQkgI2NsYXNzIGRtb3ZlLGRtX3NwaWxsCSAjIDxfbnJ1
bnMkMS44Mj50NTQKICNpbnN0cgoubG9jIDIgMTUyCglsZGEJJDE3LF8kMVNU
UklOR1BBQ0tFVC4zCSAjY2xhc3Mgc291cmNlLGNzcGVjCSAjIGxpbmUgMTUy
LCA8PnQ3OCwgPD50NjMsIGFkZHIoXyQxU1RSSU5HVkFSLjMpKFA2NCkKLmxv
YyAyIDE1MQoJYmdlCSQyNSxMMjAzJDMJICNjbGFzcyBzb3VyY2UJICMgbGlu
ZSAxNTEsIDxfbnJ1bnMkMS44Mj50NTQKICNtYXJrX2NhbGwgY2FsbGVyX3Nh
dmVzLCByZWdzLCBhdHlwZXMobjY0LG42NCxuMzIpLCBydHlwZXMobjMyKTsK
ICNpbnN0cgoJb3IJJDMxLCQzMSwkMzEJICNjbGFzcyBkbW92ZSxkbV9yZWdp
c3RlcgkgIyA8PnQ2MAoubG9jIDIgMTUyCglqc3IJJDI2LGZwcmludGYKCWJy
CSQyNixGQUtFNDQKRkFLRTQ0OglsZGdwCSRncCwwKCQyNikJICNjbGFzcyBz
b3VyY2UJICMgbGluZSAxNTIsIHJhZGRyKGZwcmludGYpKFA2NCksIDw+dDYw
LCA8PnQ3NywgPD50NzgsIDw+dDE0CgkgIyBzdGFsbCAJMQogI2luc3RyCgls
ZGEJJDE2LDEoJDMxKQkgI2NsYXNzIGRtb3ZlLGRtX2NvbnN0YW50CSAjIDEo
U0kzMikKCWNweXMJJGYzMSwkZjMxLCRmMzEJIyBwYWQKICNtYXJrX2NhbGwg
Y2FsbGVyX3NhdmVzLCByZWdzLCBhdHlwZXMobjMyKSwgcnR5cGVzKCk7CiAj
aW5zdHIKCW9yCSQzMSwkMzEsJDMxCSAjY2xhc3MgZG1vdmUsZG1fcmVnaXN0
ZXIJICMgPD50NjAKLmxvYyAyIDE1MwoJanNyCSQyNixleGl0CglicgkkMjYs
RkFLRTQ1CkZBS0U0NToJbGRncAkkZ3AsMCgkMjYpCSAjY2xhc3Mgc291cmNl
CSAjIGxpbmUgMTUzLCByYWRkcihleGl0KShQNjQpLCA8PnQ2MCwgMShTSTMy
KQpMMjAzJDM6CiAjaW5zdHIKICNpbnN0cgoubG9jIDIgMTczCglsZGEJJDE2
LF8kMVBBQ0tFVC43OQkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDE3MywgPD50
NjUsIDw+dDYzLCBhZGRyKF9ieXRlY29kZXMkMS44MikoUDY0KQoJbGRsCSQx
OCwkMi4yJDJzcGlsbF9wKCRzcCkJICNjbGFzcyBkbW92ZSxkbV9yZXN0b3Jl
CSAjIDxfbmRhdGEkMS44Mj50MTAKICNpbnN0cgoJb3IJJDMxLCQzMSwkMTcJ
ICNjbGFzcyBkbW92ZSxkbV9jb25zdGFudAkgIyAwKFNJMzIpCgljcHlzCSRm
MzEsJGYzMSwkZjMxCSMgcGFkCiAjbWFya19jYWxsIGNhbGxlcl9zYXZlcywg
cmVncywgYXR5cGVzKG42NCxuMzIsbjMyKSwgcnR5cGVzKG4zMik7CiAjaW5z
dHIKCW9yCSQzMSwkMzEsJDMxCSAjY2xhc3MgZG1vdmUsZG1fcmVnaXN0ZXIJ
ICMgPD50NjAKLmxvYyAyIDE3MwoJanNyCSQyNixpbnRlcnByZXRlcgoJYnIJ
JDI2LEZBS0U0NgpGQUtFNDY6CWxkZ3AJJGdwLDAoJDI2KQkgI2NsYXNzIHNv
dXJjZQkgIyBsaW5lIDE3MywgcmFkZHIoaW50ZXJwcmV0ZXIpKFA2NCksIDw+
dDYwLCA8PnQ2NSwgMChTSTMyKSwgPF9uZGF0YSQxLjgyPnQxMAogI2luc3Ry
CglzdGwJJDAsJDIuMiQyc3BpbGxfcCArIDgoJHNwKQkgI2NsYXNzIGRtb3Zl
LGRtX3NwaWxsCSAjIDxfcmVzdWx0JDEuODI+dDI3CiAjaW5zdHIKLmxvYyAy
IDE3NQoJb3IJJDMxLCQzMSwkMjcJICNjbGFzcyBzb3VyY2UJICMgbGluZSAx
NzUsIDxfciQxLjgyPnQ1NiwgMChTSTMyKQoJICMgc3RhbGwgCTEKICNpbnN0
cgoJc3RsCSQyNywkMi4yJDJzcGlsbF9wICsgMjQoJHNwKQkgI2NsYXNzIGRt
b3ZlLGRtX3NwaWxsCSAjIDxfciQxLjgyPnQ1NgoJY3B5cwkkZjMxLCRmMzEs
JGYzMQkjIHBhZAogI21hcmtfdHJhY2UgMTsKTDIwNCQzOgogI2luc3RyCgls
ZGwJJDI1LCQyLjIkMnNwaWxsX3AgKyAxNigkc3ApCSAjY2xhc3MgZG1vdmUs
ZG1fcmVzdG9yZQkgIyA8X25ydW5zJDEuODI+dDU0Ci5sb2MgMiAxNzcKCWxk
YQkkMTYsXyQxUEFDS0VULjc5CSAjY2xhc3Mgc291cmNlLGNzcGVjCSAjIGxp
bmUgMTc3LCA8PnQ3MSwgPD50NjMsIGFkZHIoX2J5dGVjb2RlcyQxLjgyKShQ
NjQpCiAjaW5zdHIKCWxkbAkkMTgsJDIuMiQyc3BpbGxfcCgkc3ApCSAjY2xh
c3MgZG1vdmUsZG1fcmVzdG9yZQkgIyA8X25kYXRhJDEuODI+dDEwCglvcgkk
MzEsJDMxLCQxNwkgI2NsYXNzIGRtb3ZlLGRtX2NvbnN0YW50CSAjIDAoU0kz
MikKICNpbnN0cgoJb3IJJDMxLCQzMSwkMzEJICNjbGFzcyBkbW92ZSxkbV9y
ZWdpc3RlcgkgIyA8PnQ2MAogI2luc3RyCi5sb2MgMiAxNzUKCWNtcGx0CSQy
NywkMjUsJDI1CSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMTc1LCA8PnQ2Nywg
PF9yJDEuODI+dDU2LCA8X25ydW5zJDEuODI+dDU0CiAjaW5zdHIKLmxvYyAy
IDE3NQoJYmVxCSQyNSxMMjA1JDMJICNjbGFzcyBzb3VyY2UJICMgbGluZSAx
NzUsIDw+dDY3CiAjbWFya19jYWxsIGNhbGxlcl9zYXZlcywgcmVncywgYXR5
cGVzKG42NCxuMzIsbjMyKSwgcnR5cGVzKG4zMik7CiAjaW5zdHIKLmxvYyAy
IDE3NwoJanNyCSQyNixpbnRlcnByZXRlcgoJYnIJJDI2LEZBS0UzOQpGQUtF
Mzk6CWxkZ3AJJGdwLDAoJDI2KQkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDE3
NywgcmFkZHIoaW50ZXJwcmV0ZXIpKFA2NCksIDw+dDYwLCA8PnQ3MSwgMChT
STMyKSwgPF9uZGF0YSQxLjgyPnQxMAogI2luc3RyCglsZGwJJDE5LCQyLjIk
MnNwaWxsX3AgKyA4KCRzcCkJICNjbGFzcyBkbW92ZSxkbV9yZXN0b3JlCSAj
IDxfcmVzdWx0JDEuODI+dDI3Ci5sb2MgMiAxODEKCWxkYQkkMTYsX2lvYisx
MTIJICNjbGFzcyBzb3VyY2UsY3NwZWMJICMgbGluZSAxODEsIDw+dDc0LCA8
PnQ2MywgKGFkZHIoX19pb2IkMS4wKShQNjQpICsgMHg3MChJNjQpKShQNjQp
CiAjaW5zdHIKLmxvYyAyIDE4MQoJbGRhCSQxNyxfJDFTVFJJTkdQQUNLRVQu
NAkgI2NsYXNzIHNvdXJjZSxjc3BlYwkgIyBsaW5lIDE4MSwgPD50NzUsIDw+
dDYzLCBhZGRyKF8kMVNUUklOR1ZBUi40KShQNjQpCiAjaW5zdHIKCW9yCSQz
MSwkMzEsJDMxCSAjY2xhc3MgZG1vdmUsZG1fcmVnaXN0ZXIJICMgPD50NjAK
ICNpbnN0cgoubG9jIDIgMTc5CgljbXBlcQkkMCwkMTksJDI1CSAjY2xhc3Mg
c291cmNlCSAjIGxpbmUgMTc5LCA8PnQ3MywgPF90bXAkMS44Mj50MzQsIDxf
cmVzdWx0JDEuODI+dDI3CgljcHlzCSRmMzEsJGYzMSwkZjMxCSMgcGFkCiAj
aW5zdHIKCW9yCSQwLCQzMSwkMTgJICNjbGFzcyBkbW92ZSxkbV9yZWdpc3Rl
cgkgIyA8X3RtcCQxLjgyPnQzNAoubG9jIDIgMTc5CglibmUJJDI1LEwyMDYk
MwkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDE3OSwgPD50NzMKICNtYXJrX2Nh
bGwgY2FsbGVyX3NhdmVzLCByZWdzLCBhdHlwZXMobjY0LG42NCxuMzIsbjMy
KSwgcnR5cGVzKG4zMik7CiAjaW5zdHIKLmxvYyAyIDE4MQoJanNyCSQyNixm
cHJpbnRmCglicgkkMjYsRkFLRTQwCkZBS0U0MDoJbGRncAkkZ3AsMCgkMjYp
CSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMTgxLCByYWRkcihmcHJpbnRmKShQ
NjQpLCA8PnQ2MCwgPD50NzQsIDw+dDc1LCA8X3RtcCQxLjgyPnQzNCwgPF9y
ZXN1bHQkMS44Mj50MjcKICNpbnN0cgoJbGRhCSQxNiwyKCQzMSkJICNjbGFz
cyBkbW92ZSxkbV9jb25zdGFudAkgIyAyKFNJMzIpCiAjbWFya19jYWxsIGNh
bGxlcl9zYXZlcywgcmVncywgYXR5cGVzKG4zMiksIHJ0eXBlcygpOwogI2lu
c3RyCglvcgkkMzEsJDMxLCQzMQkgI2NsYXNzIGRtb3ZlLGRtX3JlZ2lzdGVy
CSAjIDw+dDYwCi5sb2MgMiAxODIKCWpzcgkkMjYsZXhpdAoJYnIJJDI2LEZB
S0U0MQpGQUtFNDE6CWxkZ3AJJGdwLDAoJDI2KQkgI2NsYXNzIHNvdXJjZQkg
IyBsaW5lIDE4MiwgcmFkZHIoZXhpdCkoUDY0KSwgPD50NjAsIDIoU0kzMikK
TDIwNiQzOgogI2luc3RyCiAjaW5zdHIKCWxkbAkkMjcsJDIuMiQyc3BpbGxf
cCArIDI0KCRzcCkJICNjbGFzcyBkbW92ZSxkbV9yZXN0b3JlCSAjIDxfciQx
LjgyPnQ1NgoJY3B5cwkkZjMxLCRmMzEsJGYzMQkjIHBhZAoJICMgc3RhbGwg
CTIKICNpbnN0cgoubG9jIDIgMTc1CglhZGRsCSQyNywxLCQyNwkgI2NsYXNz
IHNvdXJjZQkgIyBsaW5lIDE3NSwgPF9yJDEuODI+dDU2LCA8X3IkMS44Mj50
NTYsIDEoU0kzMikKCXN0bAkkMjcsJDIuMiQyc3BpbGxfcCArIDI0KCRzcCkJ
ICNjbGFzcyBkbW92ZSxkbV9zcGlsbAkgIyA8X3IkMS44Mj50NTYKICNpbnN0
cgoJYnIJJDMxLEwyMDQkMwoJYmlzCSQzMSwkMzEsJDMxCSMgcGFkCiAjbWFy
a190cmFjZSA1OwpMMjA1JDM6CiAjaW5zdHIKLmxvYyAyIDIwNQoJbGRhCSQx
NixfJDFTVFJJTkdQQUNLRVQuNQkgI2NsYXNzIHNvdXJjZQkgIyBsaW5lIDIw
NSwgPD50NjgsIDw+dDYzLCBhZGRyKF8kMVNUUklOR1ZBUi41KShQNjQpCgls
ZGwJJDE3LCQyLjIkMnNwaWxsX3AgKyA4KCRzcCkJICNjbGFzcyBkbW92ZSxk
bV9yZXN0b3JlCSAjIDxfcmVzdWx0JDEuODI+dDI3CiAjbWFya19jYWxsIGNh
bGxlcl9zYXZlcywgcmVncywgYXR5cGVzKG42NCxuMzIpLCBydHlwZXMobjMy
KTsKICNpbnN0cgoJb3IJJDMxLCQzMSwkMzEJICNjbGFzcyBkbW92ZSxkbV9y
ZWdpc3RlcgkgIyA8PnQ2MAoubG9jIDIgMjA1Cglqc3IJJDI2LHByaW50ZgoJ
YnIJJDI2LEZBS0U0NwpGQUtFNDc6CWxkZ3AJJGdwLDAoJDI2KQkgI2NsYXNz
IHNvdXJjZQkgIyBsaW5lIDIwNSwgcmFkZHIocHJpbnRmKShQNjQpLCA8PnQ2
MCwgPD50NjgsIDxfcmVzdWx0JDEuODI+dDI3CgkgIyBzdGFsbCAJMQogI2lu
c3RyCglvcgkkMzEsJDMxLCQxNgkgI2NsYXNzIGRtb3ZlLGRtX2NvbnN0YW50
CSAjIDAoU0kzMikKCWNweXMJJGYzMSwkZjMxLCRmMzEJIyBwYWQKICNtYXJr
X2NhbGwgY2FsbGVyX3NhdmVzLCByZWdzLCBhdHlwZXMobjMyKSwgcnR5cGVz
KCk7CiAjaW5zdHIKCW9yCSQzMSwkMzEsJDMxCSAjY2xhc3MgZG1vdmUsZG1f
cmVnaXN0ZXIJICMgPD50NjAKLmxvYyAyIDIwOAoJanNyCSQyNixleGl0Cgli
cgkkMjYsRkFLRTQ4CkZBS0U0ODoJbGRncAkkZ3AsMCgkMjYpCSAjY2xhc3Mg
c291cmNlCSAjIGxpbmUgMjA4LCByYWRkcihleGl0KShQNjQpLCA8PnQ2MCwg
MChTSTMyKQoJICMgc3RhbGwgCTEKICNpbnN0cgoJbGRxCSQyNiwkMi4yJDJy
YXNfcCgkc3ApCSAjY2xhc3MgZG1vdmUsZG1fcmVzdG9yZQkgIyA8PnQ1OQoJ
b3IJJDMxLCQzMSwkMAkgI2NsYXNzIGRtb3ZlLGRtX2NvbnN0YW50CSAjIDAo
U0kzMikKCSAjIHN0YWxsIAkyCiAjbWFya19yZXR1cm4gcnR5cGVzKG4zMik7
CiAjaW5zdHIKLmxvYyAyIDIwOQoJbGRhCSRzcCwkMi4yJDJhdXRvX3NpemUo
JHNwKQoJcmV0CSQzMSwoJDI2KSwxCSAjY2xhc3Mgc291cmNlCSAjIGxpbmUg
MjA5LCA8PnQ2MCwgJDIuMiQyYXV0b19zaXplKEkzMiksIDw+dDU5CiAjbWFy
a190cmFjZSA2OwpMMjAxJDM6CiAjaW5zdHIKLmxvYyAyIDE0NgoJbGRxCSQx
OCwwKCQxNykJICNjbGFzcyBzb3VyY2UJICMgbGluZSAxNDYsIDw+dDksIDxf
YXJndiQxLjgxPnQ1MiwgMChJNjQpCi5sb2MgMiAxNDYKCWxkYQkkMTYsX2lv
YisxMTIJICNjbGFzcyBzb3VyY2UJICMgbGluZSAxNDYsIDw+dDgwLCA8PnQ2
MywgKGFkZHIoX19pb2IkMS4wKShQNjQpICsgMHg3MChJNjQpKShQNjQpCiAj
aW5zdHIKLmxvYyAyIDE0NgoJbGRhCSQxNyxfJDFTVFJJTkdQQUNLRVQuMgkg
I2NsYXNzIHNvdXJjZQkgIyBsaW5lIDE0NiwgPD50ODEsIDw+dDYzLCBhZGRy
KF8kMVNUUklOR1ZBUi4yKShQNjQpCgljcHlzCSRmMzEsJGYzMSwkZjMxCSMg
cGFkCiAjbWFya19jYWxsIGNhbGxlcl9zYXZlcywgcmVncywgYXR5cGVzKG42
NCxuNjQsbjY0KSwgcnR5cGVzKG4zMik7CiAjaW5zdHIKCW9yCSQzMSwkMzEs
JDMxCSAjY2xhc3MgZG1vdmUsZG1fcmVnaXN0ZXIJICMgPD50NjAKLmxvYyAy
IDE0NgoJanNyCSQyNixmcHJpbnRmCglicgkkMjYsRkFLRTQ5CkZBS0U0OToJ
bGRncAkkZ3AsMCgkMjYpCSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMTQ2LCBy
YWRkcihmcHJpbnRmKShQNjQpLCA8PnQ2MCwgPD50ODAsIDw+dDgxLCA8PnQ5
CgkgIyBzdGFsbCAJMQogI2luc3RyCi5sb2MgMiAxNDcKCXN1YmwJJDMxLDEs
JDE2CSAjY2xhc3Mgc291cmNlCSAjIGxpbmUgMTQ3LCA8PnQ4MiwgMChJNjQp
LCAxKFNJMzIpCgljcHlzCSRmMzEsJGYzMSwkZjMxCSMgcGFkCiAjbWFya19j
YWxsIGNhbGxlcl9zYXZlcywgcmVncywgYXR5cGVzKG4zMiksIHJ0eXBlcygp
OwogI2luc3RyCglvcgkkMzEsJDMxLCQzMQkgI2NsYXNzIGRtb3ZlLGRtX3Jl
Z2lzdGVyCSAjIDw+dDYwCi5sb2MgMiAxNDcKCWpzcgkkMjYsZXhpdAoJYnIJ
JDI2LEZBS0U1MApGQUtFNTA6CWxkZ3AJJGdwLDAoJDI2KQkgI2NsYXNzIHNv
dXJjZQkgIyBsaW5lIDE0NywgcmFkZHIoZXhpdCkoUDY0KSwgPD50NjAsIDw+
dDgyCgkgIyBzdGFsbCAJMQogI2luc3RyCglsZHEJJDE3LCQyLjIkMnNwaWxs
X3AgKyAzMigkc3ApCSAjY2xhc3MgZG1vdmUsZG1fcmVzdG9yZQkgIyA8X2Fy
Z3YkMS44MT50NTIKCW9yCSQzMSwkMzEsJDMxCSAjY2xhc3MgZG1vdmUsZG1f
cmVnaXN0ZXIJICMgPD50NjAKCSAjIHN0YWxsIAkxCiAjaW5zdHIKCWJyCSQz
MSxMMjAyJDMKCWJpcwkkMzEsJDMxLCQzMQkjIHBhZAoJLmVuZAoJLmV4dGVy
biBfaW9iCgkuZXh0ZXJuIER5Q1JUX1RhYmxlUG9pbnRlcnMKLnJkYXRhCgku
cXVhZAlpbnRlcnByZXRlciArIDB4MzU0LCBDUyQxICsgMHgwCgkucXVhZAlp
bnRlcnByZXRlciArIDB4M2I0LCBDUyQxICsgMHgxCgkucXVhZAlpbnRlcnBy
ZXRlciArIDB4NDU0LCBDUyQxICsgMHgyCgkucXVhZAlpbnRlcnByZXRlciAr
IDB4NmI0LCBDUyQxICsgMHgzCgkucXVhZAlpbnRlcnByZXRlciArIDB4Nzc0
LCBDUyQxICsgMHg5CgkucXVhZAlpbnRlcnByZXRlciArIDB4YTRjLCBDUyQx
ICsgMHhjCgkucXVhZAlpbnRlcnByZXRlciArIDB4YWE0LCBDUyQxICsgMHhl
CgkucXVhZAlpbnRlcnByZXRlciArIDB4YzdjLCBDUyQxICsgMHgxMAoJLnF1
YWQJaW50ZXJwcmV0ZXIgKyAweGVkMCwgQ1MkMSArIDB4MTIKCS5xdWFkCWlu
dGVycHJldGVyICsgMHgxMGYwLCBDUyQxICsgMHgxNAoJLnF1YWQJaW50ZXJw
cmV0ZXIgKyAweDEzOTQsIENTJDEgKyAweDE3CgkucXVhZAlpbnRlcnByZXRl
ciArIDB4MTQ4MCwgQ1MkMSArIDB4MWQKCS5xdWFkCWludGVycHJldGVyICsg
MHgxN2EwLCBDUyQxICsgMHgyMAoJLnF1YWQJaW50ZXJwcmV0ZXIgKyAweDE3
ZTAsIENTJDEgKyAweDIzCgkucXVhZAlpbnRlcnByZXRlciArIDB4MTg0Yywg
Q1MkMSArIDB4MjYKCS5xdWFkCWludGVycHJldGVyICsgMHgxOGE0LCBDUyQx
ICsgMHgyOAoJLnF1YWQJaW50ZXJwcmV0ZXIgKyAweDE5MzAsIENTJDEgKyAw
eDJlCgkucXVhZAlpbnRlcnByZXRlciArIDB4MWEwOCwgQ1MkMSArIDB4MmYK
CS5xdWFkCWludGVycHJldGVyICsgMHgxZjcwLCBDUyQxICsgMHgzMgoJLnF1
YWQJaW50ZXJwcmV0ZXIgKyAweDFmZTgsIENTJDEgKyAweDMzCgkucXVhZAlp
bnRlcnByZXRlciArIDB4MjAyOCwgQ1MkMSArIDB4MzYKCS5xdWFkCWludGVy
cHJldGVyICsgMHgyMDk0LCBDUyQxICsgMHgzOQoJLnF1YWQJaW50ZXJwcmV0
ZXIgKyAweDIwZDQsIENTJDEgKyAweDNkCgkucXVhZAlpbnRlcnByZXRlciAr
IDB4MjExNCwgQ1MkMSArIDB4NDMKCS5xdWFkCWludGVycHJldGVyICsgMHgy
MWU4LCBDUyQxICsgMHg0NgoJLnF1YWQJaW50ZXJwcmV0ZXIgKyAweDI1Mjgs
IENTJDEgKyAweDQ5CgkucXVhZAlpbnRlcnByZXRlciArIDB4MjU2OCwgQ1Mk
MSArIDB4NGMKCS5xdWFkCWludGVycHJldGVyICsgMHgyNWQ4LCBDUyQxICsg
MHg0ZgoJLnF1YWQJaW50ZXJwcmV0ZXIgKyAweDI2MTgsIENTJDEgKyAweDUy
CgkucXVhZAlpbnRlcnByZXRlciArIDB4MjY1OCwgQ1MkMSArIDB4NTgKCS5x
dWFkCWludGVycHJldGVyICsgMHgyNmEwLCBDUyQxICsgMHg1ZgoJLnF1YWQJ
aW50ZXJwcmV0ZXIgKyAweDI2ZTQsIENTJDEgKyAweDY2CgkucXVhZAltYWlu
ICsgMHg1MCwgQ1MkMiArIDB4MAoJLnF1YWQJbWFpbiArIDB4YzQsIENTJDIg
KyAweDIK
---2141257447-93009857-886714361=:18674--

Date: Thu, 5 Feb 1998 14:49:24 -0800 (PST)
From: Markus Mock <mock@apex.cs.washington.edu>
To: spin-comp@apex.cs.washington.edu
Subject: BTA feedback changes checked in

The feedback can be turned off by setting the option 
P2DYC_bta_use_feedback_file to false, default is on (true).

When turned on, it creates a feedback file named <source-file-name>.fbk
where high-level feedback on the application of BTA rules is given.

A sample (for binary) looks as follows:
line 16:
Temp t352 (_n$1.1) kept static in FilterStaticVars because there are other
temps
 derived from it, although temp t352 (_n$1.1) is not in lvs
line 18:
Temp t352 (_n$1.1) kept static in FilterStaticVars because there are other
temps
 derived from it, although temp t352 (_n$1.1) is not in lvs
line 19:
Temp t352 (_n$1.1) kept static in FilterStaticVars because there are other
temps
 derived from it, although temp t352 (_n$1.1) is not in lvs
line 20:
Loosing the following temps at this merge because they are discordant:
{t352 (_n$1.1)}
line 26:
Temp t433 (_p$1.71) becomes dynamic because one of its source root
variables is 
(possibly) assigned here, potential source roots:
{_u$1.2,_r$1.2}


	-- Markus


Date: Fri, 6 Feb 1998 14:08:52 -0800 (PST)
From: Markus Mock <mock@apex.cs.washington.edu>
To: spin-comp@apex.cs.washington.edu
Subject: Submission  589223649 to PLDI 98 (fwd)

Reviews are in.


	-- Markus

---------- Forwarded message ----------
Date: Fri, 6 Feb 1998 16:01:55 -0600 (CST)
From: Keith Cooper <keith@cs.rice.edu>
To: cooper@cs.rice.edu, mock@cs.washington.edu
Subject: Submission  589223649 to PLDI 98


Dear  Markus Mock:


Here are the reviews for your paper

 DyC: An Expressive, Annotation-Based Dynamic 

which was received with confirmation  589223649 for
consideration at PLDI '98

Each paper was read by at least three reviewers.
In most cases, each reader submitted a written review.

Again, the committee and I thank you for your
submission to PLDI 98.


   Sincerely
   Keith D. Cooper, Program Chair

---------------------------------

Nice work.  But is there enough of an increment over the previous paper?

As a measurement paper, it seems a bit premature.  A number of optimizations
likely to affect the measurements have not yet been implemented.  Are
"register actions" included in the measurements?

////////////////////////////////////////////////////////////////////////////


The paper describes a dynamic compiler for a variant of C extended by 
annotations. This reviewer has a principal aversion against such annotations, 
and hence is probably biased. Nevertheless, it would have been much better if 
the paper had concentrated on the techniques employed in the compiler, rather 
than the effect of these techniques. The comparisons with tick C and Tempo are 
only of limited value, due to the different underlying language constructs. 
Also, the fundamental problem remains of annotating the benchmark programs in 
such a manner that a fair comparison ensues in the first place. For the 
programmer, using these annotations requires a very deep understanding of the 
underlying implementation of the system. So, how does annotating a program 
differently influence performance?

////////////////////////////////////////////////////////////////////////////


This paper reports preliminary experimental results with a dynamic
compiler for C.  The compiler takes a declarative approach, using a
small number of programmer-supplied annotations to decide which code
to compile at run time.  The authors have previously published the
design of the compiler; this paper contributes experimental data from
an implementation of that design.  The most striking fact about the
compiler is that it can handle a large application (emulator for the
MIPS instruction set) that would be intractable with other dynamic
compilers.  The compiler also provides more control over dynamic
compilation then other declarative systems (without making the
programmer do everything as does `C). The optimization is not quite
competitive with `C, but this situation may be improved by the time
final papers are due.

I'd like some more insight into what programmers would do with the
ability to control dynamic-compilation policies.  I'm willing to
stipulate that more control can't hurt (when defaults are good), but
I'd like some examples that would show how this control might be used
in real situations.  I'd also like to see some data that show what
sort of improvements you can get by controlling the policies, since
you must have a deep understanding of them.

It's clear from your introduction why the imperative approach is
unpalatable for large programs.  What's not clear is why your approach
succeeds with imips where Tempo does not.  Is there something about
the approach of Tempo that won't work, or is it an accident of the
implementation?  From your extensive comparison of DyC with Tempo,
which factors seem to contribute to your ability to handle a more
ambitious program?  In other words, what's really important about this
work?  The answers to these questions should probably appear in the
conclusion of your paper.

*How* does DyC's design support separate compilation?  This support
seems crucial for using dynamic compilation on real programs, which I
see as the major benefit to your approach.

Why would it be challenging to support inline expansion of called
procedures? 

At the end of section 3, recapitulate the idea of register actions so
we can understand the improvement in Figure 5 without having to dig
out your 1996 paper.

You report the median counts for ten executions; what's the variance?

In section 3.2, it might be worth showing the hoary old picture of
static and dynamic compilation vs number of iterations, so readers can
visualize the overhead as the difference between the intercepts of two
lines and the asymptotic speedup as the ratio of their slopes.

Does the ability to support unstructured control flow matter?  How
hard would it be to add such support to Tempo?

Briefly explain the difference between tcc's icode and vcode back
ends, and explain your approach to back ends, so we can understand why
vcode is the right comparison.

On page 10, when you refer to the unimplemented improvements,
recapitulate the list on page 7 (or whatever the improvements are).

I didn't get much from the table of `Dynamic Compilation Features'.
What conclusions (if any) should I draw?  Also, I would have liked to
see what features found only in `C give it the superior speedup shown
in the previous table.

Reference [Jones et al 98] is missing.

Use present tense, not future tense, to refer to things described
later in the paper.

Table numbers don't match the numbers in the text.

////////////////////////////////////////////////////////////////////////////




Date: Fri, 6 Feb 1998 14:18:28 -0800 (PST)
From: Markus Mock <mock@apex.cs.washington.edu>
To: Brian Grant <grant@cs>, spin-comp-archive@cs
cc: Markus Mock <mock@cs>
Subject: new caching context

Brian,

I am going ahead and turn off the source root filtering, i.e. keep all
derived temps in staticVarInfo. I'll add an additional dirty bit in the
staticVarInfo that will be false if the the temp is a pure function of
annotated source variables (and hence does not have to be included in the
context), true iff potentially one source root was changed after deriving
the temp. 
As far as I can see, that should be all that you need to know to decide if
a temp needs to be included in the context or not. Any complications?

	-- Markus


To: Markus Mock <mock@apex.cs.washington.edu>
cc: spin-comp-archive@cs
Subject: Re: new caching context 
Date: Sun, 08 Feb 1998 10:34:59 PST
From: Brian Grant <grant@thistle.cs.washington.edu>

>> I am going ahead and turn off the source root filtering, i.e. keep all
>> derived temps in staticVarInfo. I'll add an additional dirty bit in the
>> staticVarInfo that will be false if the the temp is a pure function of
>> annotated source variables (and hence does not have to be included in the
>> context), true iff potentially one source root was changed after deriving
>> the temp. 
>> As far as I can see, that should be all that you need to know to decide if
>> a temp needs to be included in the context or not. Any complications?

So, the dirty bit will be true if either

1) The source root is redefined, or
2) The source root is removed from the division.

Is this right?  Can you keep a set of these called Freebies?  After a unit
boundary, I'll have to subtract the Freebies from the set of run-time
constants (or do something similar).  I'll maintain my own set of which ones
I've subtracted.  However, there are tricky points, like freebies can have
their dirty bits turned off if they are redefined again.  Is it possible
for a freebie to be redefined and made dirty again at the same program point?
If so, I may need an additional way to tell that a freebie became dirty at a
particular program point (set or bit).  Combined with clustering, this may
mean I need to do more substantial (re-)analysis.  I'll try to think about
how we can make the BTA more incremental.

--Brian

To: spin-comp@cs
Subject: Re: PLDI reviews
Date: Sun, 08 Feb 1998 11:23:12 PST
From: Brian Grant <grant@thistle.cs.washington.edu>

Comments on some of the reviewers' comments.  It looks like only the last
reviewer read the paper as we intended, but the second reviewer had one good
point.

>> For the 
>> programmer, using these annotations requires a very deep understanding of the 
>> underlying implementation of the system. So, how does annotating a program 
>> differently influence performance?

I think this is good point and should be discussed in more detail (e.g., what
happens if safe vs. unsafe annotations are used and which safe annotations
could be automatically converted to unsafe ones).

>> I'd like some more insight into what programmers would do with the
>> ability to control dynamic-compilation policies.  I'm willing to
>> stipulate that more control can't hurt (when defaults are good), but
>> I'd like some examples that would show how this control might be used
>> in real situations.  I'd also like to see some data that show what
>> sort of improvements you can get by controlling the policies, since
>> you must have a deep understanding of them.

Virtually the same point as above.  A lazy version of binary might have helped.

>> It's clear from your introduction why the imperative approach is
>> unpalatable for large programs.  What's not clear is why your approach
>> succeeds with imips where Tempo does not.  Is there something about
>> the approach of Tempo that won't work, or is it an accident of the
>> implementation?  From your extensive comparison of DyC with Tempo,
>> which factors seem to contribute to your ability to handle a more
>> ambitious program?  In other words, what's really important about this
>> work?  The answers to these questions should probably appear in the
>> conclusion of your paper.

I think this is a good point.  What do we think would be difficult for Tempo
to adopt?  Why doesn't Tempo, for example, have intraprocedural polyvariant
specialization and division?  What would happen if we specialized all static
variables polyvariantly (as would happen without policies)?

>> *How* does DyC's design support separate compilation?  This support
>> seems crucial for using dynamic compilation on real programs, which I
>> see as the major benefit to your approach.

Perhaps we should increase the priority of implementing the function
annotations?  They may be of use in OpenGL.

>> Why would it be challenging to support inline expansion of called
>> procedures? 

Run-time inlining?  Did we discuss that at all?

>> At the end of section 3, recapitulate the idea of register actions so
>> we can understand the improvement in Figure 5 without having to dig
>> out your 1996 paper.

Another good point.

>> You report the median counts for ten executions; what's the variance?

We can compute that easily.  Do people usually report it?

>> Does the ability to support unstructured control flow matter?  How
>> hard would it be to add such support to Tempo?

Maybe we should work this out for mipsi (or kill the point).

>> Briefly explain the difference between tcc's icode and vcode back
>> ends, and explain your approach to back ends, so we can understand why
>> vcode is the right comparison.

Ok.

>> I didn't get much from the table of `Dynamic Compilation Features'.
>> What conclusions (if any) should I draw?  Also, I would have liked to
>> see what features found only in `C give it the superior speedup shown
>> in the previous table.

More on this would definitely be good to add.



None of the reviewers directly asked for what I expected: more applications.

Instead, they seemed to want more understanding of why we did as well as
we did and why we succeeded with mipsi.  That is a valid point.  I think
Matthai has said that he gets little intuition about what is important in
our system from our (expanded) PEPM paper.  I would agree, and extend that
to PLDI submission as well.  We claimed that all of DyC's (many) features
were necessary for mipsi.  We relied on the example to show _how_ the
features could be used, but we did not discuss why they were required, or
what could be done without various features, if anything.

I think this shows that we need more experience with the system and we need
to play around with the policies more, and determine what _is_ really
important.

I'm interested in doing some of this for my thesis.  For example, it might be
worth it to find a way to apply Erosa & Hendren's transformation to determine
whether handling unstructured code is important or not.  Maybe we can use the
SUIF front end to do it automatically (without implementing it ourselves)?

Of course, if we do all of these things, the paper will be a different one than
we had hoped to publish, and be more along the lines of what I was planning
to work on this year.  Is there a venue for the paper we submitted?  What
changes should we make, given the comments?

-- Should we include more about the design, but try to give more understanding
   and less detail than the PEPM paper?
-- Should we add a discussion about the unsafe annotations we used and why
   it was a fair comparison?
-- Should we change the Tempo discussion to include just the feature
   differences that we found to be really important, describe whether Tempo
   could easily adopt the feature, etc.?
-- More discussion about the speedups we got, similar to what is on the web
   page
-- A lazy version of binary

Anything else?

I would not like to present a detailed study of applying our different
policies and of the importance of other aspects of our system (e.g.,
reachability analysis or handling unstructured code), if we plan to submit
to somewhere other than PLDI.  Any other opinions?

--Brian


To: spin-comp@thistle.cs.washington.edu
Subject: reminding people what I want to work on
Date: Sun, 08 Feb 1998 12:14:00 PST
From: Brian Grant <grant@thistle.cs.washington.edu>

As a group, I think we should assess how our current support for static data
structures (or lack thereof) affects:

1) Expressivity (e.g., we don't permit specialization-time stores)
2) Usability (e.g., how far can syntactic sugar take us?)
3) Performance (e.g., cache effects)

An older version of what I had planned to work on this year is described
under the "Research Agenda" bullet on our internal home page.  Here is a
summary.  


(SUMMARY -- SHORT)
We have designed a complex dynamic-compilation system.  I want to understand
what features and optimizations are important.  This will involve both turning
features and optimizations on and off and also annotating programs in several
different ways.  (I'll coordinate with Matthai to minimize overlap with his
architectural study.)

On the implementation side, I would like to implement the rest of the current
design, add run-time inlining, tweak the BTA, and add a few new optimizations.


(DETAILS -- LONG)

Examples of things I would like to study:

-- Importance of ascribing weak policies to derived run-time constants; ease
   of control over costs and code growth for different derived policies
-- Performance benefit of unsafe annotations; when can safe annotations be
   converted to unsafe ones?
-- What benefit do we receive from reachability analysis?
-- "    "       "  "  "       "    direct handling of unstructured code?
-- "    "       "  "  "       "    unit-boundary clustering?
-- "    "       "  "  "       "    linearization?
-- How useful is demand-driven specialization:
	- For avoiding non-termination?
	- For controlling aggressive code generation (such as in binary)?

Etc.

Things that remain to be implemented:

-- One-time lazy edges
-- Single run-time predecessor optimizations (now that reachability analysis is
   implemented)
-- Unit-boundary clustering; this will require improving the interface between
   the BTA and GEgen.  Markus has already started working on this to allow us
   to keep derived TEMPs with changed or evicted SourceRoots in the
   run-time-constants set (StaticVarInfo) at least until unit boundaries.
-- Unit linearization
-- Interprocedural specialization (function annotations)
-- Run-time inlining
-- I'd like to look at automatically deducing when it is safe to remove cache
   checks and lazy points so that our safe annotations can be used most of
   the time
-- PromoteOneUncheckedEager for eliminating MayDefs
-- Faster caching implementation
-- Other caching optimizations (e.g., the fix to the ms CacheAllUnchecked
   problem, and relative caching in general)
-- CacheOne
-- More realistic and robust memory management

--Brian


To: spin-comp@thistle.cs.washington.edu
Subject: note about static data structures
Date: Sun, 08 Feb 1998 12:16:40 PST
From: Brian Grant <grant@thistle.cs.washington.edu>

The beginning of my previous e-mail was intended to be a separate message.

--Brian

-------------

As a group, I think we should assess how our current support for static data
structures (or lack thereof) affects:

1) Expressivity (e.g., we don't permit specialization-time stores)
2) Usability (e.g., how far can syntactic sugar take us?)
3) Performance (e.g., cache effects)

-------------

Date: Mon, 9 Feb 1998 14:29:08 -0800 (PST)
From: Markus Mock <mock@apex.cs.washington.edu>
To: Brian Grant <grant@thistle.cs.washington.edu>
cc: spin-comp-archive@cs
Subject: Re: new caching context 

> 
> 1) The source root is redefined, or
this is implemented
> 2) The source root is removed from the division.
this is easy to add .


Why should we have two sets? Everything is just in StaticVars, those that
are free have the dirty bit off (false).

> Is this right?  Can you keep a set of these called Freebies?  After a unit
> boundary, I'll have to subtract the Freebies from the set of run-time
> constants (or do something similar).  I'll maintain my own set of which ones
> I've subtracted.  However, there are tricky points, like freebies can have
> their dirty bits turned off if they are redefined again.  Is it possible
> for a freebie to be redefined and made dirty again at the same program point?
> If so, I may need an additional way to tell that a freebie became dirty at a
> particular program point (set or bit).  Combined with clustering, this may
> mean I need to do more substantial (re-)analysis.  I'll try to think about
> how we can make the BTA more incremental.
> 


At each program point we define just one temp, all temps for which any 
source root may have been changed by that definition is made dirty. A temp
that corresponds to an annotated var can always be clean since it is
always in the context.
I think that should handle all the cases.


	-- Markus


Date: Mon, 9 Feb 1998 16:55:52 -0800 (PST)
From: chambers@klamath (Craig Chambers)
To: spin-comp@cs, cecil@cs
Subject: POPL'92?

Did I loan my POPL'92 to any of you?

-- Craig

Date: Tue, 10 Feb 1998 00:33:18 -0800 (PST)
From: "Markus U. Mock" <mock@cs.washington.edu>
To: Matthai Philipose <matthai@cs.washington.edu>,
cc: Markus Mock <mock@cs.washington.edu>
Subject: stitcher bug

Matthai,

there appears to be a bug in the stitcher: although there is no (static)
loop unrolling going on in the interpreter example, the dynamically
generated code contains that extra spurious mull that serves no purpose.
The same thing happens if the program is changed to use ADD instead, then
we produce a spurious ADD. The pms file has just one MUL for each case
arm, so the stitcher should not produce two. I suppose there is some
subtle bug (or maybe not so subtle) that causes the instruction to be
stitched twice, once with a bogus target register. Maybe some counter is
not advanced correctly? 

Could you please take a look asap?

Thanks.




	-- Markus 



Date: Tue, 10 Feb 1998 07:48:04 -0800
From: eggers@yakima (Susan Eggers)
To: spin-comp@cs
Subject: Patrick Jones
Cc: pljones@u.washington.edu

from OTT is coming to our meeting today to talk about patenting,
the process, what is appropriate, and related issues.

Susan

To: eggers@yakima (Susan Eggers)
cc: spin-comp@cs
Subject: Re: Patrick Jones 
Date: Tue, 10 Feb 1998 08:40:54 PST
From: Brian Grant <grant@thistle.cs.washington.edu>

I thought it might help to take a look at a recent software patent.  Here a
sort overview of two patents on Internet routing:

http://dworkin.wustl.edu/~varghese/PAPERS/lookups

The high-level ideas are very simple, but there are some tricky details that
(potentially) make these reasonable and useful patents.  Two big routing
companies have already signed license aggreements.

About licensing:
>> The Washington University licensing policy has been to price the
>> schemes fairly cheaply (in the low hundred thousands) so that it will
>> not be an obstacle for companies to use the technology, rather than
>> working around the patents.  The policy also allows startups to pay in
>> installments and will potentially allow free licensing for reasearch
>> and other non-commercial use.  The license includes access to software
>> packages written by graduate student V. Srinivasan.

--Brian

Date: Tue, 10 Feb 1998 11:43:42 -0800 (PST)
From: Markus Mock <mock@apex.cs.washington.edu>
To: Matthai Philipose <matthai@cs.washington.edu>
cc: Markus Mock <mock@cs>, Matthai Philipose <matthai@cs>,
Subject: Re: stitcher bug 

Is there an easy way (command line switch) to turn that speculation off in
general? If so, in that particular case we could check how much that
impacts performance, in this case I suspect it would actually improve
performance since we are punished heavily by that dumb wasted speculative
instruction.


	-- Markus

On Tue, 10 Feb 1998, Matthai Philipose wrote:

> Markus,
> The extra mull/add is not a readily fixable bug. Basically, this is an effect that I'd noted in my quals, and am wondering whether to include in the "architectural" study: the extra mull/add is a result of (mis-)speculation above the static switch. One fix for this is to avoid speculation above static branches; of course, this places more of a stress on run-time scheduling for statically scheduled processors like the 21164.
> 			Matthai
> 
> > Matthai,
> > 
> > there appears to be a bug in the stitcher: although there is no (static)
> > loop unrolling going on in the interpreter example, the dynamically
> > generated code contains that extra spurious mull that serves no purpose.
> > The same thing happens if the program is changed to use ADD instead, then
> > we produce a spurious ADD. The pms file has just one MUL for each case
> > arm, so the stitcher should not produce two. I suppose there is some
> > subtle bug (or maybe not so subtle) that causes the instruction to be
> > stitched twice, once with a bogus target register. Maybe some counter is
> > not advanced correctly? 
> > 
> > Could you please take a look asap?
> > 
> > Thanks.
> > 
> > 
> > 
> > 
> > 	-- Markus 
> > 
> > 
> > 
> 
> 


To: spin-comp@thistle.cs.washington.edu
Subject: interesting detail about Tempo 
Date: Tue, 10 Feb 1998 16:03:22 PST
From: Brian Grant <grant@thistle.cs.washington.edu>

In doing the research for my general exam, I discovered an interesting
detail about Tempo.  Due to a detail in their implementation, they can't
specialize recursive functions.  This also means they definitely can't do
multi-way unrolling of any kind.

--Brian

Date: Tue, 10 Feb 1998 16:35:55 -0800 (PST)
From: Markus Mock <mock@apex.cs.washington.edu>
To: Matthai Philipose <matthai@cs>, spin-comp-archive@cs
cc: Markus Mock <mock@cs>
Subject: mull

I checked it again: reagardless of which emit gets deleted in the .s file,
there are always two mull's in the dynamic code. If you want to take a
look, I checked in the current version of interpreter-regs in cvs or go to
my directory
/afs/cs.washington.edu/project/dyncomp/mock/DyC/regression/interpreter-regs


	-- Markus


Date: Thu, 12 Feb 1998 15:54:14 -0800
From: eggers@yakima (Susan Eggers)
To: spin-comp@cs
Subject: new hardware

Melody is going on a shopping spree and wants to know what you need
in the way of compiling simulation engines and disks.  Can you tell 
me how many are on your wish list.  I'm assumning max memory on
the machines.

If you want to move from AFS, keep that in mind when ordering. 	

Susan

Date: Thu, 12 Feb 1998 17:32:24 -0800 (PST)
From: Markus Mock <mock@apex.cs.washington.edu>
To: spin-comp@apex.cs.washington.edu
Subject: Register allocation revisited

In a nutshell: we get a speedup improvement of a factor of 1.28 to 2.00
compared to the original interpreter where no register allocation is done,
to a total speedup of up to 15.55.

I ran our little interpreter example again, with the new merger (no
spurious branches now) and (static) code generation from an editied .s
file to get rid of the unnecessary speculative operation.

Since mull is an instruction with big latency, I also had the interpreter
interpret the factorial program with the multiply replaced by an add,
computing the sum from 1 .. n (no one would compute the sum that way
but it's good enough for a comparison).

So here's the breakdown:
be = breakeven which is quite bad since I couldn't compile the program
with the worklist peeling option: it would fail the famous assertion in
the instruction scheduler (I played with a number of switches but to no
avail)

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
		NO REG-ALLOC		REG-ALLOC
ADD
	n	speedup	be 		speedup	be 	improvement factor
	
	10000	8.85	3		15.55	2	1.75
	
	 1000	8.74	22		15.28	19	1.74
	
	  100	8.25	208		13.61	182	1.64
	
	   10	5.27	2028		 6.79	1062	1.28

MUL
	n	speedup	be 		speedup	be 	improvement factor
	
	10000	4.98	3		 9.95	2	1.99

	 1000	4.91	34		 9.87	19	2.00

	  100	4.77	246		 9.20	179	1.92

	   10	3.79	2087		 5.83	1740	1.53


[Note: The computed values for n! for n>10 are of course bogus, as the add
for n=10000 due to the overflow.]

This is the code that's generated at run time from the edited assembler
file:

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
	ldl	t1,	368(sp)			
	ldl	v0,	336(sp)			
	ldl	t0,	344(sp)			
	ldq	t8,	376(sp)			
	lda	v0,	1(zero)			
	lda	t0,	0(zero)			
72:	fnop					
	or	t0,	zero,	t12		
	cmpeq	t1,	t12,	t12		
	bne	t12,	0x140013c70	<DyCRT_CodeSpace+124>		
	fnop					
	fnop					
	or	v0,	zero,	t12		
	or	t1,	zero,	t11		
	mull	t11,	t12,	v0
	fnop					
	or	t1,	zero,	t12		
	lda	t1,	-1(t12)			
	br	0x140013c38	<DyCRT_CodeSpace+72>			
124:	ldq	ra,	128(sp)			
	fnop					
	lda	sp,	448(sp)			
	ret	zero,	(ra),	1		

for this interpreted program:

     LI r31, #1             # r1 = 1
     LI r2, #0              # r2 = 0
 L0: BE r1,r2, L1           # if r1 == r2 goto L1
(*)  MUL r31, r1, r31       # r31 = r31 * r1
     SUBI r1,r1,#1          # r1 = r1 - 1
     JUMP L0                # goto L0
 L1: RET                    # return result in r31

(*) respectively ADD.


	-- Markus


Date: Tue, 17 Feb 1998 14:34:50 -0800 (PST)
From: chambers@klamath (Craig Chambers)
To: spin-comp@cs
Subject: DSL/run-time specialization


----- Begin Included Message -----

From Charles.Consel@irisa.fr  Tue Feb 17 02:34:09 1998
Delivery-Date: Tue, 17 Feb 1998 02:34:09 PST
Sender: Charles.Consel@irisa.fr
Date: Tue, 17 Feb 1998 11:33:34 +0100
From: Charles Consel <Charles.Consel@irisa.fr>
X-Mailer: Mozilla 3.0 (X11; I; SunOS 4.1.4 sun4m)
MIME-Version: 1.0
To: chambers@cs.washington.edu, eggers@cs.washington.edu
Subject: DSL/run-time specialization
Content-Transfer-Encoding: 7bit

Hi,

I thought you might be interesting in our latest work on
Domain-Specific Languages, more specifically, on a DSL for Active
Networks.

- We have extended a functional DSL developed by UPenn to widen its
  applicability.

- We have defined critical properties which can be determined from
  programs written in this language.  

- Finally, we have done an exciting application of run-time
  specialization: we specialize the interpreter (a 5,000-line program)
  at RUN TIME. Actually, we get performance comparable to an
  equivalent Java program. Moreover, the run-time aspect of
  specialization gives us the functionality of a Just-In-Time
  compiler, but for the price of an portable interpreter. This work
  was done using Tempo.

Here is the location of this paper if you're interested.

URL:
http://www.irisa.fr/EXTERNE/projet/lande/consel/papers/planp-bridge.ps.gz


Best regards,

Charles

-- 
---------------------------------------------------------------
Charles Consel              | University of Rennes / Irisa 
 consel@irisa.fr            | Campus Universitaire de Beaulieu
 Phone: (33) 2 99 84 74 10  | 35042 Rennes Cedex
 Fax:   (33) 2 99 84 71 71  | France
---------------------------------------------------------------
  URL: http://www.irisa.fr/compose/
---------------------------------------------------------------


----- End Included Message -----


Date: Wed, 18 Feb 1998 19:56:50 -0800
From: eggers@yakima (Susan Eggers)
To: spin-comp@cs
Subject: fyi


----- Begin Included Message -----

From bershad@appliant.com Wed Feb 18 19:34:59 1998
To: "'egs@cs.washington.edu'" <egs@cs.washington.edu>
Cc: "'eggers@cs.washington.edu'" <eggers@cs.washington.edu>
Subject: Hot Spot Compiler
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1457.3)
Content-Type: application/octet-stream; name=" A new breed of virtual machine - Jav...url"
Content-Disposition: attachment;
	filename=" A new breed of virtual machine - Jav...url"
Content-Length: 88
X-Lines: 2
Status: RO

[InternetShortcut]
URL=http://www.javaworld.com/javaworld/jw-03-1998/jw-03-hotspot.html


----- End Included Message -----


To: spin-comp@franklin.cs.washington.edu
Subject: Re: fyi [Article on HotSpot VM]
Date: Wed, 18 Feb 1998 20:16:47 PST
From: Matthai Philipose <matthai@franklin.cs.washington.edu>

Seems to me we should be able to approach this kind of performance on interpreters with clever use of run-time feedback to trigger conditional specialization, run-time inlining, and register allocation/actions. I wonder about scheduling, though... the fact that HotSpot works as well as statically optimizing C++ compilers means scheduling doesn't matter too much? I guess we could do the simple experiment of turning on/off scheduling on a new Sun and seeing if it makes a difference.

My favorite line was:
" At present, the system uses a very minimal heuristic [to decide what to munge] that does not involve any sort of artificial intelligence."

             Matthai


> 
> ----- Begin Included Message -----
> 
> >From bershad@appliant.com Wed Feb 18 19:34:59 1998
> To: "'egs@cs.washington.edu'" <egs@cs.washington.edu>
> Cc: "'eggers@cs.washington.edu'" <eggers@cs.washington.edu>
> Subject: Hot Spot Compiler
>
> URL=http://www.javaworld.com/javaworld/jw-03-1998/jw-03-hotspot.html
> 
> 
> ----- End Included Message -----
> 
> 


Date: Thu, 19 Feb 1998 09:49:53 -0800 (PST)
From: chambers@klamath (Craig Chambers)
To: spin-comp@cs
Subject: Re: fyi [Article on HotSpot VM]

I just skimmed the article, and it's really content-free and
over-hyped.  Don't believe any claims about "as fast as C++" because
they don't do any reasonable benchmarking.  (The linked article about
performance of JITs vs.  C++ is terrible.)  The technology in HotSpot
is clearly exactly Urs Hoelzle's Self-93 thesis work, with a new
front-end and non-trivial support for threads; the compiler & GC are
the same as the Self-93 system.

-- Craig


> From matthai@franklin.cs.washington.edu  Wed Feb 18 20:16:49 1998
> Delivery-Date: Wed, 18 Feb 1998 20:16:50 PST
> To: spin-comp@franklin.cs.washington.edu
> Subject: Re: fyi [Article on HotSpot VM]
> Reply-to: Matthai Philipose <matthai@cs.washington.edu>
> Mime-Version: 1.0
> Date: Wed, 18 Feb 1998 20:16:47 PST
> From: Matthai Philipose <matthai@franklin.cs.washington.edu>
> 
> Seems to me we should be able to approach this kind of performance on interpreters with clever use of run-time feedback to trigger conditional specialization, run-time inlining, and register allocation/actions. I wonder about scheduling, though... the fact that HotSpot works as well as statically optimizing C++ compilers means scheduling doesn't matter too much? I guess we could do the simple experiment of turning on/off scheduling on a new Sun and seeing if it makes a difference.
> 
> My favorite line was:
> " At present, the system uses a very minimal heuristic [to decide what to munge] that does not involve any sort of artificial intelligence."
> 
>              Matthai
> 
> 
> > 
> > ----- Begin Included Message -----
> > 
> > >From bershad@appliant.com Wed Feb 18 19:34:59 1998
> > To: "'egs@cs.washington.edu'" <egs@cs.washington.edu>
> > Cc: "'eggers@cs.washington.edu'" <eggers@cs.washington.edu>
> > Subject: Hot Spot Compiler
> >
> > URL=http://www.javaworld.com/javaworld/jw-03-1998/jw-03-hotspot.html
> > 
> > 
> > ----- End Included Message -----
> > 
> > 
> 
> 

Date: Thu, 19 Feb 1998 14:46:03 -0800
From: eggers@yakima (Susan Eggers)
To: levy@cs, eggers@yakima, jlo@cs, sparekh@cs, dewey@cs, spin-comp@cs
Subject: noether
Cc: burr@yakima

The long-term solution for noether's replacement/repair is complicated
and requires rethinking purchases.  I can't to do this until after the
affiliates meeting.  No suprise there.

So the fix that is in place now: no noether, disk on another CPU is
going to stay, hopefully, until after the meeting.

See Nancy's note below.

Susan


----- Begin Included Message -----

From burr@aspen Thu Feb 19 14:37:13 1998
To: eggers@yakima
Subject: Re: noether
Content-Length: 271
X-Lines: 12
Status: RO

> Do we have a temporary solution that could be in place until the
> affiliates meeting is over, and then I'll deal with this in a
> serious manner?

Sure, unless either/or

	something else dies
	backup tapes begin overflowing

We'll hope neither of these occur.

thanks


----- End Included Message -----


Date: Mon, 23 Feb 1998 16:17:29 -0800 (PST)
From: Markus Mock <mock@apex.cs.washington.edu>
To: Brian Grant <grant@cs>, spin-comp-archive@cs
cc: Markus Mock <mock@cs>
Subject: graph splitting routines

Brian,

how much of the routines necessary to duplicate the graph for multiple
divisions is already in place? Which of the functions that you wrote can I
use to build on?
Thanks.


	-- Markus


To: spin-comp@franklin.cs.washington.edu
Subject: Practice talk in chateau conference room?
Date: Tue, 24 Feb 1998 14:16:05 PST
From: Matthai Philipose <matthai@franklin.cs.washington.edu>

Hi all,
I've reserved the Chateau conference room from 2:30-3:30  for the practice talk. Let's all meet at the conference room at 2:30.
			Matthai

Date: Mon, 2 Mar 1998 11:52:44 -0800 (PST)
From: chambers@klamath (Craig Chambers)
To: cecil@cs, spin-comp@cs
Subject: Call for applications: 1998 Interns program/SUN Processor Architecture and Performance Software

FYI.

----- Begin Included Message -----

From William.Bryant@Eng.Sun.COM  Mon Mar  2 08:50:20 1998
Delivery-Date: Mon, 02 Mar 1998 08:50:21 PST
Date: Mon, 2 Mar 1998 08:49:49 -0800 (PST)
From: William Bryant <William.Bryant@Eng.Sun.COM>
Reply-To: William Bryant <William.Bryant@Eng.Sun.COM>
Subject: Call for applications: 1998 Interns program/SUN Processor Architecture and Performance Software
To: interns98@cray4.Eng.Sun.COM
Cc: arch-rec@cray4.Eng.Sun.COM
MIME-Version: 1.0
Content-MD5: 6t9f0xc5IAba5v/sNXdATA==
X-Mailer: dtmail 1.1.0 CDE Version 1.1 SunOS 5.5.1 sun4m sparc 


Greetings:

This note comes to you from SUN's Processor Architecture and
Performance Software Group, which is responsible for advanced
development of SPARC and Java processor architectures, Java Virtual
Machines, and compiler optimization and performance tuning for SPARC and
Java processors.  This also includes architecture tools and multimedia
library development.  You are receiving this message because we find
your academic work to be a good match with our research and development
needs.

We are currently looking for graduate student interns to staff our 1998
internship program.  Successful candidates will have an opportunity to
work on fun projects at the company that invented Java, and is the only
remaining major computer vendor with a roadmap to compete with Intel in
high performance CPU design!

Please encourage your students to apply quickly, as we have established
a cut-off date of 13 March 1998 for accepting applications.  All
resumes should be submitted by email to Marcia Hodes,
Marcia.Hodes@Eng.Sun.Com, our intern coordinator.  We will inform the
selected candidates of our decision no later than 3/27/98.

Please feel free to forward this note to any colleagues with interests
in the areas described above. Should your plans include a visit to the
Bay Area (or if you already work here!), and you would like an
opportunity to present your recent research work to us, please contact
our Director, Dr. John Nickolls, John.Nickolls@Eng.Sun.Com.

Regards,
Bill Bryant
1998 Interns Program Manager, 
SUN Processor Architecture and Performance Software Group






----- End Included Message -----


Date: Tue, 3 Mar 1998 11:04:11 -0800 (PST)
From: chambers@klamath (Craig Chambers)
To: spin-comp@cs
Subject: EE500B 3-9-98

FYI, for the people looking at OpenGL as a benchmark.

----- Begin Included Message -----

From voting-faculty-request@june  Tue Mar  3 10:54:00 1998
Delivery-Date: Tue, 03 Mar 1998 10:54:00 PST
Date: Tue, 3 Mar 1998 10:52:45 -0800 (PST)
From: Scott Dakins <sjdakins@cs.washington.edu>
To: talks@cs.washington.edu
Subject: EE500B 3-9-98
MIME-Version: 1.0
Sender: owner-talks@cs.washington.edu

Depts. of Electrical Engineering, Bioengineering, Radiology & Cardiology
University of Washington

EE500B Weekly Seminar on Image Computing
Winter Quarter 1998

Celeste Fowler
Member of Technical Staff
Silicon Graphics
Mountain View, CA

Image Processing Using OpenGL

Monday, 9 March 1998
4:30 p.m.
Guggenheim 217

The OpenGL API has become an industry standard. It provides a clean,
flexible, efficient interface to the graphics capabilities of many
different platforms. Frequently, OpenGL is the only interface to powerful
special-purpose graphics hardware. Although generally thought of as an API
for 3D applications, OpenGL was designed with 2D graphics and image
processing in mind as well.

OpenGL was designed to be a an efficient, low-overhead program interface to
graphics hardware. It provides an interface to a graphics pipeline
containing geometry, rasterization, and fragment (texture and fog
application) steps. OpenGL can be used to solve image processing problems
including but not limited to geometric operations such as scales,
rotations, and warps; convolution; color space operations; difference matte
extraction; and compositing.

There are several advantages and disadvantages to using OpenGL for image
processing. Since OpenGL was designed with 3D applications in mind, it has
extensive features and a very general interface for geometry, texture, and
framebuffer operations. OpenGL provides applications with access to
graphics hardware and to tuned software implementations. Because OpenGL
provides an interface to many types of graphics hardware, applications may
be easily ported. In some cases, the OpenGL interface may seem
counter-intuitive for image processing applications, particularly when
compared with dedicated software-only libraries. Also, OpenGL currently
lacks some features which might be desirable in an image processing
package.

For more information, please contact the seminar series coordinators, Prof.
Yongmin Kim (685-2271), Prof. Marty J. Kushmerick (543-3762), Prof. David
T. Linker (685-1397), Prof. James A. Nelson (543-3757), or Prof. Alan H.
Rowberg (548-7489).

Please note that this seminar will also be shown on UWTV Channel 27  (and
Channel 18 Wenatchee) on Friday, March 13, 1998 at 1:30 p.m.



----- End Included Message -----


Date: Thu, 5 Mar 1998 22:23:18 -0800 (PST)
From: "Markus U. Mock" <mock@cs.washington.edu>
To: spin-comp@cs.washington.edu
Subject: Register Action Proposal

I've added the proposal to our internal web page. It's accessible through
links to our internal DyC documentation or directly at URL
http://www.cs.washington.edu/research/projects/unisw/DynComp/www/Internal/Documentation/DyC/Development/regacts.html

Feedback welcome, please read by Tuesday so we can talk about it.

	-- Markus 



Date: Fri, 6 Mar 1998 10:45:33 -0800 (PST)
From: Markus Mock <mock@apex.cs.washington.edu>
To: Matthai Philipose <matthai@cs>, spin-comp-archive@cs
Subject: Partition number is bigger than number of partitions

matthai,

I get the following error:
? FATAL COMPILER ERROR
? Assertion failed.
? Partition number is bigger than number of partitions

? (file:line) util/set_partition.C:171

when I run on
/afs/cs.washington.edu/project/dyncomp/mock/DyC/regression/smv/smv.DyC.
Any idea what's going on there?

	-- Markus


Date: Mon, 9 Mar 1998 12:56:22 -0800
From: eggers@yakima (Susan Eggers)
To: spin-comp@cs
Subject: meeting

Just a reminder to think about what algorithms we would like 
to discuss for possible patenting.

Susan

Date: Thu, 12 Mar 1998 11:00:42 -0800 (PST)
From: Markus Mock <mock@lily.cs.washington.edu>
To: Brian Grant <grant@cs>, spin-comp-archive@cs
Subject: division identifiers

I've added unique identifiers for each division / division info pair:
UNSIGNED INT pairId; 
They are assigned uniquely when a pair is created. The BS field
sourcePairs in a pair is the set of pair identifiers from which the
division was computed.

I've checked in all my changes.



	-- Markus


Date: Mon, 16 Mar 1998 12:22:40 -0800 (PST)
From: chambers@klamath (Craig Chambers)
To: spin-comp@cs
Subject: meeting

I have to make a presentation to the prospective grads at 2:45-3, so I'll 
miss that part of our meeting.

-- Craig

To: spin-comp@thistle.cs.washington.edu
Subject: an obscure and possibly harmless glitch in polyvariant division
Date: Mon, 16 Mar 1998 14:47:29 PST
From: Brian Grant <grant@thistle.cs.washington.edu>

Discordant merges may not be properly identified.
	A discordant merge may be split due to polyvariant division,
	postponing the control-flow merge to the point at which divisions
	merge.  The BTA does not take this into account and considers only
	the original control-flow merges (actually, variables with multiple
	reaching definitions are computed by a prepass).

But it may not matter (for now).  
	There should still be a unit boundary at the post-splitting control-
	flow merge because of the single-entry requirement for units.
	Furthermore, our cache lookup currently includes all variables in the
	context in the hash key, so we should (appropriately) get different
	versions for different values of the discordant variables.  So, the
	current problem seems to be one unnecessary unit boundary where the
	discordant variables are identified.

I haven't thought about what happens when unchecked cache policies are used,
but I think CacheAllUnchecked should function correctly.  This could become
a more serious problem if I try to make the caching scheme more clever by
only checking the discordant variables.  It is unclear if the problem should
be addressed in the BTA (which is getting more complicated every day), or in
a postpass (which may not have enough information).

Example:
	x = foo();
	make_static(x);
	if (d) {
		x++;
	} else {
		x--;
		make_static(y);
	}
	...use of x...
	B: ...last use of y...

If divisions merge at B, then the post-splitting (discordant) merge will
actually occur at B, and not immediately following the if statement.

Note also that no merge need occur at all, if divisions remain separate to
the end of the dynamic region.

--Brian

Date: Tue, 17 Mar 1998 13:50:19 -0800
From: eggers@yakima (Susan Eggers)
To: spin-comp@cs
Subject: meeting

and I have a prospective student 3-3:30.

Susan

To: eggers@yakima (Susan Eggers)
cc: spin-comp@thistle.cs.washington.edu
Subject: Re: meeting 
Date: Tue, 17 Mar 1998 14:01:01 PST
From: Brian Grant <grant@thistle.cs.washington.edu>

If Craig will miss the first half, and Susan the second, then I just think
we should cancel the meeting.

Markus and I worked on polyvariant division last week.  A number of
complications were discovered.  One was that we needed to tag each Division->
DivisionInfo mapping so that we could determine which (merged) divisions were
derived from which divisions at the previous program point.  Markus then
discovered previously unconsidered implications for the reachability analysis
and may have come up with a (partial?) fix.  Similar implications exist for
discordant merges, independent of reachability analysis (described by my
message yesterday).  A few other minor complications have also arisen due
to the way we represent and use BTA information, and due to the way IGOTOs
are copied.  It will be another day or so before I am ready to test the code.

--Brian

To: spin-comp@franklin.cs.washington.edu
Subject: Progress report
Date: Tue, 17 Mar 1998 14:02:26 PST
From: Matthai Philipose <matthai@franklin.cs.washington.edu>

In case we aren't meeting today, here's my progress report.

The new version of the merger seems to be working on mipsi, and on a couple of small test programs I tried it on. I haven't tried it on the regression suite yet.

I fixed a couple of bugs uncoverd by Markus' attempt to compile the model-checker, but my fix seems to have caused/exposed a memory leak in the early part of the compiler. I will fix this, make sure mipsi and all regression suite programs run fine, before checking in mipsi and the new merger.

In the meantime, I have started digging into Mesa (the OpenGL derivative). I haven't fully figured out how things work, but there seem to be many instances of (apparently) infrequenty varying datastructures being interpreted, and of parameterization based on scalars. I will talk to Joel (Auslander) later today, since he has a lot experience using OpenGL and knows our stuff.

By next week, I'm hoping to have OpenGL compiled on multiflow, and to have figured out the identity and the pattern of use of the main runtime constants (and maybe have tried out some simple annotations).

		Matthai



Date: Tue, 17 Mar 1998 14:12:24 -0800
From: eggers@yakima (Susan Eggers)
To: spin-comp@franklin.cs.washington.edu, matthai@cs.washington.edu
Subject: Re: Progress report

Thanks both of you.

Susan

To: spin-comp@thistle.cs.washington.edu
Subject: prospective Nate Kushman
Date: Tue, 17 Mar 1998 14:23:23 PST
From: Brian Grant <grant@thistle.cs.washington.edu>

Matthai and I talked to him this morning for 30 minutes.  Craig also met with
him.  Since we did nearly all of the talking, we didn't learn much about him.
We'll probably talk to him again tomorrow.  

Nate said that he would come to UW primarily to work on dynamic compilation.
Should we be interested in him?  Should we try to "recruit" him?  What should
we tell him?

For example, I mentioned Whirlwind to him and gave him a 30s spiel.  He said
that Craig didn't mention it.  He seemed interested.  If he stops by again,
should we tell him anything else about it?

Also, do we know if we'll have funding (RA) for him?  Should we ask him if
that would be important to him?

--Brian

Date: Tue, 17 Mar 1998 14:31:08 -0800
From: eggers@yakima (Susan Eggers)
To: spin-comp@thistle.cs.washington.edu, grant@cs.washington.edu
Subject: Re: prospective Nate Kushman


Yes, we should recruit him.  We should be recruiting **all** of
them.

I talk to him tomorrow too.

Susan

Date: Tue, 17 Mar 1998 15:20:44 -0800 (PST)
From: chambers@klamath (Craig Chambers)
To: spin-comp@thistle.cs.washington.edu, grant@cs.washington.edu,
Subject: Re: prospective Nate Kushman

I also talk to Nate again tomorrow, right after Susan.

I thought I talked to him about DyC and Whirlwind.

-- Craig

Date: Fri, 20 Mar 1998 11:36:27 -0800 (PST)
From: chambers@klamath (Craig Chambers)
To: spin-comp@cs
Subject: web on afs?

I tried to access our DC web page, and got an error.  I think did klog,
and then I was able to read the web page.  Are our web pages on AFS?  If so,
how can anyone else read them?

-- Craig

To: chambers@klamath (Craig Chambers)
cc: spin-comp@thistle.cs.washington.edu
Subject: Re: web on afs? 
Date: Fri, 20 Mar 1998 11:41:32 PST
From: Brian Grant <grant@thistle.cs.washington.edu>

klog cannot affect whether you can access the web or not for two reasons:
	1) None of the web is on AFS.
	2) All accesses go through the web server, rather than via local file
	   access.

People outside the dept. can access it.  It has been recently accessed (at
least) by people from OGI, MIT, IRISA, and DIKU.

The web server is kind of flaky.  It was probably a fluke.

--Brian

Date: Tue, 31 Mar 1998 21:26:07 -0800
From: eggers@yakima (Susan Eggers)
To: spin-comp@cs
Subject: possible patents

I'd like to have a meeting at our regular time next week to discuss
potential patents.  We're coming up on the anniversary of our PEPM
paper, after which we will not be able to patent anything that it 
contains.  If we decide not to patent, I'd like our decision to be
based on our judgement that there was nothing to patent, not that we
just didn't get around to it.  If we decide to patent, we should
get the ball moving, because it's not a two-day process for Patrick
and the lawyers.

Can you think over the week what parts of your work may be patentable.
Think what is novel, no matter how small.  Then think how the small
thing could be expanded to be more general.  Or at least this is how
I do it.

Susan

To: eggers@thistle.cs.washington.edu, chambers@thistle.cs.washington.edu,
cc: spin-comp-archive@cs
Subject: TCS paper
Date: Fri, 03 Apr 1998 09:04:28 PST
From: Brian Grant <grant@thistle.cs.washington.edu>

Final papers are due May 31.  The two major suggestions (made by the second
reviewer) were:

	1) Add a section describing the overall system, with a picture
	   similar to figure 1 of the PLDI 96 paper and a diagram of our
	   different analyses and transformations.  Snippets of section 7
	   (experiences) that explain where we plugged into Multiflow could
	   be moved to the new section and expanded.

	2) Examples in sections 5 & 6 to make the paper actually readable.
	   Although this would be nice, the reviewer also commented that he
	   didn't expect us to actually do this. :-)

A weakness that I hadn't considered was also pointed out: the specialize
annotation doesn't allow us to specialize functions for globals (as Tempo
can do).  Though a small change in the annotation might seem to allow it,
we can't actually specialize with respect to globals at all because the
system uses the name (i.e., address) of the global as the cache key, rather
than the value.

--Brian

Date: Mon, 6 Apr 1998 10:42:14 -0700 (PDT)
From: Markus Mock <mock@lily.cs.washington.edu>
To: Matthai Philipose <matthai@cs>, spin-comp-archive@cs,
Subject: Re: problems in POOL_Salloc 

The problem seems to be caused by the equiv vars pass:
#1  0x12011d070 in VAR_EVSet_Malloc (size=1073833720) at p2mem/p2mem.C:596
#2  0x12011d070 in VAR_EVSet_Malloc (size=0) at p2mem/p2mem.C:596
#3  0x120114514 in SP_CreateSplitPartition
(partition_elements=0x140fdd6b8, 
    elt_num=0x120188868 <ev_var_number(VAR_BASE_NODE_S *)>)
    at util/set_partition.C:144
#4  0x120188d10 in EV_Update () at p2equiv_vars/p2equiv_vars.C:205
#5  0x120283ec4 in BTA_Compute () at p2bta/bta-v2.C:256
#6  0x120157440 in DEP_Compute_Info (dep_info_node_ptr=0x140023b30)
    at p2dep/p2dep.C:441
#7  0x120290a2c in DYC_PrepForDynComp () at p2dyc/p2dyc.C:1078
#8  0x120157554 in DEP_Invoke_Opt (dep_opt_node_ptr=0x140023df8)
    at p2dep/p2dep.C:461

failing assertion on line 439 in alloc/pool.C:
ASSERT(size > 0,"Bad size in call to POOL_Salloc");

This apparently makes all my regression tests fail right now. 
It is weird that Brian does not have that problem as we seem to have the
same source code, Matthai doesn't seem to have updated Brian's latest BTA
changes yet.

Matthai, could you update your compiler and see if you run into the same
error?
Thanks.



	-- Markus

On Fri, 3 Apr 1998, Brian Grant wrote:

> What is the size passed to POOL_Salloc?  Zero?  What is the allocation for?
> Is it called from p2bta?  from p2dyc?
> 
> --Brian
> 
> 


From: Craig Chambers <Craig.Chambers@irisa.fr>
Date: Tue, 7 Apr 1998 10:37:38 +0200
To: cecil@cs.washington.edu, spin-comp@cs.washington.edu
Subject: Summer Interns

FYI.

----- Begin Included Message -----

>From Sreeram.Duvvuru@Eng.Sun.COM Tue Apr  7 03:32 MET 1998
Date: Mon, 6 Apr 1998 18:32:27 -0700 (PDT)
From: Sreeram Duvvuru <Sreeram.Duvvuru@Eng.Sun.COM>
Subject: Summer Interns
To: chambers@cs.washington.edu
Cc: eggers@cs.washington.edu
MIME-Version: 1.0
Content-MD5: W3I5a++0Mm41Nt3OnDBCzQ==

Hello,


I was looking at the Dynamic Compilation web pages at UW.

We have one slot open for a Summer Intern to work on Solaris/SPARC version 
of HotSpot. If there is an appropriate person in your group, please refer 
them to us. We need help in performance analysis, running VMs on Shade like
tools, dynamic compilation, micro-architecture feature evaluation, 
interpreters, analyze memory footprint issues.


Thanks

Sreeram Duvvuru
Sun Microsystems.



----- End Included Message -----


From: Craig Chambers <Craig.Chambers@irisa.fr>
Date: Tue, 7 Apr 1998 11:46:13 +0200
To: melody@cs.washington.edu
Subject: France address
Cc: cecil@cs.washington.edu, spin-comp@cs.washington.edu


Here's my mailing address en France:

IRISA
Monsieur Craig CHAMBERS
Projet COMPOSE
Campus Universitaire de Beaulieu
35042 RENNES CEDEX
FRANCE


My phone number for calls from the US is:

0.11.33.2.99.84.71.98

My fax number is:

0.11.33.2.99.84.71.71


-- Craig

Date: Tue, 7 Apr 1998 10:44:02 -0700 (PDT)
From: Markus Mock <mock@lily.cs.washington.edu>
To: Brian Grant <grant@cs>, spin-comp-archive@cs
Subject: spec profiling

Brian,

is there a run-switch to turn it on or did you just modify the makefile?

	-- Markus


Date: Tue, 7 Apr 1998 13:48:45 -0700
From: eggers@yakima (Susan Eggers)
To: spin-comp@cs.washington.edu, Craig.Chambers@irisa.fr
Subject: Re: Summer Interns


I already told him that the DC students had things to do here.
But I was thinking of my own.  Markus, if that doesn't apply to
you, do you want to contact this guy?

Susan

Date: Thu, 9 Apr 1998 13:56:53 -0700 (PDT)
From: Markus Mock <mock@cs.washington.edu>
To: Brian Grant <grant@cs>, spin-comp-archive@cs
cc: Markus Mock <mock@cs>
Subject:  assert(NumberOfDivisions == 1) in bta_wrap.C

I think I have fixed the problem, however, the benchmarks now fail the
above assertion because it may happen that there is a divisionInfo pair
but is has 0 divisions indicating no specialization taking place.

It is necessary to have such a pair to be able to distinguish between two
bta's such as
{{x}} and {{x}, {}} 
where the first one indicates just one division, specializing x and the
second 2 divisions, one no specialization and one specializing x.

I can go ahead and check in my changes to the BTA if you want.






	-- Markus


Date: Thu, 9 Apr 1998 13:57:22 -0700 (PDT)
From: Markus Mock <mock@cs.washington.edu>
To: Brian Grant <grant@cs>, spin-comp-archive@cs
Subject: assertion

it fails, of course, because NumberOfDivisions == 0.


	-- Markus


Date: Mon, 13 Apr 1998 17:13:25 -0700
From: eggers@yakima (Susan Eggers)
To: spin-comp@cs
Subject: weekly meeting

Just to make sure we are all on the same page, I'd like to meet
tomorrow and continue on a weekly basis, just as before Markus and
Craig left for their trips.

Susan

Date: Mon, 13 Apr 1998 17:59:03 -0700
From: eggers@yakima (Susan Eggers)
To: spin-comp@cs
Subject: what's on my board

I've put a frame file in /projects/dyncomp/SharedWorkingArea
which contains the outline of our possible patents that was on
my whiteboard.  Can each of you take a crack at expanding some
sections, whichever you think are most up your ally.  Send mail
when you have the lock on the file.

I'm sorry this has taken so long for me to type so little.  Busy
week, last week.

Susan

Date: Tue, 14 Apr 1998 14:04:19 -0700 (PDT)
From: Markus Mock <mock@cs.washington.edu>
To: Matthai Philipose <matthai@cs>, spin-comp-archive@cs
cc: Markus Mock <mock@cs>
Subject: convergence problem with equiv vars?

Try to run on 
/afs/cs.washington.edu/project/dyncomp/mock/DyC/spec95/benchspec/CINT95/124.m88ksim.DYC/src/simtime.DyC
(ccomargs.in file in the directory).

Maybe it just takes very long but is it normal that 
Computing flow summaries...
Initializing in and out sets...
Iterating to fixed point...
Propagating to stats...
Done with equiv-vars computation...
Done with equiv-vars computation...
Computing flow summaries...
Initializing in and out sets...
Iterating to fixed point...
Propagating to stats...
Done with equiv-vars computation...
Done with equiv-vars computation...
Computing flow summaries...
Initializing in and out sets...
Iterating to fixed point...
Propagating to stats...
Done with equiv-vars computation...
Done with equiv-vars computation...
Computing flow summaries...

....

is repeated various times?


	-- Markus


Date: Wed, 15 Apr 1998 11:28:08 -0700 (PDT)
From: Markus Mock <mock@cs.washington.edu>
To: Brian Grant <grant@cs>, spin-comp-archive@cs
cc: Markus Mock <mock@cs>
Subject: another error in unit.C

I get the following assertion failure when I run on
/afs/cs.washington.edu/project/dyncomp/mock/DyC/spec95/benchspec/CINT95/124.m88ksim.DYC/src/simtime.DyC

Expression ( STAT_dyc2_staticOp(Stat) ==
(DivInfoPair->divinfo->StaticStat
== Stat) ) evaluated to FALSE at (file:line) p2dyc/unit.C:576*** Exit 1

DivInfoPair->divinfo->StaticStat = NULL 
whereas STAT_dyc2_staticOp(Stat) is (correctly) 1  (for stat 495)

(there's only one division)


	-- Markus



Date: Wed, 15 Apr 1998 12:09:52 -0700 (PDT)
From: Markus Mock <mock@cs.washington.edu>
To: Matthai Philipose <matthai@cs>, spin-comp-archive@cs
cc: Markus Mock <mock@cs>, Brian Grant <grant@cs>
Subject: More EquivVars trouble

In addition to taking a long time, it also uses a lot of space.  It just
ran out of memory when I ran it on another file (dpath.DyC part of the
mk88)  simulator.  

Since this is on the critical path, could you please
fix that quickly?  Thanks. 

	-- Markus


Date: Wed, 15 Apr 1998 12:30:12 -0700
From: eggers@yakima (Susan Eggers)
To: spin-comp@cs
Subject: Craig

Craig sent us mail with his addresses and phones, etc.  I've misplaced
mine in the morass which serves as my file directory.  Did anyone save
his mail?

Susan

Date: Wed, 15 Apr 1998 12:35:08 -0700 (PDT)
From: Markus Mock <mock@cs.washington.edu>
To: Susan Eggers <eggers@yakima>
cc: spin-comp@cs
Subject: Re: Craig


From Craig.Chambers@irisa.fr Tue Apr  7 09:31:44 1998
Date: Tue, 7 Apr 1998 11:46:13 +0200
From: Craig Chambers <Craig.Chambers@irisa.fr>
To: melody@cs.washington.edu
Cc: cecil@cs.washington.edu, spin-comp@cs.washington.edu
Subject: France address


Here's my mailing address en France:

IRISA
Monsieur Craig CHAMBERS
Projet COMPOSE
Campus Universitaire de Beaulieu
35042 RENNES CEDEX
FRANCE


My phone number for calls from the US is:

0.11.33.2.99.84.71.98

My fax number is:

0.11.33.2.99.84.71.71


-- Craig


	-- Markus

On Wed, 15 Apr 1998, Susan Eggers wrote:

> Craig sent us mail with his addresses and phones, etc.  I've misplaced
> mine in the morass which serves as my file directory.  Did anyone save
> his mail?
> 
> Susan
> 


Date: Mon, 20 Apr 1998 16:04:01 -0700 (PDT)
From: Markus Mock <mock@cs.washington.edu>
To: Brian Grant <grant@cs>, spin-comp-archive@cs
cc: Markus Mock <mock@cs>
Subject: error in  dyc_DtypeToOperand

Brian,

dyc_DtypeToOperand (DType=6) in  p2dyc/util.C:501 causes mflow to abort in
CCODE_Size_To_I (size=6) at cfe_alpha/ccode.C:6697
because of the size argument.

The problem occurs with the file
/afs/cs.washington.edu/project/dyncomp/mock/DyC/spec95/benchspec/CINT95/124.m88ksim.DYC/src/dpath.DyC

I guess the problem is because of unaligned field size in the struct that
the processor, more exactly access to m88000.ALU (at offset 6 of size 1
byte).


If you want to reproduce the problem run with reachability turned off
(otherwise it takes about 90 minutes to run the BTA, we're clearly seeing
the potential for exponential blow up in clause size here. I am looking if
there's a way to make it faster ...).


Short of padding the struct, do you think you can fix that easily? We
might run into that more often in real programs (if field size is the real
problem here).


	-- Markus


Date: Tue, 21 Apr 1998 16:43:46 -0700 (PDT)
From: Markus Mock <mock@cs.washington.edu>
To: Matthai Philipose <matthai@cs>, spin-comp-archive@cs
Subject: Label L2477$3 is not recorded as labelling any unit

I guess that's a merger bug since that label actually does exist in:
/afs/cs.washington.edu/project/dyncomp/mock/DyC/spec95/benchspec/CINT95/124.m88ksim.DYC/src/dpath.pms

Could you take a look please?
Thanks.


	-- Markus


To: spin-comp@franklin.cs.washington.edu
Subject: usr_include_alpha directory checked into cvs
Date: Tue, 21 Apr 1998 17:15:47 PDT
From: Matthai Philipose <matthai@franklin.cs.washington.edu>

Charlie made a special version of /usr/include/alpha for the 64-bit version of the multiflow, which used to reside in: /projects/trace1/mflow/usr/vssad/release/garrett/usr/usr_include_alpha

I've now placed a copy of this dir under cvs, as subdirectory usr_include_alpha of the DyC directory. Please update to get this sub-directory.

I have also changed the Makefile in DyC/bin so that dcmake now uses the the environment variable DYC_USR_INCLUDE_ALPHA_DIR to find out where the include directory is. You should therefore set the environment variable DYC_USR_INCLUDE_ALPHA_DIR to your DyC/usr_include_alpha directory, and update to the new version of dcmake.

The reason for this change is that I found I needed to modified a file in usr_include_alpha, and figured it's better to have modifiable stuff under cvs.
	Matthai
	

To: spin-comp@thistle.cs.washington.edu
Subject: tools for viewing gprof output!
Date: Thu, 23 Apr 1998 09:10:22 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

Fortunately, since it doesn't look like we'll be able to get the same info
from DCPI, someone has directed me to a couple tools that we may be able to
combine to view gprof output.

I'll try to install and test them this afternoon.

--Brian

Date: Thu, 23 Apr 1998 09:44:39 -0700 (PDT)
From: Markus Mock <mock@cs.washington.edu>
To: Brian Grant <grant@cs>, Matthai Philipose <matthai@cs>,
Subject: var args

I don't recall there being a problem with var args with our 64bit version,
however, trying to compile a function with var args runs into a syntax
error.

Did varargs ever work (I am not talking about dynamically compiling such
functions).

	-- Markus


Date: Thu, 23 Apr 1998 15:08:52 -0700 (PDT)
From: Markus Mock <mock@cs.washington.edu>
To: Brian Grant <grant@cs>, spin-comp-archive@cs
cc: Markus Mock <mock@cs>
Subject: saving callee saved regs

Brian,

how difficult would it be to add the saving of callee saved regs? 
It turns out that multiflow produces an incorrect result for mk88sim. I
can compile with cc (no optimization) though and link with the function
that is compiled with our dynamic compiler (without optimization the
problematic variable(s) do not get register allocated and hence don't get
clobbered by our runtime. 

For a more meaningful comparison we should compare to the optimized spec
benchmark, not to a castrated one, I think. So if adding that register
saving (for performance we could make that switchable in the compiler, and
turn it on only when registers get clobbered).
Since we can't compile everything through mflow, it would be good to be
able to link with cc-compiled (or gcc-compiled )code more easily.


	-- Markus


Date: Sun, 26 Apr 1998 22:57:11 -0700 (PDT)
From: Markus Mock <mock@cs.washington.edu>
To: Matthai Philipose <matthai@cs>, spin-comp-archive@cs
cc: Markus Mock <mock@cs>
Subject: stitcher problem

Matthai,


can you take a look at the executable m88k in 
/afs/cs.washington.edu/project/dyncomp/mock/DyC/spec95/benchspec/CINT95/124.m88ksim.DYC/src

It seg faults at

Program received signal SIGSEGV, Segmentation fault.
0x140035fa8 in DyCRT_CodeSpace ()
1: x/i $pc  0x140035fa8 <DyCRT_CodeSpace+56>:	
    	00000000	call_pal halt

apparently the code is not stitched correctly. 

(you need to run with  m88k <ctl.in)



	-- Markus


To: spin-comp@thistle.cs.washington.edu
Subject: New lazy-edges implementation works (mostly)
Date: Mon, 27 Apr 1998 14:27:06 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

Nearly all of the regression tests pass.  The notable exceptions are
several programs that now fail the infamous 799 assertion that didn't
before and:

	binary (both eager and loop_specialize_lazy): something weird is
		causing these programs to fail with larger array sizes, and
		to have different behavior in and out of the debugger, and
		in the simulator, too
	pow: an apparent bug in Multiflow is omitting a necessary move
		from an argument register to another register
	query: now giving the wrong answer (but I haven't tracked down the
		reason)

Now that about 10 programs fail the 799 assertion in the scheduler, I'll have
to track it down.

I won't check in my code for a while yet.  I still need to merge my code with
the new merger, and I had to make more changes to the old one than I thought
I would.

Also, the new implementation of lazy edges has (temporarily) crippled the
timing instrumentation.  So, no numbers yet.

--Brian

To: spin-comp@thistle.cs.washington.edu
Subject: other progress: nil
Date: Mon, 27 Apr 1998 17:17:39 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

I haven't made any progress on the paper or on apps this week.  I've been
fairly sick (and so have my wife and daughter), and I may skip tomorrow's
meeting if I'm not substantially better than I was today.  I won't be able
to talk more than a couple minutes in any case.

I'll email my portion of the patent writeup tonight or tomorrow morning,
just in case.

--Brian

To: spin-comp@thistle.cs.washington.edu
Subject: patents
Date: Wed, 29 Apr 1998 10:29:59 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

Ok, so I didn't get around to sending out my patent writeup yesterday.
However, today I'm feeling better, so here it is.  Hopefully, these two
points are recognizable as conditional specialization and unit identification
and clustering.

--Brian

Implementing Conditional Pragmas Using Merge Splitting
------------------------------------------------------

A pragma is a compiler directive inserted into a program's source
code.  A conditional pragma would be such a directive that would take
effect only when certain conditions held true.  By using merge
splitting, it is possible to use the programming langauge itself to
specify the conditions, rather than a macro preprocessor or special
syntax.  Consequently, because the conditions are ordinary program
statements, arbitrarily complex compile-time and run-time conditions
are possible.  If the conditions can be completely evaluated at
compile time, then the branch can be folded away, like any other
conditional statement.

A conditional pragma implemented in this way takes effect beginning
(approximately) at the place in the program where the pragma was
inserted.  Merges of paths through the program's control-flow graph
(or supergraph, if the pragma should have interprocedural effects)
on which the pragma should and should not take effect are split.  The
paths need not be split blindly.  Rather, the paths could be analyzed
independently and actually split if it were determined that the pragma
actually has an effect.


Determination of Code-Caching Points in Dynamic Compilation
-----------------------------------------------------------

There are three types of program points where dynamically generated
code should be cached to enable code reuse:

	1) Transitions from execution to dynamic compilation, in order
	to use code that was previously generated under a similar
	program state, i.e., the same values (or other properties,
	such as types) of program or system variables used in the code
	generation

	2) Control-flow merges of paths on which program or system
	variables used in the code generation potentially (but not
	definitely) are	assigned the same values

	3) Program points after which variables that were used
	in code generation are no longer used, eliminating
	that potential difference between different versions
	of dynamically generated code

However, due to the significant cost of code caching, it is desirable
to minimize the number of caching points.  So, we first identify
candidate caching points at the above three types of program points,
identify program ranges in which the candidate caching points can be
actually placed, intersect the ranges of the candidates, and place
caching points in the intersections such that the amount of
dynamically generated code is minimized.



Date: Thu, 30 Apr 1998 20:27:14 -0700 (PDT)
From: "Markus U. Mock" <mock@cs.washington.edu>
To: Matthai Philipose <matthai@cs.washington.edu>,
Subject: new merger & dcmake

Hi Matthai,

is the new merger ready yet? I need it now to get the last part of
m88ksim working as I need to make changes in the source file  and it's not
practical for me to wait each time for you to hack the .pms file as I keep
getting:

Label L2957$3 is not recorded as labelling any unit

Or, alternatively, you show me how to munge the file -- but having a
working merger would be preferable.

BTW: dcmake does not seem to be checked in.



	-- Markus 




Date: Mon, 4 May 1998 10:40:04 -0700
From: eggers@yakima (Susan Eggers)
To: spin-comp@cs
Subject: patents

I've put an updated copy of the patent ideas in
/projects/dyncomp/SharedWorkingArea.

Matthai and Markus, could you complete your sections today?

Thanks, Susan

Date: Mon, 4 May 1998 12:05:58 -0700 (PDT)
From: Markus Mock <mock@cs.washington.edu>
To: Matthai Philipose <matthai@cs>, spin-comp-archive@cs



	-- Markus


Date: Mon, 4 May 1998 15:55:29 -0700 (PDT)
From: Markus Mock <mock@cs.washington.edu>
To: Susan Eggers <eggers@yakima>
cc: spin-comp@cs.washington.edu
Subject: Re: patents

I've put my spiel in the file annotations.txt in the shared directory.

	-- Markus

On Mon, 4 May 1998, Susan Eggers wrote:

> I've put an updated copy of the patent ideas in
> /projects/dyncomp/SharedWorkingArea.
> 
> Matthai and Markus, could you complete your sections today?
> 
> Thanks, Susan
> 



Date: Tue, 5 May 1998 10:48:56 -0700 (PDT)
From: Markus Mock <mock@cs.washington.edu>
To: spin-comp@cs.washington.edu
Subject: jtcs paper

I've edited the paper to incorporate the factored BTA equations. The
modified copy with the new BTA equations is in:
/afs/cs.washington.edu/project/dyncomp/grant/Papers/jtcs98/trbta-factored.doc

Use it for as the base for further edits.


	-- Markus


Date: Tue, 5 May 1998 10:50:21 -0700
From: eggers@yakima (Susan Eggers)
To: spin-comp@cs.washington.edu, mock@cs.washington.edu
Subject: Re: jtcs paper

I hope you're all using change bars, so we can quickly spot the
new sections.

Susan

To: spin-comp@noether.cs.washington.edu
Subject: committed new lazy-edge implementation
Date: Wed, 06 May 1998 23:42:26 PDT
From: Brian Grant <grant@noether.cs.washington.edu>

You'll need to update bin, lib, and mflow.  If you have no need to update,
then I suggest you don't update at this time.  Note that pow and query
still fail (pow for a known reason, but unknown if it can be fixed; query
for unknown reason).  A few other programs fail assertion 799.

--Brian

Date: Fri, 8 May 1998 15:25:43 -0700 (PDT)
From: Markus Mock <mock@cs.washington.edu>
To: Matthai Philipose <matthai@cs>, spin-comp-archive@cs
Subject: util.C bug

Matthai,

do you remember why you added the check for a direct call in line 1565 in
file p2dyc/util.C? I am running into an example where it returns NULL and
then crashes in strncmp called from  dyc_Keyword because the name string
is empty.

Also the call in question (source line 2948 in file
/afs/cs.washington.edu/project/dyncomp/mock/DyC/applications/tcl8.0/generic/tclExecute.DyC
is in fact a direct call, 
So I guess the bug is in the function dyc_StatIsADirectCall.
Could you take a look.

Thanks.

	-- Markus


Date: Tue, 12 May 1998 09:57:13 -0700
From: eggers@yakima (Susan Eggers)
To: spin-comp@cs
Subject: 590G

I just started reading the paper, but I suspect that we all should
read and attend today.  The topic is modeling program predictability,
and it includes data values as well as control.

12:30, EE1 perhaps room 025, papers on the 4th floor.

Susan

Date: Tue, 12 May 1998 10:48:11 -0700 (PDT)
From: Markus Mock <mock@cs.washington.edu>
To: Brian Grant <grant@cs>, spin-comp-archive@cs,
cc: Markus Mock <mock@cs>
Subject: rt status

FYI
these are the benchmarks that currently fail for me:

### Application csi crashed (log in csi/.test-mock-log)
### Application dotproduct crashed (log in dotproduct/.test-mock-log)
### Application fft crashed (log in fft/.test-mock-log)
### Application hsh crashed (log in hsh/.test-mock-log)
### Application interpreter-regs crashed (log in interpreter-regs/.test-mock-log)
### Application polydiv crashed (log in polydiv/.test-mock-log)
### Application polydiv2 crashed (log in polydiv2/.test-mock-log)
### Application xvalg crashed (log in xvalg/.test-mock-log)


	-- Markus


Date: Tue, 12 May 1998 10:49:28 -0700 (PDT)
From: Markus Mock <mock@cs.washington.edu>
To: Brian Grant <grant@cs>, spin-comp-archive@cs,
cc: Markus Mock <mock@cs>
Subject: m88k

I compared the run times with a version where the ckbrkpts routine is not
called at all:

no-bkpts:	21:04.63
base:		22:48.08
dyc:		25:54.64 

I compiled one version with instrumentation and got the following overhead
time:

Total time: 137686 cycles
Total dynamic-compilation overhead: 134000 cycles
Number of instructions emitted: 4
Cycles / instruction emitted: 33500.000000


So where does all that time go?  Could it be due to the much larger
executable size (the dyc version grows to over 145Meg VSZ whereas the base
version only goes to about 55Meg, so cache locality might be worse)?
Ideas?


	-- Markus



To: Markus Mock <mock@cs.washington.edu>
cc: matthai@thistle.cs.washington.edu, spin-comp-archive@cs
Subject: Re: rt status 
Date: Tue, 12 May 1998 10:56:12 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

Thanks.  For some reason, I have some different ones crash.  The differences:

### Application binary crashed (log in binary/.test-grant-log)
+++ Application dotproduct passed
+++ Application hsh passed
### Application interpreter crashed (log in interpreter/.test-grant-log)
+++ Application interpreter-regs passed
### Application promote1 failed (log in promote1/.test-grant-log)
### Application query failed (log in query/.test-grant-log)

promote1 and query give the wrong answer.  binary and interpreter fail 799.

--Brian

Date: Tue, 12 May 1998 16:42:39 -0700
From: eggers@yakima (Susan Eggers)
To: spin-comp@cs
Subject: first reply


----- Begin Included Message -----

From jouppi@pa.dec.com Tue May 12 16:23:59 1998
To: eggers@cs.washington.edu (Susan Eggers)
Cc: jouppi@pa.dec.com, farkas@pa.dec.com, sano@pa.dec.com
Subject: Re: cheap floating point register moves 
X-Mts: smtp
Content-Length: 501
X-Lines: 13
Status: RO


The 21064 and 21164 are both statically-scheduled machines.
In order to have simple precise exceptions in this type of
machine you want to have the latency of all operations the
same (except for a few long exceptions like divide).  I'm
not an expert on the machines but I wouldn't expect one
type of FP op to be faster than another due to the common
pipe.  You might have better luck with a 21264 since it is
dynamically scheduled, unless moves still go through the
add pipe to reduce wiring.

Norm



----- End Included Message -----


Date: Tue, 12 May 1998 17:02:49 -0700 (PDT)
From: Markus Mock <mock@cs.washington.edu>
To: Matthai Philipose <matthai@cs>, spin-comp-archive@cs
Subject: equiva vars memory hog

Matthai,

have you made any progress on a leaner version? For tcl the equiv vars
phase is just running forerver, currently at almost 300Meg... and swap
space is getting low..


	-- Markus


Date: Wed, 13 May 1998 10:36:59 -0700 (PDT)
From: Markus Mock <mock@cs.washington.edu>
To: Matthai Philipose <matthai@cs>, spin-comp-archive@cs
Subject: equiv-vars

Any progress?

	-- Markus


Date: Wed, 13 May 1998 21:12:38 -0700 (PDT)
From: "Markus U. Mock" <mock@cs.washington.edu>
To: Brian Grant <grant@cs.washington.edu>, spin-comp-archive@cs.washington.edu,
cc: Markus Mock <mock@cs.washington.edu>
Subject: profiles

I gathered the profile that Brian suggested: immediate return from the
ckbrpts function so that no dynamic code or setup is ever executed. It
showed similarly blown up execution times for Data_path and rdwr (the
functions that call ckbrpts):


BASE-VERSION:

Each sample covers 4.00 byte(s) for 8.9e-05% of 1099.6416 seconds

%time     seconds  cum %   cum sec  procedure (file)

 18.3    201.3262   18.3    201.33 killtime (<stripped>)
 11.4    125.9072   29.8    327.23 ckbrkpts (<stripped>)
 11.0    121.0361   40.8    448.27 Data_path (<stripped>)
  8.3     91.4795   49.1    539.75 alignd (<stripped>)
  7.5     82.3252   56.6    622.07 check_scoreboard (<stripped>)
  7.1     78.3477   63.7    700.42 execute (<stripped>)
  4.4     48.7949   68.1    749.22 rdwr (<stripped>)
  3.5     38.7891   71.7    788.01 Pc (<stripped>)
  3.3     35.9453   74.9    823.95 test_issue (<stripped>)
  2.9     32.3232   77.9    856.27 checklmt (<stripped>)

DYNAMICALLY-COMPILED VERSION
Each sample covers 4.00 byte(s) for 8.9e-05% of 1096.8213 seconds

%time     seconds  cum %   cum sec  procedure (file)

 15.8    173.7646   15.8    173.76 killtime (<stripped>)
 15.4    169.0518   31.3    342.82 Data_path (<stripped>)
  7.2     78.8789   38.4    421.70 execute (<stripped>)
  6.7     73.3711   45.1    495.07 checklmt (<stripped>)
  6.6     72.8799   51.8    567.95 rdwr (<stripped>)
  6.5     71.0791   58.3    639.03 alignd (<stripped>)
  5.7     62.1768   63.9    701.20 Pc (<stripped>)
  4.4     48.6816   68.4    749.88 check_scoreboard (<stripped>)
  3.4     37.4443   71.8    787.33 goexec (<stripped>)
  3.3     36.3359   75.1    823.66 test_issue (<stripped>)

DYNAMIC VERSION WITH NO ACTUAL EXECUTION OF DYNAMIC CODE
Each sample covers 4.00 byte(s) for 9e-05% of 1081.3594 seconds

%time     seconds  cum %   cum sec  procedure (file)

 16.3    175.8135   16.3    175.81 killtime (<stripped>)
 14.5    156.6611   30.7    332.47 Data_path (<stripped>)
  8.4     90.9629   39.2    423.44 execute (<stripped>)
  6.5     70.5879   45.7    494.03 alignd (<stripped>)
  6.0     65.0615   51.7    559.09 rdwr (<stripped>)
  5.5     59.4639   57.2    618.55 checklmt (<stripped>)
  4.9     52.9434   62.1    671.49 check_scoreboard (<stripped>)
  4.6     49.6699   66.7    721.16 Pc (<stripped>)
  3.8     40.6270   70.4    761.79 goexec (<stripped>)
  3.4     36.6943   73.8    798.49 test_issue (<stripped>)



	-- Markus 



Date: Thu, 14 May 1998 18:24:24 -0700 (PDT)
From: Markus Mock <mock@cs.washington.edu>
To: Matthai Philipose <matthai@cs>, spin-comp-archive@cs
Subject: progress?


Any progress on the equiv-vars front?

	-- Markus


Date: Fri, 15 May 1998 09:18:39 -0700 (PDT)
From: chambers@klamath (Craig Chambers)
To: spin-comp@cs
Subject: tempo

Tempo is available for downloading from the COMPOSE web pages now.  So we
can figure out what's really going on in comparisons.

-- Craig

To: spin-comp@franklin.cs.washington.edu
Subject: Fast version of equiv-vars checked in...
Date: Sat, 16 May 1998 15:12:16 PDT
From: Matthai Philipose <matthai@franklin.cs.washington.edu>

It's linear instead of quadratic in space now, and runs much faster in practice. I tried it out on the regression tests and mipsi and it's much faster.
			Matthai


Date: Sun, 17 May 1998 13:05:25 -0700 (PDT)
From: "Markus U. Mock" <mock@cs.washington.edu>
To: spin-comp@cs.washington.edu
Subject: 10% speedup in m88ksim!

Good news: I managed to get a 10.7% speedup on m88ksim after digging
around and finding what actually gave us a slowdown before.

After ruling out other factors, cache behavior remained as the only usual
suspect. I was using the cord/ftoc tools to confirm that and also
remembered that Ori Gershony had found in his quals project (where he
examined the effectiveness of procedure reorder algorithms a la
Pattis/Hansen) that m88ksim was particularly bad behaved on the Alpha with
about 4% of icache misses. However, using procedure reordering these went
down to almost 0.  Apparently, the change in procedure size of the
ckbrkpts routine which we are specializing made the bad behaviour
even  worse, leading to a slow down of up to 1.2 (with some
variation depending on some benchmark arguments). 

To improve cache behavior I used a tool called cord, which you feed a
desired procedure ordering and a binary and it gives you a binary with the
desired ordering. The desired ordering was generated using a profile with
prof & pixie and a tool called ftoc. The man page is not clear what exact
algorithm ftoc uses but is seems to be some variant of Pattis/Hansen that
orders procedures by the execution frequency and does a top-down ordering
based on frequency (instead of the static dfs-ordering used by the
standard DEC compiler/linker). I used the same order for the base
executable and the dynamically compiled executable. 

The following times [min:sec] are the median of 16 runs (running on
meitner all night): 

static base	static base		dyc		dyc
		+ proc reordering			+ proc reordering

00:21:34.8	00:20:28.8 		00:21:51.3	00:18:30.0

base : x
1.00		1.054			0.986		1.166

base w/ proc. reordering : x   	
0.949		1.00			0.937		1.107
							=====

A fair comparison of static base w/ reordering with dyc w/ reordering
shows a 10.7% speedup, which is about what we expect based on what I saw
in previous profiles. 



	-- Markus 


P.S. After speeding up m88ksim I will now continue with the tcl
interpreter. Matthai has finished the new equiv-vars implementation so
that I can actually dynamically compile it (previously, the compile ran
out of memory in that phase). 



Date: Sun, 17 May 1998 20:25:52 -0700
From: eggers@yakima (Susan Eggers)
To: spin-comp@cs.washington.edu, mock@cs.washington.edu
Subject: Re: 10% speedup in m88ksim!

This is good news.  It's also fodder for Matthai's architecture study.

Susan

Date: Mon, 18 May 1998 08:26:29 -0700 (PDT)
From: "Markus U. Mock" <mock@cs.washington.edu>
To: Matthai Philipose <matthai@cs.washington.edu>,
Subject: set_partition_vector.H

Matthai,

it appears that you have not checked in that file, so that the compile
fails right now. Could you check it in please? 
Thanks.




	-- Markus 



Date: Mon, 18 May 1998 08:38:47 -0700 (PDT)
From: "Markus U. Mock" <mock@cs.washington.edu>
To: Matthai Philipose <matthai@cs.washington.edu>,
Subject: set_partition.H

Matthai, 

copying the file directly to my util directory resulted in failed
compilation:

util/set_partition.H:106: warning:
`FOR_EACH_SET_PARTITION_EQUIVALENT_ELEMENT' r
edefined
util/set_partition_vector.H:111: warning: this is the location of the
previous d
efinition
util/set_partition.H:122: warning: `FOR_EACH_SET_PARTITION_SUBSET'
redefined

Let me know if the recompile works for you once you've added it to CVS.



	-- Markus 



Date: Tue, 19 May 1998 16:08:02 -0700 (PDT)
From: Markus Mock <mock@cs.washington.edu>
To: Craig Chambers <chambers@klamath>
cc: spin-comp@cs
Subject: Re: tempo

Do we want to download it? 

If so, we need to sign a form available at:
http://www.irisa.fr/compose/tempo/ in order to get the password to ftp the
file. 
Susan or Craig, could you send/sign the form?

	-- Markus

On Fri, 15 May 1998, Craig Chambers wrote:

> Tempo is available for downloading from the COMPOSE web pages now.  So we
> can figure out what's really going on in comparisons.
> 
> -- Craig
> 


To: spin-comp@thistle.cs.washington.edu
Subject: update on app search
Date: Thu, 21 May 1998 15:20:33 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

Encryption is out.  The implementations have already extracted and memoized
all static operations by munging the keys before they are used.

So, now I'm back looking at apps we already know about: xv, pov, dinero,
and xlisp.  At least we know these apps have potential.  For example,
45% of dinero's execution time is spent in 3 routines with DC opportunities.

--Brian

Date: Mon, 25 May 1998 13:48:54 -0700 (PDT)
From: "Markus U. Mock" <mock@cs.washington.edu>
To: Brian Grant <grant@thistle.cs.washington.edu>
cc: Markus Mock <mock@cs.washington.edu>,
Subject: Re: Memory usage of unit assignment etc 

Ok.

BTW: I updated and tried to compile but changes in p2mem make the compile
fail, apparently Matthai made some changes there

 p2mem_POOL_VEC_ENTRY(VAR_uv_set_pool);

using a ; where a , should be used.

Are there fixed but not checked-in version for the changed files?




	-- Markus 


On Mon, 25 May 1998, Brian Grant wrote:

   >> do you have any idea how to cut down on memory usages of the unit passes?
   
   For chebychev:
   
   DYC_BTA_pool: Total bytes allocated (ta): 292896
   DYC_pool: Total bytes allocated (ta): 48816
   
   I would guess most of the memory blow-up caused by my transformations are
   not due to direct allocations by me, but rather due to explosion in the size
   of the CFG, number of TEMPs, etc.  The back end keeps around 3-4
   representations simultaneously, so it could be eating memory.
   
   --Brian
   
   


To: mock@thistle.cs.washington.edu, matthai@thistle.cs.washington.edu
Subject: POOL_DEBUG
Date: Mon, 25 May 1998 12:52:58 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

After turning on pool debugging, I found that we were using the pools
incorrectly.  We were using Sreset and Salloc in some cases instead of
Reset and Alloc.  The latter calls must be used if the memory could be
freed prior to a subsequent Reset.  For now (and only in my version), I
have changed all our pools (including those used by equiv_vars and used_vars)
to use Reset, Alloc, and Realloc.  Definitely, the BTA pool and my pool
should use those calls, since they also use POOL_Free.  I'm not sure about
the others.  The S* calls use the pool like a true arena.  No memory is truly
freed for reuse until the pool is reset or destroyed.  If you know some of
the pools would be fine to be implemented like this, please let me know.
The S* calls are slightly faster.  I'll let you know whether I notice any
change in behavior due to the change in alloc. calls.

--Brian


Date: Mon, 25 May 1998 15:29:24 -0700 (PDT)
From: "Markus U. Mock" <mock@cs.washington.edu>
To: Brian Grant <grant@cs.washington.edu>, spin-comp-archive@cs.washington.edu
Subject: pool stuff - regression tests

Brian,

does it work for you? All regression tests fail for me now in
? FATAL COMPILER ERROR
? Assertion failed.
? POOL_Salloc called on unreset pool.
? (file:line) alloc/pool.C:436
*** Exit 1

(I had compiled with POOL_DEBUG=2 but that shouldn't matter).




	-- Markus 



Date: Wed, 27 May 1998 11:05:27 -0700 (PDT)
From: Markus Mock <mock@cs.washington.edu>
To: Matthai Philipose <matthai@cs>, spin-comp-archive@cs
Subject: Re: [UW-CS #1240] account on tennis machines (fwd)


>.., the account can't be created until an account request form
>is completed and turned in to support.

Matthai, 


where did you get the account request form, remember?



Date: Wed, 27 May 1998 16:46:12 -0700 (PDT)
From: Markus Mock <mock@cs.washington.edu>
To: Susan Eggers <eggers@cs.washington.edu>
cc: spin-comp@cs.washington.edu
Subject: afs on tennis machines

Susan,

the afs files are currently not available on the tennis machines. For now,
I will just have to create a complete copy of my mflow compiler on my
tennis account, which is ok. If we want to run more stuff on these faster
machines, afs should be installed there too (whoever's in charge for
that).


	-- Markus


Date: Wed, 27 May 1998 17:36:36 -0700
From: eggers@yakima (Susan Eggers)
To: eggers@cs.washington.edu, mock@cs.washington.edu
Subject: Re: afs on tennis machines
Cc: spin-comp@cs.washington.edu

Someone make an argument why we need afs on the new alphas.  Otherwise,
we should not have it installed.

If there's some reason we need afs, someone make an argument why we can't
have a script that copies whatever copy of mflow we are using for runs
on the new machines and then starts executing it.

(I'm trying to get rid of using afs if we can/should.)

Susan

Date: Wed, 27 May 1998 17:42:32 -0700
From: eggers@yakima (Susan Eggers)
To: spin-comp@cs, levy@cs, eggers@yakima, jlo@cs, sparekh@cs, redstone@yakima
Subject: new alphas

This is what student support does?  Wow, seems like alot.

So the students doing the work should be the DC students, with
Sujay as a consultant.  These are technically DC machines.
Can you let me know when your part is done?

Susan

> From oystr@maui Wed May 27 17:34:20 1998
> Subject: New Alphas
> To: eggers@june, sparekh@june
> Cc: burr@aspen
> Content-Length: 666
> X-Lines: 17
> Status: RO
> 
> I just had a talk with Joel and apparently there was some
> confusion.  The Alphas Joel was talking about have nothing to
> do with your new ones...
> 
> Which are sitting down here in 117 still in their boxes.
> So what Sujay, who I understand will be the sysadmin, needs
> to do is:
> 
> a) Decide where the machines are going to be placed physically,
>    what subnet they are going to be on, etc.
I have no idea how you decide that.  One on Matthai's desk, but what about
the others?
> b) Run the newhost(1L) command on June to define the machine
>    names and get the appropriate addresses.
I'll bring in my list of shortchanged, famous women.  Barring that, it
will be shade plants of the northeast.  I'm open to other suggestions,
but I plan to be pretty closed-minded.  :-)
> c) Haul the machines to where they will live.
> d) Bring the results of (b) to Nancy and me, at which point
>    we will help him configure the machines and get them on
>    the net.
> 
> 

Date: Thu, 28 May 1998 12:34:10 -0700 (PDT)
From: Markus Mock <mock@cs.washington.edu>
To: Matthai Philipose <matthai@cs>, spin-comp-archive@cs
cc: Markus Mock <mock@cs>
Subject: Re: using m88ksim

Go to 

/afs/cs.washington.edu/project/dyncomp/mock/DyC/spec95/benchspec/CINT95/124.m88ksim.DYC/src/measurements

you want to grab
m88k-ckbrpts-base-reordered (not dynamically compiled base)
m88k-ckbrps-opt-reordered (dyc)

Both are compiled with -non_shared as that's a standard compiler flag for
that benchmark.

To run it, you need more files, run it with 

executable -c < ctl.in
ctl.in is in
/afs/cs.washington.edu/project/dyncomp/mock/DyC/spec95/benchspec/CINT95/124.m88ksim.DYC/src

this in turn reads in a couple of more files (I don't remember which) all
of which are in
/afs/cs.washington.edu/project/dyncomp/mock/DyC/spec95/benchspec/CINT95/124.m88ksim.DYC/src
and that should be in the directory your running from.


	-- Markus

On Thu, 28 May 1998, Matthai Philipose wrote:

> Hey Markus,
> Do you have a version of m88ksim with dynamic compilation and one noop version so we (Tony Tsai and I) can simulate it? Also, the simulator need the libraries to be linked in using the "-non_shared" flag... what's the easiest way to do this?
> 
> Basically, if you can give us a binaries for m88sim with and without dynamic compilation, created using the non-shared flag?
> 	Thanks,
> 	Matthai
> 


Date: Fri, 29 May 1998 13:58:02 -0700
From: eggers@yakima (Susan Eggers)
To: spin-comp@cs
Subject: the flowcharts

I know you don't want to hear this, but we have to finish our
part of the patent description by early next week.  Can we have
the flowcharts (you) and overview (me) finished by Monday?

Susan

To: eggers@yakima (Susan Eggers)
cc: spin-comp@thistle.cs.washington.edu
Subject: Re: the flowcharts 
Date: Fri, 29 May 1998 14:46:46 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

>> I know you don't want to hear this, but

I know you don't want to hear this, but...

I have to finish up the TCS paper tonight and probably tomorrow.  I already
have other plans for the weekend as well.  I can't start on the figures
until Monday.  If possible, we should meet soon so that I can start
productively working on this first thing Monday morning.

--Brian

To: spin-comp@thistle.cs.washington.edu
Subject: any final comments on the paper?
Date: Fri, 29 May 1998 15:36:12 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

I am preparing the final version.  A few naming issues still need to be
resolved:

-- whether to use "generating extensions"/"GEs" or "run-time specializer"
   in section 3 and figures 6&7
-- whether to rename "specializable merge points" to "discordant merge",
   rename "discordant variables" to something else, or make no changes
-- whether to rename the cache policies, particularly the promotion cache
   policies (reviewers commented that promote_* are misleading). We could
   call them pcache_* and mcache_*.  pcache_all_unchecked could be changed
   to pcache_none, since the generated version would be thrown away.  Also,
   we could make the checked policies explicit (e.g., mcache_all_checked).

Also, please let me know if you have any comments on the abstract or keywords.
Below are the (brief) instructions/comments I received regarding these.

--Brian


INSTRUCTIONS TO AUTHORS

We kindly ask that you read through the following for the
preparation of your article for Theoretical Computer Science. 

KEYWORDS: Check to see that you have listed 3 to 5 
keywords (to be placed under the abstract). Keywords are 
essential for the accessibility and retrievability of your article.

ABSTRACT: Please note that the abstract of your article will 
be made available via Internet. It may be worthwhile to pay 
some extra attention to this summary so that future users 
will obtain a clear insight in your results and methods.


To: spin-comp@thistle.cs.washington.edu
Subject: final version of TCS paper ready
Date: Sat, 30 May 1998 00:29:01 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

I have made a final version of the paper.  I will send it out tomorrow
evening, so please send me any comments or make any changes before then.

The version with the TR number and date is still in:
	/projects/dyncomp/Papers/98/TCS/tr.doc

The version to be sent out is:
	/projects/dyncomp/Papers/98/TCS/final.doc
	/projects/dyncomp/Papers/98/TCS/final.mif
	/projects/dyncomp/Papers/98/TCS/final.ps

If you would like to make changes, please make them to tr.doc, then make a
new final.doc from that by deleting the TR number, date, and the preceding
blank line.  Also regenerate the .ps (by print to file) and .mif (save as MIF)
files.  I will send these to Charles compressed and encoded in various ways
(probably gzip MIME and gzip uuencode).

If you change more than a single word, please recheck the bib at the back. I
had to insert one blank line to prevent an entry from being split.  If the
text moves, you'll have to move that line.

Of the three naming quandaries I mentioned earlier, I only fixed the cache-
policy one (as described).  I also expanded the discussion of all the policies
in section 5.

I think the other two naming issues are not as serious.  I massaged the GE vs.
RTS issue by explaining the rationale for the different terms.  Discordant
variables I left as is because the term is pervasive.

--Brian

To: spin-comp@thistle.cs.washington.edu
Subject: woo hoo!  799 != 666
Date: Sat, 30 May 1998 01:59:38 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

To cap a week of amazing debugging successes, I think I have finally
vanquished a long-standing thorn in our sides -- the infamous 799
assertion failure.  The problem was annoyingly simple.  I put in some
trace boundaries to prevent certain code motion (e.g., between units in
template code).  When propagating the bits indicating where these boundaries
should be to a new IR, I didn't properly initialize the bits.  Some nodes
inserted later into that particular IR didn't have the bits initialized,
ending traces at unintended locations, and sometimes preventing an
essential node from being included in a short trace.

Other fixes this week allow the lazy version of binary to work with
work-list loop optimizations on, mipsi to interpret standard Unix
programs, and one version of xv to run!

Yippie!  We're on a roll. :-)
--Brian

To: spin-comp@thistle.cs.washington.edu
Subject: final version sent out
Date: Sat, 30 May 1998 22:27:16 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

I received no further comments on the paper, so I sent it out.  Now, on
to other things (like the patent)...

--Brian

Date: Sun, 31 May 1998 08:04:06 -0700
From: eggers@yakima (Susan Eggers)
To: spin-comp@thistle.cs.washington.edu, grant@cs.washington.edu
Subject: Re: woo hoo!  799 != 666


This is great.

Susan

To: spin-comp@thistle.cs.washington.edu
Subject: "slight" glitch in the BTA equations
Date: Mon, 01 Jun 1998 14:20:05 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

The division policy (polyvariant vs. mono.) is never consulted.  What actually
happens in sort of (but not quite) what we said our polyvariant policy was
supposed to do.  So, no monovariant division.

Of course, we had to notice this AFTER submitting the final version of the
TCS paper...

Markus is working on a fix.

--Brian

To: spin-comp@cs
Subject: Re: "slight" glitch in the BTA equations 
Date: Mon, 01 Jun 1998 17:32:18 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

My panic attack was unjustified.  Markus has found the case in the equations
that handles polyvariant vs. monovariant division.  It just didn't make it
into the implementation.

--Brian

Date: Tue, 2 Jun 1998 11:21:58 -0700 (PDT)
From: Markus Mock <mock@cs.washington.edu>
To: Brian Grant <grant@thistle.cs.washington.edu>
cc: spin-comp@cs
Subject: polyvariant division

The previously unimplemented case that handles correct division
partitioning in the presence of variables with monovariant division policy
is now also implemented. The updated BTA is checked into cvs.


	-- Markus

On Mon, 1 Jun 1998, Brian Grant wrote:

> My panic attack was unjustified.  Markus has found the case in the equations
> that handles polyvariant vs. monovariant division.  It just didn't make it
> into the implementation.
> 
> --Brian
> 
> 


Date: Wed, 3 Jun 1998 09:37:19 -0700 (PDT)
From: Markus Mock <mock@cs.washington.edu>
To: Matthai Philipose <matthai@cs>, spin-comp-archive@cs
Subject: summary

Matthai,

could you mail around the notes you took in yesterday's meeting?
Thanks.

	-- Markus


To: spin-comp@franklin.cs.washington.edu
Subject: Patent notes from yesterday's meeting
Date: Wed, 03 Jun 1998 09:52:45 PDT
From: Matthai Philipose <matthai@franklin.cs.washington.edu>

Here are the notes on our patent ideas from yesterday's meeting:

[Markus]
1) Our analysis is directed by policies:
	- We have a scheme of policy annotation
	- We have a scheme for propagating policies

2) We allow polyvariant division at arbitrary granularity. Specifically, we have the ability to perform intraprocedural polyvariant division.

[Matthai]
3) We can have both eager and lazy edges within the CFG being specialized.

4) We have schemes to determine how to choose which edges to mark lazy, while maintaining termination properties and performance.

[Brian]
5) We allow conditional specialization:
	- With arbitrary (run-time) conditions
	- At arbitrarily fine granularity (i.e. to determine specialization of arbitrary subgraphs of the program CFG)

6) We have a procedure to determine where to place cache checks (this includes breaking the graph up into units which have a single cache-context and clustering of unit boundaries)

7) We have a linearization scheme which allows us to include dynamic branches inside specialization units "cheaply" i.e. without having a worklist scheme to lay out each unit.



Date: Wed, 3 Jun 1998 12:15:52 -0700
From: eggers@yakima (Susan Eggers)
To: spin-comp@cs
Subject: word on the specificity

What we're doing is a provisional patent application, just getting our
toe in the door.  When we do the "real" one, we can't add to it at all,
meaning any new provisionals.  So we have to include everything we want
to include this time around.

Says Bershad.

Susan

Date: Wed, 3 Jun 1998 13:59:46 -0700
From: eggers@yakima (Susan Eggers)
To: spin-comp@cs
Subject: patents

I'm constructing the templates for the patents and writing the summaries.
I sort of want to combine 3 and 4 on Matthai's write-up into the same summary,
because they seem so related.  What was our compelling reason to split
them?

Susan

PS When I'm done, I'm going to ask you for a (any) background and invention
section, just to try integrating.

Date: Wed, 3 Jun 1998 14:17:05 -0700
From: eggers@yakima (Susan Eggers)
To: matthai@cs.washington.edu
Subject: Re: patents
Cc: spin-comp@cs

From Matthai:
> The way I'm writing it right now, (3) relates to a scheme for suspending specialization at any edge until that edge is executed,

But we didn't event lazy DC -- you must mean a framework that includes both
l and e.

> and (4) relates to the choice of edge to suspend at an edge given the need to gain such properties as termination and avoiding overspecialization.

OK, this is the split that I have now. 
But if you look at Brian's patent, it includes
some ramifications -- "the enforcement also includes a caching mechanism",
"the inventions separates the enforcement fof a security policy from the
actual security policy by ..."
and so forth.

To: spin-comp@thistle.cs.washington.edu
Subject: reply from Charles about TCS paper
Date: Thu, 04 Jun 1998 08:36:50 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>


------- Forwarded Message
Date: Thu, 04 Jun 1998 09:19:35 +0200
From: Charles Consel <Charles.Consel@irisa.fr>
To: grant@cs.washington.edu
Subject: Re: DyC.ps.gz.uu

Thanks for the final version of your paper. I saved both version. If the
TCS people have problems with the paper I'll let you, but it's working
fine here. As for the date of publication, it will be know as soon as I
collect the remaining papers (the second iteration has just started).

Charles
- -- 
- ---------------------------------------------------------------
Charles Consel              | University of Rennes / Irisa 
 consel@irisa.fr            | Campus Universitaire de Beaulieu
 Phone: (33) 2 99 84 74 10  | 35042 Rennes Cedex
 Fax:   (33) 2 99 84 71 71  | France
- ---------------------------------------------------------------
  URL: http://www.irisa.fr/compose/
- ---------------------------------------------------------------
------- End of Forwarded Message



To: spin-comp@thistle.cs.washington.edu
Subject: Patrick's reply about patent invalidation
Date: Thu, 04 Jun 1998 09:16:37 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>


------- Forwarded Message

Date: Thu, 4 Jun 1998 09:02:12 -0700 (PDT)
From: Patrick Jones <pljones@u.washington.edu>
To: Brian Grant <grant@cs.washington.edu>
Subject: Re: patent question

You are correct it would not invalidate the entire patent

the structure of a patent is briefly

abstract
specifications - two purposes 1) serve as a glossary/dictionary of terms
			      2) describe the best mode of the invcention
claims - two types 1) independent - they stand alone and are the broadest
		   2) dependent - they refer to one of the independent
claims and narrow the scope of the independent claim to which they refer

the claims are the heart of the patent: they describe the "claimed
invention" They are interpreted in light of the lexicon established in the
specifications and the implementation of the best mode. 

If a broad claim is invalidated, the narrower dependent claims are not
necessarily also invalidated. If one independent claim is invalidated, it
does not necessarily imply that all independent claims are invalidated.

If the invalidation arises from a loss of novelty (newness) you are at
greater risk for losing everything depending upon how the items are
linked. In a sense, a patent can only describe "one" invention, though the
invention may have many forms or implementations.

pljones, Technology Manager
Office of Technology Transfer
University of Washington

voice 206-616-3451 fax 206-616-3322

On Wed, 3 Jun 1998, Brian Grant wrote:

> Patrick,
> 
> I'm working with Susan Eggers on the dynamic compilation patent.  I was
> wondering: if a portion of the patent is invalidated, does it invalidate
> the entire patent?  I would assume that it doesn't, but I just thought I'd
> check.
> 
> Thanks.
> --Brian
> 



------- End of Forwarded Message



To: eggers@thistle.cs.washington.edu
cc: spin-comp@thistle.cs.washington.edu
Subject: patent progress (or apparent lack thereof)
Date: Thu, 04 Jun 1998 15:38:28 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

We have found the patent writing to be more difficult than we had hoped.
Writing the background has required some reading to refresh our memories,
and some discussion.  I probably will not be able to finish until late
tonight.  The writeup of caching points (aka unit boundary identification
and clustering) is furthest along.  It is at:

/projects/dyncomp/SharedWorkingArea/Patents/caching-points.doc

I still need to finish the flow chart, define some terms, and massage the
text I pulled from the paper a little more, but it seems under control.

I think I now have an idea of what I want to write for conditional
specialization.  I don't think it will have a flow chart, but a simple
example figure.  It is a little tricky, since intraprocedural polyvariant
division is a separate section.

I'm inclinded to axe linearization from the list for the following reasons:

-- Linearization itself is not novel.  Tempo does it, though a little
   differently.

-- Based on current benchmarks, I estimate that linearization will have a
   minor impact on performance.  It is a very minor aspect of our system.

-- Linearization comprises two techniques, actually.  The actual
   "linearization", which we achieve by splitting static paths then merging
   needlessly split blocks, eliminates the intra-unit work-list pushes and pops
   for N-1 successors of an N-way dynamic branch.  The other, related idea
   is to convert the static variables to SSA.  This reduces the cost of saving
   and restoring the context at the dynamic branches.  However, since SSA is
   known, I'm not sure we can patent that portion.  Another problem is that
   this solution only works because the context only contains unaliased,
   scalar static variables.  We have not thought how to extend it to data
   stored in memory.  So, the patent would be fairly narrow (even if we could
   patent a specific application of a known technique).  The biggest problem,
   though, is that Tempo may do something very similar to this.

-- So, the novel aspect is the splitting and merging approach, which we think
   may handle unstructured code better.  However, the algorithm is inefficient
   (exponential time).

-- There doesn't seem to be time to write yet another section (which would
   include a flow chart of the algorithm).

--Brian

Date: Thu, 4 Jun 1998 15:47:07 -0700
From: eggers@yakima (Susan Eggers)
To: eggers@thistle.cs.washington.edu, grant@cs.washington.edu
Subject: Re: patent progress (or apparent lack thereof)
Cc: spin-comp@thistle.cs.washington.edu

If you are having to do some research, there is some chance you are
doing a too detailed job.  (Look a what Brian wrote as a guideline.)
Maybe you two should stop by with what you have now, just so we can
have a sanity check.  Remember, this is not the patent application, 
but a *provisional* patent application.

Markus handed in what in hindsight was very rough, but it was enough
for me to make several suggestions to flush it out.  I think we should
do the same.

Susan

Date: Fri, 5 Jun 1998 17:39:27 -0700
From: eggers@yakima (Susan Eggers)
To: pljones@u.washington.edu, spin-comp@cs
Subject: patents

Patrick and Craig --

Slowly we will be sending you our initial drafts of the provisional
patents.  Patrick, could you read them from your perspective and 
reply with changes to the whole group?  Craig, can you read them
for inaccuracies?

The first should come soon.

Thanks, Susan

Date: Fri, 5 Jun 1998 17:41:12 -0700
From: eggers@yakima (Susan Eggers)
To: pljones@u.washington.edu, spin-comp@cs
Subject: cache lookups

%!PS-Adobe-3.0
%%BoundingBox: (atend)
%%Pages: (atend)
%%PageOrder: (atend)
%%DocumentFonts: (atend)
%%Creator: Frame 4.0
%%DocumentData: Clean7Bit
%%EndComments
%%BeginProlog
%
% Frame ps_prolog 4.0, for use with Frame 4.0 products
% This ps_prolog file is Copyright (c) 1986-1993 Frame Technology
% Corporation.  All rights reserved.  This ps_prolog file may be
% freely copied and distributed in conjunction with documents created
% using FrameMaker, FrameBuilder and FrameViewer as long as this 
% copyright notice is preserved.
%
% Frame products normally print colors as their true color on a color printer
% or as shades of gray, based on luminance, on a black-and white printer. The
% following flag, if set to True, forces all non-white colors to print as pure
% black. This has no effect on bitmap images.
/FMPrintAllColorsAsBlack             false def
%
% Frame products can either set their own line screens or use a printer's 
% default settings. Three flags below control this separately for no 
% separations, spot separations and process separations. If a flag
% is true, then the default printer settings will not be changed. If it is
% false, Frame products will use their own settings from a table based on
% the printer's resolution.
/FMUseDefaultNoSeparationScreen      true  def
/FMUseDefaultSpotSeparationScreen    true  def
/FMUseDefaultProcessSeparationScreen false def
%
% For any given PostScript printer resolution, Frame products have two sets of 
% screen angles and frequencies for printing process separations, which are 
% recomended by Adobe. The following variable chooses the higher frequencies
% when set to true or the lower frequencies when set to false. This is only
% effective if the appropriate FMUseDefault...SeparationScreen flag is false.
/FMUseHighFrequencyScreens true def
%
% PostScript Level 2 printers contain an "Accurate Screens" feature which can
% improve process separation rendering at the expense of compute time. This 
% flag is ignored by PostScript Level 1 printers.
/FMUseAcccurateScreens true def
%
% The following PostScript procedure defines the spot function that Frame
% products will use for process separations. You may un-comment-out one of
% the alternative functions below, or use your own.
%
% Dot function
/FMSpotFunction {abs exch abs 2 copy add 1 gt 
		{1 sub dup mul exch 1 sub dup mul add 1 sub }
		{dup mul exch dup mul add 1 exch sub }ifelse } def
%
% Line function
% /FMSpotFunction { pop } def
%
% Elipse function
% /FMSpotFunction { dup 5 mul 8 div mul exch dup mul exch add 
%		sqrt 1 exch sub } def
%
%
/FMversion (4.0) def 
/FMLevel1 /languagelevel where {pop languagelevel} {1} ifelse 2 lt def
/FMPColor
	FMLevel1 {
		false
		/colorimage where {pop pop true} if
	} {
		true
	} ifelse
def
/FrameDict 400 dict def 
systemdict /errordict known not {/errordict 10 dict def
		errordict /rangecheck {stop} put} if
% The readline in PS 23.0 doesn't recognize cr's as nl's on AppleTalk
FrameDict /tmprangecheck errordict /rangecheck get put 
errordict /rangecheck {FrameDict /bug true put} put 
FrameDict /bug false put 
mark 
% Some PS machines read past the CR, so keep the following 3 lines together!
currentfile 5 string readline
00
0000000000
cleartomark 
errordict /rangecheck FrameDict /tmprangecheck get put 
FrameDict /bug get { 
	/readline {
		/gstring exch def
		/gfile exch def
		/gindex 0 def
		{
			gfile read pop 
			dup 10 eq {exit} if 
			dup 13 eq {exit} if 
			gstring exch gindex exch put 
			/gindex gindex 1 add def 
		} loop
		pop 
		gstring 0 gindex getinterval true 
		} bind def
	} if
/FMshowpage /showpage load def
/FMquit /quit load def
/FMFAILURE { 
	dup = flush 
	FMshowpage 
	/Helvetica findfont 12 scalefont setfont
	72 200 moveto
	show FMshowpage 
	FMquit 
	} def 
/FMVERSION {
	FMversion ne {
		(Frame product version does not match ps_prolog!) FMFAILURE
		} if
	} def 
/FMBADEPSF { 
	(PostScript Lang. Ref. Man., 2nd Ed., H.2.4 says EPS must not call X              )
	dup dup (X) search pop exch pop exch pop length 
	4 -1 roll 
	putinterval 
	FMFAILURE
	} def
/FMLOCAL {
	FrameDict begin
	0 def 
	end 
	} def 
/concatprocs
	{
	/proc2 exch cvlit def/proc1 exch cvlit def/newproc proc1 length proc2 length add array def
	newproc 0 proc1 putinterval newproc proc1 length proc2 putinterval newproc cvx
}def
FrameDict begin 
/FMnone 0 def
/FMcyan 1 def
/FMmagenta 2 def
/FMyellow 3 def
/FMblack 4 def
/FMcustom 5 def
/FrameNegative false def 
/FrameSepIs FMnone def 
/FrameSepBlack 0 def
/FrameSepYellow 0 def
/FrameSepMagenta 0 def
/FrameSepCyan 0 def
/FrameSepRed 1 def
/FrameSepGreen 1 def
/FrameSepBlue 1 def
/FrameCurGray 1 def
/FrameCurPat null def
/FrameCurColors [ 0 0 0 1 0 0 0 ] def 
/FrameColorEpsilon .001 def	
/eqepsilon {		
	sub dup 0 lt {neg} if
	FrameColorEpsilon le
} bind def
/FrameCmpColorsCMYK { 
	2 copy 0 get exch 0 get eqepsilon {
		2 copy 1 get exch 1 get eqepsilon {
			2 copy 2 get exch 2 get eqepsilon {
				3 get exch 3 get eqepsilon
			} {pop pop false} ifelse
		}{pop pop false} ifelse
	} {pop pop false} ifelse
} bind def
/FrameCmpColorsRGB { 
	2 copy 4 get exch 0 get eqepsilon {
		2 copy 5 get exch 1 get eqepsilon {
			6 get exch 2 get eqepsilon
		}{pop pop false} ifelse
	} {pop pop false} ifelse
} bind def
/RGBtoCMYK { 
	1 exch sub 
	3 1 roll 
	1 exch sub 
	3 1 roll 
	1 exch sub 
	3 1 roll 
	3 copy 
	2 copy 
	le { pop } { exch pop } ifelse 
	2 copy 
	le { pop } { exch pop } ifelse 
	dup dup dup 
	6 1 roll 
	4 1 roll 
	7 1 roll 
	sub 
	6 1 roll 
	sub 
	5 1 roll 
	sub 
	4 1 roll 
} bind def
/CMYKtoRGB { 
	dup dup 4 -1 roll add 						  
	5 1 roll 3 -1 roll add 						  
	4 1 roll add 								  
	1 exch sub dup 0 lt {pop 0} if 3 1 roll 	  
	1 exch sub dup 0 lt {pop 0} if exch 	      
	1 exch sub dup 0 lt {pop 0} if exch	  		  
} bind def
/FrameSepInit {
	1.0 RealSetgray
} bind def
/FrameSetSepColor { 
	/FrameSepBlue exch def
	/FrameSepGreen exch def
	/FrameSepRed exch def
	/FrameSepBlack exch def
	/FrameSepYellow exch def
	/FrameSepMagenta exch def
	/FrameSepCyan exch def
	/FrameSepIs FMcustom def
	setCurrentScreen	
} bind def
/FrameSetCyan {
	/FrameSepBlue 1.0 def
	/FrameSepGreen 1.0 def
	/FrameSepRed 0.0 def
	/FrameSepBlack 0.0 def
	/FrameSepYellow 0.0 def
	/FrameSepMagenta 0.0 def
	/FrameSepCyan 1.0 def
	/FrameSepIs FMcyan def
	setCurrentScreen	
} bind def
 
/FrameSetMagenta {
	/FrameSepBlue 1.0 def
	/FrameSepGreen 0.0 def
	/FrameSepRed 1.0 def
	/FrameSepBlack 0.0 def
	/FrameSepYellow 0.0 def
	/FrameSepMagenta 1.0 def
	/FrameSepCyan 0.0 def
	/FrameSepIs FMmagenta def
	setCurrentScreen
} bind def
 
/FrameSetYellow {
	/FrameSepBlue 0.0 def
	/FrameSepGreen 1.0 def
	/FrameSepRed 1.0 def
	/FrameSepBlack 0.0 def
	/FrameSepYellow 1.0 def
	/FrameSepMagenta 0.0 def
	/FrameSepCyan 0.0 def
	/FrameSepIs FMyellow def
	setCurrentScreen
} bind def
 
/FrameSetBlack {
	/FrameSepBlue 0.0 def
	/FrameSepGreen 0.0 def
	/FrameSepRed 0.0 def
	/FrameSepBlack 1.0 def
	/FrameSepYellow 0.0 def
	/FrameSepMagenta 0.0 def
	/FrameSepCyan 0.0 def
	/FrameSepIs FMblack def
	setCurrentScreen
} bind def
 
/FrameNoSep { 
	/FrameSepIs FMnone def
	setCurrentScreen
} bind def
/FrameSetSepColors { 
	FrameDict begin
	[ exch 1 add 1 roll ]
	/FrameSepColors  
	exch def end
	} bind def
/FrameColorInSepListCMYK { 
	FrameSepColors {  
       		exch dup 3 -1 roll 
       		FrameCmpColorsCMYK 
       		{ pop true exit } if
    	} forall 
	dup true ne {pop false} if
	} bind def
/FrameColorInSepListRGB { 
	FrameSepColors {  
       		exch dup 3 -1 roll 
       		FrameCmpColorsRGB 
       		{ pop true exit } if
    	} forall 
	dup true ne {pop false} if
	} bind def
/RealSetgray /setgray load def
/RealSetrgbcolor /setrgbcolor load def
/RealSethsbcolor /sethsbcolor load def
end 
/setgray { 
	FrameDict begin
	FrameSepIs FMnone eq
		{ RealSetgray } 
		{ 
		FrameSepIs FMblack eq 
			{ RealSetgray } 
			{ FrameSepIs FMcustom eq 
			  FrameSepRed 0 eq and
			  FrameSepGreen 0 eq and
			  FrameSepBlue 0 eq and {
			  	RealSetgray
			  } {
				1 RealSetgray pop 
			  } ifelse
			} ifelse
		} ifelse
	end
} bind def
/setrgbcolor { 
	FrameDict begin
	FrameSepIs FMnone eq
	{  RealSetrgbcolor }
	{
		3 copy [ 4 1 roll ] 
		FrameColorInSepListRGB
		{
				FrameSepBlue eq exch 
			 	FrameSepGreen eq and exch 
			 	FrameSepRed eq and
			 	{ 0 } { 1 } ifelse
		}
		{
			FMPColor {
				RealSetrgbcolor
				currentcmykcolor
			} {
				RGBtoCMYK
			} ifelse
			FrameSepIs FMblack eq
			{1.0 exch sub 4 1 roll pop pop pop} {
			FrameSepIs FMyellow eq
			{pop 1.0 exch sub 3 1 roll pop pop} {
			FrameSepIs FMmagenta eq
			{pop pop 1.0 exch sub exch pop } {
			FrameSepIs FMcyan eq
			{pop pop pop 1.0 exch sub } 
			{pop pop pop pop 1} ifelse } ifelse } ifelse } ifelse 
		} ifelse
		RealSetgray
	} 
	ifelse
	end
} bind def
/sethsbcolor {
	FrameDict begin
	FrameSepIs FMnone eq 
	{ RealSethsbcolor } 
	{
		RealSethsbcolor 
		currentrgbcolor  
		setrgbcolor 
	} 
	ifelse
	end
} bind def
FrameDict begin
/setcmykcolor where {
	pop /RealSetcmykcolor /setcmykcolor load def
} {
	/RealSetcmykcolor {
		4 1 roll
		3 { 3 index add 0 max 1 min 1 exch sub 3 1 roll} repeat 
		setrgbcolor pop
	} bind def
} ifelse
userdict /setcmykcolor { 
		FrameDict begin
		FrameSepIs FMnone eq
		{ RealSetcmykcolor } 
		{
			4 copy [ 5 1 roll ]
			FrameColorInSepListCMYK
			{
				FrameSepBlack eq exch 
				FrameSepYellow eq and exch 
				FrameSepMagenta eq and exch 
				FrameSepCyan eq and 
				{ 0 } { 1 } ifelse
			}
			{
				FrameSepIs FMblack eq
				{1.0 exch sub 4 1 roll pop pop pop} {
				FrameSepIs FMyellow eq
				{pop 1.0 exch sub 3 1 roll pop pop} {
				FrameSepIs FMmagenta eq
				{pop pop 1.0 exch sub exch pop } {
				FrameSepIs FMcyan eq
				{pop pop pop 1.0 exch sub } 
				{pop pop pop pop 1} ifelse } ifelse } ifelse } ifelse 
			} ifelse
			RealSetgray
		}
		ifelse
		end
	} bind put
FMLevel1 not { 
	
	/patProcDict 5 dict dup begin
		<0f1e3c78f0e1c387> { 3 setlinewidth -1 -1 moveto 9 9 lineto stroke 
											4 -4 moveto 12 4 lineto stroke
											-4 4 moveto 4 12 lineto stroke} bind def
		<0f87c3e1f0783c1e> { 3 setlinewidth -1 9 moveto 9 -1 lineto stroke 
											-4 4 moveto 4 -4 lineto stroke
											4 12 moveto 12 4 lineto stroke} bind def
		<8142241818244281> { 1 setlinewidth -1 9 moveto 9 -1 lineto stroke
											-1 -1 moveto 9 9 lineto stroke } bind def
		<03060c183060c081> { 1 setlinewidth -1 -1 moveto 9 9 lineto stroke 
											4 -4 moveto 12 4 lineto stroke
											-4 4 moveto 4 12 lineto stroke} bind def
		<8040201008040201> { 1 setlinewidth -1 9 moveto 9 -1 lineto stroke 
											-4 4 moveto 4 -4 lineto stroke
											4 12 moveto 12 4 lineto stroke} bind def
	end def
	/patDict 15 dict dup begin
		/PatternType 1 def		
		/PaintType 2 def		
		/TilingType 3 def		
		/BBox [ 0 0 8 8 ] def 	
		/XStep 8 def			
		/YStep 8 def			
		/PaintProc {
			begin
			patProcDict bstring known {
				patProcDict bstring get exec
			} {
				8 8 true [1 0 0 -1 0 8] bstring imagemask
			} ifelse
			end
		} bind def
	end def
} if
/combineColor {
    FrameSepIs FMnone eq
	{
		graymode FMLevel1 or not {
			
			[/Pattern [/DeviceCMYK]] setcolorspace
			FrameCurColors 0 4 getinterval aload pop FrameCurPat setcolor
		} {
			FrameCurColors 3 get 1.0 ge {
				FrameCurGray RealSetgray
			} {
				FMPColor graymode and {
					0 1 3 { 
						FrameCurColors exch get
						1 FrameCurGray sub mul
					} for
					RealSetcmykcolor
				} {
					4 1 6 {
						FrameCurColors exch get
						graymode {
							1 exch sub 1 FrameCurGray sub mul 1 exch sub
						} {
							1.0 lt {FrameCurGray} {1} ifelse
						} ifelse
					} for
					RealSetrgbcolor
				} ifelse
			} ifelse
		} ifelse
	} { 
		FrameCurColors 0 4 getinterval aload
		FrameColorInSepListCMYK {
			FrameSepBlack eq exch 
			FrameSepYellow eq and exch 
			FrameSepMagenta eq and exch 
			FrameSepCyan eq and
			FrameSepIs FMcustom eq and
			{ FrameCurGray } { 1 } ifelse
		} {
			FrameSepIs FMblack eq
			{FrameCurGray 1.0 exch sub mul 1.0 exch sub 4 1 roll pop pop pop} {
			FrameSepIs FMyellow eq
			{pop FrameCurGray 1.0 exch sub mul 1.0 exch sub 3 1 roll pop pop} {
			FrameSepIs FMmagenta eq
			{pop pop FrameCurGray 1.0 exch sub mul 1.0 exch sub exch pop } {
			FrameSepIs FMcyan eq
			{pop pop pop FrameCurGray 1.0 exch sub mul 1.0 exch sub } 
			{pop pop pop pop 1} ifelse } ifelse } ifelse } ifelse 
		} ifelse
		graymode FMLevel1 or not {
			
			[/Pattern [/DeviceGray]] setcolorspace
			FrameCurPat setcolor
		} { 
			graymode not FMLevel1 and {
				
				dup 1 lt {pop FrameCurGray} if
			} if
			RealSetgray
		} ifelse
	} ifelse
} bind def
/savematrix {
	orgmatrix currentmatrix pop
	} bind def
/restorematrix {
	orgmatrix setmatrix
	} bind def
/dmatrix matrix def
/dpi    72 0 dmatrix defaultmatrix dtransform
    dup mul exch   dup mul add   sqrt def
	
/freq dpi dup 72 div round dup 0 eq {pop 1} if 8 mul div def
/sangle 1 0 dmatrix defaultmatrix dtransform exch atan def
/dpiranges   [  2540    2400    1693     1270    1200     635      600      0      ] def
/CMLowFreqs  [ 100.402  94.8683 89.2289 100.402  94.8683  66.9349  63.2456 47.4342 ] def
/YLowFreqs   [  95.25   90.0    84.65    95.25   90.0     70.5556  66.6667 50.0    ] def
/KLowFreqs   [  89.8026 84.8528 79.8088  89.8026 84.8528  74.8355  70.7107 53.033  ] def
/CLowAngles  [  71.5651 71.5651 71.5651 71.5651  71.5651  71.5651  71.5651 71.5651 ] def
/MLowAngles  [  18.4349 18.4349 18.4349 18.4349  18.4349  18.4349  18.4349 18.4349 ] def
/YLowTDot    [  true    true    false    true    true     false    false   false   ] def
/CMHighFreqs [ 133.87  126.491 133.843  108.503 102.523  100.402   94.8683 63.2456 ] def
/YHighFreqs  [ 127.0   120.0   126.975  115.455 109.091   95.25    90.0    60.0    ] def
/KHighFreqs  [ 119.737 113.137 119.713  128.289 121.218   89.8026  84.8528 63.6395 ] def
/CHighAngles [  71.5651 71.5651 71.5651  70.0169 70.0169  71.5651  71.5651 71.5651 ] def
/MHighAngles [  18.4349 18.4349 18.4349  19.9831 19.9831  18.4349  18.4349 18.4349 ] def
/YHighTDot   [  false   false   true     false   false    true     true    false   ] def
/PatFreq     [	10.5833 10.0     9.4055  10.5833 10.0	  10.5833  10.0	   9.375   ] def
/screenIndex {
	0 1 dpiranges length 1 sub { dup dpiranges exch get 1 sub dpi le {exit} {pop} ifelse } for
} bind def
/getCyanScreen {
	FMUseHighFrequencyScreens { CHighAngles CMHighFreqs} {CLowAngles CMLowFreqs} ifelse
		screenIndex dup 3 1 roll get 3 1 roll get /FMSpotFunction load
} bind def
/getMagentaScreen {
	FMUseHighFrequencyScreens { MHighAngles CMHighFreqs } {MLowAngles CMLowFreqs} ifelse
		screenIndex dup 3 1 roll get 3 1 roll get /FMSpotFunction load
} bind def
/getYellowScreen {
	FMUseHighFrequencyScreens { YHighTDot YHighFreqs} { YLowTDot YLowFreqs } ifelse
		screenIndex dup 3 1 roll get 3 1 roll get { 3 div
			{2 { 1 add 2 div 3 mul dup floor sub 2 mul 1 sub exch} repeat
			FMSpotFunction } } {/FMSpotFunction load } ifelse
			0.0 exch
} bind def
/getBlackScreen  {
	FMUseHighFrequencyScreens { KHighFreqs } { KLowFreqs } ifelse
		screenIndex get 45.0 /FMSpotFunction load 
} bind def
/getSpotScreen {
	getBlackScreen
} bind def
/getCompositeScreen {
	getBlackScreen
} bind def
/FMSetScreen 
	FMLevel1 { /setscreen load 
	}{ {
		8 dict begin
		/HalftoneType 1 def
		/SpotFunction exch def
		/Angle exch def
		/Frequency exch def
		/AccurateScreens FMUseAcccurateScreens def
		currentdict end sethalftone
	} bind } ifelse
def
/setDefaultScreen {
	FMPColor {
		orgrxfer cvx orggxfer cvx orgbxfer cvx orgxfer cvx setcolortransfer
	}
	{
		orgxfer cvx settransfer
	} ifelse
	orgfreq organgle orgproc cvx setscreen
} bind def
/setCurrentScreen {
	FrameSepIs FMnone eq {
		FMUseDefaultNoSeparationScreen {
			setDefaultScreen
		} {
			getCompositeScreen FMSetScreen
		} ifelse
	} {
		FrameSepIs FMcustom eq {
			FMUseDefaultSpotSeparationScreen {
				setDefaultScreen
			} {
				getSpotScreen FMSetScreen
			} ifelse
		} {
			FMUseDefaultProcessSeparationScreen {
				setDefaultScreen
			} {
				FrameSepIs FMcyan eq {
					getCyanScreen FMSetScreen
				} {
					FrameSepIs FMmagenta eq {
						getMagentaScreen FMSetScreen
					} {
						FrameSepIs FMyellow eq {
							getYellowScreen FMSetScreen
						} {
							getBlackScreen FMSetScreen
						} ifelse
					} ifelse
				} ifelse
			} ifelse
		} ifelse
	} ifelse 
} bind def
end
	/gstring FMLOCAL
	/gfile FMLOCAL
	/gindex FMLOCAL
	/orgrxfer FMLOCAL
	/orggxfer FMLOCAL
	/orgbxfer FMLOCAL
	/orgxfer FMLOCAL
	/orgproc FMLOCAL
	/orgrproc FMLOCAL
	/orggproc FMLOCAL
	/orgbproc FMLOCAL
	/organgle FMLOCAL
	/orgrangle FMLOCAL
	/orggangle FMLOCAL
	/orgbangle FMLOCAL
	/orgfreq FMLOCAL
	/orgrfreq FMLOCAL
	/orggfreq FMLOCAL
	/orgbfreq FMLOCAL
	/yscale FMLOCAL
	/xscale FMLOCAL
	/edown FMLOCAL
	/manualfeed FMLOCAL
	/paperheight FMLOCAL
	/paperwidth FMLOCAL
/FMDOCUMENT { 
	array /FMfonts exch def 
	/#copies exch def
	FrameDict begin
	0 ne /manualfeed exch def
	/paperheight exch def
	/paperwidth exch def
	0 ne /FrameNegative exch def 
	0 ne /edown exch def 
	/yscale exch def
	/xscale exch def
	FMLevel1 {
		manualfeed {setmanualfeed} if
		/FMdicttop countdictstack 1 add def 
		/FMoptop count def 
		setpapername 
		manualfeed {true} {papersize} ifelse 
		{manualpapersize} {false} ifelse 
		{desperatepapersize} {false} ifelse 
		{ (Can't select requested paper size for Frame print job!) FMFAILURE } if
		count -1 FMoptop {pop pop} for
		countdictstack -1 FMdicttop {pop end} for 
		}
		{{1 dict dup /PageSize [paperwidth paperheight]put setpagedevice}stopped
		{ (Can't select requested paper size for Frame print job!) FMFAILURE } if
		 {1 dict dup /ManualFeed manualfeed put setpagedevice } stopped pop }
	ifelse 
	
	FMPColor {
		currentcolorscreen
			cvlit /orgproc exch def
				  /organgle exch def 
				  /orgfreq exch def
			cvlit /orgbproc exch def
				  /orgbangle exch def 
				  /orgbfreq exch def
			cvlit /orggproc exch def
				  /orggangle exch def 
				  /orggfreq exch def
			cvlit /orgrproc exch def
				  /orgrangle exch def 
				  /orgrfreq exch def
			currentcolortransfer 
			FrameNegative {
				1 1 4 { 
					pop { 1 exch sub } concatprocs 4 1 roll
				} for
				4 copy
				setcolortransfer
			} if
			cvlit /orgxfer exch def
			cvlit /orgbxfer exch def
			cvlit /orggxfer exch def
			cvlit /orgrxfer exch def
	} {
		currentscreen 
			cvlit /orgproc exch def
				  /organgle exch def 
				  /orgfreq exch def
				  
		currenttransfer 
		FrameNegative {
			{ 1 exch sub } concatprocs
			dup settransfer
		} if 
		cvlit /orgxfer exch def
	} ifelse
	end 
} def 
/pagesave FMLOCAL
/orgmatrix FMLOCAL
/landscape FMLOCAL
/pwid FMLOCAL
/FMBEGINPAGE { 
	FrameDict begin 
	/pagesave save def
	3.86 setmiterlimit
	/landscape exch 0 ne def
	landscape { 
		90 rotate 0 exch dup /pwid exch def neg translate pop 
	}{
		pop /pwid exch def
	} ifelse
	edown { [-1 0 0 1 pwid 0] concat } if
	0 0 moveto paperwidth 0 lineto paperwidth paperheight lineto 
	0 paperheight lineto 0 0 lineto 1 setgray fill
	xscale yscale scale
	/orgmatrix matrix def
	gsave 
} def 
/FMENDPAGE {
	grestore 
	pagesave restore
	end 
	showpage
	} def 
/FMFONTDEFINE { 
	FrameDict begin
	findfont 
	ReEncode 
	1 index exch 
	definefont 
	FMfonts 3 1 roll 
	put
	end 
	} def 
/FMFILLS {
	FrameDict begin dup
	array /fillvals exch def
	dict /patCache exch def
	end 
	} def 
/FMFILL {
	FrameDict begin
	 fillvals 3 1 roll put
	end 
	} def 
/FMNORMALIZEGRAPHICS { 
	newpath
	0.0 0.0 moveto
	1 setlinewidth
	0 setlinecap
	0 0 0 sethsbcolor
	0 setgray 
	} bind def
	/fx FMLOCAL
	/fy FMLOCAL
	/fh FMLOCAL
	/fw FMLOCAL
	/llx FMLOCAL
	/lly FMLOCAL
	/urx FMLOCAL
	/ury FMLOCAL
/FMBEGINEPSF { 
	end 
	/FMEPSF save def 
	/showpage {} def 
% See Adobe's "PostScript Language Reference Manual, 2nd Edition", page 714.
% "...the following operators MUST NOT be used in an EPS file:" (emphasis ours)
	/banddevice {(banddevice) FMBADEPSF} def
	/clear {(clear) FMBADEPSF} def
	/cleardictstack {(cleardictstack) FMBADEPSF} def 
	/copypage {(copypage) FMBADEPSF} def
	/erasepage {(erasepage) FMBADEPSF} def
	/exitserver {(exitserver) FMBADEPSF} def
	/framedevice {(framedevice) FMBADEPSF} def
	/grestoreall {(grestoreall) FMBADEPSF} def
	/initclip {(initclip) FMBADEPSF} def
	/initgraphics {(initgraphics) FMBADEPSF} def
	/initmatrix {(initmatrix) FMBADEPSF} def
	/quit {(quit) FMBADEPSF} def
	/renderbands {(renderbands) FMBADEPSF} def
	/setglobal {(setglobal) FMBADEPSF} def
	/setpagedevice {(setpagedevice) FMBADEPSF} def
	/setshared {(setshared) FMBADEPSF} def
	/startjob {(startjob) FMBADEPSF} def
	/lettertray {(lettertray) FMBADEPSF} def
	/letter {(letter) FMBADEPSF} def
	/lettersmall {(lettersmall) FMBADEPSF} def
	/11x17tray {(11x17tray) FMBADEPSF} def
	/11x17 {(11x17) FMBADEPSF} def
	/ledgertray {(ledgertray) FMBADEPSF} def
	/ledger {(ledger) FMBADEPSF} def
	/legaltray {(legaltray) FMBADEPSF} def
	/legal {(legal) FMBADEPSF} def
	/statementtray {(statementtray) FMBADEPSF} def
	/statement {(statement) FMBADEPSF} def
	/executivetray {(executivetray) FMBADEPSF} def
	/executive {(executive) FMBADEPSF} def
	/a3tray {(a3tray) FMBADEPSF} def
	/a3 {(a3) FMBADEPSF} def
	/a4tray {(a4tray) FMBADEPSF} def
	/a4 {(a4) FMBADEPSF} def
	/a4small {(a4small) FMBADEPSF} def
	/b4tray {(b4tray) FMBADEPSF} def
	/b4 {(b4) FMBADEPSF} def
	/b5tray {(b5tray) FMBADEPSF} def
	/b5 {(b5) FMBADEPSF} def
	FMNORMALIZEGRAPHICS 
	[/fy /fx /fh /fw /ury /urx /lly /llx] {exch def} forall 
	fx fw 2 div add fy fh 2 div add  translate
	rotate
	fw 2 div neg fh 2 div neg translate
	fw urx llx sub div fh ury lly sub div scale 
	llx neg lly neg translate 
	/FMdicttop countdictstack 1 add def 
	/FMoptop count def 
	} bind def
/FMENDEPSF {
	count -1 FMoptop {pop pop} for 
	countdictstack -1 FMdicttop {pop end} for 
	FMEPSF restore
	FrameDict begin 
	} bind def
FrameDict begin 
/setmanualfeed {
%%BeginFeature *ManualFeed True
	 statusdict /manualfeed true put
%%EndFeature
	} bind def
/max {2 copy lt {exch} if pop} bind def
/min {2 copy gt {exch} if pop} bind def
/inch {72 mul} def
/pagedimen { 
	paperheight sub abs 16 lt exch 
	paperwidth sub abs 16 lt and
	{/papername exch def} {pop} ifelse
	} bind def
	/papersizedict FMLOCAL
/setpapername { 
	/papersizedict 14 dict def 
	papersizedict begin
	/papername /unknown def 
		/Letter 8.5 inch 11.0 inch pagedimen
		/LetterSmall 7.68 inch 10.16 inch pagedimen
		/Tabloid 11.0 inch 17.0 inch pagedimen
		/Ledger 17.0 inch 11.0 inch pagedimen
		/Legal 8.5 inch 14.0 inch pagedimen
		/Statement 5.5 inch 8.5 inch pagedimen
		/Executive 7.5 inch 10.0 inch pagedimen
		/A3 11.69 inch 16.5 inch pagedimen
		/A4 8.26 inch 11.69 inch pagedimen
		/A4Small 7.47 inch 10.85 inch pagedimen
		/B4 10.125 inch 14.33 inch pagedimen
		/B5 7.16 inch 10.125 inch pagedimen
	end
	} bind def
/papersize {
	papersizedict begin
		/Letter {lettertray letter} def
		/LetterSmall {lettertray lettersmall} def
		/Tabloid {11x17tray 11x17} def
		/Ledger {ledgertray ledger} def
		/Legal {legaltray legal} def
		/Statement {statementtray statement} def
		/Executive {executivetray executive} def
		/A3 {a3tray a3} def
		/A4 {a4tray a4} def
		/A4Small {a4tray a4small} def
		/B4 {b4tray b4} def
		/B5 {b5tray b5} def
		/unknown {unknown} def
	papersizedict dup papername known {papername} {/unknown} ifelse get
	end
	statusdict begin stopped end 
	} bind def
/manualpapersize {
	papersizedict begin
		/Letter {letter} def
		/LetterSmall {lettersmall} def
		/Tabloid {11x17} def
		/Ledger {ledger} def
		/Legal {legal} def
		/Statement {statement} def
		/Executive {executive} def
		/A3 {a3} def
		/A4 {a4} def
		/A4Small {a4small} def
		/B4 {b4} def
		/B5 {b5} def
		/unknown {unknown} def
	papersizedict dup papername known {papername} {/unknown} ifelse get
	end
	stopped 
	} bind def
/desperatepapersize {
	statusdict /setpageparams known
		{
		paperwidth paperheight 0 1 
		statusdict begin
		{setpageparams} stopped 
		end
		} {true} ifelse 
	} bind def
/DiacriticEncoding [
/.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef
/.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef
/.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef
/.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef
/.notdef /.notdef /.notdef /.notdef /space /exclam /quotedbl
/numbersign /dollar /percent /ampersand /quotesingle /parenleft
/parenright /asterisk /plus /comma /hyphen /period /slash /zero /one
/two /three /four /five /six /seven /eight /nine /colon /semicolon
/less /equal /greater /question /at /A /B /C /D /E /F /G /H /I /J /K
/L /M /N /O /P /Q /R /S /T /U /V /W /X /Y /Z /bracketleft /backslash
/bracketright /asciicircum /underscore /grave /a /b /c /d /e /f /g /h
/i /j /k /l /m /n /o /p /q /r /s /t /u /v /w /x /y /z /braceleft /bar
/braceright /asciitilde /.notdef /Adieresis /Aring /Ccedilla /Eacute
/Ntilde /Odieresis /Udieresis /aacute /agrave /acircumflex /adieresis
/atilde /aring /ccedilla /eacute /egrave /ecircumflex /edieresis
/iacute /igrave /icircumflex /idieresis /ntilde /oacute /ograve
/ocircumflex /odieresis /otilde /uacute /ugrave /ucircumflex
/udieresis /dagger /.notdef /cent /sterling /section /bullet
/paragraph /germandbls /registered /copyright /trademark /acute
/dieresis /.notdef /AE /Oslash /.notdef /.notdef /.notdef /.notdef
/yen /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef
/ordfeminine /ordmasculine /.notdef /ae /oslash /questiondown
/exclamdown /logicalnot /.notdef /florin /.notdef /.notdef
/guillemotleft /guillemotright /ellipsis /.notdef /Agrave /Atilde
/Otilde /OE /oe /endash /emdash /quotedblleft /quotedblright
/quoteleft /quoteright /.notdef /.notdef /ydieresis /Ydieresis
/fraction /currency /guilsinglleft /guilsinglright /fi /fl /daggerdbl
/periodcentered /quotesinglbase /quotedblbase /perthousand
/Acircumflex /Ecircumflex /Aacute /Edieresis /Egrave /Iacute
/Icircumflex /Idieresis /Igrave /Oacute /Ocircumflex /.notdef /Ograve
/Uacute /Ucircumflex /Ugrave /dotlessi /circumflex /tilde /macron
/breve /dotaccent /ring /cedilla /hungarumlaut /ogonek /caron
] def
/ReEncode { 
	dup 
	length 
	dict begin 
	{
	1 index /FID ne 
		{def} 
		{pop pop} ifelse 
	} forall 
	0 eq {/Encoding DiacriticEncoding def} if 
	currentdict 
	end 
	} bind def
FMPColor 
	
	{
	/BEGINBITMAPCOLOR { 
		BITMAPCOLOR} def
	/BEGINBITMAPCOLORc { 
		BITMAPCOLORc} def
	/BEGINBITMAPTRUECOLOR { 
		BITMAPTRUECOLOR } def
	/BEGINBITMAPTRUECOLORc { 
		BITMAPTRUECOLORc } def
	}
	
	{
	/BEGINBITMAPCOLOR { 
		BITMAPGRAY} def
	/BEGINBITMAPCOLORc { 
		BITMAPGRAYc} def
	/BEGINBITMAPTRUECOLOR { 
		BITMAPTRUEGRAY } def
	/BEGINBITMAPTRUECOLORc { 
		BITMAPTRUEGRAYc } def
	}
ifelse
/K { 
	FMPrintAllColorsAsBlack {
		dup 1 eq 2 index 1 eq and 3 index 1 eq and not
			{7 {pop} repeat 0 0 0 1 0 0 0} if
	} if 
	FrameCurColors astore 
	pop combineColor
} bind def
/graymode true def
	/bwidth FMLOCAL
	/bpside FMLOCAL
	/bstring FMLOCAL
	/onbits FMLOCAL
	/offbits FMLOCAL
	/xindex FMLOCAL
	/yindex FMLOCAL
	/x FMLOCAL
	/y FMLOCAL
/setPatternMode {
	FMLevel1 {
		/bwidth  exch def
		/bpside  exch def
		/bstring exch def
		/onbits 0 def  /offbits 0 def
		freq sangle landscape {90 add} if 
			{/y exch def
			 /x exch def
			 /xindex x 1 add 2 div bpside mul cvi def
			 /yindex y 1 add 2 div bpside mul cvi def
			 bstring yindex bwidth mul xindex 8 idiv add get
			 1 7 xindex 8 mod sub bitshift and 0 ne FrameNegative {not} if
			 {/onbits  onbits  1 add def 1}
			 {/offbits offbits 1 add def 0}
			 ifelse
			}
			setscreen
		offbits offbits onbits add div FrameNegative {1.0 exch sub} if
		/FrameCurGray exch def
	} { 
		pop pop
		dup patCache exch known {
			patCache exch get
		} { 
			dup
			patDict /bstring 3 -1 roll put
			patDict 
			9 PatFreq screenIndex get div dup matrix scale
			makepattern
			dup 
			patCache 4 -1 roll 3 -1 roll put
		} ifelse
		/FrameCurGray 0 def
		/FrameCurPat exch def
	} ifelse
	/graymode false def
	combineColor
} bind def
/setGrayScaleMode {
	graymode not {
		/graymode true def
		FMLevel1 {
			setCurrentScreen
		} if
	} if
	/FrameCurGray exch def
	combineColor
} bind def
/normalize {
	transform round exch round exch itransform
	} bind def
/dnormalize {
	dtransform round exch round exch idtransform
	} bind def
/lnormalize { 
	0 dtransform exch cvi 2 idiv 2 mul 1 add exch idtransform pop
	} bind def
/H { 
	lnormalize setlinewidth
	} bind def
/Z {
	setlinecap
	} bind def
	
/PFill {
	graymode FMLevel1 or not {
		gsave 1 setgray eofill grestore
	} if
} bind def
/PStroke {
	graymode FMLevel1 or not {
		gsave 1 setgray stroke grestore
	} if
	stroke
} bind def
	/fillvals FMLOCAL
/X { 
	fillvals exch get
	dup type /stringtype eq
	{8 1 setPatternMode} 
	{setGrayScaleMode}
	ifelse
	} bind def
/V { 
	PFill gsave eofill grestore
	} bind def
/Vclip {
	clip
	} bind def
/Vstrk {
	currentlinewidth exch setlinewidth PStroke setlinewidth
	} bind def
/N { 
	PStroke
	} bind def
/Nclip {
	strokepath clip newpath
	} bind def
/Nstrk {
	currentlinewidth exch setlinewidth PStroke setlinewidth
	} bind def
/M {newpath moveto} bind def
/E {lineto} bind def
/D {curveto} bind def
/O {closepath} bind def
	/n FMLOCAL
/L { 
 	/n exch def
	newpath
	normalize
	moveto 
	2 1 n {pop normalize lineto} for
	} bind def
/Y { 
	L 
	closepath
	} bind def
	/x1 FMLOCAL
	/x2 FMLOCAL
	/y1 FMLOCAL
	/y2 FMLOCAL
/R { 
	/y2 exch def
	/x2 exch def
	/y1 exch def
	/x1 exch def
	x1 y1
	x2 y1
	x2 y2
	x1 y2
	4 Y 
	} bind def
	/rad FMLOCAL
/rarc 
	{rad 
	 arcto
	} bind def
/RR { 
	/rad exch def
	normalize
	/y2 exch def
	/x2 exch def
	normalize
	/y1 exch def
	/x1 exch def
	mark
	newpath
	{
	x1 y1 rad add moveto
	x1 y2 x2 y2 rarc
	x2 y2 x2 y1 rarc
	x2 y1 x1 y1 rarc
	x1 y1 x1 y2 rarc
	closepath
	} stopped {x1 y1 x2 y2 R} if 
	cleartomark
	} bind def
/RRR { 
	/rad exch def
	normalize /y4 exch def /x4 exch def
	normalize /y3 exch def /x3 exch def
	normalize /y2 exch def /x2 exch def
	normalize /y1 exch def /x1 exch def
	newpath
	normalize moveto 
	mark
	{
	x2 y2 x3 y3 rarc
	x3 y3 x4 y4 rarc
	x4 y4 x1 y1 rarc
	x1 y1 x2 y2 rarc
	closepath
	} stopped
	 {x1 y1 x2 y2 x3 y3 x4 y4 newpath moveto lineto lineto lineto closepath} if
	cleartomark
	} bind def
/C { 
	grestore
	gsave
	R 
	clip
	setCurrentScreen
} bind def
/CP { 
	grestore
	gsave
	Y 
	clip
	setCurrentScreen
} bind def
	/FMpointsize FMLOCAL
/F { 
	FMfonts exch get
	FMpointsize scalefont
	setfont
	} bind def
/Q { 
	/FMpointsize exch def
	F 
	} bind def
/T { 
	moveto show
	} bind def
/RF { 
	rotate
	0 ne {-1 1 scale} if
	} bind def
/TF { 
	gsave
	moveto 
	RF
	show
	grestore
	} bind def
/P { 
	moveto
	0 32 3 2 roll widthshow
	} bind def
/PF { 
	gsave
	moveto 
	RF
	0 32 3 2 roll widthshow
	grestore
	} bind def
/S { 
	moveto
	0 exch ashow
	} bind def
/SF { 
	gsave
	moveto
	RF
	0 exch ashow
	grestore
	} bind def
/B { 
	moveto
	0 32 4 2 roll 0 exch awidthshow
	} bind def
/BF { 
	gsave
	moveto
	RF
	0 32 4 2 roll 0 exch awidthshow
	grestore
	} bind def
/G { 
	gsave
	newpath
	normalize translate 0.0 0.0 moveto 
	dnormalize scale 
	0.0 0.0 1.0 5 3 roll arc 
	closepath 
	PFill fill
	grestore
	} bind def
/Gstrk {
	savematrix
    newpath
    2 index 2 div add exch 3 index 2 div sub exch 
    normalize 2 index 2 div sub exch 3 index 2 div add exch 
    translate
    scale 
    0.0 0.0 1.0 5 3 roll arc 
    restorematrix
    currentlinewidth exch setlinewidth PStroke setlinewidth
    } bind def
/Gclip { 
	newpath
	savematrix
	normalize translate 0.0 0.0 moveto 
	dnormalize scale 
	0.0 0.0 1.0 5 3 roll arc 
	closepath 
	clip newpath
	restorematrix
	} bind def
/GG { 
	gsave
	newpath
	normalize translate 0.0 0.0 moveto 
	rotate 
	dnormalize scale 
	0.0 0.0 1.0 5 3 roll arc 
	closepath
	PFill
	fill
	grestore
	} bind def
/GGclip { 
	savematrix
	newpath
    normalize translate 0.0 0.0 moveto 
    rotate 
    dnormalize scale 
    0.0 0.0 1.0 5 3 roll arc 
    closepath
	clip newpath
	restorematrix
	} bind def
/GGstrk { 
	savematrix
    newpath
    normalize translate 0.0 0.0 moveto 
    rotate 
    dnormalize scale 
    0.0 0.0 1.0 5 3 roll arc 
    closepath 
	restorematrix
    currentlinewidth exch setlinewidth PStroke setlinewidth
	} bind def
/A { 
	gsave
	savematrix
	newpath
	2 index 2 div add exch 3 index 2 div sub exch 
	normalize 2 index 2 div sub exch 3 index 2 div add exch 
	translate 
	scale 
	0.0 0.0 1.0 5 3 roll arc 
	restorematrix
	PStroke
	grestore
	} bind def
/Aclip {
	newpath
	savematrix
	normalize translate 0.0 0.0 moveto 
	dnormalize scale 
	0.0 0.0 1.0 5 3 roll arc 
	closepath 
	strokepath clip newpath
	restorematrix
} bind def
/Astrk {
	Gstrk
} bind def
/AA { 
	gsave
	savematrix
	newpath
	
	3 index 2 div add exch 4 index 2 div sub exch 
	
	normalize 3 index 2 div sub exch 4 index 2 div add exch
	translate 
	rotate 
	scale 
	0.0 0.0 1.0 5 3 roll arc 
	restorematrix
	PStroke
	grestore
	} bind def
/AAclip {
	savematrix
	newpath
    normalize translate 0.0 0.0 moveto 
    rotate 
    dnormalize scale 
    0.0 0.0 1.0 5 3 roll arc 
    closepath
	strokepath clip newpath
	restorematrix
} bind def
/AAstrk {
	GGstrk
} bind def
	/x FMLOCAL
	/y FMLOCAL
	/w FMLOCAL
	/h FMLOCAL
	/xx FMLOCAL
	/yy FMLOCAL
	/ww FMLOCAL
	/hh FMLOCAL
	/FMsaveobject FMLOCAL
	/FMoptop FMLOCAL
	/FMdicttop FMLOCAL
/BEGINPRINTCODE { 
	/FMdicttop countdictstack 1 add def 
	/FMoptop count 7 sub def 
	/FMsaveobject save def
	userdict begin 
	/showpage {} def 
	FMNORMALIZEGRAPHICS 
	3 index neg 3 index neg translate
	} bind def
/ENDPRINTCODE {
	count -1 FMoptop {pop pop} for 
	countdictstack -1 FMdicttop {pop end} for 
	FMsaveobject restore 
	} bind def
/gn { 
	0 
	{	46 mul 
		cf read pop 
		32 sub 
		dup 46 lt {exit} if 
		46 sub add 
		} loop
	add 
	} bind def
	/str FMLOCAL
/cfs { 
	/str sl string def 
	0 1 sl 1 sub {str exch val put} for 
	str def 
	} bind def
/ic [ 
	0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0223
	0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0223
	0
	{0 hx} {1 hx} {2 hx} {3 hx} {4 hx} {5 hx} {6 hx} {7 hx} {8 hx} {9 hx}
	{10 hx} {11 hx} {12 hx} {13 hx} {14 hx} {15 hx} {16 hx} {17 hx} {18 hx}
	{19 hx} {gn hx} {0} {1} {2} {3} {4} {5} {6} {7} {8} {9} {10} {11} {12}
	{13} {14} {15} {16} {17} {18} {19} {gn} {0 wh} {1 wh} {2 wh} {3 wh}
	{4 wh} {5 wh} {6 wh} {7 wh} {8 wh} {9 wh} {10 wh} {11 wh} {12 wh}
	{13 wh} {14 wh} {gn wh} {0 bl} {1 bl} {2 bl} {3 bl} {4 bl} {5 bl} {6 bl}
	{7 bl} {8 bl} {9 bl} {10 bl} {11 bl} {12 bl} {13 bl} {14 bl} {gn bl}
	{0 fl} {1 fl} {2 fl} {3 fl} {4 fl} {5 fl} {6 fl} {7 fl} {8 fl} {9 fl}
	{10 fl} {11 fl} {12 fl} {13 fl} {14 fl} {gn fl}
	] def
	/sl FMLOCAL
	/val FMLOCAL
	/ws FMLOCAL
	/im FMLOCAL
	/bs FMLOCAL
	/cs FMLOCAL
	/len FMLOCAL
	/pos FMLOCAL
/ms { 
	/sl exch def 
	/val 255 def 
	/ws cfs 
	/im cfs 
	/val 0 def 
	/bs cfs 
	/cs cfs 
	} bind def
400 ms 
/ip { 
	is 
	0 
	cf cs readline pop 
	{	ic exch get exec 
		add 
		} forall 
	pop 
	
	} bind def
/rip { 
	   
	  
	  bis ris copy pop 
      is
      0
      cf cs readline pop 
      {       ic exch get exec 
              add 
              } forall 
	  pop pop 
	  ris gis copy pop 
	  dup is exch 
	  
      cf cs readline pop 
      {       ic exch get exec 
              add 
              } forall 
	  pop pop
	  gis bis copy pop 
	  dup add is exch 
	  
      cf cs readline pop 
      {       ic exch get exec 
              add 
              } forall 
      pop 
      
      } bind def
/wh { 
	/len exch def 
	/pos exch def 
	ws 0 len getinterval im pos len getinterval copy pop
	pos len 
	} bind def
/bl { 
	/len exch def 
	/pos exch def 
	bs 0 len getinterval im pos len getinterval copy pop
	pos len 
	} bind def
/s1 1 string def
/fl { 
	/len exch def 
	/pos exch def 
	/val cf s1 readhexstring pop 0 get def
	pos 1 pos len add 1 sub {im exch val put} for
	pos len 
	} bind def
/hx { 
	3 copy getinterval 
	cf exch readhexstring pop pop 
	} bind def
	/h FMLOCAL
	/w FMLOCAL
	/d FMLOCAL
	/lb FMLOCAL
	/bitmapsave FMLOCAL
	/is FMLOCAL
	/cf FMLOCAL
/wbytes { 
      dup dup
      24 eq { pop pop 3 mul }
      { 8 eq {pop} {1 eq {7 add 8 idiv} {3 add 4 idiv} ifelse} ifelse } ifelse
	} bind def
/BEGINBITMAPBWc { 
	1 {} COMMONBITMAPc
	} bind def
/BEGINBITMAPGRAYc { 
	8 {} COMMONBITMAPc
	} bind def
/BEGINBITMAP2BITc { 
	2 {} COMMONBITMAPc
	} bind def
/COMMONBITMAPc { 
		 
	/r exch def
	/d exch def
	gsave
	
	3 index 2 div add exch	
	4 index 2 div add exch	
	translate		
	rotate			
	1 index 2 div neg	
	1 index 2 div neg	
	translate		
	scale			
	/h exch def /w exch def
	/lb w d wbytes def 
	sl lb lt {lb ms} if 
	/bitmapsave save def 
	r                    
	/is im 0 lb getinterval def 
	ws 0 lb getinterval is copy pop 
	/cf currentfile def 
	w h d [w 0 0 h neg 0 h] 
	{ip} image 
	bitmapsave restore 
	grestore
	} bind def
/BEGINBITMAPBW { 
	1 {} COMMONBITMAP
	} bind def
/BEGINBITMAPGRAY { 
	8 {} COMMONBITMAP
	} bind def
/BEGINBITMAP2BIT { 
	2 {} COMMONBITMAP
	} bind def
/COMMONBITMAP { 
	/r exch def
	/d exch def
	gsave
	
	3 index 2 div add exch	
	4 index 2 div add exch	
	translate		
	rotate			
	1 index 2 div neg	
	1 index 2 div neg	
	translate		
	scale			
	/h exch def /w exch def
	/bitmapsave save def 
	r                    
	/is w d wbytes string def
	/cf currentfile def 
	w h d [w 0 0 h neg 0 h] 
	{cf is readhexstring pop} image
	bitmapsave restore 
	grestore
	} bind def
/ngrayt 256 array def
/nredt 256 array def
/nbluet 256 array def
/ngreent 256 array def
	/gryt FMLOCAL
	/blut FMLOCAL
	/grnt FMLOCAL
	/redt FMLOCAL
	/indx FMLOCAL
	/cynu FMLOCAL
	/magu FMLOCAL
	/yelu FMLOCAL
	/k FMLOCAL
	/u FMLOCAL
FMLevel1 {
/colorsetup {
	currentcolortransfer
	/gryt exch def
	/blut exch def
	/grnt exch def
	/redt exch def
	0 1 255 {
		/indx exch def
		/cynu 1 red indx get 255 div sub def
		/magu 1 green indx get 255 div sub def
		/yelu 1 blue indx get 255 div sub def
		/k cynu magu min yelu min def
		/u k currentundercolorremoval exec def
%		/u 0 def
		nredt indx 1 0 cynu u sub max sub redt exec put
		ngreent indx 1 0 magu u sub max sub grnt exec put
		nbluet indx 1 0 yelu u sub max sub blut exec put
		ngrayt indx 1 k currentblackgeneration exec sub gryt exec put
	} for
	{255 mul cvi nredt exch get}
	{255 mul cvi ngreent exch get}
	{255 mul cvi nbluet exch get}
	{255 mul cvi ngrayt exch get}
	setcolortransfer
	{pop 0} setundercolorremoval
	{} setblackgeneration
	} bind def
}
{
/colorSetup2 {
	[ /Indexed /DeviceRGB 255 
		{dup red exch get 255 div 
		 exch dup green exch get 255 div 
		 exch blue exch get 255 div}
	] setcolorspace
} bind def
} ifelse
	/tran FMLOCAL
/fakecolorsetup {
	/tran 256 string def
	0 1 255 {/indx exch def 
		tran indx
		red indx get 77 mul
		green indx get 151 mul
		blue indx get 28 mul
		add add 256 idiv put} for
	currenttransfer
	{255 mul cvi tran exch get 255.0 div}
	exch concatprocs settransfer
} bind def
/BITMAPCOLOR { 
	/d 8 def
	gsave
	
	3 index 2 div add exch	
	4 index 2 div add exch	
	translate		
	rotate			
	1 index 2 div neg	
	1 index 2 div neg	
	translate		
	scale			
	/h exch def /w exch def
	/bitmapsave save def
	FMLevel1 {	
		colorsetup
		/is w d wbytes string def
		/cf currentfile def 
		w h d [w 0 0 h neg 0 h] 
		{cf is readhexstring pop} {is} {is} true 3 colorimage 
	} {
		colorSetup2
		/is w d wbytes string def
		/cf currentfile def 
		7 dict dup begin
			/ImageType 1 def
			/Width w def
			/Height h def
			/ImageMatrix [w 0 0 h neg 0 h] def
			/DataSource {cf is readhexstring pop} bind def
			/BitsPerComponent d def
			/Decode [0 255] def
		end image	
	} ifelse
	bitmapsave restore 
	grestore
	} bind def
/BITMAPCOLORc { 
	/d 8 def
	gsave
	
	3 index 2 div add exch	
	4 index 2 div add exch	
	translate		
	rotate			
	1 index 2 div neg	
	1 index 2 div neg	
	translate		
	scale			
	/h exch def /w exch def
	/lb w d wbytes def 
	sl lb lt {lb ms} if 
	/bitmapsave save def 
	FMLevel1 {	
		colorsetup
		/is im 0 lb getinterval def 
		ws 0 lb getinterval is copy pop 
		/cf currentfile def 
		w h d [w 0 0 h neg 0 h] 
		{ip} {is} {is} true 3 colorimage
	} {
		colorSetup2
		/is im 0 lb getinterval def 
		ws 0 lb getinterval is copy pop 
		/cf currentfile def 
		7 dict dup begin
			/ImageType 1 def
			/Width w def
			/Height h def
			/ImageMatrix [w 0 0 h neg 0 h] def
			/DataSource {ip} bind def
			/BitsPerComponent d def
			/Decode [0 255] def
		end image	
	} ifelse
	bitmapsave restore 
	grestore
	} bind def
/BITMAPTRUECOLORc { 
	/d 24 def
        gsave
 	
	3 index 2 div add exch	
	4 index 2 div add exch	
	translate		
	rotate			
	1 index 2 div neg	
	1 index 2 div neg	
	translate		
	scale			
	/h exch def /w exch def
	/lb w d wbytes def 
	sl lb lt {lb ms} if 
        /bitmapsave save def 
        
	/is im 0 lb getinterval def	
	/ris im 0 w getinterval def	
	/gis im w w getinterval def	
	/bis im w 2 mul w getinterval def 
        
        ws 0 lb getinterval is copy pop 
        /cf currentfile def 
        w h 8 [w 0 0 h neg 0 h] 
        {w rip pop ris} {gis} {bis} true 3 colorimage
        bitmapsave restore 
        grestore
        } bind def
/BITMAPTRUECOLOR { 
        gsave
		
		3 index 2 div add exch	
		4 index 2 div add exch	
		translate		
		rotate			
		1 index 2 div neg	
		1 index 2 div neg	
		translate		
		scale			
		/h exch def /w exch def
        /bitmapsave save def 
        /is w string def
        /gis w string def
        /bis w string def
        /cf currentfile def 
        w h 8 [w 0 0 h neg 0 h] 
        { cf is readhexstring pop } 
        { cf gis readhexstring pop } 
        { cf bis readhexstring pop } 
        true 3 colorimage 
        bitmapsave restore 
        grestore
        } bind def
/BITMAPTRUEGRAYc { 
	/d 24 def
        gsave
	
	3 index 2 div add exch	
	4 index 2 div add exch	
	translate		
	rotate			
	1 index 2 div neg	
	1 index 2 div neg	
	translate		
	scale			
	/h exch def /w exch def
	/lb w d wbytes def 
	sl lb lt {lb ms} if 
        /bitmapsave save def 
        
	/is im 0 lb getinterval def	
	/ris im 0 w getinterval def	
	/gis im w w getinterval def	
	/bis im w 2 mul w getinterval def 
        ws 0 lb getinterval is copy pop 
        /cf currentfile def 
        w h 8 [w 0 0 h neg 0 h] 
        {w rip pop ris gis bis w gray} image
        bitmapsave restore 
        grestore
        } bind def
/ww FMLOCAL
/r FMLOCAL
/g FMLOCAL
/b FMLOCAL
/i FMLOCAL
/gray { 
        /ww exch def
        /b exch def
        /g exch def
        /r exch def
        0 1 ww 1 sub { /i exch def r i get .299 mul g i get .587 mul
			b i get .114 mul add add r i 3 -1 roll floor cvi put } for
        r
        } bind def
/BITMAPTRUEGRAY { 
        gsave
		
		3 index 2 div add exch	
		4 index 2 div add exch	
		translate		
		rotate			
		1 index 2 div neg	
		1 index 2 div neg	
		translate		
		scale			
		/h exch def /w exch def
        /bitmapsave save def 
        /is w string def
        /gis w string def
        /bis w string def
        /cf currentfile def 
        w h 8 [w 0 0 h neg 0 h] 
        { cf is readhexstring pop 
          cf gis readhexstring pop 
          cf bis readhexstring pop w gray}  image
        bitmapsave restore 
        grestore
        } bind def
/BITMAPGRAY { 
	8 {fakecolorsetup} COMMONBITMAP
	} bind def
/BITMAPGRAYc { 
	8 {fakecolorsetup} COMMONBITMAPc
	} bind def
/ENDBITMAP {
	} bind def
end 
	/ALDsave FMLOCAL
	/ALDmatrix matrix def ALDmatrix currentmatrix pop
/StartALD {
	/ALDsave save def
	 savematrix
	 ALDmatrix setmatrix
	} bind def
/InALD {
	 restorematrix
	} bind def
/DoneALD {
	 ALDsave restore
	} bind def
/I { setdash } bind def
/J { [] 0 setdash } bind def
%%EndProlog
%%BeginSetup
(4.0) FMVERSION
1 1 0 0 612 792 0 1 6 FMDOCUMENT
0 0 /Times-Roman FMFONTDEFINE
1 0 /Times-Bold FMFONTDEFINE
2 0 /Times-Italic FMFONTDEFINE
32 FMFILLS
0 0 FMFILL
1 0.1 FMFILL
2 0.3 FMFILL
3 0.5 FMFILL
4 0.7 FMFILL
5 0.9 FMFILL
6 0.97 FMFILL
7 1 FMFILL
8 <0f1e3c78f0e1c387> FMFILL
9 <0f87c3e1f0783c1e> FMFILL
10 <cccccccccccccccc> FMFILL
11 <ffff0000ffff0000> FMFILL
12 <8142241818244281> FMFILL
13 <03060c183060c081> FMFILL
14 <8040201008040201> FMFILL
16 1 FMFILL
17 0.9 FMFILL
18 0.7 FMFILL
19 0.5 FMFILL
20 0.3 FMFILL
21 0.1 FMFILL
22 0.03 FMFILL
23 0 FMFILL
24 <f0e1c3870f1e3c78> FMFILL
25 <f0783c1e0f87c3e1> FMFILL
26 <3333333333333333> FMFILL
27 <0000ffff0000ffff> FMFILL
28 <7ebddbe7e7dbbd7e> FMFILL
29 <fcf9f3e7cf9f3f7e> FMFILL
30 <7fbfdfeff7fbfdfe> FMFILL
%%EndSetup
%%Page: "1" 1
%%BeginPaperSize: Letter
%%EndPaperSize
612 792 0 FMBEGINPAGE
[0 0 0 1 0 0 0]
[ 0 1 1 0 1 0 0]
[ 1 0 1 0 0 1 0]
[ 1 1 0 0 0 0 1]
[ 1 0 0 0 0 1 1]
[ 0 1 0 0 1 0 1]
[ 0 0 1 0 1 1 0]
 7 FrameSetSepColors
FrameNoSep
0 0 0 1 0 0 0 K
J
0 0 0 1 0 0 0 K
72 746 540 756 R
7 X
0 0 0 1 0 0 0 K
V
75 36 543 46 R
V
0 10 Q
0 X
(Page 1) 516.06 39.18 T
0 0 0 1 0 0 0 K
0 0 0 1 0 0 0 K
72 72 540 720 R
7 X
V
0 12 Q
0 X
(PROVISIONAL APPLICATION) 225.17 576 T
1 14 Q
(A Process for Automatically Positioning Cache Lookups) 138.39 550.67 T
(for Dynamically Compiled Code) 209.37 533.67 T
0 12 Q
(Inventors:) 281.67 497 T
(Craig Chambers) 266.84 469 T
(Citizen of U.S.) 270 455 T
(residing in Seattle, Washington) 230.67 441 T
(and) 297.34 413 T
(Susan J. Eggers) 268.17 385 T
(Citizen of U.S.) 270 371 T
(residing in Seattle, Washington) 230.67 357 T
(and) 297.34 329 T
(Brian K. Grant) 270.17 301 T
(Citizen of U.S.) 270 287 T
(residing in Seattle, Washington) 230.67 273 T
(and) 297.34 245 T
(Markus Mock) 272.17 217 T
(Citizen of Germany.) 256.84 203 T
(residing in Seattle, Washington) 230.67 189 T
(and) 297.34 161 T
(Matthai Philipose) 263.5 133 T
(Citizen of India) 268.34 119 T
(residing in Seattle, Washington) 230.67 105 T
0 1 1 0 1 0 0 K
0 0 0 1 0 0 0 K
0 0 0 1 0 0 0 K
FMENDPAGE
%%EndPage: "1" 1
%%Page: "2" 2
612 792 0 FMBEGINPAGE
[0 0 0 1 0 0 0]
[ 0 1 1 0 1 0 0]
[ 1 0 1 0 0 1 0]
[ 1 1 0 0 0 0 1]
[ 1 0 0 0 0 1 1]
[ 0 1 0 0 1 0 1]
[ 0 0 1 0 1 1 0]
 7 FrameSetSepColors
FrameNoSep
0 0 0 1 0 0 0 K
72 746 540 756 R
7 X
0 0 0 1 0 0 0 K
V
75 36 543 46 R
V
0 10 Q
0 X
(Page 2) 516.06 39.18 T
0 0 0 1 0 0 0 K
0 0 0 1 0 0 0 K
72 72 540 720 R
7 X
V
1 14 Q
0 X
(Provisional Patent Application for) 203.53 654.67 T
(A Process for Automatically Positioning Cache Lookups) 138.39 637.67 T
(for Dynamically Compiled Code) 209.37 620.67 T
(Craig Chambers, Susan J. Eggers, Brian K. Grant, Markus Mock, and) 94.82 586.67 T
(Matthai Philipose) 252.91 569.67 T
(Field of Invention) 72 524.67 T
0 12 Q
1.18 (This invention relates to the field of dynamic compilation, specifically to the management and) 72 500.5 P
(performance of cached versions of specialized code.) 72 479.5 T
1 14 Q
(Summary) 72 431.67 T
0 12 Q
1.25 (This invention is a process for deciding where to cache dynamically generated code, so that it) 72 407.5 P
1.74 (can be reused without again incurring the costs of dynamic compilation, both at the program) 72 386.5 P
0.36 (point at which it is generated and by other program points that need identical code \050for example,) 72 365.5 P
0.54 (multiple call sites for the same function\051. In determining caching points, the invention considers) 72 344.5 P
2.98 (both the savings due to code reuse and the cost of using and maintaining the cache. The) 72 323.5 P
(invention can be used by any compiler that implements dynamic compilation.) 72 302.5 T
1 14 Q
(Background) 72 259.17 T
2 12 Q
1.23 (Dynamic compilation) 72 235 P
0 F
1.23 ( offers the potential for increased performance by delaying some parts of) 176.89 235 P
3.25 (program compilation until run time, when values of key variables, called) 72 214 P
2 F
3.25 (static variables) 460.08 214 P
0 F
3.25 (,) 537 214 P
0.53 (become known. Compilation then completes, generating code that is) 72 193 P
2 F
0.53 (specialized) 408.42 193 P
0 F
0.53 ( to these values.) 461.75 193 P
1.18 (Before benefits from the more efficient, specialized code can be realized, however, the cost of) 72 172 P
2.94 (dynamic code generation must be recovered. One way to recover this cost is to reuse the) 72 151 P
0.85 (specialized code when the executing program reaches the same point again. Unfortunately, it is) 72 130 P
0.67 (not always possible to do this, because the values of the static variables for which the code was) 72 109 P
(specialized may have changed, rendering the specialized code unreusable.) 72 88 T
0 1 1 0 1 0 0 K
0 0 0 1 0 0 0 K
0 0 0 1 0 0 0 K
FMENDPAGE
%%EndPage: "2" 2
%%Page: "3" 3
612 792 0 FMBEGINPAGE
[0 0 0 1 0 0 0]
[ 0 1 1 0 1 0 0]
[ 1 0 1 0 0 1 0]
[ 1 1 0 0 0 0 1]
[ 1 0 0 0 0 1 1]
[ 0 1 0 0 1 0 1]
[ 0 0 1 0 1 1 0]
 7 FrameSetSepColors
FrameNoSep
0 0 0 1 0 0 0 K
72 746 540 756 R
7 X
0 0 0 1 0 0 0 K
V
75 36 543 46 R
V
0 10 Q
0 X
(Page 3) 516.06 39.18 T
0 0 0 1 0 0 0 K
0 0 0 1 0 0 0 K
72 72 540 720 R
7 X
V
0 12 Q
0 X
1.19 (Reuse is achieved by caching the specialized code when it is dynamically generated) 72 708.8 P
0 9.6 Q
0.95 (1) 488.83 713.6 P
0 12 Q
1.19 ( and then) 493.63 708.8 P
0.71 (doing a cache lookup, based on the values of the static variables, to retrieve it when the code is) 72 687.8 P
3.62 (executed again. Some systems cache specialized code only at function entry points. This) 72 666.8 P
3.31 (restricts the granularity of code specialization and reuse to an entire function, eliminating) 72 645.8 P
0.48 (opportunities for reusing portions of a function. Our invention allows specialization and caching) 72 624.8 P
(on a sub-function granularity.) 72 603.8 T
3.4 (Other systems that produce specialized code at compile time \050rather than execution time\051) 72 582.8 P
0.96 (aggressively reuse code by caching it at every specialized jump target. However, such frequent) 72 561.8 P
1.78 (cache lookups cause unacceptable overhead in run-time specialization systems. Our invention) 72 540.8 P
2.04 (reduces the cache-lookup overhead by reducing the number of cache lookups. The invention) 72 519.8 P
1.42 (strives for a good compromise between reducing the number of cache lookups and preserving) 72 498.8 P
(opportunities for code reuse.) 72 477.8 T
1 14 Q
(Invention) 72 434.47 T
0 12 Q
0.2 (First, we identify points in the region of the program to be dynamically compiled, called) 72 410.3 P
2 F
0.2 (caching) 502.01 410.3 P
0.36 (points) 72 389.3 P
0 F
0.36 (, where the potential for reuse may arise. Then, we coalesce the caching points as much as) 101.34 389.3 P
0.9 (is reasonable, potentially sacrificing some reuse in order to reduce cache-lookup overhead. The) 72 368.3 P
(procedure is as follows:) 72 347.3 T
(1.) 72 326.3 T
(Identify code-generation and other potential reuse points \050the caching points\051.) 90 326.3 T
(The caching points are placed at the following types of program points:) 90 305.3 T
(\245) 93.6 284.3 T
(A transition, called a) 107 284.3 T
2 F
(lazy point) 209.98 284.3 T
0 F
(, from executing \050statically or dynamically generated\051) 256.99 284.3 T
(code to generating code. Before dynamically generating the code, we check in the) 108 266.3 T
(reusable code cache to see if the code has been previously specialized to identical static-) 108 248.3 T
(variable values. If they have changed, then new static values, called) 108 230.3 T
2 F
(promoted values) 435.91 230.3 T
0 F
(,) 515.57 230.3 T
(must be passed to the dynamic compiler, so that code that is specialized to the new) 108 212.3 T
(values can be dynamically compiled. Lazy points where values are promoted are called) 108 194.3 T
2 F
(promotion) 108 176.3 T
(points) 161 176.3 T
0 F
(.) 190.34 176.3 T
(\245) 93.6 158.3 T
(A procedure entry. The procedure could be invoked again with the same parameter) 107 158.3 T
(values and other \050global\051 values for which it has been specialized.) 108 140.3 T
(\245) 93.6 122.3 T
(A merge of control paths on which static variables could be assigned the same values. If) 107 122.3 T
0 0 0 1 0 0 0 K
72 87.33 540 102.33 C
0 0 0 1 0 0 0 K
81 100.33 225 100.33 2 L
0.5 H
2 Z
0 X
0 0 0 1 0 0 0 K
N
0 0 0 1 0 0 0 K
0 0 612 792 C
0 0 0 1 0 0 0 K
0 8 Q
0 X
0 0 0 1 0 0 0 K
(1.) 90 82 T
0 0 0 1 0 0 0 K
0 0 0 1 0 0 0 K
0 12 Q
(Code execution and code generation can be interleaved throughout a program.) 102 78 T
0 0 0 1 0 0 0 K
0 0 0 1 0 0 0 K
0 1 1 0 1 0 0 K
0 0 0 1 0 0 0 K
0 0 0 1 0 0 0 K
FMENDPAGE
%%EndPage: "3" 3
%%Page: "4" 4
612 792 0 FMBEGINPAGE
[0 0 0 1 0 0 0]
[ 0 1 1 0 1 0 0]
[ 1 0 1 0 0 1 0]
[ 1 1 0 0 0 0 1]
[ 1 0 0 0 0 1 1]
[ 0 1 0 0 1 0 1]
[ 0 0 1 0 1 1 0]
 7 FrameSetSepColors
FrameNoSep
0 0 0 1 0 0 0 K
72 746 540 756 R
7 X
0 0 0 1 0 0 0 K
V
75 36 543 46 R
V
0 10 Q
0 X
(Page 4) 516.06 39.18 T
0 0 0 1 0 0 0 K
0 0 0 1 0 0 0 K
72 72 540 720 R
7 X
V
0 12 Q
0 X
(this were the case, the code that follows would be the same for both paths.) 108 712 T
(\245) 93.6 694 T
(A program point that occurs after a static variable has become either) 107 694 T
2 F
(dynamic) 438.25 694 T
0 F
( \050i.e., it is) 478.9 694 T
(no longer used for specialization\051 or) 108 676 T
2 F
(dead) 284.63 676 T
0 F
( \050i.e., it is no longer used at all\051. \050We call static) 307.96 676 T
(variables that meet these criteria) 108 658 T
2 F
(evicted variables) 266.29 658 T
0 F
(.\051 If an evicted variable was not a pure) 347.94 658 T
(function of other static variables, then eliminating it from the set of specialized values) 108 640 T
(could eliminate differences between specialized versions of the code that follows.) 108 622 T
(2.) 72 604 T
(Determine ranges of caching-point placement.) 90 604 T
(For each caching point, we construct the range over the procedure where that caching point) 90 583 T
-0.08 (can be legally moved. Procedure entries, control-\337ow mer) 90 562 P
-0.08 (ges, and lazy points that follow par-) 368.17 562 P
(ticular branches cannot be moved, so each of their ranges is a single program point. Eviction) 90 541 T
-0.31 (and promotion points can move to any control-equivalent program point \050i.e., a program point) 90 520 P
(with the same control dependences\051 that is bounded by earlier and later uses of the evicted or) 90 499 T
(promoted variables, respectively) 90 478 T
(. In addition, promotion points cannot move above earlier) 245.52 478 T
(de\336nitions.) 90 457 T
(3.) 72 436 T
(Sort the ranges by end point.) 90 436 T
(W) 90 415 T
(e sort the caching-point ranges in increasing order of their ends.) 100.37 415 T
(4.) 72 394 T
(Intersect adjacent overlapping ranges.) 90 394 T
(W) 90 373 T
(e make a linear scan through this sorted list of caching-point ranges. W) 100.37 373 T
(e remove the range) 441.01 373 T
-0.01 (that ends \336rst in the list, remove all other ranges that overlap with the \336rst range, and \336nd the) 90 352 P
(intersection of these ranges. Then we continue processing the sorted list of caching-point) 90 331 T
(ranges, until all entries in the list are removed.) 90 310 T
(5.) 72 289 T
(Place \336nal caching points within the intersections.) 90 289 T
-0.33 (The intersections are the program regions where the \336nal caching points should be placed. W) 90 268 P
-0.33 (e) 532 268 P
(prefer earliest possible points for evictions and later points for promotions, as these will) 90 247 T
-0.3 (reduce the amount of specialized code, and thus reduce overhead. For each intersection range,) 90 226 P
(we choose either the start or end of the range, based on the relative mix of promotions and) 90 205 T
(evictions, and insert a single caching point for all the mer) 90 184 T
(ged ranges.) 365.41 184 T
1 14 Q
(Broadening) 72 140.67 T
0 12 Q
(The invention can be modified or extended in the following ways:) 72 116.5 T
(\245) 75.6 95.5 T
(One may wish to take into account the fact that dif) 90 95.5 T
(ferent kinds of caching points, or points to) 332.41 95.5 T
-0.26 (which we want to apply dif) 90 77.5 P
-0.26 (ferent caching policies, incur dif) 219.47 77.5 P
-0.26 (ferent kinds of costs. One may not) 373.84 77.5 P
0 1 1 0 1 0 0 K
0 0 0 1 0 0 0 K
0 0 0 1 0 0 0 K
FMENDPAGE
%%EndPage: "4" 4
%%Page: "5" 5
612 792 0 FMBEGINPAGE
[0 0 0 1 0 0 0]
[ 0 1 1 0 1 0 0]
[ 1 0 1 0 0 1 0]
[ 1 1 0 0 0 0 1]
[ 1 0 0 0 0 1 1]
[ 0 1 0 0 1 0 1]
[ 0 0 1 0 1 1 0]
 7 FrameSetSepColors
FrameNoSep
0 0 0 1 0 0 0 K
72 746 540 756 R
7 X
0 0 0 1 0 0 0 K
V
75 36 543 46 R
V
0 10 Q
0 X
(Page 5) 516.06 39.18 T
0 0 0 1 0 0 0 K
0 0 0 1 0 0 0 K
72 72 540 720 R
7 X
V
0 12 Q
0 X
(wish to coalesce caching points with dif) 90 712 T
(ferent kinds of costs together) 281.76 712 T
(, if that would increase) 420.59 712 T
(overall expense.) 90 694 T
(\245) 75.6 676 T
(One could permit coalescing of caching points beyond control-equivalent regions. Moving) 90 676 T
-0.1 (caching points below branches or above control-\337ow mer) 90 658 P
-0.1 (ges would create identical points on) 365.32 658 P
(all paths from the branches or to the mer) 90 640 T
(ges. Moving caching points in the opposite direction) 284.41 640 T
(could only be permitted if such identical caching points existed on all the paths.) 90 622 T
(\245) 75.6 604 T
(Except at loop heads, cache lookups at mer) 90 604 T
(ge points could be moved down by the coalescing) 297.07 604 T
(procedure. This could decrease the number of caching points, but would also decrease the) 90 586 T
(amount of reuse.) 90 568 T
(\245) 75.6 550 T
(One may wish to further restrict the ranges of some types of caching points.) 90 550 T
(\245) 75.6 532 T
-0.17 (One need not place the caching points only at the end of the intersection ranges. For example,) 90 532 P
(one could choose the \336nal position for a caching point by selecting an of) 90 514 T
(fset within its inter-) 438.07 514 T
(section range that is scaled by the ratio of the numbers of evictions and promotions.) 90 496 T
(\245) 75.6 478 T
(One may wish to limit the lengths of the ranges, so that caching points suf) 90 478 T
(\336ciently far away) 445.43 478 T
(from each other are not coalesced, or one may want to avoid coalescing dif) 90 460 T
(ferent types of) 449.69 460 T
(caching points that are relatively distant from each other) 90 442 T
(. For example, one may not wish to) 359.95 442 T
-0.16 (combine distant caching points due to evictions and promotions, since it is preferred that evic-) 90 424 P
(tion caching points occur earlier and promotion caching points occur later) 90 406 T
(.) 443.94 406 T
0 1 1 0 1 0 0 K
0 0 0 1 0 0 0 K
0 0 0 1 0 0 0 K
FMENDPAGE
%%EndPage: "5" 5
%%Trailer
%%BoundingBox: 0 0 612 792
%%PageOrder: Ascend
%%Pages: 5
%%DocumentFonts: Times-Roman
%%+ Times-Bold
%%+ Times-Italic
%%EOF

Date: Fri, 5 Jun 1998 21:15:16 -0700
From: eggers@yakima (Susan Eggers)
To: pljones@u.washington.edu, spin-comp@cs
Subject: lazy spec

%!PS-Adobe-3.0
%%BoundingBox: (atend)
%%Pages: (atend)
%%PageOrder: (atend)
%%DocumentFonts: (atend)
%%Creator: Frame 4.0
%%DocumentData: Clean7Bit
%%EndComments
%%BeginProlog
%
% Frame ps_prolog 4.0, for use with Frame 4.0 products
% This ps_prolog file is Copyright (c) 1986-1993 Frame Technology
% Corporation.  All rights reserved.  This ps_prolog file may be
% freely copied and distributed in conjunction with documents created
% using FrameMaker, FrameBuilder and FrameViewer as long as this 
% copyright notice is preserved.
%
% Frame products normally print colors as their true color on a color printer
% or as shades of gray, based on luminance, on a black-and white printer. The
% following flag, if set to True, forces all non-white colors to print as pure
% black. This has no effect on bitmap images.
/FMPrintAllColorsAsBlack             false def
%
% Frame products can either set their own line screens or use a printer's 
% default settings. Three flags below control this separately for no 
% separations, spot separations and process separations. If a flag
% is true, then the default printer settings will not be changed. If it is
% false, Frame products will use their own settings from a table based on
% the printer's resolution.
/FMUseDefaultNoSeparationScreen      true  def
/FMUseDefaultSpotSeparationScreen    true  def
/FMUseDefaultProcessSeparationScreen false def
%
% For any given PostScript printer resolution, Frame products have two sets of 
% screen angles and frequencies for printing process separations, which are 
% recomended by Adobe. The following variable chooses the higher frequencies
% when set to true or the lower frequencies when set to false. This is only
% effective if the appropriate FMUseDefault...SeparationScreen flag is false.
/FMUseHighFrequencyScreens true def
%
% PostScript Level 2 printers contain an "Accurate Screens" feature which can
% improve process separation rendering at the expense of compute time. This 
% flag is ignored by PostScript Level 1 printers.
/FMUseAcccurateScreens true def
%
% The following PostScript procedure defines the spot function that Frame
% products will use for process separations. You may un-comment-out one of
% the alternative functions below, or use your own.
%
% Dot function
/FMSpotFunction {abs exch abs 2 copy add 1 gt 
		{1 sub dup mul exch 1 sub dup mul add 1 sub }
		{dup mul exch dup mul add 1 exch sub }ifelse } def
%
% Line function
% /FMSpotFunction { pop } def
%
% Elipse function
% /FMSpotFunction { dup 5 mul 8 div mul exch dup mul exch add 
%		sqrt 1 exch sub } def
%
%
/FMversion (4.0) def 
/FMLevel1 /languagelevel where {pop languagelevel} {1} ifelse 2 lt def
/FMPColor
	FMLevel1 {
		false
		/colorimage where {pop pop true} if
	} {
		true
	} ifelse
def
/FrameDict 400 dict def 
systemdict /errordict known not {/errordict 10 dict def
		errordict /rangecheck {stop} put} if
% The readline in PS 23.0 doesn't recognize cr's as nl's on AppleTalk
FrameDict /tmprangecheck errordict /rangecheck get put 
errordict /rangecheck {FrameDict /bug true put} put 
FrameDict /bug false put 
mark 
% Some PS machines read past the CR, so keep the following 3 lines together!
currentfile 5 string readline
00
0000000000
cleartomark 
errordict /rangecheck FrameDict /tmprangecheck get put 
FrameDict /bug get { 
	/readline {
		/gstring exch def
		/gfile exch def
		/gindex 0 def
		{
			gfile read pop 
			dup 10 eq {exit} if 
			dup 13 eq {exit} if 
			gstring exch gindex exch put 
			/gindex gindex 1 add def 
		} loop
		pop 
		gstring 0 gindex getinterval true 
		} bind def
	} if
/FMshowpage /showpage load def
/FMquit /quit load def
/FMFAILURE { 
	dup = flush 
	FMshowpage 
	/Helvetica findfont 12 scalefont setfont
	72 200 moveto
	show FMshowpage 
	FMquit 
	} def 
/FMVERSION {
	FMversion ne {
		(Frame product version does not match ps_prolog!) FMFAILURE
		} if
	} def 
/FMBADEPSF { 
	(PostScript Lang. Ref. Man., 2nd Ed., H.2.4 says EPS must not call X              )
	dup dup (X) search pop exch pop exch pop length 
	4 -1 roll 
	putinterval 
	FMFAILURE
	} def
/FMLOCAL {
	FrameDict begin
	0 def 
	end 
	} def 
/concatprocs
	{
	/proc2 exch cvlit def/proc1 exch cvlit def/newproc proc1 length proc2 length add array def
	newproc 0 proc1 putinterval newproc proc1 length proc2 putinterval newproc cvx
}def
FrameDict begin 
/FMnone 0 def
/FMcyan 1 def
/FMmagenta 2 def
/FMyellow 3 def
/FMblack 4 def
/FMcustom 5 def
/FrameNegative false def 
/FrameSepIs FMnone def 
/FrameSepBlack 0 def
/FrameSepYellow 0 def
/FrameSepMagenta 0 def
/FrameSepCyan 0 def
/FrameSepRed 1 def
/FrameSepGreen 1 def
/FrameSepBlue 1 def
/FrameCurGray 1 def
/FrameCurPat null def
/FrameCurColors [ 0 0 0 1 0 0 0 ] def 
/FrameColorEpsilon .001 def	
/eqepsilon {		
	sub dup 0 lt {neg} if
	FrameColorEpsilon le
} bind def
/FrameCmpColorsCMYK { 
	2 copy 0 get exch 0 get eqepsilon {
		2 copy 1 get exch 1 get eqepsilon {
			2 copy 2 get exch 2 get eqepsilon {
				3 get exch 3 get eqepsilon
			} {pop pop false} ifelse
		}{pop pop false} ifelse
	} {pop pop false} ifelse
} bind def
/FrameCmpColorsRGB { 
	2 copy 4 get exch 0 get eqepsilon {
		2 copy 5 get exch 1 get eqepsilon {
			6 get exch 2 get eqepsilon
		}{pop pop false} ifelse
	} {pop pop false} ifelse
} bind def
/RGBtoCMYK { 
	1 exch sub 
	3 1 roll 
	1 exch sub 
	3 1 roll 
	1 exch sub 
	3 1 roll 
	3 copy 
	2 copy 
	le { pop } { exch pop } ifelse 
	2 copy 
	le { pop } { exch pop } ifelse 
	dup dup dup 
	6 1 roll 
	4 1 roll 
	7 1 roll 
	sub 
	6 1 roll 
	sub 
	5 1 roll 
	sub 
	4 1 roll 
} bind def
/CMYKtoRGB { 
	dup dup 4 -1 roll add 						  
	5 1 roll 3 -1 roll add 						  
	4 1 roll add 								  
	1 exch sub dup 0 lt {pop 0} if 3 1 roll 	  
	1 exch sub dup 0 lt {pop 0} if exch 	      
	1 exch sub dup 0 lt {pop 0} if exch	  		  
} bind def
/FrameSepInit {
	1.0 RealSetgray
} bind def
/FrameSetSepColor { 
	/FrameSepBlue exch def
	/FrameSepGreen exch def
	/FrameSepRed exch def
	/FrameSepBlack exch def
	/FrameSepYellow exch def
	/FrameSepMagenta exch def
	/FrameSepCyan exch def
	/FrameSepIs FMcustom def
	setCurrentScreen	
} bind def
/FrameSetCyan {
	/FrameSepBlue 1.0 def
	/FrameSepGreen 1.0 def
	/FrameSepRed 0.0 def
	/FrameSepBlack 0.0 def
	/FrameSepYellow 0.0 def
	/FrameSepMagenta 0.0 def
	/FrameSepCyan 1.0 def
	/FrameSepIs FMcyan def
	setCurrentScreen	
} bind def
 
/FrameSetMagenta {
	/FrameSepBlue 1.0 def
	/FrameSepGreen 0.0 def
	/FrameSepRed 1.0 def
	/FrameSepBlack 0.0 def
	/FrameSepYellow 0.0 def
	/FrameSepMagenta 1.0 def
	/FrameSepCyan 0.0 def
	/FrameSepIs FMmagenta def
	setCurrentScreen
} bind def
 
/FrameSetYellow {
	/FrameSepBlue 0.0 def
	/FrameSepGreen 1.0 def
	/FrameSepRed 1.0 def
	/FrameSepBlack 0.0 def
	/FrameSepYellow 1.0 def
	/FrameSepMagenta 0.0 def
	/FrameSepCyan 0.0 def
	/FrameSepIs FMyellow def
	setCurrentScreen
} bind def
 
/FrameSetBlack {
	/FrameSepBlue 0.0 def
	/FrameSepGreen 0.0 def
	/FrameSepRed 0.0 def
	/FrameSepBlack 1.0 def
	/FrameSepYellow 0.0 def
	/FrameSepMagenta 0.0 def
	/FrameSepCyan 0.0 def
	/FrameSepIs FMblack def
	setCurrentScreen
} bind def
 
/FrameNoSep { 
	/FrameSepIs FMnone def
	setCurrentScreen
} bind def
/FrameSetSepColors { 
	FrameDict begin
	[ exch 1 add 1 roll ]
	/FrameSepColors  
	exch def end
	} bind def
/FrameColorInSepListCMYK { 
	FrameSepColors {  
       		exch dup 3 -1 roll 
       		FrameCmpColorsCMYK 
       		{ pop true exit } if
    	} forall 
	dup true ne {pop false} if
	} bind def
/FrameColorInSepListRGB { 
	FrameSepColors {  
       		exch dup 3 -1 roll 
       		FrameCmpColorsRGB 
       		{ pop true exit } if
    	} forall 
	dup true ne {pop false} if
	} bind def
/RealSetgray /setgray load def
/RealSetrgbcolor /setrgbcolor load def
/RealSethsbcolor /sethsbcolor load def
end 
/setgray { 
	FrameDict begin
	FrameSepIs FMnone eq
		{ RealSetgray } 
		{ 
		FrameSepIs FMblack eq 
			{ RealSetgray } 
			{ FrameSepIs FMcustom eq 
			  FrameSepRed 0 eq and
			  FrameSepGreen 0 eq and
			  FrameSepBlue 0 eq and {
			  	RealSetgray
			  } {
				1 RealSetgray pop 
			  } ifelse
			} ifelse
		} ifelse
	end
} bind def
/setrgbcolor { 
	FrameDict begin
	FrameSepIs FMnone eq
	{  RealSetrgbcolor }
	{
		3 copy [ 4 1 roll ] 
		FrameColorInSepListRGB
		{
				FrameSepBlue eq exch 
			 	FrameSepGreen eq and exch 
			 	FrameSepRed eq and
			 	{ 0 } { 1 } ifelse
		}
		{
			FMPColor {
				RealSetrgbcolor
				currentcmykcolor
			} {
				RGBtoCMYK
			} ifelse
			FrameSepIs FMblack eq
			{1.0 exch sub 4 1 roll pop pop pop} {
			FrameSepIs FMyellow eq
			{pop 1.0 exch sub 3 1 roll pop pop} {
			FrameSepIs FMmagenta eq
			{pop pop 1.0 exch sub exch pop } {
			FrameSepIs FMcyan eq
			{pop pop pop 1.0 exch sub } 
			{pop pop pop pop 1} ifelse } ifelse } ifelse } ifelse 
		} ifelse
		RealSetgray
	} 
	ifelse
	end
} bind def
/sethsbcolor {
	FrameDict begin
	FrameSepIs FMnone eq 
	{ RealSethsbcolor } 
	{
		RealSethsbcolor 
		currentrgbcolor  
		setrgbcolor 
	} 
	ifelse
	end
} bind def
FrameDict begin
/setcmykcolor where {
	pop /RealSetcmykcolor /setcmykcolor load def
} {
	/RealSetcmykcolor {
		4 1 roll
		3 { 3 index add 0 max 1 min 1 exch sub 3 1 roll} repeat 
		setrgbcolor pop
	} bind def
} ifelse
userdict /setcmykcolor { 
		FrameDict begin
		FrameSepIs FMnone eq
		{ RealSetcmykcolor } 
		{
			4 copy [ 5 1 roll ]
			FrameColorInSepListCMYK
			{
				FrameSepBlack eq exch 
				FrameSepYellow eq and exch 
				FrameSepMagenta eq and exch 
				FrameSepCyan eq and 
				{ 0 } { 1 } ifelse
			}
			{
				FrameSepIs FMblack eq
				{1.0 exch sub 4 1 roll pop pop pop} {
				FrameSepIs FMyellow eq
				{pop 1.0 exch sub 3 1 roll pop pop} {
				FrameSepIs FMmagenta eq
				{pop pop 1.0 exch sub exch pop } {
				FrameSepIs FMcyan eq
				{pop pop pop 1.0 exch sub } 
				{pop pop pop pop 1} ifelse } ifelse } ifelse } ifelse 
			} ifelse
			RealSetgray
		}
		ifelse
		end
	} bind put
FMLevel1 not { 
	
	/patProcDict 5 dict dup begin
		<0f1e3c78f0e1c387> { 3 setlinewidth -1 -1 moveto 9 9 lineto stroke 
											4 -4 moveto 12 4 lineto stroke
											-4 4 moveto 4 12 lineto stroke} bind def
		<0f87c3e1f0783c1e> { 3 setlinewidth -1 9 moveto 9 -1 lineto stroke 
											-4 4 moveto 4 -4 lineto stroke
											4 12 moveto 12 4 lineto stroke} bind def
		<8142241818244281> { 1 setlinewidth -1 9 moveto 9 -1 lineto stroke
											-1 -1 moveto 9 9 lineto stroke } bind def
		<03060c183060c081> { 1 setlinewidth -1 -1 moveto 9 9 lineto stroke 
											4 -4 moveto 12 4 lineto stroke
											-4 4 moveto 4 12 lineto stroke} bind def
		<8040201008040201> { 1 setlinewidth -1 9 moveto 9 -1 lineto stroke 
											-4 4 moveto 4 -4 lineto stroke
											4 12 moveto 12 4 lineto stroke} bind def
	end def
	/patDict 15 dict dup begin
		/PatternType 1 def		
		/PaintType 2 def		
		/TilingType 3 def		
		/BBox [ 0 0 8 8 ] def 	
		/XStep 8 def			
		/YStep 8 def			
		/PaintProc {
			begin
			patProcDict bstring known {
				patProcDict bstring get exec
			} {
				8 8 true [1 0 0 -1 0 8] bstring imagemask
			} ifelse
			end
		} bind def
	end def
} if
/combineColor {
    FrameSepIs FMnone eq
	{
		graymode FMLevel1 or not {
			
			[/Pattern [/DeviceCMYK]] setcolorspace
			FrameCurColors 0 4 getinterval aload pop FrameCurPat setcolor
		} {
			FrameCurColors 3 get 1.0 ge {
				FrameCurGray RealSetgray
			} {
				FMPColor graymode and {
					0 1 3 { 
						FrameCurColors exch get
						1 FrameCurGray sub mul
					} for
					RealSetcmykcolor
				} {
					4 1 6 {
						FrameCurColors exch get
						graymode {
							1 exch sub 1 FrameCurGray sub mul 1 exch sub
						} {
							1.0 lt {FrameCurGray} {1} ifelse
						} ifelse
					} for
					RealSetrgbcolor
				} ifelse
			} ifelse
		} ifelse
	} { 
		FrameCurColors 0 4 getinterval aload
		FrameColorInSepListCMYK {
			FrameSepBlack eq exch 
			FrameSepYellow eq and exch 
			FrameSepMagenta eq and exch 
			FrameSepCyan eq and
			FrameSepIs FMcustom eq and
			{ FrameCurGray } { 1 } ifelse
		} {
			FrameSepIs FMblack eq
			{FrameCurGray 1.0 exch sub mul 1.0 exch sub 4 1 roll pop pop pop} {
			FrameSepIs FMyellow eq
			{pop FrameCurGray 1.0 exch sub mul 1.0 exch sub 3 1 roll pop pop} {
			FrameSepIs FMmagenta eq
			{pop pop FrameCurGray 1.0 exch sub mul 1.0 exch sub exch pop } {
			FrameSepIs FMcyan eq
			{pop pop pop FrameCurGray 1.0 exch sub mul 1.0 exch sub } 
			{pop pop pop pop 1} ifelse } ifelse } ifelse } ifelse 
		} ifelse
		graymode FMLevel1 or not {
			
			[/Pattern [/DeviceGray]] setcolorspace
			FrameCurPat setcolor
		} { 
			graymode not FMLevel1 and {
				
				dup 1 lt {pop FrameCurGray} if
			} if
			RealSetgray
		} ifelse
	} ifelse
} bind def
/savematrix {
	orgmatrix currentmatrix pop
	} bind def
/restorematrix {
	orgmatrix setmatrix
	} bind def
/dmatrix matrix def
/dpi    72 0 dmatrix defaultmatrix dtransform
    dup mul exch   dup mul add   sqrt def
	
/freq dpi dup 72 div round dup 0 eq {pop 1} if 8 mul div def
/sangle 1 0 dmatrix defaultmatrix dtransform exch atan def
/dpiranges   [  2540    2400    1693     1270    1200     635      600      0      ] def
/CMLowFreqs  [ 100.402  94.8683 89.2289 100.402  94.8683  66.9349  63.2456 47.4342 ] def
/YLowFreqs   [  95.25   90.0    84.65    95.25   90.0     70.5556  66.6667 50.0    ] def
/KLowFreqs   [  89.8026 84.8528 79.8088  89.8026 84.8528  74.8355  70.7107 53.033  ] def
/CLowAngles  [  71.5651 71.5651 71.5651 71.5651  71.5651  71.5651  71.5651 71.5651 ] def
/MLowAngles  [  18.4349 18.4349 18.4349 18.4349  18.4349  18.4349  18.4349 18.4349 ] def
/YLowTDot    [  true    true    false    true    true     false    false   false   ] def
/CMHighFreqs [ 133.87  126.491 133.843  108.503 102.523  100.402   94.8683 63.2456 ] def
/YHighFreqs  [ 127.0   120.0   126.975  115.455 109.091   95.25    90.0    60.0    ] def
/KHighFreqs  [ 119.737 113.137 119.713  128.289 121.218   89.8026  84.8528 63.6395 ] def
/CHighAngles [  71.5651 71.5651 71.5651  70.0169 70.0169  71.5651  71.5651 71.5651 ] def
/MHighAngles [  18.4349 18.4349 18.4349  19.9831 19.9831  18.4349  18.4349 18.4349 ] def
/YHighTDot   [  false   false   true     false   false    true     true    false   ] def
/PatFreq     [	10.5833 10.0     9.4055  10.5833 10.0	  10.5833  10.0	   9.375   ] def
/screenIndex {
	0 1 dpiranges length 1 sub { dup dpiranges exch get 1 sub dpi le {exit} {pop} ifelse } for
} bind def
/getCyanScreen {
	FMUseHighFrequencyScreens { CHighAngles CMHighFreqs} {CLowAngles CMLowFreqs} ifelse
		screenIndex dup 3 1 roll get 3 1 roll get /FMSpotFunction load
} bind def
/getMagentaScreen {
	FMUseHighFrequencyScreens { MHighAngles CMHighFreqs } {MLowAngles CMLowFreqs} ifelse
		screenIndex dup 3 1 roll get 3 1 roll get /FMSpotFunction load
} bind def
/getYellowScreen {
	FMUseHighFrequencyScreens { YHighTDot YHighFreqs} { YLowTDot YLowFreqs } ifelse
		screenIndex dup 3 1 roll get 3 1 roll get { 3 div
			{2 { 1 add 2 div 3 mul dup floor sub 2 mul 1 sub exch} repeat
			FMSpotFunction } } {/FMSpotFunction load } ifelse
			0.0 exch
} bind def
/getBlackScreen  {
	FMUseHighFrequencyScreens { KHighFreqs } { KLowFreqs } ifelse
		screenIndex get 45.0 /FMSpotFunction load 
} bind def
/getSpotScreen {
	getBlackScreen
} bind def
/getCompositeScreen {
	getBlackScreen
} bind def
/FMSetScreen 
	FMLevel1 { /setscreen load 
	}{ {
		8 dict begin
		/HalftoneType 1 def
		/SpotFunction exch def
		/Angle exch def
		/Frequency exch def
		/AccurateScreens FMUseAcccurateScreens def
		currentdict end sethalftone
	} bind } ifelse
def
/setDefaultScreen {
	FMPColor {
		orgrxfer cvx orggxfer cvx orgbxfer cvx orgxfer cvx setcolortransfer
	}
	{
		orgxfer cvx settransfer
	} ifelse
	orgfreq organgle orgproc cvx setscreen
} bind def
/setCurrentScreen {
	FrameSepIs FMnone eq {
		FMUseDefaultNoSeparationScreen {
			setDefaultScreen
		} {
			getCompositeScreen FMSetScreen
		} ifelse
	} {
		FrameSepIs FMcustom eq {
			FMUseDefaultSpotSeparationScreen {
				setDefaultScreen
			} {
				getSpotScreen FMSetScreen
			} ifelse
		} {
			FMUseDefaultProcessSeparationScreen {
				setDefaultScreen
			} {
				FrameSepIs FMcyan eq {
					getCyanScreen FMSetScreen
				} {
					FrameSepIs FMmagenta eq {
						getMagentaScreen FMSetScreen
					} {
						FrameSepIs FMyellow eq {
							getYellowScreen FMSetScreen
						} {
							getBlackScreen FMSetScreen
						} ifelse
					} ifelse
				} ifelse
			} ifelse
		} ifelse
	} ifelse 
} bind def
end
	/gstring FMLOCAL
	/gfile FMLOCAL
	/gindex FMLOCAL
	/orgrxfer FMLOCAL
	/orggxfer FMLOCAL
	/orgbxfer FMLOCAL
	/orgxfer FMLOCAL
	/orgproc FMLOCAL
	/orgrproc FMLOCAL
	/orggproc FMLOCAL
	/orgbproc FMLOCAL
	/organgle FMLOCAL
	/orgrangle FMLOCAL
	/orggangle FMLOCAL
	/orgbangle FMLOCAL
	/orgfreq FMLOCAL
	/orgrfreq FMLOCAL
	/orggfreq FMLOCAL
	/orgbfreq FMLOCAL
	/yscale FMLOCAL
	/xscale FMLOCAL
	/edown FMLOCAL
	/manualfeed FMLOCAL
	/paperheight FMLOCAL
	/paperwidth FMLOCAL
/FMDOCUMENT { 
	array /FMfonts exch def 
	/#copies exch def
	FrameDict begin
	0 ne /manualfeed exch def
	/paperheight exch def
	/paperwidth exch def
	0 ne /FrameNegative exch def 
	0 ne /edown exch def 
	/yscale exch def
	/xscale exch def
	FMLevel1 {
		manualfeed {setmanualfeed} if
		/FMdicttop countdictstack 1 add def 
		/FMoptop count def 
		setpapername 
		manualfeed {true} {papersize} ifelse 
		{manualpapersize} {false} ifelse 
		{desperatepapersize} {false} ifelse 
		{ (Can't select requested paper size for Frame print job!) FMFAILURE } if
		count -1 FMoptop {pop pop} for
		countdictstack -1 FMdicttop {pop end} for 
		}
		{{1 dict dup /PageSize [paperwidth paperheight]put setpagedevice}stopped
		{ (Can't select requested paper size for Frame print job!) FMFAILURE } if
		 {1 dict dup /ManualFeed manualfeed put setpagedevice } stopped pop }
	ifelse 
	
	FMPColor {
		currentcolorscreen
			cvlit /orgproc exch def
				  /organgle exch def 
				  /orgfreq exch def
			cvlit /orgbproc exch def
				  /orgbangle exch def 
				  /orgbfreq exch def
			cvlit /orggproc exch def
				  /orggangle exch def 
				  /orggfreq exch def
			cvlit /orgrproc exch def
				  /orgrangle exch def 
				  /orgrfreq exch def
			currentcolortransfer 
			FrameNegative {
				1 1 4 { 
					pop { 1 exch sub } concatprocs 4 1 roll
				} for
				4 copy
				setcolortransfer
			} if
			cvlit /orgxfer exch def
			cvlit /orgbxfer exch def
			cvlit /orggxfer exch def
			cvlit /orgrxfer exch def
	} {
		currentscreen 
			cvlit /orgproc exch def
				  /organgle exch def 
				  /orgfreq exch def
				  
		currenttransfer 
		FrameNegative {
			{ 1 exch sub } concatprocs
			dup settransfer
		} if 
		cvlit /orgxfer exch def
	} ifelse
	end 
} def 
/pagesave FMLOCAL
/orgmatrix FMLOCAL
/landscape FMLOCAL
/pwid FMLOCAL
/FMBEGINPAGE { 
	FrameDict begin 
	/pagesave save def
	3.86 setmiterlimit
	/landscape exch 0 ne def
	landscape { 
		90 rotate 0 exch dup /pwid exch def neg translate pop 
	}{
		pop /pwid exch def
	} ifelse
	edown { [-1 0 0 1 pwid 0] concat } if
	0 0 moveto paperwidth 0 lineto paperwidth paperheight lineto 
	0 paperheight lineto 0 0 lineto 1 setgray fill
	xscale yscale scale
	/orgmatrix matrix def
	gsave 
} def 
/FMENDPAGE {
	grestore 
	pagesave restore
	end 
	showpage
	} def 
/FMFONTDEFINE { 
	FrameDict begin
	findfont 
	ReEncode 
	1 index exch 
	definefont 
	FMfonts 3 1 roll 
	put
	end 
	} def 
/FMFILLS {
	FrameDict begin dup
	array /fillvals exch def
	dict /patCache exch def
	end 
	} def 
/FMFILL {
	FrameDict begin
	 fillvals 3 1 roll put
	end 
	} def 
/FMNORMALIZEGRAPHICS { 
	newpath
	0.0 0.0 moveto
	1 setlinewidth
	0 setlinecap
	0 0 0 sethsbcolor
	0 setgray 
	} bind def
	/fx FMLOCAL
	/fy FMLOCAL
	/fh FMLOCAL
	/fw FMLOCAL
	/llx FMLOCAL
	/lly FMLOCAL
	/urx FMLOCAL
	/ury FMLOCAL
/FMBEGINEPSF { 
	end 
	/FMEPSF save def 
	/showpage {} def 
% See Adobe's "PostScript Language Reference Manual, 2nd Edition", page 714.
% "...the following operators MUST NOT be used in an EPS file:" (emphasis ours)
	/banddevice {(banddevice) FMBADEPSF} def
	/clear {(clear) FMBADEPSF} def
	/cleardictstack {(cleardictstack) FMBADEPSF} def 
	/copypage {(copypage) FMBADEPSF} def
	/erasepage {(erasepage) FMBADEPSF} def
	/exitserver {(exitserver) FMBADEPSF} def
	/framedevice {(framedevice) FMBADEPSF} def
	/grestoreall {(grestoreall) FMBADEPSF} def
	/initclip {(initclip) FMBADEPSF} def
	/initgraphics {(initgraphics) FMBADEPSF} def
	/initmatrix {(initmatrix) FMBADEPSF} def
	/quit {(quit) FMBADEPSF} def
	/renderbands {(renderbands) FMBADEPSF} def
	/setglobal {(setglobal) FMBADEPSF} def
	/setpagedevice {(setpagedevice) FMBADEPSF} def
	/setshared {(setshared) FMBADEPSF} def
	/startjob {(startjob) FMBADEPSF} def
	/lettertray {(lettertray) FMBADEPSF} def
	/letter {(letter) FMBADEPSF} def
	/lettersmall {(lettersmall) FMBADEPSF} def
	/11x17tray {(11x17tray) FMBADEPSF} def
	/11x17 {(11x17) FMBADEPSF} def
	/ledgertray {(ledgertray) FMBADEPSF} def
	/ledger {(ledger) FMBADEPSF} def
	/legaltray {(legaltray) FMBADEPSF} def
	/legal {(legal) FMBADEPSF} def
	/statementtray {(statementtray) FMBADEPSF} def
	/statement {(statement) FMBADEPSF} def
	/executivetray {(executivetray) FMBADEPSF} def
	/executive {(executive) FMBADEPSF} def
	/a3tray {(a3tray) FMBADEPSF} def
	/a3 {(a3) FMBADEPSF} def
	/a4tray {(a4tray) FMBADEPSF} def
	/a4 {(a4) FMBADEPSF} def
	/a4small {(a4small) FMBADEPSF} def
	/b4tray {(b4tray) FMBADEPSF} def
	/b4 {(b4) FMBADEPSF} def
	/b5tray {(b5tray) FMBADEPSF} def
	/b5 {(b5) FMBADEPSF} def
	FMNORMALIZEGRAPHICS 
	[/fy /fx /fh /fw /ury /urx /lly /llx] {exch def} forall 
	fx fw 2 div add fy fh 2 div add  translate
	rotate
	fw 2 div neg fh 2 div neg translate
	fw urx llx sub div fh ury lly sub div scale 
	llx neg lly neg translate 
	/FMdicttop countdictstack 1 add def 
	/FMoptop count def 
	} bind def
/FMENDEPSF {
	count -1 FMoptop {pop pop} for 
	countdictstack -1 FMdicttop {pop end} for 
	FMEPSF restore
	FrameDict begin 
	} bind def
FrameDict begin 
/setmanualfeed {
%%BeginFeature *ManualFeed True
	 statusdict /manualfeed true put
%%EndFeature
	} bind def
/max {2 copy lt {exch} if pop} bind def
/min {2 copy gt {exch} if pop} bind def
/inch {72 mul} def
/pagedimen { 
	paperheight sub abs 16 lt exch 
	paperwidth sub abs 16 lt and
	{/papername exch def} {pop} ifelse
	} bind def
	/papersizedict FMLOCAL
/setpapername { 
	/papersizedict 14 dict def 
	papersizedict begin
	/papername /unknown def 
		/Letter 8.5 inch 11.0 inch pagedimen
		/LetterSmall 7.68 inch 10.16 inch pagedimen
		/Tabloid 11.0 inch 17.0 inch pagedimen
		/Ledger 17.0 inch 11.0 inch pagedimen
		/Legal 8.5 inch 14.0 inch pagedimen
		/Statement 5.5 inch 8.5 inch pagedimen
		/Executive 7.5 inch 10.0 inch pagedimen
		/A3 11.69 inch 16.5 inch pagedimen
		/A4 8.26 inch 11.69 inch pagedimen
		/A4Small 7.47 inch 10.85 inch pagedimen
		/B4 10.125 inch 14.33 inch pagedimen
		/B5 7.16 inch 10.125 inch pagedimen
	end
	} bind def
/papersize {
	papersizedict begin
		/Letter {lettertray letter} def
		/LetterSmall {lettertray lettersmall} def
		/Tabloid {11x17tray 11x17} def
		/Ledger {ledgertray ledger} def
		/Legal {legaltray legal} def
		/Statement {statementtray statement} def
		/Executive {executivetray executive} def
		/A3 {a3tray a3} def
		/A4 {a4tray a4} def
		/A4Small {a4tray a4small} def
		/B4 {b4tray b4} def
		/B5 {b5tray b5} def
		/unknown {unknown} def
	papersizedict dup papername known {papername} {/unknown} ifelse get
	end
	statusdict begin stopped end 
	} bind def
/manualpapersize {
	papersizedict begin
		/Letter {letter} def
		/LetterSmall {lettersmall} def
		/Tabloid {11x17} def
		/Ledger {ledger} def
		/Legal {legal} def
		/Statement {statement} def
		/Executive {executive} def
		/A3 {a3} def
		/A4 {a4} def
		/A4Small {a4small} def
		/B4 {b4} def
		/B5 {b5} def
		/unknown {unknown} def
	papersizedict dup papername known {papername} {/unknown} ifelse get
	end
	stopped 
	} bind def
/desperatepapersize {
	statusdict /setpageparams known
		{
		paperwidth paperheight 0 1 
		statusdict begin
		{setpageparams} stopped 
		end
		} {true} ifelse 
	} bind def
/DiacriticEncoding [
/.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef
/.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef
/.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef
/.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef
/.notdef /.notdef /.notdef /.notdef /space /exclam /quotedbl
/numbersign /dollar /percent /ampersand /quotesingle /parenleft
/parenright /asterisk /plus /comma /hyphen /period /slash /zero /one
/two /three /four /five /six /seven /eight /nine /colon /semicolon
/less /equal /greater /question /at /A /B /C /D /E /F /G /H /I /J /K
/L /M /N /O /P /Q /R /S /T /U /V /W /X /Y /Z /bracketleft /backslash
/bracketright /asciicircum /underscore /grave /a /b /c /d /e /f /g /h
/i /j /k /l /m /n /o /p /q /r /s /t /u /v /w /x /y /z /braceleft /bar
/braceright /asciitilde /.notdef /Adieresis /Aring /Ccedilla /Eacute
/Ntilde /Odieresis /Udieresis /aacute /agrave /acircumflex /adieresis
/atilde /aring /ccedilla /eacute /egrave /ecircumflex /edieresis
/iacute /igrave /icircumflex /idieresis /ntilde /oacute /ograve
/ocircumflex /odieresis /otilde /uacute /ugrave /ucircumflex
/udieresis /dagger /.notdef /cent /sterling /section /bullet
/paragraph /germandbls /registered /copyright /trademark /acute
/dieresis /.notdef /AE /Oslash /.notdef /.notdef /.notdef /.notdef
/yen /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef
/ordfeminine /ordmasculine /.notdef /ae /oslash /questiondown
/exclamdown /logicalnot /.notdef /florin /.notdef /.notdef
/guillemotleft /guillemotright /ellipsis /.notdef /Agrave /Atilde
/Otilde /OE /oe /endash /emdash /quotedblleft /quotedblright
/quoteleft /quoteright /.notdef /.notdef /ydieresis /Ydieresis
/fraction /currency /guilsinglleft /guilsinglright /fi /fl /daggerdbl
/periodcentered /quotesinglbase /quotedblbase /perthousand
/Acircumflex /Ecircumflex /Aacute /Edieresis /Egrave /Iacute
/Icircumflex /Idieresis /Igrave /Oacute /Ocircumflex /.notdef /Ograve
/Uacute /Ucircumflex /Ugrave /dotlessi /circumflex /tilde /macron
/breve /dotaccent /ring /cedilla /hungarumlaut /ogonek /caron
] def
/ReEncode { 
	dup 
	length 
	dict begin 
	{
	1 index /FID ne 
		{def} 
		{pop pop} ifelse 
	} forall 
	0 eq {/Encoding DiacriticEncoding def} if 
	currentdict 
	end 
	} bind def
FMPColor 
	
	{
	/BEGINBITMAPCOLOR { 
		BITMAPCOLOR} def
	/BEGINBITMAPCOLORc { 
		BITMAPCOLORc} def
	/BEGINBITMAPTRUECOLOR { 
		BITMAPTRUECOLOR } def
	/BEGINBITMAPTRUECOLORc { 
		BITMAPTRUECOLORc } def
	}
	
	{
	/BEGINBITMAPCOLOR { 
		BITMAPGRAY} def
	/BEGINBITMAPCOLORc { 
		BITMAPGRAYc} def
	/BEGINBITMAPTRUECOLOR { 
		BITMAPTRUEGRAY } def
	/BEGINBITMAPTRUECOLORc { 
		BITMAPTRUEGRAYc } def
	}
ifelse
/K { 
	FMPrintAllColorsAsBlack {
		dup 1 eq 2 index 1 eq and 3 index 1 eq and not
			{7 {pop} repeat 0 0 0 1 0 0 0} if
	} if 
	FrameCurColors astore 
	pop combineColor
} bind def
/graymode true def
	/bwidth FMLOCAL
	/bpside FMLOCAL
	/bstring FMLOCAL
	/onbits FMLOCAL
	/offbits FMLOCAL
	/xindex FMLOCAL
	/yindex FMLOCAL
	/x FMLOCAL
	/y FMLOCAL
/setPatternMode {
	FMLevel1 {
		/bwidth  exch def
		/bpside  exch def
		/bstring exch def
		/onbits 0 def  /offbits 0 def
		freq sangle landscape {90 add} if 
			{/y exch def
			 /x exch def
			 /xindex x 1 add 2 div bpside mul cvi def
			 /yindex y 1 add 2 div bpside mul cvi def
			 bstring yindex bwidth mul xindex 8 idiv add get
			 1 7 xindex 8 mod sub bitshift and 0 ne FrameNegative {not} if
			 {/onbits  onbits  1 add def 1}
			 {/offbits offbits 1 add def 0}
			 ifelse
			}
			setscreen
		offbits offbits onbits add div FrameNegative {1.0 exch sub} if
		/FrameCurGray exch def
	} { 
		pop pop
		dup patCache exch known {
			patCache exch get
		} { 
			dup
			patDict /bstring 3 -1 roll put
			patDict 
			9 PatFreq screenIndex get div dup matrix scale
			makepattern
			dup 
			patCache 4 -1 roll 3 -1 roll put
		} ifelse
		/FrameCurGray 0 def
		/FrameCurPat exch def
	} ifelse
	/graymode false def
	combineColor
} bind def
/setGrayScaleMode {
	graymode not {
		/graymode true def
		FMLevel1 {
			setCurrentScreen
		} if
	} if
	/FrameCurGray exch def
	combineColor
} bind def
/normalize {
	transform round exch round exch itransform
	} bind def
/dnormalize {
	dtransform round exch round exch idtransform
	} bind def
/lnormalize { 
	0 dtransform exch cvi 2 idiv 2 mul 1 add exch idtransform pop
	} bind def
/H { 
	lnormalize setlinewidth
	} bind def
/Z {
	setlinecap
	} bind def
	
/PFill {
	graymode FMLevel1 or not {
		gsave 1 setgray eofill grestore
	} if
} bind def
/PStroke {
	graymode FMLevel1 or not {
		gsave 1 setgray stroke grestore
	} if
	stroke
} bind def
	/fillvals FMLOCAL
/X { 
	fillvals exch get
	dup type /stringtype eq
	{8 1 setPatternMode} 
	{setGrayScaleMode}
	ifelse
	} bind def
/V { 
	PFill gsave eofill grestore
	} bind def
/Vclip {
	clip
	} bind def
/Vstrk {
	currentlinewidth exch setlinewidth PStroke setlinewidth
	} bind def
/N { 
	PStroke
	} bind def
/Nclip {
	strokepath clip newpath
	} bind def
/Nstrk {
	currentlinewidth exch setlinewidth PStroke setlinewidth
	} bind def
/M {newpath moveto} bind def
/E {lineto} bind def
/D {curveto} bind def
/O {closepath} bind def
	/n FMLOCAL
/L { 
 	/n exch def
	newpath
	normalize
	moveto 
	2 1 n {pop normalize lineto} for
	} bind def
/Y { 
	L 
	closepath
	} bind def
	/x1 FMLOCAL
	/x2 FMLOCAL
	/y1 FMLOCAL
	/y2 FMLOCAL
/R { 
	/y2 exch def
	/x2 exch def
	/y1 exch def
	/x1 exch def
	x1 y1
	x2 y1
	x2 y2
	x1 y2
	4 Y 
	} bind def
	/rad FMLOCAL
/rarc 
	{rad 
	 arcto
	} bind def
/RR { 
	/rad exch def
	normalize
	/y2 exch def
	/x2 exch def
	normalize
	/y1 exch def
	/x1 exch def
	mark
	newpath
	{
	x1 y1 rad add moveto
	x1 y2 x2 y2 rarc
	x2 y2 x2 y1 rarc
	x2 y1 x1 y1 rarc
	x1 y1 x1 y2 rarc
	closepath
	} stopped {x1 y1 x2 y2 R} if 
	cleartomark
	} bind def
/RRR { 
	/rad exch def
	normalize /y4 exch def /x4 exch def
	normalize /y3 exch def /x3 exch def
	normalize /y2 exch def /x2 exch def
	normalize /y1 exch def /x1 exch def
	newpath
	normalize moveto 
	mark
	{
	x2 y2 x3 y3 rarc
	x3 y3 x4 y4 rarc
	x4 y4 x1 y1 rarc
	x1 y1 x2 y2 rarc
	closepath
	} stopped
	 {x1 y1 x2 y2 x3 y3 x4 y4 newpath moveto lineto lineto lineto closepath} if
	cleartomark
	} bind def
/C { 
	grestore
	gsave
	R 
	clip
	setCurrentScreen
} bind def
/CP { 
	grestore
	gsave
	Y 
	clip
	setCurrentScreen
} bind def
	/FMpointsize FMLOCAL
/F { 
	FMfonts exch get
	FMpointsize scalefont
	setfont
	} bind def
/Q { 
	/FMpointsize exch def
	F 
	} bind def
/T { 
	moveto show
	} bind def
/RF { 
	rotate
	0 ne {-1 1 scale} if
	} bind def
/TF { 
	gsave
	moveto 
	RF
	show
	grestore
	} bind def
/P { 
	moveto
	0 32 3 2 roll widthshow
	} bind def
/PF { 
	gsave
	moveto 
	RF
	0 32 3 2 roll widthshow
	grestore
	} bind def
/S { 
	moveto
	0 exch ashow
	} bind def
/SF { 
	gsave
	moveto
	RF
	0 exch ashow
	grestore
	} bind def
/B { 
	moveto
	0 32 4 2 roll 0 exch awidthshow
	} bind def
/BF { 
	gsave
	moveto
	RF
	0 32 4 2 roll 0 exch awidthshow
	grestore
	} bind def
/G { 
	gsave
	newpath
	normalize translate 0.0 0.0 moveto 
	dnormalize scale 
	0.0 0.0 1.0 5 3 roll arc 
	closepath 
	PFill fill
	grestore
	} bind def
/Gstrk {
	savematrix
    newpath
    2 index 2 div add exch 3 index 2 div sub exch 
    normalize 2 index 2 div sub exch 3 index 2 div add exch 
    translate
    scale 
    0.0 0.0 1.0 5 3 roll arc 
    restorematrix
    currentlinewidth exch setlinewidth PStroke setlinewidth
    } bind def
/Gclip { 
	newpath
	savematrix
	normalize translate 0.0 0.0 moveto 
	dnormalize scale 
	0.0 0.0 1.0 5 3 roll arc 
	closepath 
	clip newpath
	restorematrix
	} bind def
/GG { 
	gsave
	newpath
	normalize translate 0.0 0.0 moveto 
	rotate 
	dnormalize scale 
	0.0 0.0 1.0 5 3 roll arc 
	closepath
	PFill
	fill
	grestore
	} bind def
/GGclip { 
	savematrix
	newpath
    normalize translate 0.0 0.0 moveto 
    rotate 
    dnormalize scale 
    0.0 0.0 1.0 5 3 roll arc 
    closepath
	clip newpath
	restorematrix
	} bind def
/GGstrk { 
	savematrix
    newpath
    normalize translate 0.0 0.0 moveto 
    rotate 
    dnormalize scale 
    0.0 0.0 1.0 5 3 roll arc 
    closepath 
	restorematrix
    currentlinewidth exch setlinewidth PStroke setlinewidth
	} bind def
/A { 
	gsave
	savematrix
	newpath
	2 index 2 div add exch 3 index 2 div sub exch 
	normalize 2 index 2 div sub exch 3 index 2 div add exch 
	translate 
	scale 
	0.0 0.0 1.0 5 3 roll arc 
	restorematrix
	PStroke
	grestore
	} bind def
/Aclip {
	newpath
	savematrix
	normalize translate 0.0 0.0 moveto 
	dnormalize scale 
	0.0 0.0 1.0 5 3 roll arc 
	closepath 
	strokepath clip newpath
	restorematrix
} bind def
/Astrk {
	Gstrk
} bind def
/AA { 
	gsave
	savematrix
	newpath
	
	3 index 2 div add exch 4 index 2 div sub exch 
	
	normalize 3 index 2 div sub exch 4 index 2 div add exch
	translate 
	rotate 
	scale 
	0.0 0.0 1.0 5 3 roll arc 
	restorematrix
	PStroke
	grestore
	} bind def
/AAclip {
	savematrix
	newpath
    normalize translate 0.0 0.0 moveto 
    rotate 
    dnormalize scale 
    0.0 0.0 1.0 5 3 roll arc 
    closepath
	strokepath clip newpath
	restorematrix
} bind def
/AAstrk {
	GGstrk
} bind def
	/x FMLOCAL
	/y FMLOCAL
	/w FMLOCAL
	/h FMLOCAL
	/xx FMLOCAL
	/yy FMLOCAL
	/ww FMLOCAL
	/hh FMLOCAL
	/FMsaveobject FMLOCAL
	/FMoptop FMLOCAL
	/FMdicttop FMLOCAL
/BEGINPRINTCODE { 
	/FMdicttop countdictstack 1 add def 
	/FMoptop count 7 sub def 
	/FMsaveobject save def
	userdict begin 
	/showpage {} def 
	FMNORMALIZEGRAPHICS 
	3 index neg 3 index neg translate
	} bind def
/ENDPRINTCODE {
	count -1 FMoptop {pop pop} for 
	countdictstack -1 FMdicttop {pop end} for 
	FMsaveobject restore 
	} bind def
/gn { 
	0 
	{	46 mul 
		cf read pop 
		32 sub 
		dup 46 lt {exit} if 
		46 sub add 
		} loop
	add 
	} bind def
	/str FMLOCAL
/cfs { 
	/str sl string def 
	0 1 sl 1 sub {str exch val put} for 
	str def 
	} bind def
/ic [ 
	0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0223
	0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0223
	0
	{0 hx} {1 hx} {2 hx} {3 hx} {4 hx} {5 hx} {6 hx} {7 hx} {8 hx} {9 hx}
	{10 hx} {11 hx} {12 hx} {13 hx} {14 hx} {15 hx} {16 hx} {17 hx} {18 hx}
	{19 hx} {gn hx} {0} {1} {2} {3} {4} {5} {6} {7} {8} {9} {10} {11} {12}
	{13} {14} {15} {16} {17} {18} {19} {gn} {0 wh} {1 wh} {2 wh} {3 wh}
	{4 wh} {5 wh} {6 wh} {7 wh} {8 wh} {9 wh} {10 wh} {11 wh} {12 wh}
	{13 wh} {14 wh} {gn wh} {0 bl} {1 bl} {2 bl} {3 bl} {4 bl} {5 bl} {6 bl}
	{7 bl} {8 bl} {9 bl} {10 bl} {11 bl} {12 bl} {13 bl} {14 bl} {gn bl}
	{0 fl} {1 fl} {2 fl} {3 fl} {4 fl} {5 fl} {6 fl} {7 fl} {8 fl} {9 fl}
	{10 fl} {11 fl} {12 fl} {13 fl} {14 fl} {gn fl}
	] def
	/sl FMLOCAL
	/val FMLOCAL
	/ws FMLOCAL
	/im FMLOCAL
	/bs FMLOCAL
	/cs FMLOCAL
	/len FMLOCAL
	/pos FMLOCAL
/ms { 
	/sl exch def 
	/val 255 def 
	/ws cfs 
	/im cfs 
	/val 0 def 
	/bs cfs 
	/cs cfs 
	} bind def
400 ms 
/ip { 
	is 
	0 
	cf cs readline pop 
	{	ic exch get exec 
		add 
		} forall 
	pop 
	
	} bind def
/rip { 
	   
	  
	  bis ris copy pop 
      is
      0
      cf cs readline pop 
      {       ic exch get exec 
              add 
              } forall 
	  pop pop 
	  ris gis copy pop 
	  dup is exch 
	  
      cf cs readline pop 
      {       ic exch get exec 
              add 
              } forall 
	  pop pop
	  gis bis copy pop 
	  dup add is exch 
	  
      cf cs readline pop 
      {       ic exch get exec 
              add 
              } forall 
      pop 
      
      } bind def
/wh { 
	/len exch def 
	/pos exch def 
	ws 0 len getinterval im pos len getinterval copy pop
	pos len 
	} bind def
/bl { 
	/len exch def 
	/pos exch def 
	bs 0 len getinterval im pos len getinterval copy pop
	pos len 
	} bind def
/s1 1 string def
/fl { 
	/len exch def 
	/pos exch def 
	/val cf s1 readhexstring pop 0 get def
	pos 1 pos len add 1 sub {im exch val put} for
	pos len 
	} bind def
/hx { 
	3 copy getinterval 
	cf exch readhexstring pop pop 
	} bind def
	/h FMLOCAL
	/w FMLOCAL
	/d FMLOCAL
	/lb FMLOCAL
	/bitmapsave FMLOCAL
	/is FMLOCAL
	/cf FMLOCAL
/wbytes { 
      dup dup
      24 eq { pop pop 3 mul }
      { 8 eq {pop} {1 eq {7 add 8 idiv} {3 add 4 idiv} ifelse} ifelse } ifelse
	} bind def
/BEGINBITMAPBWc { 
	1 {} COMMONBITMAPc
	} bind def
/BEGINBITMAPGRAYc { 
	8 {} COMMONBITMAPc
	} bind def
/BEGINBITMAP2BITc { 
	2 {} COMMONBITMAPc
	} bind def
/COMMONBITMAPc { 
		 
	/r exch def
	/d exch def
	gsave
	
	3 index 2 div add exch	
	4 index 2 div add exch	
	translate		
	rotate			
	1 index 2 div neg	
	1 index 2 div neg	
	translate		
	scale			
	/h exch def /w exch def
	/lb w d wbytes def 
	sl lb lt {lb ms} if 
	/bitmapsave save def 
	r                    
	/is im 0 lb getinterval def 
	ws 0 lb getinterval is copy pop 
	/cf currentfile def 
	w h d [w 0 0 h neg 0 h] 
	{ip} image 
	bitmapsave restore 
	grestore
	} bind def
/BEGINBITMAPBW { 
	1 {} COMMONBITMAP
	} bind def
/BEGINBITMAPGRAY { 
	8 {} COMMONBITMAP
	} bind def
/BEGINBITMAP2BIT { 
	2 {} COMMONBITMAP
	} bind def
/COMMONBITMAP { 
	/r exch def
	/d exch def
	gsave
	
	3 index 2 div add exch	
	4 index 2 div add exch	
	translate		
	rotate			
	1 index 2 div neg	
	1 index 2 div neg	
	translate		
	scale			
	/h exch def /w exch def
	/bitmapsave save def 
	r                    
	/is w d wbytes string def
	/cf currentfile def 
	w h d [w 0 0 h neg 0 h] 
	{cf is readhexstring pop} image
	bitmapsave restore 
	grestore
	} bind def
/ngrayt 256 array def
/nredt 256 array def
/nbluet 256 array def
/ngreent 256 array def
	/gryt FMLOCAL
	/blut FMLOCAL
	/grnt FMLOCAL
	/redt FMLOCAL
	/indx FMLOCAL
	/cynu FMLOCAL
	/magu FMLOCAL
	/yelu FMLOCAL
	/k FMLOCAL
	/u FMLOCAL
FMLevel1 {
/colorsetup {
	currentcolortransfer
	/gryt exch def
	/blut exch def
	/grnt exch def
	/redt exch def
	0 1 255 {
		/indx exch def
		/cynu 1 red indx get 255 div sub def
		/magu 1 green indx get 255 div sub def
		/yelu 1 blue indx get 255 div sub def
		/k cynu magu min yelu min def
		/u k currentundercolorremoval exec def
%		/u 0 def
		nredt indx 1 0 cynu u sub max sub redt exec put
		ngreent indx 1 0 magu u sub max sub grnt exec put
		nbluet indx 1 0 yelu u sub max sub blut exec put
		ngrayt indx 1 k currentblackgeneration exec sub gryt exec put
	} for
	{255 mul cvi nredt exch get}
	{255 mul cvi ngreent exch get}
	{255 mul cvi nbluet exch get}
	{255 mul cvi ngrayt exch get}
	setcolortransfer
	{pop 0} setundercolorremoval
	{} setblackgeneration
	} bind def
}
{
/colorSetup2 {
	[ /Indexed /DeviceRGB 255 
		{dup red exch get 255 div 
		 exch dup green exch get 255 div 
		 exch blue exch get 255 div}
	] setcolorspace
} bind def
} ifelse
	/tran FMLOCAL
/fakecolorsetup {
	/tran 256 string def
	0 1 255 {/indx exch def 
		tran indx
		red indx get 77 mul
		green indx get 151 mul
		blue indx get 28 mul
		add add 256 idiv put} for
	currenttransfer
	{255 mul cvi tran exch get 255.0 div}
	exch concatprocs settransfer
} bind def
/BITMAPCOLOR { 
	/d 8 def
	gsave
	
	3 index 2 div add exch	
	4 index 2 div add exch	
	translate		
	rotate			
	1 index 2 div neg	
	1 index 2 div neg	
	translate		
	scale			
	/h exch def /w exch def
	/bitmapsave save def
	FMLevel1 {	
		colorsetup
		/is w d wbytes string def
		/cf currentfile def 
		w h d [w 0 0 h neg 0 h] 
		{cf is readhexstring pop} {is} {is} true 3 colorimage 
	} {
		colorSetup2
		/is w d wbytes string def
		/cf currentfile def 
		7 dict dup begin
			/ImageType 1 def
			/Width w def
			/Height h def
			/ImageMatrix [w 0 0 h neg 0 h] def
			/DataSource {cf is readhexstring pop} bind def
			/BitsPerComponent d def
			/Decode [0 255] def
		end image	
	} ifelse
	bitmapsave restore 
	grestore
	} bind def
/BITMAPCOLORc { 
	/d 8 def
	gsave
	
	3 index 2 div add exch	
	4 index 2 div add exch	
	translate		
	rotate			
	1 index 2 div neg	
	1 index 2 div neg	
	translate		
	scale			
	/h exch def /w exch def
	/lb w d wbytes def 
	sl lb lt {lb ms} if 
	/bitmapsave save def 
	FMLevel1 {	
		colorsetup
		/is im 0 lb getinterval def 
		ws 0 lb getinterval is copy pop 
		/cf currentfile def 
		w h d [w 0 0 h neg 0 h] 
		{ip} {is} {is} true 3 colorimage
	} {
		colorSetup2
		/is im 0 lb getinterval def 
		ws 0 lb getinterval is copy pop 
		/cf currentfile def 
		7 dict dup begin
			/ImageType 1 def
			/Width w def
			/Height h def
			/ImageMatrix [w 0 0 h neg 0 h] def
			/DataSource {ip} bind def
			/BitsPerComponent d def
			/Decode [0 255] def
		end image	
	} ifelse
	bitmapsave restore 
	grestore
	} bind def
/BITMAPTRUECOLORc { 
	/d 24 def
        gsave
 	
	3 index 2 div add exch	
	4 index 2 div add exch	
	translate		
	rotate			
	1 index 2 div neg	
	1 index 2 div neg	
	translate		
	scale			
	/h exch def /w exch def
	/lb w d wbytes def 
	sl lb lt {lb ms} if 
        /bitmapsave save def 
        
	/is im 0 lb getinterval def	
	/ris im 0 w getinterval def	
	/gis im w w getinterval def	
	/bis im w 2 mul w getinterval def 
        
        ws 0 lb getinterval is copy pop 
        /cf currentfile def 
        w h 8 [w 0 0 h neg 0 h] 
        {w rip pop ris} {gis} {bis} true 3 colorimage
        bitmapsave restore 
        grestore
        } bind def
/BITMAPTRUECOLOR { 
        gsave
		
		3 index 2 div add exch	
		4 index 2 div add exch	
		translate		
		rotate			
		1 index 2 div neg	
		1 index 2 div neg	
		translate		
		scale			
		/h exch def /w exch def
        /bitmapsave save def 
        /is w string def
        /gis w string def
        /bis w string def
        /cf currentfile def 
        w h 8 [w 0 0 h neg 0 h] 
        { cf is readhexstring pop } 
        { cf gis readhexstring pop } 
        { cf bis readhexstring pop } 
        true 3 colorimage 
        bitmapsave restore 
        grestore
        } bind def
/BITMAPTRUEGRAYc { 
	/d 24 def
        gsave
	
	3 index 2 div add exch	
	4 index 2 div add exch	
	translate		
	rotate			
	1 index 2 div neg	
	1 index 2 div neg	
	translate		
	scale			
	/h exch def /w exch def
	/lb w d wbytes def 
	sl lb lt {lb ms} if 
        /bitmapsave save def 
        
	/is im 0 lb getinterval def	
	/ris im 0 w getinterval def	
	/gis im w w getinterval def	
	/bis im w 2 mul w getinterval def 
        ws 0 lb getinterval is copy pop 
        /cf currentfile def 
        w h 8 [w 0 0 h neg 0 h] 
        {w rip pop ris gis bis w gray} image
        bitmapsave restore 
        grestore
        } bind def
/ww FMLOCAL
/r FMLOCAL
/g FMLOCAL
/b FMLOCAL
/i FMLOCAL
/gray { 
        /ww exch def
        /b exch def
        /g exch def
        /r exch def
        0 1 ww 1 sub { /i exch def r i get .299 mul g i get .587 mul
			b i get .114 mul add add r i 3 -1 roll floor cvi put } for
        r
        } bind def
/BITMAPTRUEGRAY { 
        gsave
		
		3 index 2 div add exch	
		4 index 2 div add exch	
		translate		
		rotate			
		1 index 2 div neg	
		1 index 2 div neg	
		translate		
		scale			
		/h exch def /w exch def
        /bitmapsave save def 
        /is w string def
        /gis w string def
        /bis w string def
        /cf currentfile def 
        w h 8 [w 0 0 h neg 0 h] 
        { cf is readhexstring pop 
          cf gis readhexstring pop 
          cf bis readhexstring pop w gray}  image
        bitmapsave restore 
        grestore
        } bind def
/BITMAPGRAY { 
	8 {fakecolorsetup} COMMONBITMAP
	} bind def
/BITMAPGRAYc { 
	8 {fakecolorsetup} COMMONBITMAPc
	} bind def
/ENDBITMAP {
	} bind def
end 
	/ALDsave FMLOCAL
	/ALDmatrix matrix def ALDmatrix currentmatrix pop
/StartALD {
	/ALDsave save def
	 savematrix
	 ALDmatrix setmatrix
	} bind def
/InALD {
	 restorematrix
	} bind def
/DoneALD {
	 ALDsave restore
	} bind def
/I { setdash } bind def
/J { [] 0 setdash } bind def
%%EndProlog
%%BeginSetup
(4.0) FMVERSION
1 1 0 0 612 792 0 1 6 FMDOCUMENT
0 0 /Times-Roman FMFONTDEFINE
1 0 /Times-Bold FMFONTDEFINE
2 0 /Times-Italic FMFONTDEFINE
32 FMFILLS
0 0 FMFILL
1 0.1 FMFILL
2 0.3 FMFILL
3 0.5 FMFILL
4 0.7 FMFILL
5 0.9 FMFILL
6 0.97 FMFILL
7 1 FMFILL
8 <0f1e3c78f0e1c387> FMFILL
9 <0f87c3e1f0783c1e> FMFILL
10 <cccccccccccccccc> FMFILL
11 <ffff0000ffff0000> FMFILL
12 <8142241818244281> FMFILL
13 <03060c183060c081> FMFILL
14 <8040201008040201> FMFILL
16 1 FMFILL
17 0.9 FMFILL
18 0.7 FMFILL
19 0.5 FMFILL
20 0.3 FMFILL
21 0.1 FMFILL
22 0.03 FMFILL
23 0 FMFILL
24 <f0e1c3870f1e3c78> FMFILL
25 <f0783c1e0f87c3e1> FMFILL
26 <3333333333333333> FMFILL
27 <0000ffff0000ffff> FMFILL
28 <7ebddbe7e7dbbd7e> FMFILL
29 <fcf9f3e7cf9f3f7e> FMFILL
30 <7fbfdfeff7fbfdfe> FMFILL
%%EndSetup
%%Page: "1" 1
%%BeginPaperSize: Letter
%%EndPaperSize
612 792 0 FMBEGINPAGE
[0 0 0 1 0 0 0]
[ 0 1 1 0 1 0 0]
[ 1 0 1 0 0 1 0]
[ 1 1 0 0 0 0 1]
[ 1 0 0 0 0 1 1]
[ 0 1 0 0 1 0 1]
[ 0 0 1 0 1 1 0]
 7 FrameSetSepColors
FrameNoSep
0 0 0 1 0 0 0 K
J
0 0 0 1 0 0 0 K
72 746 540 756 R
7 X
0 0 0 1 0 0 0 K
V
75 36 543 46 R
V
0 10 Q
0 X
(Page 1) 516.06 39.18 T
0 0 0 1 0 0 0 K
0 0 0 1 0 0 0 K
72 72 540 720 R
7 X
V
0 12 Q
0 X
(PROVISIONAL APPLICATION) 225.17 576 T
1 14 Q
(A Pr) 103.97 550.67 T
(ocedur) 132.1 550.67 T
(e to Enable On-demand Specialization Acr) 173.06 550.67 T
(oss Arbitrary) 427.54 550.67 T
(Contr) 248.38 529.67 T
(ol-\337ow Edges) 283.89 529.67 T
0 12 Q
(Inventors:) 281.67 482 T
(Craig Chambers) 266.84 454 T
(Citizen of U.S.) 270 440 T
(residing in Seattle, Washington) 230.67 426 T
(and) 297.34 398 T
(Susan J. Eggers) 268.17 370 T
(Citizen of U.S.) 270 356 T
(residing in Seattle, Washington) 230.67 342 T
(and) 297.34 314 T
(Brian K. Grant) 270.17 286 T
(Citizen of U.S.) 270 272 T
(residing in Seattle, Washington) 230.67 258 T
(and) 297.34 230 T
(Markus Mock) 272.17 202 T
(Citizen of Germany.) 256.84 188 T
(residing in Seattle, Washington) 230.67 174 T
(and) 297.34 146 T
(Matthai Philipose) 263.5 118 T
(Citizen of India) 268.34 104 T
(residing in Seattle, Washington) 230.67 90 T
0 1 1 0 1 0 0 K
0 0 0 1 0 0 0 K
0 0 0 1 0 0 0 K
FMENDPAGE
%%EndPage: "1" 1
%%Page: "2" 2
612 792 0 FMBEGINPAGE
[0 0 0 1 0 0 0]
[ 0 1 1 0 1 0 0]
[ 1 0 1 0 0 1 0]
[ 1 1 0 0 0 0 1]
[ 1 0 0 0 0 1 1]
[ 0 1 0 0 1 0 1]
[ 0 0 1 0 1 1 0]
 7 FrameSetSepColors
FrameNoSep
0 0 0 1 0 0 0 K
72 746 540 756 R
7 X
0 0 0 1 0 0 0 K
V
75 36 543 46 R
V
0 10 Q
0 X
(Page 2) 516.06 39.18 T
0 0 0 1 0 0 0 K
0 0 0 1 0 0 0 K
72 72 540 720 R
7 X
V
1 14 Q
0 X
(Provisional Patent Application for) 203.53 640.67 T
(A Pr) 103.97 620.67 T
(ocedur) 132.1 620.67 T
(e to Enable On-demand Specialization Acr) 173.06 620.67 T
(oss Arbitrary) 427.54 620.67 T
(Contr) 248.38 599.67 T
(ol-\337ow Edges) 283.89 599.67 T
(Craig Chambers, Susan J. Eggers, Brian K. Grant, Markus Mock, and) 94.82 554.67 T
(Matthai Philipose) 252.91 537.67 T
(Field of Invention) 72 492.67 T
0 12 Q
6.43 (This invention relates to the field of dynamic compilation, specifically to deferring) 72 468.5 P
(specialization in an efficient and flexible manner.) 72 447.5 T
1 14 Q
(Summary) 72 425.17 T
0 12 Q
1.58 (This invention is a procedure that transforms a program so that the run-time specialization of) 72 401 P
1.12 (arbitrary parts of the program may be deferred until those parts are guaranteed to be executed.) 72 380 P
1.84 (The invention may be used in systems for dynamic program specialization, in order to make) 72 359 P
3.89 (specialization faster \050by not specializing code until it is sure to be executed\051, to enable) 72 338 P
0.58 (aggressive specialization that depends on interleaving execution and specialization, to guarantee) 72 317 P
2.34 (termination of certain aggressive forms of specialization and to reduce the amount of space) 72 296 P
1.03 (occupied by the specialized code. It can also be used in systems that apply optimizations other) 72 275 P
(than specialization dynamically.) 72 254 T
1 14 Q
(Background) 72 210.67 T
0 12 Q
2.29 (Specialization is the process of optimizing a program for specific values of variables in the) 72 186.5 P
1.12 (program. Specialization can be done at compile time, and/or while the program is running. An) 72 165.5 P
0.43 (advantage of specializing while the program is running is that specialization can be) 72 144.5 P
2 F
0.43 ( lazy) 476.4 144.5 P
0 F
0.43 (: a piece) 499.16 144.5 P
1.2 (of code need not be specialized until it is about to be executed. \050If, on the other hand, code is) 72 123.5 P
2.19 (specialized before its execution is guaranteed, we say that the specialization is) 72 102.5 P
2 F
2.19 (eager) 476.5 102.5 P
0 F
2.19 (\051. Lazy) 503.83 102.5 P
(specialization has at least two benefits:) 72 81.5 T
0 1 1 0 1 0 0 K
0 0 0 1 0 0 0 K
0 0 0 1 0 0 0 K
FMENDPAGE
%%EndPage: "2" 2
%%Page: "3" 3
612 792 0 FMBEGINPAGE
[0 0 0 1 0 0 0]
[ 0 1 1 0 1 0 0]
[ 1 0 1 0 0 1 0]
[ 1 1 0 0 0 0 1]
[ 1 0 0 0 0 1 1]
[ 0 1 0 0 1 0 1]
[ 0 0 1 0 1 1 0]
 7 FrameSetSepColors
FrameNoSep
0 0 0 1 0 0 0 K
72 746 540 756 R
7 X
0 0 0 1 0 0 0 K
V
75 36 543 46 R
V
0 10 Q
0 X
(Page 3) 516.06 39.18 T
0 0 0 1 0 0 0 K
0 0 0 1 0 0 0 K
72 72 540 720 R
7 X
V
0 12 Q
0 X
(1.) 72 712 T
(It enables specialization of variables \050known as) 90 712 T
2 F
(pr) 320.28 712 T
(omoted static) 330.5 712 T
0 F
(variables\051 whose values may) 397.84 712 T
(only be known when the thread of execution reaches the code awaiting lazy specialization.) 90 691 T
-0.08 (The value of a promoted static variable at a given program point may change many times dur-) 90 670 P
(ing execution of the program. Lazy specialization can produce optimized code for each of) 90 649 T
(these many values.) 90 628 T
(2.) 72 607 T
-0.17 (It enables deferred specialization of parts of the code that may not be executed, thereby reduc-) 90 607 P
(ing both the amount of specialized code produced and the overhead of producing it. In partic-) 90 586 T
(ular) 90 565 T
(, it enables an aggressive form of loop specialization, termed) 108.18 565 T
2 F
(complete loop unr) 402.79 565 T
(olling) 489.67 565 T
0 F
(:) 517.68 565 T
-0.18 (each iteration of the loop is specialized on-demand, as it is about to execute. In the absence of) 90 544 P
(lazy behavior) 90 523 T
(, specialization by complete loop-unrolling is not guaranteed to terminate.) 154.5 523 T
2.88 (In most systems that do not benefit from our invention, lazy specialization is restricted to) 72 502 P
2.45 (specializing entire functions on different values of function arguments. However, it is often) 72 481 P
0.36 (beneficial to lazily specialize parts of a program smaller than a function. Such parts may include) 72 460 P
1.09 (a rarely-taken side of a conditional branch, separate iterations of a loop, or a fragment of code) 72 439 P
(within a function that uses a static variable.) 72 418 T
0.86 (Some systems do allow a limited set of optimizations other than specialization to be performed) 72 397 P
1.45 (lazily on arbitrary parts of programs. However, when these systems resume optimization after) 72 376 P
2.04 (the deferral, they cannot use optimization information computed before the deferral, produce) 72 355 P
2.01 (optimized code for different instances of this optimization information, or defer optimization) 72 334 P
0.7 (again when optimizing the initial deferred part of the program. Without these capabilities, these) 72 313 P
0.64 (systems cannot add to their repertoire of optimizations specialization that specializes effectively) 72 292 P
1.46 (across a deferral, specializes on promoted static variables or provides complete loop-unrolling) 72 271 P
(that is guaranteed to terminate.) 72 250 T
0.84 (Our invention allows specialization of arbitrary program fragments, not just of entire functions.) 72 229 P
2.2 (Further, because we have a mechanism to propagate information across deferrals \050called the) 72 208 P
2 F
0.98 (context) 72 187 P
0 F
0.98 ( of specialization\051, we can both propagate optimization information across deferrals) 106.66 187 P
2 F
0.98 (and) 522 187 P
0 F
3.23 (specialize on promoted static variables \050the many values of which correspond to different) 72 166 P
1.67 (contexts\051. Finally, our invention is capable of deferring specialization while specializing code) 72 145 P
1.52 (that is already deferred, thereby enabling complete loop unrolling. We call this last capability) 72 124 P
2 F
(nested laziness) 72 103 T
0 F
(.) 143.66 103 T
0 1 1 0 1 0 0 K
0 0 0 1 0 0 0 K
0 0 0 1 0 0 0 K
FMENDPAGE
%%EndPage: "3" 3
%%Page: "4" 4
612 792 0 FMBEGINPAGE
[0 0 0 1 0 0 0]
[ 0 1 1 0 1 0 0]
[ 1 0 1 0 0 1 0]
[ 1 1 0 0 0 0 1]
[ 1 0 0 0 0 1 1]
[ 0 1 0 0 1 0 1]
[ 0 0 1 0 1 1 0]
 7 FrameSetSepColors
FrameNoSep
0 0 0 1 0 0 0 K
72 746 540 756 R
7 X
0 0 0 1 0 0 0 K
V
75 36 543 46 R
V
0 10 Q
0 X
(Page 4) 516.06 39.18 T
0 0 0 1 0 0 0 K
0 0 0 1 0 0 0 K
72 72 540 720 R
7 X
V
1 14 Q
0 X
(Construction and Operation of Invention) 72 689.67 T
0 12 Q
2.08 (We explain below how our invention enables the deferral of specialization until an arbitrary) 72 665.5 P
2.06 (program fragment executes. The first two paragraphs provide a high-level summary, and the) 72 644.5 P
(remaining paragraphs provide a detailed description.) 72 623.5 T
0.27 (Given a control-flow graph \050CFG\051 representation of a program, and a particular edge in the CFG) 72 602.5 P
0.72 (that connects two basic blocks, the invention provides a mechanism for eagerly specializing the) 72 581.5 P
1.84 (source block of the edge, while deferring the specialization of the destination block until the) 72 560.5 P
1.61 (specialized version of the source block and the edge are executed \050i.e., a mechanism for lazy) 72 539.5 P
0.95 (specialization\051. The invention replaces the edge with code that generates, immediately after the) 72 518.5 P
(source block is specialized, a) 72 497.5 T
2 F
(stub) 214.63 497.5 T
0 F
(.) 234.64 497.5 T
0.7 (The stub, when executed, gathers values of variables that comprise the context of specialization) 72 476.5 P
0.45 (of the destination block, and invokes a routine to specialize the destination block with respect to) 72 455.5 P
1.26 (the context. If possible, the stub patches in a direct branch from the specialized version of the) 72 434.5 P
1.52 (source block to the specialized version of the destination block, so that in future traversals of) 72 413.5 P
0.65 (this edge, the stub may be bypassed.) 72 392.5 P
0.65 (Finally, the stub jumps to the newly specialized version of) 254.18 392.5 P
(the destination block.) 72 86.5 T
72 72 540 720 C
0 0 0 1 0 0 0 K
80.75 103.5 531.25 388.5 C
0 0 0 1 0 0 0 K
220.58 162.5 381.58 385.5 C
0 0 0 1 0 0 0 K
0 0 0 1 0 0 0 K
220.58 162.5 381.58 385.5 R
7 X
0 0 0 1 0 0 0 K
V
239.58 307.5 338.58 352.5 R
V
0.5 H
2 Z
0 X
N
239.58 172.5 338.58 217.5 R
7 X
V
0 X
N
287.89 229.03 284.58 217.5 281.27 229.03 284.58 229.03 4 Y
V
284.58 307.5 284.58 229.03 2 L
N
0 12 Q
(B) 248.58 334.5 T
0 9.6 Q
(1) 256.59 331.5 T
0 12 Q
(\050source\051) 263.79 334.5 T
(B) 248.58 200.32 T
0 9.6 Q
(2) 256.59 197.32 T
0 12 Q
(\050destination\051) 263.79 200.32 T
(edge e) 285.6 262.32 T
0 9.6 Q
(12) 316.58 259.32 T
J
242.45 266.59 231.58 261.5 238.1 271.58 240.27 269.09 4 Y
V
J
286.58 309.5 240.27 269.09 2 L
J
286.58 309.5 283.76 307.03 2 L
N
[8.345 7.232] 8.345 I
283.76 307.03 243.1 271.55 2 L
N
J
243.1 271.55 240.27 269.09 2 L
N
J
80.75 103.5 531.25 388.5 C
109.25 108.5 500.92 150.5 R
7 X
0 0 0 1 0 0 0 K
V
1 12 Q
0 X
0.32 (Figure 1:) 109.25 142.5 P
0 F
0.32 (Two basic blocks B) 159.89 142.5 P
0 9.6 Q
0.26 (1) 255.85 139.5 P
0 12 Q
0.32 ( and B) 260.65 142.5 P
0 9.6 Q
0.26 (2) 292.62 139.5 P
0 12 Q
0.32 (with edge e) 300.08 142.5 P
0 9.6 Q
0.26 (12) 356.05 139.5 P
0 12 Q
0.32 ( across which specialization) 365.64 142.5 P
(should be suspended. The dotted edge represents other possible edges from B) 109.25 119.3 T
0 9.6 Q
(1) 481.19 116.3 T
0 12 Q
(.) 485.99 119.3 T
0 1 1 0 1 0 0 K
0 0 0 1 0 0 0 K
0 0 0 1 0 0 0 K
72 72 540 720 C
0 -208 1000 792 C
0 1 1 0 1 0 0 K
0 0 0 1 0 0 0 K
FMENDPAGE
%%EndPage: "4" 4
%%Page: "5" 5
612 792 0 FMBEGINPAGE
[0 0 0 1 0 0 0]
[ 0 1 1 0 1 0 0]
[ 1 0 1 0 0 1 0]
[ 1 1 0 0 0 0 1]
[ 1 0 0 0 0 1 1]
[ 0 1 0 0 1 0 1]
[ 0 0 1 0 1 1 0]
 7 FrameSetSepColors
FrameNoSep
0 0 0 1 0 0 0 K
72 746 540 756 R
7 X
0 0 0 1 0 0 0 K
V
75 36 543 46 R
V
0 10 Q
0 X
(Page 5) 516.06 39.18 T
0 0 0 1 0 0 0 K
0 0 0 1 0 0 0 K
72 72 540 720 R
7 X
V
0 12 Q
0 X
1.74 (In more detail, consider an edge e) 72 712 P
0 9.6 Q
1.39 (12) 244.71 709 P
0 12 Q
1.74 ( that connects two basic blocks, B) 254.31 712 P
0 9.6 Q
1.39 (1) 427.72 709 P
0 12 Q
1.74 ( and B) 432.52 712 P
0 9.6 Q
1.39 (2) 467.32 709 P
0 12 Q
1.74 (, as shown in) 472.12 712 P
1.65 (Figure 1. Suppose both B) 72 688.8 P
0 9.6 Q
1.32 (1) 200.95 685.8 P
0 12 Q
1.65 ( and B) 205.75 688.8 P
0 9.6 Q
1.32 (2) 240.38 685.8 P
0 12 Q
1.65 ( are to be specialized, but specialization will be suspended) 245.18 688.8 P
1.3 (across e) 72 665.6 P
0 9.6 Q
1.04 (12) 111.62 662.6 P
0 12 Q
1.3 ( \050e) 121.22 665.6 P
0 9.6 Q
1.04 (12) 134.84 662.6 P
0 12 Q
1.3 ( is then called a) 144.44 665.6 P
2 F
1.3 (lazy edge) 228.6 665.6 P
0 F
1.3 (\051. In other words, B) 274.89 665.6 P
0 9.6 Q
1.04 (2) 374.07 662.6 P
0 12 Q
1.3 ( will not be specialized until the) 378.87 665.6 P
1.58 (specialized version of B) 72 642.4 P
0 9.6 Q
1.26 (1) 192.37 639.4 P
0 12 Q
1.58 ( has been executed and execution seeks to continue across edge e) 197.17 642.4 P
0 9.6 Q
1.26 (12) 527.4 639.4 P
0 12 Q
1.58 (.) 537 642.4 P
0.75 (Figure 2 illustrates how our invention transforms the sub-graph shown in Figure 1 into a a sub-) 72 619.2 P
(graph, which, when executed, achieves suspended specialization across edge e) 72 598.2 T
0 9.6 Q
(12) 448.56 595.2 T
0 12 Q
(.) 458.16 598.2 T
0.47 (We assume the existence of a procedure that produces a specialized version of a given block for) 72 575 P
1.42 (a given context. Block 21 invokes this procedure to generate a specialized version of B) 72 554 P
0 9.6 Q
1.13 (1) 509.46 551 P
0 12 Q
1.42 ( \050call) 514.26 554 P
1.73 (this generated version B) 72 530.8 P
0 9.6 Q
1.38 (1) 193.5 527.8 P
0 12 Q
1.73 (\325\051. The execution of B) 198.3 530.8 P
0 9.6 Q
1.38 (1) 311.52 527.8 P
0 12 Q
1.73 (\325 computes values that constitute the context) 316.32 530.8 P
0.29 (that will be used to specialize block B) 72 507.6 P
0 9.6 Q
0.23 (2) 256.32 504.6 P
0 12 Q
0.29 (. Block 22 generates code to construct this context. Block) 261.12 507.6 P
0.96 (23 patches the branch at the end of B) 72 484.4 P
0 9.6 Q
0.77 (1) 257.62 481.4 P
0 12 Q
0.96 (\325 to point to the beginning of the context-gathering code) 262.42 484.4 P
(that was generated in block 22.) 72 461.2 T
0.19 (The code generated in block 22 is the beginning of the stub that will be executed if the execution) 72 440.2 P
0.44 (of B) 72 419.2 P
0 9.6 Q
0.35 (1) 93.43 416.2 P
0 12 Q
0.44 (\325 is followed by a traversal of edge e) 98.24 419.2 P
0 9.6 Q
0.35 (12) 277 416.2 P
0 12 Q
0.44 (. The next part of the stub to be generated \050by block) 286.6 419.2 P
2.85 (25\051 is code that invokes the specialization mechanism to specialize B) 72 396 P
0 9.6 Q
2.28 (2) 432.47 393 P
0 12 Q
2.85 ( with respect to the) 437.27 396 P
0.55 (context just constructed \050call the specialized version of B) 72 372.8 P
0 9.6 Q
0.44 (2) 351.02 369.8 P
0 12 Q
0.55 (, B) 355.82 372.8 P
0 9.6 Q
0.44 (2) 370.37 369.8 P
0 12 Q
0.55 (\325\051. Note that if B) 375.17 372.8 P
0 9.6 Q
0.44 (2) 457.03 369.8 P
0 12 Q
0.55 ( has a lazy edge) 461.83 372.8 P
1.81 (emanating from it \050nested laziness\051, the mechanism in Figure 2 would suspend specialization) 72 349.6 P
(across that edge as well. Specialization of deferred code can thus itself be lazy in our invention.) 72 328.6 T
0.17 (Now that code to construct B) 72 307.6 P
0 9.6 Q
0.13 (2) 213.15 304.6 P
0 12 Q
0.17 (\325 has been generated, block 28 generates a jump to B) 217.95 307.6 P
0 9.6 Q
0.13 (2) 473.23 304.6 P
0 12 Q
0.17 (\325, so that B) 478.03 307.6 P
0 9.6 Q
0.13 (2) 531.2 304.6 P
0 12 Q
0.17 (\325) 536 307.6 P
1.23 (is be executed after the stub is executed. This completes generation of the stub; block 29 then) 72 284.4 P
(specializes any other blocks that can be specialized without deferral.) 72 263.4 T
0.77 (If we know that the context for specializing B) 72 242.4 P
0 9.6 Q
0.62 (2) 298.15 239.4 P
0 12 Q
0.77 ( will be unchanged on all subsequent executions) 302.95 242.4 P
0.37 (of B) 72 219.2 P
0 9.6 Q
0.3 (1) 93.37 216.2 P
0 12 Q
0.37 (\325 \050i.e., if we know that the edge e) 98.17 219.2 P
0 9.6 Q
0.3 (12) 259.44 216.2 P
0 12 Q
0.37 ( is) 269.04 219.2 P
2 F
0.37 (one-time-lazy) 283.79 219.2 P
0 F
0.37 (, block 24\051, we can avoid executing the) 349.1 219.2 P
0.76 (stub in the future. In this case, block 27 generates code to patch the branch at the end of B) 72 196 P
0 9.6 Q
0.61 (1) 518.1 193 P
0 12 Q
0.76 (\325 to) 522.9 196 P
(point to the beginning of B) 72 172.8 T
0 9.6 Q
(2) 201.67 169.8 T
0 12 Q
(\325, thus bypassing the stub in future traversals of edge e) 206.47 172.8 T
0 9.6 Q
(12) 468.1 169.8 T
0 12 Q
(.) 477.7 172.8 T
1 14 Q
(Broadening) 72 148.27 T
0 12 Q
(1.) 72 124.1 T
(The notion of a value of a variable \050on which specialization takes place\051 can be broadened to) 90 124.1 T
-0.12 (include class, type or similar abstract properties of the variable. The context information gath-) 90 103.1 P
(ered and passed can have any of these kinds of information.) 90 82.1 T
0 1 1 0 1 0 0 K
0 0 0 1 0 0 0 K
0 0 0 1 0 0 0 K
FMENDPAGE
%%EndPage: "5" 5
%%Page: "6" 6
612 792 0 FMBEGINPAGE
[0 0 0 1 0 0 0]
[ 0 1 1 0 1 0 0]
[ 1 0 1 0 0 1 0]
[ 1 1 0 0 0 0 1]
[ 1 0 0 0 0 1 1]
[ 0 1 0 0 1 0 1]
[ 0 0 1 0 1 1 0]
 7 FrameSetSepColors
FrameNoSep
0 0 0 1 0 0 0 K
72 729 540 756 R
7 X
0 0 0 1 0 0 0 K
V
72 33.32 540 43.32 R
V
0 0 0 1 0 0 0 K
0 0 0 1 0 0 0 K
72 72 540 720 R
V
0 1 1 0 1 0 0 K
0 0 0 1 0 0 0 K
72 72 540 720 C
0 0 0 1 0 0 0 K
0 0 0 1 0 0 0 K
72 72 540 720 R
7 X
0 0 0 1 0 0 0 K
V
188 657.92 413 702.92 R
V
0.5 H
2 Z
0 X
N
186 210 411 255 R
7 X
V
0 X
N
188 583.17 413 624 R
7 X
V
0 X
N
152 507 441.83 552 R
7 X
V
0 X
N
187 439 417 475 R
7 X
V
0 X
N
250.09 365 301 415.91 351.91 365 301 314.09 4 Y
7 X
V
0 X
N
189 123 414 178 R
7 X
V
0 X
N
302.31 636.7 299 625.17 295.69 636.7 299 636.7 4 Y
V
299 660.17 299 636.7 2 L
N
302.31 564.54 299 553 295.69 564.54 299 564.54 4 Y
V
299 581 299 564.54 2 L
N
302.31 487.54 299 476 295.69 487.54 299 487.54 4 Y
V
299 505 299 487.54 2 L
N
450.31 341.54 447 330 443.69 341.54 447 341.54 4 Y
V
352 365 447 365 447 341.54 3 L
N
317.92 256.67 306 258.01 316.82 263.19 317.37 259.93 4 Y
V
442 281 317.37 259.92 2 L
N
195 673.17 406 687.67 R
7 X
V
0 12 Q
0 X
(21. Generate specialized version of B1) 195 679.67 T
0 1 1 0 1 0 0 K
0 0 0 1 0 0 0 K
195 596.33 406 610.83 R
7 X
V
0 X
(22. Generate context construction code) 195 602.83 T
0 1 1 0 1 0 0 K
0 0 0 1 0 0 0 K
162 516 434.5 543 R
7 X
V
0 X
(23. Generate code to backpatch specialized version of) 162 535 T
(B1 to point to context construction code) 162 521 T
0 1 1 0 1 0 0 K
0 0 0 1 0 0 0 K
276 339.17 328 386 R
7 X
V
0 X
(24. Edge) 276 378 T
(e12 one-) 276 364 T
(time-lazy?) 276 350 T
0 1 1 0 1 0 0 K
0 0 0 1 0 0 0 K
(YES) 388 369 T
194 442 410 470 R
7 X
V
0 X
-0.47 (25. Generate code to trigger specialization of) 194 462 P
(B2) 194 448 T
0 1 1 0 1 0 0 K
0 0 0 1 0 0 0 K
302.31 190.53 299 179 295.69 190.53 299 190.53 4 Y
V
299 211 299 190.53 2 L
N
194 132 407 166 R
7 X
V
0 X
(29. Continue specializing any other blocks) 194 158 T
(that need to be specialized eagerly with B1) 194 144 T
0 1 1 0 1 0 0 K
0 0 0 1 0 0 0 K
201 221 381 248 R
7 X
V
0 X
(28. Generate code to jump to special-) 201 240 T
(ized version of B2) 201 226 T
0 1 1 0 1 0 0 K
0 0 0 1 0 0 0 K
320 282 506 328 R
7 X
V
0 X
N
324 287 503 323 R
7 X
V
0 X
-0.61 (27. Generate code to backpatch B1 to) 324 315 P
(point to specialized version of B2) 324 301 T
0 1 1 0 1 0 0 K
0 0 0 1 0 0 0 K
231.31 266.53 228 255 224.69 266.53 228 266.53 4 Y
V
248 365 228 365 228 266.53 3 L
N
302.69 428.7 300 417 296.09 428.35 299.39 428.52 4 Y
V
299 436 299.39 428.52 2 L
N
111 84 523 113 R
7 X
V
1 F
0 X
(\336gur) 111 105 T
(e 2:) 135.46 105 T
0 F
( Result of transforming the graph on \336gure 1 to allow suspended specializa-) 153.78 105 T
-0.25 (tion on edge e12. Note that block B2 from \336gure 1 is referred to indirectly in block 27.) 111 91 P
0 1 1 0 1 0 0 K
0 0 0 1 0 0 0 K
J
177.96 631.04 166 632 176.65 637.52 177.3 634.28 4 Y
V
J
300 659 177.31 634.28 2 L
J
300 659 296.32 658.26 2 L
N
[7.447 6.454] 7.447 I
296.32 658.26 180.99 635.02 2 L
N
J
180.99 635.02 177.31 634.28 2 L
N
J
0 0 612 792 C
0 0 0 1 0 0 0 K
FMENDPAGE
%%EndPage: "6" 6
%%Page: "7" 7
612 792 0 FMBEGINPAGE
[0 0 0 1 0 0 0]
[ 0 1 1 0 1 0 0]
[ 1 0 1 0 0 1 0]
[ 1 1 0 0 0 0 1]
[ 1 0 0 0 0 1 1]
[ 0 1 0 0 1 0 1]
[ 0 0 1 0 1 1 0]
 7 FrameSetSepColors
FrameNoSep
0 0 0 1 0 0 0 K
72 746 540 756 R
7 X
0 0 0 1 0 0 0 K
V
75 36 543 46 R
V
0 10 Q
0 X
(Page 7) 516.06 39.18 T
0 0 0 1 0 0 0 K
0 0 0 1 0 0 0 K
72 72 540 720 R
7 X
V
0 12 Q
0 X
(2.) 72 712 T
(The run-time optimizations performed need not be restricted to specialization. Any run-time) 90 712 T
(optimization that bene\336ts from deferring optimization across certain branches can bene\336t) 90 691 T
(from our invention. For these optimizations, our system provides the bene\336ts of lazy optimi-) 90 670 T
(zation at arbitrary program points, of propagating optimization information across deferrals) 90 649 T
(\050through the context, which in this case would contain the particular optimization informa-) 90 628 T
(tion\051, and of nested laziness.) 90 607 T
0 1 1 0 1 0 0 K
0 0 0 1 0 0 0 K
0 0 0 1 0 0 0 K
FMENDPAGE
%%EndPage: "7" 7
%%Trailer
%%BoundingBox: 0 0 612 792
%%PageOrder: Ascend
%%Pages: 7
%%DocumentFonts: Times-Roman
%%+ Times-Bold
%%+ Times-Italic
%%EOF

Date: Sun, 7 Jun 1998 16:44:05 -0700
From: eggers@yakima (Susan Eggers)
To: spin-comp@cs
Subject: policy annotations

I've put an edited version of the policy annotations patent in our shared
area.  Turns out Markus and I were on the same plane, so I was able to talk
to him abit about the content.  I've tightened the text alot, but the section
that grinds through the process needs the same sort of tightening.  Either
of you (Brian and Matthai) are better able to do this part than I.  Can one
of you take a look?

I'll be back tomorrow.

Susan

Date: Mon, 8 Jun 1998 15:04:45 -0700 (PDT)
From: Patrick Jones <pljones@u.washington.edu>
To: Susan Eggers <eggers@cs.washington.edu>
cc: spin-comp@cs.washington.edu
Subject: Re: lazy spec

lazy looks very good

cache lookup looks good (somehow just doesn't have the zing of the prior
one plus I think you could flow diagram the process but it works)

What I would include in the Invention section after the detail is a short
description of experiments & data (tabular or graphical results are fine)
supporting the working of the ideas - assuming some is available. The key
aspect of the provisional is that it must be reduced to practice such that
the description is enabling - that is a collegue in the area reading what
you've put down could duplicate the invention w/o a lot of "undue
experimentation" 

If you need to give me a call 

pljones, Technology Manager
Office of Technology Transfer
University of Washington

voice 206-616-3451 fax 206-616-3322


Date: Tue, 9 Jun 1998 13:27:36 -0700
From: eggers@yakima (Susan Eggers)
To: spin-comp@cs
Subject: meeting

Can we bag it today, since we're still doing patents?

Susan

To: spin-comp@thistle.cs.washington.edu
Subject: policies patent
Date: Wed, 10 Jun 1998 02:04:27 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

Here is my proposal for revising the policies patent.  A copy of this is at:

/projects/dyncomp/SharedWorkingArea/Patents/policies-outline.txt

Upshot:

I think our contributions in this area are:

1. the concept & implementation of flow-sensitive policies to control run-time
   specialization

2. our particular policies

I think we should reorganize the text to better reflect this.

--Brian


Title
-----

Using Flow-Sensitive Policies to Control Run-Time Specialization


Background
----------

A. Problem
	1. Define specialization
	2. Typically, specializer policy is hard-coded in mechanism
	3. Different policies may be appropriate for different
	   programs
	4. Some policies can lead to over-specialization (example?),
	   which causes several problems
		a. reduced I-cache locality
		b. run-time overhead (for run-time specialization)
		c. non-termination (omit?)
	5. Problems with over-specialization causes many systems to
	   adopt policies that lead to under-specialization (e.g., no
	   intraprocedural polyvariant specialization)
	6. Run-time specialization has even more options and
	   considerations than compile-time specialization (e.g.,
	   caching, on-demand specialization)
	7. Rather than hard-code policy choices, would like to leave
	   them open so they can be easily changed for different
	   apps. or situations

B. Solution (this invention...)
	1. Separate policy from mechanism in run-time specialization
	   (answers A7)
	2. Fine-grained control over run-time specialization (answers A6-7)
		a. allows policies to be changed at arbitrary program
		   points and makes them flow-sensitive
		b. associates policies with variables, affecting how
		   each variable is treated by the analysis and later
		   transformations 


Invention
---------

I see our contribution as two-fold:

A. The concept and implementation of flow-sensitive policies governing
   run-time specialization (more broadly: other optimizations)
	1. Concept: fine-grained control
		a. Applied to every variable at each program point, or
		b. Applied to specific variable at each program point.
	2. Implementation: three components
		a. Way to set policies (annotations - minor aspect)
		b. Way to propagate policies (meet operators & DFA/BTA)
		c. Way to apply policies (in DFA/BTA and in later
		   phases, such as our run-time specializer)

		note: we need to characterize what types of policies
		can be flowed (definition of DFA may do this for us)

B. Our specific policies (categories and options)
    note: need to say why each is important to have control over
	1. monovariant vs. polyvariant specialization
	2. monovariant vs. polyvariant division
	3. manual vs. automatic promotion
	4. caching (e.g., infinite versions vs. one version, check
	   vs. no check)
	5. speculative vs. on-demand (we have identified a few points
	   on the spectrum)


Does it make sense to reorganize the patent around these two
contributions?  If so, the easiest (and therefore most likely) way to
do this is to summarize A, convert the last three paragraphs of the
current "Background" and all of "Invention" into B, and adapt
"Description and Operation" into a detailed description of A in terms
of B.  In "Broadening", we would then generalize A to other policies
and other optimizations.


Date: Wed, 10 Jun 1998 14:50:44 -0700
From: eggers@yakima (Susan Eggers)
To: spin-comp@cs
Subject: in 15 mintues

Tracy Halbert from OTT will be here in 15 minutes with forms for us
to sign.  Craig and I will sign here and then I'll send her to the
Chateau.

Susan

Date: Thu, 11 Jun 1998 09:13:31 -0700
From: eggers@yakima (Susan Eggers)
To: pljones@u.washington.edu, spin-comp@cs
Subject: conditional specialization patent

%!PS-Adobe-3.0
%%BoundingBox: (atend)
%%Pages: (atend)
%%PageOrder: (atend)
%%DocumentFonts: (atend)
%%Creator: Frame 4.0
%%DocumentData: Clean7Bit
%%EndComments
%%BeginProlog
%
% Frame ps_prolog 4.0, for use with Frame 4.0 products
% This ps_prolog file is Copyright (c) 1986-1993 Frame Technology
% Corporation.  All rights reserved.  This ps_prolog file may be
% freely copied and distributed in conjunction with documents created
% using FrameMaker, FrameBuilder and FrameViewer as long as this 
% copyright notice is preserved.
%
% Frame products normally print colors as their true color on a color printer
% or as shades of gray, based on luminance, on a black-and white printer. The
% following flag, if set to True, forces all non-white colors to print as pure
% black. This has no effect on bitmap images.
/FMPrintAllColorsAsBlack             false def
%
% Frame products can either set their own line screens or use a printer's 
% default settings. Three flags below control this separately for no 
% separations, spot separations and process separations. If a flag
% is true, then the default printer settings will not be changed. If it is
% false, Frame products will use their own settings from a table based on
% the printer's resolution.
/FMUseDefaultNoSeparationScreen      true  def
/FMUseDefaultSpotSeparationScreen    true  def
/FMUseDefaultProcessSeparationScreen false def
%
% For any given PostScript printer resolution, Frame products have two sets of 
% screen angles and frequencies for printing process separations, which are 
% recomended by Adobe. The following variable chooses the higher frequencies
% when set to true or the lower frequencies when set to false. This is only
% effective if the appropriate FMUseDefault...SeparationScreen flag is false.
/FMUseHighFrequencyScreens true def
%
% PostScript Level 2 printers contain an "Accurate Screens" feature which can
% improve process separation rendering at the expense of compute time. This 
% flag is ignored by PostScript Level 1 printers.
/FMUseAcccurateScreens true def
%
% The following PostScript procedure defines the spot function that Frame
% products will use for process separations. You may un-comment-out one of
% the alternative functions below, or use your own.
%
% Dot function
/FMSpotFunction {abs exch abs 2 copy add 1 gt 
		{1 sub dup mul exch 1 sub dup mul add 1 sub }
		{dup mul exch dup mul add 1 exch sub }ifelse } def
%
% Line function
% /FMSpotFunction { pop } def
%
% Elipse function
% /FMSpotFunction { dup 5 mul 8 div mul exch dup mul exch add 
%		sqrt 1 exch sub } def
%
%
/FMversion (4.0) def 
/FMLevel1 /languagelevel where {pop languagelevel} {1} ifelse 2 lt def
/FMPColor
	FMLevel1 {
		false
		/colorimage where {pop pop true} if
	} {
		true
	} ifelse
def
/FrameDict 400 dict def 
systemdict /errordict known not {/errordict 10 dict def
		errordict /rangecheck {stop} put} if
% The readline in PS 23.0 doesn't recognize cr's as nl's on AppleTalk
FrameDict /tmprangecheck errordict /rangecheck get put 
errordict /rangecheck {FrameDict /bug true put} put 
FrameDict /bug false put 
mark 
% Some PS machines read past the CR, so keep the following 3 lines together!
currentfile 5 string readline
00
0000000000
cleartomark 
errordict /rangecheck FrameDict /tmprangecheck get put 
FrameDict /bug get { 
	/readline {
		/gstring exch def
		/gfile exch def
		/gindex 0 def
		{
			gfile read pop 
			dup 10 eq {exit} if 
			dup 13 eq {exit} if 
			gstring exch gindex exch put 
			/gindex gindex 1 add def 
		} loop
		pop 
		gstring 0 gindex getinterval true 
		} bind def
	} if
/FMshowpage /showpage load def
/FMquit /quit load def
/FMFAILURE { 
	dup = flush 
	FMshowpage 
	/Helvetica findfont 12 scalefont setfont
	72 200 moveto
	show FMshowpage 
	FMquit 
	} def 
/FMVERSION {
	FMversion ne {
		(Frame product version does not match ps_prolog!) FMFAILURE
		} if
	} def 
/FMBADEPSF { 
	(PostScript Lang. Ref. Man., 2nd Ed., H.2.4 says EPS must not call X              )
	dup dup (X) search pop exch pop exch pop length 
	4 -1 roll 
	putinterval 
	FMFAILURE
	} def
/FMLOCAL {
	FrameDict begin
	0 def 
	end 
	} def 
/concatprocs
	{
	/proc2 exch cvlit def/proc1 exch cvlit def/newproc proc1 length proc2 length add array def
	newproc 0 proc1 putinterval newproc proc1 length proc2 putinterval newproc cvx
}def
FrameDict begin 
/FMnone 0 def
/FMcyan 1 def
/FMmagenta 2 def
/FMyellow 3 def
/FMblack 4 def
/FMcustom 5 def
/FrameNegative false def 
/FrameSepIs FMnone def 
/FrameSepBlack 0 def
/FrameSepYellow 0 def
/FrameSepMagenta 0 def
/FrameSepCyan 0 def
/FrameSepRed 1 def
/FrameSepGreen 1 def
/FrameSepBlue 1 def
/FrameCurGray 1 def
/FrameCurPat null def
/FrameCurColors [ 0 0 0 1 0 0 0 ] def 
/FrameColorEpsilon .001 def	
/eqepsilon {		
	sub dup 0 lt {neg} if
	FrameColorEpsilon le
} bind def
/FrameCmpColorsCMYK { 
	2 copy 0 get exch 0 get eqepsilon {
		2 copy 1 get exch 1 get eqepsilon {
			2 copy 2 get exch 2 get eqepsilon {
				3 get exch 3 get eqepsilon
			} {pop pop false} ifelse
		}{pop pop false} ifelse
	} {pop pop false} ifelse
} bind def
/FrameCmpColorsRGB { 
	2 copy 4 get exch 0 get eqepsilon {
		2 copy 5 get exch 1 get eqepsilon {
			6 get exch 2 get eqepsilon
		}{pop pop false} ifelse
	} {pop pop false} ifelse
} bind def
/RGBtoCMYK { 
	1 exch sub 
	3 1 roll 
	1 exch sub 
	3 1 roll 
	1 exch sub 
	3 1 roll 
	3 copy 
	2 copy 
	le { pop } { exch pop } ifelse 
	2 copy 
	le { pop } { exch pop } ifelse 
	dup dup dup 
	6 1 roll 
	4 1 roll 
	7 1 roll 
	sub 
	6 1 roll 
	sub 
	5 1 roll 
	sub 
	4 1 roll 
} bind def
/CMYKtoRGB { 
	dup dup 4 -1 roll add 						  
	5 1 roll 3 -1 roll add 						  
	4 1 roll add 								  
	1 exch sub dup 0 lt {pop 0} if 3 1 roll 	  
	1 exch sub dup 0 lt {pop 0} if exch 	      
	1 exch sub dup 0 lt {pop 0} if exch	  		  
} bind def
/FrameSepInit {
	1.0 RealSetgray
} bind def
/FrameSetSepColor { 
	/FrameSepBlue exch def
	/FrameSepGreen exch def
	/FrameSepRed exch def
	/FrameSepBlack exch def
	/FrameSepYellow exch def
	/FrameSepMagenta exch def
	/FrameSepCyan exch def
	/FrameSepIs FMcustom def
	setCurrentScreen	
} bind def
/FrameSetCyan {
	/FrameSepBlue 1.0 def
	/FrameSepGreen 1.0 def
	/FrameSepRed 0.0 def
	/FrameSepBlack 0.0 def
	/FrameSepYellow 0.0 def
	/FrameSepMagenta 0.0 def
	/FrameSepCyan 1.0 def
	/FrameSepIs FMcyan def
	setCurrentScreen	
} bind def
 
/FrameSetMagenta {
	/FrameSepBlue 1.0 def
	/FrameSepGreen 0.0 def
	/FrameSepRed 1.0 def
	/FrameSepBlack 0.0 def
	/FrameSepYellow 0.0 def
	/FrameSepMagenta 1.0 def
	/FrameSepCyan 0.0 def
	/FrameSepIs FMmagenta def
	setCurrentScreen
} bind def
 
/FrameSetYellow {
	/FrameSepBlue 0.0 def
	/FrameSepGreen 1.0 def
	/FrameSepRed 1.0 def
	/FrameSepBlack 0.0 def
	/FrameSepYellow 1.0 def
	/FrameSepMagenta 0.0 def
	/FrameSepCyan 0.0 def
	/FrameSepIs FMyellow def
	setCurrentScreen
} bind def
 
/FrameSetBlack {
	/FrameSepBlue 0.0 def
	/FrameSepGreen 0.0 def
	/FrameSepRed 0.0 def
	/FrameSepBlack 1.0 def
	/FrameSepYellow 0.0 def
	/FrameSepMagenta 0.0 def
	/FrameSepCyan 0.0 def
	/FrameSepIs FMblack def
	setCurrentScreen
} bind def
 
/FrameNoSep { 
	/FrameSepIs FMnone def
	setCurrentScreen
} bind def
/FrameSetSepColors { 
	FrameDict begin
	[ exch 1 add 1 roll ]
	/FrameSepColors  
	exch def end
	} bind def
/FrameColorInSepListCMYK { 
	FrameSepColors {  
       		exch dup 3 -1 roll 
       		FrameCmpColorsCMYK 
       		{ pop true exit } if
    	} forall 
	dup true ne {pop false} if
	} bind def
/FrameColorInSepListRGB { 
	FrameSepColors {  
       		exch dup 3 -1 roll 
       		FrameCmpColorsRGB 
       		{ pop true exit } if
    	} forall 
	dup true ne {pop false} if
	} bind def
/RealSetgray /setgray load def
/RealSetrgbcolor /setrgbcolor load def
/RealSethsbcolor /sethsbcolor load def
end 
/setgray { 
	FrameDict begin
	FrameSepIs FMnone eq
		{ RealSetgray } 
		{ 
		FrameSepIs FMblack eq 
			{ RealSetgray } 
			{ FrameSepIs FMcustom eq 
			  FrameSepRed 0 eq and
			  FrameSepGreen 0 eq and
			  FrameSepBlue 0 eq and {
			  	RealSetgray
			  } {
				1 RealSetgray pop 
			  } ifelse
			} ifelse
		} ifelse
	end
} bind def
/setrgbcolor { 
	FrameDict begin
	FrameSepIs FMnone eq
	{  RealSetrgbcolor }
	{
		3 copy [ 4 1 roll ] 
		FrameColorInSepListRGB
		{
				FrameSepBlue eq exch 
			 	FrameSepGreen eq and exch 
			 	FrameSepRed eq and
			 	{ 0 } { 1 } ifelse
		}
		{
			FMPColor {
				RealSetrgbcolor
				currentcmykcolor
			} {
				RGBtoCMYK
			} ifelse
			FrameSepIs FMblack eq
			{1.0 exch sub 4 1 roll pop pop pop} {
			FrameSepIs FMyellow eq
			{pop 1.0 exch sub 3 1 roll pop pop} {
			FrameSepIs FMmagenta eq
			{pop pop 1.0 exch sub exch pop } {
			FrameSepIs FMcyan eq
			{pop pop pop 1.0 exch sub } 
			{pop pop pop pop 1} ifelse } ifelse } ifelse } ifelse 
		} ifelse
		RealSetgray
	} 
	ifelse
	end
} bind def
/sethsbcolor {
	FrameDict begin
	FrameSepIs FMnone eq 
	{ RealSethsbcolor } 
	{
		RealSethsbcolor 
		currentrgbcolor  
		setrgbcolor 
	} 
	ifelse
	end
} bind def
FrameDict begin
/setcmykcolor where {
	pop /RealSetcmykcolor /setcmykcolor load def
} {
	/RealSetcmykcolor {
		4 1 roll
		3 { 3 index add 0 max 1 min 1 exch sub 3 1 roll} repeat 
		setrgbcolor pop
	} bind def
} ifelse
userdict /setcmykcolor { 
		FrameDict begin
		FrameSepIs FMnone eq
		{ RealSetcmykcolor } 
		{
			4 copy [ 5 1 roll ]
			FrameColorInSepListCMYK
			{
				FrameSepBlack eq exch 
				FrameSepYellow eq and exch 
				FrameSepMagenta eq and exch 
				FrameSepCyan eq and 
				{ 0 } { 1 } ifelse
			}
			{
				FrameSepIs FMblack eq
				{1.0 exch sub 4 1 roll pop pop pop} {
				FrameSepIs FMyellow eq
				{pop 1.0 exch sub 3 1 roll pop pop} {
				FrameSepIs FMmagenta eq
				{pop pop 1.0 exch sub exch pop } {
				FrameSepIs FMcyan eq
				{pop pop pop 1.0 exch sub } 
				{pop pop pop pop 1} ifelse } ifelse } ifelse } ifelse 
			} ifelse
			RealSetgray
		}
		ifelse
		end
	} bind put
FMLevel1 not { 
	
	/patProcDict 5 dict dup begin
		<0f1e3c78f0e1c387> { 3 setlinewidth -1 -1 moveto 9 9 lineto stroke 
											4 -4 moveto 12 4 lineto stroke
											-4 4 moveto 4 12 lineto stroke} bind def
		<0f87c3e1f0783c1e> { 3 setlinewidth -1 9 moveto 9 -1 lineto stroke 
											-4 4 moveto 4 -4 lineto stroke
											4 12 moveto 12 4 lineto stroke} bind def
		<8142241818244281> { 1 setlinewidth -1 9 moveto 9 -1 lineto stroke
											-1 -1 moveto 9 9 lineto stroke } bind def
		<03060c183060c081> { 1 setlinewidth -1 -1 moveto 9 9 lineto stroke 
											4 -4 moveto 12 4 lineto stroke
											-4 4 moveto 4 12 lineto stroke} bind def
		<8040201008040201> { 1 setlinewidth -1 9 moveto 9 -1 lineto stroke 
											-4 4 moveto 4 -4 lineto stroke
											4 12 moveto 12 4 lineto stroke} bind def
	end def
	/patDict 15 dict dup begin
		/PatternType 1 def		
		/PaintType 2 def		
		/TilingType 3 def		
		/BBox [ 0 0 8 8 ] def 	
		/XStep 8 def			
		/YStep 8 def			
		/PaintProc {
			begin
			patProcDict bstring known {
				patProcDict bstring get exec
			} {
				8 8 true [1 0 0 -1 0 8] bstring imagemask
			} ifelse
			end
		} bind def
	end def
} if
/combineColor {
    FrameSepIs FMnone eq
	{
		graymode FMLevel1 or not {
			
			[/Pattern [/DeviceCMYK]] setcolorspace
			FrameCurColors 0 4 getinterval aload pop FrameCurPat setcolor
		} {
			FrameCurColors 3 get 1.0 ge {
				FrameCurGray RealSetgray
			} {
				FMPColor graymode and {
					0 1 3 { 
						FrameCurColors exch get
						1 FrameCurGray sub mul
					} for
					RealSetcmykcolor
				} {
					4 1 6 {
						FrameCurColors exch get
						graymode {
							1 exch sub 1 FrameCurGray sub mul 1 exch sub
						} {
							1.0 lt {FrameCurGray} {1} ifelse
						} ifelse
					} for
					RealSetrgbcolor
				} ifelse
			} ifelse
		} ifelse
	} { 
		FrameCurColors 0 4 getinterval aload
		FrameColorInSepListCMYK {
			FrameSepBlack eq exch 
			FrameSepYellow eq and exch 
			FrameSepMagenta eq and exch 
			FrameSepCyan eq and
			FrameSepIs FMcustom eq and
			{ FrameCurGray } { 1 } ifelse
		} {
			FrameSepIs FMblack eq
			{FrameCurGray 1.0 exch sub mul 1.0 exch sub 4 1 roll pop pop pop} {
			FrameSepIs FMyellow eq
			{pop FrameCurGray 1.0 exch sub mul 1.0 exch sub 3 1 roll pop pop} {
			FrameSepIs FMmagenta eq
			{pop pop FrameCurGray 1.0 exch sub mul 1.0 exch sub exch pop } {
			FrameSepIs FMcyan eq
			{pop pop pop FrameCurGray 1.0 exch sub mul 1.0 exch sub } 
			{pop pop pop pop 1} ifelse } ifelse } ifelse } ifelse 
		} ifelse
		graymode FMLevel1 or not {
			
			[/Pattern [/DeviceGray]] setcolorspace
			FrameCurPat setcolor
		} { 
			graymode not FMLevel1 and {
				
				dup 1 lt {pop FrameCurGray} if
			} if
			RealSetgray
		} ifelse
	} ifelse
} bind def
/savematrix {
	orgmatrix currentmatrix pop
	} bind def
/restorematrix {
	orgmatrix setmatrix
	} bind def
/dmatrix matrix def
/dpi    72 0 dmatrix defaultmatrix dtransform
    dup mul exch   dup mul add   sqrt def
	
/freq dpi dup 72 div round dup 0 eq {pop 1} if 8 mul div def
/sangle 1 0 dmatrix defaultmatrix dtransform exch atan def
/dpiranges   [  2540    2400    1693     1270    1200     635      600      0      ] def
/CMLowFreqs  [ 100.402  94.8683 89.2289 100.402  94.8683  66.9349  63.2456 47.4342 ] def
/YLowFreqs   [  95.25   90.0    84.65    95.25   90.0     70.5556  66.6667 50.0    ] def
/KLowFreqs   [  89.8026 84.8528 79.8088  89.8026 84.8528  74.8355  70.7107 53.033  ] def
/CLowAngles  [  71.5651 71.5651 71.5651 71.5651  71.5651  71.5651  71.5651 71.5651 ] def
/MLowAngles  [  18.4349 18.4349 18.4349 18.4349  18.4349  18.4349  18.4349 18.4349 ] def
/YLowTDot    [  true    true    false    true    true     false    false   false   ] def
/CMHighFreqs [ 133.87  126.491 133.843  108.503 102.523  100.402   94.8683 63.2456 ] def
/YHighFreqs  [ 127.0   120.0   126.975  115.455 109.091   95.25    90.0    60.0    ] def
/KHighFreqs  [ 119.737 113.137 119.713  128.289 121.218   89.8026  84.8528 63.6395 ] def
/CHighAngles [  71.5651 71.5651 71.5651  70.0169 70.0169  71.5651  71.5651 71.5651 ] def
/MHighAngles [  18.4349 18.4349 18.4349  19.9831 19.9831  18.4349  18.4349 18.4349 ] def
/YHighTDot   [  false   false   true     false   false    true     true    false   ] def
/PatFreq     [	10.5833 10.0     9.4055  10.5833 10.0	  10.5833  10.0	   9.375   ] def
/screenIndex {
	0 1 dpiranges length 1 sub { dup dpiranges exch get 1 sub dpi le {exit} {pop} ifelse } for
} bind def
/getCyanScreen {
	FMUseHighFrequencyScreens { CHighAngles CMHighFreqs} {CLowAngles CMLowFreqs} ifelse
		screenIndex dup 3 1 roll get 3 1 roll get /FMSpotFunction load
} bind def
/getMagentaScreen {
	FMUseHighFrequencyScreens { MHighAngles CMHighFreqs } {MLowAngles CMLowFreqs} ifelse
		screenIndex dup 3 1 roll get 3 1 roll get /FMSpotFunction load
} bind def
/getYellowScreen {
	FMUseHighFrequencyScreens { YHighTDot YHighFreqs} { YLowTDot YLowFreqs } ifelse
		screenIndex dup 3 1 roll get 3 1 roll get { 3 div
			{2 { 1 add 2 div 3 mul dup floor sub 2 mul 1 sub exch} repeat
			FMSpotFunction } } {/FMSpotFunction load } ifelse
			0.0 exch
} bind def
/getBlackScreen  {
	FMUseHighFrequencyScreens { KHighFreqs } { KLowFreqs } ifelse
		screenIndex get 45.0 /FMSpotFunction load 
} bind def
/getSpotScreen {
	getBlackScreen
} bind def
/getCompositeScreen {
	getBlackScreen
} bind def
/FMSetScreen 
	FMLevel1 { /setscreen load 
	}{ {
		8 dict begin
		/HalftoneType 1 def
		/SpotFunction exch def
		/Angle exch def
		/Frequency exch def
		/AccurateScreens FMUseAcccurateScreens def
		currentdict end sethalftone
	} bind } ifelse
def
/setDefaultScreen {
	FMPColor {
		orgrxfer cvx orggxfer cvx orgbxfer cvx orgxfer cvx setcolortransfer
	}
	{
		orgxfer cvx settransfer
	} ifelse
	orgfreq organgle orgproc cvx setscreen
} bind def
/setCurrentScreen {
	FrameSepIs FMnone eq {
		FMUseDefaultNoSeparationScreen {
			setDefaultScreen
		} {
			getCompositeScreen FMSetScreen
		} ifelse
	} {
		FrameSepIs FMcustom eq {
			FMUseDefaultSpotSeparationScreen {
				setDefaultScreen
			} {
				getSpotScreen FMSetScreen
			} ifelse
		} {
			FMUseDefaultProcessSeparationScreen {
				setDefaultScreen
			} {
				FrameSepIs FMcyan eq {
					getCyanScreen FMSetScreen
				} {
					FrameSepIs FMmagenta eq {
						getMagentaScreen FMSetScreen
					} {
						FrameSepIs FMyellow eq {
							getYellowScreen FMSetScreen
						} {
							getBlackScreen FMSetScreen
						} ifelse
					} ifelse
				} ifelse
			} ifelse
		} ifelse
	} ifelse 
} bind def
end
	/gstring FMLOCAL
	/gfile FMLOCAL
	/gindex FMLOCAL
	/orgrxfer FMLOCAL
	/orggxfer FMLOCAL
	/orgbxfer FMLOCAL
	/orgxfer FMLOCAL
	/orgproc FMLOCAL
	/orgrproc FMLOCAL
	/orggproc FMLOCAL
	/orgbproc FMLOCAL
	/organgle FMLOCAL
	/orgrangle FMLOCAL
	/orggangle FMLOCAL
	/orgbangle FMLOCAL
	/orgfreq FMLOCAL
	/orgrfreq FMLOCAL
	/orggfreq FMLOCAL
	/orgbfreq FMLOCAL
	/yscale FMLOCAL
	/xscale FMLOCAL
	/edown FMLOCAL
	/manualfeed FMLOCAL
	/paperheight FMLOCAL
	/paperwidth FMLOCAL
/FMDOCUMENT { 
	array /FMfonts exch def 
	/#copies exch def
	FrameDict begin
	0 ne /manualfeed exch def
	/paperheight exch def
	/paperwidth exch def
	0 ne /FrameNegative exch def 
	0 ne /edown exch def 
	/yscale exch def
	/xscale exch def
	FMLevel1 {
		manualfeed {setmanualfeed} if
		/FMdicttop countdictstack 1 add def 
		/FMoptop count def 
		setpapername 
		manualfeed {true} {papersize} ifelse 
		{manualpapersize} {false} ifelse 
		{desperatepapersize} {false} ifelse 
		{ (Can't select requested paper size for Frame print job!) FMFAILURE } if
		count -1 FMoptop {pop pop} for
		countdictstack -1 FMdicttop {pop end} for 
		}
		{{1 dict dup /PageSize [paperwidth paperheight]put setpagedevice}stopped
		{ (Can't select requested paper size for Frame print job!) FMFAILURE } if
		 {1 dict dup /ManualFeed manualfeed put setpagedevice } stopped pop }
	ifelse 
	
	FMPColor {
		currentcolorscreen
			cvlit /orgproc exch def
				  /organgle exch def 
				  /orgfreq exch def
			cvlit /orgbproc exch def
				  /orgbangle exch def 
				  /orgbfreq exch def
			cvlit /orggproc exch def
				  /orggangle exch def 
				  /orggfreq exch def
			cvlit /orgrproc exch def
				  /orgrangle exch def 
				  /orgrfreq exch def
			currentcolortransfer 
			FrameNegative {
				1 1 4 { 
					pop { 1 exch sub } concatprocs 4 1 roll
				} for
				4 copy
				setcolortransfer
			} if
			cvlit /orgxfer exch def
			cvlit /orgbxfer exch def
			cvlit /orggxfer exch def
			cvlit /orgrxfer exch def
	} {
		currentscreen 
			cvlit /orgproc exch def
				  /organgle exch def 
				  /orgfreq exch def
				  
		currenttransfer 
		FrameNegative {
			{ 1 exch sub } concatprocs
			dup settransfer
		} if 
		cvlit /orgxfer exch def
	} ifelse
	end 
} def 
/pagesave FMLOCAL
/orgmatrix FMLOCAL
/landscape FMLOCAL
/pwid FMLOCAL
/FMBEGINPAGE { 
	FrameDict begin 
	/pagesave save def
	3.86 setmiterlimit
	/landscape exch 0 ne def
	landscape { 
		90 rotate 0 exch dup /pwid exch def neg translate pop 
	}{
		pop /pwid exch def
	} ifelse
	edown { [-1 0 0 1 pwid 0] concat } if
	0 0 moveto paperwidth 0 lineto paperwidth paperheight lineto 
	0 paperheight lineto 0 0 lineto 1 setgray fill
	xscale yscale scale
	/orgmatrix matrix def
	gsave 
} def 
/FMENDPAGE {
	grestore 
	pagesave restore
	end 
	showpage
	} def 
/FMFONTDEFINE { 
	FrameDict begin
	findfont 
	ReEncode 
	1 index exch 
	definefont 
	FMfonts 3 1 roll 
	put
	end 
	} def 
/FMFILLS {
	FrameDict begin dup
	array /fillvals exch def
	dict /patCache exch def
	end 
	} def 
/FMFILL {
	FrameDict begin
	 fillvals 3 1 roll put
	end 
	} def 
/FMNORMALIZEGRAPHICS { 
	newpath
	0.0 0.0 moveto
	1 setlinewidth
	0 setlinecap
	0 0 0 sethsbcolor
	0 setgray 
	} bind def
	/fx FMLOCAL
	/fy FMLOCAL
	/fh FMLOCAL
	/fw FMLOCAL
	/llx FMLOCAL
	/lly FMLOCAL
	/urx FMLOCAL
	/ury FMLOCAL
/FMBEGINEPSF { 
	end 
	/FMEPSF save def 
	/showpage {} def 
% See Adobe's "PostScript Language Reference Manual, 2nd Edition", page 714.
% "...the following operators MUST NOT be used in an EPS file:" (emphasis ours)
	/banddevice {(banddevice) FMBADEPSF} def
	/clear {(clear) FMBADEPSF} def
	/cleardictstack {(cleardictstack) FMBADEPSF} def 
	/copypage {(copypage) FMBADEPSF} def
	/erasepage {(erasepage) FMBADEPSF} def
	/exitserver {(exitserver) FMBADEPSF} def
	/framedevice {(framedevice) FMBADEPSF} def
	/grestoreall {(grestoreall) FMBADEPSF} def
	/initclip {(initclip) FMBADEPSF} def
	/initgraphics {(initgraphics) FMBADEPSF} def
	/initmatrix {(initmatrix) FMBADEPSF} def
	/quit {(quit) FMBADEPSF} def
	/renderbands {(renderbands) FMBADEPSF} def
	/setglobal {(setglobal) FMBADEPSF} def
	/setpagedevice {(setpagedevice) FMBADEPSF} def
	/setshared {(setshared) FMBADEPSF} def
	/startjob {(startjob) FMBADEPSF} def
	/lettertray {(lettertray) FMBADEPSF} def
	/letter {(letter) FMBADEPSF} def
	/lettersmall {(lettersmall) FMBADEPSF} def
	/11x17tray {(11x17tray) FMBADEPSF} def
	/11x17 {(11x17) FMBADEPSF} def
	/ledgertray {(ledgertray) FMBADEPSF} def
	/ledger {(ledger) FMBADEPSF} def
	/legaltray {(legaltray) FMBADEPSF} def
	/legal {(legal) FMBADEPSF} def
	/statementtray {(statementtray) FMBADEPSF} def
	/statement {(statement) FMBADEPSF} def
	/executivetray {(executivetray) FMBADEPSF} def
	/executive {(executive) FMBADEPSF} def
	/a3tray {(a3tray) FMBADEPSF} def
	/a3 {(a3) FMBADEPSF} def
	/a4tray {(a4tray) FMBADEPSF} def
	/a4 {(a4) FMBADEPSF} def
	/a4small {(a4small) FMBADEPSF} def
	/b4tray {(b4tray) FMBADEPSF} def
	/b4 {(b4) FMBADEPSF} def
	/b5tray {(b5tray) FMBADEPSF} def
	/b5 {(b5) FMBADEPSF} def
	FMNORMALIZEGRAPHICS 
	[/fy /fx /fh /fw /ury /urx /lly /llx] {exch def} forall 
	fx fw 2 div add fy fh 2 div add  translate
	rotate
	fw 2 div neg fh 2 div neg translate
	fw urx llx sub div fh ury lly sub div scale 
	llx neg lly neg translate 
	/FMdicttop countdictstack 1 add def 
	/FMoptop count def 
	} bind def
/FMENDEPSF {
	count -1 FMoptop {pop pop} for 
	countdictstack -1 FMdicttop {pop end} for 
	FMEPSF restore
	FrameDict begin 
	} bind def
FrameDict begin 
/setmanualfeed {
%%BeginFeature *ManualFeed True
	 statusdict /manualfeed true put
%%EndFeature
	} bind def
/max {2 copy lt {exch} if pop} bind def
/min {2 copy gt {exch} if pop} bind def
/inch {72 mul} def
/pagedimen { 
	paperheight sub abs 16 lt exch 
	paperwidth sub abs 16 lt and
	{/papername exch def} {pop} ifelse
	} bind def
	/papersizedict FMLOCAL
/setpapername { 
	/papersizedict 14 dict def 
	papersizedict begin
	/papername /unknown def 
		/Letter 8.5 inch 11.0 inch pagedimen
		/LetterSmall 7.68 inch 10.16 inch pagedimen
		/Tabloid 11.0 inch 17.0 inch pagedimen
		/Ledger 17.0 inch 11.0 inch pagedimen
		/Legal 8.5 inch 14.0 inch pagedimen
		/Statement 5.5 inch 8.5 inch pagedimen
		/Executive 7.5 inch 10.0 inch pagedimen
		/A3 11.69 inch 16.5 inch pagedimen
		/A4 8.26 inch 11.69 inch pagedimen
		/A4Small 7.47 inch 10.85 inch pagedimen
		/B4 10.125 inch 14.33 inch pagedimen
		/B5 7.16 inch 10.125 inch pagedimen
	end
	} bind def
/papersize {
	papersizedict begin
		/Letter {lettertray letter} def
		/LetterSmall {lettertray lettersmall} def
		/Tabloid {11x17tray 11x17} def
		/Ledger {ledgertray ledger} def
		/Legal {legaltray legal} def
		/Statement {statementtray statement} def
		/Executive {executivetray executive} def
		/A3 {a3tray a3} def
		/A4 {a4tray a4} def
		/A4Small {a4tray a4small} def
		/B4 {b4tray b4} def
		/B5 {b5tray b5} def
		/unknown {unknown} def
	papersizedict dup papername known {papername} {/unknown} ifelse get
	end
	statusdict begin stopped end 
	} bind def
/manualpapersize {
	papersizedict begin
		/Letter {letter} def
		/LetterSmall {lettersmall} def
		/Tabloid {11x17} def
		/Ledger {ledger} def
		/Legal {legal} def
		/Statement {statement} def
		/Executive {executive} def
		/A3 {a3} def
		/A4 {a4} def
		/A4Small {a4small} def
		/B4 {b4} def
		/B5 {b5} def
		/unknown {unknown} def
	papersizedict dup papername known {papername} {/unknown} ifelse get
	end
	stopped 
	} bind def
/desperatepapersize {
	statusdict /setpageparams known
		{
		paperwidth paperheight 0 1 
		statusdict begin
		{setpageparams} stopped 
		end
		} {true} ifelse 
	} bind def
/DiacriticEncoding [
/.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef
/.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef
/.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef
/.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef
/.notdef /.notdef /.notdef /.notdef /space /exclam /quotedbl
/numbersign /dollar /percent /ampersand /quotesingle /parenleft
/parenright /asterisk /plus /comma /hyphen /period /slash /zero /one
/two /three /four /five /six /seven /eight /nine /colon /semicolon
/less /equal /greater /question /at /A /B /C /D /E /F /G /H /I /J /K
/L /M /N /O /P /Q /R /S /T /U /V /W /X /Y /Z /bracketleft /backslash
/bracketright /asciicircum /underscore /grave /a /b /c /d /e /f /g /h
/i /j /k /l /m /n /o /p /q /r /s /t /u /v /w /x /y /z /braceleft /bar
/braceright /asciitilde /.notdef /Adieresis /Aring /Ccedilla /Eacute
/Ntilde /Odieresis /Udieresis /aacute /agrave /acircumflex /adieresis
/atilde /aring /ccedilla /eacute /egrave /ecircumflex /edieresis
/iacute /igrave /icircumflex /idieresis /ntilde /oacute /ograve
/ocircumflex /odieresis /otilde /uacute /ugrave /ucircumflex
/udieresis /dagger /.notdef /cent /sterling /section /bullet
/paragraph /germandbls /registered /copyright /trademark /acute
/dieresis /.notdef /AE /Oslash /.notdef /.notdef /.notdef /.notdef
/yen /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef
/ordfeminine /ordmasculine /.notdef /ae /oslash /questiondown
/exclamdown /logicalnot /.notdef /florin /.notdef /.notdef
/guillemotleft /guillemotright /ellipsis /.notdef /Agrave /Atilde
/Otilde /OE /oe /endash /emdash /quotedblleft /quotedblright
/quoteleft /quoteright /.notdef /.notdef /ydieresis /Ydieresis
/fraction /currency /guilsinglleft /guilsinglright /fi /fl /daggerdbl
/periodcentered /quotesinglbase /quotedblbase /perthousand
/Acircumflex /Ecircumflex /Aacute /Edieresis /Egrave /Iacute
/Icircumflex /Idieresis /Igrave /Oacute /Ocircumflex /.notdef /Ograve
/Uacute /Ucircumflex /Ugrave /dotlessi /circumflex /tilde /macron
/breve /dotaccent /ring /cedilla /hungarumlaut /ogonek /caron
] def
/ReEncode { 
	dup 
	length 
	dict begin 
	{
	1 index /FID ne 
		{def} 
		{pop pop} ifelse 
	} forall 
	0 eq {/Encoding DiacriticEncoding def} if 
	currentdict 
	end 
	} bind def
FMPColor 
	
	{
	/BEGINBITMAPCOLOR { 
		BITMAPCOLOR} def
	/BEGINBITMAPCOLORc { 
		BITMAPCOLORc} def
	/BEGINBITMAPTRUECOLOR { 
		BITMAPTRUECOLOR } def
	/BEGINBITMAPTRUECOLORc { 
		BITMAPTRUECOLORc } def
	}
	
	{
	/BEGINBITMAPCOLOR { 
		BITMAPGRAY} def
	/BEGINBITMAPCOLORc { 
		BITMAPGRAYc} def
	/BEGINBITMAPTRUECOLOR { 
		BITMAPTRUEGRAY } def
	/BEGINBITMAPTRUECOLORc { 
		BITMAPTRUEGRAYc } def
	}
ifelse
/K { 
	FMPrintAllColorsAsBlack {
		dup 1 eq 2 index 1 eq and 3 index 1 eq and not
			{7 {pop} repeat 0 0 0 1 0 0 0} if
	} if 
	FrameCurColors astore 
	pop combineColor
} bind def
/graymode true def
	/bwidth FMLOCAL
	/bpside FMLOCAL
	/bstring FMLOCAL
	/onbits FMLOCAL
	/offbits FMLOCAL
	/xindex FMLOCAL
	/yindex FMLOCAL
	/x FMLOCAL
	/y FMLOCAL
/setPatternMode {
	FMLevel1 {
		/bwidth  exch def
		/bpside  exch def
		/bstring exch def
		/onbits 0 def  /offbits 0 def
		freq sangle landscape {90 add} if 
			{/y exch def
			 /x exch def
			 /xindex x 1 add 2 div bpside mul cvi def
			 /yindex y 1 add 2 div bpside mul cvi def
			 bstring yindex bwidth mul xindex 8 idiv add get
			 1 7 xindex 8 mod sub bitshift and 0 ne FrameNegative {not} if
			 {/onbits  onbits  1 add def 1}
			 {/offbits offbits 1 add def 0}
			 ifelse
			}
			setscreen
		offbits offbits onbits add div FrameNegative {1.0 exch sub} if
		/FrameCurGray exch def
	} { 
		pop pop
		dup patCache exch known {
			patCache exch get
		} { 
			dup
			patDict /bstring 3 -1 roll put
			patDict 
			9 PatFreq screenIndex get div dup matrix scale
			makepattern
			dup 
			patCache 4 -1 roll 3 -1 roll put
		} ifelse
		/FrameCurGray 0 def
		/FrameCurPat exch def
	} ifelse
	/graymode false def
	combineColor
} bind def
/setGrayScaleMode {
	graymode not {
		/graymode true def
		FMLevel1 {
			setCurrentScreen
		} if
	} if
	/FrameCurGray exch def
	combineColor
} bind def
/normalize {
	transform round exch round exch itransform
	} bind def
/dnormalize {
	dtransform round exch round exch idtransform
	} bind def
/lnormalize { 
	0 dtransform exch cvi 2 idiv 2 mul 1 add exch idtransform pop
	} bind def
/H { 
	lnormalize setlinewidth
	} bind def
/Z {
	setlinecap
	} bind def
	
/PFill {
	graymode FMLevel1 or not {
		gsave 1 setgray eofill grestore
	} if
} bind def
/PStroke {
	graymode FMLevel1 or not {
		gsave 1 setgray stroke grestore
	} if
	stroke
} bind def
	/fillvals FMLOCAL
/X { 
	fillvals exch get
	dup type /stringtype eq
	{8 1 setPatternMode} 
	{setGrayScaleMode}
	ifelse
	} bind def
/V { 
	PFill gsave eofill grestore
	} bind def
/Vclip {
	clip
	} bind def
/Vstrk {
	currentlinewidth exch setlinewidth PStroke setlinewidth
	} bind def
/N { 
	PStroke
	} bind def
/Nclip {
	strokepath clip newpath
	} bind def
/Nstrk {
	currentlinewidth exch setlinewidth PStroke setlinewidth
	} bind def
/M {newpath moveto} bind def
/E {lineto} bind def
/D {curveto} bind def
/O {closepath} bind def
	/n FMLOCAL
/L { 
 	/n exch def
	newpath
	normalize
	moveto 
	2 1 n {pop normalize lineto} for
	} bind def
/Y { 
	L 
	closepath
	} bind def
	/x1 FMLOCAL
	/x2 FMLOCAL
	/y1 FMLOCAL
	/y2 FMLOCAL
/R { 
	/y2 exch def
	/x2 exch def
	/y1 exch def
	/x1 exch def
	x1 y1
	x2 y1
	x2 y2
	x1 y2
	4 Y 
	} bind def
	/rad FMLOCAL
/rarc 
	{rad 
	 arcto
	} bind def
/RR { 
	/rad exch def
	normalize
	/y2 exch def
	/x2 exch def
	normalize
	/y1 exch def
	/x1 exch def
	mark
	newpath
	{
	x1 y1 rad add moveto
	x1 y2 x2 y2 rarc
	x2 y2 x2 y1 rarc
	x2 y1 x1 y1 rarc
	x1 y1 x1 y2 rarc
	closepath
	} stopped {x1 y1 x2 y2 R} if 
	cleartomark
	} bind def
/RRR { 
	/rad exch def
	normalize /y4 exch def /x4 exch def
	normalize /y3 exch def /x3 exch def
	normalize /y2 exch def /x2 exch def
	normalize /y1 exch def /x1 exch def
	newpath
	normalize moveto 
	mark
	{
	x2 y2 x3 y3 rarc
	x3 y3 x4 y4 rarc
	x4 y4 x1 y1 rarc
	x1 y1 x2 y2 rarc
	closepath
	} stopped
	 {x1 y1 x2 y2 x3 y3 x4 y4 newpath moveto lineto lineto lineto closepath} if
	cleartomark
	} bind def
/C { 
	grestore
	gsave
	R 
	clip
	setCurrentScreen
} bind def
/CP { 
	grestore
	gsave
	Y 
	clip
	setCurrentScreen
} bind def
	/FMpointsize FMLOCAL
/F { 
	FMfonts exch get
	FMpointsize scalefont
	setfont
	} bind def
/Q { 
	/FMpointsize exch def
	F 
	} bind def
/T { 
	moveto show
	} bind def
/RF { 
	rotate
	0 ne {-1 1 scale} if
	} bind def
/TF { 
	gsave
	moveto 
	RF
	show
	grestore
	} bind def
/P { 
	moveto
	0 32 3 2 roll widthshow
	} bind def
/PF { 
	gsave
	moveto 
	RF
	0 32 3 2 roll widthshow
	grestore
	} bind def
/S { 
	moveto
	0 exch ashow
	} bind def
/SF { 
	gsave
	moveto
	RF
	0 exch ashow
	grestore
	} bind def
/B { 
	moveto
	0 32 4 2 roll 0 exch awidthshow
	} bind def
/BF { 
	gsave
	moveto
	RF
	0 32 4 2 roll 0 exch awidthshow
	grestore
	} bind def
/G { 
	gsave
	newpath
	normalize translate 0.0 0.0 moveto 
	dnormalize scale 
	0.0 0.0 1.0 5 3 roll arc 
	closepath 
	PFill fill
	grestore
	} bind def
/Gstrk {
	savematrix
    newpath
    2 index 2 div add exch 3 index 2 div sub exch 
    normalize 2 index 2 div sub exch 3 index 2 div add exch 
    translate
    scale 
    0.0 0.0 1.0 5 3 roll arc 
    restorematrix
    currentlinewidth exch setlinewidth PStroke setlinewidth
    } bind def
/Gclip { 
	newpath
	savematrix
	normalize translate 0.0 0.0 moveto 
	dnormalize scale 
	0.0 0.0 1.0 5 3 roll arc 
	closepath 
	clip newpath
	restorematrix
	} bind def
/GG { 
	gsave
	newpath
	normalize translate 0.0 0.0 moveto 
	rotate 
	dnormalize scale 
	0.0 0.0 1.0 5 3 roll arc 
	closepath
	PFill
	fill
	grestore
	} bind def
/GGclip { 
	savematrix
	newpath
    normalize translate 0.0 0.0 moveto 
    rotate 
    dnormalize scale 
    0.0 0.0 1.0 5 3 roll arc 
    closepath
	clip newpath
	restorematrix
	} bind def
/GGstrk { 
	savematrix
    newpath
    normalize translate 0.0 0.0 moveto 
    rotate 
    dnormalize scale 
    0.0 0.0 1.0 5 3 roll arc 
    closepath 
	restorematrix
    currentlinewidth exch setlinewidth PStroke setlinewidth
	} bind def
/A { 
	gsave
	savematrix
	newpath
	2 index 2 div add exch 3 index 2 div sub exch 
	normalize 2 index 2 div sub exch 3 index 2 div add exch 
	translate 
	scale 
	0.0 0.0 1.0 5 3 roll arc 
	restorematrix
	PStroke
	grestore
	} bind def
/Aclip {
	newpath
	savematrix
	normalize translate 0.0 0.0 moveto 
	dnormalize scale 
	0.0 0.0 1.0 5 3 roll arc 
	closepath 
	strokepath clip newpath
	restorematrix
} bind def
/Astrk {
	Gstrk
} bind def
/AA { 
	gsave
	savematrix
	newpath
	
	3 index 2 div add exch 4 index 2 div sub exch 
	
	normalize 3 index 2 div sub exch 4 index 2 div add exch
	translate 
	rotate 
	scale 
	0.0 0.0 1.0 5 3 roll arc 
	restorematrix
	PStroke
	grestore
	} bind def
/AAclip {
	savematrix
	newpath
    normalize translate 0.0 0.0 moveto 
    rotate 
    dnormalize scale 
    0.0 0.0 1.0 5 3 roll arc 
    closepath
	strokepath clip newpath
	restorematrix
} bind def
/AAstrk {
	GGstrk
} bind def
	/x FMLOCAL
	/y FMLOCAL
	/w FMLOCAL
	/h FMLOCAL
	/xx FMLOCAL
	/yy FMLOCAL
	/ww FMLOCAL
	/hh FMLOCAL
	/FMsaveobject FMLOCAL
	/FMoptop FMLOCAL
	/FMdicttop FMLOCAL
/BEGINPRINTCODE { 
	/FMdicttop countdictstack 1 add def 
	/FMoptop count 7 sub def 
	/FMsaveobject save def
	userdict begin 
	/showpage {} def 
	FMNORMALIZEGRAPHICS 
	3 index neg 3 index neg translate
	} bind def
/ENDPRINTCODE {
	count -1 FMoptop {pop pop} for 
	countdictstack -1 FMdicttop {pop end} for 
	FMsaveobject restore 
	} bind def
/gn { 
	0 
	{	46 mul 
		cf read pop 
		32 sub 
		dup 46 lt {exit} if 
		46 sub add 
		} loop
	add 
	} bind def
	/str FMLOCAL
/cfs { 
	/str sl string def 
	0 1 sl 1 sub {str exch val put} for 
	str def 
	} bind def
/ic [ 
	0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0223
	0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0223
	0
	{0 hx} {1 hx} {2 hx} {3 hx} {4 hx} {5 hx} {6 hx} {7 hx} {8 hx} {9 hx}
	{10 hx} {11 hx} {12 hx} {13 hx} {14 hx} {15 hx} {16 hx} {17 hx} {18 hx}
	{19 hx} {gn hx} {0} {1} {2} {3} {4} {5} {6} {7} {8} {9} {10} {11} {12}
	{13} {14} {15} {16} {17} {18} {19} {gn} {0 wh} {1 wh} {2 wh} {3 wh}
	{4 wh} {5 wh} {6 wh} {7 wh} {8 wh} {9 wh} {10 wh} {11 wh} {12 wh}
	{13 wh} {14 wh} {gn wh} {0 bl} {1 bl} {2 bl} {3 bl} {4 bl} {5 bl} {6 bl}
	{7 bl} {8 bl} {9 bl} {10 bl} {11 bl} {12 bl} {13 bl} {14 bl} {gn bl}
	{0 fl} {1 fl} {2 fl} {3 fl} {4 fl} {5 fl} {6 fl} {7 fl} {8 fl} {9 fl}
	{10 fl} {11 fl} {12 fl} {13 fl} {14 fl} {gn fl}
	] def
	/sl FMLOCAL
	/val FMLOCAL
	/ws FMLOCAL
	/im FMLOCAL
	/bs FMLOCAL
	/cs FMLOCAL
	/len FMLOCAL
	/pos FMLOCAL
/ms { 
	/sl exch def 
	/val 255 def 
	/ws cfs 
	/im cfs 
	/val 0 def 
	/bs cfs 
	/cs cfs 
	} bind def
400 ms 
/ip { 
	is 
	0 
	cf cs readline pop 
	{	ic exch get exec 
		add 
		} forall 
	pop 
	
	} bind def
/rip { 
	   
	  
	  bis ris copy pop 
      is
      0
      cf cs readline pop 
      {       ic exch get exec 
              add 
              } forall 
	  pop pop 
	  ris gis copy pop 
	  dup is exch 
	  
      cf cs readline pop 
      {       ic exch get exec 
              add 
              } forall 
	  pop pop
	  gis bis copy pop 
	  dup add is exch 
	  
      cf cs readline pop 
      {       ic exch get exec 
              add 
              } forall 
      pop 
      
      } bind def
/wh { 
	/len exch def 
	/pos exch def 
	ws 0 len getinterval im pos len getinterval copy pop
	pos len 
	} bind def
/bl { 
	/len exch def 
	/pos exch def 
	bs 0 len getinterval im pos len getinterval copy pop
	pos len 
	} bind def
/s1 1 string def
/fl { 
	/len exch def 
	/pos exch def 
	/val cf s1 readhexstring pop 0 get def
	pos 1 pos len add 1 sub {im exch val put} for
	pos len 
	} bind def
/hx { 
	3 copy getinterval 
	cf exch readhexstring pop pop 
	} bind def
	/h FMLOCAL
	/w FMLOCAL
	/d FMLOCAL
	/lb FMLOCAL
	/bitmapsave FMLOCAL
	/is FMLOCAL
	/cf FMLOCAL
/wbytes { 
      dup dup
      24 eq { pop pop 3 mul }
      { 8 eq {pop} {1 eq {7 add 8 idiv} {3 add 4 idiv} ifelse} ifelse } ifelse
	} bind def
/BEGINBITMAPBWc { 
	1 {} COMMONBITMAPc
	} bind def
/BEGINBITMAPGRAYc { 
	8 {} COMMONBITMAPc
	} bind def
/BEGINBITMAP2BITc { 
	2 {} COMMONBITMAPc
	} bind def
/COMMONBITMAPc { 
		 
	/r exch def
	/d exch def
	gsave
	
	3 index 2 div add exch	
	4 index 2 div add exch	
	translate		
	rotate			
	1 index 2 div neg	
	1 index 2 div neg	
	translate		
	scale			
	/h exch def /w exch def
	/lb w d wbytes def 
	sl lb lt {lb ms} if 
	/bitmapsave save def 
	r                    
	/is im 0 lb getinterval def 
	ws 0 lb getinterval is copy pop 
	/cf currentfile def 
	w h d [w 0 0 h neg 0 h] 
	{ip} image 
	bitmapsave restore 
	grestore
	} bind def
/BEGINBITMAPBW { 
	1 {} COMMONBITMAP
	} bind def
/BEGINBITMAPGRAY { 
	8 {} COMMONBITMAP
	} bind def
/BEGINBITMAP2BIT { 
	2 {} COMMONBITMAP
	} bind def
/COMMONBITMAP { 
	/r exch def
	/d exch def
	gsave
	
	3 index 2 div add exch	
	4 index 2 div add exch	
	translate		
	rotate			
	1 index 2 div neg	
	1 index 2 div neg	
	translate		
	scale			
	/h exch def /w exch def
	/bitmapsave save def 
	r                    
	/is w d wbytes string def
	/cf currentfile def 
	w h d [w 0 0 h neg 0 h] 
	{cf is readhexstring pop} image
	bitmapsave restore 
	grestore
	} bind def
/ngrayt 256 array def
/nredt 256 array def
/nbluet 256 array def
/ngreent 256 array def
	/gryt FMLOCAL
	/blut FMLOCAL
	/grnt FMLOCAL
	/redt FMLOCAL
	/indx FMLOCAL
	/cynu FMLOCAL
	/magu FMLOCAL
	/yelu FMLOCAL
	/k FMLOCAL
	/u FMLOCAL
FMLevel1 {
/colorsetup {
	currentcolortransfer
	/gryt exch def
	/blut exch def
	/grnt exch def
	/redt exch def
	0 1 255 {
		/indx exch def
		/cynu 1 red indx get 255 div sub def
		/magu 1 green indx get 255 div sub def
		/yelu 1 blue indx get 255 div sub def
		/k cynu magu min yelu min def
		/u k currentundercolorremoval exec def
%		/u 0 def
		nredt indx 1 0 cynu u sub max sub redt exec put
		ngreent indx 1 0 magu u sub max sub grnt exec put
		nbluet indx 1 0 yelu u sub max sub blut exec put
		ngrayt indx 1 k currentblackgeneration exec sub gryt exec put
	} for
	{255 mul cvi nredt exch get}
	{255 mul cvi ngreent exch get}
	{255 mul cvi nbluet exch get}
	{255 mul cvi ngrayt exch get}
	setcolortransfer
	{pop 0} setundercolorremoval
	{} setblackgeneration
	} bind def
}
{
/colorSetup2 {
	[ /Indexed /DeviceRGB 255 
		{dup red exch get 255 div 
		 exch dup green exch get 255 div 
		 exch blue exch get 255 div}
	] setcolorspace
} bind def
} ifelse
	/tran FMLOCAL
/fakecolorsetup {
	/tran 256 string def
	0 1 255 {/indx exch def 
		tran indx
		red indx get 77 mul
		green indx get 151 mul
		blue indx get 28 mul
		add add 256 idiv put} for
	currenttransfer
	{255 mul cvi tran exch get 255.0 div}
	exch concatprocs settransfer
} bind def
/BITMAPCOLOR { 
	/d 8 def
	gsave
	
	3 index 2 div add exch	
	4 index 2 div add exch	
	translate		
	rotate			
	1 index 2 div neg	
	1 index 2 div neg	
	translate		
	scale			
	/h exch def /w exch def
	/bitmapsave save def
	FMLevel1 {	
		colorsetup
		/is w d wbytes string def
		/cf currentfile def 
		w h d [w 0 0 h neg 0 h] 
		{cf is readhexstring pop} {is} {is} true 3 colorimage 
	} {
		colorSetup2
		/is w d wbytes string def
		/cf currentfile def 
		7 dict dup begin
			/ImageType 1 def
			/Width w def
			/Height h def
			/ImageMatrix [w 0 0 h neg 0 h] def
			/DataSource {cf is readhexstring pop} bind def
			/BitsPerComponent d def
			/Decode [0 255] def
		end image	
	} ifelse
	bitmapsave restore 
	grestore
	} bind def
/BITMAPCOLORc { 
	/d 8 def
	gsave
	
	3 index 2 div add exch	
	4 index 2 div add exch	
	translate		
	rotate			
	1 index 2 div neg	
	1 index 2 div neg	
	translate		
	scale			
	/h exch def /w exch def
	/lb w d wbytes def 
	sl lb lt {lb ms} if 
	/bitmapsave save def 
	FMLevel1 {	
		colorsetup
		/is im 0 lb getinterval def 
		ws 0 lb getinterval is copy pop 
		/cf currentfile def 
		w h d [w 0 0 h neg 0 h] 
		{ip} {is} {is} true 3 colorimage
	} {
		colorSetup2
		/is im 0 lb getinterval def 
		ws 0 lb getinterval is copy pop 
		/cf currentfile def 
		7 dict dup begin
			/ImageType 1 def
			/Width w def
			/Height h def
			/ImageMatrix [w 0 0 h neg 0 h] def
			/DataSource {ip} bind def
			/BitsPerComponent d def
			/Decode [0 255] def
		end image	
	} ifelse
	bitmapsave restore 
	grestore
	} bind def
/BITMAPTRUECOLORc { 
	/d 24 def
        gsave
 	
	3 index 2 div add exch	
	4 index 2 div add exch	
	translate		
	rotate			
	1 index 2 div neg	
	1 index 2 div neg	
	translate		
	scale			
	/h exch def /w exch def
	/lb w d wbytes def 
	sl lb lt {lb ms} if 
        /bitmapsave save def 
        
	/is im 0 lb getinterval def	
	/ris im 0 w getinterval def	
	/gis im w w getinterval def	
	/bis im w 2 mul w getinterval def 
        
        ws 0 lb getinterval is copy pop 
        /cf currentfile def 
        w h 8 [w 0 0 h neg 0 h] 
        {w rip pop ris} {gis} {bis} true 3 colorimage
        bitmapsave restore 
        grestore
        } bind def
/BITMAPTRUECOLOR { 
        gsave
		
		3 index 2 div add exch	
		4 index 2 div add exch	
		translate		
		rotate			
		1 index 2 div neg	
		1 index 2 div neg	
		translate		
		scale			
		/h exch def /w exch def
        /bitmapsave save def 
        /is w string def
        /gis w string def
        /bis w string def
        /cf currentfile def 
        w h 8 [w 0 0 h neg 0 h] 
        { cf is readhexstring pop } 
        { cf gis readhexstring pop } 
        { cf bis readhexstring pop } 
        true 3 colorimage 
        bitmapsave restore 
        grestore
        } bind def
/BITMAPTRUEGRAYc { 
	/d 24 def
        gsave
	
	3 index 2 div add exch	
	4 index 2 div add exch	
	translate		
	rotate			
	1 index 2 div neg	
	1 index 2 div neg	
	translate		
	scale			
	/h exch def /w exch def
	/lb w d wbytes def 
	sl lb lt {lb ms} if 
        /bitmapsave save def 
        
	/is im 0 lb getinterval def	
	/ris im 0 w getinterval def	
	/gis im w w getinterval def	
	/bis im w 2 mul w getinterval def 
        ws 0 lb getinterval is copy pop 
        /cf currentfile def 
        w h 8 [w 0 0 h neg 0 h] 
        {w rip pop ris gis bis w gray} image
        bitmapsave restore 
        grestore
        } bind def
/ww FMLOCAL
/r FMLOCAL
/g FMLOCAL
/b FMLOCAL
/i FMLOCAL
/gray { 
        /ww exch def
        /b exch def
        /g exch def
        /r exch def
        0 1 ww 1 sub { /i exch def r i get .299 mul g i get .587 mul
			b i get .114 mul add add r i 3 -1 roll floor cvi put } for
        r
        } bind def
/BITMAPTRUEGRAY { 
        gsave
		
		3 index 2 div add exch	
		4 index 2 div add exch	
		translate		
		rotate			
		1 index 2 div neg	
		1 index 2 div neg	
		translate		
		scale			
		/h exch def /w exch def
        /bitmapsave save def 
        /is w string def
        /gis w string def
        /bis w string def
        /cf currentfile def 
        w h 8 [w 0 0 h neg 0 h] 
        { cf is readhexstring pop 
          cf gis readhexstring pop 
          cf bis readhexstring pop w gray}  image
        bitmapsave restore 
        grestore
        } bind def
/BITMAPGRAY { 
	8 {fakecolorsetup} COMMONBITMAP
	} bind def
/BITMAPGRAYc { 
	8 {fakecolorsetup} COMMONBITMAPc
	} bind def
/ENDBITMAP {
	} bind def
end 
	/ALDsave FMLOCAL
	/ALDmatrix matrix def ALDmatrix currentmatrix pop
/StartALD {
	/ALDsave save def
	 savematrix
	 ALDmatrix setmatrix
	} bind def
/InALD {
	 restorematrix
	} bind def
/DoneALD {
	 ALDsave restore
	} bind def
/I { setdash } bind def
/J { [] 0 setdash } bind def
%%EndProlog
%%BeginSetup
(4.0) FMVERSION
1 1 0 0 612 792 0 1 8 FMDOCUMENT
0 0 /Times-Roman FMFONTDEFINE
1 0 /Times-Bold FMFONTDEFINE
2 0 /Times-Italic FMFONTDEFINE
3 0 /Courier FMFONTDEFINE
32 FMFILLS
0 0 FMFILL
1 0.1 FMFILL
2 0.3 FMFILL
3 0.5 FMFILL
4 0.7 FMFILL
5 0.9 FMFILL
6 0.97 FMFILL
7 1 FMFILL
8 <0f1e3c78f0e1c387> FMFILL
9 <0f87c3e1f0783c1e> FMFILL
10 <cccccccccccccccc> FMFILL
11 <ffff0000ffff0000> FMFILL
12 <8142241818244281> FMFILL
13 <03060c183060c081> FMFILL
14 <8040201008040201> FMFILL
16 1 FMFILL
17 0.9 FMFILL
18 0.7 FMFILL
19 0.5 FMFILL
20 0.3 FMFILL
21 0.1 FMFILL
22 0.03 FMFILL
23 0 FMFILL
24 <f0e1c3870f1e3c78> FMFILL
25 <f0783c1e0f87c3e1> FMFILL
26 <3333333333333333> FMFILL
27 <0000ffff0000ffff> FMFILL
28 <7ebddbe7e7dbbd7e> FMFILL
29 <fcf9f3e7cf9f3f7e> FMFILL
30 <7fbfdfeff7fbfdfe> FMFILL
%%EndSetup
%%Page: "1" 1
%%BeginPaperSize: Letter
%%EndPaperSize
612 792 0 FMBEGINPAGE
[0 0 0 1 0 0 0]
[ 0 1 1 0 1 0 0]
[ 1 0 1 0 0 1 0]
[ 1 1 0 0 0 0 1]
[ 1 0 0 0 0 1 1]
[ 0 1 0 0 1 0 1]
[ 0 0 1 0 1 1 0]
 7 FrameSetSepColors
FrameNoSep
0 0 0 1 0 0 0 K
J
0 0 0 1 0 0 0 K
72 746 540 756 R
7 X
0 0 0 1 0 0 0 K
V
75 36 543 46 R
V
0 10 Q
0 X
(Page 1) 516.06 39.18 T
0 0 0 1 0 0 0 K
0 0 0 1 0 0 0 K
72 72 540 720 R
7 X
V
0 12 Q
0 X
(PROVISIONAL APPLICATION) 225.17 576 T
1 14 Q
(A Process for Controlling Program Specialization Using Arbitrary) 107.49 550.67 T
(Compile-time and Run-time Conditions) 187.58 533.67 T
0 12 Q
(Inventors:) 281.67 497 T
(Craig Chambers) 266.84 469 T
(Citizen of U.S.) 270 455 T
(residing in Seattle, Washington) 230.67 441 T
(and) 297.34 413 T
(Susan J. Eggers) 268.17 385 T
(Citizen of U.S.) 270 371 T
(residing in Seattle, Washington) 230.67 357 T
(and) 297.34 329 T
(Brian K. Grant) 270.17 301 T
(Citizen of U.S.) 270 287 T
(residing in Seattle, Washington) 230.67 273 T
(and) 297.34 245 T
(Markus Mock) 272.17 217 T
(Citizen of Germany.) 256.84 203 T
(residing in Seattle, Washington) 230.67 189 T
(and) 297.34 161 T
(Matthai Philipose) 263.5 133 T
(Citizen of India) 268.34 119 T
(residing in Seattle, Washington) 230.67 105 T
0 1 1 0 1 0 0 K
0 0 0 1 0 0 0 K
0 0 0 1 0 0 0 K
FMENDPAGE
%%EndPage: "1" 1
%%Page: "2" 2
612 792 0 FMBEGINPAGE
[0 0 0 1 0 0 0]
[ 0 1 1 0 1 0 0]
[ 1 0 1 0 0 1 0]
[ 1 1 0 0 0 0 1]
[ 1 0 0 0 0 1 1]
[ 0 1 0 0 1 0 1]
[ 0 0 1 0 1 1 0]
 7 FrameSetSepColors
FrameNoSep
0 0 0 1 0 0 0 K
72 746 540 756 R
7 X
0 0 0 1 0 0 0 K
V
75 36 543 46 R
V
0 10 Q
0 X
(Page 2) 516.06 39.18 T
0 0 0 1 0 0 0 K
0 0 0 1 0 0 0 K
72 72 540 720 R
7 X
V
1 14 Q
0 X
(Provisional Patent Application for) 203.53 654.67 T
(A Process for Controlling Program Specialization Using Arbitrary) 107.49 637.67 T
(Compile-time and Run-time Conditions) 187.58 620.67 T
(Craig Chambers, Susan J. Eggers, Brian K. Grant, Markus Mock, and) 94.82 586.67 T
(Matthai Philipose) 252.91 569.67 T
(Field of Invention) 72 524.67 T
(Summary) 72 473.67 T
0 12 Q
2.91 (This invention is a process for implementing conditional specialization. The conditions are) 72 449.5 P
2.93 (based on compile-time and run-time information, and the scope of the specialization is an) 72 428.5 P
5.62 (arbitrary number of program points, not simply entire functions. The process uses a) 72 407.5 P
4.37 (programming language to specify the conditions on which specialization should depend.) 72 386.5 P
0.34 (Consequently, arbitrarily complex compile-time and run-time conditions are possible, enabling a) 72 365.5 P
0.26 (programmer to decide when it is profitable to specialize. Any compiler that implements run-time) 72 344.5 P
(specialization could include this invention.) 72 323.5 T
1 14 Q
(Background) 72 280.17 T
0 12 Q
3.93 (Several program optimizations sometimes improve program performance, and other times) 72 256 P
0.53 (degrade it. Therefore one may wish to apply these optimizations conditionally, only when it can) 72 235 P
3.1 (be ascertained that they will benefit performance. Two opposing) 72 214 P
0 1 1 0 1 0 0 K
0 0 0 1 0 0 0 K
3.1 (factors usually determine) 412.49 214 P
0.36 (whether conditionally applying an optimization will be beneficial, the reliability of the condition) 72 193 P
0.55 (and the run-time overhead of applying the optimization. A reliable condition is often difficult to) 72 172 P
3.48 (make at static compile time, which can formulate conditions based only on compile-time) 72 151 P
0.97 (information. On the other hand, compile-time conditions incur no run-time overhead. Run-time) 72 130 P
1.04 (conditions are more reliable, because more information about the program\325s state and behavior) 72 109 P
1.15 (is available at run time. The price of deferring the optimization until run time, however, is the) 72 88 P
0 1 1 0 1 0 0 K
0 0 0 1 0 0 0 K
0 0 0 1 0 0 0 K
FMENDPAGE
%%EndPage: "2" 2
%%Page: "3" 3
612 792 0 FMBEGINPAGE
[0 0 0 1 0 0 0]
[ 0 1 1 0 1 0 0]
[ 1 0 1 0 0 1 0]
[ 1 1 0 0 0 0 1]
[ 1 0 0 0 0 1 1]
[ 0 1 0 0 1 0 1]
[ 0 0 1 0 1 1 0]
 7 FrameSetSepColors
FrameNoSep
0 0 0 1 0 0 0 K
72 746 540 756 R
7 X
0 0 0 1 0 0 0 K
V
75 36 543 46 R
V
0 10 Q
0 X
(Page 3) 516.06 39.18 T
0 0 0 1 0 0 0 K
0 0 0 1 0 0 0 K
72 72 540 720 R
7 X
V
0 12 Q
0 X
(run-time cost in applying the optimization.) 72 712 T
0.57 (This invention is concerned with conditionally applying program specialization, an optimization) 72 691 P
2.93 (in which code is specialized for the values of particular variables. Most previous program) 72 670 P
2.19 (specialization systems either did specialization unconditionally or only allowed compile-time) 72 649 P
3.56 (conditions \050including those based on binding-time information\051. One specialization system) 72 628 P
0.54 (conditionally specialized at run time, but incurred a high run-time specialization cost, because it) 72 607 P
(deferred) 72 586 T
2 F
(all) 114.97 586 T
0 F
( specialization until run time.) 127.64 586 T
3.9 (This invention enables conditional run-time specialization, but without the large run-time) 72 565 P
1.92 (overhead. It relies on both compile-time and run-time information to formulate the condition) 72 544 P
0.76 (and evaluates the condition at run time, resulting in a more reliable forecast of the performance) 72 523 P
4.34 (benefits of specializing a program. However, it does the bulk of the analysis to apply) 72 502 P
1.03 (specialization at compile time, in order to reduce the run-time cost of specialization. Finally, it) 72 481 P
(applies conditional specialization to program scope of arbitrary granularity.) 72 460 T
1 14 Q
(Invention) 72 423.67 T
0 12 Q
1.91 (This invention enables run-time specialization to be controlled by arbitrary compile-time and) 72 404 P
0.67 (run-time conditions. A programmer inserts the conditions under which the specialization should) 72 383 P
0.9 (be applied into a program in the form of source-code statements. These conditions, represented) 72 362 P
1.78 (in Figures 1 and 2 as <) 72 341 P
2 F
1.78 (conditions>) 192.13 341 P
0 F
1.78 (, are arbitrary combinations of compile-time and run-time) 250.23 341 P
1.6 (expressions, and are evaluated by the compiler and executed at run time as ordinary program) 72 320 P
2.28 (expressions. Multiple conditions can govern the same specialization, the same condition can) 72 299 P
1.64 (control multiple specializations, and multiple conditional specializations can be applied to the) 72 278 P
2.54 (same body of code. Figure 1 presents an example of conditions inserted into a program to) 72 257 P
0.22 (control a few different kinds of specialization \050for example, specialization based on the values of) 72 236 P
(different variables\051.) 72 215 T
0.98 (The conditions must be annotated, so that the run-time specializer can easily differentiate them) 72 194 P
4.23 (from normal program code. We use source-level annotations \050i.e., text inserted into the) 72 173 P
0.88 (program\325s source code\051 to identify the conditions and to control the specialization process \050i.e.,) 72 152 P
3.44 (to set policies that guide the specialization analyses and the run-time specializer\051, and to) 72 131 P
0.57 (delineate the desired scope of specialization. These annotations are represented in Figures 1 and) 72 110 P
(2 by) 72 89 T
2 F
(<do specialization>) 96 89 T
0 F
(.) 193.87 89 T
0 1 1 0 1 0 0 K
0 0 0 1 0 0 0 K
0 0 0 1 0 0 0 K
FMENDPAGE
%%EndPage: "3" 3
%%Page: "4" 4
612 792 0 FMBEGINPAGE
[0 0 0 1 0 0 0]
[ 0 1 1 0 1 0 0]
[ 1 0 1 0 0 1 0]
[ 1 1 0 0 0 0 1]
[ 1 0 0 0 0 1 1]
[ 0 1 0 0 1 0 1]
[ 0 0 1 0 1 1 0]
 7 FrameSetSepColors
FrameNoSep
0 0 0 1 0 0 0 K
72 746 540 756 R
7 X
0 0 0 1 0 0 0 K
V
75 36 543 46 R
V
0 10 Q
0 X
(Page 4) 516.06 39.18 T
0 0 0 1 0 0 0 K
0 0 0 1 0 0 0 K
72 72 540 720 R
7 X
V
0 12 Q
0 X
2.47 (Once the desired conditions are inserted and annotated \050shown in Figure 2a\051, the following) 72 523 P
(procedure is applied to implement conditional run-time specialization:) 72 502 T
(1.) 72 481 T
(Copy the code that will be specialized.) 90 481 T
-0.23 (Starting at the control-\337ow mer) 90 463 P
-0.23 (ge following the condition, split the mer) 240.18 463 P
-0.23 (ging paths by copying) 431.59 463 P
(the code after the mer) 90 445 T
(ge. Stop copying when the end of the desired scope of specialization is) 194.41 445 T
-0.24 (reached, or when the specialization is known to no longer have an ef) 90 427 P
-0.24 (fect. The new copy of the) 415.82 427 P
(code will be specialized and then executed whenever the speci\336ed conditions hold.) 90 409 T
(2.) 72 391 T
(Apply the specialization analysis to the copy) 90 391 T
(.) 303.86 391 T
-0.24 (Analyze the copy for run-time specialization, applying both traditional specialization analysis) 90 373 P
-0.38 (\050typically called a) 90 355 P
2 F
-0.38 (binding-time analysis) 177.84 355 P
0 F
-0.38 (\051 and analyses driven by the annotations, for example,) 281.13 355 P
(those needed to determine whether and when to cache specialized code.) 90 337 T
(3.) 72 319 T
(Create a run-time specializer) 90 319 T
(.) 227.63 319 T
(Create a run-time specializer from the analyzed copy that will generate a specialized version) 90 301 T
(of the copy) 90 283 T
(.) 143.21 283 T
(4.) 72 265 T
(Create a specializer stub.) 90 265 T
(Prepend to the run-time specializer a stub that either executes the run-time specializer or dis-) 90 247 T
(patches to the already created specialized version of the copy) 90 229 T
(.) 382.8 229 T
(Figure 2b depicts the result of this process.) 72 211 T
1 14 Q
(Br) 72 174.67 T
(oadening) 87.3 174.67 T
0 12 Q
(This invention can be modified or extended in the following ways:) 72 155 T
(\245) 75.6 134 T
(The invention can be used to conditionally) 90 134 T
2 F
(pr) 297.65 134 T
(event) 307.87 134 T
0 F
( specialization from being applied.) 333.19 134 T
(\245) 75.6 116 T
(Our conditions and annotations are inserted manually) 90 116 T
(. Conditions and/or annotations can be) 345.85 116 T
(inserted automatically) 90 98 T
(, based on run-time pro\336ling information or by compiler analysis.) 195.54 98 T
(\245) 75.6 80 T
-0.25 (Specialization can occur at arbitrary points before the control-\337ow mer) 90 80 P
-0.25 (ge following the condi-) 428.44 80 P
0 0 0 1 0 0 0 K
100.76 531 511.24 720 C
0 0 0 1 0 0 0 K
125.83 558.67 491.67 709.5 R
7 X
0 0 0 1 0 0 0 K
V
3 12 Q
0 X
(if \050) 125.83 701.5 T
2 F
(<conditions for specialization 1>) 154.63 701.5 T
3 F
(\051 then) 316.51 701.5 T
2 F
(<do specialization 1>) 162.17 687.5 T
3 F
(else if \050) 125.83 673.5 T
2 F
(<conditions for specialization 2>) 190.63 673.5 T
3 F
(\051 then) 352.51 673.5 T
2 F
(<do specialization 2>) 162.17 659.5 T
3 F
(else i) 125.83 645.5 T
0 F
(. .) 125.83 631.5 T
3 F
(endif) 125.83 617.5 T
2 F
(<code to be conditionally specialized>) 125.83 600.5 T
(. . .) 125.83 583.5 T
1 F
(Figur) 159.52 559.5 T
(e 1: Example of Annotated Specialization Conditions) 187.97 559.5 T
0 1 1 0 1 0 0 K
0 0 0 1 0 0 0 K
0 0 0 1 0 0 0 K
0 0 612 792 C
0 1 1 0 1 0 0 K
0 0 0 1 0 0 0 K
FMENDPAGE
%%EndPage: "4" 4
%%Page: "5" 5
612 792 0 FMBEGINPAGE
[0 0 0 1 0 0 0]
[ 0 1 1 0 1 0 0]
[ 1 0 1 0 0 1 0]
[ 1 1 0 0 0 0 1]
[ 1 0 0 0 0 1 1]
[ 0 1 0 0 1 0 1]
[ 0 0 1 0 1 1 0]
 7 FrameSetSepColors
FrameNoSep
0 0 0 1 0 0 0 K
72 746 540 756 R
7 X
0 0 0 1 0 0 0 K
V
75 36 543 46 R
V
0 10 Q
0 X
(Page 5) 516.06 39.18 T
0 0 0 1 0 0 0 K
0 0 0 1 0 0 0 K
72 72 540 720 R
7 X
V
0 12 Q
0 X
(tion, rather than at the mer) 90 712 T
(ge.) 217.09 712 T
(\245) 75.6 694 T
-0.2 (The code to be specialized can be copied at some other time than immediately before the anal-) 90 694 P
(ysis.) 90 676 T
(\245) 75.6 658 T
-0.53 (The invention, speci\336cally) 90 658 P
-0.53 (, the combination of run-time conditions and compile-time analysis,) 215.81 658 P
(can be applied to optimizations other than specialization, as described below) 90 640 T
(.) 456.83 640 T
1 F
(Compile-time Optimizations) 72 610 T
0 F
1.75 (This description recasts the invention in terms of an arbitrary) 72 593 P
2 F
1.75 (compile-time) 385.51 593 P
0 F
1.75 ( optimization. The) 448.16 593 P
0.77 (primary difference is, instead of replacing the copied code with a stub and run-time specializer,) 72 572 P
(the optimization is applied directly to the copy, as shown in Figure 3.) 72 551 T
0.24 (Once the desired conditions are inserted into the program source and annotated \050shown in Figure) 72 530 P
(3a\051, the following procedure is applied to implement the conditional optimization:) 72 509 T
(1.) 72 488 T
(From the control-\337ow mer) 90 488 T
(ge following the condition, split the mer) 217.44 488 T
(ging paths by copying the) 410.22 488 T
(code that follows, creating a new copy of the code to be optimized and executed when the) 90 470 T
(speci\336ed conditions hold. Stop copying when the end of the desired scope of optimization is) 90 452 T
(reached, or when the optimization is known to no longer have an ef) 90 434 T
(fect. The new copy of the) 413.39 434 T
(code will be optimized and then executed whenever the speci\336ed conditions hold.) 90 416 T
(2.) 72 398 T
(Apply the optimization described by the annotations to the copy) 90 398 T
(.) 396.86 398 T
(3.) 72 379.82 T
-0.29 (If the useful scope of the optimization was not accurately determined in step 2, re-mer) 90 379.82 P
-0.29 (ge need-) 499.31 379.82 P
(lessly copied code with the original.) 90 361.82 T
( Figure 3b depicts the result of this process.) 72 343.82 T
0 1 1 0 1 0 0 K
0 0 0 1 0 0 0 K
0 0 0 1 0 0 0 K
FMENDPAGE
%%EndPage: "5" 5
%%Page: "6" 6
612 792 0 FMBEGINPAGE
[0 0 0 1 0 0 0]
[ 0 1 1 0 1 0 0]
[ 1 0 1 0 0 1 0]
[ 1 1 0 0 0 0 1]
[ 1 0 0 0 0 1 1]
[ 0 1 0 0 1 0 1]
[ 0 0 1 0 1 1 0]
 7 FrameSetSepColors
FrameNoSep
0 0 0 1 0 0 0 K
72 746 540 756 R
7 X
0 0 0 1 0 0 0 K
V
75 36 543 46 R
V
0 10 Q
0 X
(Page 6) 516.06 39.18 T
0 0 0 1 0 0 0 K
0 0 0 1 0 0 0 K
72 72 540 720 R
7 X
V
0 0 0 1 0 0 0 K
71.75 404.98 540.25 720 C
0 0 0 1 0 0 0 K
439.07 570.6 537.4 610.6 R
7 X
0 0 0 1 0 0 0 K
V
0.5 H
2 Z
0 X
N
87.24 667.67 138.15 685.67 189.06 667.67 138.15 649.67 4 Y
7 X
V
0 X
N
0 0 0 1 0 0 0 K
3 10 Q
(if) 103.32 664.26 T
0 0 0 1 0 0 0 K
2 F
(<conditions>) 117.82 664.26 T
0 0 0 1 0 0 0 K
0 0 0 1 0 0 0 K
382.91 687.67 433.82 705.67 484.73 687.67 433.82 669.67 4 Y
7 X
V
0 X
N
0 0 0 1 0 0 0 K
3 F
(if) 398.98 684.26 T
0 0 0 1 0 0 0 K
2 F
(<conditions>) 413.48 684.26 T
0 0 0 1 0 0 0 K
0 0 0 1 0 0 0 K
88.82 577.83 187.15 617.83 R
7 X
V
0 X
N
330.23 595.27 428.57 635.27 R
7 X
V
0 X
N
439.07 610.27 537.4 635.27 R
7 X
V
0 X
N
121.64 624.26 123.82 618.67 117.89 619.58 119.76 621.92 4 Y
V
112.15 661.17 M
 90.73 653.56 107.82 632.29 119.77 621.92 D
1 H
N
158.85 619.09 152.92 618.17 155.09 623.76 156.97 621.42 4 Y
V
164.59 660.67 M
 186 653.06 168.92 631.79 156.97 621.42 D
N
383.29 641.01 379.81 636.17 377.36 641.6 380.32 641.3 4 Y
V
408.98 677.83 M
 393.43 672.64 382.86 657.41 380.34 641.3 D
N
490.24 641.95 487.82 636.5 484.31 641.32 487.27 641.64 4 Y
V
458.65 678.17 M
 474.21 672.97 484.78 657.74 487.29 641.63 D
N
2 12 Q
(Original Code) 103.15 606.17 T
(Original Code) 344.57 623.67 T
(Specializer Stub) 449.4 618.67 T
69.82 472.33 539.82 487.33 R
7 X
V
1 F
0 X
(Figur) 125.15 479.33 T
(e 2: Code Befor) 153.6 479.33 T
(e and After Conditional Run-T) 233.03 479.33 T
(ime Specialization) 391.49 479.33 T
0 1 1 0 1 0 0 K
0 0 0 1 0 0 0 K
2 F
(Run-time) 464.74 596.17 T
0 0 0 1 0 0 0 K
0 0 0 1 0 0 0 K
0 F
(\050a\051) 131.32 544.5 T
(\050b\051) 426.82 544.5 T
2 F
(Specializer) 461.57 584.17 T
161.49 639.71 184.82 646.37 R
7 X
V
N
0 X
(<do specialization) 131.82 640.33 T
0 F
(>) 221.59 640.33 T
1 F
(Befor) 121.27 515.81 T
(e) 149.71 515.81 T
(After) 421.22 515.81 T
0 0 0 1 0 0 0 K
0 0 612 792 C
71.77 83.29 540.23 404.98 C
0 0 0 1 0 0 0 K
90.93 355.15 141.84 373.15 192.75 355.15 141.84 337.15 4 Y
7 X
0 0 0 1 0 0 0 K
V
0.5 H
2 Z
0 X
N
0 0 0 1 0 0 0 K
3 10 Q
(if) 107 351.74 T
0 0 0 1 0 0 0 K
2 F
(<conditions>) 121.5 351.74 T
0 0 0 1 0 0 0 K
0 0 0 1 0 0 0 K
369.59 355.15 420.5 373.15 471.42 355.15 420.5 337.15 4 Y
7 X
V
0 X
N
0 0 0 1 0 0 0 K
3 F
(if) 385.67 351.74 T
0 0 0 1 0 0 0 K
2 F
(<conditions>) 400.17 351.74 T
0 0 0 1 0 0 0 K
0 0 0 1 0 0 0 K
71.34 140.32 538.84 161.15 R
7 X
V
1 12 Q
0 X
(Figur) 154.81 153.15 T
(e 3: Code Befor) 183.26 153.15 T
(e and After Conditional Optimization) 262.69 153.15 T
0 1 1 0 1 0 0 K
0 0 0 1 0 0 0 K
92.5 262.82 190.84 302.82 R
7 X
V
0 X
N
316.92 262.82 415.26 302.82 R
7 X
V
0 X
N
425.75 262.82 524.09 302.82 R
7 X
V
0 X
N
125.33 309.24 127.5 303.65 121.57 304.57 123.45 306.91 4 Y
V
115.84 346.15 M
 94.42 338.55 111.5 317.27 123.45 306.9 D
1 H
N
162.53 304.07 156.6 303.15 158.77 308.75 160.65 306.41 4 Y
V
168.27 345.65 M
 189.69 338.05 172.61 316.77 160.66 306.4 D
N
369.98 308.49 366.5 303.65 364.05 309.08 367.01 308.79 4 Y
V
395.67 345.32 M
 380.12 340.12 369.55 324.89 367.03 308.78 D
N
476.93 309.43 474.51 303.98 471 308.81 473.96 309.12 4 Y
V
445.34 345.65 M
 460.89 340.45 471.46 325.23 473.98 309.12 D
N
2 F
(Original Code) 106.83 291.15 T
(Original Code) 331.25 291.15 T
(Optimized Code) 436.09 291.15 T
0 F
(\050a\051) 135.18 225.8 T
(\050b\051) 413.51 225.8 T
165.83 322.83 189.17 329.5 R
7 X
V
N
2 F
0 X
(<do optimization>) 143.34 323.65 T
1 F
(Befor) 124.95 195.33 T
(e) 153.39 195.33 T
(After) 406.85 195.33 T
0 0 0 1 0 0 0 K
0 0 612 792 C
0 1 1 0 1 0 0 K
0 0 0 1 0 0 0 K
FMENDPAGE
%%EndPage: "6" 6
%%Trailer
%%BoundingBox: 0 0 612 792
%%PageOrder: Ascend
%%Pages: 6
%%DocumentFonts: Times-Roman
%%+ Times-Bold
%%+ Times-Italic
%%+ Courier
%%EOF

Date: Thu, 11 Jun 1998 09:14:46 -0700
From: eggers@yakima (Susan Eggers)
To: pljones@u.washington.edu
Subject: one more to go
Cc: spin-comp@cs


Patrick --

You should have 3 patents completed by now.  Brian Grant and Matthai
Philipose are working on the fourth and we'll send it to you some
time today.

Thanks very much for coping with our last minute writing.

Susan

Date: Thu, 11 Jun 1998 11:17:27 -0700 (PDT)
From: Patrick Jones <pljones@u.washington.edu>
To: Susan Eggers <eggers@cs.washington.edu>
cc: spin-comp@cs.washington.edu
Subject: Re: one more to go

Tracy mentioned that you had a mofifications for the original two - or is
that not the case? If not, I'll send the three today and do the fourth
overnight.

pljones, Technology Manager
Office of Technology Transfer
University of Washington

voice 206-616-3451 fax 206-616-3322

On Thu, 11 Jun 1998, Susan Eggers wrote:

> 
> Patrick --
> 
> You should have 3 patents completed by now.  Brian Grant and Matthai
> Philipose are working on the fourth and we'll send it to you some
> time today.
> 
> Thanks very much for coping with our last minute writing.
> 
> Susan
> 


Date: Thu, 11 Jun 1998 22:22:46 -0700
From: eggers@yakima (Susan Eggers)
To: spin-comp@cs
Subject: policy patent

I've sent it on to Patrick.

Susan

Date: Mon, 15 Jun 1998 11:08:37 -0700
From: eggers@yakima (Susan Eggers)
To: spin-comp@yakima
Subject: can we move tomorrow's meeting

I have a conflict with an affirmative action meeting at 2.
Actually, it's just the 3 of us and we probably need one-on-one
meetings, more than a group meeting.
So if I'm right on this, let's just have our research meetings.

When do you want them over the summer?

Susan

To: spin-comp@thistle.cs.washington.edu
Subject: polyvariant division works on the small mipsi-like interpreter
Date: Thu, 18 Jun 1998 16:27:24 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

I fixed several problems in the BTA, and one problem with copying IGOTOs.
Update mflow.

--Brian

+++ Application polydiv passed
+++ Application polydiv2 passed

To: spin-comp@thistle.cs.washington.edu
Subject: rt/dcmake changes
Date: Fri, 19 Jun 1998 15:08:08 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

I've made a few enhancements to our scripts.  The most noticeable one is that
I've changed dcmake to produce and use a ccomargs file, so that you can use
exactly the same arguments for debugging as you used on the command line.
The file is named <app>.ccomargs, and any existing ccomargs.in files won't
be touched.  A debugging file, <app>.dbx, is also generated.  You can source
it in gdb, and it should work (amazing!).

NB: one-step mode doesn't (yet?) use the ccomargs file, nor is
    one created for the noop version.

You need to do the following to get this to work (cut & paste):

0) cvs update bin

1) Erase the contents of
   /projects/trace1/mflow/usr/vssad/release/matthai/.ccrc
   /projects/trace1/mflow/usr/vssad/release/mock/.ccrc
   but don't delete the files!

2) /bin/rm /projects/trace1/mflow/usr/vssad/release/matthai/bin/rcc
   /bin/rm /projects/trace1/mflow/usr/vssad/release/mock/bin/rcc

3) ln -s /afs/cs/project/dyncomp/matthai/DyC/bin/rcc \
	/projects/trace1/mflow/usr/vssad/release/matthai/bin/rcc
   ln -s /afs/cs/project/dyncomp/mock/DyC/bin/rcc \
	/projects/trace1/mflow/usr/vssad/release/mock/bin/rcc

Your rcc will be created when you first to a dcmake.

Other changes to the scripts:

dcmake will use the rt-args file if you specify "-use-rt-args".  Remember,
the last arguments specified take precedence, so if you want to override
any arguments in the rt-args file, put them on the dcmake command line
after -use-rt-args.

rt and dcmake now set the include directory correctly even if you don't
have the environment variable set.

dcmake will rebuild the app if the rt-args file is changed, whether those
arguments are used or not.

Probably some other minor fixes that I've forgotten...

--Brian

To: spin-comp@thistle.cs.washington.edu
Subject: dcmake
Date: Fri, 19 Jun 1998 15:25:20 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

I just update the one-step rules to use the ccomargs file.  The changes
are totally untested, but should work. :-)  Note that I also haven't tested
the scripts in timing mode.  But, the timing instrumentation is still broken
(next on my list...), so that shouldn't matter right now.  

--Brian

Date: Tue, 23 Jun 1998 08:35:36 -0700
From: eggers@yakima (Susan Eggers)
To: spin-comp@yakima
Subject: profiling workshop


----- Begin Included Message -----

From calder@cs.ucsd.edu Mon Jun 22 11:39:55 1998
Subject: Workshop on Profile and Feedback-Directed Compilation
Content-Length: 2233
X-Lines: 59
Status: RO


      Workshop on Profile and Feedback-Directed Compilation

                 Paris, France October 13, 1998

       In Conjunction with the International Conference on
  Parallel Architectures and Compilation Techniques (PACT '98)

This workshop is intended to be a forum for bringing together
researchers in the area of feedback-directed compilation and
optimization. Talks will be solicited emphasizing new ideas and
experience with building feedback-directed systems. There will be
a limited number of talks in order to allow the audience to
participate. The topics of interest include, but are not limited
to:

   - Analysis to estimate program behavior
   - Profile techniques to measure program behavior
   - Techniques for estimating the benefit of optimization
   - Program analysis based on measurements, estimates, or 
     program behavior
   - Compiler optimization based on measurements, estimates, 
     or program behavior
   - Adaptive execution, dynamic compilation and continuous 
     profiling/optimization
   - Behavior analysis and optimization to improve memory hierarchy 
     performance (e.g., cache-conscious data structures)
   - Experiences with real systems

There will be no published proceedings. However, workshop attendees
will receive copies of slides and related papers.

Submission: Talks will be accepted on the basis of a short abstract
that describes the work and the novel algorithms or experiences that
resulted from it.

Deadlines:
	- 5 Page abstract due by Aug. 21, 1998
	- Notifications by Sept. 5, 1998

Questions: pfdc@cs.ucsd.edu

The most recent information is available at:
	http://www.cse.ucsd.edu/~calder/pfdc/


Workshop Co-Chairs: Brad Calder, Rajiv Gupta, and James Larus

Program Committee:

Brad Calder         UC San Diego              calder@cs.ucsd.edu		    
Craig Chambers      University of Washington  chambers@cs.washington.edu
Evelyn Duesterwald  Hewlett Packard           duester@hpl.hp.com
Jesse Fang          Intel                     jfang@riddler.sc.intel.com
Rajiv Gupta         University of Pittsburgh  gupta@cs.pitt.edu
James Larus         Microsoft Research        larus@microsoft.com
Mike Smith          Harvard University        smith@eecs.harvard.edu




----- End Included Message -----


Date: Tue, 23 Jun 1998 09:42:10 -0700
From: eggers@yakima (Susan Eggers)
To: spin-comp@yakima
Subject: PLDI deadline

is early this year -- Oct. 9.

Susan

To: spin-comp@thistle.cs.washington.edu
Subject: pov profiled
Date: Wed, 24 Jun 1998 11:10:39 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

I profiled POV to check whether we should consider it further.  The
routine we were planning to specialize, Trace, only contributes directly
to at most 7.2% of the execution time, and as little as 1% for some inputs.
The different inputs have significantly different profiles, since the types
of objects comprising the scenes determine what routines are called.  For
example, Intersect_Quadric is 5% of exec. time in this example, 16% in another,
and 0% in another.

The upshot is that we'd have to specialize multiple routines to get
significant speedup on any one input and we'd have to carefully choose
that input to suite what we could specialize.  It would probably take an
effort comparable to what Matthai has invested in OpenGL.  It may not be
worth it in the short term.  On the other hand, if we want to submit to
SigGraph... :-)

--Brian

 11.5      1.9854   11.5      1.99 All_Ellipsoid_Intersections (<stripped>)
  9.1      1.5771   20.6      3.56 Intersect_Sphere (<stripped>)
  8.6      1.4922   29.2      5.05 MInvTransPoint (<stripped>)
  7.2      1.2383   36.3      6.29 Trace (<stripped>)
  5.3      0.9160   41.6      7.21 Intersect_Plane (<stripped>)
  5.2      0.8984   46.8      8.11 proc_at_0x1200276a0 (<stripped>)
  5.0      0.8633   51.8      8.97 Intersect_Quadric (<stripped>)
  4.7      0.8145   56.5      9.79 Ray_In_Bounds (<stripped>)
  4.4      0.7686   60.9     10.55 Intersection (<stripped>)
  4.0      0.6855   64.9     11.24 All_CSG_Intersect_Intersections (<stripped>)


To: spin-comp@franklin.cs.washington.edu
Subject: Some observations on automation, triggered by Brian's pov mail
Date: Wed, 24 Jun 1998 12:07:50 PDT
From: Matthai Philipose <matthai@franklin.cs.washington.edu>

Brian's experience with pov (along with mine with OpenGL) seems to cast the following additional light on automation of dynamic compilation:

1) Real programs seem to have many dynamic regions, most of which have to be specialized to get appreciable gain. This means that the amount of work done manually to specialize a single program may be getting out of hand => automation (or at least "tools") would be good.

2) In general, the total benefit from our dynamic compilation  of all these regions may not be very great (say 10-15%), perhaps more in line with what value-specific optimizations give in the static compilation context for C. At these speedup levels, people may be unwilling to use dynamic compilation unless it is automated.
	The burden on the user will only get worse when there is a richer catalog of optimizations available. 

3) The presence of many dynamic regions each with relatively small benefit makes it even more important to have very fast dispatches to dynamically compiled code. This is a point Craig brought up yesterday too. In general, automated dynamic compilation systems will not be able to use unchecked annotations. 

Just writing down our "experiences" while they're still fresh.
		Matthai

Date: Wed, 24 Jun 1998 16:50:09 -0700
From: eggers@yakima (Susan Eggers)
To: spin-comp@thistle.cs.washington.edu, grant@cs.washington.edu
Subject: Re: pov profiled

From your description, pov didn't seem to be a complete lose, but
more a case of a program that should be done after easier ones
are tackled.  The execution time profile looked reasonable for the
input you used.  So as long as the annotations to the various
routines don't cause changes to the infrastructure, we could begin
by annotating the top half of those.

Susan

To: eggers@yakima (Susan Eggers)
cc: spin-comp@cs
Subject: Re: pov profiled 
Date: Wed, 24 Jun 1998 16:58:29 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

>> >From your description, pov didn't seem to be a complete lose, but
>> more a case of a program that should be done after easier ones
>> are tackled.  The execution time profile looked reasonable for the
>> input you used.  So as long as the annotations to the various
>> routines don't cause changes to the infrastructure, we could begin
>> by annotating the top half of those.

No, not a complete lose.  But, I'd have to spend time figuring out what to
make static, comparable to what Matthai did for OpenGL.  I don't know that
the top half of those routines are even specializable.  With dinero and
the interpreters, it is fairly obvious what annotations to put in.  So, I
agree with you that pov hasn't been ruled out, but maybe has lower priority
than the others.

--Brian

To: spin-comp@thistle.cs.washington.edu
Subject: new scripts committed
Date: Mon, 06 Jul 1998 17:20:16 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

I've committed the new scripts (rt, dcmake, etc.).  The new scripts (more than
50% rewritten) have many new features, such as support for multiple source
files, header files, multiple sets of annotations, and multiple sets of
compiler arguments.  I'll write up something about how to use them.  The
default behavior should be nearly the same as what you're used to.  If you
have problems, let me know.

One comment: dcmake's "-onestep" option is not yet implemented (you'll get
a fatal error).

--Brian

To: eggers@yakima (Susan Eggers)
cc: spin-comp@cs
Subject: Re: hi 
Date: Fri, 10 Jul 1998 13:51:08 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

What I've been doing:

	- I inlined all specializable code into one routine in dinero,
	  and annotated it, producing a 700+-line dynamic region.  I
	  reprofiled it to see how much speedup we got just from inlining
	  (the answer: quite a bit).  However, the region is still
	  responsible for 65% of the run time.  Dynamic compilation of
	  the region does seem to be hung up on spill code, though there
	  are a couple bugs in the compiler that I'm also thinking about how
	  to solve.

	- I rewrote the scripts we used to build DyC apps in order to
	  provide the features we need for testing.

	- I fixed the timing infrastructure that I broke when overhauling
	  the lazy-edge implementation.  I still need to put in a few more
	  pieces to get the detailed timing information we will want,
	  however.

	- I downloaded the latest version of SUIF (well, the last 1.x version)
	  and am trying to figure out how to convert unstructured code to
	  structured code.

	- I've spent some time thinking about the design for moving loads
	  of big static values from uses to defs.  Matthai needs this for
	  OpenGL, and it would be good to do this, in general.

I will put together a web page for the PLDI paper that includes what we've
discussed so far (slant, to-do lists, experiments, etc.), and a link to my
study writeup.

--Brian

To: spin-comp@cs
Subject: commit of new merger
Date: Thu, 16 Jul 1998 12:34:11 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

I just committed the new merger.  It is run by default.  To run the old merger,
give "-p old" as a dcmake option, or put it in your rt-args file.

The new merger passes all regression tests except chebychev and query.
Those don't look like they'll be difficult to fix, but I'll probably leave
them for Matthai to figure out.  xvalg now works again, as predicted.

Unfortunately, fft still doesn't work.  I noticed that it was annotated
improperly, however, and I'm still futzing with it.  dinero also did not
work.  It apparently requires some functionality still not complete in
the new merger (and that did not exist at all in the old one).  If the
problem looks easy to fix, I'll take a shot at it.  If not, dinero will have
to wait.

I will test the timed versions next, since we were having trouble with those.

--Brian

To: eggers@thistle.cs.washington.edu
cc: spin-comp-archive@cs
Subject: sound apps of FFT (audio filters)
Date: Thu, 16 Jul 1998 12:37:50 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

FYI, the Mac app I came across was called SoundHack.

A couple types of filters:
	binuaral filter (makes stereo stream from a mono stream)
	spectral mutation (no clue what it does)

Some sites also mentioned that FFT was used for "spectral analysis" of
audio streams.  One site mentioned that the SETI project uses an FFT-based
spectral analyzer or some kind of filter to produce sound from radio waves
(ala "Contact", I suppose), but I didn't find the source code.

--Brian

Date: Thu, 16 Jul 1998 14:28:45 -0700
From: eggers@yakima (Susan Eggers)
To: spin-comp@cs
Subject: notes from ISCA

Just thought I'd pass on the good news I heard at ISCA which is that
Monica Lam is doing some dynamic compilation on OpenGL.  One of the
graphics faculty came to her with the problem.

This should light a very bright fire under Matthai's fanny...

Susan

To: matthai@thistle.cs.washington.edu
cc: spin-comp-archive@cs
Subject: chebychev and ppmdither now work, noop pads
Date: Thu, 16 Jul 1998 15:33:29 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

chebychev:

The assembler didn't permit two identical "bis" noops to be back-to-back.
It removed one.  Thus, when the merger copied three instructions, the last
one was not a noop.  The fix was to make the second noop a "cpys" noop.

It seems that this business of copying 2-3 instructions for every load
or store, when most translate to only one instruction, will produce many
more instructions than necessary.  I thought of the following sceme (and
tested it in order to find this bug!).

Copy everything (macro and data definitions) preceding ".text" to a new file.
Also copy ".extern" declarations that could appear later in the .pms file.
(I don't know what that happens.)  Then, build the following program,
inserting the instruction we want to assemble.

	.align	5
_$asm_format_string:
	.byte	91
	.byte	37
	.byte	48
	.byte	56
	.byte	120
	.byte	93
	.byte	32
	.byte	91
	.byte	37
	.byte	48
	.byte	56
	.byte	120
	.byte	93
	.byte	32
	.byte	91
	.byte	37
	.byte	48
	.byte	56
	.byte	120
	.byte	93
	.byte	10
	.byte	0
.text
	.ent	main
	.globl	main
main:
	br	10f
	.set noreorder
5:	#################   PUT ST/LD INSTRUCTION HERE!!!!
	bis	$31,$31,$31
	cpys	$f31,$f31,$f31
	.set reorder
10:	lda	$16,_$asm_format_string
	ldl	$17,5b
	ldl	$18,5b+4
	ldl	$19,5b+8
	jsr	$26,printf
	br	$26,FAKE1
FAKE1:	ldgp	$gp,0($26)
	or	$31,$31,$16
	jsr	$26,exit
	br	$26,FAKE2
FAKE2:	ldgp	$gp,0($26)
	ret	$31,($26),1
	.end

This program copies the assembled three instructions at label 5, as
we are currently doing at run time, and prints them out.  For each
store or load we might need to pad we:

1) Build such a program
2) Compile it
3) Run it
4) Insert lda's for the assembled instructions (non-noops) instead of
   copying them.

What do you think?  For just one store/load, this was pretty fast.  I'm
not sure how much it would slow down the merging process, but it would
probably be acceptable.

--Brian

To: spin-comp@cs
cc: melody@thistle.cs.washington.edu
Subject: Frame 5.5
Date: Tue, 21 Jul 1998 11:29:08 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

Frame5.5 is installed on the Suns, and SGIs now too!  Set FMHOME to
/var/mnt/Frame5.5/ and add /var/mnt/Frame5.5/bin to your path IN FRONT OF
/usr/local/bin (which still links to the old version), or make an alias
for /var/mnt/Frame5.5/bin/maker.  The Sun version only works on Suns running
SunOS 5 (e.g., lillith), however, and not the Sun4 machines (manastash, ozette,
etc.).

Thanks, Melody!
--Brian

Date: Fri, 31 Jul 1998 14:00:28 -0700
From: eggers@yakima (Susan Eggers)
To: spin-comp@cs
Subject: PLDI paper thoughts

Below is our current thinking on the content of the PLDI paper.  This
is a result of random brainstorming rather than carefully planning out
the paper. The decision of which topics we'll actually include in the paper
will depend heavily on what the results are.
Please feel free to add to this and let's discuss it at a group meeting.

The paper will of course include bottom line performance (asymptotic
speedups on our programs) and stress that we compile "real" programs.

The heart of the paper will be an analysis of DyC's features:
(1) what features brought the best performance and why
(2) what features didn't contribute much to performance and why
(3) how prevalently are features used in our workload & why the infrequently
used features were so infrequently used
(4) what features were crucial for certain applications (but maybe not used
much in others)
(5) is there a synergy between certain features in the sense that when they
are applied together the performance benefits are greater than summing the
benefit we get when we use them one at a time.  An example of this might
be: 	single-way loop unrolling
	register actions
	combine both (might get extra milage out of having accesses to the 
		array elements run-time constants, which would most likely
		happen only if the loop were unrolled)
(6) evaluate the features wrt their implementation difficulty:
	what features were so trivial to implement that one would always
		want to include them
	what features had so complicated an implementation that one might
		consider omitting them, even though they bring performance
		benefits
	what features worked at odds with how most compilers are implemented
		or view the outside world

		
Perhaps we could categorize the features in different ways when we
examine them.  Possible categorizations are:
(1) normal PE features and our new ones
(2) discuss features independently if we can, discuss together those
features that enable other features, such as polyvariant specialization
enables single and multi-way loop unrolling and specialization after a
merge
(3) those that are the same as or different from other DC systems (Tempo/`C)


A discussion in which we broaden our results to dynamic compilation in
general, rather than simply in the context of DyC.  Some issues might be:
	when might some features not bring good performance in other systems
	when might they bring better performance
	what underlying framework do you need to have a particular feature


Ways in which we could categorize the programs when we discuss them.  We 
could use the categories to show that:
	we've covered a lot of different kinds of applications
	we've covered key application areas and have several examples in each
Possible categories are:
	by what the application actually does (machine simulators, language
		interpreters, etc.)
	by what the application specializes on
		(dinero specializes on cache configuration parameters and
		caching policies, mipsi specialies on the input program
		being simulated)
	kernel apps and "real" programs
Discuss what other programs that we didn't evaluate fall into these
	categories to show that they are major categories.


A discussion of how our results would change
	if we had additional features such as function-level optimizations
		that allow us to specialize functions wrt their arguments
		or dynamically inline functions, or more dynamic features
		along the lines of dynamic copy prop or register actions
	if we had added optimizations that would reduce the dynamic
		compilation overhead


In which directions do our results point us for future work?


A section on the methodology we used to pick our dynamic regions and static
variables.
To what extent does this bias our results, if at all?
What other regions/variables could we have chosen?


When we discuss the various caching options, we'll support that analysis
with a table that shows:
	how often only one version was needed
	how often multiple versions were needed
	how often we reused a version


We're completed a design of most of the experiments.  We'll send that out
when it's done, but we'll not think too hard about it again until Brian has
more of the applications completed.

To: spin-comp@franklin.cs.washington.edu
Subject: Specification of run-time copy prop phase
Date: Tue, 04 Aug 1998 13:44:50 PDT
From: Matthai Philipose <matthai@franklin.cs.washington.edu>

Hi all,
Unfortunately, I cannot come to today's meeting because my mother is 
showing up by an earlier flight than expected, for a visit to Seattle.

Here's what I did last week:
1) The interpreter code in Mesa/OpenGL seems to be working. I haven't 
yet taken a look at the assembler to see exactly how much better the 
code produced is. I hope to do this and mail around an evaluation of 
what our system achieves sometimes tomorrow.
2) I helped Brian set up the three computers (took most of Thursday, 
some of Friday). Brian can tell you more about it... helped in the 
heavy lugging and wiring up, but Brian has been busy setting up with 
the software on themachines too.
3) I came up with a spec for the run-time copy propagation phase, 
which I have appended below. I have discussed it with Brian, so he 
should be able to provide clarifications if needed. It took me a 
while to understand everything, which is why I didn't mail the 
write-up earlier.

After quickly making sure that the interpreter is doing what we want 
it to do, I will move on to the specialized shader. If that works, 
and after munging feedback on the runtime copy-prop spec below, I 
will implement the run-time copy/zero prop pass (most likely in the 
merger).

Sorry for taking off at short notice!
                     Matthai


=====================================
Copy-propagation and constant (zero) propagation during run-time
specialization:

1. Introduction and motivation:
Until now, DyC has performed constant propagation at static 
compile time (in the BTA), and folding at run-time. It turns out that
the run-time constant folding exposes further opportunities for
constant propagation and folding, and copy-propagation. In some
situations (such as while specializing floating-point code), it is
critical to exploit these additional oppportunities to get any benefit
at all from run-time specialization. The sections below examine the
need for these additional phases and discuss how they may be
implemented.  

Consider the following fragment of code:
	r1 = r2 + rtc0
	r3 = r4 * rtc1
	r5 = r1 * r3
	..use of r5...

The r_i stand for registers, and the rtc_i stand for runtime
constants. 

1.1. The need for copy propagation at specialization time: 

Now consider specializing this fragment of code for the values
(rtc0, rtc1) = (0,1). In our current framework, i.e. with only
strength-reduction performed at run-time, the specialized code
produced will be: 
	r1 = r2	
	r3 = r4
	r5 = r1 * r3
	..use of r5...
	
In the case that the arithmetic operations are more expensive than a
copy operation, the above specialization is a win. For integer
operations on th DEC Alpha 21064, for instance, the copy operation
takes one cycle, and the * operations takes 23 cycles, so that the
latency of the  first piece of code is 47 cycles, vs. 25 for the
second fragment of code.  

However, if all the above operations were of the same latency (say 6
cycles each, as in the floating-point pipeline for the 21064), the
specialized version of the code is no faster than the original
version. In other words, it is impossible to replace any operation 
with 
one of smaller latency in the 21064's float pipeline;
stregth-reduction alone is ineffective. Consider, however, the code
produced if copy-propagation were applied to the specialized code
above; the resulting code would be: 
	r5 = r2 * r4
	..use of r5...
This fragment potentially saves seven cycles over the old specialized
version. 

Note that the question of whether the first two operations are copies
or not can be answered only at specializaton time. Although it is
possible to statically identify operations that _could_ become copies 
at
run-time, and the consumers of these operations, the transformation 
of 
code (i.e. removal of copy operations and modification of consuming
operations) needs to be performed conditionally at 
specialization-time 
(i.e. while the program is running). In other words, part of the
analysis can be done statically, but it has to  be completed (and 
code-
transformations performed) only at runtime. 

1.2 The need for constant propagaton/folding at specialization time:
What if we were specializing for (rtc0,rtc1) = (30,0)? With pure
strength-reduction, we would have:
	r1 = r2 + 30
	r3 = 0
	r5 = r1 * r3
	..use of r5...

Once again, for floating-point numbers on the 21064, this
specialization yields no benefit. If we performed constant 
propagation 
and folding on this code, however, we would get the following faster
piece of code:
	r1 = r2 + 30	
	...uses of r5 replaced by uses of zero-register...
Of course, dead-code elimination at this phase could eliminate even
the add operation above.

2. Implementation
We want to implement the copy and zero-propagation phases as a single
non-iterative, non-backtracking, peephole pass over the basic blocks
produced at specialization time. The basic structure of the pass was
to come from Markus Mock's adaptation of David Wall's register actions
idea. 

Register actions provide a one-pass non-iterative, non-backtracking 
peephole
implementation of register allocation. Recall that register 
allocation 
ordinarily requires an IDFA for determining live-ranges, a
linear scheme for determining interference among live ranges and a
final single pass allocating non-interfering live ranges to the same
register. The Wall scheme performs the first two steps at
intraprocedural compile time, leaving only the final flow insensitive 
allocation pass to linktime. 

In the run-time array-allocation variation of the problem that Mock
addresses, neither the live-ranges nor the structure of the graph on
which allocation should take place are computable statically, in
general. This information can only be computed accurately at
specialization time, when the value of array indices and the structure
of the graph being optimized are explicit. In order to avoid an
iterative analysis to compute this information at specialization 
time, 
Mock assumes conservatively that all live-ranges interfere and
allocates exactly as many array locations at run time as there are
registers available. At specialization time, when an array location 
is 
being register allocated, the only datastructure consulted is a table 
which maps array indices to the registers they are allocated to. A
single fixed table applies to the whole function. The information 
being
propagated is therefore flow-insensitive.

2.1 Copy Propagation 
Conventionally, copy propagation has two analyses associated with
it. Recall that a copy x=y is propagated to subsequent uses of x iff: 
1a. The copy is the only reaching def of the use, and
1b. y is not re-defined on any path between the copy and any of the
uses of x that statisfy a.

The code-transformation related to propagation has two aspects:
2a. The copy statement is removed.
2b. All uses of x that satisfy 1a above are replaced by uses of y.

Of course, the analyses phases that verify conditions 1a and 1b are
implemented typically  as IDFAs. We need to perform as
much of the analysis as possible at static compile time, leaving only
a non-iterative, peephole, combined analysis and transformation pass
to run time. Note that the amount of analysis we can perform
statically is limited, in general, by the fact that we do not
know the identity of the copy statements, nor (sometimes) the
structure of the graph  on which propagation will occur, at static
compile time. In what follows, we first determine what
specialization-time actions we would like to perform at which
operations, and then devise a static analysis that identifies the
relevant operations and conditions for actions on them.

The two actions we would like to take are just 2a and 2b;
3a.	REMOVE_COPY(r1,r2,rtc) removes the current copy 
3b.	REPLACE_COPIES(r2,r3) replaces operand registers r2 and r3 with
live copy registers ri,rj iff the copy ri=r2 or rj=r3 is being
propagated.  

As for the conditions under which the actions should be executed:

4a. The REMOVE_COPY action should only be performed on a potential
copy  operation if: 
	4a.1: The operation is indeed a copy (i.e. for operation
add r1,r2,rtc1, if rtc1 == 0; and for operation mul r1,r2,rtc1, if
rtc1 == 1) 
	4a.2: Static analysis has determined conservatively that (for
copy r1 = r2), the live range of r1 is contained in the live range of
r2; i.e. that conditions 1a and 1b above hold. 

4b. The PROPAGATE_COPY action should be performed on an operation
OP r1, r2, r3 that uses the result of a potential copy (s: r1 == r2) 
if:
	4b.1	The REMOVE_COPY operation was successfully applied to the
statement s. 


4a.1 and 4a.2 give rise to a clean and appealing division between
run-time and compile-time responsibilities. The static analaysis will
only place REMOVE_COPY action annotations on potential copies that
satisfy the range-containment condition. As long as the run-time CFG 
is 
known statically with a fair degree of accuracy (as is generally the
case, for instance, in the absence of run-time loop unrolling), 
static 
analysis should be able to do a good (i.e. aggressive) job of placing
the REMOVE_COPY and PROPAGATE_COPY actions. Note that the static
analysis would only produce a PROPAGATE_COPY annotations for uses of
potential copies that it decides to  mark with a REMOVE_COPY.


Finally, there is the detail of propagating information on whether a
particular potential copy was indeed a copy. This information is set
as part of the REMOVE_COPY action, if the related condition (as
described in 4a.1 above) holds. A single global "valid copies" table
that maps registers onto other registers should suffice for this
purpose. While processing any given program point, if the copy r1=r2
is active, the map r1->r2 is inserted  in the table. In order to
reset the entry for a copy r1=r2, static analysis needs to insert a
RESET_COPY action at the first point (or set of first points)
downstream of the REMOVE_COPY that re-defines r1 or r2. RESET_COPY(r1)
resets the entry for r1 in the valid copies table. 


Example:

	L1:	<op1>	bgt r1,L2			
		<op2>	add r1,r2,rtc1
		<op3>	mul r3,r4,rtc2
		<op4>	mul r8,r9,rtc3
		<op5>	add r7,r1,r3
		<op6>	add r9,r9,1	
		<op7>	mul r4,r8,r3	
		<op8>	br L1	
	L2:
		...


The actions produced are:
		op2:	RESET_COPY(r1);REMOVE_COPY(r1,r2)	run-time condition: rtc1==0
		op3:	RESET_COPY(r3);REMOVE_COPY		run-time condition: rtc2==0
		op4:	No remove copy here, since r9 is re-defed (op6)
			before a use of r8 (op7) 
		op5:	PROPAGATE_COPY(r1,r3)			valid_copy[r1], valid_copy[r3]
		op7:	PROPAGATE_COPY(x,r3)			valid_copy[r3]

Note valid_copy[ri] checks if there is a valid entry for ri in the
valid_copy table.


2.2 Zero-propagation
To be specified.


To: spin-comp@franklin.cs.washington.edu
Subject: reminder to read copy-prop actions description
Date: Thu, 06 Aug 1998 11:30:58 PDT
From: Matthai Philipose <matthai@franklin.cs.washington.edu>

Folks,
Just a reminder to read the description of the run-time copy-prop 
phase in time for next Tuesday's meeting. I will probably begin 
implementing the phase around then, so it'll be good to settle the 
details by then.
		Thanks,
		Matthai

To: matthai@thistle.cs.washington.edu
cc: spin-comp-archive@cs
Subject: assembly macros
Date: Fri, 07 Aug 1998 15:44:40 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

Cases in which it would be useful to know that a symbol is a macro:

1) ld/st
	The common case is ld/st from/to some offset from the sp, where
	the offset is a macro.  We should only be copying one instruction
	in this case, not three.

2) arithmetic operations
	It would be easier to recognize symbols in immediate fields and
	we could do more error checking.

Maybe others...

--Brian

Date: Fri, 7 Aug 1998 16:28:03 -0700 (PDT)
From: chambers@klamath (Craig Chambers)
To: spin-comp@cs, compilers@cs, cse590k@cs
Subject: PFDC PACT Workshop

FYI, here's an announcement for a workshop that you may be interested in.

-- Craig Chambers


-------------------------------------------------------------------
        Workshop on Profile and Feedback-Directed Compilation

         In Conjunction with the International Conference on
    Parallel Architectures and Compilation Techniques (PACT 98)

                  Paris, France October 13, 1998


This workshop is intended to be a forum for bringing together
researchers in the area of feedback-directed compilation and
optimization. Talks will be solicited emphasizing new ideas and
experience with building feedback-directed systems. There will be a
limited number of talks in order to allow the audience to
participate. The topics of interest include, but are not limited to:

   * Analysis to estimate program behavior
   * Profile techniques to measure program behavior
   * Techniques for estimating the benefit of optimization
   * Program analysis based on measurements, estimates, or program behavior
   * Compiler optimization based on measurements, estimates, or program
     behavior
   * Adaptive execution, dynamic compilation and continuous
     profiling/optimization
   * Behavior analysis and optimization to improve memory hierarchy
     performance (e.g., cache-conscious data structures)
   * Experiences with real systems

There will be no published proceedings. However, workshop attendees
will receive copies of the papers. We chose not to seek publication of
the workshop proceedings to allow papers to more easily be published
in a later conference or journal.

Submission Guidelines: Talks will be accepted on the basis of a short
abstract that describes the work and the novel algorithms or
experiences that resulted from it. Email a ghostviewable PostScript 5
page abstract uuencoded to pfdc@cs.ucsd.edu by August 21st. Send email
if these requirements are a hardship. At the top of the email
submission (in text) include (1) title of paper, (2) list of authors,
(3) email and phone number of contact author, and (4) a 200 word
summary of abstract. In addition, include the contact information on
the title page of the abstract. You should receive a notification of
your submission by the following week.  Authors will be notified of
acceptance or rejection by September 5th, and the final abstracts are
due September 25th.


Deadlines:

5 Page abstract due by Aug. 21, 1998

Notifications by Sept. 5, 1998

Final abstracts (maximum of 10 pages) due Sept. 25, 1998

Questions: pfdc@cs.ucsd.edu

For current information see: 
http://www-cse.ucsd.edu/users/calder/pfdc/index.html


Workshop Co-Chairs: Brad Calder, Rajiv Gupta, and James Larus

Program Committee:

Brad Calder         UC, San Diego       calder@cs.ucsd.edu
Craig Chambers      U. of Washington    chambers@cs.washington.edu
Evelyn Duesterwald  Hewlett Packard     duester@hpl.hp.com
Jesse Fang          Intel               jfang@riddler.sc.intel.com
Rajiv Gupta         U. of Pittsburgh	gupta@cs.pitt.edu
James Larus         Microsoft Research  larus@microsoft.com
Mike Smith          Harvard University  smith@eecs.harvard.edu

To: matthai@thistle.cs.washington.edu, mock@thistle.cs.washington.edu
cc: spin-comp-archive@cs
Subject: links to change
Date: Mon, 17 Aug 1998 11:34:02 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

I couldn't change the links that scc follows to your versions
of the compiler.  You'll have to change them to the new paths.

ln -s /projects/DyC_Homes/matthai/DyC/bin/rcc \
	/projects/trace1/mflow/usr/vssad/release/matthai/bin/rcc
ln -s /projets/DyC_Homes/matthai/DyC/mflow/ccom/ccom \
	/projects/trace1/mflow/usr/vssad/release/matthai/lib/ccom

Markus, yours are similar.

--Brian

To: spin-comp@cs
Subject: we're back in business, baby!!
Date: Mon, 17 Aug 1998 11:39:30 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

Port to the new machines is complete.  Boy, these new machines
are FAST!  All of Multiflow now builds in about 10 minutes.  Just
linking used to take that long...

--Brian

+++ Application binary passed
+++ Application binary-lazy passed
+++ Application chebychev passed
+++ Application dinero passed
+++ Application dotproduct passed
+++ Application extend-context passed
+++ Application float-demotions passed
+++ Application float-holes passed
+++ Application float-int passed
+++ Application float-unroll passed
+++ Application hsh passed
+++ Application int-unroll passed
+++ Application interpreter passed
+++ Application interpreter-regs passed
+++ Application loop-lazy passed
+++ Application mipsi passed
+++ Application multiunit-all passed
+++ Application multiunit-lazy passed
+++ Application multiunit-promote passed
+++ Application multiunit-rep passed
+++ Application multiunit-unchecked passed
+++ Application polydiv passed
+++ Application polydiv2 passed
+++ Application pow passed
+++ Application promote1 passed
+++ Application query passed
+++ Application romberg passed
+++ Application rt-merge passed
+++ Application side-effects passed
+++ Application stack passed
+++ Application static-branch passed
+++ Application static_switch passed
+++ Application two-entries passed
+++ Application unchecked passed
+++ Application unchecked-trivial passed
+++ Application unroll1 passed

*** All 36 applications passed! ***


Date: Mon, 17 Aug 1998 11:54:22 -0700 (PDT)
From: chambers@klamath (Craig Chambers)
To: spin-comp@cs, grant@cs.washington.edu
Subject: Re: we're back in business, baby!!

Congratulations!!  I know it's been a long, painful road, but now you can
enjoy the fruits of your labors.

-- Craig

Date: Mon, 17 Aug 1998 12:03:37 -0700
From: eggers@yakima (Susan Eggers)
To: spin-comp@cs, grant@cs.washington.edu
Subject: Re: we're back in business, baby!!


Excellent!  Thanks to both of you for getting them up and running.
How nice to finally be back to research.

Susan

To: Markus Mock <mock@cs.washington.edu>
cc: spin-comp-archive@cs, matthai@thistle.cs.washington.edu
Subject: Re: links to change 
Date: Tue, 18 Aug 1998 11:32:40 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

>> On which machine can I do this? /projects/DyC_Homes is not visible on my
>> machine. What are the names of the new Alphas?

You can do this on the new machines: alper, wu, and robscheit.  Your
directory is actually on wu, so you may want to run there.

There are other things you need to do to rebuild on the
new machines (if you use bash, you should be able to cut and paste this):

export CVSROOT=/projects/DyC_Home/DyC
cd /projects/DyC_Homes/mock/DyC
cvs update -d
. bin/set-paths
unset DYC_USR_INCLUDE_ALPHA_DIR
export PATH="${PATH}:${MFLOW_BIN}:${DYC_BIN_DIR}:${DYC_HOME}/bin"
rm mflow/*/*.o bin/rcc lib/*.[ao]
cd mflow
do_make
cd ../regression
touch */*.DyC
rt

--Brian

To: spin-comp@thistle.cs.washington.edu
Subject: yeah! speedup for dinero
Date: Fri, 21 Aug 1998 10:57:33 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

Caveats:
	-- The strength reduction I've put in is at the source-code level
	-- Not all strength reduction opportunities are being exploited
	-- These times are whole-program-execution times and include I/O
	-- These times were collected on the new machines

Given that, I just thought I'd spread some happy news:

On robscheit:

Statically compiled Multiflow version:

real   1.7
user   1.7
sys    0.0

Dynamically compiled version:

real   1.2
user   1.2
sys    0.0

That's 1.42x speedup.  Woo hoo!

More good news: The executables built on the new machines seem
to run on the old machines.  I'll try to compare with ones
built on the old machines to see if there is any difference.

On meitner:

Statically compiled Multiflow version:

real   12.8
user   12.3
sys    0.2

Dynamically compiled version:

real   8.4
user   8.2
sys    0.1

That's 1.5x speedup!!!!

--Brian

ps. Note the time difference between the new and old machines!!!

Date: Fri, 21 Aug 1998 11:26:34 -0700
From: eggers@yakima (Susan Eggers)
To: spin-comp@thistle.cs.washington.edu, grant@cs.washington.edu
Subject: Re: yeah! speedup for dinero

This is just great!

Date: Fri, 21 Aug 1998 12:44:35 -0700 (PDT)
From: Markus Mock <mock@cs.washington.edu>
To: spin-comp@cs.washington.edu
Subject: HP, UIUC & NYU RELEASE EPIC COMPILER RESEARCH INFRASTRUCTURE (fwd)

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.
  Send mail to mime@docserver.cac.washington.edu for more info.

---2141257399-906300505-903728345=:3235
Content-Type: TEXT/PLAIN; CHARSET=us-ascii
Content-ID: <Pine.SOL.3.96.980821120317.23091F@bloch>

check out:
	http://www.trimaran.org/
	
	-- Markus
	

---2141257399-906300505-903728345=:3235
Content-Type: TEXT/PLAIN; NAME="artread.txt"; CHARSET=us-ascii; X-UNIX-MODE=0644
Content-ID: <Pine.SOL.3.96.980821120317.23091G@bloch>
Content-Description: artread.txt

                                 [MAXSTRAT]
                      [Image]

HP, UIUC & NYU RELEASE EPIC COMPILER RESEARCH INFRASTRUCTURE

SCIENCE AND ENGINEERING NEWS

[Image]
08/21/98

Palo Alto, CA -- Hewlett-Packard Company, the IMPACT compiler group at the
University of Illinois at Urbana-Champaign, and the React-ILP Laboratory at
New York University in New York City released the Trimaran EPIC (Explicitly
Parallel Instruction Computing) compiler research infrastructure to the
academic community.

The infrastructure is expected to facilitate instruction and research in
EPIC technology and to lower the barrier to entry for research and
instruction in this field greatly. It also is expected to help universities
participate in development of EPIC compiler technology. IA-64 (Intel
Architecture 64-bit), Intel's next-generation microprocessor platform, is
based on EPIC technology, co-developed by HP and Intel.

HP Labs has been developing EPIC compilers since 1989 in the company's
Compiler and Architecture Research group and as part of the PA-WideWord
program. Extensive compiler research has continued at HP Labs and through
cooperative efforts with the University of Illinois and New York University.
The research infrastructure produced through these cooperative efforts is
available free of charge at http://www.trimaran.org to universities
interested in studying EPIC compilers.

The Trimaran team is helping universities overcome financial barriers to
establishing EPIC compiler research programs by providing a research
infrastructure at no cost. While many universities have infrastructures for
superscalar and multiprocessor research, most are just beginning to study
next-generation EPIC technology. HP believes that extensive research will
produce significant gains in EPIC compiler technology and help realize the
tremendous performance potential of EPIC architectures. HP intends to
continue its own compiler research as well.

HP's Compiler and Architecture Research group is headed by B. Ramakrishna
Rau, who holds a doctorate in electrical engineering. Professor Wen-mei Hwu
heads the University of Illinois' IMPACT compiler group, and Professor
Krishna V. Palem leads the React-ILP Laboratory at New York University.

"Years of EPIC compiler research enable HP to provide this information to
the academic community while maintaining a significant edge in designing
IA-64-based systems with the highest performance levels," said Bill Russell,
HP vice president and general manager of the Enterprise Systems Group.
"Continuing our innovation in advanced compiler technology and fostering a
strong research infrastructure for the academic community reinforces HP's
commitment to driving the broad adoption of IA-64 technology. The expertise
and knowledge HP has gained in co-developing EPIC positions the company to
deliver systems that realize the full potential of IA-64 technology."

EPIC, the foundation of the 64-bit Instruction Set Architecture (ISA), uses
predication, speculation, explicit parallelism and other qualities specific
to EPIC technology to deliver superior processing performance and inherent
scalability not available with conventional RISC architectures. EPIC
compilers use access to architectural information and control over processor
execution to expose, exploit and orchestrate opportunities for parallelism
within an application, thus extracting maximum speed and performance from
EPIC/IA-64 systems. HP expects EPIC/IA-64 systems to offer significant
advantages over existing computing platforms.

For more information visit http://www.hp.com and
http://www.crhc.uiuc.edu/Impact/ and http://react-ilp.cs.nyu.edu/

------------------------------------------------------------------------

Our Sponsors:

     Silicon Graphics Inc. [Image]IBM Corp. [Image]Sony [Image]MAXSTRAT

 Digital Equipment [Image]HP/Convex Tech. Center [Image]NEC [Image]Portland
                                   Group

                Fujitsu [Image]Eudora [Image]HAL [Image]SUN

    Raytheon Systems [Image]Northrop Grumman DSSD [Image]NAG [Image]QSW

              Dolphin Interconnect Solutions, Inc. [Image]Tera

                     [Previous][Table of Contents][Next]

---2141257399-906300505-903728345=:3235--

To: matthai@thistle.cs.washington.edu, mock@thistle.cs.washington.edu
cc: spin-comp-archive@cs
Subject: gdb
Date: Mon, 24 Aug 1998 22:26:01 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

I rebuilt gdb with the annoying warning eliminated.  It
may or may not have been necessary.  I realized that I
was running the old gdb from /uns/bin, which preceded
$DYC_HOME/bin in my path.  You probably want to put
$DYC_HOME/bin before /uns/bin in your path only on the
new machines.

--Brian

Date: Tue, 25 Aug 1998 14:24:23 -0700
From: eggers@yakima (Susan Eggers)
To: spin-comp@cs
Subject: meeting

I forgot to put a day pass on my car windshield, so I have to go back
to the parking lot.  It will only take me a sec -- just come on in.

Susan

To: spin-comp@franklin.cs.washington.edu
Subject: some trivia: IEEE-floating point on the alpha
Date: Tue, 25 Aug 1998 16:19:35 PDT
From: Matthai Philipose <matthai@franklin.cs.washington.edu>

Turns out that the in-register representation of an IEEE fp number is 
different from the in-memory representation, on the alpha. 

The in-memory representation is the conventional IEEE one (I think):
	Single Precision:
		sign(bit 31) exponent(bits 30-23) fraction(bits 22-0)
	Double Precision:
		sign(bit 63) exponent(bits 62-52) fraction(bits 51-0)


The in-register formats (remember alpha regs are 64-bit) are:
	Single Precision:
		sign(bit 63) exponent(bits 62-52) fraction(bits 51-32) zeroed(bits 
31-0)	
	Double Precision:
		same as in-memory format

The exponent is automatically expanded and compressed when 
loaded/stored from/to memory to register, in the single-precision 
case.

		Matthai


Date: Tue, 25 Aug 1998 17:11:13 -0700 (PDT)
From: chambers@klamath (Craig Chambers)
To: spin-comp@franklin.cs.washington.edu, matthai@cs.washington.edu
Subject: Re: some trivia: IEEE-floating point on the alpha


> From matthai@franklin.cs.washington.edu  Tue Aug 25 16:19:38 1998
> Delivery-Date: Tue, 25 Aug 1998 16:19:39 PDT
> X-Mailer: exmh version 1.5.3 12/28/94
> To: spin-comp@franklin.cs.washington.edu
> Subject: some trivia: IEEE-floating point on the alpha
> Reply-to: Matthai Philipose <matthai@cs.washington.edu>
> Mime-Version: 1.0
> Date: Tue, 25 Aug 1998 16:19:35 PDT
> From: Matthai Philipose <matthai@franklin.cs.washington.edu>
> 
> Turns out that the in-register representation of an IEEE fp number is 
> different from the in-memory representation, on the alpha. 
> 
> The in-memory representation is the conventional IEEE one (I think):
> 	Single Precision:
> 		sign(bit 31) exponent(bits 30-23) fraction(bits 22-0)
> 	Double Precision:
> 		sign(bit 63) exponent(bits 62-52) fraction(bits 51-0)
> 
> 
> The in-register formats (remember alpha regs are 64-bit) are:
> 	Single Precision:
> 		sign(bit 63) exponent(bits 62-52) fraction(bits 51-32) zeroed(bits 
> 31-0)	
> 	Double Precision:
> 		same as in-memory format
> 
> The exponent is automatically expanded and compressed when 
> loaded/stored from/to memory to register, in the single-precision 
> case.
> 
> 		Matthai
> 
> 

Wow, that's really cool.

-- Craig

To: spin-comp@thistle.cs.washington.edu
Subject: bug fix in reachability analysis; BIG speedup in mipsi
Date: Fri, 28 Aug 1998 14:45:39 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

I found a bug in reachability conditions that caused some static
merges to not appear static.  The result in mipsi was that derived
static variables that contributed to the pc were being killed and
the pc had to be promoted.  This promotion happened every time a
branch was encountered in the interpreted program (even unconditional
ones).

With the bug fixed, compilation of mipsi takes a long, long time,
even on the new machines.  Reachability conditions reach nearly 8000
clauses for some program points.  However, the merges that should be
static are static.

Now, the good news:

	Speedup of a sorting program
		 over Mflow:		3.13
		 over cc -O4:		2.56

Woo hoo!!!

Caveats:
	Mostly the same as for dinero (this is on the new machines,
	not linked with our optimized libraries, whole program times,
	etc.)

--Brian

Date: Fri, 28 Aug 1998 14:59:00 -0700
From: eggers@yakima (Susan Eggers)
To: spin-comp@thistle.cs.washington.edu, grant@cs.washington.edu
Subject: Re: bug fix in reachability analysis; BIG speedup in mipsi


Fantastic!

Date: Tue, 1 Sep 1998 15:24:57 -0700
From: eggers@yakima (Susan Eggers)
To: spin-comp@cs
Subject: grep and gawk

"Detailed profiling of grep and gawk revealed that both spend a
significant portion of their time in the bmexec() and dfaexec()
routines, which implement string search routines in loops with long
dependence chains. For both benchamrks, value prediction is frequently
able to break these dependence chains, resulting in significant
additional parallelism."
from Lipasti and Shen's value prediction paper in Micro96

grep had much larger speedups for them, but, as Matthai said, it's
not clear that that translates into large speedups for us.

Susan

To: spin-comp@franklin.cs.washington.edu
Subject: m88ksim preliminary numbers
Date: Wed, 02 Sep 1998 12:32:21 PDT
From: Matthai Philipose <matthai@franklin.cs.washington.edu>

Unix time gives a 16% speedup on m88ksim on the new alphas. The 
--------------
                               user     system
dynamically compiled version: 155.798u 0.221s 
 statically compiled version: 181.712u 0.113s 
--------------
Brian mentions that minimizing the number of callee-save registers 
saved and restored in the multiflow compiled routine on m88ksim could 
increase the relative speedup by a bit.

Right now, we automatically save and restore 16 registers, when we 
probably need to do so for only two registers. Since there's not much 
else in the routine once we're done dynamically compiling, these 
saves/restores have a disproportionate impact. I'd say we may get 
about 2% extra overall speedup from this, but it remains to be seen.

m88ksim has the additional interesting property that we get the 
speedup only if we re-order functions in the static executable (using 
the dec 'cord' utility); so basically, we need to worry about cache 
conflicts between dynamically generated code and static code. Markus 
was the one who discovered this.
            Matthai



To: spin-comp@franklin.cs.washington.edu
Subject: m88ksim blurb: minor correction
Date: Wed, 02 Sep 1998 12:45:41 PDT
From: Matthai Philipose <matthai@franklin.cs.washington.edu>

I mis-spoke when I said m88ksim seems to demonstrate the need to 
worry about conflicts between statically generated code and 
dynamically code.

The cache effects that cord addresses seem to be conflicts between 
the static code and the other static code. The huge size of the 
generating extension, which is executed just once (even though the 
routine it is contained in is one of the most frequently called) 
seems to throw off cache behavior. 

We end up having to direct cord to place the GE at one end of the 
executable, and this seems to help ensure that the remaining 
frequently called procedures don't interfere with each other.

	Matthai

Date: Thu, 3 Sep 1998 11:29:35 -0700
From: eggers@yakima (Susan Eggers)
To: spin-comp@cs
Subject: faculty retreat

I'm deliberately *not* suggesting that the two of you (Matthai and
Brian) be invited to the faculty retreat, because we have something
more important we're working on.

Susan

To: spin-comp@cs
Subject: load hoisting
Date: Sat, 05 Sep 1998 00:42:45 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

Load hoisting works and is committed.  Update bin and mflow.
Currently, it is turned on by default, but I may change that (read on).

I re-timed the microbenchmarks and dinero with load hoisting turned on.
It only affected chebychev (sic) and dinero.  The others don't have any
loads to hoist.  In dinero's case, about twenty explicit table loads are
eliminated entirely rather than "hoisted", because the previous defs are
dynamic.  However, in both chebychev and dinero, performance _decreases_
significantly with load hoisting.  The best speedup for chebychev with
hoisting was 7.7 (compared to 8.7 without), and 1.3 for dinero (1.6 without).
In both cases, _more_ instructions are generated with hoisting turned on,
presumably because of additional spills, though I haven't compared the
generated code yet.

--Brian

Date: Sat, 5 Sep 1998 12:19:10 -0700
From: eggers@yakima (Susan Eggers)
To: spin-comp@cs, grant@cs.washington.edu
Subject: Re: load hoisting

So maybe load hoisting isn't an optimization after all...
Initeresting trade-off.

Susan

Date: Tue, 8 Sep 1998 11:14:31 -0700
From: eggers@yakima (Susan Eggers)
To: spin-comp@cs
Subject: PLDI paper

I've put a first draft of a paper outline in /projects/dyncomp/Papers/PLDI99.

Take a look, so we can discuss it today in the meeting.

Susan

Date: Tue, 8 Sep 1998 11:35:15 -0700
From: eggers@yakima (Susan Eggers)
To: spin-comp@cs
Subject: somethig else for today's discussion

I've also made a first pass at the evaluations that go into the paper.
This was taken from Brian and my discussions on what experiments he
should be doing.

These are in the same dirrectory in a file called 'experiments.doc'.

Susan

Date: Tue, 8 Sep 1998 17:37:31 -0700
From: eggers@yakima (Susan Eggers)
To: spin-comp@cs
Subject: meeting times

Shall we keep our same meeting times for fall quarter?

Susan

Date: Tue, 8 Sep 1998 17:47:25 -0700 (PDT)
From: chambers@klamath (Craig Chambers)
To: spin-comp@cs, eggers@yakima
Subject: Re: meeting times

OK with me so far.

-- Craig


To: spin-comp@cs
Subject: early results
Date: Wed, 09 Sep 1998 11:13:10 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

The current times for the microbenchmarks (ones we reported previously minus
pow) and dinero can be found in:

/projects/DyC_Homes/grant/DyC/results/09-08-98/

Let me know what format you would prefer.

Notes:

In the reported times, I not only dropped the first time, but also the next
worst, since most benchmarks have an outlier in the 8th out of 11 runs.

I used getrusage for total run times and the cycle counter for
dynamic-compilation overhead.  I converted all times to cycles for
calculations.

These times are for "best" configurations, such as unsafe policies.  I'll
work on some simple variations next (such as safe policies).

Previously reported speedups and breakevens can be found on our web page.

binary still uses eager unrolling because of a couple glitches with timing
the lazy version.  It isn't clear that we really need the lazy version for
this study, anyway.

romberg no longer gets speedups comparable to what we previously reported.
I don't yet know why.  Run times for both the dynamically and statically
compiled versions are 20-25% faster than posted times, with the statically
compiled version speeding up more than the dynamically compiled one.

In dinero, one more function could be inlined and one or two small loops
could be unrolled, but I don't think there is any benefit to doing so.
dinero still crashes with these optimizations.  Also, dinero still has
strength reduction implemented at the source-code level.

Current speedup for mipsi is about 3.3x, but the script doesn't work for that
yet.  m88ksim also needs a (different) fix to go through the script.

--Brian

Date: Wed, 9 Sep 1998 11:34:11 -0700
From: eggers@yakima (Susan Eggers)
To: spin-comp@cs, grant@cs.washington.edu
Subject: Re: early results

> I used getrusage for total run times and the cycle counter for
> dynamic-compilation overhead.  I converted all times to cycles for
> calculations.
In the paper I think we should report real time, not cycles.  Maybe cycles
in parens, so that a comparison can be made to the DC overhead.  And then
of course explain why we are using these metrics.  We're not simulating,
we're running on a real machine, and we should keep in that world.
> 
> binary still uses eager unrolling because of a couple glitches with timing
> the lazy version.  It isn't clear that we really need the lazy version for
> this study, anyway.
Maybe we can come back to this, depending on how the experiments go.
> 
> romberg no longer gets speedups comparable to what we previously reported.
> I don't yet know why.  Run times for both the dynamically and statically
> compiled versions are 20-25% faster than posted times, with the statically
> compiled version speeding up more than the dynamically compiled one.
Why don't we just omit romberg for the moment then, or maybe omit period.
> 
> In dinero, one more function could be inlined and one or two small loops
> could be unrolled, but I don't think there is any benefit to doing so.
> dinero still crashes with these optimizations.  Also, dinero still has
> strength reduction implemented at the source-code level.
Maybe these can go on Matthai's ever-lengthning list.

Susan

Date: Wed, 9 Sep 1998 13:29:40 -0700
From: eggers@yakima (Susan Eggers)
To: spin-comp@cs
Subject: prelim results

Brian --

This is what strikes me so far:
(1) I assume best time is lowest execution time, regardless of what the
dynamic compilation overhead is (could also be lowest, may not be)
(2) I'd like to see best and medium times and asymptotic speedups for
both the dynamic region and the entire application.  It would be nice
to have some notion of how important dynamic regions are to performance.
Percentage of time spent in them and the speedup due to DC are ways to
get this.
(3) Best and Medium time in microseconds (presumeably), as well as cycles.
A measure of "real" is not just how many static lines of code these programs
are, but how long they run.  Among other factors.
(4) Here's a first pass at a presentation of results for all the programs.
A bar graph, in which each bar measures speedup over the static version
for a particular application.  Each bar is divided into several colors,
each color representing the contribution in speedup of another feature
we have added.  The more colors, the more features, the greater the speedup.
For example, base in white, the increment from adding single-way loop
unrolling in rightway diagonal lines, then the increment from adding
multiway loop unrolling in leftway diagonal lines, something else in black...
If we did this for execution time, then a bar for the static run would need
to sit beside the dynamic runs.

Susan
and so forth.

To: eggers@yakima (Susan Eggers)
cc: spin-comp@cs
Subject: Re: prelim results 
Date: Wed, 09 Sep 1998 13:42:31 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

>> (1) I assume best time is lowest execution time, regardless of what the
>> dynamic compilation overhead is (could also be lowest, may not be)

Yes.

>> (2) I'd like to see best and medium times and asymptotic speedups for
>> both the dynamic region and the entire application.  It would be nice
>> to have some notion of how important dynamic regions are to performance.
>> Percentage of time spent in them and the speedup due to DC are ways to
>> get this.

Ok.

I can profile the cc/gcc compiled versions of dinero, mipsi, and the other
macrobenchmarks.  I'll double-check whether profiling with Multiflow works.
Profiling the dynamically compiled version would be harder.

>> (3) Best and Medium time in microseconds (presumeably), as well as cycles.
>> A measure of "real" is not just how many static lines of code these programs
>> are, but how long they run.  Among other factors.

No problem to print out seconds.  I'll just divide by 1.34e+8.

>> (4) Here's a first pass at a presentation of results for all the programs.
>> A bar graph...

Sounds good.  Do you want to see raw numbers in addition to graphs?  If so,
what format would you prefer?  Should I just put Multiflow-relative
best and median numbers into a table?

--Brian

Date: Wed, 9 Sep 1998 14:19:43 -0700
From: eggers@yakima (Susan Eggers)
To: eggers@yakima, grant@thistle.cs.washington.edu
Subject: Re: prelim results
Cc: spin-comp@cs


Sounds good.  Do you want to see raw numbers in addition to graphs? 

-- yes

 If so,
what format would you prefer?  Should I just put Multiflow-relative
best and median numbers into a table?

--yes

Susan

About the profiling:  you're already measuring the time to execute
one segment of the program (dynamic compilation overhead).  Can you
not to the same for the dynamic region, and just note how many times
you enter it or accumulate all the times you measure.  This is if the
profilers don't work with MFlow.

Also, Jack has a suite of scripts that create tables and graphs from raw
numbers.  I believe there was some sort of spreadsheet in the middle.
Craig had a similar suggestion as well yesterday.


To: eggers@yakima (Susan Eggers)
cc: spin-comp@cs
Subject: Re: prelim results 
Date: Wed, 09 Sep 1998 14:31:37 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

>> About the profiling:  you're already measuring the time to execute
>> one segment of the program (dynamic compilation overhead).  Can you
>> not to the same for the dynamic region, and just note how many times
>> you enter it or accumulate all the times you measure.  This is if the
>> profilers don't work with MFlow.

DC overhead is easy.  Everything done at DC time is counted as overhead.
And, those timing calls are inserted automatically.

The macrobenchmarks make several function calls from within their dynamic
regions.  It would be a pain to put timing calls around all callees and
subtract out that time and an estimate of the cost of the timing calls
themselves.  Also, the dynamically compiled version may no longer work
if we do that.  Profiling should be much easier, provided that it works.
If not, then this can be a fall-back.

--Brian

Date: Wed, 9 Sep 1998 15:26:25 -0700
From: eggers@yakima (Susan Eggers)
To: eggers@yakima, grant@thistle.cs.washington.edu
Subject: Re: prelim results
Cc: spin-comp@cs


Got it, thanks.

To: spin-comp@cs
Subject: resource limits
Date: Wed, 09 Sep 1998 16:29:57 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

My default resource limits were very low on the new alphas.  This caused
m88ksim to crash and Multiflow to crash when compiling mipsi.  In your .login
or .cshrc, you'll want to raise the limits to the max:

# set limits to the max
limit cputime unlimited
limit filesize unlimited
limit datasize unlimited
limit stacksize unlimited
limit memoryuse unlimited
limit addressspace unlimited

This doesn't really eliminate the limits, but rather sets them to the max
permissible.  If you do this, it should allow you to use all the memory on
the machines.

--Brian

Date: Thu, 10 Sep 1998 12:09:00 -0700 (PDT)
From: chambers@klamath (Craig Chambers)
To: spin-comp@cs
Subject: PEPM'99 CFP (reminder)

FYI.

----- Begin Included Message -----

From types-errors@linc.cis.upenn.edu  Thu Sep 10 09:56:48 1998
Delivery-Date: Thu, 10 Sep 1998 09:56:53 PDT
Date: Wed, 9 Sep 1998 20:27:41 +0200 (MET DST)
From: Olivier Danvy <danvy@brics.dk>
To: types@cs.indiana.edu
Subject: PEPM'99 CFP (reminder)
Reply-to: danvy@brics.dk
Content-Type: text

[----- The Types Forum, http://www.cis.upenn.edu/~bcpierce/types -----]

[Reminder: submission deadline in one month.]

There will be three invited talks at PEPM'99:
- one by Alan Bawden, on quasiquote and unquote;
- one by Charles Consel, on adaptative programming; and
- one by Neil Jones, on challenging problems in partial evaluation.

----------

			     Call for Papers

			 ACM SIGPLAN Workshop on
 Partial Evaluation and Semantics-Based Program Manipulation (PEPM '99)
		 San Antonio, Texas, January 22-23, 1999
		       http://www.brics.dk/~pepm99

	    Submission deadline: Friday 9th of October, 1998.

The PEPM'99 workshop will bring together researchers working in the areas
of semantics-based program manipulation and partial evaluation.  The
workshop focuses on techniques and supporting theory for the analysis and
manipulation of programs.  Technical topics include, but are not limited
to:

   * Program manipulation techniques: program transformation, program
     specialization, type specialization, syntax-directed partial
     evaluation, type-directed partial evaluation, normalization,
     continuations, reflection, rewriting, run-time code generation.
   * Program analysis techniques: abstract interpretation, static analysis,
     binding-time analysis, attribute grammars, constraints.
   * Related issues in language design and models of computation:
     imperative, functional, logical, object-oriented, parallel,
     distributed, mobile, secure.
   * Programs as data objects: staging, meta-programming, incremental
     computation, mobility, tools and techniques, prototyping and debugging.
   * Applications: systems programming, scientific computing, algorithmics,
     graphics, security checking, simulation, compiler generation,
     compiler optimization, decompilation.

Original results that bear on these and related topics are solicited.
Prospective authors should submit papers directly to pepm99@brics.dk to
arrive no later than October 9, 1998.  Authors concerned about the
appropriateness of a topic are encouraged to consult with the program
chair prior to submission.

Papers should be submitted electronically, either in PostScript or as a
self-contained TeX or LaTeX file.  (If this is a problem, please contact
the program chair.)  The PostScript file should be gzip'ed and uuencoded.
Its name should result from the catenation of the names of its authors
(ie, *not* "paper.ps", etc., but, eg, "dupond-dupont.ps.gz",
"brown-al.ps.gz", or "pedersen.ps.gz").  Within reason, submissions
should not exceed 5000 words (about 10 pages), excluding bibliography and
figures.  Final papers may of course be longer.  Excessively long
submissions may be rejected outright by the program chair.  Submissions
should designate a corresponding author and include a mailing address,
phone number, and e-mail address for correspondence.

Submitted papers will be judged on the basis of significance, relevance,
correctness, originality, and clarity.  They should include a clear
identification of what has been accomplished and why it is significant.
Submissions must include an abstract and discussion of related work.
They also must describe work that has not previously been published in a
major forum.  Authors should indicate if a closely related paper is also
being considered for another conference or journal.

Authors will be notified of acceptance by November 23, 1998.  Full
versions of the accepted papers should be formatted according to ACM
conventions, and a camera-ready copy must be received by the program
chair no later than January 5, 1999.  Accepted papers will be presented
at the workshop and will appear in the proceedings, which will be
published by BRICS.  Further information about the workshop is available
in its home page.

Chairperson:
  Olivier Danvy, BRICS, University of Aarhus, Denmark
  E-mail: danvy@brics.dk

Program Committee:
  Kenichi Asai, University of Tokyo, Japan
  Mike Ashley, University of Kansas, USA
  Anindya Banerjee, Stevens Institute of Technology, Hoboken, USA.
  Mayer Goldberg, Ben Gurion University, Israel
  Nevin Heintze, Bell Labs, USA
  Morry Katz, Stanford University, USA
  Michael Leuschel, University of Southampton, UK
  Jacques Malenfant, Laboratoire VALORIA, Universite de Bretagne Sud, France
  Renaud Marlet, IRISA / INRIA, France
  Kristoffer Rose, ENS-Lyon, France
  Peter Sestoft, Royal Veterinary and Agricultural University, Denmark

PEPM'99 is held in conjunction with POPL'99.



----- End Included Message -----


To: eggers@cs
cc: spin-comp-archive@cs
Subject: prelim. results table
Date: Mon, 14 Sep 1998 12:44:34 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

This is a multipart MIME message.

--boundary=_0
Content-Type: text/plain; charset="us-ascii"
--------
Jack has told me where his scripts are, but I haven't had time to look
at them yet.  He said most are specific to his output formats.  He used
xmgr to generate MIF graphs.  I haven't used that tool before, so it will
take me a little while to learn how to use it.

Meanwhile, I have put the results into a text file (also included below):

/projects/dyncomp/Papers/PLDI99/results/table.txt

For now, results were computed from best times.  Median times are not yet
there.  Also, actual run times are not there, only speedups, etc.

Note about strength reduction & dotproduct:
	We had been timing against a version that checked for zero in source
code because the test helps the statically compiled versions as well.  However,
when we eliminate strength reduction, we must compare against a version without
the test.  Therefore, we should probably always compare against a version
without the test.  If we compare to other systems, we can provide the speedup
against the version with the test as well.  I think Tempo timed theirs that
way.  I believe `C compared against a statically compiled version without
the test.

In dinero, we're comparing against a static version with no tests for special
cases.  Perhaps I should also run once to see if the statically compiled
version would also speedup with the strength reduction.

--Brian
--boundary=_0
Content-Type: text/plain; charset="us-ascii"
Content-Description: table.txt

Benchmark	Speedup	Breakeven	Overhead (C/I)	Instrs. Gen.

------------------------------------------------------------------------------
BEST:
------------------------------------------------------------------------------

binary
	16	1.8	570		68		330
chebyshev
	5	6.5	2		70		262
	10	8.9	2		66		807
	15	11.5	2		70		1652
	20	11.1	2		70		2797
dotproduct (compared with version that tests for zero)
	10	3.1	15		176		11
	100	5.3	5		135		51
	200	5.4	4		118		101
	32	2.3	9		76		47
dotproduct (compared with version with no test for zero)
	10	4.8	10		180		11
	100	7.2	4		136		51
	200	7.3	3		117		101
	32	2.5	8		78		47
query
	100	2.2	1		95		71
	1000	1.8	1		95		71
	2000	1.8	1		95		71
romberg
	omitted, at least for now
dinero
	100k	1.8	1		233		466
mipsi
	not run yet


------------------------------------------------------------------------------
Cache lookup on entry (promote_all):
------------------------------------------------------------------------------

Substantial slowdowns for (I need to confirm the numbers):
binary
	16	0.3	inf.		78		330
chebyshev
	5	4.5	3		86		262
	10	7.2	2		79		807
	15	10.0	2		83		1652
	20	10.3	2		84		2797
dotproduct (compared with version that tests for zero)
	10	0.5	inf.		414		11
	100	2.9	10		211		51
	200	3.6	6		144		101
	32	1.2	42		130		47
query
	100	0.4	inf.		152		71
	1000	0.4	inf.		152		71
	2000	0.4	inf.		152		71
romberg
	omitted, at least for now
dinero
	no good numbers yet
mipsi
	10k	3.3	1		?		36535


------------------------------------------------------------------------------
No strength reduction:
------------------------------------------------------------------------------

dotproduct (compared with version with no test for zero)
	10	0.9	inf.		93		54
	100	0.8	inf.		26		492
	200	0.8	inf.		21		992
	32	0.9	inf.		41		159
dinero
	100k	1.3	1		181		629
--boundary=_0--


To: spin-comp@cs
Subject: more results available
Date: Wed, 16 Sep 1998 00:16:30 PDT
From: Brian Grant <grant@meitner.cs.washington.edu>

I'm accumulating results and a few notes in:

/projects/dyncomp/Papers/PLDI99/results/table.txt

--Brian

To: spin-comp@franklin.cs.washington.edu
Subject: copy/zero-prop working
Date: Thu, 17 Sep 1998 17:43:07 PDT
From: Matthai Philipose <matthai@franklin.cs.washington.edu>

Folks,
Copy/zero prop seems to be working. It removes a bunch of 
instructions from the dynamic region (e.g. it reduces the number of 
multiplies in dynamic region from 16 to 5) and runs correctly i.e. 
produces the right image. I'm getting a few unaligned access 
exceptions and a few instructions that should be removed are not, but 
I'm plugging away at this. Hope to get this squared away by tomorrow 
morning latest.
	Matthai


Date: Thu, 17 Sep 1998 17:48:43 -0700
From: eggers@yakima (Susan Eggers)
To: spin-comp@franklin.cs.washington.edu, matthai@cs.washington.edu
Subject: Re: copy/zero-prop working

Wonderful!

To: spin-comp@franklin.cs.washington.edu
Subject: some thoughts on our paper
Date: Fri, 18 Sep 1998 17:09:28 PDT
From: Matthai Philipose <matthai@franklin.cs.washington.edu>

Seems to me that for most large applications, speedups from 
dynamic compilation will be less than 2x at most (i.e. 10s of 
percents of speedup). To obtain these speedups, we typically have to 
dynamically compile many functions where the program spends 5-20% of 
it's time: i.e. I feel mipsi is a bit of an exception in that the 
program spends pretty much all (> 90%?) it's time in the run 
function, and we get a 4x speedup on it. The 16% and 60% we get on 
m88ksim and dinero are probably more representative (I expect 
similar speedups in mesa/OpenGL, and the fetch/decode numbers that 
the Rocky people got for Java and TCl also support this view).

Though these speedups are not very sexy, I think there is an analogy 
with static compilation which is interesting.
The rewards from dynamic compilation seem to be similar those from 
static compilation phases i.e. getting a 3-5x speedup on a large 
program is  more an exception than a rule. The norm seems more like 
5-20% speedup from each dynamic optimization phase, with different 
optimizations being effective for different programs, as with 
classical optimizations.  It's not a terrible thing, from this point 
of view,
that a fair number of our capabilities are used profitably only bo a 
couple
of our benchmarks, or that each benchmark primarily needs a couple of 
the
capabilities.

One implication of this (small speedups, different optimizatins 
matter for different programs)
is that as with classical optimizations,  dynamic optimizations may 
need to be 
fully automated or at least need  better tool support. Programmers 
are not 
likely to spend days or  weeks studying and annotating their program 
to trigger
different optimization phases in order to get speedups in the 10s of 
%'s.

Of course, as in mesa, dinero, and chebychev show, in certain cases 
dynamic compilation can be used by a programmer to obtain large 
speedups with relatively little annotation. Allowing the user to 
annotate for dynamic compilation is therefore certainly a valuable 
capability... it is just that when speedups on "run-of-the-mill" 
programs are considered, automation is essential.

I'm not sure how these ideas fit in with the current avatar of the 
paper, but
on Brian'a advice, I decided to mail them out to everyone earlier 
rather than
later.

Of course, if we get big speedups on the remaining benchmarks and a 
small
subset of capabilties of our system turns out to be key, I'll have to 
eat my
words! But if not, it may be interesting to consider the above as 
part of the
slant.
	Matthai


Date: Fri, 18 Sep 1998 20:22:37 -0700
From: eggers@yakima (Susan Eggers)
To: spin-comp@franklin.cs.washington.edu, matthai@cs.washington.edu
Subject: Re: some thoughts on our paper


It could perhaps fit into the ruminations in the conclusion.

Susan

To: spin-comp@cs
Subject: instruction mix analysis
Date: Sun, 20 Sep 1998 06:01:43 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

I've written a short gdb script to generate a short program trace, and
a perl script to produce instruction counts.  Here is what it produces
for a couple executions of binary's dynamic region.  Let me know what
you think we need to add/change before I run all the programs through it.
How many executions of the dynamic region do you think we need?  For
the microbenchmarks, all executions should be identical, so a couple should
be ok, I think.  For the macrobenchmarks, different executions could be
a little different.  dinero and mipsi only execute their regions once,
but loop inside them for a long time.

Actually, the counts are for the function containing binary's dynamic
region.

--Brian

Multiflow statically compiled version of binary:
All instructions: 214
	cmplt:	23
	clr:	3
	or:	8
	negl:	1
	sra:	11
	ret:	3
	lda:	18
	cmple:	21
	br:	15
	addl:	31
	bne:	18
	subl:	11
	cmpeq:	10
	beq:	11
	addq:	10
	s4addl:	10
	ldl:	10

	lda/ldah: 18
	ldgp: 0
	loads: 10
	loads from the stack: 0
	global loads: 0

	stores: 0
	stores to the stack: 0
	global stores: 0

	conditional branches: 29
	arithmetic operations with immediates: 7

	memory operations: 28
	integer operations: 136
	float operations: 0

Dynamic instructions: 0

	table-pointer builds: 0
	global-pointer loads: 0
	other table loads: 0

Dynamically compiled version:
All instructions: 80
	cmple:	8
	ldq:	6
	or:	9
	lda:	16
	bne:	10
	negl:	1
	cmpeq:	10
	jmp:	3
	beq:	8
	stq:	6
	ret:	3

	lda/ldah: 16
	ldgp: 0
	loads: 6
	loads from the stack: 3
	global loads: 3

	stores: 6
	stores to the stack: 6
	global stores: 0

	conditional branches: 18
	arithmetic operations with immediates: 10

	memory operations: 28
	integer operations: 28
	float operations: 0

Dynamic instructions: 65
	beq:	8
	stq:	3
	cmple:	8
	ldq:	3
	lda:	13
	or:	6
	ret:	3
	bne:	10
	negl:	1
	cmpeq:	10

	table-pointer builds: 0
	global-pointer loads: 0
	other table loads: 0

Date: Sun, 20 Sep 1998 22:39:47 -0700
From: eggers@yakima (Susan Eggers)
To: spin-comp@cs
Subject: results so far

I've put a file called results.doc in /projects, so we can have a 
sense of where we are in generating results.  Just look at the first
2 tables.  gears, x and y are graphics programs.  The 3 odd-looking
routines are the OpenGL library functions.

The first contains our basic results, with all the optimizations
we have so far (load hoisting & unstructured code & dynamic copy/0
prop & register actions are missing, and maybe something else too)
turned on -- the best we can do.

The second contains speedups without certain optimizations (this
doesn't mean we'll put this table in the paper as is -- I just wanted
you to see how far along we are).  ??? means we apply the optimization
but don't have a result yet for not applying it.  ? means we don't
know whether we apply the optimization or not.  The blanks are supposed
to be blank, because the application doesn't call for the opt.

Susan
/projects/dyncomp/Papers/PLDI99

Date: Sun, 20 Sep 1998 23:00:08 -0700
From: eggers@yakima (Susan Eggers)
To: spin-comp@cs, grant@cs.washington.edu
Subject: Re: instruction mix analysis

> I've written a short gdb script to generate a short program trace, and
> a perl script to produce instruction counts.  Here is what it produces
> for a couple executions of binary's dynamic region.  Let me know what
> you think we need to add/change before I run all the programs through it.
> How many executions of the dynamic region do you think we need?  For
> the microbenchmarks, all executions should be identical, so a couple should
> be ok, I think.  For the macrobenchmarks, different executions could be
> a little different.  dinero and mipsi only execute their regions once,
> but loop inside them for a long time.
To gauge how the instruction mix changes from statically compiled
programs to dynamically compiled programs, I would think we should run each
dynamic region once & compare.  Then to gauge how that change effects
the total instruction mix, to see whether the changes amount to much,
we would run each program once, but all the way through.
At the moment I don't see how runnnig a program many times will help us.
To summarize:
	whole program: statically & dynamically compiled code
	dynamic region: statically & dynamically compiled code
	dynamic compiler: dynamically compiled code


> 
> Actually, the counts are for the function containing binary's dynamic
> region.
> Multiflow statically compiled version of binary:
> All instructions: 214
> 	cmplt:	23
> 	clr:	3
> 	or:	8
> 	negl:	1
> 	sra:	11
> 	ret:	3
> 	lda:	18
> 	cmple:	21
> 	br:	15
> 	addl:	31
> 	bne:	18
> 	subl:	11
> 	cmpeq:	10
> 	beq:	11
> 	addq:	10
> 	s4addl:	10
> 	ldl:	10
> 
> 	lda/ldah: 18
> 	ldgp: 0
> 	loads: 10
> 	loads from the stack: 0
> 	global loads: 0
> 
> 	stores: 0
> 	stores to the stack: 0
> 	global stores: 0
> 
> 	conditional branches: 29
> 	arithmetic operations with immediates: 7
> 
> 	memory operations: 28
> 	integer operations: 136
> 	float operations: 0
> 
> Dynamic instructions: 0
> 
> 	table-pointer builds: 0
> 	global-pointer loads: 0
> 	other table loads: 0
> 
> Dynamically compiled version:
> All instructions: 80
> 	cmple:	8
> 	ldq:	6
> 	or:	9
> 	lda:	16
> 	bne:	10
> 	negl:	1
> 	cmpeq:	10
> 	jmp:	3
> 	beq:	8
> 	stq:	6
> 	ret:	3
> 
> 	lda/ldah: 16
> 	ldgp: 0
> 	loads: 6
> 	loads from the stack: 3
> 	global loads: 3
> 
> 	stores: 6
> 	stores to the stack: 6
> 	global stores: 0
> 
> 	conditional branches: 18
> 	arithmetic operations with immediates: 10
> 
> 	memory operations: 28
> 	integer operations: 28
> 	float operations: 0
> 
> Dynamic instructions: 65
> 	beq:	8
> 	stq:	3
> 	cmple:	8
> 	ldq:	3
> 	lda:	13
> 	or:	6
> 	ret:	3
> 	bne:	10
> 	negl:	1
> 	cmpeq:	10
> 
> 	table-pointer builds: 0
> 	global-pointer loads: 0
> 	other table loads: 0
> 

A summary of the instruction categories.  Subcategories are indented.
Many you already have -- I'm just laying them out in an organized 
fashion.
memory operations
	loads
		loads from the stack (restores)
		loads using the GP
	stores
		stores to the stack (spills)
		stores using the GP
computation
	integer arithmetic
		address calculations
		arithmetic with one immediate source operand
	FP arithmetic
		arithmetic with one immediate source operand
	arithmetic with one immediate source operand
control
	unconditional branches
	conditional branches



It would be helpful to have lists of the instructions to get a quick
sense of the changes in instruction mix:
	the instructions appear in the same order in both lists
	the instructions are sorted in descending order (frequency of
		occurrence in the dynamically compiled program),
	the instructions are sorted in descending order in the statically
		compiled program.
	sublist of instructions which occur in the dynamically compiled
		code more often than/the same as/less often than in the
		statically compiled instructions 

It would also be helpful to see these lists where the numbers are a
percentage of static instructions or are normalized to static instructions.

We'll need averages for the kernels/real programs. On everything, not
just the instruction mix.

Multiflow generates loads and stores to longs and our dynamic compiler
generates to quadwords.  Is this right or do we have a bug in our
generation?

Susan

To: spin-comp@thistle.cs.washington.edu
Subject: update: shader, lazy, switches->ifs
Date: Wed, 23 Sep 1998 13:14:55 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

The fully-annotated shader now works without run-time copy/zero prop.  I
haven't tested with copy/zero prop.

********************************

The lazy version of binary now works again.  The bug was that I forgot I
reload the value of a TEMP in the GE.  It worked before because the register
holding the value of the TEMP just happened not to be clobbered before its
use.

Here are the stats (using best times: speedup, breakeven,
cycles per instruction generated, and instructions generated).

Array length 16
---------------
Lazy:
       1.2     1898            34                815
	
Eager:
       1.9      577	        71	         330

Array length 4095
-----------------
Lazy:
	1.0     36562           30              3859

Eager:
	1.4     51682	        64 	       73462


So, lazy doesn't make sense for short array lengths, but it might for
longer ones, especially if we close the speedup gap.  The speedup gap is
caused by:
	- Loads + indirect jumps; the original relative branches are
	  not yet patched
	- A copy of the address of the memory location containing the 
	  address to jump to
	- Table-pointer builds
	- Poorer cache locality (maybe) because the code isn't stitched
	  contiguously

All of these inefficiencies, except the last one, could be relatively
easily eliminated.

********************************

As for mipsi with ifs instead of computed jumps:

I put in an option to select whether we want to use computed jumps for
switches or not.  Previously, Multiflow just relied on a simple sparsity
check to choose which to use.  I'm trying to build mipsi with the option
selects to gen switches as ifs, but the BTA has been chugging away for about
90 minutes so far.  That is about twice as long as with jumps.  I'll let it
go a while longer before stopping it to debug it.  Reachability may not be
converging.

Multiflow's implementation of the tree of tests seems less than optimal.
Matthai and I think that equality tests can be postponed to the leaves of
the tree, rather than doing both equality and relational tests at all interior
nodes.  Does this seem reasonable?  I've attached Multiflow's code for
generating the ifs, in case you're curious.  I've added a couple comments.

--Brian

		heapsw[0].slab = dlab = p->slab != NOLAB ? p->slab : getlab();

		makeheap(p, n, 1);	/* build heap */
		walkheap(1, n); /* produce code */

		if( p->slab != NOLAB )
			branch( dlab );
		else
			deflab(dlab);



makeheap(p, m, n)
register struct sw *p;
{
	register int q;

	q = select(m);
	heapsw[n] = p[q];
	if( q>1 ) makeheap(p, q-1, 2*n);
	if( q<m ) makeheap(p+q, m-q, 2*n+1);
}

select(m) {
	register int l,i,k;

	for(i=1; ; i*=2)
		if( (i-1) > m ) break;
	l = ((k = i/2 - 1) + 1)/2;
	return( l + (m-k < l ? m-k : l));
}

walkheap(start, limit)
{
	long label;


	if( start > limit ) return;
	/* insert equality test */
	CCODE_Sw_Test_And_Branch(heapsw[start].sval,
				 heapsw[start].slab,
                                 0,
                                 lineno);
	if( (2*start) > limit ) {
		branch(heapsw[0].slab);
		return;
	}
	/* insert relational tests */
	if( (2*start+1) <= limit ) {
		label = getlab(); /* generate a new label */
		CCODE_Sw_Test_And_Branch(heapsw[start].sval,
					 label,
					 1,
					 lineno);
	} else /* 2*start == limit */
		CCODE_Sw_Test_And_Branch(heapsw[start].sval,
					 heapsw[0].slab,
					 1,
					 lineno);
	walkheap( 2*start, limit);
	if( (2*start+1) <= limit ) {
		deflab(label); /* place the label */
		walkheap( 2*start+1, limit);
	}
}

EXTERN "C" VOID CCODE_Sw_Test_And_Branch(
    INT                 case_constant,
    LABEL               target,
    BOOL                bin_search_test,
    INT                 line
)
{
    OP                  if_op;
    OPER                if_oper;
    LABEL               false_label;

    if_op = bin_search_test ? OP_make(IF_REL)(CCODE_volatility,GT,
					      CCODE_Size_To_SI(GLOB_machine_word_size)) :
                              OP_make(IF_EQT)(CCODE_volatility,EQ,
					      CCODE_Size_To_N(GLOB_machine_word_size));
    if_oper = OPER_Create_Oper(if_op, NOPOS_OR_LINENO(line));
    OPER_part(if_oper,prob)  = probability_with_default(
				   ccode_DEFLT_BRANCH_PROB);
    OPER_part(if_oper,if_convert) = IF_CONVERT_NONE;
    OPER_part(if_oper,read1) = *ccode_sw_stackp;
    OPER_part(if_oper,read2) = CONST_N_Create(
                                        DTYPE_make(BTYPE_SI,
						   GLOB_machine_word_size),
                                        TARGET_Int_N_Size(case_constant,
							  GLOB_machine_word_size));
    false_label = LABEL_Create();
    IF (P1OPT_generate_ifprob_data)
        IFPROB_Add_Counters(if_oper,
                            2,
                            line);
    PH12_Next_Oper_If(if_oper, target, false_label);
    PH12_Next_Label(false_label);
    RETURN;
}



To: grant@thistle.cs.washington.edu
cc: spin-comp-archive@cs
Subject: code gen. of switch statements
Date: Wed, 23 Sep 1998 13:55:42 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>



> As I understand it, a switch/case setup compiles exactly the same as
>       if (var == const1) {.....};
>       else if (var == const2) {.....};
>       else  {default_action};
> anyway.

A compiler should be able to do better than that.  Generating good code for
switches is one place where compiler writers can show they know something
about searching.

Using a branch table will produce faster and smaller code if the cases
are consecutive integers.  The only thing that may be non-obvious is the
best way to test whether the expression being switched on is within
range before accessing the branch table.  A straightforward coding of
this test requires two comparisons, but Ritchie's compiler for the
PDP-11 generated only one comparison using the machine language
equivalent of the following code:

        if ((unsigned)(value -= MIN) > (MAX - MIN) goto default;

On the PDP-11, this generates one less instruction (or two less, if MIN
is zero) than:

        if (value < MIN || value > MAX) goto default;

(Learning hacks like these is one of the benefits of reading the
compiler.)

Since some people like to count starting at one, a possible enhancement
would be to change MIN from 1 to 0 in this case by adding an extra entry
to the beginning of the branch table.  But real C programmer count from
0; wimps who count starting with 1 deserve to have their switch statements
execute slower.  :-)

If the cases are not consecutive, the branch table must be filled with
entries for the "missing" cases, making the table larger.  The Ritchie
compiler will generate a branch table if the number of entries in the
branch table would be less than three times the number of cases.  If
the cases are mostly consecutive with a few outliers, a branch table
could be augmented with a few specific tests for the outliers, but I
don't know of any compiler that does this.

There are two general methods for implementing tables which do not rely
on the keys being nearly consecutive:  hashing and the binary search.
Hashing, which is what the Ritchie compiler uses, has the advantage that
its performance is independent of the number of cases, just as with a
branch table.  The modulo instruction is used as the hash function; the
C compiler tries a variety of values for the modulus and selects the
best one which means that the time required to generate the hash table
is proportional to the square of the number of cases.

The UN*X VAX compiler, on the other hand, uses a binary search.  A
binary search executes in time proportional to the log of the number of
cases.  This makes it sound worse that the hash search; I presume
someone discovered that most switch statements contained few enough
statements that the binary search was superior.  The binary search works
best on a machine with a three way branch like that provided by the
Fortran arithmentic IF statement.  On a machine with condition codes
like the VAX, each step of the binary search is implemented by a compare
instruction followed by two branches on the condition codes.

Several things may be done to improve the performance of the binary
search.  First, many machines execute a conditional branch instruction
faster when no branch is taken, so that rather than testing the middle
value in the table one can test a value somewhat to one side in order to
decrease the chance that a branch will be taken.  This is implemented in
the VAX compiler, but some other possible improvements are not.  The
binary search could be abandoned in favor of the linear search at some
level (e. g. when the number of possibilities has been reduced to 2 or
3).  If there are a series of consecutive cases, this can be used to
eliminate extra tests.  (For example, if a number is known to be less
than 5 it cannot be greater than 4, and if a number is greater than 2 and
less than 4 then it must be equal to 3, but the VAX compiler will code
to test for both these cases.)  Finally, each comparison generated by
the VAX compiler looks like:

        cmpl    r0,$7           # compare switch value with 7
        beql    L1              # if equal, branch to the code for case 7
        bgtr    L8              # if greater, branch to L8 for the next cmpl.
        # The next cmpl instruction goes here.

Since the branch to L8 is more likely to be executed that the branch to
L1, the bgtr instruction should come first to minimize the number of
instructions executed.

For small cases, the good old linear search is used by both the Ritchie
and the VAX compilers.  Several things are done to speed up the linear
search.  First, the switch expression is copied into a register.  This
helps in general but loses when the switch instruction is a register
variable or the switch contains only one case.  (This is hard to fix
because the compilers generate the code for a switch in two pieces;
first they generate code to place the value to be switched on in r0, and
then they generate the code to implement the switch.  Another problem
with this separation appears on the PDP-11, where it may be easier to
compute an expression in r1 than in r0 due to a brain damaged multiply
instruction.)  Second, the compiler implements the search as a series of
compares followed by branch if equal instructions.  This minimizes the
time required to reach the default case because in the default case none
of the branches will be taken.  In contrast, the code at the top of this
article will probably be compiled into a series of branch if not equal
instructions, all of which will branch if there is no match.

The Ritchie compiler at one time actually generated a table of values
and labels, and did a linear search on it using a loop.  This saves
space but takes more time.  Furthermore, it doesn't even save space if
there are 1 or 2 cases.  (The Ritchie compiler has special handling of
switch statements with no cases except the default.)  The Ritchie
compiler was changed to generate linear searches using a series of
compare instructions quite a long time ago, but I don't know if Dennis
was responsible for the change.

I don't know why the VAX compiler uses with a linear search at all,
rather than using the binary search.  Probably this was a holdover from
the Ritchie compiler, which must be prepared to generate a linear search
because a linear search will outperform a hash search on a few elements.

In general, then, a compiler should do pretty well by using a jump table
where possible and a binary search otherwise.  What is actually optimum
must be determined by measuring various approaches on a specific machine.
                                Kenneth Almquist
                                ihnp4!houxm!hropus!ka   (official name)
                                ihnp4!opus!ka           (shorter path)





To: spin-comp@thistle.cs.washington.edu
Subject: mipsi with ifs
Date: Wed, 23 Sep 1998 14:11:09 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

mipsi completed.  The Multiflow statically compiled version takes 185 seconds
with ifs, compared to 115 seconds with jmps.  That's a 62% increase.  Is
that reasonable?  If we implemented a more efficient tree, we might be
able to cut that to 30-40%, I'm guessing.

FYI, mipsi's main switch has 35 cases plus the default.  It has a few nested
switches, as well, each with 10-30 cases.

--Brian

Date: Wed, 23 Sep 1998 14:16:19 -0700 (PDT)
From: chambers@klamath (Craig Chambers)
To: spin-comp@thistle.cs.washington.edu, grant@cs.washington.edu
Subject: Re: mipsi with ifs


> From grant@thistle.cs.washington.edu  Wed Sep 23 14:11:24 1998
> Delivery-Date: Wed, 23 Sep 1998 14:11:27 PDT
> Reply-To: grant@cs.washington.edu
> To: spin-comp@thistle.cs.washington.edu
> Subject: mipsi with ifs
> Mime-Version: 1.0
> Date: Wed, 23 Sep 1998 14:11:09 PDT
> From: Brian Grant <grant@thistle.cs.washington.edu>
> 
> mipsi completed.  The Multiflow statically compiled version takes 185 seconds
> with ifs, compared to 115 seconds with jmps.  That's a 62% increase.  Is
> that reasonable?  If we implemented a more efficient tree, we might be
> able to cut that to 30-40%, I'm guessing.
> 
> FYI, mipsi's main switch has 35 cases plus the default.  It has a few nested
> switches, as well, each with 10-30 cases.
> 
> --Brian
> 

If we compare our best to a hobbled or no-op version, then 30-62% is a lot
of magnification of our benefit.

If we compare a no-op/hobbled versions, where none of the switches are
static, then 30-62% is on the edge of what's reasonable, to me.  It's
still a lot, and the extra fixed overhead of the if's will tend to
reduce in magnitude any benefits of other optimizations.

-- Craig

Date: Wed, 23 Sep 1998 14:36:02 -0700
From: eggers@yakima (Susan Eggers)
To: spin-comp@thistle.cs.washington.edu, grant@cs.washington.edu
Subject: Re: update: shader, lazy, switches->ifs



I've been reporting median, because they are always close to best
and I imagine that they look fairer to a reviewer.  Can you send
me the median times?

Thanks,
Susan

To: eggers@yakima (Susan Eggers)
cc: spin-comp-archive@cs
Subject: Re: update: shader, lazy, switches->ifs 
Date: Wed, 23 Sep 1998 14:43:42 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

Array length 16:

Eager (you should have something close to these numbers):
 1.8     589      72      330
Lazy:
1.2     2011            36              815

Array length 500:

Eager:
  2.1    7917      66     8769
Lazy:
 1.1     4012            32              1822

Array length 4095:

Eager:
1.2   85851      64    73462
Lazy:
1.0     34493           31              3859


--Brian

To: chambers@klamath (Craig Chambers)
cc: spin-comp@cs
Subject: Re: mipsi with ifs 
Date: Wed, 23 Sep 1998 14:55:59 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

>> If we compare a no-op/hobbled versions, where none of the switches are
>> static, then 30-62% is on the edge of what's reasonable, to me.  It's
>> still a lot, and the extra fixed overhead of the if's will tend to
>> reduce in magnitude any benefits of other optimizations.

The switches in the other benchmarks (dinero, query) only have small numbers
of cases.  Maybe for those I should run the comparison, and for mipsi we punt.
mipsi is an all-or-nothing benchmark, in any case.  For mipsi's cases that
have dynamic switches, essentially nothing is specialized, and I expect to
get slowdown.  We can include a note saying that we'll run the experiment for
the final paper.

--Brian

Date: Wed, 23 Sep 1998 14:57:56 -0700 (PDT)
From: chambers@klamath (Craig Chambers)
To: grant@thistle.cs.washington.edu
Subject: Re: mipsi with ifs
Cc: spin-comp@cs


> From grant@thistle.cs.washington.edu  Wed Sep 23 14:56:02 1998
> Delivery-Date: Wed, 23 Sep 1998 14:56:07 PDT
> To: chambers@klamath (Craig Chambers)
> cc: spin-comp@cs
> Subject: Re: mipsi with ifs 
> Mime-Version: 1.0
> Date: Wed, 23 Sep 1998 14:55:59 PDT
> From: Brian Grant <grant@thistle.cs.washington.edu>
> 
> >> If we compare a no-op/hobbled versions, where none of the switches are
> >> static, then 30-62% is on the edge of what's reasonable, to me.  It's
> >> still a lot, and the extra fixed overhead of the if's will tend to
> >> reduce in magnitude any benefits of other optimizations.
> 
> The switches in the other benchmarks (dinero, query) only have small numbers
> of cases.  Maybe for those I should run the comparison, and for mipsi we punt.
> mipsi is an all-or-nothing benchmark, in any case.  For mipsi's cases that
> have dynamic switches, essentially nothing is specialized, and I expect to
> get slowdown.  We can include a note saying that we'll run the experiment for
> the final paper.
> 
> --Brian
> 

Sounds right to me.

-- Craig

To: spin-comp@cs
Subject: more times
Date: Thu, 24 Sep 1998 10:49:06 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

(The M just indicates that these are using medians.)


chebychev

	with load hoisting
        M       7.2     2               74              790

It appears now that chebychev benefits from load hoisting.  Perhaps
earlier performance degradation was due to some of the bugs I've fixed
while working on the shader.  This suggests that I should probably rerun
the old experiments with load hoisting turned on.


dinero

Compared with static strength reduction:

	00:BEST
        M       1.4     0               291             564
	01:BEST-FD
        M       1.4     0               734             532
	03:BEST-PS
        M       1.3     0               243             538
	04:BEST-SC
        M       0.9     0               235             831
	05:BEST-SL
	still running
	07:BEST-RA
        M       1.4     0               302             551
	11:BEST+LH
        M       1.5     0               289             570

Load hoisting appears to be a win again.  I'll have to rerun these with LH
in BEST.

Compared with no static strength reduction:

	00:BEST
        M       1.7     0               292             564
	01:BEST-FD
        M       1.6     0               729             532
	02:BEST-SR
        M       1.0     0               229             701
	03:BEST-PS
        M       1.7     0               250             538
	05:BEST-SL
        M       0.8     0               177             1649
	07:BEST-RA
        M       1.7     0               303             551
	11:BEST+LH
        M       1.7     0               287             570

Note that speedups are lower because, for a reason I can't fathom, the
statically compiled version ran nearly 20% faster for this run than for the
previous ones.  I haven't changed compiler options, linker options, or
any other part of our infrastructure that should affect the statically
compiled version.

Regarding 05:BEST-SL:

This is a run with no static loads.  In this case, nothing can be specialized.
Also, one small switch is converted to ifs, but it isn't executed, so the
comparison with the regular statically compiled version should be fair.


mipsi:

	06:BEST+LAZY
        M       2.6     0               148             11858
	07:BEST-RA
        M       4.8     0               204             23822


06:BEST+LAZY is a lazily specialized version of mipsi (loop lazy).
07:BEST-RA is a version with reachability turned off, but one additional
variable annotated.  It looks like I need to annotate that variable in
the other cases, too.


pnmconvol:

This is a 5x5 convolution over a color image, size 768x1024.  I'm looking
at why performance is so dreadful.

	00:BEST
        M       0.5     0               20              1386


--Brian

To: spin-comp@cs
Subject: the missing time
Date: Thu, 24 Sep 1998 10:54:26 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

dinero

Compared with static strength reduction:
	05:BEST-SL
        M       0.7     0               176             1649

--Brian


To: spin-comp@cs
Subject: instruction mix of pnmconvol
Date: Thu, 24 Sep 1998 13:33:26 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

The new instruction mix script isn't quite ready, so I ran the old one.

We didn't remove too many instructions, and none of the float operations.
One thing that can't be seen by these looking at these counts is that the
scheduling of the statically compiled version is good and the
scheduling of the dynamically compiled version is not so good.

From the tail of the inner loop of the statically-compiled version:

0x120006b6c <really_do_convol+300>:	lda	a4,1(zero)
0x120006b70 <really_do_convol+304>:	lda	a5,16(zero)
0x120006b74 <really_do_convol+308>:	lds	$f24,0(sp)
0x120006b78 <really_do_convol+312>:	lds	$f22,16(sp)
0x120006b7c <really_do_convol+316>:	lds	$f23,8(sp)
0x120006b80 <really_do_convol+320>:	cvtlq	$f24,$f24
0x120006b84 <really_do_convol+324>:	cvtlq	$f22,$f22
0x120006b88 <really_do_convol+328>:	cvtlq	$f23,$f23
0x120006b8c <really_do_convol+332>:	cvtqt	$f24,$f24
0x120006b90 <really_do_convol+336>:	cvtqt	$f22,$f22
0x120006b94 <really_do_convol+340>:	cvtqt	$f23,$f23
0x120006b98 <really_do_convol+344>:	mult	$f24,$f27,$f27
0x120006b9c <really_do_convol+348>:	mult	$f22,$f25,$f25
0x120006ba0 <really_do_convol+352>:	mult	$f23,$f26,$f26
0x120006ba4 <really_do_convol+356>:	addt	$f30,$f27,$f27
0x120006ba8 <really_do_convol+360>:	addt	$f28,$f25,$f25
0x120006bac <really_do_convol+364>:	addt	$f29,$f26,$f26
0x120006bb0 <really_do_convol+368>:	cvtts	$f27,$f30
0x120006bb4 <really_do_convol+372>:	cvtts	$f25,$f28
0x120006bb8 <really_do_convol+376>:	cvtts	$f26,$f29


Dynamically compiled version (not exactly the corresponding instructions,
but close):

0x14001cb04 <DyCRT_CodeSpace+3060>:	lds	$f26,16(sp)
0x14001cb08 <DyCRT_CodeSpace+3064>:	cvtlq	$f27,$f27
0x14001cb0c <DyCRT_CodeSpace+3068>:	extbl	t9,zero,t9
0x14001cb10 <DyCRT_CodeSpace+3072>:	stl	t9,24(sp)
0x14001cb14 <DyCRT_CodeSpace+3076>:	cvtlq	$f26,$f26
0x14001cb18 <DyCRT_CodeSpace+3080>:	lds	$f25,24(sp)
0x14001cb1c <DyCRT_CodeSpace+3084>:	cvtlq	$f25,$f25
0x14001cb20 <DyCRT_CodeSpace+3088>:	cvtqt	$f27,$f27
0x14001cb24 <DyCRT_CodeSpace+3092>:	cvtqt	$f26,$f26
0x14001cb28 <DyCRT_CodeSpace+3096>:	cvtqt	$f25,$f25
0x14001cb2c <DyCRT_CodeSpace+3100>:	ldt	$f24,-32456(s1)
0x14001cb30 <DyCRT_CodeSpace+3104>:	mult	$f27,$f24,$f24
0x14001cb34 <DyCRT_CodeSpace+3108>:	addt	$f30,$f24,$f24
0x14001cb38 <DyCRT_CodeSpace+3112>:	cvtts	$f24,$f30
0x14001cb3c <DyCRT_CodeSpace+3116>:	ldt	$f27,-32448(s1)
0x14001cb40 <DyCRT_CodeSpace+3120>:	mult	$f25,$f27,$f27
0x14001cb44 <DyCRT_CodeSpace+3124>:	addt	$f29,$f27,$f27
0x14001cb48 <DyCRT_CodeSpace+3128>:	cvtts	$f27,$f29
0x14001cb4c <DyCRT_CodeSpace+3132>:	ldt	$f27,-32440(s1)
0x14001cb50 <DyCRT_CodeSpace+3136>:	mult	$f26,$f27,$f27
0x14001cb54 <DyCRT_CodeSpace+3140>:	addt	$f28,$f27,$f27
0x14001cb58 <DyCRT_CodeSpace+3144>:	cvtts	$f27,$f28
0x14001cb5c <DyCRT_CodeSpace+3148>:	lda	t9,16(zero)
0x14001cb60 <DyCRT_CodeSpace+3152>:	lda	t8,1(zero)
0x14001cb64 <DyCRT_CodeSpace+3156>:	ldq	t12,0(t11)
0x14001cb68 <DyCRT_CodeSpace+3160>:	lda	a5,4(t10)
0x14001cb6c <DyCRT_CodeSpace+3164>:	addl	a5,a5,a4
0x14001cb70 <DyCRT_CodeSpace+3168>:	addl	a4,a5,a5
0x14001cb74 <DyCRT_CodeSpace+3172>:	addq	a5,t12,t12
0x14001cb78 <DyCRT_CodeSpace+3176>:	addq	t12,0x2,a5


Dynamic Counts
--------------

One execution of really_do_convol.

Statically compiled version:

All instructions: 1690
	s8addl:	10
	cmplt:	36
	s4addq:	75
	clr:	6
	or:	54
	ldq:	106
	mult:	75
	lds:	153
	cvtlq:	75
	ret:	1
	sll:	25
	lda:	62
	cvtqt:	75
	stl:	75
	br:	30
	cvtts:	75
	addl:	141
	ldq_u:	75
	insbl:	50
	stq:	3
	beq:	36
	mskbl:	50
	sts:	3
	addq:	95
	ldl:	4
	addt:	75
	extbl:	225

	lda/ldah: 62
	ldgp: 0
	loads: 338
	loads from the stack: 78
	global loads: 0

	stores: 81
	stores to the stack: 78
	global stores: 0

	conditional branches: 36
	arithmetic operations with immediates: 136

	memory operations: 481
	integer operations: 767
	float operations: 375


Dynamically compiled version:

All instructions: 1396
	s8addl:	5
	ldq:	29
	or:	76
	mult:	75
	lds:	78
	ldt:	75
	jmp:	1
	cvtlq:	75
	ret:	1
	sll:	25
	lda:	92
	cvtqt:	75
	stl:	75
	cvtts:	75
	addl:	75
	ldq_u:	75
	stq:	2
	insbl:	50
	mskbl:	50
	sts:	3
	addq:	80
	ldl:	4
	addt:	75
	extbl:	225

	lda/ldah: 92
	ldgp: 0
	loads: 261
	loads from the stack: 76
	global loads: 2

	stores: 80
	stores to the stack: 77
	global stores: 0

	conditional branches: 0
	arithmetic operations with immediates: 100

	memory operations: 433
	integer operations: 586
	float operations: 375



To: spin-comp@cs
Subject: updated times
Date: Fri, 25 Sep 1998 00:51:01 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

Load hoisting is now in BEST.

chebychev
---------

	00:BEST
        M       7.3     2               72              790
	01:BEST-FD
        M       6.7     2               71              790
	03:BEST-PS
	Not run yet.
	04:BEST-SC
        M       1.1     16              22              1567
	07:BEST-RA
        M       7.1     2               71              788
	11:BEST-LH
        M       7.1     2               76              797


dinero
------

After looking over my notes, I quickly figured out that the change
in speed of the statically compiled version was due to my inlining
of one more routine.

Compared with version that tests for 2^k:

	00:BEST
        M       1.4     0               264             564
	01:BEST-FD
        M       1.4     0               690             532
	03:BEST-PS
        M       1.3     0               242             538
	04:BEST-SC
        M       0.9     0               233             831
	05:BEST-SL
        M       0.7     0               175             1649
	07:BEST-RA
        M       1.4     0               299             551
	11:BEST-LH
        M       1.4     0               294             564

Compared with version that doesn't test for 2^k:

	00:BEST
        M       1.7     0               262             564
	01:BEST-FD
        M       1.7     0               685             532
	02:BEST-SR
        M       1.0     0               229             701
	03:BEST-PS
        M       1.7     0               241             538
	05:BEST-SL
        M       0.8     0               174             1649
	07:BEST-RA
        M       1.7     0               301             551
	11:BEST-LH
        M       1.7     0               295             564

mipsi
-----

	00:BEST
        M       5.2     0               196             23752
	01:BEST-FD
        M       5.2     0               196             23813
	06:BEST+Lazy
        M       4.1     0               170             11841
	07:BEST-RA
        M       5.2     0               211             23822
	11:BEST-LH
        M       5.2     0               154             24135

Some discussion is probably necessary for 07.  In that case, if one variable
isn't annotated (and we didn't think it needed to be), then performance goes
to pot because the offset added to the pc is killed, which causes the pc to
be promoted at every branch in the interpreted program.  With the variable
annotated, then we get the same performance as with reachability, but with
somewhat greater dynamic-compilation overhead.

ckbrpts
-------

This is the routine we're specializing in m88ksim.  I extracted it for
easier timing.  The only input we have for the full program doesn't
have any breakpoints.  The point of the second batch of runs is to show
that what we're doing has benefit even in the non-brain-damaged case.
I'll try to get the whole-program times this morning, too.

0 breakpoints:

	00:BEST
        M       5.4     25              548             8
	01:BEST-FD
        M       0.8     inf.            1031            7
	03:BEST-PS
        M       0.4     inf.            57              199
	05:BEST-SL
        M       0.6     inf.            118             827
	07:BEST-RA
        M       5.4     26              566             8
	11:BEST-LH
        M       6.2     23              677             6

5 breakpoints (but none ever matched):

	00:BEST
        M       3.9     57              106             98
	01:BEST-FD
        M       0.8     inf.            221             92
	03:BEST-PS
        M       0.4     inf.            65              199
	05:BEST-SL
        M       0.7     inf.            117             827
	07:BEST-RA
        M       3.9     60              112             98
	11:BEST-LH
        M       4.1     53              113             87

Ok, so load hoisting is sometimes an optimization and sometimes not.
Should it be part of BEST?

query
-----

This very of query uses ifs rather than a computed jump.  However, the
statically compiled version it is compared to used the jump.  I'll fix
this and send you an updated number soon.

	05:BEST-SL
        M       1.3     6               190             793


dotproduct
----------

Compared with statically compiled version that tests for zero:

	05:BEST-SL
        M       1.4     345             186             943

Date: Fri, 25 Sep 1998 11:20:10 -0700
From: eggers@yakima (Susan Eggers)
To: spin-comp@cs
Subject: home phone over the weekend

650-941-9744

Susan

To: spin-comp@franklin.cs.washington.edu
Subject: Zero-copy prop write-up
Date: Fri, 25 Sep 1998 13:41:04 PDT
From: Matthai Philipose <matthai@franklin.cs.washington.edu>

In what detail are we going to describe the zero/copy propagation, 
register actions, and dead-code removal? As Brian just observed, we 
probably should describe reg-actions and dead-code removal even if 
they're not implemented, since they will add to the value of the 
paper and will certainly be implemented by the time the final 
deadline comes around.

BTW, Craig, it looks like we can have a zero-pass (forward) version 
of dead-code removal that is fairly effective (at least for the 
programs of interest to us) within our current framework. The basic 
idea is to determine for each potentially dead statement whether its 
"deadness condition" holds. For instance, if we know that zero-value 
of a runtime-constant will cause a downstream computation to be 
eliminated, we can eliminate an upstream operation that writes only 
into that computation based on a zero-check on that run-time 
constant. Of course, the limitation of this approach is that only a 
subset of the dead code will be eliminated; in the above example, for 
instance, we cannot eliminate any dead code that happens before the 
definition of the potentially zero runtime-constant. 

Turns out that this is very useful in pnconvol, and to lesser degree 
in Mesa (the openGL clone).

	Matthai



Date: Fri, 25 Sep 1998 13:55:24 -0700
From: eggers@yakima (Susan Eggers)
To: spin-comp@franklin.cs.washington.edu, matthai@cs.washington.edu
Subject: Re: Zero-copy prop write-up


So far I've written the optimizations (features) in a pretty high 
level.  We can see how we feel about that, especially in the context
of the other descriptions.

Susan 

Date: Fri, 25 Sep 1998 15:44:28 -0700
From: eggers@yakima (Susan Eggers)
To: spin-comp@cs
Subject: the paper

I've put a copy of the first draft in /projects.  The only parts you
should read are sections 2, 3 and related work.  I'll work on section
4 over the weekend.

I've left markers all over the place.  Sometimes they are messages
to you, sometimes words or sentences I'm considering replacing or
omitting, sometimes something else that needs futzing.

Good chance section 2 will need reworking after we write the introducion,
so that we don't repeat and the two fit together.

Susan

Date: Sat, 26 Sep 1998 14:55:23 -0700
From: eggers@yakima (Susan Eggers)
To: spin-comp@cs
Subject: new files

There are new copies of results.doc and paper.doc in /projects.
The change to paper.doc is the addition of some tables/graphs in
the results section, so you can see what the presentation of the
results might be in the paper (as opposed to what the tables in
results.doc that Brian and I are using to collect numbers).  The
 only changes to results.doc are some markers for Brian.

Susan

To: eggers@cs
cc: spin-comp@cs
Subject: location of source code, counting lines
Date: Sun, 27 Sep 1998 14:51:24 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

I know that previously you had trouble accessing these directories.  Warren
restarted the automount demon on yakima and klamath, so you should be able
to access them from there.

The code for dynamic regions (.DyC files) for most programs can be found in:
/projects/DyC_Homes/grant/DyC/regression/
	binary
	ckbrpts
	dinero (whole program is there)
	dotproduct
	mipsi (whole program is there)
	pnmconvol
	query
	romberg

Other code can be found in a number of places:
/projects/DyC_Home/libs/m88ksim/
/projects/dyncomp/DyC/examples/mesa/Mesa-2.5/
/projects/DyC_Homes/mock/benchmarks/consel/benchmark-ppmdither/package/netpbm/

I assume that we will count lines in dynamic regions and also whole
programs?  The netpbm library and mesa (opengl) have a lot of source code,
so I'm not sure what a fair whole-program count would be.  Ignore library
routines?  Count the lines of the ones the programs use?

Also, to count the lines of code, we'll need to eliminate:
	blank lines
	comments
	cpp directives
	our annotations

Perhaps we should write a script to count the lines, since I'm sure we'll
need to do this more than just this time.

--Brian

To: spin-comp@franklin.cs.washington.edu
Date: Sun, 27 Sep 1998 15:20:25 PDT
From: Matthai Philipose <matthai@franklin.cs.washington.edu>


----------- Brian said:
I assume that we will count lines in dynamic regions and also whole
programs?  The netpbm library and mesa (opengl) have a lot of source 
code,
so I'm not sure what a fair whole-program count would be.  Ignore 
library
routines?  Count the lines of the ones the programs use?
---------------

Overall, just to get an idea of the size of these programs, I'd say 
number of program (i.e. library client) along lines with the number 
of lines in the library files/routines we use would probably be 
useful. I guess the tricky thing here is that the automatic part of 
our system still only handles relatively small parts of these large 
libraries i.e. dynamic regions are small relative to total 
source-size. Our system does not really provide any help in 
specializing the whole library, so talking about all the source-lines 
in the library, or even the source-lines outside the dynamic region, 
is misleading, except as a an aid to demonstrate that the program is 
"real". Even for this purpose, it is probably the popularity of the 
program e.g. m88ksim/Mesa/netpbm that is more useful in claiming it 
is "real".

What we probably want to say is that handling real programs has many 
complications, including:
1) Large dynamic regions with bad structure that stresses 
high-running-time analyses e.g. mipsi, where reachability takes for 
ever.

2) Lots of functions called, making it challenging to identify 
opportunities for dynamic compilation, and potentially, making the 
benefits due to DC small.

3) Strange structure which may require teasing apart to get at the 
dynamic region e.g. the generalized shader in Mesa has variables that 
are static along some paths, but dynamic along others, giving rise to 
the need for conditional specialization to allow promotion along all 
paths. The general version is larger than the specific one since it 
tries to handle more cases.

4) Hand specialization by the user, in the case of the Mesa matrix 
transformation routines and shader; in these cases our contribution 
is to avoid code-bloat and missed special cases through DC.

The line size of the whole program is perhaps relevant only for (2).
For 1, the size and structure of the dynamic region are important.
For 3 and 4, it's perhaps just the structure of the DR.


Date: Mon, 28 Sep 1998 12:27:23 -0700 (PDT)
From: chambers@klamath (Craig Chambers)
To: eggers@cs, grant@cs.washington.edu
Subject: Re: location of source code, counting lines
Cc: spin-comp@cs

I bet there are scripts already to count non-blank non-comment lines of C;
ask Mike Ernst or Greg Badros, who've reported such counts in their papers.

-- Craig

Date: Tue, 29 Sep 1998 13:51:43 -0700
From: eggers@yakima (Susan Eggers)
To: spin-comp@cs
Subject: the bibliography

Can anyone tell me where our bibliography for frame papers is?
I might as well get started on updated the references.

Susan

To: eggers@yakima (Susan Eggers)
cc: spin-comp@cs
Subject: Re: the bibliography 
Date: Tue, 29 Sep 1998 14:26:29 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

>> Can anyone tell me where our bibliography for frame papers is?
>> I might as well get started on updated the references.

/projects/unisw/DynComp/www/Related/*.bib

We think we put all previously relevant entries in combined.bib.

--Brian

To: eggers@yakima (Susan Eggers)
cc: spin-comp@cs
Subject: Re: bibs 
Date: Tue, 29 Sep 1998 22:52:49 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

load hoisting ref:

Effective Specialization of Realistic Programs via Use Sensitivity
Luke Hornof, Jacques Noye, and Charles Consel
P. Hentenryck, editor
Proceedings of the Fourth International Symposium on Static Analysis, SAS`97,
volume 1302 of Lecture Notes in Computer Science, pages 293-314, Paris,
France, September 1997. Springer-Verlag.

They don't do exactly what we do.

Similarities:
- They do a backwards use-def analysis that identifies the corresponding defs
  of uses of static variables.
- For uses of static pointers, structures, and arrays that must be "lifted"
  in a dynamic context (i.e., in an emitted instruction), they make those
  uses dynamic and mark the def.
- They handle demotions the same way as non-liftable values in dynamic
  contexts.  We also implement load hoisting in a unified framework with
  demotions.

Differences:
- They make marked defs both static and dynamic, and their analysis has
  to back-propagate this mark because marking a def dynamic creates a new
  dynamic context.
	- In contrast, our defs are only static, but I place demotions
	  immediately following the defs.  This makes the value available
	  in both static and dynamic contexts, but we don't have to
	  back-propagate, which is one advantage of our approach.
	- Another advantage of our approach is that we could potentially make
	  more intelligent load-placement decisions, whereas they just make
	  the original statements static/dynamic.
	- One advantage of their approach is that the instruction they make
	  dynamic may be cheaper than a load, for example, address
	  calculations off a static pointer (add vs. load).  We could also
	  do this, if cost-benefit analysis showed that it would be worthwhile.
- We do load hoisting for floats as well.  I don't know how they place their
  loads of float constants.
- Their backwards analysis is integrated into their interprocedural framework.
- In Tempo, the alternative to use sensitivity is to just make the uses and
  defs dynamic rather than static/dynamic.  In DyC, the defs are still static,
  but we have loads just before the uses.  Actually, Tempo's limitation is
  artificial.  Their claim that certain types of values are non-liftable in
  C is bogus.  They do note that it may be cheaper to combine lifts from
  multiple uses.  It might be worthwhile to take a quick look at the related
  work section of this paper.

--Brian

Date: Wed, 30 Sep 1998 14:06:10 -0700 (PDT)
From: Markus Mock <mock@cs.washington.edu>
To: Brian Grant <grant@cs>, spin-comp-archive@cs
Subject: reachability 

I ran the applications (except m8ksim) and compared the .smry output.

For binary, chebychev, dotproduct, query and romberg where was no
difference in the number of merges with lost temps or number of lost
temps.
For query the only difference was that two more static merges where
identified which does not seem to make a difference, performance with and
w/o RA is the same. For dotproduct your performance numbers are a little
different but maybe that was just a fluke.

dinero has one more merge with temps lost: 6 vs 5 and 8 vs 7 temps are
lost in total. Also there are only 7 instead of 13 static merges. No big
difference which may or not account for the different speedups 1.8 vs 1.6.

mipsi shows big differences. The number of merges with lost temps, though,
is identical: 63 merges with 20 where temps are lost (=31%) and a total of
23 lost temps in both cases. However, there are 51 static merges vs only
9, i.e. 42 less! That produces 107 vs 102 units, the 5 additional units
are dynamic branch units: 59 vs 54. So apparently, the performance penalty
(5.0 vs 4.3 speedup) comes not from less derived variables but from the
increased number of dynamic branches and the associated overhead.

Do you want to add anything to that before we send it to Susan?

The summary files are in /projects/DyC_Homes/mock/DyC/reachability_study/


	-- Markus


Date: Wed, 30 Sep 1998 19:03:58 -0700 (PDT)
From: Markus Mock <mock@cs.washington.edu>
To: spin-comp@cs.washington.edu
Subject: pnmconvol works!

We no longer stare into a black hole when running pnmconvol through mflow.
Both the statically and dynamically compiled version produce now the same
convoluted images as the cc-compiled version (except for the 2 random
bytes that differ in all 3 versions).

The problem were the following lines:

		if ( rsum < 0.0 ) r = 0;
		else if ( rsum > maxval ) r = maxval;
		else r = (int) (rsum + 0.5);
		if ( gsum < 0.0 ) g = 0;
		else if ( gsum > maxval ) g = maxval;
		else g = (int) (gsum + 0.5);
		if ( bsum < 0.0 ) b = 0;
		else if ( bsum > maxval ) b = maxval;
		else b = (int) (bsum + 0.5);

I had to add the explicit cast to int to make the assignment of the
floating point values (rsum + 0.5, gsum + 0.5, and bsum + 0.5) produce the
correct truncated integer values. Without that explicit cast the
assignment of all floating point values was truncated by Mflow to 0,
regardless of the actual floating point value, eg r = rsum + 0. 5 was 0
for rsum = 67.7 (the first result value). 

I've commited the changed source code.



	-- Markus



Date: Wed, 30 Sep 1998 20:04:33 -0700
From: eggers@yakima (Susan Eggers)
To: spin-comp@cs.washington.edu, mock@cs.washington.edu
Subject: Re: pnmconvol works!

Great, Markus.  Now hopefully it will pass thru DyC.

Susan

Date: Thu, 1 Oct 1998 10:13:27 -0700 (PDT)
From: Markus Mock <mock@cs.washington.edu>
To: Brian Grant <grant@cs>, spin-comp-archive@cs
cc: Markus Mock <mock@cs>
Subject: information about static branches

I added a simple pass that prints information about static branches at the
end of the BTA int the .fbk files. A simple diff between the versions w /
w/o reachability can tell which static branches were lost w/o RA.

For mipsi they are:

< line 548 at stat 1964: is a static branch
< line 550 at stat 1971: is a static branch
< line 552 at stat 1980: is a static branch

i.e the branches in this code

	     if(fmt == S)
		FGR[fd] = (float) fpres;
	      else if (fmt == D)
		FPR[fd >> 1] = (double) fpres;
	      else if (fmt == W)
		FWR[fd] = (int) fpres;


That apparently results in the 5 additional dynamic branch units.

	-- Markus


To: eggers@cs
cc: spin-comp@cs
Subject: whole-program times for m88ksim
Date: Sun, 04 Oct 1998 15:34:22 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

m88ksim/m88ksim-wptime.stats00:


WPT
---
Standard Deviation / Mean:
	DyC:		0.00426727593586678
	Mflow:		0.000478490591391508
	(G)cc:		0.000228716271952161

B	1.07	  74.276	  79.198	  78.838
M	1.07	  74.422	  79.236	  78.864
A	1.07	  74.599	  79.242	  78.867


m88ksim/m88ksim-wptime.stats01:


WPT
---
Standard Deviation / Mean:
	DyC:		0.000780434600552587
	Mflow:		0.000221126708091242
	(G)cc:		0.00138013306848898

B	1.07	  74.258	  79.247	  78.860
M	1.07	  74.319	  79.267	  78.887
A	1.07	  74.327	  79.271	  78.934


m88ksim/m88ksim-wptime.stats03:


WPT
---
Standard Deviation / Mean:
	DyC:		0.00102377002406287
	Mflow:		0.000358791712742291
	(G)cc:		0.000246452269437317

B	1.07	  74.249	  79.229	  78.822
M	1.07	  74.293	  79.244	  78.852
A	1.07	  74.315	  79.256	  78.853


m88ksim/m88ksim-wptime.stats05:


WPT
---
Standard Deviation / Mean:
	DyC:		0.00188541769171594
	Mflow:		0.000466520856927278
	(G)cc:		0.000382547521050226

B	1.07	  74.376	  79.220	  78.856
M	1.06	  74.586	  79.260	  78.876
A	1.06	  74.577	  79.273	  78.884


m88ksim/m88ksim-wptime.stats07:


WPT
---
Standard Deviation / Mean:
	DyC:		0.00197980042782884
	Mflow:		0.000225764813408327
	(G)cc:		0.000365904499753131

B	1.07	  74.269	  79.226	  78.837
M	1.06	  74.482	  79.246	  78.867
A	1.06	  74.470	  79.254	  78.877


m88ksim/m88ksim-wptime.stats11:


WPT
---
Standard Deviation / Mean:
	DyC:		0.000841111164069156
	Mflow:		0.000386335893435237
	(G)cc:		0.000267105996590275

B	1.06	  74.969	  79.200	  78.854
M	1.06	  75.073	  79.265	  78.869
A	1.06	  75.067	  79.253	  78.880


Date: Sun, 4 Oct 1998 16:23:55 -0700
From: eggers@yakima (Susan Eggers)
To: spin-comp@cs
Subject: change in strategy

Craig --

Since Markus is unfamiliar with perl and the strength reduction
implementation is in the merger, we thought his time would be
better spent getting grep working.  Matthai will do strength
reduction after he finishes dead code elimination (best case
Monday, probably Tuesday).  If we don't have strength reduction
done by the submission, we'll just be honest with what we've
done and how far along we are.

Susan

To: eggers@cs
cc: spin-comp-archive@cs
Subject: % of time spent in dynamic region for whole programs
Date: Mon, 05 Oct 1998 09:59:53 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

I'm reporting two numbers.  "cumulative" includes callees, which matches the
region times I sent you (which measured speedup, including the time of
callees).  The "non-cumulative" number is time just spent in the actual
body of code we specialize.  I measured it using prof on the cc-compiled
version.  If the function has no callees, then the numbers will be the same.

I thought the %time in m88ksim's region was greater.  I'll try a different
input.

			cumulative	non-cumulative		callees?
m88ksim:ckbrkpts	9.8%		9.8%			no
dinero:mainloop		100.0%		49.9%			yes
mipsi:run		100.0%		100.0%			yes

--Brian

Date: Mon, 5 Oct 1998 10:56:57 -0700
From: eggers@yakima (Susan Eggers)
To: eggers@cs, grant@cs.washington.edu
Subject: Re: % of time spent in dynamic region for whole programs
Cc: spin-comp-archive@cs


It would be better to have numbers that reflect the time spent
in the dynamic regions, omitting that spent in unspecialized callees
(non-cumulative).  You probably have more important things on
your plate than redoing these numbers, so I'll use the cumulative
ones for now, for consistency.

Susan

To: spin-comp@cs
Subject: progress on opengl
Date: Mon, 05 Oct 1998 12:08:55 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

FYI, here are the latest times for gears.  We're currently getting slowdown
in the shader.   I'm trying to determine why.

Note: these totals include dynamic-compilation overhead.

--Brian

demos/gears_dyc_noop 2500 100
DyC WPT Total time: 6.402186 seconds
Accumulated time for project_and_cliptest: 350107418 cycles
Number of invocations of project_and_cliptest: 45018
Accumulated time for execute_list: 6605965826 cycles
Number of invocations of execute_list: 7503
Accumulated time for gl_color_shade_vertices: 0 cycles
Number of invocations of gl_color_shade_vertices: 0
Accumulated time for gl_color_shade_vertices_fast: 440214173 cycles
Number of invocations of gl_color_shade_vertices_fast: 45018


demos/gears_dyc 2500 100
DyC WPT Total time: 6.638265 seconds
Accumulated time for project_and_cliptest: 304544307 cycles
Number of invocations of project_and_cliptest: 45018
Accumulated time for execute_list: 4281826618 cycles
Number of invocations of execute_list: 7503
Accumulated time for gl_color_shade_vertices: 0 cycles
Number of invocations of gl_color_shade_vertices: 0
Accumulated time for gl_color_shade_vertices_fast: 504952749 cycles
Number of invocations of gl_color_shade_vertices_fast: 45018


Date: Mon, 5 Oct 1998 13:25:10 -0700
From: eggers@yakima (Susan Eggers)
To: spin-comp@cs
Subject: the paper

I've put the latest copy of the paper in /projects.  You should
only read up to the results section.  The results numbers I have are
in the paper, but there is no discussion.

Craig wants to change the order of the optimizations in section 2.2.
So he should get the lock on the paper next.  (Craig: can you
call me at home when you get back to your office?)

Susan

Date: Mon, 5 Oct 1998 14:01:15 -0700
From: eggers@yakima (Susan Eggers)
To: spin-comp@cs
Subject: paper

I'm going to assume that until I hear from Craig, I still have
the lock on the paper.


Susan

Date: Mon, 5 Oct 1998 17:48:52 -0700 (PDT)
From: Markus Mock <mock@cs.washington.edu>
To: spin-comp@cs.washington.edu
Subject: BTA update

I checked in the changes to the BTA to support the new weak/strong
policies that should help us annotating some benchmarks.

With the default 'strong' policy a make_static annotations behaves as
known, with the 'weak' policy the make_static annotation has no effect if
the annotated variable is not already static at the point of the
annotation. This is handy to change the policy of a variable w/o the risk
of creating new divisions if the variable is not already static.

Update the following files:
bta-v2.C bta-v2.H bta_util-v2.C bta_util-v2.H  and dyc2c in the bin dir.


	-- Markus


Date: Mon, 5 Oct 1998 22:10:22 -0700
From: eggers@yakima (Susan Eggers)
To: spin-comp@cs
Subject: fodder for tomorrow's meeting

Something to discuss in the meeting tomorrow:

This is a partial list of data we are missing.  We should talk about
which are the most important for the paper as its going to turn out
to be (which is different than what we originally conceived it) and
which can be realistically done by the deadline.  Don't change course
now -- we'll discuss this all tomorrow.
 
(1) number of lines in dynamic regions
(2) check experiimental 'C and Tempo papers to make sure our analysis
doesn't contradict theirs.
(3) automated graphs for importance of particular opts
(4) all numbers on OpenGL and grep
(5) copy prop, strength reduction and register actions
(6) instruction mix analysis
(7) cache 1 in OpenGL
(7) Not having no LU is a problem.  This includes the current greater
speedups in dinero without it.
(8) loss in performance has to be relative to the same statically compiled
version.
(9) Nice to have some accumulative analysis, in which optimizations were
continually applied.  This would illustrate nicely when there is a
dependence between optimizations, namely that applying one enables others
and not applying that one disables them.  A graph showing the flattening
performance gains within the group would do this.
(10) Lots of points of analysis that Brian and I proposed can't be
done because we don't have the data to do so yet.  I won't repeat them
here, but will just bring the outline to the meeting.

Susan

Date: Tue, 6 Oct 1998 10:17:13 -0700
From: eggers@yakima (Susan Eggers)
To: spin-comp@cs
Subject: instruction mix analysis

This would be most useful for the dynamic regions, not whole programs.
At least not now.  So let's forget about a whole program analysis 
until after the paper submission.

Susan

Date: Tue, 6 Oct 1998 11:07:41 -0700 (PDT)
From: chambers@klamath (Craig Chambers)
To: spin-comp@cs
Subject: paper lock

I'm grabbing the write lock on the first part of the paper, through section 2.

-- Craig

Date: Tue, 6 Oct 1998 12:06:29 -0700
From: eggers@yakima (Susan Eggers)
To: spin-comp@cs, chambers@klamath
Subject: Re: paper lock

And I have the lock on the paper starting at section 3.

Susan

To: spin-comp@cs
Subject: profiles from mesa (opengl): gears
Date: Tue, 06 Oct 1998 17:16:49 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

execute_list is no longer a candidate, but I've included here, fyi.

gears:

With rendering commented out:
#2  15.4   0.5635   34.2      1.25 gl_color_shade_vertices_fast (shade_normal.c)
#3  14.8   0.5420   49.0      1.79 project_and_cliptest (vbxform_normal.c)
#6   9.1   0.3330   79.3      2.90 execute_list (dlist_normal.c)

We couldn't comment out rendering (seg. fault) for viewperf.  I relinked
with profiling, but too many procedures remained unidentified, so I'm not
sure which ones should be subtracted out.  I will have to rebuild the whole
library with -g3, I think, in order to get good profiles.  I'm  doing that
now.

--Brian

To: spin-comp@thistle.cs.washington.edu
Subject: more mesa profiles
Date: Tue, 06 Oct 1998 17:36:50 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

Subtracting out suspected rendering routines.

gears top routines:

 18.6      0.7354   18.6      0.74 gl_xform_normals_3fv (xform.c)
 14.6      0.5771   33.3      1.31 gl_color_shade_vertices_fast (shade_normal.c)
 12.3      0.4834   45.5      1.80 project_and_cliptest (vbxform_normal.c)
 11.0      0.4346   56.6      2.23 viewport_map_vertices (vbxform.c)
 10.1      0.3965   66.6      2.63 vertex3f_normal (vbfill.c)
  9.3      0.3662   75.9      2.99 execute_list (dlist_normal.c)

viewperf test #2 top routines:

 30.7      1.3330   30.7      1.33 gl_color_shade_vertices_fast (shade_normal.c)
 22.3      0.9707   53.0      2.30 execute_list (dlist_normal.c)
 10.7      0.4658   63.7      2.77 project_and_cliptest (vbxform_normal.c)
  8.6      0.3750   72.4      3.14 viewport_map_vertices (vbxform.c)
  6.0      0.2598   78.3      3.40 vertex3f_normal (vbfill.c)

--Brian

Date: Tue, 6 Oct 1998 18:00:19 -0700 (PDT)
From: chambers@klamath (Craig Chambers)
To: spin-comp@cs
Subject: paper

I'm done with my first pass through section 2 (and a little before that).  I've
done substantial rewriting and reorganization, but I haven't done any
proofreading.  Please read it ignoring little writing details but rather to 
get a sense of the organization and level of detail.  I eagerly await your
feedback.

-- Craig

Date: Tue, 6 Oct 1998 18:01:57 -0700 (PDT)
From: chambers@klamath (Craig Chambers)
To: spin-comp@cs
Subject: Re: paper

P.S. My copy of the paper is in /homes/rivers/chambers/papers/pldi/99/paper.doc.

-- Craig

To: spin-comp-archive@cs
Subject: Markus' recent fix yields new microbenchmark?
Date: Wed, 07 Oct 1998 02:42:40 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

Markus' recent BTA fix of one of the loop bugs fixed fft and one version
of xvalg (doBlurConvolv).  We still don't get speedup on that version of
xvalg, but we do for some vector lengths on fft.  In fft, we're
specializing on the length of the vector.  If several loops are unrolled,
we get speedups on the short vector lengths (16 - 20%, 32 - 16%, 64 - 3%),
due to eliminating calls to sin and cos.  Performance decreases as the size
of the generated code grows bigger than the L1 cache (for 64 and beyond).
If one of the loops is not unrolled, we can't eliminate these calls, but
still get about a 3% speedup for these smaller sizes.

--Brian

To: spin-comp@franklin.cs.washington.edu
Subject: Looks like dynamic dead-code elimination works...
Date: Wed, 07 Oct 1998 11:01:40 PDT
From: Matthai Philipose <matthai@franklin.cs.washington.edu>

Code produced looks good. I'm committing it to cvs; times should be 
coming around pretty soon.

I'm moving on to strength-reduction, right?
		Matthai

Date: Wed, 7 Oct 1998 11:13:50 -0700
From: eggers@yakima (Susan Eggers)
To: spin-comp@franklin.cs.washington.edu, matthai@cs.washington.edu
Subject: Re: Looks like dynamic dead-code elimination works...


right

To: spin-comp@cs
Subject: awesome DCE numbers
Date: Wed, 07 Oct 1998 13:02:48 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

Numbers are starting to come in from pnmconvol.

00:BEST
M       7.32    0       156     1081      1.454  10.639

Woo hoo!

Of course, this is with an 11x11 convolution matrix of all zeroes.  Now to
try with a more interesting matrix...

--Brian

To: spin-comp@cs
Subject: pnmconvol and DCE
Date: Wed, 07 Oct 1998 13:28:44 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

Without dead-code elimination, performance plummets because the amount of
generated code exceeds the size of the L1 cache by a factor of 2.7.  If
we reduced the size of the convolution matrix, we should get speedup.
We'd have to reduce the matrix to 7x7 or 5x5 in order to fit in L1.

--Brian

--------------------
pnmconvol:do_convol
--------------------
00:BEST
	76810241111:	M	7.32	0	156	1081	  1.454	 10.639
01:BEST-FD
	76810241111:	M	6.33	0	161	1083	  1.681	 10.639
05:BEST-SL
	76810241111:	M	0.74	inf.	7	7725	 14.456	 10.639
11:BEST-LH
	76810241111:	M	7.29	0	158	1087	  1.459	 10.639
13:BEST-ZC
	76810241111:	M	3.32	0	60	2171	  3.207	 10.639
14:BEST-DC
	76810241111:	M	0.92	inf.	17	5437	 11.584	 10.639


Date: Wed, 7 Oct 1998 13:40:17 -0700
From: eggers@yakima (Susan Eggers)
To: spin-comp@cs, grant@cs.washington.edu
Subject: Re: pnmconvol and DCE


Can you put this in context -- isn't the norm a screen size?
Or am I (hopefully) wrong?

Susan

To: spin-comp@franklin.cs.washington.edu
Subject: re: pnmconvol and DCE
Date: Wed, 07 Oct 1998 13:47:54 PDT
From: Matthai Philipose <matthai@franklin.cs.washington.edu>

Hmmmm.... this brings up the interesting observation that 
full-unrolling based optimizations can sometimes be made more 
reasonable (in terms of cache-space consumption) by dead-code 
elimination.
                Matthai

---------------------
Without dead-code elimination, performance plummets because the 
amount of
generated code exceeds the size of the L1 cache by a factor of 2.7.  
If
we reduced the size of the convolution matrix, we should get speedup.
We'd have to reduce the matrix to 7x7 or 5x5 in order to fit in L1.

--Brian

Date: Wed, 7 Oct 1998 15:16:16 -0700
From: eggers@yakima (Susan Eggers)
To: spin-comp@cs
Subject: results section

I've put a file called lookAtMethResults.doc in /projects.
The file name tells you what sections you should read.  Some places
I've left markers -- some of these you can address, some I've marked
so that they can be changed when the OpenGl and grep numbers come in.
The latest results from pmnconvol have been incorporated.

Can you take a look at it and let me know any comments.  If you have
comments on paper, can you give them to Hank and I'll ask him to
bring them home.  Otherwise turn on bars in your own copy or give a call.
I'm assuming that Brian, Matthai and Markus will read for untruths
and omissions, but will not concentrate on style, since they have
other things on their plates, and Craig will comment on writing.

After today the amount of time I can spend on the paper gets cut
by about two thirds.

Susan

To: spin-comp@cs
Subject: pnmconvol
Date: Wed, 07 Oct 1998 15:18:18 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

We didn't get speedup for the smaller matrix with DCE off.

Legend:
11111000	11x11, all zeroes
551000		5x5, all zeroes
997911		9x9, 79% zeroes, 11% ones, a few 0.5 and -0.5


--------------------
pnmconvol:do_convol
--------------------
00:BEST
	11111000:	M	7.32	0	156	1081	  1.454	 10.642
	551000:		M	4.75	0	232	259	  0.528	  2.506
	997911:		M	2.68	0	90	1455	  2.689	  7.204
01:BEST-FD
	11111000:	M	6.30	0	164	1083	  1.689	 10.642
	551000:		M	3.38	0	255	261	  0.743	  2.506
	997911:		M	2.47	0	95	1457	  2.923	  7.204
05:BEST-SL
	11111000:	M	0.74	inf.	7	7725	 14.304	 10.642
	551000:		M	0.80	inf.	15	1659	  3.127	  2.506
	997911:		M	0.74	inf.	8	5207	  9.693	  7.204
07:BEST-RA
	11111000:	M	7.32	0	156	1081	  1.453	 10.642
	551000:		M	4.75	0	237	259	  0.528	  2.506
	997911:		M	2.68	0	89	1455	  2.689	  7.204
11:BEST-LH
	11111000:	M	7.30	0	157	1087	  1.459	 10.642
	551000:		M	4.58	0	233	265	  0.548	  2.506
	997911:		M	2.71	0	91	1460	  2.659	  7.204
13:BEST-ZC
	11111000:	M	3.33	0	60	2171	  3.197	 10.642
	551000:		M	2.58	0	98	485	  0.973	  2.506
	997911:		M	1.11	0	49	2085	  6.516	  7.204
14:BEST-DC
	11111000:	M	0.92	inf.	17	5437	 11.592	 10.642
	551000:		M	0.94	inf.	33	1159	  2.658	  2.506
	997911:		M	0.90	inf.	19	3759	  8.010	  7.204


Date: Wed, 7 Oct 1998 21:33:53 -0700 (PDT)
From: chambers@klamath (Craig Chambers)
To: spin-comp@cs
Subject: paper 

I've finished my second pass through the first 2 sections of the paper. The
latest version of this is in ~chambers/papers/pldi/99/paper.{doc,mif}.

-- Craig

Date: Wed, 7 Oct 1998 23:21:28 -0700
From: eggers@yakima (Susan Eggers)
To: spin-comp@cs
Subject: latest version of the pape

I've combined Craig and my sections, and made another editing pass
over the whole thing.  It can be found in 
/projects/dyncomp/Papers/PLDI99/paperCombined.doc.

Susan

To: spin-comp@cs
Subject: future work
Date: Thu, 08 Oct 1998 15:33:25 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

Are we supposed to fill in future work in the conclusion?

If so, here is my list of possibilities:

- Fix the loop bug
- Dynamic switches
- Efficient one-time lazy edges
- Different program inputs
- Compare mesa specialized routines with original hand-specialized ones
- Measurement of DyC-introduced overhead
	- Unchecked dispatches
	- Cache lookups
	- Table-pointer builds
	- Sceduling constraints
- Instruction alignment
- Look at instructions generated for accessing run-time constants
  (immediates, loads, etc.)
- Smarter load hoisting
- General instruction-mix analysis
- Analysis of benefit in mipsi of our support for unstructured code
- More benchmarks
- Real strength reduction
- Register actions (ha! this time we mean it!)

Did I miss anything?

--Brian

Date: Thu, 8 Oct 1998 15:39:31 -0700
From: eggers@yakima (Susan Eggers)
To: spin-comp@cs, grant@cs.washington.edu
Subject: Re: future work

We should probably be realky short and sweet in the conclusion.
We are currently 7400 words on a 5000 word budget.

Susan

Date: Thu, 8 Oct 1998 15:41:20 -0700
From: eggers@yakima (Susan Eggers)
To: spin-comp@cs, grant@cs.washington.edu
Subject: Re: future work


Actually, now that I've read the list, ;-) it looks like a good
to-do list for us.  I'm hoping for some grander thoughts in the
conclusion, i.e., a real conclusion.  Be thinking what all these
results have told us.

Susan

To: spin-comp@franklin.cs.washington.edu
Subject: suggestions for conclusions
Date: Thu, 08 Oct 1998 17:21:40 PDT
From: Matthai Philipose <matthai@franklin.cs.washington.edu>

I'll send more around as/if I think of them.

---------------
0. Dynamic compilation can give significant speedups on real-world 
programs for reasonable inputs. However (in a manner reminiscent of 
static optimizations) a variety of optimization techniques (in 
different combinations) are necessary for maximum benefit.

1. Given the modest (on average) whole-program speedups and the 
relative sophistication of the annotations, most users will require 
signficant automation of annotation choices. The fact that safe 
annotations are not too bad makes the prospects of automation 
brighter. The fact that @ signs are used a lot means that good 
side-effect analysis will be very important. Conditional 
specialization allows us to "risk" dynamic compilation only if 
conditions are [very likely to be] favorable.
 
----------------


Date: Thu, 8 Oct 1998 18:34:36 -0700 (PDT)
From: chambers@klamath (Craig Chambers)
To: spin-comp@cs
Subject: cache policy annotations

I want to talk to someone about what non-default (cache-all) cache policies we
use in the benchmarks.

-- Craig

To: spin-comp@cs
Subject: mesa numbers: project_and_cliptest
Date: Thu, 08 Oct 1998 19:23:02 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

Measured using viewperf test #2.

For measuring mesa, we have somewhat different methology than for the other
programs, unfortunately.  The reasons are:

-- the regions are deeply embedded in the client programs and are not
   easily extracted for timing
-- some regions are invoked from multiple call sites
-- the regions in mesa are called with different arguments and execute
   different paths for each call
-- we want to subtract away rendering overhead, which accounts for most of
   the execution time
-- we've been having problems with cache effects dominating performance

Methodology:

- In one run, measure whole-program speedup.
	- Iterate over the rendering routine many times to overcome the
	  coarse granularity of getrusage.  Subtract this rendering time
	  from the total.
	- Do that 10 times and take the median.

- In another run, measure region speedup.
	- Each time the function containing the dynamic region is invoked,
	  loop over the region a large number of times to overcome the 
	  coarse granularity of the timer.
	- Do that 10 times and take the median.

- In yet another run, measure dynamic-compilation overhead.
	- Use the cycle counter to measure DC overhead.
	- Do that 10 times and take the median.

project_and_cliptest is called with two different sets of run-time constants.
The first set is used during initialization.  The second set is used forever
after.  After the initialization, I'm currently doing a reset to invalidate
the first set.  project_and_cliptest is only called about 70 times with the
first set, so we might not want to specialize the function for that set at
all.

For now, I just have region speedups.  No overhead, #instrs, etc. yet.
mesa isn't integrated into our framework to the level that the other
benchmarks are.  Hence, producing these numbers is much more tedious.
I plan to measure region speedups on the shader next.

project_and_cliptest


Actual speedup for 252800 invocations of the region:

00:BEST
1.31
01:BEST-FD
1.31
03:BEST-PS
1.31
05:BEST-SL
1.25
07:BEST-RA
1.31
11:BEST-LH
1.31
13:BEST-ZC
1.22
14:BEST-DC
1.31

We can't yet explain these results, however.  We didn't expect _any_
speedup for 05, and expected much less speedup for 11, 13, and 14.
One of us may do an instruction-mix analysis to find out what is going
on.  A quick glance showed that the statically compiled version is doing
a lot of moves that aren't there in the dynamically compiled version
(i.e., Multiflow produces fewer moves for the DyC version).  Since
float moves are as costly as multiplies, and this could account
for much of the difference.

--Brian


Date: Thu, 8 Oct 1998 21:22:32 -0700 (PDT)
From: chambers@klamath (Craig Chambers)
To: spin-comp@cs
Subject: paper

I've editing the related work to be very short, and written a conclusion
based on Matthai's text and our earlier conversation.  See
 ~chambers/papers/pldi/99/closing.{mif,doc}.
 
-- Craig

To: spin-comp@thistle.cs.washington.edu
Subject: paper editting
Date: Thu, 08 Oct 1998 22:01:25 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

I'm going to make a pass over the paper.  A number of inaccuracies need
to be fixed.  Which version should I start with?  

--Brian

Date: Thu, 8 Oct 1998 22:08:06 -0700
From: eggers@yakima (Susan Eggers)
To: spin-comp@cs
Subject: Re: paper editting

I have the most current copy except for related work and the conclusion.
I'll put a copy in /projects called paperCombined3.doc.

I'm currently reading over 2.2.5 and will continue to the end.
When I finish, I'll put this plus Craig's related work and conclusion
into paperCombined4.doc and put it in /projects.

If you want to read the related work and conclusion now, just take
it from where Craig said it was.

Sound reasonable?
Susan

Date: Thu, 8 Oct 1998 22:10:17 -0700
From: eggers@yakima (Susan Eggers)
To: spin-comp@cs
Subject: Craig and Brian

Can you discuss what to do with this?

Susan


To: chambers@klamath (Craig Chambers)
cc: spin-comp@cs
Subject: Re: paper 
Date: Thu, 08 Oct 1998 22:11:34 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

>> I've editing the related work to be very short, and written a conclusion
>> based on Matthai's text and our earlier conversation.

I like it.

Wrt. "much larger programs":
FYI, m88ksim's dynamic region, ckbrkpts, is not significantly different
from the kernels.  pnmconvol is only slightly larger.  A similar program
from the same image-processing package, ppmdither, was previously used as
a kernel by Consel & gang.

--Brian

To: spin-comp@cs
Subject: Re: caching description
Date: Thu, 08 Oct 1998 22:46:19 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

Susan wrote:
>> Can you discuss what to do with this?

On one hand, merge caching is a unique and essential feature of our system.
On the other, it is not one of the features/optimizations we're evaluating
in this paper.

I'm inclined to drop its description and example from that paragraph.

--Brian

To: spin-comp@cs
Subject: section 2.2.4: policy annotations
Date: Thu, 08 Oct 1998 22:52:44 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

"Policy annotations" are not run-time optimizations.  Why is there such
a section?  It seems like "caching" and "speculative vs. demand-driven"
(or "eager vs. lazy") should be the section titles.  Other optimizations
controlled by the annotations are described in their own subsubsections:
polyvariant specialization and division, promotions, static loads and calls,
etc.

--Brian

To: spin-comp@cs
Subject: new numbers on pnmconvol using a (slightly) more realistic matrix
Date: Thu, 08 Oct 1998 22:59:16 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

An 11x11 convolution matrix with 83% zeroes, 9% ones, and a few other entries.

Region times:

--------------------
pnmconvol:do_convol
--------------------
00:BEST
        1111839:        M       3.00    0       91      1961      3.505  10.530
01:BEST-FD
        1111839:        M       2.78    0       95      1963      3.784  10.530
05:BEST-SL
        1111839:        M       0.74    inf.    7       7725     14.185  10.530
07:BEST-RA
        1111839:        M       3.00    0       90      1961      3.505  10.530
11:BEST-LH
        1111839:        M       3.05    0       93      1966      3.458  10.530
13:BEST-ZC
        1111839:        M       2.11    0       48      2927      4.999  10.530
14:BEST-DC
        1111839:        M       0.90    inf.    18      5561     11.671  10.530


whole program times:

00:BEST
M       2.86       3.772          10.773          11.988
01:BEST-FD
M       2.68       4.020          10.781          12.002
05:BEST-SL
M       0.75      14.462          10.788          12.000
07:BEST-RA
M       2.87       3.753          10.777          11.995
11:BEST-LH
M       2.88       3.739          10.777          11.993
13:BEST-ZC
M       2.01       5.350          10.777          12.003
14:BEST-DC
M       0.90      11.942          10.779          12.004

--Brian

Date: Thu, 8 Oct 1998 22:59:22 -0700
From: eggers@yakima (Susan Eggers)
To: spin-comp@cs
Subject: paperCombined4.doc

is now in /projects.

Susan

To: eggers@yakima (Susan Eggers)
cc: spin-comp@cs
Subject: Re: paperCombined4.doc 
Date: Thu, 08 Oct 1998 23:01:50 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

Thanks.  If everyone else is planning to sleep, then I'll claim the lock
on the whole paper.

--Brian

To: spin-comp@cs
Subject: shader
Date: Thu, 08 Oct 1998 23:54:59 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

We're still getting slowdown on the shader.  I don't think it is cache
effects.  I'm running instruction-mix analysis on it now.  Markus is working
on instruction-mix analysis for project_and_cliptest.

--Brian

To: spin-comp@thistle.cs.washington.edu
Subject: releasing lock - no changes
Date: Thu, 08 Oct 1998 23:55:39 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

I haven't made changes to the paper yet, but I have to go home.

--Brian

To: spin-comp@cs
Subject: instruction-mix analysis on the shader
Date: Fri, 09 Oct 1998 09:00:54 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

I ran IMA over many executions of the shader.  On random executions that I
traced before, we removed a significant number of instructions.  However,
over these many runs, unless something is wrong with my scripts, it appears
that we actually increase the number of executed instructions by nearly 6%,
including a BIG increase in loads.  Load hoisting is probably doing something
stupid.  Unfortunately, zcprop doesn't seem to work on the shader with
load-hoisting off. :-(  Something fixable by the final paper, perhaps.
Note the decrease in float operations.

--Brian

	All instructions:   	381159	402953		5.7% increase
	float operations:   	131028	105074		19.8% decrease
	memory operations:  	130311	207801		59.5% increase
	integer operations: 	101537	70692		30.4% decrease
	loads:              	81069	132285		63.2% increase
	mult:               	53953	41988		22.2% decrease
	lds:                	46077	39164		15.0% decrease
	addq:               	35898	20876		41.8% decrease
	fmov:               	31739	30440		4.1% decrease
	lda/ldah:           	27111	21901		19.2% decrease
	addt:               	23048	11027		52.2% decrease
	stores:             	22131	53615		142.3% increase
	ldah:               	21099	19493		7.6% decrease
	conditional branches:	16868	16306		3.3% decrease
	ldt:                	16712	38002		127.4% increase
	clr:                	16315	7870		51.8% decrease
	ldq:                	10974	47829		335.8% increase
	stq:                	10076	12655		25.6% increase
	s4addl:             	9360	6248		33.2% decrease
	insbl:              	7798	9372		20.2% increase
	addl:               	7519	6268		16.6% decrease
	sts:                	6059	32716		440.0% increase
	lda:                	6012	2408		59.9% decrease
	extbl:              	5997	3164		47.2% decrease
	cvtts:              	4994	7827		56.7% increase
	cvtql:              	4706	9101		93.4% increase
	fbne:               	4686	2833		39.5% decrease
	stl:                	4477	4686		4.7% increase
	beq:                	4395	1582		64.0% decrease
	ldq_u:              	4391	3124		28.9% decrease
	ldgp:               	4061	248		93.9% decrease
	cmptlt:             	3813	1271		66.7% decrease
	subt:               	3224	682		78.8% decrease
	fbge:               	3144	4706		49.7% increase
	bne:                	2957	1686		43.0% decrease
	ldl:                	2915	4166		42.9% increase
	and:                	2852	310		89.1% decrease
	sll:                	2728	1748		35.9% decrease
	s4addq:             	2604	4166		60.0% increase
	cmpult:             	1644	1644		0.0% change
	fbeq:               	1624	1333		17.9% decrease
	cmpteq:             	1562	0		100.0% decrease
	xor:                	1519	248		83.7% decrease
	stt:                	1519	434		71.4% decrease
	or:                 	1455	4890		236.1% increase
	ret:                	1415	144		89.8% decrease
	cmpule:             	1333	62		95.3% decrease
	cpyse:              	1333	62		95.3% decrease
	global loads:       	1333	18372		1278.2% increase
	sra:                	1333	62		95.3% decrease
	subl:               	1271	0		100.0% decrease
	fcmoveq:            	1271	0		100.0% decrease
	fcmovne:            	1271	0		100.0% decrease
	zapnot:             	1271	0		100.0% decrease
	srl:                	186	186		0.0% change
	andnot:             	124	124		0.0% change
	mov:                	124	124		0.0% change
	subq:               	124	124		0.0% change
	cmple:              	62	62		0.0% change
	bge:                	62	62		0.0% change
	cvtqt:              	62	62		0.0% change
	fclr:               	52	52		0.0% change
	mulq:               	20	20		0.0% change
	global stores:      	0	0		0.0% change
	mskbl:              	0	3124		infinite increase
	stq_u:              	0	3124		infinite increase
	fble:               	0	2833		infinite increase
	jmp:                	0	1562		infinite increase
	br:                 	0	1312		infinite increase
	cmptle:             	0	1291		infinite increase
	fblt:               	0	1271		infinite increase
	divt:               	0	1271		infinite increase
	jsr:                	0	62		infinite increase


Date: Fri, 9 Oct 1998 09:05:17 -0700
From: eggers@yakima (Susan Eggers)
To: spin-comp@cs
Subject: paper


I've taken paperCombined4.doc and am making changes to it.  I've
reset the change bars, so you can see what the new changes are.

Susan

Date: Fri, 9 Oct 1998 09:09:33 -0700
From: eggers@yakima (Susan Eggers)
To: grant@cs.washington.edu, spin-comp@cs
Subject: Re: instruction-mix analysis on the shader


Then can you look at the results table in the paper,
and think about which NA entries you can guess will be
what value?  We have to decide whether by putting SD
for slowdown in the entries where we have numbers <1
and the entries where you expect numbers <1, we have
a respectable enough table to put into the paper.  Or
whether we should just go with textual results.

Susan

To: eggers@yakima (Susan Eggers)
cc: spin-comp@thistle.cs.washington.edu
Subject: table 4, the shader
Date: Fri, 09 Oct 1998 09:25:47 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

mipsi:
	- the NA for static loads should be SD
	- the NA for program-point promotions: we might want to comment that
	  we haven't yet constructed a fair comparison to compensate for
	  lack of this feature
	- there should be no SD for polyvariant division, which we currently
	  don't do

pnmconvol:
	- the NA for loop unrolling should be SD

test_2: (can we call this viewperf-2?)
	- no NA for static calls or polyvariant division

Given our current shader results, I think we should remove it from the tables
and just mention that we are experimenting with other promising candidates
for dynamic compilation in the library that use interesting features, including
polyvariant division, run-time zero/copy prop, and run-time dce.

--Brian

Date: Fri, 9 Oct 1998 09:36:11 -0700
From: eggers@yakima (Susan Eggers)
To: spin-comp@cs
Subject: that policy pargraph

As a compromise,  I've kept Craig's paragraph the way it is
(because it described a unique feature) and added after the
discussion of promotion caching that we evaluate it only.

Brian still has a second set of comments on this.

Susan

Date: Fri, 9 Oct 1998 09:38:52 -0700
From: eggers@yakima (Susan Eggers)
To: spin-comp@cs
Subject: no more mif files

They stripe table captions.  From now til the deadline we'll have to use
frame5.

Susan

To: spin-comp@cs
Subject: bogus instruction mix for shader
Date: Fri, 09 Oct 1998 10:48:13 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

The instruction-mix analysis I sent out was bogus.  Markus noticed a problem
with the way gdb is generating some traces.  I'll take a look and rerun it.

--Brian

To: spin-comp@cs
Subject: whole-program speedup for viewperf
Date: Fri, 09 Oct 1998 12:03:55 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

We get about 2%, which is somewhat less than the 3% we expected.  This
benchmark spends a lot more time in the shader, where we were also hoping
to get significant speedup.

--Brian

To: spin-comp@cs
Subject: new IMA for shader
Date: Fri, 09 Oct 1998 13:32:20 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

For many invocations of the shader:


	All instructions:   	702417	524225		25.4% decrease
	memory operations:  	317720	260039		18.2% decrease
	loads:              	197139	168475		14.5% decrease
	float operations:   	175982	119276		32.2% decrease
	integer operations: 	158848	109782		30.9% decrease
	lds:                	95918	48556		49.4% decrease
	stores:             	85138	67915		20.2% decrease
	mult:               	66617	45112		32.3% decrease
	addq:               	51818	38078		26.5% decrease
	fmov:               	45720	35250		22.9% decrease
	ldq:                	43519	54199		24.5% increase
	lda/ldah:           	35443	23649		33.3% decrease
	ldt:                	33834	44332		31.0% increase
	sts:                	31743	39004		22.9% increase
	addt:               	29694	11027		62.9% decrease
	conditional branches:	28240	19450		31.1% decrease
	stq:                	26941	15981		40.7% decrease
	ldah:               	26474	21055		20.5% decrease
	s4addl:             	21844	14058		35.6% decrease
	clr:                	20190	7890		60.9% decrease
	br:                 	18817	12286		34.7% decrease
	ldl:                	16349	15140		7.4% decrease
	insbl:              	14046	14058		0.1% increase
	stl:                	13603	4686		65.6% decrease
	or:                 	10867	8014		26.3% decrease
	cvtql:              	9121	10683		17.1% increase
	lda:                	8969	2594		71.1% decrease
	fbne:               	7539	5977		20.7% decrease
	ldq_u:              	7519	6248		16.9% decrease
	addl:               	7519	6268		16.6% decrease
	stt:                	6603	1996		69.8% decrease
	stq_u:              	6248	6248		0.0% change
	mskbl:              	6248	6248		0.0% change
	extbl:              	5997	6288		4.9% increase
	beq:                	5977	1582		73.5% decrease
	fbge:               	5977	4706		21.3% decrease
	cmptle:             	5977	5977		0.0% change
	ldgp:               	5456	372		93.2% decrease
	cvtts:              	4994	7827		56.7% increase
	sll:                	4290	1748		59.3% decrease
	s4addq:             	4166	4166		0.0% change
	cmptlt:             	3813	1271		66.7% decrease
	subt:               	3224	682		78.8% decrease
	bne:                	2957	1686		43.0% decrease
	fbeq:               	2895	1333		54.0% decrease
	and:                	2852	310		89.1% decrease
	fbgt:               	2833	0		100.0% decrease
	global loads:       	2666	18434		591.4% increase
	cmpult:             	1644	1644		0.0% change
	cmpteq:             	1562	0		100.0% decrease
	xor:                	1519	248		83.7% decrease
	ret:                	1415	144		89.8% decrease
	jsr:                	1333	124		90.7% decrease
	cpyse:              	1333	62		95.3% decrease
	cmpule:             	1333	62		95.3% decrease
	sra:                	1333	62		95.3% decrease
	fcmovne:            	1271	0		100.0% decrease
	fcmoveq:            	1271	0		100.0% decrease
	zapnot:             	1271	0		100.0% decrease
	divt:               	1271	1271		0.0% change
	subl:               	1271	0		100.0% decrease
	srl:                	186	186		0.0% change
	andnot:             	124	124		0.0% change
	subq:               	124	124		0.0% change
	mov:                	124	124		0.0% change
	cmple:              	62	62		0.0% change
	bge:                	62	62		0.0% change
	cvtqt:              	62	62		0.0% change
	bsr:                	62	0		100.0% decrease
	fclr:               	52	52		0.0% change
	mulq:               	20	20		0.0% change
	global stores:      	0	0		0.0% change
	jmp:                	0	3124		infinite increase
	fble:               	0	2833		infinite increase
	fblt:               	0	1271		infinite increase

We should be able to reduce jumps once the loop bug is fixed.

--Brian


To: spin-comp@thistle.cs.washington.edu
Date: Fri, 09 Oct 1998 16:28:38 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>


------- Forwarded Message

Received: from mroe.cs.colorado.edu (mroe.cs.Colorado.EDU [128.138.243.151]) by june.cs.washington.edu (8.8.7+CS/7.2ju) with ESMTP id PAA27887 for <grant@cs.washington.edu>; Fri, 9 Oct 1998 15:58:56 -0700
From: zorn@mroe.cs.colorado.edu
Received: from plague.cs.colorado.edu (plague.cs.colorado.edu [128.138.243.10])
	by mroe.cs.colorado.edu (8.9.1a/8.9.1) with ESMTP id QAA11722;
	Fri, 9 Oct 1998 16:58:55 -0600 (MDT)
Received: by plague.cs.colorado.edu (8.9.1a/8.9.1) id QAA28619;
	Fri, 9 Oct 1998 16:58:55 -0600 (MDT)
Date: Fri, 9 Oct 1998 16:58:55 -0600 (MDT)
Message-Id: <199810092258.QAA28619@plague.cs.colorado.edu>
To: grant@cs.washington.edu
Cc: zorn@microsoft.com
Subject: Your PLDI99 submission 'An Evaluation of Run-time Optimizations'
X-UIDL: 78c9949542b3216e2a1e02961a6d9eb8
Status: U


We sucessfully received a submission from you for PLDI99.

Your submission was 81549 bytes long.
Here is the information we recorded about your submission:
Confirmation#:
 298728291
title:
 An Evaluation of Run-time Optimizations
address:
 Dept. of Computer Science & Eng.
University of Washington
Box 352350
Seattle WA 98195-2350
c-author-name:
 Brian Grant
c-author-email:
 grant@cs.washington.edu
authors:
 Brian Grant, Matthai Philipose, Markus Mock, Susan J. Eggers, and Craig Chambers
abstract:
 Previous dynamic compilation systems have demonstrated that dynamic
compilation can achieve performance improvements at low cost on small
kernels, but have had difficulty scaling to larger programs. To
overcome this limitation, we developed DyC, a dynamic compilation
system that includes more sophisticated and flexible analyses and
transformations. DyC is able to achieve good performance improvements
on programs one and two orders of magnitude larger and more complex
than the kernels. We analyze the individual optimizations of DyC and
assess their impact on performance collectively and individually.

T15-concerns-PROGRAM-ANALYSIS-AND-OPTIMIZATION:
 Somewhat
T50-concerns-incremental-compilation-and-analysis:
 Kind of
T21-concerns-partial-evaluation:
 Greatly
T51-concerns-interpreters-and-virtual-machines:
 Kind of
T28-concerns-PROGRAM-RUNTIME-SYSTEMS:
 Greatly
T23-concerns-CODE-GENERATION:
 Greatly
T31-concerns-runtime-code-generation:
 Greatly

Thank you for submitting to PLDI99.

Once we have verified that we are able to successfully print
your submission, we will email you a confirmation.



------- End of Forwarded Message



Date: Fri, 9 Oct 1998 16:54:34 -0700 (PDT)
From: chambers@klamath (Craig Chambers)
To: spin-comp@cs
Subject: paper

I talked to Susan on the phone, and we discovered some more problems with
the lazy/eager optimization and analysis.  I figured out a modest change to
the analysis, and I made the change and resubmitted the paper.  See the
latest version of the paper at ~chambers/papers/pldi/99/submitted.{doc,ps}.

-- Craig

Date: Mon, 12 Oct 1998 17:19:17 -0700 (PDT)
From: chambers@klamath (Craig Chambers)
To: spin-comp@cs
Subject: no meeting for me this week

I can't meet tomorrow, as I'm working on a grant proposal due next week.

-- Craig

Date: Mon, 12 Oct 1998 18:18:48 -0700
From: eggers@yakima (Susan Eggers)
To: spin-comp@cs, chambers@klamath
Subject: Re: no meeting for me this week


Then let's gather in my room.

Susan

To: eggers@yakima (Susan Eggers)
cc: spin-comp@cs
Subject: Re: no meeting for me this week 
Date: Mon, 12 Oct 1998 22:55:07 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

>> Then let's gather in my room.

I can't meet today because I caught my daughter's flu.

--Brian

To: spin-comp@cs
Subject: print ack for PLDI
Date: Wed, 14 Oct 1998 10:22:34 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>


------- Forwarded Message
Date: Mon, 12 Oct 1998 17:45:42 -0600 (MDT)
From: Ben Zorn <zorn@anchor.cs.colorado.edu>
Message-Id: <199810122345.RAA18728@anchor.cs.colorado.edu>
To: grant@cs.washington.edu, zorn@microsoft.com
Subject: Print acknowledgement for 386897675 to PLDI99

Dear Brian Grant:


We have successfully printed your paper entitled:
"An Evaluation of Run-time Optimizations"
which was received with acknowledgement code 386897675.

Thank you for your submission to PLDI99.


  Sincerely
   Ben Zorn, Program Chair (zorn@microsoft.com)
------- End of Forwarded Message



Date: Wed, 14 Oct 1998 11:59:42 -0700 (PDT)
From: chambers@klamath (Craig Chambers)
To: spin-comp@cs
Subject: tweak to submission.doc

I put in a couple of edits to sections 2.2.3 and 2.2.4 that got lost
right before the submission deadline, into my submission.doc.

-- Craig

Date: Wed, 14 Oct 1998 12:08:06 -0700
From: eggers@yakima (Susan Eggers)
To: spin-comp@cs, chambers@klamath
Subject: Re: tweak to submission.doc


And I've placed a copy of that paper in our /projects area.

Susan

To: spin-comp@cs
Subject: conditional specialization and dynamic compilation on SMT
Date: Fri, 16 Oct 1998 17:12:07 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

In thinking about how to conditional specialization on mipsi, Matthai and I
came up for a design of how to do dynamic compilation in parallel with
execution of unspecialized code (thinking this would be a cool thing to
simulate on SMT).

The basic idea is this: we just use conditional specialization to create
the specialized and unspecialized versions.  The condition includes some
flags we'll set and the thread id.

At the region entry:

{
  if (dyc_compile_finished || (!dyc_thread_compiling && thread_fork())) {
    dyc_thread_compiling = TRUE;
    make_static(....);
  }

  /* dynamic region */
}

So, we need to set the dyc_compile_finished flag when the region is compiled.
This can be done in the merger, for example.  Eventually, the region will be
entered with the specialization complete, and the specialized code will just
be executed.  One other thing we need to do when specialization is complete
is kill the thread doing the specializing, but that can be done by the same
mechanism that sets the dyc_compile_finished flag.

Mipsi is a little trickier.  We enter the region only once, so we'll have
to put similar tests inside the loop as well (only they won't fork).  
We could perhaps insert the tests only at procedure calls, for example, so
that the tests aren't executed at every program point in the interpreted	
program.  (Dinero has a similar problem.)

Conditional specialization of mipsi looks almost the same, except no fork.
The conditions are counts of executions of the procedure entries (or arbitrary
program points).  It would be nice if we could also somehow distinguish loop
heads, but I'm not sure quite how to do this.  Maybe put counters on
unconditional branches, which should only precede merges?  Another issue is
that we may also want to switch from the specialized version back to the
unspecialized version at procedure returns (in the interpreted program).  To
do that, we would keep a stack of flags indicating whether returned-to
procedures were specialized or not.

So, if we want to do either one of these (general conditional specialization
or DC on SMT) there may be some more debugging of polyvariant division, which
Markus and I would have to do, but it shouldn't be too painful (compared to
the shader).

The SMT part seems like a fine thing for a new student to do. :-)

--Brian

To: spin-comp@franklin.cs.washington.edu
Subject: Re: conditional specialization and dynamic compilation on SMT
Date: Fri, 16 Oct 1998 17:29:22 PDT
From: Matthai Philipose <matthai@franklin.cs.washington.edu>

Another idea I have been trying to peddle for a while is that of 
commencing dispatches (like the ones on our promotion point) on a 
separate SMT thread as soon as the dispatched-upon variables are 
defed (this may be in procedures other than the one in which dispatch 
actually happens).

With some reasonable may-def analysis and clever synchronization, 
this should definitely be do-able.

By reducing the visible cost of dynamic compilation, and the cost of 
safety (viz. promotions/checks), SMT is a very interesting enabler of 
auomatic DC. Basically automatic techniques can afford to be a little 
optimistic about what to dynamically compiled, _and_ the resulting 
code produced can be safe/checked.

Some other enablers of automated dynamic compilation that I thought 
up are:
	1. continuous profiling [This will make (value) profiling for 
automation seem less weird, and less visible]
	2. use of garabage collected, typesafe languages [This will make 
side-effect analysis easier, and make it easier to do such tricks as 
putting datastructures in trap-when-written-to memory]. 

	Matthai

To: spin-comp@cs
Subject: The Loop Bug
Date: Tue, 20 Oct 1998 23:54:43 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

I think I found "The Loop Bug."  It is in the BTA.  Variables are static
that shouldn't be.  The likely suspects:

	- The Division meet operator
		The meet operator in our papers is defined to be the
		intersection of the divisions met.  However, this doesn't
		work for loop heads, whose back edges are initialized to
		the empty set (no divisions).  Fortunately (?), the
		implementation unions the divisions instead.  This doesn't
		seem right to me, either.  If a make_static is used inside
		a loop using the monovariant-division policy, shouldn't
		these variables be removed from the division at the loop
		head?
	- The DivisionInfo meet operator
		The paper does specify union for this one, and the
		implementation matches the spec.  However, we appear to
		have the problem that variables found to be dynamic inside
		the loop aren't killed by subsequent iterations of the
		analysis.  Markus has a comment which indicates that all
		variables with multiple reaching definitions should be
		killed upon the first pass over a loop head.  Is this
		sufficient (assuming the reaching defs are correct - see
		below)?
	- The prepass to the BTA that computes which variables have
	  multiple reaching definitions
		This looks like the cause of my immediate problems.  We
		know this prepass is inherently broken (it can't be aware of
		promotions, multiple divisions), but I'll try to patch it.

When I learn more, I'll let you know.

--Brian

To: spin-comp@cs
Subject: Re: The Loop Bug 
Date: Wed, 21 Oct 1998 01:14:58 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

I spoke too soon.  The pass that computes multiple reaching defs is
actually quite simple, clean, and correct.  The actual problem is
related to the bug Markus fixed recently.  A loop head is being identified
as a static merge, which should never happen.

--Brian

To: spin-comp@cs
Subject: loop bug fixed
Date: Wed, 21 Oct 1998 10:02:57 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

Looks like the static-loop-head problem was THE loop bug.  The fix fixed
broken versions of chebychev, pnmconvol, and ppmdither.  We should still
think about what the right meets are, however.

--Brian

ps. All changes are committed (bin, mflow, regression).


To: spin-comp@cs
Subject: ppmdither as a new benchmark
Date: Wed, 21 Oct 1998 10:20:42 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

We currently get slowdown with full optimization, so  we'll have to decide
how much we want to look at it.  We don't expect it to get nearly as much
speedup as pnmconvol, so maybe it's not worth the trouble.

--Brian

Date: Wed, 21 Oct 1998 12:25:20 -0700 (PDT)
From: chambers@klamath (Craig Chambers)
To: grant@cs.washington.edu, spin-comp@cs
Subject: Re: The Loop Bug

> 	- The Division meet operator
> 		The meet operator in our papers is defined to be the
> 		intersection of the divisions met.  However, this doesn't
> 		work for loop heads, whose back edges are initialized to
> 		the empty set (no divisions).  Fortunately (?), the
> 		implementation unions the divisions instead.  This doesn't
> 		seem right to me, either.  If a make_static is used inside
> 		a loop using the monovariant-division policy, shouldn't
> 		these variables be removed from the division at the loop
> 		head?

The backedges should be initialized to the identity value for the
meet operator, for any optimistic iterative analysis.  If intersection
is the right meet operator, then the identity value should be the set
of all possible divisions, i.e., ignore the back edge until it has
some real data.

-- Craig


To: chambers@klamath (Craig Chambers)
cc: spin-comp@cs
Subject: Re: The Loop Bug 
Date: Wed, 21 Oct 1998 12:31:21 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

>> The backedges should be initialized to the identity value for the
>> meet operator, for any optimistic iterative analysis.  If intersection
>> is the right meet operator, then the identity value should be the set
>> of all possible divisions, i.e., ignore the back edge until it has
>> some real data.

Yes, I realize that.  I suppose what I should have asked is whether we should
just make the meet operator intersection instead of union.  It seems to me
that intersection is right, but why did we choose union?

--Brian

Date: Wed, 21 Oct 1998 17:28:54 -0700
From: eggers@yakima (Susan Eggers)
To: spin-comp@cs, grant@cs.washington.edu
Subject: Re: ppmdither as a new benchmark


I would vote for moving on, say to Java.
What is the status of grep?

Susan

To: spin-comp@cs
Subject: new instruction-mix analysis on the shader
Date: Thu, 22 Oct 1998 00:53:49 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

I've moved the annotations outside the loop.  That and other bug fixes
appear to have significantly reduced the number of executed instructions.
I'll run more timings to see if we get speedup now.

Unfortunately, we won't be able to eliminate the float divides.

--Brian

The left column is instrs. executed by the statically compiled version.
The column to the right of that is instrs. executed by the dynamically
compiled version.  %Differences reported on the right.

	All instructions:   	702417	416390		40.7% decrease
	memory operations:  	317720	229005		27.9% decrease
	loads:              	197139	149859		24.0% decrease
	float operations:   	175982	103581		41.1% decrease
	integer operations: 	158848	59598		62.5% decrease
	lds:                	95918	56865		40.7% decrease
	stores:             	85138	66470		21.9% decrease
	mult:               	66617	27536		58.7% decrease
	addq:               	51818	12946		75.0% decrease
	fmov:               	45720	36171		20.9% decrease
	ldq:                	43519	47671		9.5% increase
	lda/ldah:           	35443	12676		64.2% decrease
	ldt:                	33834	27079		20.0% decrease
	sts:                	31743	47153		48.5% increase
	addt:               	29694	19526		34.2% decrease
	conditional branches:	28240	19450		31.1% decrease
	stq:                	26941	7949		70.5% decrease
	ldah:               	26474	10082		61.9% decrease
	s4addl:             	21844	4686		78.5% decrease
	clr:                	20190	0		eliminated
	br:                 	18817	4448		76.4% decrease
	ldl:                	16349	11996		26.6% decrease
	insbl:              	14046	6248		55.5% decrease
	stl:                	13603	4686		65.6% decrease
	or:                 	10867	9636		11.3% decrease
	cvtql:              	9121	5977		34.5% decrease
	lda:                	8969	2594		71.1% decrease
	fbne:               	7539	1271		83.1% decrease
	ldq_u:              	7519	6248		16.9% decrease
	addl:               	7519	6248		16.9% decrease
	stt:                	6603	434		93.4% decrease
	stq_u:              	6248	6248		same
	mskbl:              	6248	6248		same
	extbl:              	5997	4706		21.5% decrease
	beq:                	5977	1562		73.9% decrease
	fbge:               	5977	0		eliminated
	cmptle:             	5977	5977		same
	ldgp:               	5456	372		93.2% decrease
	cvtts:              	4994	4994		same
	sll:                	4290	3310		22.8% decrease
	s4addq:             	4166	2604		37.5% decrease
	cmptlt:             	3813	1271		66.7% decrease
	subt:               	3224	682		78.8% decrease
	bne:                	2957	1706		42.3% decrease
	fbeq:               	2895	6039		108.6% increase
	and:                	2852	310		89.1% decrease
	fbgt:               	2833	0		eliminated
	global loads:       	2666	15961		498.7% increase
	cmpult:             	1644	1644		same
	cmpteq:             	1562	0		eliminated
	xor:                	1519	248		83.7% decrease
	ret:                	1415	144		89.8% decrease
	jsr:                	1333	124		90.7% decrease
	cpyse:              	1333	62		95.3% decrease
	cmpule:             	1333	62		95.3% decrease
	sra:                	1333	62		95.3% decrease
	fcmovne:            	1271	0		eliminated
	fcmoveq:            	1271	0		eliminated
	zapnot:             	1271	0		eliminated
	divt:               	1271	1271		same
	subl:               	1271	0		eliminated
	srl:                	186	186		same
	andnot:             	124	124		same
	subq:               	124	124		same
	mov:                	124	124		same
	cmple:              	62	62		same
	bge:                	62	62		same
	cvtqt:              	62	62		same
	bsr:                	62	0		eliminated
	fclr:               	52	52		same
	mulq:               	20	20		same
	global stores:      	0	0		same
	fblt:               	0	5977		new
	fble:               	0	2833		new
	jmp:                	0	40		new

To: spin-comp@cs
Subject: shader speedup!
Date: Thu, 22 Oct 1998 01:14:56 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

But, fairly small.  We apparently get about 1.12x.

--Brian

To: spin-comp@cs
Subject: bug status
Date: Thu, 22 Oct 1998 01:21:02 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

I need to double-check, but I think only one version of one benchmark isn't
working (pnmconvol with reachability off), other than the ones that
have dynamic switches.

--Brian

To: grant@franklin.cs.washington.edu
cc: spin-comp@franklin.cs.washington.edu
Date: Thu, 22 Oct 1998 09:54:17 PDT
From: Matthai Philipose <matthai@franklin.cs.washington.edu>

Good, good! Let me know if there are any other problems in the 
backend/merger.
         Matthai

-----------------
I need to double-check, but I think only one version of one benchmark 
isn't
working (pnmconvol with reachability off), other than the ones that
have dynamic switches.

--Brian


To: spin-comp@franklin.cs.washington.edu
Subject: dynamic-to-static promotion vs. polyvariant specialization
Date: Thu, 22 Oct 1998 18:20:45 PDT
From: Matthai Philipose <matthai@franklin.cs.washington.edu>

This is something I've been wondering for a while. Is it useful to 
consider dynamic-to-static promotion as a form of polyvariant 
specialization where the degree of polyvariance of the specialized 
variable in a given unit (i.e. instance of specialization context) is 
unbounded?

This as opposed to bounded polyvariance, as happens e.g. at merges 
(the number of different versions in a given unit is bounded by the 
number of control flow paths along which the static variable is 
modified). Turns out that at merges, not only is the number of 
versions bounded, but we can also associate each polyvariant version 
with a unique program-point flowing into the merge. We can therefore 
optimize away the dispatch at the merge by branching directly to the 
appropriate specialized version of code whenever the related program 
point is executed (as we do with our merge patching).

It seems that understanding the kinds of polyvariance in this way 
(i.e. degree and nature of polyvariance) is at least good for faster 
dispatches. For instance, take one datapoint we don't consider: 
bounded polyvariance, where the polyvariant values are not 
attributable to control flow (for instance type information may tell 
us that a variable has one of some set of values). If the bound is 
very small (or if the polyvariance is very skewed towards a very 
small subset) e.g. two values, we may choose to use a branch instead 
of (or in combination with) a dispatch table to implement the 
dispatch. This seems like the stuff people in the OO world do for 
dynamic dispatches.

Just some "deep thoughts" at the end of a long day!
				Matthai

To: Matthai Philipose <matthai@cs.washington.edu>
cc: spin-comp@cs
Subject: Re: dynamic-to-static promotion vs. polyvariant specialization 
Date: Fri, 23 Oct 1998 08:56:24 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

>> This is something I've been wondering for a while. Is it useful to 
>> consider dynamic-to-static promotion as a form of polyvariant 
>> specialization where the degree of polyvariance of the specialized 
>> variable in a given unit (i.e. instance of specialization context) is 
>> unbounded?

Susan and I have discussed whether we should present dynamic-to-static
promotions as just the most aggressive form of polyvariant specialization.

>> This as opposed to bounded polyvariance, as happens e.g. at merges 
>> (the number of different versions in a given unit is bounded by the 
>> number of control flow paths along which the static variable is 
>> modified). Turns out that at merges, not only is the number of 
>> versions bounded, but we can also associate each polyvariant version 
>> with a unique program-point flowing into the merge. We can therefore 
>> optimize away the dispatch at the merge by branching directly to the 
>> appropriate specialized version of code whenever the related program 
>> point is executed (as we do with our merge patching).

Merge polyvariance is not necessarily bounded.  The differences are that we
know the values of the polyvariant variables at specialization time in
advance of the merge and, as you pointed out, that the static variables
have one set of values on each (dynamic) path to the merge.

>> It seems that understanding the kinds of polyvariance in this way 
>> (i.e. degree and nature of polyvariance) is at least good for faster 
>> dispatches. For instance, take one datapoint we don't consider: 
>> bounded polyvariance, where the polyvariant values are not 
>> attributable to control flow (for instance type information may tell 
>> us that a variable has one of some set of values). If the bound is 
>> very small (or if the polyvariance is very skewed towards a very 
>> small subset) e.g. two values, we may choose to use a branch instead 
>> of (or in combination with) a dispatch table to implement the 
>> dispatch. This seems like the stuff people in the OO world do for 
>> dynamic dispatches.

Good idea.  I have thought of ways to speed up dispatches.  It is true that
if you know more about the values being dispatched upon, you can make faster
dispatches.  For a single promoted value, there are a number of possible
optimizations.  For example, a jump table for the bounded case you mention, or
a series of tests for a very small number of possibilities, much like the
implementation of switches in the static compiler.  One could also keep
track of the most frequently occurring values and use dynamically generated
PIC-style dispatches.  Or, custom hash functions.  Suppose you know that the
static value will be a power of two. Then, you could use the base-2 log of
the value as a table index.  The question is: do any of these examples appear
in our benchmarks?  So far, only mipsi has (potentially) significant
polyvariance at promotions.  And, its degree of polyvariance depends on the
input program.  So, we'd probably have to use the dynamic technique, rather
than being able to figure out anything statically.  It's something I've
thought about doing, but would be a non-trivial amount of work.  I'll think
about it as I implement the dynamic jump-table patching.  Maybe there are
similarities.

--Brian


Date: Fri, 23 Oct 1998 10:50:47 -0700
From: Matthai Philipose <matthai@cs.washington.edu>
To: Brian Grant <grant@thistle.cs.washington.edu>
Subject: intelligent polyvariant dispatches and mipsi

Brian brought up some interesting points in his response to my mail on classifying
polyvariance to better enable optimized dispatching. I've tried to clarify three
points that I thought would be useful .

The most interesting part of this mail is point (3) below; it looks like there's a
cool, easy way to speed up some (maybe most) of the promotion points in mipsi,
based on observations that the polyvariance at these points is very skewed to one
value.

1.
---My original mail:
>> This as opposed to bounded polyvariance, as happens e.g. at merges
>> (the number of different versions in a given unit is bounded by the
>> number of control flow paths along which the static variable is
>> modified).Turns out that at merges, not only is the number of
>> versions bounded, ....

---Brian's observation:
>Merge polyvariance is not necessarily bounded.  ...

---My clarification:
I guess what I'm saying is that for each execution of an instance of a unit, merge
polyvariance is bounded.  This is not so in the d/s promotion case, because of
which we need a cache check for each dynamic instance of a unit (i.e. we need a
cache-check in the code we stitch). As we see in the mipsi example below, it is
per-instance info on polyvariance that we care about.

2.

>> It seems that understanding the kinds of polyvariance in this way  [rationale
for techniques to characterize polyvariance snipped]...

>Good idea.  I have thought of ways to speed up dispatches.  It is true that
>if you know more about the values being dispatched upon, you can make faster
>dispatches. [... description of many cool dispatch optimizations snipped...]

I guess what I'm saying boils down to coming up with some systematic way of
describing what we know about the values being dispatched upon. What are the kinds
of things we want to know about the values? Some important aspects seem to be
whether we can bound the number of polyvariant values _for a unit instance_ at
stitch time, whether we can say anything about the distribution of these values,
and whether we can attribute each of these values to upstream control flow. Seems
to me that a characterization of the kinds of polyvariance and the corresponding
dispatch optimizations would be useful, since we the problem of figuring out which
dispatch optimization to use boils down to detecting which kind of polyvariance
holds.

3.

>The question is: do any of these examples appear in our benchmarks?  So far, only
mipsi has (potentially) significant
>polyvariance at promotions. [suggestion to use dynamic monitoring followed by
Polyvariant Inline Caching Snipped]

Dynamic collection of info followed by dynamic optimization is certainly one
powerful (though as you note, not particularly easy to implement, in our
framework) way to apply intelligent dispatching to mipsi. This technique (in its
more general form), will work on any dynamic dispatch at the expense of some
run-time overhead.

On the other hand, seems to me that even static techniques for characterizing
polyvariance can be substantially beneficial for mipsi. Consider the case of the
jsr opcode in mipsi; it's a computed jump, there must be a promotion point after
it. We can know just from static value profiling that ____for a given instance of
this  unit___ (i.e. for a given value of pc, the dispatch is, in the
overwhelmingly common case, to the very first jump target encountered by this jump
instance). So the dispatch should be implemented as a test on the first
jump-target pc, and the code should be laid out assuming this test will succeed.
Is this cool or what?

A similar technique can probably be used to optimized promotions after the
"return" opcode.

Another cool aspect of this optimization is that it can clearly be automated.

                Matthai


Date: Fri, 23 Oct 1998 12:17:13 -0700
From: eggers@yakima (Susan Eggers)
To: spin-comp@cs
Subject: staging discussion

Tuesday Nov. 10 at 1:30 is fine with Craig and Markus for talking
about a paper on staging.

Susan

Date: Fri, 23 Oct 1998 12:19:49 -0700
From: eggers@yakima (Susan Eggers)
To: spin-comp@cs
Subject: do I have the mail aliases for spin-comp?

If someone else does, can you add Mark Berryman (markb) to it?

Susan

To: eggers@yakima (Susan Eggers)
cc: spin-comp@cs
Subject: Re: do I have the mail aliases for spin-comp? 
Date: Fri, 23 Oct 1998 12:37:03 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

I see you already modified the list.  You could change it to group dyncomp
and make it group writable.

Mark needs to be added to the Unix groups dyncomp and mflow as well.

--Brian

Date: Fri, 23 Oct 1998 15:08:16 -0700
From: eggers@yakima (Susan Eggers)
To: spin-comp@cs
Subject: WCSSS

Charles Consel (as general chair) and Jim Larus (as program chair)
are going to organize the second invited workshop on Compiler Support
for System Software (WCSSS'99).  Charles is unfortunately not going
to come through on his promise to hold the workshop in the Caribbean --
it's Atlanta instead.

Check
http://www.irisa.fr/compose/wcsss99/wcsss99.html
for more detail.  It might be nice to submit something here, even if
a short paper.  Give this some thought, and let's discuss on Tuesday.

Susan

To: spin-comp@franklin.cs.washington.edu
Subject: Possible way to substantially speed up floating-point apps
Date: Fri, 23 Oct 1998 15:09:21 PDT
From: Matthai Philipose <matthai@franklin.cs.washington.edu>

We just realized that multiflow performs all FP ops in double 
precision (and converts back to single-precision if needed) as per 
the old C spec (the new C spec allows single precion ops for single 
precion operands). This dramatically increases the time spent in 
operations we can't eliminate in both project_and_cliptest and the 
shader (a single-precision divide on the shader takes 10 cycles, vs. 
double precision takes 6 cycles). Further each convert format 
operations takes 6 cycles.

I'm going to look in multiflow's intermediate representation lowering 
phase to see if I can avoid this conversion. Keep your fingers 
crossed!
	Matthai

To: spin-comp@cs
Subject: bugs fixed
Date: Wed, 28 Oct 1998 17:34:56 PST
From: Brian Grant <grant@thistle.cs.washington.edu>

I believe that all bugs in tested versions of our benchmarks are fixed.
There is one feature we need to implement to complete the tests: dynamic
switches (dynamically allocating jump tables and patching their entries).

Update bin, lib, mflow.

--Brian

To: spin-comp@cs
Subject: Architectural Support for Dynamic Compilation and Runtime Feedback 
Date: Mon, 02 Nov 1998 09:22:57 PST
From: Brian Grant <grant@thistle.cs.washington.edu>

--------------------------
Architectural Support for Dynamic Compilation and Runtime Feedback 
Project Proposal, CS 252, Fall 1998
Marat Boshernitsan, Alyosha Efros (with David Oppenheimer)

We plan to investigate dynamic compilation that uses runtime information to continuously perform traditional back-end compiler
optimizations as a program executes. This project draws on two threads of earlier work: dynamic compilation and profile-driven
optimization. [rest omitted]

http://www.cs.berkeley.edu/~maratb/cs252/proposal.html
--------------------------

I get weekly e-mail about how our web site is accessed.  Usually, it is just
accessed locally or from the TickC related-work page.  Occasionally, a new
link appears, like this one.

--Brian

To: Markus Mock <mock@cs.washington.edu>
cc: spin-comp-archive@cs
Subject: Re: constraining grep 
Date: Mon, 02 Nov 1998 14:14:31 PST
From: Brian Grant <grant@thistle.cs.washington.edu>

The problem in grepdfa is not due to constraints.  The hole markers are
actually inserted in the wrong order (see grepdfa.restruct.dot).  In my
code, the "ordinary" static operations are copied first from the original
BBLOCK, and holes replaced with place-holder stores.  Lazy-edge code is
inserted later, and new holes can be added by context-building operations.
These should be inserted after all previous holes but in this case,
place-holders 15_0_2 and 15_0_3 were inserted before 15_0_1.  15_0_4,
which corresponds to a demotion, was appended last.

The bug is most likely at the bottom of 
p2dyc/setup.C:dyc_InstantiateLazyEdgeAsPush(), if you want to take a look.
My version of the compiler isn't currently debugable, since I'm in the middle
of changing inter-unit branch patching.  If you want me to debug using yours,
let me know.

--Brian

My guess is that SetupSource has a place-holder store for some reason.  What
to do about that is another ball of wax.  If you could confirm that this
is the problem, that would be a big help.  You want to break when
BBLOCK_DYC_INFO_TemplateNumber(SetupSource) == 15.  (You'll have to expand
that macro.)

	IF (BBLOCK_DYC_INFO_BlockType(TemplateSource) == DYC_BBLOCK_TEMPLATE) {
	    SetupPreviousBlock = dyc_GetSoleBlockPredecessor(SetupSource);

	    /* NextHoleId should be updated by this */
	    dyc_CopySetupStats(PreviousBlock, SetupPreviousBlock,
			       BBLOCK_DYC_INFO_TemplateNumber(SetupSource),
			       BBLOCK_DYC_INFO_SetupSubnumber(SetupSource),
			       &BBLOCK_DYC_INFO_NextHoleId(SetupSource));
	    dyc_CopySetupStats(TemplateSource, SetupSource,
			       BBLOCK_DYC_INFO_TemplateNumber(SetupSource),
			       BBLOCK_DYC_INFO_SetupSubnumber(SetupSource),
			       &BBLOCK_DYC_INFO_NextHoleId(SetupSource));
	}

Date: Mon, 2 Nov 1998 14:49:06 -0800 (PST)
From: Markus Mock <mock@cs.washington.edu>
To: Brian Grant <grant@thistle.cs.washington.edu>
cc: spin-comp-archive@cs
Subject: Re: constraining grep 

> My guess is that SetupSource has a place-holder store for some reason.  What
> to do about that is another ball of wax.  If you could confirm that this
> is the problem, that would be a big help.  You want to break when
> BBLOCK_DYC_INFO_TemplateNumber(SetupSource) == 15.  (You'll have to expand
> that macro.)
> 

That seems to be the case:

call dg_Dump_Dot_Bblock(SetupSource)
	bblock94 [label=" BBlock 94 (unit 15, D)\lDivision 0:  83
ST<_s1$1.2>t574 0x0(P64) dfaexec.rtconst_15_0_1 
_DyCRT_StaticValueTable$1.0\l 82 TAG_ANCHOR
[tag(dfaexec.dyn_setup_end_15_0)(P64)]\l"];
	bblock94 -> bblock480;

You know probably best where to go from here.


	-- Markus




To: Markus Mock <mock@cs.washington.edu>
cc: spin-comp-archive@cs
Subject: Re: assertion failure 
Date: Tue, 03 Nov 1998 14:14:03 PST
From: Brian Grant <grant@thistle.cs.washington.edu>

>> can you give me a hint what kind of bogosity in the BTA might cause
>> Expression ( (BBlock == NULL) || (BBLOCK_dfo_number(CurrentBBlock) >
>> BBLOCK_dfo_number(BBlock)) ) evaluated to FALSE at (file:line) p2dyc/setup.C

This assertion is failed when a unit is found to contain a loop (more
specifically, a back edge).  I currently expect all loop heads to be unit
heads as well.  There are two possible causes of this condition:

1) A loop that should be unrolled doesn't have discordant variables at its
loop head.

2) A loop that shouldn't be unrolled for some reason doesn't have a dynamic
exit test, or any dynamic branches within it.

I took a quick look at int-unroll, and didn't find any discordant variables.
That looks like your problem, in this case.

--Brian

Date: Tue, 3 Nov 1998 14:18:49 -0800 (PST)
From: Markus Mock <mock@cs.washington.edu>
To: Brian Grant <grant@thistle.cs.washington.edu>
cc: spin-comp-archive@cs
Subject: Re: assertion failure 

> 
> 2) A loop that shouldn't be unrolled for some reason doesn't have a dynamic
> exit test, or any dynamic branches within it.
> 
> I took a quick look at int-unroll, and didn't find any discordant variables.
> That looks like your problem, in this case.
> 

Thanks.
What's what I wanted to confirm, I am tracking down where they get
lost now...

	-- Markus
	


To: Jeff Dean <jdean@pa.dec.com>
cc: spin-comp@cs
Subject: Re: Profiling dynamically generated code with DCPI 
Date: Tue, 10 Nov 1998 07:15:43 PST
From: Brian Grant <grant@thistle.cs.washington.edu>

That's great, Jeff.  Thanks.  That is roughly what we had in mind, but any
details/code you could provide would help us along.

--Brian


>> Hi Brian,
>> 
>> Susan left me a voice mail that you folks wanted to be able to use DCPI to 
>> profile code that your dynamic compiler is generating.  I just tried to call 
>> you at your office, but they said that you had left for the day.  In any case, 
>> it is possible to do what you want.  The basic strategy is:
>> 
>> 1) Create something that looks like an image header for an Alpha executable 
>> image and fill in the appropriate fields, and flush the image header to disk.
>> 2) Use the 'dcpictl register' option to register this image with the dcpi 
>> daemon (see 'man dcpictl' for more details).
>> 3) Generate code dynamically into the heap.
>> 4) When your program finishes, write out the dynamically generated code into 
>> the text section of the image file.
>> 
>> Note that for profiling purposes you can't reuse any of your code buffer to 
>> generate multiple different pieces of code.
>> 
>> We have some code that does this image trickery in the context of a Java 
>> compiler that we're working on here.  This allows us to use DCPI to profile 
>> the dynamically-generated code produced by our Java compiler.  I'm checking 
>> with the author of the code that generates the fake images for DCPI to see if 
>> there's an easily extractable piece of code that we can just send you that 
>> does what you want.  If not, I'll at least try to look at the code to give you 
>> more details about what pieces of the iamge header are necessary.  I'll try to 
>> get back to you by the end of the week.  If not, please bug me again, as I'll 
>> be gone all next week.
>> 
>>   -Jeff
>> 
>> 


To: mock@thistle.cs.washington.edu
cc: spin-comp-archive@cs
Subject: grep
Date: Tue, 10 Nov 1998 09:20:47 PST
From: Brian Grant <grant@thistle.cs.washington.edu>

Before I debug grep, I'd like to discuss the code with you:
	- What it does
	- What should be static
	- What we expect to get speedup from

I don't think we should put too much time into grep, however, because it
looks similar to decompress to me.  We may need to implement a custom dispatch
mechanism in order to get speedup overall because I think there will always be
promotions in the innermost loop.

--Brian

To: spin-comp@cs
Subject: transmeta
Date: Fri, 13 Nov 1998 08:02:03 PST
From: Brian Grant <grant@thistle.cs.washington.edu>

http://www.news.com/News/Item/0,4,28737,00.html

To: spin-comp@franklin.cs.washington.edu
Subject: transmeta patent...
Date: Mon, 16 Nov 1998 09:47:10 PST
From: Matthai Philipose <matthai@franklin.cs.washington.edu>

After a quick look at the patent, it strikes me that transmeta is 
what the dynamic compilation project would look like if Paul Allen 
funded it instead of ONR! They have a lot of the tricks we've wanted 
to do, and more, in hardware!
			Matthai

------- Forwarded Message

Date:    16 Nov 1998 09:33:13
From:    Stefan Savage <savage@spinoza.cs.washington.edu>
To:      arch-lunch@cs
cc:      uw-systems@cs
Subject: Transmeta patent

For those who are curious about what's going on at Transmeta (and
aren't working there yet), they've been issued a patent titled: 

"Memory controller for a microprocessor for detecting a failure of
speculation on the physical nature of a component being addressed"

I've only skimmed it, but the patent seems to describe a VLIW
processor (referred to as a "morph host") with an instruction set
translation engine built in (referred to as "code morphing software").
They claim that such a processor can outperform a Pentium Pro using 
1/4
as many gates. Translated instructions are buffered up, so translation
only happens once for loop bodies (they say this instruction
translation buffer is 2MB in their x86 translation version).  The
memory controller referred to in the patent looks like its used to
speed up detection of exceptional conditions like self-modifying code,
disambiguating side-effect free memory accesses from device I/O
accesses, etc... It also looks like its used to rename memory
locations to eliminate unnecessary dependencies on memory addresses
(the obvious win here is to be able to absorb all the useless memory
traffic from the spills in the register poor x86).

In general, it reads more like a technical paper than a patent
(meaning to say that its not horrendously obfuscated ;-)


More info can be found at:
	http://www.patents.ibm.com/details?pn=US05832205__&language=en

- - Stefan


------- End of Forwarded Message



From: Geoff Voelker <voelker@cs.washington.edu>
To: spin-comp@cs
Subject: new alphas
Date: Mon, 23 Nov 1998 11:42:24 -0800 (PST)

Hi, Hank mentioned that the alphas that you are using are fully loaded
with 1.5GB of main memory.  We are doing analyses of very large traces
(e.g., 8GB) for a paper that we are trying to finish in a week, and
being able to use such large memory machines would help us
tremendously.  If the machines are not being heavily used, would it be
possible for members from our group to get accounts and use the
machines for our analyses for the next week?

Thanks,
-geoff

p.s. We have memory on order for the tennis alphas, but it doesn't
     look like it will arrive in time.

Date: Tue, 24 Nov 1998 08:36:20 -0800
From: eggers@yakima (Susan Eggers)
To: spin-comp@cs, voelker@cs.washington.edu
Subject: Re: new alphas
Cc: wolman@cs, levy@cs

Has anyone answered this?  I told Hank that it was fine, depending
on your (Brian, Matthai, Markus) plans for the machines.  But I
couldn't think of anything that would prevent us from lending the
machines.

Susan

Date: Wed, 25 Nov 1998 12:52:23 -0800 (PST)
From: chambers@klamath (Craig Chambers)
To: cecil@cs, spin-comp@cs
Subject: Summer internship at WRL

FYI.

----- Begin Included Message -----

From verghese@pa.dec.com  Wed Nov 25 12:21:08 1998
Delivery-Date: Wed, 25 Nov 1998 12:21:10 PST
Date: Wed, 25 Nov 1998 12:21:12 -0800 (PST)
From: Ben Verghese <verghese@pa.dec.com>
To: chambers@cs.washington.edu
Subject: Summer internship at WRL



                 1999 SUMMER INTERNSHIP OPPORTUNITIES AT WRL

                      Western Research Laboratory
                     Compaq Computer Corporation
                          250 University Ave.
                          Palo Alto, CA 94301


The Western Research Laboratory is a computer systems research group that
was founded in 1982.  At present we have 22 full-time researchers.  Our
goal is to develop new hardware and software design principles that are
later used in Compaq's products.  We test our ideas by designing, building
and using real systems. Examples of lab projects that you may have heard of
include the Itsy Pocket Computer, Shasta: a software-only shared-memory
system, the AltaVista web search engine, and the ATOM program
instrumentation system.

Every summer WRL employs several graduate students on projects related to
our research efforts.  We are now accepting applications for positions
during the upcoming summer (1999).  The positions usually involve work
which is of use to the full-time researchers and of a scope that can
reasonably be completed during the summer months.

To qualify, a student should be enrolled in a PhD program, although
exceptional Masters students will also be considered. While the starting
and ending times for these jobs are flexible and will depend on a student's
individual schedule, individuals will typically be expected to spend three
months at WRL.

WRL is located in the heart of cosmopolitan downtown Palo Alto, within
walking distance of a variety of restaurants and shops, and next to the
Stanford University campus. Palo Alto is situated 30 miles south of San
Francisco in the heart of Silicon Valley.

Ongoing research projects span the following areas:

      	Architectural Simulation
      	Profile-guided Compiler Optimizations
      	Scalable Computer Systems
      	Hardware and Software for Distributed Shared Memory
      	Parallel Applications
      	Performance Studies of User and System Code (esp. database applications)
      	Operating Systems
      	File Systems
      	Distributed Systems
      	Internet Performance
      	Innovative WWW Applications
        Computer-Supported Collaborative Work
        Wireless Multimedia
        Robotics
        Augmented Memory & Wearable Computing
        Pocket Computers: Hardware, system software, and applications
        User Interfaces for small devices
        Power management for portable computers

The above list is not necessarily complete and we encourage excellent
students interested in related areas to apply.  Please see
http://www.research.digital.com/wrl/home.html or e-mail
wrl-interns-coordinator@pa.dec.com for more information about our lab.
        
HOW TO APPLY

1. E-mail your resume to wrl-interns-coordinator@pa.dec.com with "INTERN RESUME"
   in the subject line.  Please ensure that your resume is in plain
   ASCII, not PostScript, and includes the names and e-mail addresses of
   three technical references.  It will be helpful if your message
   specifies the two or three research areas listed above that you are
   most interested in.  You are also encouraged to provide URLs to
   related information and/or to Postscript copies of your resume.

2. Arrange to have each of your references send a letter of recommendation 
   to wrl-interns-coordinator@pa.dec.com with "INTERN RECOMMENDATION" in the
   subject line.  ASCII is preferred, but PostScript is acceptable too.  
   It is your responsibility to ensure that the letters are sent to us; 
   WRL will not contact your references for you.

For full consideration, your resume and recommendation letters must be
received by February 13th, 1999.  We expect decisions will be made on or
before March 31st, 1999.



----- End Included Message -----


To: eggers@yakima (Susan Eggers)
cc: spin-comp-archive@cs
Subject: Re: meeting 
Date: Wed, 25 Nov 1998 14:09:12 PST
From: Brian Grant <grant@thistle.cs.washington.edu>

>> Do you want to chat this week (meaning today), or just wait until
>> next week?

Let's wait until next week.

I wasn't able to coerce Multiflow into producing float store (stt)
instructions, if you can believe that!  I am also now having a related
problem with chebyshev that integer values are being put in float registers.
Multiflow permits this in the case that the values are loaded and stored,
but not otherwise operated upon, in that (possibly split?) live range.  This
screws up the merger, of course, which expects the static values to be in
integer registers.

But, I was able to simply prevent the join from being pushed below any of our
specially constrained operations (e.g., an operation with a hole).  So, I
am now ready to time all versions of mipsi.  With a fix Matthai made to the
merger, I am also ready to time a version of dinero that breaks traces at
static branches in order to prevent bad speculation above the manually
inserted tests for strength reduction.

I'm just waiting for one of Sujay's simulations to finish before I start
timing (about another half hour).

--Brian

To: spin-comp@cs
Subject: DCPI
Date: Tue, 01 Dec 1998 09:43:18 PST
From: Brian Grant <grant@thistle.cs.washington.edu>

I installed the latest version of DPCI on alper and wu.  They'll reboot at
noon with the new kernel.

--Brian

Date: Fri, 4 Dec 1998 16:05:32 -0800
From: eggers@yakima (Susan Eggers)
To: spin-comp@cs
Subject: frame, version 5

From whj@rtfm Fri Dec  4 15:59:37 1998
Received: from rtfm.cs.washington.edu (whj@rtfm.cs.washington.edu [128.95.3.231]) by yakima.cs.washington.edu (8.6.12/7.2ws+) with ESMTP id PAA00306 for <eggers@yakima.cs.washington.edu>; Fri, 4 Dec 1998 15:59:34 -0800
Received: (whj@localhost) by rtfm.cs.washington.edu (8.9.1+CS/7.2ws+) id QAA02299; Fri, 4 Dec 1998 16:01:38 -0800
Date: Fri, 4 Dec 1998 16:01:38 -0800
From: whj@rtfm (Warren Jessop)
Message-Id: <199812050001.QAA02299@rtfm.cs.washington.edu>
X-Mailer: TkReq v1.10.1
To: eggers@yakima.cs.washington.edu
Cc: support@rtfm
Reply-To: support@cs.washington.edu
Subject: Re: [UW-CS #4675] frame, version 5
Status: R

> When I write to the file /projects/dyncomp/Papers/PLDI99/master.doc,
> the owner and group changes to fac_cs rather than remaining dyncomp.
> And my students can't then change the file.
> Can someone look into this?

Somone can look into this, but I'm not sure someone can do anything about it.
A mounted filesystem needs the "grpid" option set in order for the
group to be set to that of the directory instead of the owner of the file
and grpid is supported on Solaris (and other "pure" System V Unix versions)
only for NFS-mounted filesystems.

Since /projects/dyncomp is local to yakima2, the option isn't there.

You will need to do a "chgrp dyncomp" on new files you write under
/projects/dyncomp to put them in that group.

I'm not sure about this, but it's a fair bet that frame might allow some
postprocessing on files, and hence you may be able to get frame to do this
for you.

(I quote from the Solaris "Answerbook": The functionality of the following
flags, defined in <sys/mount.h>, is not supported by the SunOS 5.x releases, 
or the ABI, SVID, or SVR4 versions: M_NOSUB, M_GRPID, M_MULTI.)


Date: Sat, 5 Dec 1998 07:24:23 -0800 (PST)
From: "Markus U. Mock" <mock@cs.washington.edu>
To: La.Niña:;
Subject: =?iso-8859-1?Q?La_ni=F1a_has_arrived!?=

		Andrea Maria 

was born on Friday, December 4th at 7:44pm (PST). She weighs 3,24kg (7lb
2oz) and is 50cm tall (20 inches). She's doing great. Patricia is fine,
just very tired and both she and papa Markus are very happy. 


	-- Markus & Patricia



Date: Mon, 7 Dec 1998 11:30:57 -0800
From: eggers@yakima (Susan Eggers)
To: spin-comp@cs, levy@cs, eggers@yakima, sparekh@cs, redstone@yakima
Subject: affiliates presentations

Let's talk about what we have to present at our meetings this week.
It will look bad if I'm not first in line with a response here.  :-)

Susan

To: spin-comp@cs
Subject: commit of merger changes
Date: Mon, 07 Dec 1998 15:31:54 PST
From: Brian Grant <grant@thistle.cs.washington.edu>

I've committed the instrumented, cleaned up version of the merger's Emit
subroutines.  For our benchmarks, you'll see info in the log files about
how many holes were of the different sizes.  The version also uses ldah/lda
pairs to build 32-bit constants.  This capability is put to use in the
benchmarks primarily to rebuild the gp after function calls, without loading
from our run-time-constants table.  This change eliminates two thirds of the
table-pointer builds in dinero and 100% in mipsi.

New times are being generated right now.  When they are complete, I'll
update the tables in the paper.

--Brian

ps. chebyshev still doesn't work due to Multiflow troubles

Date: Tue, 8 Dec 1998 11:04:36 -0800 (PST)
From: "Markus U. Mock" <mock@cs.washington.edu>
To: Susan Eggers <eggers@yakima.cs.washington.edu>
cc: spin-comp@cs.washington.edu
Subject: Re: affiliates presentations

I'll have to skip our meeting today, Andrea needs to be checked-up today,
and I need to catch up on sleep.


	-- Markus 


On Mon, 7 Dec 1998, Susan Eggers wrote:

   Let's talk about what we have to present at our meetings this week.
   It will look bad if I'm not first in line with a response here.  :-)
   
   Susan
   


To: spin-comp@cs
Subject: scheduling using profile info
Date: Thu, 10 Dec 1998 14:36:05 PST
From: Brian Grant <grant@thistle.cs.washington.edu>

It looks like generating and using the information won't be that difficult.
The information is initialized in the compiler front end, so we should just
need to make minor modifications to our pass to preserve the information for
the back end.

--Brian

To: chambers@cs
cc: spin-comp@cs
Subject: draft of PLDI submission to distribute
Date: Thu, 10 Dec 1998 16:22:42 PST
From: Brian Grant <grant@thistle.cs.washington.edu>

I made a copy:

/projects/dyncomp/Papers/PLDI99/master-bkg.ps

It isn't much changed from the submission.  I put a "Draft, do not distribute"
notice at the bottom, but I don't know how to plaster "DRAFT" across the page.
I also put in a comment about the performance results.  The numbers in the
paper are partially updated based on my new experiments.

Take a look and let me know if you were expecting other changes before
(even limited) distribution.

--Brian

Date: Thu, 10 Dec 1998 16:33:43 -0800
From: eggers@yakima (Susan Eggers)
To: chambers@cs, grant@cs.washington.edu
Subject: Re: draft of PLDI submission to distribute
Cc: spin-comp@cs


We'll hear from PLDI on Jan. 8, so I see no reason to rush to
distribute the paper.  Besides, since we're now profiling, the
results are sure to change somewhat.

What numbers are missing?  Anything other than the shader?

Susan

To: eggers@yakima (Susan Eggers)
cc: spin-comp@cs
Subject: Re: draft of PLDI submission to distribute 
Date: Thu, 10 Dec 1998 16:46:36 PST
From: Brian Grant <grant@thistle.cs.washington.edu>


>> What numbers are missing?  Anything other than the shader?
>> Besides, since we're now profiling, the
>> results are sure to change somewhat.

I have run all of the region times and the whole-program times, except for
mesa.  However, I haven't put all of the numbers from my most recent batch
of runs into the paper because, as you mentioned above, I'm still tweaking
compiler/merger options.  For example, my recent change to how holes were
patched didn't significantly affect speedups, but it increased dynamic
compilation overhead.  So, I'm going to do some runs doing something slightly
different.  I'm also going to look at the profiling, and the effect of
reserving registers in the statically compiled version.  The profiling, in
particular, could also lead me to change other compiler options; for example,
whether we break traces at static branches.

I also ran dinero with different configurations and inputs.  There was
some variation, but the different runs didn't have significantly different
performance.  Not surprising, I suppose, given that I didn't radically change
the cache parameters.  We are looking for significant differences when we
change mipsi's input, however.

--Brian

Date: Thu, 10 Dec 1998 17:08:48 -0800 (PST)
From: chambers@klamath (Craig Chambers)
To: eggers@yakima, grant@thistle.cs.washington.edu
Subject: Re: draft of PLDI submission to distribute
Cc: spin-comp@cs

Vivek Sarkar had asked about reading our PLDI submission, since I mentioned it
to him.  I wanted to send him our submission.  I heard he had fun using `C
when he was at MIT, and I wanted to expose him to the Right Way.

-- Craig

Date: Thu, 10 Dec 1998 18:09:07 -0800
From: eggers@yakima (Susan Eggers)
To: eggers@yakima, grant@thistle.cs.washington.edu, chambers@klamath
Subject: Re: draft of PLDI submission to distribute
Cc: spin-comp@cs


Vivek is hardly a distribution, so this seems fine to me.
Even our submitted copy would be ok.

Susan

Date: Wed, 16 Dec 1998 17:33:37 -0800 (PST)
From: chambers@klamath (Craig Chambers)
To: spin-comp@cs
Subject: Fabius PhD thesis

!!!!

----- Begin Included Message -----

From mock@cs.washington.edu  Wed Dec 16 15:34:04 1998
Delivery-Date: Wed, 16 Dec 1998 15:34:06 PST
Date: Wed, 16 Dec 1998 15:34:02 -0800 (PST)
From: Markus Mock <mock@cs.washington.edu>
Reply-To: Markus Mock <mock@cs.washington.edu>
To: Craig Chambers <chambers@cs.washington.edu>
Subject: Fabius PhD thesis
MIME-Version: 1.0


FYI. There are no details on Fabius' register allocation to be gleaned
from Leone's thesis, since it is non-existent!


	-- Markus

---------- Forwarded message ----------
Date: Mon, 14 Dec 1998 14:54:57 -0500
From: Mark Leone <mark@zoesis.com>
To: Markus Mock <mock@cs.washington.edu>
Subject: Re: PhD Thesis 

No, my thesis is on indefinite hold -- I took a leave of absence from
CMU and I'm now working for a startup company in Boston.

- Mark



----- End Included Message -----


To: spin-comp@cs
Subject: chebyshev fixed!, branch-direction profiling
Date: Thu, 17 Dec 1998 12:43:07 PST
From: Brian Grant <grant@thistle.cs.washington.edu>

Short version:

- changes to bin, lib, mflow, and regression are committed
- chebyshev works
- branch-direction profiling of statically compiled code seems to work, but
  doesn't make a huge difference
- branch-direction profiling for dynamically compiled code has problems


Long version:

chebyshev:

I became frustrated with problems I was having using the branch-direction
profiling for the dynamic code, so I decided to look at the problem with
chebyshev again.  The problem was that what should have been an integer
place-holder store in the setup code was being generated as a float store,
causing the merger to yack.  The merger expects integer constant values
to be in integer registers, so that it can insert operations that use
the values.

I had thought that what I needed to do was to restrict the choice of register
bank for our place-holder stores, but today I noticed that the store was
already bound to a float functional unit before the register bank for its
operand was chosen (it took me a while to figure out where exactly the bank
was selected).  Once I realized that, it wasn't difficult to restrict the
functional-unit selection for the store (about 20 minutes, and just a few
lines of code).  The result is that chebychev works again.


About the branch-direction profiling:

Profiling for the statically compiled version seems to work.  It doesn't seem
to make much difference to performance, however.  I'll collect time 
comparisons for all the benchmarks and send them out.

The main problem with doing the same for the dynamic version seems to be
getting the front end to ignore the boilerplate when both generating and
using the profile information.  I'm still working on that getting that right.


--Brian

To: spin-comp@cs
Subject: improvements in times of statically compiled versions
Date: Fri, 18 Dec 1998 09:18:45 PST
From: Brian Grant <grant@thistle.cs.washington.edu>

I did two things:
	1) Branch-direction profiles
	2) Permitted the statically compiled version to use the two
	   registers we reserve for dynamic compilation.


performance of dynamic regions in multiflow-compiled versions with above
changes:

			than old mflow config.	than gcc -O2
			----------------------	------------
binary:16		same			same
ckbrpts:0		36% faster 		20% faster
chebyshev:10		same			20% faster
dotproduct:100/90%	same			69% faster
query:7			same			40% slower
romberg:6		4% faster		2% slower
dinero:8k/8k		6% faster		13% slower
pnmconvol:11x11		same			11% faster
mipsi:5k		12% faster		17% slower

I'll try to take a look at query to see why it is so much slower.  At least
there are no longer differences on the order of a factor of two!  I think
that was due to optimizations being disabled during development.  I just hadn't
looked at the numbers recently.

--Brian

To: spin-comp@cs
Subject: good news (early)!!!!!!!!
Date: Fri, 18 Dec 1998 09:27:59 PST
From: Brian Grant <grant@thistle.cs.washington.edu>


------- Forwarded Message

Date: Fri, 18 Dec 1998 10:26:39 -0700 (MST)
From: Ben Zorn <zorn@disable.cs.colorado.edu>
To: grant@cs.washington.edu, zorn@cs.colorado.edu
Subject: Submission 386897675 to PLDI 99


Dear Brian Grant:


This note is in regard to your paper with title

An Evaluation of Run-time Optimizations

which was received with confirmation 386897675 for
consideration at PLDI '99

Each paper was read by at least three members of the
program committee as well as two outside reviewers.
In most cases, each reader submitted a written review.

Congratulations!  I am pleased to inform you that the above paper has
been accepted for presentation at PLDI '99 as one of 26 papers
accepted out of 130 papers submitted.

Full versions of the accepted papers must be formatted according to
ACM conventions, and a camera-ready copy and electronic abstract must
be received by the program chair (zorn@microsoft.com) no later than

- --->     19 February 1999, 5 PM Mountain Standard Time    <---

Authors of accepted papers must sign an ACM copyright release form.  I
will send you further details about formatting conventions in
subsequent email.


Thank you for your submission to PLDI 99


   Sincerely
   Ben Zorn, Program Chair

Your reviews follow:

- ---------------------------------

This paper describes DyC, a C compiler that supports optimization
via declarative dynamic compilation, and shows the payoff from
each f the different dynamic optimizations it employs.

A very nice paper.  As intriguing as the various research projects
on dynamic compilation seemed, up until now I've had the idea that
they were still basically toys.  For the first time, I begin to see
the possibility of dynamic compilation actually entering the average
programmer's toolbox.

I didn't understand why Table 4 just says "slowdown" if leaving out
a particular optimization makes the optimized program slower than
the control.  You must have the numbers; why not present them?
If nothing else, it would help to decide just how critical it
is to include such an optimization in a production compiler.

I decided early that DyC must be pronounced "dicey" since I figured
it stood for "dynamic C".  But the chance that it really stood for
"dynamic compiler" and was supposed to be pronounced "dike" was a
constant hindrance to the flow of my reading.  I don't say you should
provide a pronunciation, which might seem a little pedantic, but at
least make it clear what it stands for.

////////////////////////////////////////////////////////////////////////////


This paper is an evaluation of 10 applications and 11 run-time
optimizations.  The system, DyC, requires the user to annotate code to
be optimized at run-time.  A static compiler performs part of each
optimization, and a dynamic compiler uses run-time information to fill
in the blanks.  Some speedups were obtained.

This paper suffers from the Stanford approach to paper writing -- lots
of applications, and optimizations, and the cross-product of them, and
little _insight_ into what's going on.  I think this system could
yield interesting results, and this paper could be re-written to give
much more insight.  Remember, numbers are not the center of research
- -- they are the supporting evidence for the story that you are
telling.  What story are the numbers telling you?


Here are some questions I came away with:

1. Why are any of these optimizations really run-time optimizations?
Why can't they be done at compile-time?

Yes, it is possible to do some of these optimizations at run-time, and
you've implemented them as such.  But wouldn't a little hand-tuning by
the application writer achieve the same goal?  Wouldn't a little more
inter-procedural analysis and loop unrolling achieve most of the
performance gains you've done through heroics like run-time
optimization?

Most of the gain is in loop unrolling, and yet you don't compare
static (i.e. compile-time) loop unrolling to your dynamic loop
unrolling.  I believe there might be some advantage to a dynamic
unrolling approach, but what would it be, and how would it compare to
a smart static compiler?


2. If the paper is really a study of application-level performance, as
opposed to kernel-level performance, why is it that for each
application, there are only one or two small regions which are
annotated?  [Table 1]


3. If the user has to annotate the application, he must have some
fairly deep understanding of it -- i.e. he knows that only a few
constant values are used as loop bounds, or only a few run-time
constants will be used, allowing for constant folding.  The hard part
is to figure all this out -- after he does that, wouldn't it be easier
for him to tweak his application's hot spot rather than go through the
hassle of annotation?


4. Why does the user have to annotate anything at all?  Can't this be
figured out by the static compiler?  Or with static profile
information?  Or with dynamic profile information gathered by
instrumentation or sampling?  You hint at this in the conclusion, but
you need to be more up front that you are evaluating mechanisms, not
proposing the system as an end-user solution.



It seems to me that this paper is really mostly about loop unrolling,
but the fact that you have 11 optimizations listed really obscures
this, since you give the 11 optimizations equal weight through most of
the paper.  As far as I can tell, the other optimizations are all
"supporting" loop unrolling in some way or another.

The paper would be stronger if you did the following:

1. You are up front about the fact that you are evaluating mechanisms,
not proposing solutions.  Your mechanisms will be parts of solutions,
but your system as it is is not a solution.

2. You are up front about not really looking at applications -- you
are looking at kernels in applications.  Nothing to be ashamed of, but
the claim that you were looking at "real applications" really annoyed
and distracted me while I was reading the paper.

3. Organize the paper around loop unrolling, and state this from the
beginning, not be shy about it.  If this is what your numbers are
telling you, then tell us that.  Present the other optimizations
incrementally in the context of supporting loop unrolling, and
describe their interaction.  This is done in a big glob in 4.3 ... but
it's a mess.  Each of these optimizations deserves its own subsection.

4. Do a real, well-thought out comparison with static loop unrolling
- -- I mean a real, macho, loop unroller which can do inter-procedural
constant propagation and procedure cloning or loop cloning.  Explain
what dynamic optimization can do that it can't do and why.

5. Have a running example, to explain the transformations and their
interaction.

6. Have the numbers to confirm your story, not be the story.  I had to
spend a lot of time and energy to figure this out ... this is your
job!

7. Combine tables 2 & 4.  Simplify them -- they are hard to read.
Perhaps order the optimization in reverse importance, starting with
unrolling.  Also, doing just the dynamic region speedup is, IMO,
deceptive.  I didn't figure this out until the 4th or 5th time reading
the paper.  Just do overall speedup, and get rid of Table 5.


I think this work is interesting, but it isn't being presented in a
very useful way, and left too many nagging questions in my mind.


////////////////////////////////////////////////////////////////////////////


The paper presents an evaluation of the DyC (dynamic compilation)
system on some larger benchmarks.

Although the DyC system itself has been presented already (at
PEPM'97), the first half of the paper is devoted to an informal
description of the DyC system.  This part of the paper appears to be
superfluous: it is not precise or clear enough to admit a proper
understanding of the DyC system anyway.  Use more examples,
appropriate formalism, and less text.

The experimental results show that DyC can considerably speed up
realistic programs by judicious use of run-time specialization.  The
methodology is to first profile the program and then handannotate the
most time consuming parts for specialization.

The so-called multi-way loop unrolling is achieved in the Tempo
specializer (Consel et al) by turning jumps into function calls, which
are then specialized at run time.  Because C implementations are so
poor (no general tail call optimization) this is probably less
efficient than DyC's loop unrolling.

Page 2 line 13: it is surprising that dead code elimination brings a
speed-up.  Clearly you save some time if you avoid generating dead
code (which will never be executed), but I don't think that's what you
say.

Page 4: the `internal promotion points' are probably `specialization
points' (Jones, Gomard, Sestoft, Prentice-Hall 1993).

Page 5 footnote 1: The C-mix specializer described in Andersen's
Ph.D. thesis (1994) performs an accurate binding-time analysis of C in
the presence of pointers and structs.

Page 7 line 2: mesa is not mentioned in table 1.

Page 7 line -8: spell out ILP --- this acronym has at least three
different meanings in computer science.

Page 8 table 2: it is unclear what `applicability' means.  I take it
that all programs were actually processed with all optimizations
enabled, and that you just check whether they have any beneficial
effect?  Or did you turn off those optimizations not having a check in
the table (to avoid detrimental effects)?

////////////////////////////////////////////////////////////////////////////


This paper presents an evaluation of the DyC dynamic compiler.  It
presents performance results for fairly large applications and
discusses the applicability and effectiveness of the compiler's
optimizations.  The results show that DyC achieves good performance
improvements on the programs (up to 4.7x speedup).

General Comments:

This paper does a very thorough job of evaluating the DyC dynamic
compiler.  Previous papers that I've seen on dynamic compilation used
small kernels for their benchmarks.  In addition to the kernels, this
paper presents results for complete programs that are fairly large (up
to 15K lines of code).  The main contribution of this paper is that it
shows that dynamic compilers can achieve speedups for realistic
programs.  It also shows that a number of optimizations and analyses
are needed to actually achieve good performance.  The weakest part of
the paper is that it doesn't contain many new ideas.  DyC's structure
and most of its optimizations have already been published elsewhere.


Specific Comments:

2 The DyC Dynamic Compilation System

* The distinction between the what's static and what's dynamic can get
confusing for readers that are not familiar with dynamic compilation,
especially when referring to the dynamic compiler generator and emit
code sequences.  A small example showing exactly what DyC generates
would help make the paper more accessible.

* A brief description of DyC's annotations would give readers a better
feel for how much work the programmer must do to use the system.

* Minor formatting point: The footnote reference on page 1 shows up on
page 2.


3.2 The Experimental Methodology

* The paper says that routines with > 5% of the execution time were
used to choose which routines to dynamically compile, and that
variables whose values changed infrequently were annotated.  Looking
at Table 1, all of the benchmarks had only 1 dynamically compiled
region, with the exception of the renderer which had 2.  The paper
doesn't adequately describe the process for coming up with the
annotations that were used.  Why are there so few dynamic regions in
each benchmark? How often can a variable's value change and still be
considered "infrequent"?

4.2 Performance of Dynamic Regions

* The paper mentions that the main contributor to dynamic compilation
overhead is cache lookups.  It would nice (space-permitting) to see a
quantitative breakdown of the overhead costs.

Table 4:

* I'd rather see the actual data than just "s/d" for the cases 
that had slowdowns.


////////////////////////////////////////////////////////////////////////////


The paper presents an empirical evaluation of the DyC system for
run-time code generation. The major contributions are an evaluation of
the effectiveness of various optimizations and the use of larger
benchmarks.  Some of the optimizations implemented in DyC prove their
effectiveness only in the larger programs.

Detailed comments:

You have two footnotes 1 on page 2.

Although the paper is not primarily about the source end, I would find
it helpful if the paper displayed an example of DyC input.

2.2.6: Are there different templates for different constant sizes?

Mesa-2.4 is not in the public domain, but Copyright (C) 1995-1997
Brian Paul. It is distributed under the terms of the GNU Library
General Public License. If you want a shorthand, write that it's free.

Tables in general: In some tables there's test_2, in others
project&clip etc.  That's confusing.

Table 2: I found it difficult to understand the column headers; it
required quite a bit of work to find what in Section 2 they refer
to. Maybe the topics should be organized in the same order in Section
2 and in the table, or the terms should be emphasised stronger in
Section 2 (boldface?). Is the "unchecked promotion caching" the "one"
or the "all" variant?

4.1: You probably should repeat the observation that only the larger
benchmarks take advantage of some optimizations in the introduction.
At first I was not convinced of the value of larger benchmarks.

Table 4: Why don't you just give the s/d numbers? Since the baseline
case for the "Without" colums is the "With all" column, it would be
useful to also see the slowdown with respect to that column; this
would give a better feeling of the importance of this optimization.

5: Not specific to this paper, but in the run-time code generation
literature I miss references to languages that have provided run-time
code generation capabilities for decades, e.g. Lisp, Prolog and Forth.

Since Fabius works with curried programs, it is not restricted to
first-order programs, unless you have a different definition of
"first-order" than I have.

////////////////////////////////////////////////////////////////////////////


SUMMARY
=======

This paper presents an overview of several run-time optimizations for
dynamically generated code, and evaluates their effectiveness on
medium-size benchmarks.  The experiments show that loop unrolling is
essential to achieving speedup, and that loop unrolling enables other
optimizations which are otherwise of lesser value.

COMMENTS
========

The paper is well written and of general interest to PLDI.  Since this
paper is largely experimental, the originality of the paper is modest.
On the other hand, the authors should be more rigorous in their reporting
of data (see comments below).  In particular, there is no mention of
code size, and slowdown numbers are omitted.  The author's really should
position this as an optimistic view of performance, since the work shows
what a programmer can get by hand-tuning annotations.  Since the long-term
goal is to automate the entire process, it would be interesting (and not
necessarily a negative result) to show how whole program performance
evolves as a programmer tunes the annotations.  This would shed some light
on the challenge of crafting heuristics for the automated system.


DETAILED COMMENTS
=================

=== Introduction

Subject-verb agreement: "reasons ... varies" should be "vary".
Use "partial-evaluation style" instead of "partial evaluation-style".

Which combinations of language features have caused problems with
previous systems?

Footnote 1 not on first page, aliases with footnote 1 on page 2.
In footnote 1, page 1, what is a 'division'?

Subject-verb agreement in footnote 1, page 2: "paper... include".
Spell out "BTA" in Figure 1.

=== Section 2

Overall, this section is well written.

A figure would help in the example of unbounded code generation in
section 2.2.4.

In section 2.2.7, saying that "all downstream references to the target
of the move can be replaced" implies that copy propagation is always
legal; this is not generally true.  Similarly, replacing a multiply
x-by-zero with a clear does not always the computation of x to be dead.

=== section 3

Your overview of benchmarks should follow the same order as table 1;
in particular, test_2 should be described last.

In section 3.2, you should give some description of the number of 
annotations needed in each benchmark (number of routines and variables).
It would also be interesting to know how much tuning of annotations was
needed to get the best results, or how sensitive the results are to
changes in the annotations.

=== Section 4

In table 3, you show one region per benchmark; if multiple regions are
annotated per benchmark, you should give more data.  Table 3 should
also show the observed speedup for these regions, as well as the number of
invocations/checks/searches/etc.

You should use "asymptotic dynamic region speedup" in the first paragraph,
page 9.

A bar-graph of DC overhead with a breakdown of costs would be interesting.

You should say more about why instruction issue width and L1 icache
size determine performance.  Since the dynamic compiler will displace
running code from the icache, how does icache size interact with the
choice of speculation policy?

In table 4, the "all optimization" column has the same values as the
asymptotic speedup column in table 3.
  Are these asymptotic speedups as well?
  Are all speedups asymptotic in table 4?  It would be good to include
     overheads in this table.

Table 4 should list the slowdown numbers.

You should say something about code size.  How much memory did the
workstation have?  What happens if you run several of these programs
simultaneously?

////////////////////////////////////////////////////////////////////////////


The authors present new results for their dynamic compilation
system.  As before, users must insert annotations to identify
dynamic compilation regions and static variables.  The 
contributions of this paper are some new optimization techniques 
(e.g., loop unrolling) and larger programs.  Results show 
loop unrolling was essential for all programs to achieve 
improvements.  Overall application improvements are from 10-370%.

This paper presents improvements over previous work.  However,
there are still remaining issues:

 - Why is the list of benchmarks so small (5 programs)?  Should
    we take this to mean the authors examined many SPEC benchmarks
    and were only able to find one (m88ksim) which was improved?
    Say something about how widely applicable your optimizations are.
    Given current results I get the impression it can be applied
    only to a small subset of programs.

 - Why is loop unrolling so essential, when it can be performed 
    (and is performed) at compile time by the underlying multiflow
    compiler?  Three out of five appliations do not speed up 
    without unrolling, and one speeds up 9% instead of 80%.
    The results make me wonder whether static compilation with
    more unrolling would yield better performance.

 - Compare performance for multiple back ends?  I have no idea 
    whether the multiflow compiler is performing enough optimizations
    at compile time (compared to gcc, DEC's C compiler, etc)
    for the result to be credible.

 - Certain of the dynamic optimizations were presented in the
    author's PLDI'96 paper.  Which dynamic optimizations are new, 
    and how much did they contribute to improvements in performance?  
    It seems many of the dynamic optimizations did not impact
    overall performance, so how do you justify their use?

Mostly, the authors should provide a concrete list of contributions
of this paper over others.

////////////////////////////////////////////////////////////////////////////




------- End of Forwarded Message



To: grant@cs.washington.edu
cc: spin-comp@franklin.cs.washington.edu
Subject: Re: improvements in times of statically compiled versions 
Date: Fri, 18 Dec 1998 10:15:58 PST
From: Matthai Philipose <matthai@franklin.cs.washington.edu>

Cool... if these numbers are right, we our baseline looks comparable 
to gcc -O2, and we should be able to put the below numbers in a table 
in the paper. At least one of the reviewers had the concern that they 
had no idea how good our baseline is.
			Matthai


> I did two things:
> 	1) Branch-direction profiles
> 	2) Permitted the statically compiled version to use the two
> 	   registers we reserve for dynamic compilation.
> 
> 
> performance of dynamic regions in multiflow-compiled versions with above
> changes:
> 
> 			than old mflow config.	than gcc -O2
> 			----------------------	------------
> binary:16		same			same
> ckbrpts:0		36% faster 		20% faster
> chebyshev:10		same			20% faster
> dotproduct:100/90%	same			69% faster
> query:7			same			40% slower
> romberg:6		4% faster		2% slower
> dinero:8k/8k		6% faster		13% slower
> pnmconvol:11x11		same			11% faster
> mipsi:5k		12% faster		17% slower
> 
> I'll try to take a look at query to see why it is so much slower.  At least
> there are no longer differences on the order of a factor of two!  I think
> that was due to optimizations being disabled during development.  I just hadn't
> looked at the numbers recently.
> 
> --Brian
> 


Date: Fri, 18 Dec 1998 10:25:04 -0800 (PST)
From: chambers@klamath (Craig Chambers)
To: grant@cs.washington.edu, matthai@cs.washington.edu
Subject: Re: improvements in times of statically compiled versions
Cc: spin-comp@franklin.cs.washington.edu

> Cool... if these numbers are right, we our baseline looks comparable 
> to gcc -O2, and we should be able to put the below numbers in a table 
> in the paper. At least one of the reviewers had the concern that they 
> had no idea how good our baseline is.
> 			Matthai

I agree: these numbers say multiflow is in the right ballpark, and we're 
not getting speedups solely because of removing junk in our bad baseline.
If we have a plausible story for the one 40% slowdown, that would be even
better.  (query's a microbenchmark, and so one small screwup on multiflow's
part is greatly magnified.)

> 
> 
> > I did two things:
> > 	1) Branch-direction profiles
> > 	2) Permitted the statically compiled version to use the two
> > 	   registers we reserve for dynamic compilation.
> > 
> > 
> > performance of dynamic regions in multiflow-compiled versions with above
> > changes:
> > 
> > 			than old mflow config.	than gcc -O2
> > 			----------------------	------------
> > binary:16		same			same
> > ckbrpts:0		36% faster 		20% faster
> > chebyshev:10		same			20% faster
> > dotproduct:100/90%	same			69% faster
> > query:7			same			40% slower
> > romberg:6		4% faster		2% slower
> > dinero:8k/8k		6% faster		13% slower
> > pnmconvol:11x11		same			11% faster
> > mipsi:5k		12% faster		17% slower
> > 
> > I'll try to take a look at query to see why it is so much slower.  At least
> > there are no longer differences on the order of a factor of two!  I think
> > that was due to optimizations being disabled during development.  I just hadn't
> > looked at the numbers recently.
> > 
> > --Brian
> > 
> 
> 

To: spin-comp@cs
Subject: causes for query's poor performance
Date: Mon, 21 Dec 1998 15:41:46 PST
From: Brian Grant <grant@thistle.cs.washington.edu>

The upshot is that it is due to a few factors:
1) Multiflow inefficiencies in implementing certain code idioms
2) Induction-variable simplification is turned off (because it hoses
   our annotations)
3) Poor scheduling


Details:

The function containing query's dynamic region consists of a single loop
containing two consequtive switch statements.

1) Idiom inefficiencies
    A. Function prologue and epilogue.  For each function, Multiflow always:
	- stores the return address to the stack,
	- copies the return address to another register and back, and
	- copies the argument registers to other registers.
    This introduces an extra 9 instructions per invocation of the function
    containing the dynamic region over gcc.

    B. Switch.
	- Multiflow tests whether the value switched upon is within
	  the range of cases by building the upper bound into a register,
	  performing two compares, and or'ing the results of the compares.
	  That is 4 instructions per switch per loop iteration compared to
	  gcc's 1, an unsigned compare against the upper bound (an immediate;
	  the lower bound is zero).
	- Multiflow builds the jump target address using a shift-and-add and
	  a load instruction that gets expanded into 3 instructions by the
	  assembler/linker.  That's 4 instructions compared to gcc's three
	  (gcc also uses a 32-bit load rather than a 64-bit load).

2) Induction-variable simplification
	Twice per iteration of the loop, the address of q[i] is computed.
	Because we have IVS disabled, five instructions are required to
	load from the array (Multiflow uses shifts&adds rather than int.
	multiply, at least!).  In gcc, only one instruction is needed - the
	load.

3) Scheduling
	The Multiflow-compiled version speculatively executes some
	instructions.  At least one hoisted operation appears to be one that
	is seldom, if ever, needed.

I could run instruction-mix analysis to find out exactly how many extra
instructions the Multiflow version is executing, but I think you get the
idea.  In query's case, we _are_ eliminating instructions that are there
due to Multiflow's inefficiencies: the switches, the loop, and loads from q.
Furthermore, unit boundaries should prevent some of the bad speculation.
The dynamically compiled version still suffers from the function prologue/
epilogue problems, however.

Code for query:

int sq(struct record *d, struct query *q, int n) {
     int i,j;
     int field;
  
     
     i=0;
     for (;i<n; i++) {
       switch (q[i].record_field) {
       case AA:   field = d->a; break;
       case BB:   field = d->b; break;
       case CC:   field = d->c; break;
       case DD:   field = d->d; break;
       case EE:   field = d->e; break;
       case FF:   field = d->f; break;
       case GG:   field = d->g; break;
       }
       switch (q[i].bool_op) {
       case LT: if (field >= q[i].val) return 0;     continue;
       case EQ: if (field != q[i].val) return 0;     continue;
       case LE: if (field >  q[i].val) return 0;     continue;
       case GT: if (field <= q[i].val) return 0;     continue;
       case NE: if (field == q[i].val) return 0;     continue;
       case GE: if (field <  q[i].val) return 0;     continue;
       }
     }
     return 1;
}


--Brian

Date: Tue, 29 Dec 1998 11:42:09 -0800 (PST)
From: chambers@klamath (Craig Chambers)
To: spin-comp@cs
Subject: dyc paper question


----- Begin Included Message -----

From groved@us.ibm.com  Tue Dec 29 06:26:48 1998
Delivery-Date: Tue, 29 Dec 1998 06:26:49 PST
From: groved@us.ibm.com
X-Lotus-FromDomain: IBMUS
To: chambers@cs.washington.edu
Date: Mon, 28 Dec 1998 22:08:23 -0500
Subject: dyc paper question
Mime-Version: 1.0
Content-Disposition: inline

Hi Craig,

     I'm confused by the formulas in section 4.2 of the paper.  In
particular, I'm unclear on the exact defintion of the 'o' variable.  Is
this meant to be (1) the creation-time overhead of actually dynamically
compiling a region for a particular combination of runtime constants or (2)
the per invocation overhead of checking a cache and/or making sure the
dynamically compiled  code is valid?  I would have expected the definiton
of asymptotic speedup to be as=s/d, but the paper defines it as as=s/(d-o).
In this case, I'm guessing 'o' is defined as #2 above. A little wierd, but
I think I understand (do I?).  The second equation defining the breakeven
point is what really threw me: be=o/(s-d+o).  Notice, that for all s,d, and
o where s-d>=o, ie in practice all of them, be<=1.  Bizarro. The only thing
I can think of here is that  the 'o' in the numerator is o as defined by
#1, but the 'o' in the denumetor is o as defined by #2.

--dave




----- End Included Message -----


To: groved@us.ibm.com
cc: spin-comp@cs
Subject: Re: dyc paper question 
Date: Wed, 30 Dec 1998 09:08:23 PST
From: Brian Grant <grant@thistle.cs.washington.edu>

>> particular, I'm unclear on the exact defintion of the 'o' variable.  Is
>> this meant to be (1) the creation-time overhead of actually dynamically
>> compiling a region for a particular combination of runtime constants

The meaning of 'o' is #1.  The assumption is that, asymptotically, the
"one-time" code-generation overhead will be insignificant.  By
asymptotically, we're talking about executing the dynamic region a huge
number of times for a fixed static input.  Hence, the speedup formula
s/(d-o), where d includes both the code-generation time and the time to
execute the dynamically generated code.  Neither d nor o is well described
in the paper; we'll fix that.  Also, because d includes o, the breakeven
formula is o/(s-(d-o)), or o/(s-d+o).  Admittedly, it would be less confusing
if d didn't include o.  We'll consider changing that.

Let us know if you have any more questions.  (The final paper is due Feb. 19.)
--Brian


To: spin-comp@cs
Subject: PLDI final paper
Date: Tue, 05 Jan 1999 12:04:38 PST
From: Brian Grant <grant@thistle.cs.washington.edu>

We need to wrap up the PLDI submission by Feb. 19.  I'd like to wrap
it up before Feb., if possible.  In that spirit, I've gone through
my notes and the reviewers comments to come up with a list of proposed
revisions.  I'd like to discuss at least some of the open issues and
revision proposals at today's meeting.

--Brian


Open issues:
    - Query
        - Should we replace/drop query because of Multiflow's poor code
          generation for it?  If replace, I'm not sure which other
	  TickC/Tempo benchmark we could use, but I could double-check.

    - Dinero
	- Is the decision on strength reduction final?

    - Dotproduct
	The body of dotproduct's loop is:
	      if (uelem) /* we inserted this test on static uelem */
		  result = result + uelem*v[i];

	In the submission, we attributed the speedup due to the test
	we inserted to "strength reduction."  Elimination of the
	multiply and add might be considered to be strength reduction,
	but are very similar to zcprop.  Elimination of v[i] is
	definitely dead-code elimination.  What should we do for the
	final paper?  Is it hard to extend zcprop/DCE to integers?

    - M88ksim and Mesa
	- Should we take another look at other routines to try to
	  improve our whole-program results?


Pushed into TOPLAS or other submissions (discussed already, I think):
    - features
	- conditional specialization
	- lazy specialization
	- internal dynamic-to-static promotions (e.g., when other
	  features are disabled)
	- fast checked dispatch mechanisms
    - varying inputs to the benchmarks
    - analysis
	- instruction-mix analysis
	- DCPI
	- other detailed measurements
	    - dispatch times
	    - hole-patching times


Suggested significant changes to the paper (open for discussion):
    - Downplay annotation policies since we're not evaluating
      them in this paper
    - Eliminate optimizations that were pushed to future work
    - Add an example to section 2
    - Significantly prune the descriptions of the optimizations and
      move them to section 3
    - Some kind of brief discussion about why we don't have more
      benchmarks
    - Swap 4.3 and 4.4


Proposed outline/summary of changes for final version of our paper for
PLDI99 (not really fit for consumption, but ...):

1. Introduction
    Mostly, the same as it is now.
    Changed points:
	- "Safe annotations": correct or eliminate
    New points:
	- Pronunciation of DyC :-)
	- Mechanisms of DC vs. end-user solutions
	- Some optimizations only benefit the larger programs
	- List of contributions of the paper

2. DyC
    - Overview
	- Our approach to DC
	    - Declarative
	    - Specialization
	- High-level, result-oriented (rather than mechanism-oriented)
	  description of capabilities
	    - VSO
	    - Loop unrolling
	- Implementation (more or less what is there already)
    - Example (interpreter?)
	- Show annotated program, input, and dynamically generated code
	- Demonstrate loop unrolling

3. Methodology
    - Study overview (what, why, how)
    - Optimizations
	- Eliminate most discussion about things outside the focus of this
	  paper:
	    - annotations and policies
	    - conditional specialization
	    - lazy vs. eager specialization
	    - internal dynamic-to-static promotions?
	- Define division in main text rather than footnote?
        - Clarify "dead-code elimination"
        - Fix "_all_ downstream references" in zcprop/DCE description
    - Workload: description of benchmarks
	- Mesa: free but not PD
	- Eliminate/replace query as a benchmark?
    - Selection of regions and annotations
	- define "infrequent"
    - Reasons for so few benchmarks?
	- manual parts of process
	- lack of features
	- not amenable to our optimizations
	    - not enough variables with right properties
		- too many different values to dispatch on
		- loops with too many iterations
	    - not enough operations depending only on variables with
	      desirable properties
	- robustness
    - Timing methodology
	- mention how regions were timed as well as whole programs
	- exclude o from d

4. Results and discussion
    Reorganize as indicated below.
    Eliminate table 2.
    Order and name table 4 columns to be same as in s. 3 and below.
    Eliminate columns from table 4
	- lazy vs. eager specialization
	- internal dynamic-to-static promotions?
    Put all numbers in tables, eliminating s/d and n/a.
    Add gcc numbers for comparison.
    Include sizes of statically and dynamically generated code.
    Exclude unspecialized callees from region times (dinero, mesa, mipsi)?

    - All optimizations
	- Asymptotic speedups
	    - Clarify "asymptotic speedups"
	    - Differences between macro and micro benchmarks
	    - gcc vs. mflow
	- Overhead
	- Break even
	- Whole-program performance
	- Factors to consider
	    - Omit comments about architectural effects?
    - Evaluating individual optimizations
	- Loop unrolling
	- Dispatching
	- Static loads and calls
	- Strength reduction, zcprop, DCE
	- Load hoisting

5. Related work
    Mostly the same.
    Reviewers had notes about C-Mix and Fabius.

6. Conclusions



Other reviewer points:
    - Static/dynamic terminology confusing and possibly inconsistent
      (static sometimes referring to static compile time and sometimes
      to DC time?)
    - Spell out ILP
    - Grammar notes of next-to-last reviewer
    - "medium-sized" or "larger" programs rather than "large"


To: spin-comp@cs
Subject: dispatching outline
Date: Tue, 05 Jan 1999 16:25:04 PST
From: Brian Grant <grant@thistle.cs.washington.edu>

To be read after imminent deadlines have passed. :-)

This explores the issue in depth in outline form, not a complete writeup.
The short list of things to implement is:

- streamlining the current implementation of the general lookups
- caching techniques for quasi-invariants
    - invalidation-based caching
    - inline caching (not inlined lookups!)
- staged caching for internal dynamic-to-static promotions
- special-case table lookup for decompress and grep

--Brian

- Implementation of dynamic dispatches for run-time specialization
    - Premise
	- Our current implementation is inefficient and very general
	  (non-trivial hash function, handles collisions, growable
	   tables, arbitrary key length)
	- Some benchmarks require faster checked dispatches
	    - decompress
	    - grep
	    - mipsi (for certain inputs)
	    - mipsi with conditional specialization (a dispatch is
	      required to switch from unspecialized code to
	      specialized code)
	    - benchmarks with other run-time optimizations
	      disabled
	    - "safe" versions of the benchmarks
		- Note: There may be no reasonable "safe" versions of
		  several of the benchmarks due to @s (e.g., mipsi).
		  For these programs, a different approach would be
		  required.  That is beyond the scope of this
		  study.  Matthai has previously mentioned these
		  possibilities (in connection with fully automatic DC):
		    - Invalidate on write
		    - Fingerprinting (see hash functions, below)
		  This might be a good quals topic!
	- Several known alternatives from other contexts (switches,
	  dynamic dispatches, hashing in general)
    - Why is this important?
	- Dispatches are a major determinant of performance
	- Cheap checked dispatches could allow our system to be safe(r)
	- Broadens applicability of DyC, maybe of dynamic compilation
	  in general
	- Strengthens our previous claims / lies within our purported
	  focus
	    - "Real" programs, not just kernels in isolation (at
	      least, "medium-sized," whole programs)
	    - Moving towards full automation
	- Shows that DC systems are maturing by being the first to
	  apply sophisticated (though known) techniques
    - Approach
	- Demonstrate that the cost of the dispatch can be critical
	  for certain applications
	- Identify performance problems in current implementation
	- Present the design space
	    - Unsafe
		- Unchecked: load & jump for invariants (implemented)
		- Checked: explicit invalidation for (quasi-)invariants
		    - load & jump (invalidation resets target
		      address)
		    - Could be safe if invalidations inserted by the
		      compiler or memory set to invalidate on write
		      by changing access rights for the data
	    - "Safe" (note: most of these still won't check contents
	      of run-time-constant data structures)
		- Full lookup with growable tables
		    - Hashing
			- Collision resolution
			    - Open addressing with double hashing
			      (implemented) 
			    - Chaining
			- Hash functions
			    - Single, simple function (implemented)
				- There are infinitely many possible
				  variations.  For example, we might want
				  to split and combine (e.g., using xor)
				  upper and lower bits of pointers or
				  floats before adding those types of keys
				  to the hash value.
			    - "Perfect hash": select best among large
			      library of hash functions using set of
			      key values used for current run (dynamic
			      selection) or past runs (static selection)
			    - "Universal hash" (or "fingerprinting"):
			      hash function with random weights
			      applied to the key bits; probabilistic
			      guarantees on worst-case behavior;
			      efficient for large key spaces:
			      O(log(n)) for key length n
		    - Alternatives to hashing: for small numbers of keys
			- Linear search
			    - Array of cached key/target pairs
			    - Dynamically generate series of key
			      comparisons
			    - Variations
			        - Only store fixed number of most
			          frequently/recently used keys
			        - Dynamically reorder the lists
			- Search trees / indices (binary search, B
			  trees, etc.)
			    - Probably not worthwhile
		- Inline caches (creates 2-level code cache)
		    - Monomorphic: for (quasi-)invariants
			- Compare against previous key.  If
			  same, jump to saved target address.  If
			  different, do a full lookup, replace the
			  key and target address in the inline cache,
			  and jump.
		    - Polymorphic: for small number of unique key values
			- Cache subset of keys/targets using one of the
			  alternatives to hashing listed above
		- Lookups with small, bounded key spaces (up to 16 bits)
		    - Direct table lookup (no need to store nor compare
		      against the key as well!)
		- Special casing
		    - If statically don't know that the number of
		      possible values is small, can test the value.
			- Use direct lookup for small values and
			  general method for others
			- Could use perfect hash for certain types of
			  values and general method for others (e.g.,
			  log base k then table lookup for powers of
			  k)
			- Use a polymorphic scheme for the
			  special-case keys and general method for
			  others
		- Key comparisons (basically a string comparison)
		    - Traditional: compare all bits (implemented)
		    - Probabilistic: compare random bits (just
		      the fingerprint)
		- Invalidation of particular versions would be
		  useful in a system that deallocated (garbage
		  collected) specializations that were not used
		  recently
	- Identify exploitable characteristics of our benchmarks
	  (e.g., invariants or quasi-invariants)
	- Implement several optimizations
	    - decompress and grep could benefit from dispatches
	      implemented as table lookups (I need to verify that
	      the tables would be small enough)
	    - mipsi could benefit from changing the hash function
	    - all benchmarks could use invalidation-based caching or
	      inline caching for invariant or quasi-invariant run-time
	      constants (i.e., at all dynamic-region entries)
	    - mipsi's jump and return cases could also use inline
	      caching, as noted by Matthai on 10/23/98
	    - all of the above benchmarks could benefit from a generally
	      more efficient implementation, independent of issues
	      discussed above
		- lookups with key passed in registers
		- (partially) inlined lookups
		- static allocation of memory to store key
		- dynamic lookup only on dynamic context (static lookup
		  on static context => staged caching)
	- Compare costs of different dispatch implementations
    - How is this different from switches and dynamic dispatches?
	- First to apply known sophisticated dispatching techniques to
	  dynamic compilation / run-time specialization (e.g.,
	  dispatches in Tempo and `C are manually implemented by the user)
	- Potentially vast key space
	    - Big key variables (32 bits is too big to
	      use a directly indexed table)
		- Switches and dynamic dispatches typically have a
		  small number of possibilities, all of which are
		  known statically (i.e., new types and new cases are
		  not created dynamically)
		- Our keys don't have to be integers.  Floats and
		  pointers can be (part of) keys, too.
	    - An arbitrary number of key variables
		- Switches and single dispatches are only on one
		  variable; multiple dispatch may be on multiple
		  variables (types) 
	    - Potentially whole data structures, though not for this
	      study
	- Execution characteristics different from OO programs?
    - Advantages
	- It allows me to do experiments I had planned to do (e.g.,
	  with certain optimizations off)
	- It makes the "safe" annotations more appealing and allows us
	  to more credibly evaluate the safety/performance tradeoff
	- Broadens the set of applications to which we can apply DyC
	- It addresses a significant weakness in DyC (e.g., Ruf
	  seemed surprised that we hadn't invested significant effort
	  in making dispatches fast)
	- Strengthens other studies that depend on fast dispatches
	    - Uses of conditional specialization
	- Strengthens other studies by adding more benchmarks
	- Techniques could also be applied to other systems
	    - Consel's specialization classes
	- Demonstrates why caching/dispatching should be part of the
	  infrastructure
    - Disadvantages
	- There is a non-trivial amount implementation required
	- I would have to get one or two more benchmarks working to
	  demonstrate the table-lookup implementation
	- Few of the techniques are novel in the absolute sense
    - Overlaps with other studies
	- Sensitivity of optimizations to program inputs



Date: Tue, 5 Jan 1999 16:29:04 -0800
From: Markus Mock <mock@cs.washington.edu>
To: Susan Eggers <eggers@cs.washington.edu>,
cc: spin-comp@cs, Markus Mock <mock@cs>
Subject: Grant Proposal

I'd like to see an additional point added to the section.

o Develop a static analysis which, in interaction with the value locality
profiler, identifies both  slowly changing variables that are potential
candidates for specialization and loops that may be beneficially unrolled. 

We can cite Autrey, Wolfe "Initial Results for Glacial
Variable Analysis" [International Journal of Parallel Programming
vol 26, no 1, 1998] here as a precursor. They use only static frequency
estimates and a simple staging model based on loop nests to come up with
good guesses for semi-invariant or invariant variables (which they call
glacial variables).

Also, the last sub-point about the cost-benefit model: it seems that this
model should mostly depend on the capabilites and associated cost of the
unterlying dynamic compilation system. Given the profile information, this
model can then be refined to take into account the actual architecture and
program that is optimized to produce a specialized cost-benefit model for
the particular configuration.

Just my 2/100 euros. 


	-- Markus



To: spin-comp@cs
Subject: conditional and lazy specialization outline
Date: Tue, 05 Jan 1999 16:29:55 PST
From: Brian Grant <grant@thistle.cs.washington.edu>

This is not as fleshed out as the dispatching outline, but I thought
it might be of interest (again, after deadlines).

--Brian

- Uses of conditional and lazy specialization
    - Premise
	- Conditional and lazy specialization fit naturally into DyC's
	  framework
	    - We get conditional specialization "for free" from DyC's
	      style of polyvariant division
	    - Lazy specialization fits naturally in DyC because it
	      also supports both eager specialization and laziness
	      due to promotions
	- Conditional and lazy specialization are novel capabilities
	  of DyC that are unproven
	    - Conditional specialization can be used
		- To avoid DC when the cost wouldn't be amortized
		- To avoid DC when it would little or no benefit
		- To avoid DC when it would have a negative impact on
		  other parts of the program (in particular, by
		  trashing the i-cache) 
		- To select appropriate optimizations?
	    - Lazy specialization can be used
		- To avoid specializing code that won't be executed
		- To provide a measure of safety (i.e., guarantees
		  termination)
    - Why is this important?
	- Broadens applicability of dynamic compilation
	    - To dynamic regions that might sometimes be amenable to
	      specialization and sometimes might not
	    - To dynamic regions that contain considerable amounts of
	      code that is seldom executed
[reword]    - By permitting multiway unrolling to be used in more
	      circumstances (e.g., in binary search)
	- Paves the way for fully automatic DC by avoiding negative
	  consequences (e.g., i-cache trashing, non-terminating
	  specialization, excessive DC overhead)
    - Approach
	- There are a variety of ways in which conditional
	  specialization could be used.  Find and implement examples
	  of each in our benchmark suite.  When creating conditions,
	  keep in mind that it should be possible to generate them
	  using automatic techniques.
	    - Execution threshold: specialize only when the code has
	      been executed enough times to recoup estimated DC cost
	      (ala ski rental)
		- Could/should be for particular values of the static
		  variables
		- Trickier when threshold must be tested inside dynamic
		  region, as in dinero and (especially) mipsi
	    - Cache size: specialize only when it is estimated that
	      the generated code is likely to "fit nicely" in the
	      i-cache and not clobber the rest of the working set
		- What does "nicely" mean?  Number of iterations * size
		  of iteration < cache size?
		- How can we account for what else is in the cache?
		- Could also partially unroll loops, which, again,
		  might put the test inside the dynamic region
	    - When particular optimizations apply: specialize only
	      when it is determined that particular run-time
	      optimizations can be applied
		- Strength reduction in dinero for power-of-2 cache
		  sizes
		- Does the polyvariant division in the shader, where
		  we only specialize particular paths, qualify as
		  conditional specialization?  We certainly didn't
		  insert any new conditions.
		- Any instances of @s being conditionally safe in our
		  benchmarks (and being able to perform a simple
		  source-level check to determine that)?
	    - Application of _different_ optimizations (not just full
	      optimization or none) for different conditions
		- Any examples of this in our benchmarks?
		- What optimizations potentially have high dynamic
		  overhead, other than loop unrolling, that we could
		  control using annotations (we can't control run-time
		  dce using annotations, for example)?
	- Lazy specialization is used to avoid generating code that
	  won't be used (reached by branches not taken)
	    - Improve implemention of one-time lazy edges
	    - If we knew which edge would be the one most likely
	      taken, we could make that one eager and the other one
	      lazy (i.e., if the branch were biased)
	- Use our current benchmarks
	    - conditional specialization (execution threshold)
		- mipsi, in particular
		- all other benchmarks, too
	    - lazy specialization
		- mipsi
		- binary
	- Are other programs required?
	- Compare conditional and lazy specialization to:
	    - not applying specialization
	    - applying specialization indiscriminately
	- What kind of experiments should I run?
    - How is this novel?
	- Conditional and lazy specialization are novel features
    - Advantages
	- Could prove the utility of cool features of DyC
    - Disadvantages
	- Some debugging will likely be required for mipsi
	- Examples using our current benchmarks might be largely
	  uninteresting (still uncertain)
	- The design for conditional and lazy specialization is
	  described in detail in the PEPM/TCS papers



Date: Wed, 6 Jan 1999 13:07:55 -0800
From: eggers@yakima (Susan Eggers)
To: spin-comp@cs
Subject: machines

What are our machines called:
Digital X, with 21164 processors, and X bytes of memory, running
the X operating system.

Susan

Date: Wed, 6 Jan 1999 14:57:28 -0800
From: eggers@yakima (Susan Eggers)
To: eggers@cs.washington.edu, chambers@cs.washington.edu,
Subject: Re: Grant Proposal
Cc: spin-comp@cs, mock@cs


Excellent, both good points -- they're in.

Thanks for your input.
Susan

Date: Fri, 8 Jan 1999 11:52:53 -0800
From: eggers@yakima (Susan Eggers)
To: spin-comp@cs
Subject: look at paper 10


----- Begin Included Message -----

From owner-arch-lunch@june Fri Jan  8 11:22:45 1999
To: arch-lunch@cs, cse590g@cs.washington.edu
Subject: ISCA99
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Content-Length: 72
X-Lines: 4
Status: RO


The program is already on the web http://www.neci.nj.nec.com/isca99/




----- End Included Message -----


Date: Mon, 11 Jan 1999 10:54:19 -0800 (PST)
From: chambers@klamath (Craig Chambers)
To: spin-comp@cs
Subject: DyC pldi'99 comments



----- Begin Included Message -----

From groved@us.ibm.com  Mon Jan 11 05:24:21 1999
Delivery-Date: Mon, 11 Jan 1999 05:24:23 PST
From: groved@us.ibm.com
X-Lotus-FromDomain: IBMUS
To: chambers@cs.washington.edu
Date: Sun, 10 Jan 1999 21:25:09 -0500
Subject: DyC pldi'99 comments
Mime-Version: 1.0
Content-Disposition: inline

Hi Craig,

     I led a discussion (about 10 people) of the DyC PLDI'99 paper on
Friday afternoon.  Here's some of the high level comments people had.  A
couple people also said they had some minor detailed comments about the
presentation that they would email to me -- if I actually get them I'll
pass them along, but since we're also all involved writing a JavaGrande
submission (due 1/15), they may not get written  in a timely fashion.

     **  Given the space constraints you may not be able to do much better,
but it would be helpful to provide a better description of the
assumptions/terminology you are using -- there was a bunch of discussion
related to division vs. specialization, the exact meaning of "static," and
the various policy annotations.  I don't think you can assume that people
are familiar with the details of the TCS journal paper.

     ** It would be nice if the non-standard optimizations were described
more precisely or in more detail in section 4.  There was a strong feeling
that a good running example would really help both in making it clear what
the optimizations were and what  the overall structure of the system was.
In particular, there was a great deal of confusion over the details of loop
unrolling.

     ** There's the confusion over the formulas in section 4.2 that I
mentioned in my previous email.

     ** Table 1 tells which variables were annotated, but several people
were interested in knowing exactly what the annotations were for each
program (was it just a make_static on the variable(s), or was more
annotation required).  It was suggested that you make the annotated
programs available on your web page.

     ** Table 4 shows all, none, and all but one.  For completeness, it
might be nice to show just one too  -- or at least do the experiments and
report any interesting results in the running text.  (Just my comment --
not a big issue).

     ** Several people thought it would be very interesting for section #4
to contain a more in depth (informal) analysis of what exactly was enabling
the huge speedups ("they got a 5x speedup on a spec benchmark....what
exactly did the system do?").  From table 4 one can more or less tell which
subset of the optimizations are important, but it would be interesting to
read a description of what transformations were enabled (e.g. loop
unrolling and static loads enabled the elimination of all loads from the
instruction array, which in turn enabled.....).  You've all been looking at
these benchmarks in great detail -- if you had any intuition/thoughts
people would be interested in reading about them.

     ** In the related word section, people expected a discussion of
various other dynamic compilation/JIT systems such as Self and more recent
Java work.  I can see an argument that these systems aren't really that
closely related (both are interspersing code generation with program
execution, but the approach/tradeoffs are very different).  I think you
should make this argument explicit, if you believe it, and thus do not
believe that the Self/JIT work is relevant.

     ** In the intro, you might want to be a little more explicit about
what's new in this paper.  I think it's implicit in the last part of the
intro, but maybe you should reorder/reword to make it more prominent (on
the first page for example).

     I think that's most of the major points....since I was moderating I
wasn't quite as careful about writing things done as I should have been.
If I think of anything else I'll let you know.

--dave





----- End Included Message -----


Date: Mon, 11 Jan 1999 19:44:42 -0800
From: eggers@yakima (Susan Eggers)
To: spin-comp@cs
Subject: meeting tomorrow

Craig and I would like to cancel.
Grant proposal.

Susan

Date: Tue, 12 Jan 1999 18:02:52 -0800
From: eggers@yakima (Susan Eggers)
To: spin-comp@cs
Subject: the proposal

We submitted the proposal early this time -- 4:57, three minutes
to spare.

Thanks for tolerating our absence.

Susan and Craig

Date: Mon, 18 Jan 1999 10:28:47 -0800 (PST)
From: chambers@klamath (Craig Chambers)
To: spin-comp@cs
Subject: conferences vs. journals

I noticed in a request to review a TOPLAS submission the following paragraph,
which seems to indicate TOPLAS's views on conference vs. journal papers, and
is relevant to our discussions on the topic of what's required in a journal 
paper beyond a conference paper:

"Prior conference publication is no bar to publication in TOPLAS. Conference 
proceedings are not archival and are not carefully refereed. Conference papers 
that are submitted to TOPLAS will go through a refereeing process (as will 
any submission) that almost always leads to clarification, better discussion 
of the relevant literature, correction or improvement of the results, 
deletion of irrelevant material, and other changes that are of value to 
TOPLAS's readership."

As I read it, it suggests that (TOPLAS) journal papers may simply be
better edited versions of conference papers.  I'm not suggesting that we
only do that, but that we shouldn't save work or tackle additional work
just to make a journal paper out of a conference paper.

-- Craig

To: spin-comp@cs
Subject: more info from Zorn
Date: Tue, 19 Jan 1999 07:40:58 PST
From: Brian Grant <grant@thistle.cs.washington.edu>

Looks like we're in good company. :-)

--Brian

------- Forwarded Message

From: Ben Zorn <zorn@microsoft.com>
To: chilimbi@cs.wisc.edu, simonpj@microsoft.com, jhr@research.bell-labs.com,
        crary@cs.cmu.edu, bodik@cs.pitt.edu, rinard@lcs.mit.edu,
        horwitz@cs.wisc.edu, blelloch@cs.cmu.edu, James.Stichnoth@intel.com,
        santosh@ececs.uc.edu, n.mcintosh@acm.org, vegdahl@up.edu,
        mahlke@hpl.hp.com, athena@theory.lcs.mit.edu, lcwu@crhc.uiuc.edu,
        jfoster@cs.berkeley.edu, leunga@cs.nyu.edu, li@cs.purdue.edu,
        cding@cs.rice.edu, CWFraser@microsoft.com, pugh@cs.umd.edu,
        larus@microsoft.com, toddpro@microsoft.com, consel@irisa.fr,
        grant@cs.washington.edu
Subject: Information for PLDI'99 authors...
Date: Mon, 18 Jan 1999 08:47:49 -0800

Congratulations on having your paper accepted to PLDI'99.

As mentioned in earlier email, the hard deadline for the final version of
the paper is Feb. 19, and I must receive an electronic copy and a hardcopy
at that time.  Full information about the format and addional materials you
must provide are available at the URL:

http://www.cs.rutgers.edu/pldi99/author-info.html

This year, as an added benefit, student authors of PLDI papers are granted
free ACM SIGPLAN membership.  Send your name and email address to Ben Zorn
(zorn@microsoft.com) to learn about how to apply for free membership.  Also,
SIGPLAN PAC (http://www.acm.org/sigplan/pac/) supports travel expenses for
student authors.  Check on the PAC web page to find out more about this
opportunity.

I look forward to receiving your final papers.  Please let me know if you
have any questions or comments.  Thank you for your interest and
contribution to PLDI'99.

- -Ben Zorn
------- End of Forwarded Message



Date: Tue, 19 Jan 1999 11:46:26 -0800
From: eggers@yakima (Susan Eggers)
To: spin-comp@cs, grant@thistle.cs.washington.edu
Subject: Re: more info from Zorn

Can you all look into the SIGPLAN membership deal and travel
support to the conference?

Thanks,
Susan

Date: Tue, 19 Jan 1999 15:45:44 -0800
From: eggers@yakima (Susan Eggers)
To: melody@cs
Subject: travel to PLDI
Cc: spin-comp@cs


Melody --

Can you make a ball-partk estimate of how much a student will spend
at PLDI, including, air fare, hotel, registration, meals not covered
by the registration, to/from the airport, etc.?  They have to add
this information to their petitions for getting student funding for
the conference.

Thanks,
Susan

Date: Tue, 26 Jan 1999 09:37:50 -0800
From: eggers@yakima (Susan Eggers)
To: spin-comp@cs
Subject: hotel at FCRC

Lisa had not made our reservations, so I tried to do so this 
morning.

The general Hilton 800 number had no student rate, so I didn't
make one for Brian/Matthai/Markus -- you'll have to call the hotel
directly.
http://www.acm.org/sigs/conferences/fcrc/

I made a reservation for Craig from May 1 - May 5,  If that's not
what you want, you can change easily.  Your confirmation number is
222167877.

I didn't do reservations.

Susan

To: eggers@yakima (Susan Eggers)
cc: spin-comp@cs
Subject: Re: hotel at FCRC 
Date: Tue, 26 Jan 1999 09:44:25 PST
From: Brian Grant <grant@thistle.cs.washington.edu>

>> The general Hilton 800 number had no student rate, so I didn't
>> make one for Brian/Matthai/Markus -- you'll have to call the hotel
>> directly.

I made the reservations for the three of us a week ago. May 1 - 4.

--Brian

Date: Tue, 26 Jan 1999 11:15:55 -0800 (PST)
From: Markus Mock <mock@cs.washington.edu>
To: spin-comp@cs.washington.edu
Subject: meeting today

Since Patricia is not feeling well today, I need to stay at home and take
care of Andrea. 

To give you an update of what I have been doing: I have been looking at
the loops we unroll in our benchmarks. I think I have found a scheme to
identify most of them using static analysis and execution frequency
information from a profile run. Some loops don't fit the scheme, eg.
the ones in fft and Mipsi. I am still working on that. I will be writing
up what I have this week and send it around.


	-- Markus


Date: Tue, 26 Jan 1999 11:42:20 -0800
From: eggers@yakima (Susan Eggers)
To: spin-comp@cs.washington.edu, mock@cs.washington.edu
Subject: Re: meeting today

Do we need a meeting today?

Matthai is busy working out his optimization framework and is not
yet ready to report.
Brian is completing his PLDI draft, and will probably just hand it over
to us?.
Mark just started on the DyC-scheduled vs. assembler-scheduled analysis.

What do you think?

Susan

To: eggers@yakima (Susan Eggers)
cc: spin-comp@franklin.cs.washington.edu
Subject: Re: meeting today 
Date: Tue, 26 Jan 1999 11:47:39 PST
From: Matthai Philipose <matthai@franklin.cs.washington.edu>

I'd be fine with not meeting.
		Matthai


To: spin-comp@cs.washington.edu
Subject: Re: meeting today 
Date: Tue, 26 Jan 1999 11:53:02 PST
From: Brian Grant <grant@thistle.cs.washington.edu>

>> Do we need a meeting today?

No meeting is fine.

>> Brian is completing his PLDI draft, and will probably just hand it over
>> to us?.

The draft isn't going to be ready today.  Now that I'm over my cold,
I'm shooting for tomorrow night or Thursday morning.

--Brian

Date: Tue, 26 Jan 1999 12:05:55 -0800 (PST)
From: chambers@klamath (Craig Chambers)
To: spin-comp@cs.washington.edu, mock@cs.washington.edu, eggers@yakima
Subject: Re: meeting today

Fine with me not to meet.

-- Craig

Date: Wed, 27 Jan 1999 15:13:37 -0800
From: eggers@yakima (Susan Eggers)
To: spin-comp@cs
Subject: projected expenditures from Lisa


----- Begin Included Message -----

From lisas@cs.washington.edu Tue Jan 26 13:05:22 1999
To: Susan Eggers <eggers@cs.washington.edu>
Subject: PLDI Student Attendance Estimate
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain
Content-Length: 452
X-Lines: 20
Status: RO

http://www.cs.rutgers.edu/pldi99/

Although the Web Page cautions that the hotel space is limited and
advises early registration, I found no path to register online.

Here are the estimated costs of PLDI99 Attendance, May 1 - 4, 1999 in
Atlanta, GA.

Conference Cost				$200
RT Airfare		 		 	 400
Taxi's			   		  	  50
Student Room/shared $120 x 3 nights		 360
Per diem  $38 x 4 days			 	 152
						_____

Total						$1162
					
Hope this helps,

Lisa


----- End Included Message -----


Date: Wed, 27 Jan 1999 15:22:03 -0800 (PST)
From: Markus Mock <mock@cs.washington.edu>
To: Susan Eggers <eggers@yakima>
cc: spin-comp@cs
Subject: Re: projected expenditures from Lisa


> RT Airfare		 		 	 400

I talked to Jerry and he told me the UW contract fare was $590 rt. The
cheaper fares have penalties for changes and have to be ticketed within 48
hours after reservation.
If you have a student Amex card you can get a ticket for $269 + tax
(roundtrip), but the reservation can't be made until 3 weeks before
travel. 

	-- Markus




Date: Tue, 2 Feb 1999 11:15:22 -0800 (PST)
From: chambers@klamath (Craig Chambers)
To: cecil@cs, spin-comp@cs
Subject: Summer Internships at Sun Labs East

FYI.

----- Begin Included Message -----

From detlefs@slats.East.Sun.COM  Tue Feb  2 08:34:59 1999
Delivery-Date: Tue, 02 Feb 1999 08:35:00 PST
From: David Detlefs - Sun Microsystems Labs BOS <detlefs@slats.East.Sun.COM>
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Date: Tue,  2 Feb 1999 11:34:44 -0500 (EST)
To: chambers@cs.washington.edu
Subject: Summer Internships at Sun Labs East
X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs  Lucid
Reply-To: David Detlefs <david.detlefs@East.Sun.COM>

Dear friend, colleague, and/or mentor --

The Java Topics group of Sun Microsystems Laboratories in Burlington,
MA, is looking to recruit an excellent summer intern or two.  We are a
small but productive group that works in all areas of advanced Java
Virtual Machine implementation, especially garbage collection and
Just-In-Time compilation.  If you know of a bright graduate (or very
bright undergraduate!) student who might find this sort of work
interesting for a summer (and who would be good at it!), please
forward them this mail.  They can reply directly to me.  We don't have
a firm deadline, but sooner is better than later.

Thank you for your time.

Dave Detlefs


----- End Included Message -----


Date: Tue, 2 Feb 1999 13:31:58 -0800 (PST)
From: Markus Mock <mock@cs.washington.edu>
To: spin-comp@cs.washington.edu
Subject: sick

Andrea got her vaccinations yesterday, and I got the bacteria/virus and
fever. Since it didn't get better this morning, I won't come in today.


	-- Markus


Date: Thu, 4 Feb 1999 17:17:21 -0800
From: Markus Mock <mock@cs.washington.edu>
To: spin-comp@cs.washington.edu
Subject: SIGPLAN PAC application

I just looked at the web page describing the PAC support again: it's
awarded on a first-come first-served basis. So I just sent in my
application since I am already a SIGPLAN member. 
If you haven't applied yet, you should probably do so soon.


	-- Markus


Date: Thu, 4 Feb 1999 18:39:51 -0800
From: eggers@yakima (Susan Eggers)
To: levy@cs, eggers@yakima, sparekh@cs, redstone@yakima, spin-comp@cs
Subject: do we still have franklin?

What are the names of our still-alive alphas?

Susan

Date: Thu, 4 Feb 1999 18:44:10 -0800
From: Joshua Redstone <redstone@cs.washington.edu>
To: Susan Eggers <eggers@yakima>
cc: levy@cs, sparekh@cs, redstone@yakima, spin-comp@cs
Subject: Re: do we still have franklin?

At least:

steffi, chrissie, jimmy, martina

franklin is alive but is being used for something else? (it doesn't accept
logins)

Josh

On Thu, 4 Feb 1999, Susan Eggers wrote:

> What are the names of our still-alive alphas?
> 
> Susan
> 


Date: Thu, 4 Feb 1999 18:48:35 -0800 (PST)
From: Markus Mock <mock@cs.washington.edu>
To: Joshua Redstone <redstone@cs.washington.edu>
cc: Susan Eggers <eggers@yakima>, levy@cs, sparekh@cs, redstone@yakima,
Subject: Re: do we still have franklin?

Franklin is sitting on Matthai's desk and is alive, I can log on at least.
The 3 alphas we are using for dyc are: wu, alper and robscheit.


	-- Markus

On Thu, 4 Feb 1999, Joshua Redstone wrote:

> At least:
> 
> steffi, chrissie, jimmy, martina
> 
> franklin is alive but is being used for something else? (it doesn't accept
> logins)
> 
> Josh
> 
> On Thu, 4 Feb 1999, Susan Eggers wrote:
> 
> > What are the names of our still-alive alphas?
> > 
> > Susan
> > 
> 
> 


To: eggers@yakima (Susan Eggers)
cc: spin-comp@cs
Subject: Re: do we still have franklin? 
Date: Thu, 04 Feb 1999 22:33:14 PST
From: Brian Grant <grant@thistle.cs.washington.edu>

>> What are the names of our still-alive alphas?

DyC machines are:

old:
franklin 	Matthai's desk
meitner		essentially unused

new:
robscheit
alper
wu

--Brian

Date: Fri,  5 Feb 1999 11:34:56 -0800 (PST)
From: Sujay Parekh <sparekh@cs.washington.edu>
To: Markus Mock <mock@cs.washington.edu>
Cc: Joshua Redstone <redstone@cs.washington.edu>, Susan Eggers <eggers@yakima>,
Subject: Re: do we still have franklin?


Just last week, Nancy moved franklin from being controlled by lab staff to
being administered by students (ie, it's now unsupported, just like the new
SMT and DyC Alphas).  I believe that's why no one else but Matthai can log
in.

Sujay

To: Ben Zorn <zorn@microsoft.com>
cc: spin-comp@cs
Subject: PLDI `99: format question
Date: Fri, 05 Feb 1999 13:17:39 PST
From: Brian Grant <grant@thistle.cs.washington.edu>

Dr. Zorn,

The authors' info web page states the text should use a
"9 point font, set on 10 point spacing."  However, the
Framemaker5 template uses a 10-point font and 11-point
line spacing.  Which is correct?  Is either format
acceptable?  Using the small font and spacing might
alleviate our need for an additional page.

Thank you for your help.
--Brian Grant


To: spin-comp@cs
Subject: disabled backups on robscheit
Date: Mon, 08 Feb 1999 13:06:26 PST
From: Brian Grant <grant@thistle.cs.washington.edu>

I've asked Warren to disable backups on robscheit temporarily while I
perform more timing experiments.  The CVS archive, which is on robscheit,
should be fully backed up.  Please don't commit anything new until further
notice.

--Brian

To: spin-comp@cs
Subject: paper
Date: Mon, 08 Feb 1999 15:00:35 PST
From: Brian Grant <grant@thistle.cs.washington.edu>

I just heard from Ben Zorn that the Frame template was incorrect.  I
had noticed it was inconsistent with the format spec.  I changed the
font to 9pt to comply with the spec.  That cut our # pages from 12 back
to 11 (not including references), so we should have enough space, I think.

The latest draft of the paper is at:
/projects/dyncomp/Papers/PLDI99/final.fm

The results and related work still have a few rough spots, but nearly
all of the numbers are there.  I probably won't be making more changes
today or tomorrow while I work on my affiliates talk.

--Brian

To: spin-comp@cs
Subject: let's meet in 114
Date: Tue, 09 Feb 1999 13:37:15 PST
From: Brian Grant <grant@thistle.cs.washington.edu>

I'll go directly there @2:30 and set up the projector.

--Brian

Date: Tue, 9 Feb 1999 18:27:57 -0800
From: eggers@yakima (Susan Eggers)
To: spin-comp@cs
Subject: sorry


----- Begin Included Message -----

From MAILER-DAEMON Tue Feb  9 18:22:16 1999
Subject: Returned mail: User unknown
To: eggers
Content-Length: 771
X-Lines: 26
Status: RO

The original message was received at Tue, 9 Feb 1999 18:22:12 -0800
from eggers@localhost

   ----- The following addresses had delivery problems -----
spoin-comp  (unrecoverable error)

   ----- Transcript of session follows -----
550 spoin-comp... User unknown

   ----- Original message follows -----
Return-Path: <eggers>
Received: (eggers@localhost) by yakima.cs.washington.edu (8.6.12/7.2ws+) id SAA12678; Tue, 9 Feb 1999 18:22:12 -0800
Date: Tue, 9 Feb 1999 18:22:12 -0800
From: eggers (Susan Eggers)
Message-Id: <199902100222.SAA12678@yakima.cs.washington.edu>
To: grant@cs
Subject: our meeting this Friday
Cc: spoin-comp


Can we meet at some time other than 3:30?  I'd like to go to
the Equator talk.
Matthai is at 2:30, and I'm free starting at 11:30.

SUsan



----- End Included Message -----


To: eggers@yakima (Susan Eggers)
cc: spin-comp@cs
Subject: Re: our meeting this Friday 
Date: Wed, 10 Feb 1999 07:50:52 PST
From: Brian Grant <grant@thistle.cs.washington.edu>

11:30 is ok by me.

--Brian

To: spin-comp@cs
Subject: PLDI deadline looming near
Date: Fri, 12 Feb 1999 10:40:56 PST
From: Brian Grant <grant@thistle.cs.washington.edu>


------- Forwarded Message

Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by june.cs.washington.edu (8.8.7+CS/7.2ju) with ESMTP id KAA21458 for <grant@cs.washington.edu>; Fri, 12 Feb 1999 10:29:25 -0800
Received: by mail2.microsoft.com with Internet Mail Service (5.5.2524.0)
	id <15AJPY14>; Fri, 12 Feb 1999 10:22:18 -0800
Message-ID: <C35556591D34D111BB5600805F1961B91253766A@RED-MSG-47>
From: Ben Zorn <zorn@microsoft.com>
To: "'chilimbi@cs.wisc.edu'" <chilimbi@cs.wisc.edu>,
        "'simonpj@microsoft.com'" <simonpj@microsoft.com>,
        "'jhr@research.bell-labs.com'" <jhr@research.bell-labs.com>,
        "'crary@cs.cmu.edu'" <crary@cs.cmu.edu>,
        "'bodik@cs.pitt.edu'"
	 <bodik@cs.pitt.edu>,
        "'rinard@lcs.mit.edu'" <rinard@lcs.mit.edu>,
        "'horwitz@cs.wisc.edu'" <horwitz@cs.wisc.edu>,
        "'blelloch@cs.cmu.edu'"
	 <blelloch@cs.cmu.edu>,
        "'James.Stichnoth@intel.com'"
	 <James.Stichnoth@intel.com>,
        "'santosh@ececs.uc.edu'"
	 <santosh@ececs.uc.edu>,
        "'n.mcintosh@acm.org'" <n.mcintosh@acm.org>,
        "'vegdahl@up.edu'" <vegdahl@up.edu>,
        "'mahlke@hpl.hp.com'"
	 <mahlke@hpl.hp.com>,
        "'athena@theory.lcs.mit.edu'"
	 <athena@theory.lcs.mit.edu>,
        "'lcwu@crhc.uiuc.edu'" <lcwu@crhc.uiuc.edu>,
        "'jfoster@cs.berkeley.edu'" <jfoster@cs.berkeley.edu>,
        "'leunga@cs.nyu.edu'" <leunga@cs.nyu.edu>,
        "'li@cs.purdue.edu'"
	 <li@cs.purdue.edu>,
        "'cding@cs.rice.edu'" <cding@cs.rice.edu>,
        "'CWFraser@microsoft.com'" <CWFraser@microsoft.com>,
        "'pugh@cs.umd.edu'"
	 <pugh@cs.umd.edu>,
        "'larus@microsoft.com'" <larus@microsoft.com>,
        "'toddpro@microsoft.com'" <toddpro@microsoft.com>,
        "'consel@irisa.fr'"
	 <consel@irisa.fr>,
        "'grant@cs.washington.edu'" <grant@cs.washington.edu>
Cc: ryder@cs.rutgers.edu
Subject: PLDI hardcopy deadline and typesetting issues...
Date: Fri, 12 Feb 1999 10:21:50 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2524.0)
Content-Type: text/plain;
	charset="ISO-8859-1"
X-UIDL: 06d06fadc9c242b7298ff4da99bc1753
Status: U

I wanted all the PLDI authors to know that since I won't be in Boulder on
Friday, Feb 19 to receive the papers, I will accept hardcopies of your final
papers until Monday MORNING (Feb 22).  Please make sure that I receive them
by then.  Send the hardcopies to:

Ben Zorn
5108 Ellsworth Place
Boulder, CO 80303

This deadline is very firm.  Please do not ask for any further extensions.

Also, there have been some inquiries about the Framemaker ACM conference
style template on the Web.  It turns out that the point size and spacing in
the Framemaker template is 10 pts on 11pts, whereas the rules say that the
size and spacing should be 9pt on 10pt.  If you are using Framemaker, you
are welcome to change the Framemaker template to 9pt on 10pt, as that will
give you more space.  Also, that template has hypenation turned off in the
body of the document, which is also an error.  You are welcome to turn it
back on.  

If you have any questions, please let me know.

- -Ben


------- End of Forwarded Message



Date: Fri, 12 Feb 1999 14:30:59 -0800
From: eggers@yakima (Susan Eggers)
To: melody@cs
Subject: fed expr deadline
Cc: spin-comp@cs

Mel --

Can you find out the lastest express mail we can use to get
a paper to Boulder CO by Monday MORNING (Feb 22).  

Thanks,
Susan

Date: Fri, 12 Feb 1999 14:46:16 -0800
From: melody (Melody Kadenko-Ludwa)
To: eggers@yakima
Subject: Re: fed expr deadline



FedEx offers the latest time.  The university cannot use Airborne
anymore.  Monday is a university/government holiday, but not for
FedEx.  However, the deadline for calling today is 3pm.  Otherwise, it
would be a drop-off at the box at 6th & University streets downtown.
As for Saturday pickup, they will pick up at your house, but the
charge is doubled.  If you plan on doing that, then you'll need the
"special" university forms.

Mel


>>>>> "Susan" == Susan Eggers <eggers@yakima> writes:

    > Mel -- Can you find out the lastest express mail we can use to
    > get a paper to Boulder CO by Monday MORNING (Feb 22).

    > Thanks, Susan


  

To: Gretchen Cox <gretc@cs.washington.edu>
cc: spin-comp@cs
Subject: Re: Equipment needs for Affiliate talks 
Date: Mon, 15 Feb 1999 15:02:51 PST
From: Brian Grant <grant@thistle.cs.washington.edu>

>> Please let me know by Tuesday noon latest, if you need any special
>> equipment for your presentations next Thurday.  The only equipment that
>> will be standard to each room will be an overhead projector and a screen.
>> Please be sure to let me know if you need anything in addition to this and
>> I will try to accomodate your requests.

I'll need a LCD projector and a laptop for a PowerPoint slide show.
Matthai Philipose (whose talk is in the same session) will need one
as well.  We already reserved a dept. LCD projector for that time.
Was that the right thing to do?

--Brian

To: spin-comp@cs
Subject: my poster and talk
Date: Mon, 15 Feb 1999 15:05:57 PST
From: Brian Grant <grant@thistle.cs.washington.edu>

I signed up for pizza during tomorrow's poster-making session. :-)
It looks likely that I won't be able to make it.  My talk is in:

/projects/dyncomp/grant/affiliates99.ppt

Unless I send another message before the poster-making session tomorrow,
could someone else please do the poster?  Otherwise, I could try to do it
Thursday morning.

--Brian

To: spin-comp@cs
Subject: poster
Date: Tue, 16 Feb 1999 07:28:31 PST
From: Brian Grant <grant@thistle.cs.washington.edu>

I'm here.  No baby yet.  I'll try to finish my poster this morning.

--Brian

To: spin-comp@franklin.cs.washington.edu
Subject: Practice talk at today's meeting
Date: Tue, 16 Feb 1999 09:32:22 PST
From: Matthai Philipose <matthai@franklin.cs.washington.edu>

Hi all,
I'll be giving another practice talk at today's dynamic compilation 
meeting. I've again reserved the Chateau conference room for the 
2:30-3:30 slot.
		Thanks,
		Matthai


Date: Tue, 16 Feb 1999 13:45:41 -0800
From: eggers@yakima (Susan Eggers)
To: matthai@cs
Subject: your example
Cc: spin-comp@cs


Matthai --

Now that you've thought about the convolution example for your
affilates talk, I'm wondering if the example in the paper wants
to be simplified in any way.

Can you get in touch after your practice wrt this?

Thanks,
Susan

To: spin-comp@franklin.cs.washington.edu
Subject: practice talk
Date: Tue, 16 Feb 1999 14:29:23 PST
From: Matthai Philipose <matthai@franklin.cs.washington.edu>

Just a reminder that I'm giving another practice talk for affiliates 
in the Chateau conference room right now.
		Matthai


Date: Tue, 16 Feb 1999 16:22:19 -0800 (PST)
From: chambers@klamath (Craig Chambers)
To: spin-comp@cs, cecil@cs
Subject: Whirlwind poster draft

----------
X-Sun-Data-Type: text
X-Sun-Data-Description: text
X-Sun-Data-Name: text
X-Sun-Charset: us-ascii
X-Sun-Content-Lines: 8

I've made a draft of the Whirlwind poster.  I'm taking comments for the 
next hour (later comments can help the talk, which will be derived from the
poster slides).

Postscript attached below.  Or see
~chambers/talks/uw/affiliates/99/poster.{doc,ps}.

-- Craig
----------
X-Sun-Data-Type: postscript-file
X-Sun-Data-Description: postscript-file
X-Sun-Data-Name: poster.ps
X-Sun-Charset: us-ascii
X-Sun-Content-Lines: 3091

%!PS-Adobe-3.0
%%BoundingBox: (atend)
%%Pages: (atend)
%%PageOrder: (atend)
%%DocumentFonts: (atend)
%%Creator: Frame 4.0
%%DocumentData: Clean7Bit
%%EndComments
%%BeginProlog
%
% Frame ps_prolog 4.0, for use with Frame 4.0 products
% This ps_prolog file is Copyright (c) 1986-1993 Frame Technology
% Corporation.  All rights reserved.  This ps_prolog file may be
% freely copied and distributed in conjunction with documents created
% using FrameMaker, FrameBuilder and FrameViewer as long as this 
% copyright notice is preserved.
%
% Frame products normally print colors as their true color on a color printer
% or as shades of gray, based on luminance, on a black-and white printer. The
% following flag, if set to True, forces all non-white colors to print as pure
% black. This has no effect on bitmap images.
/FMPrintAllColorsAsBlack             false def
%
% Frame products can either set their own line screens or use a printer's 
% default settings. Three flags below control this separately for no 
% separations, spot separations and process separations. If a flag
% is true, then the default printer settings will not be changed. If it is
% false, Frame products will use their own settings from a table based on
% the printer's resolution.
/FMUseDefaultNoSeparationScreen      true  def
/FMUseDefaultSpotSeparationScreen    true  def
/FMUseDefaultProcessSeparationScreen false def
%
% For any given PostScript printer resolution, Frame products have two sets of 
% screen angles and frequencies for printing process separations, which are 
% recomended by Adobe. The following variable chooses the higher frequencies
% when set to true or the lower frequencies when set to false. This is only
% effective if the appropriate FMUseDefault...SeparationScreen flag is false.
/FMUseHighFrequencyScreens true def
%
% PostScript Level 2 printers contain an "Accurate Screens" feature which can
% improve process separation rendering at the expense of compute time. This 
% flag is ignored by PostScript Level 1 printers.
/FMUseAcccurateScreens true def
%
% The following PostScript procedure defines the spot function that Frame
% products will use for process separations. You may un-comment-out one of
% the alternative functions below, or use your own.
%
% Dot function
/FMSpotFunction {abs exch abs 2 copy add 1 gt 
		{1 sub dup mul exch 1 sub dup mul add 1 sub }
		{dup mul exch dup mul add 1 exch sub }ifelse } def
%
% Line function
% /FMSpotFunction { pop } def
%
% Elipse function
% /FMSpotFunction { dup 5 mul 8 div mul exch dup mul exch add 
%		sqrt 1 exch sub } def
%
%
/FMversion (4.0) def 
/FMLevel1 /languagelevel where {pop languagelevel} {1} ifelse 2 lt def
/FMPColor
	FMLevel1 {
		false
		/colorimage where {pop pop true} if
	} {
		true
	} ifelse
def
/FrameDict 400 dict def 
systemdict /errordict known not {/errordict 10 dict def
		errordict /rangecheck {stop} put} if
% The readline in PS 23.0 doesn't recognize cr's as nl's on AppleTalk
FrameDict /tmprangecheck errordict /rangecheck get put 
errordict /rangecheck {FrameDict /bug true put} put 
FrameDict /bug false put 
mark 
% Some PS machines read past the CR, so keep the following 3 lines together!
currentfile 5 string readline
00
0000000000
cleartomark 
errordict /rangecheck FrameDict /tmprangecheck get put 
FrameDict /bug get { 
	/readline {
		/gstring exch def
		/gfile exch def
		/gindex 0 def
		{
			gfile read pop 
			dup 10 eq {exit} if 
			dup 13 eq {exit} if 
			gstring exch gindex exch put 
			/gindex gindex 1 add def 
		} loop
		pop 
		gstring 0 gindex getinterval true 
		} bind def
	} if
/FMshowpage /showpage load def
/FMquit /quit load def
/FMFAILURE { 
	dup = flush 
	FMshowpage 
	/Helvetica findfont 12 scalefont setfont
	72 200 moveto
	show FMshowpage 
	FMquit 
	} def 
/FMVERSION {
	FMversion ne {
		(Frame product version does not match ps_prolog!) FMFAILURE
		} if
	} def 
/FMBADEPSF { 
	(PostScript Lang. Ref. Man., 2nd Ed., H.2.4 says EPS must not call X              )
	dup dup (X) search pop exch pop exch pop length 
	4 -1 roll 
	putinterval 
	FMFAILURE
	} def
/FMLOCAL {
	FrameDict begin
	0 def 
	end 
	} def 
/concatprocs
	{
	/proc2 exch cvlit def/proc1 exch cvlit def/newproc proc1 length proc2 length add array def
	newproc 0 proc1 putinterval newproc proc1 length proc2 putinterval newproc cvx
}def
FrameDict begin 
/FMnone 0 def
/FMcyan 1 def
/FMmagenta 2 def
/FMyellow 3 def
/FMblack 4 def
/FMcustom 5 def
/FrameNegative false def 
/FrameSepIs FMnone def 
/FrameSepBlack 0 def
/FrameSepYellow 0 def
/FrameSepMagenta 0 def
/FrameSepCyan 0 def
/FrameSepRed 1 def
/FrameSepGreen 1 def
/FrameSepBlue 1 def
/FrameCurGray 1 def
/FrameCurPat null def
/FrameCurColors [ 0 0 0 1 0 0 0 ] def 
/FrameColorEpsilon .001 def	
/eqepsilon {		
	sub dup 0 lt {neg} if
	FrameColorEpsilon le
} bind def
/FrameCmpColorsCMYK { 
	2 copy 0 get exch 0 get eqepsilon {
		2 copy 1 get exch 1 get eqepsilon {
			2 copy 2 get exch 2 get eqepsilon {
				3 get exch 3 get eqepsilon
			} {pop pop false} ifelse
		}{pop pop false} ifelse
	} {pop pop false} ifelse
} bind def
/FrameCmpColorsRGB { 
	2 copy 4 get exch 0 get eqepsilon {
		2 copy 5 get exch 1 get eqepsilon {
			6 get exch 2 get eqepsilon
		}{pop pop false} ifelse
	} {pop pop false} ifelse
} bind def
/RGBtoCMYK { 
	1 exch sub 
	3 1 roll 
	1 exch sub 
	3 1 roll 
	1 exch sub 
	3 1 roll 
	3 copy 
	2 copy 
	le { pop } { exch pop } ifelse 
	2 copy 
	le { pop } { exch pop } ifelse 
	dup dup dup 
	6 1 roll 
	4 1 roll 
	7 1 roll 
	sub 
	6 1 roll 
	sub 
	5 1 roll 
	sub 
	4 1 roll 
} bind def
/CMYKtoRGB { 
	dup dup 4 -1 roll add 						  
	5 1 roll 3 -1 roll add 						  
	4 1 roll add 								  
	1 exch sub dup 0 lt {pop 0} if 3 1 roll 	  
	1 exch sub dup 0 lt {pop 0} if exch 	      
	1 exch sub dup 0 lt {pop 0} if exch	  		  
} bind def
/FrameSepInit {
	1.0 RealSetgray
} bind def
/FrameSetSepColor { 
	/FrameSepBlue exch def
	/FrameSepGreen exch def
	/FrameSepRed exch def
	/FrameSepBlack exch def
	/FrameSepYellow exch def
	/FrameSepMagenta exch def
	/FrameSepCyan exch def
	/FrameSepIs FMcustom def
	setCurrentScreen	
} bind def
/FrameSetCyan {
	/FrameSepBlue 1.0 def
	/FrameSepGreen 1.0 def
	/FrameSepRed 0.0 def
	/FrameSepBlack 0.0 def
	/FrameSepYellow 0.0 def
	/FrameSepMagenta 0.0 def
	/FrameSepCyan 1.0 def
	/FrameSepIs FMcyan def
	setCurrentScreen	
} bind def
 
/FrameSetMagenta {
	/FrameSepBlue 1.0 def
	/FrameSepGreen 0.0 def
	/FrameSepRed 1.0 def
	/FrameSepBlack 0.0 def
	/FrameSepYellow 0.0 def
	/FrameSepMagenta 1.0 def
	/FrameSepCyan 0.0 def
	/FrameSepIs FMmagenta def
	setCurrentScreen
} bind def
 
/FrameSetYellow {
	/FrameSepBlue 0.0 def
	/FrameSepGreen 1.0 def
	/FrameSepRed 1.0 def
	/FrameSepBlack 0.0 def
	/FrameSepYellow 1.0 def
	/FrameSepMagenta 0.0 def
	/FrameSepCyan 0.0 def
	/FrameSepIs FMyellow def
	setCurrentScreen
} bind def
 
/FrameSetBlack {
	/FrameSepBlue 0.0 def
	/FrameSepGreen 0.0 def
	/FrameSepRed 0.0 def
	/FrameSepBlack 1.0 def
	/FrameSepYellow 0.0 def
	/FrameSepMagenta 0.0 def
	/FrameSepCyan 0.0 def
	/FrameSepIs FMblack def
	setCurrentScreen
} bind def
 
/FrameNoSep { 
	/FrameSepIs FMnone def
	setCurrentScreen
} bind def
/FrameSetSepColors { 
	FrameDict begin
	[ exch 1 add 1 roll ]
	/FrameSepColors  
	exch def end
	} bind def
/FrameColorInSepListCMYK { 
	FrameSepColors {  
       		exch dup 3 -1 roll 
       		FrameCmpColorsCMYK 
       		{ pop true exit } if
    	} forall 
	dup true ne {pop false} if
	} bind def
/FrameColorInSepListRGB { 
	FrameSepColors {  
       		exch dup 3 -1 roll 
       		FrameCmpColorsRGB 
       		{ pop true exit } if
    	} forall 
	dup true ne {pop false} if
	} bind def
/RealSetgray /setgray load def
/RealSetrgbcolor /setrgbcolor load def
/RealSethsbcolor /sethsbcolor load def
end 
/setgray { 
	FrameDict begin
	FrameSepIs FMnone eq
		{ RealSetgray } 
		{ 
		FrameSepIs FMblack eq 
			{ RealSetgray } 
			{ FrameSepIs FMcustom eq 
			  FrameSepRed 0 eq and
			  FrameSepGreen 0 eq and
			  FrameSepBlue 0 eq and {
			  	RealSetgray
			  } {
				1 RealSetgray pop 
			  } ifelse
			} ifelse
		} ifelse
	end
} bind def
/setrgbcolor { 
	FrameDict begin
	FrameSepIs FMnone eq
	{  RealSetrgbcolor }
	{
		3 copy [ 4 1 roll ] 
		FrameColorInSepListRGB
		{
				FrameSepBlue eq exch 
			 	FrameSepGreen eq and exch 
			 	FrameSepRed eq and
			 	{ 0 } { 1 } ifelse
		}
		{
			FMPColor {
				RealSetrgbcolor
				currentcmykcolor
			} {
				RGBtoCMYK
			} ifelse
			FrameSepIs FMblack eq
			{1.0 exch sub 4 1 roll pop pop pop} {
			FrameSepIs FMyellow eq
			{pop 1.0 exch sub 3 1 roll pop pop} {
			FrameSepIs FMmagenta eq
			{pop pop 1.0 exch sub exch pop } {
			FrameSepIs FMcyan eq
			{pop pop pop 1.0 exch sub } 
			{pop pop pop pop 1} ifelse } ifelse } ifelse } ifelse 
		} ifelse
		RealSetgray
	} 
	ifelse
	end
} bind def
/sethsbcolor {
	FrameDict begin
	FrameSepIs FMnone eq 
	{ RealSethsbcolor } 
	{
		RealSethsbcolor 
		currentrgbcolor  
		setrgbcolor 
	} 
	ifelse
	end
} bind def
FrameDict begin
/setcmykcolor where {
	pop /RealSetcmykcolor /setcmykcolor load def
} {
	/RealSetcmykcolor {
		4 1 roll
		3 { 3 index add 0 max 1 min 1 exch sub 3 1 roll} repeat 
		setrgbcolor pop
	} bind def
} ifelse
userdict /setcmykcolor { 
		FrameDict begin
		FrameSepIs FMnone eq
		{ RealSetcmykcolor } 
		{
			4 copy [ 5 1 roll ]
			FrameColorInSepListCMYK
			{
				FrameSepBlack eq exch 
				FrameSepYellow eq and exch 
				FrameSepMagenta eq and exch 
				FrameSepCyan eq and 
				{ 0 } { 1 } ifelse
			}
			{
				FrameSepIs FMblack eq
				{1.0 exch sub 4 1 roll pop pop pop} {
				FrameSepIs FMyellow eq
				{pop 1.0 exch sub 3 1 roll pop pop} {
				FrameSepIs FMmagenta eq
				{pop pop 1.0 exch sub exch pop } {
				FrameSepIs FMcyan eq
				{pop pop pop 1.0 exch sub } 
				{pop pop pop pop 1} ifelse } ifelse } ifelse } ifelse 
			} ifelse
			RealSetgray
		}
		ifelse
		end
	} bind put
FMLevel1 not { 
	
	/patProcDict 5 dict dup begin
		<0f1e3c78f0e1c387> { 3 setlinewidth -1 -1 moveto 9 9 lineto stroke 
											4 -4 moveto 12 4 lineto stroke
											-4 4 moveto 4 12 lineto stroke} bind def
		<0f87c3e1f0783c1e> { 3 setlinewidth -1 9 moveto 9 -1 lineto stroke 
											-4 4 moveto 4 -4 lineto stroke
											4 12 moveto 12 4 lineto stroke} bind def
		<8142241818244281> { 1 setlinewidth -1 9 moveto 9 -1 lineto stroke
											-1 -1 moveto 9 9 lineto stroke } bind def
		<03060c183060c081> { 1 setlinewidth -1 -1 moveto 9 9 lineto stroke 
											4 -4 moveto 12 4 lineto stroke
											-4 4 moveto 4 12 lineto stroke} bind def
		<8040201008040201> { 1 setlinewidth -1 9 moveto 9 -1 lineto stroke 
											-4 4 moveto 4 -4 lineto stroke
											4 12 moveto 12 4 lineto stroke} bind def
	end def
	/patDict 15 dict dup begin
		/PatternType 1 def		
		/PaintType 2 def		
		/TilingType 3 def		
		/BBox [ 0 0 8 8 ] def 	
		/XStep 8 def			
		/YStep 8 def			
		/PaintProc {
			begin
			patProcDict bstring known {
				patProcDict bstring get exec
			} {
				8 8 true [1 0 0 -1 0 8] bstring imagemask
			} ifelse
			end
		} bind def
	end def
} if
/combineColor {
    FrameSepIs FMnone eq
	{
		graymode FMLevel1 or not {
			
			[/Pattern [/DeviceCMYK]] setcolorspace
			FrameCurColors 0 4 getinterval aload pop FrameCurPat setcolor
		} {
			FrameCurColors 3 get 1.0 ge {
				FrameCurGray RealSetgray
			} {
				FMPColor graymode and {
					0 1 3 { 
						FrameCurColors exch get
						1 FrameCurGray sub mul
					} for
					RealSetcmykcolor
				} {
					4 1 6 {
						FrameCurColors exch get
						graymode {
							1 exch sub 1 FrameCurGray sub mul 1 exch sub
						} {
							1.0 lt {FrameCurGray} {1} ifelse
						} ifelse
					} for
					RealSetrgbcolor
				} ifelse
			} ifelse
		} ifelse
	} { 
		FrameCurColors 0 4 getinterval aload
		FrameColorInSepListCMYK {
			FrameSepBlack eq exch 
			FrameSepYellow eq and exch 
			FrameSepMagenta eq and exch 
			FrameSepCyan eq and
			FrameSepIs FMcustom eq and
			{ FrameCurGray } { 1 } ifelse
		} {
			FrameSepIs FMblack eq
			{FrameCurGray 1.0 exch sub mul 1.0 exch sub 4 1 roll pop pop pop} {
			FrameSepIs FMyellow eq
			{pop FrameCurGray 1.0 exch sub mul 1.0 exch sub 3 1 roll pop pop} {
			FrameSepIs FMmagenta eq
			{pop pop FrameCurGray 1.0 exch sub mul 1.0 exch sub exch pop } {
			FrameSepIs FMcyan eq
			{pop pop pop FrameCurGray 1.0 exch sub mul 1.0 exch sub } 
			{pop pop pop pop 1} ifelse } ifelse } ifelse } ifelse 
		} ifelse
		graymode FMLevel1 or not {
			
			[/Pattern [/DeviceGray]] setcolorspace
			FrameCurPat setcolor
		} { 
			graymode not FMLevel1 and {
				
				dup 1 lt {pop FrameCurGray} if
			} if
			RealSetgray
		} ifelse
	} ifelse
} bind def
/savematrix {
	orgmatrix currentmatrix pop
	} bind def
/restorematrix {
	orgmatrix setmatrix
	} bind def
/dmatrix matrix def
/dpi    72 0 dmatrix defaultmatrix dtransform
    dup mul exch   dup mul add   sqrt def
	
/freq dpi dup 72 div round dup 0 eq {pop 1} if 8 mul div def
/sangle 1 0 dmatrix defaultmatrix dtransform exch atan def
/dpiranges   [  2540    2400    1693     1270    1200     635      600      0      ] def
/CMLowFreqs  [ 100.402  94.8683 89.2289 100.402  94.8683  66.9349  63.2456 47.4342 ] def
/YLowFreqs   [  95.25   90.0    84.65    95.25   90.0     70.5556  66.6667 50.0    ] def
/KLowFreqs   [  89.8026 84.8528 79.8088  89.8026 84.8528  74.8355  70.7107 53.033  ] def
/CLowAngles  [  71.5651 71.5651 71.5651 71.5651  71.5651  71.5651  71.5651 71.5651 ] def
/MLowAngles  [  18.4349 18.4349 18.4349 18.4349  18.4349  18.4349  18.4349 18.4349 ] def
/YLowTDot    [  true    true    false    true    true     false    false   false   ] def
/CMHighFreqs [ 133.87  126.491 133.843  108.503 102.523  100.402   94.8683 63.2456 ] def
/YHighFreqs  [ 127.0   120.0   126.975  115.455 109.091   95.25    90.0    60.0    ] def
/KHighFreqs  [ 119.737 113.137 119.713  128.289 121.218   89.8026  84.8528 63.6395 ] def
/CHighAngles [  71.5651 71.5651 71.5651  70.0169 70.0169  71.5651  71.5651 71.5651 ] def
/MHighAngles [  18.4349 18.4349 18.4349  19.9831 19.9831  18.4349  18.4349 18.4349 ] def
/YHighTDot   [  false   false   true     false   false    true     true    false   ] def
/PatFreq     [	10.5833 10.0     9.4055  10.5833 10.0	  10.5833  10.0	   9.375   ] def
/screenIndex {
	0 1 dpiranges length 1 sub { dup dpiranges exch get 1 sub dpi le {exit} {pop} ifelse } for
} bind def
/getCyanScreen {
	FMUseHighFrequencyScreens { CHighAngles CMHighFreqs} {CLowAngles CMLowFreqs} ifelse
		screenIndex dup 3 1 roll get 3 1 roll get /FMSpotFunction load
} bind def
/getMagentaScreen {
	FMUseHighFrequencyScreens { MHighAngles CMHighFreqs } {MLowAngles CMLowFreqs} ifelse
		screenIndex dup 3 1 roll get 3 1 roll get /FMSpotFunction load
} bind def
/getYellowScreen {
	FMUseHighFrequencyScreens { YHighTDot YHighFreqs} { YLowTDot YLowFreqs } ifelse
		screenIndex dup 3 1 roll get 3 1 roll get { 3 div
			{2 { 1 add 2 div 3 mul dup floor sub 2 mul 1 sub exch} repeat
			FMSpotFunction } } {/FMSpotFunction load } ifelse
			0.0 exch
} bind def
/getBlackScreen  {
	FMUseHighFrequencyScreens { KHighFreqs } { KLowFreqs } ifelse
		screenIndex get 45.0 /FMSpotFunction load 
} bind def
/getSpotScreen {
	getBlackScreen
} bind def
/getCompositeScreen {
	getBlackScreen
} bind def
/FMSetScreen 
	FMLevel1 { /setscreen load 
	}{ {
		8 dict begin
		/HalftoneType 1 def
		/SpotFunction exch def
		/Angle exch def
		/Frequency exch def
		/AccurateScreens FMUseAcccurateScreens def
		currentdict end sethalftone
	} bind } ifelse
def
/setDefaultScreen {
	FMPColor {
		orgrxfer cvx orggxfer cvx orgbxfer cvx orgxfer cvx setcolortransfer
	}
	{
		orgxfer cvx settransfer
	} ifelse
	orgfreq organgle orgproc cvx setscreen
} bind def
/setCurrentScreen {
	FrameSepIs FMnone eq {
		FMUseDefaultNoSeparationScreen {
			setDefaultScreen
		} {
			getCompositeScreen FMSetScreen
		} ifelse
	} {
		FrameSepIs FMcustom eq {
			FMUseDefaultSpotSeparationScreen {
				setDefaultScreen
			} {
				getSpotScreen FMSetScreen
			} ifelse
		} {
			FMUseDefaultProcessSeparationScreen {
				setDefaultScreen
			} {
				FrameSepIs FMcyan eq {
					getCyanScreen FMSetScreen
				} {
					FrameSepIs FMmagenta eq {
						getMagentaScreen FMSetScreen
					} {
						FrameSepIs FMyellow eq {
							getYellowScreen FMSetScreen
						} {
							getBlackScreen FMSetScreen
						} ifelse
					} ifelse
				} ifelse
			} ifelse
		} ifelse
	} ifelse 
} bind def
end
	/gstring FMLOCAL
	/gfile FMLOCAL
	/gindex FMLOCAL
	/orgrxfer FMLOCAL
	/orggxfer FMLOCAL
	/orgbxfer FMLOCAL
	/orgxfer FMLOCAL
	/orgproc FMLOCAL
	/orgrproc FMLOCAL
	/orggproc FMLOCAL
	/orgbproc FMLOCAL
	/organgle FMLOCAL
	/orgrangle FMLOCAL
	/orggangle FMLOCAL
	/orgbangle FMLOCAL
	/orgfreq FMLOCAL
	/orgrfreq FMLOCAL
	/orggfreq FMLOCAL
	/orgbfreq FMLOCAL
	/yscale FMLOCAL
	/xscale FMLOCAL
	/edown FMLOCAL
	/manualfeed FMLOCAL
	/paperheight FMLOCAL
	/paperwidth FMLOCAL
/FMDOCUMENT { 
	array /FMfonts exch def 
	/#copies exch def
	FrameDict begin
	0 ne /manualfeed exch def
	/paperheight exch def
	/paperwidth exch def
	0 ne /FrameNegative exch def 
	0 ne /edown exch def 
	/yscale exch def
	/xscale exch def
	FMLevel1 {
		manualfeed {setmanualfeed} if
		/FMdicttop countdictstack 1 add def 
		/FMoptop count def 
		setpapername 
		manualfeed {true} {papersize} ifelse 
		{manualpapersize} {false} ifelse 
		{desperatepapersize} {false} ifelse 
		{ (Can't select requested paper size for Frame print job!) FMFAILURE } if
		count -1 FMoptop {pop pop} for
		countdictstack -1 FMdicttop {pop end} for 
		}
		{{1 dict dup /PageSize [paperwidth paperheight]put setpagedevice}stopped
		{ (Can't select requested paper size for Frame print job!) FMFAILURE } if
		 {1 dict dup /ManualFeed manualfeed put setpagedevice } stopped pop }
	ifelse 
	
	FMPColor {
		currentcolorscreen
			cvlit /orgproc exch def
				  /organgle exch def 
				  /orgfreq exch def
			cvlit /orgbproc exch def
				  /orgbangle exch def 
				  /orgbfreq exch def
			cvlit /orggproc exch def
				  /orggangle exch def 
				  /orggfreq exch def
			cvlit /orgrproc exch def
				  /orgrangle exch def 
				  /orgrfreq exch def
			currentcolortransfer 
			FrameNegative {
				1 1 4 { 
					pop { 1 exch sub } concatprocs 4 1 roll
				} for
				4 copy
				setcolortransfer
			} if
			cvlit /orgxfer exch def
			cvlit /orgbxfer exch def
			cvlit /orggxfer exch def
			cvlit /orgrxfer exch def
	} {
		currentscreen 
			cvlit /orgproc exch def
				  /organgle exch def 
				  /orgfreq exch def
				  
		currenttransfer 
		FrameNegative {
			{ 1 exch sub } concatprocs
			dup settransfer
		} if 
		cvlit /orgxfer exch def
	} ifelse
	end 
} def 
/pagesave FMLOCAL
/orgmatrix FMLOCAL
/landscape FMLOCAL
/pwid FMLOCAL
/FMBEGINPAGE { 
	FrameDict begin 
	/pagesave save def
	3.86 setmiterlimit
	/landscape exch 0 ne def
	landscape { 
		90 rotate 0 exch dup /pwid exch def neg translate pop 
	}{
		pop /pwid exch def
	} ifelse
	edown { [-1 0 0 1 pwid 0] concat } if
	0 0 moveto paperwidth 0 lineto paperwidth paperheight lineto 
	0 paperheight lineto 0 0 lineto 1 setgray fill
	xscale yscale scale
	/orgmatrix matrix def
	gsave 
} def 
/FMENDPAGE {
	grestore 
	pagesave restore
	end 
	showpage
	} def 
/FMFONTDEFINE { 
	FrameDict begin
	findfont 
	ReEncode 
	1 index exch 
	definefont 
	FMfonts 3 1 roll 
	put
	end 
	} def 
/FMFILLS {
	FrameDict begin dup
	array /fillvals exch def
	dict /patCache exch def
	end 
	} def 
/FMFILL {
	FrameDict begin
	 fillvals 3 1 roll put
	end 
	} def 
/FMNORMALIZEGRAPHICS { 
	newpath
	0.0 0.0 moveto
	1 setlinewidth
	0 setlinecap
	0 0 0 sethsbcolor
	0 setgray 
	} bind def
	/fx FMLOCAL
	/fy FMLOCAL
	/fh FMLOCAL
	/fw FMLOCAL
	/llx FMLOCAL
	/lly FMLOCAL
	/urx FMLOCAL
	/ury FMLOCAL
/FMBEGINEPSF { 
	end 
	/FMEPSF save def 
	/showpage {} def 
% See Adobe's "PostScript Language Reference Manual, 2nd Edition", page 714.
% "...the following operators MUST NOT be used in an EPS file:" (emphasis ours)
	/banddevice {(banddevice) FMBADEPSF} def
	/clear {(clear) FMBADEPSF} def
	/cleardictstack {(cleardictstack) FMBADEPSF} def 
	/copypage {(copypage) FMBADEPSF} def
	/erasepage {(erasepage) FMBADEPSF} def
	/exitserver {(exitserver) FMBADEPSF} def
	/framedevice {(framedevice) FMBADEPSF} def
	/grestoreall {(grestoreall) FMBADEPSF} def
	/initclip {(initclip) FMBADEPSF} def
	/initgraphics {(initgraphics) FMBADEPSF} def
	/initmatrix {(initmatrix) FMBADEPSF} def
	/quit {(quit) FMBADEPSF} def
	/renderbands {(renderbands) FMBADEPSF} def
	/setglobal {(setglobal) FMBADEPSF} def
	/setpagedevice {(setpagedevice) FMBADEPSF} def
	/setshared {(setshared) FMBADEPSF} def
	/startjob {(startjob) FMBADEPSF} def
	/lettertray {(lettertray) FMBADEPSF} def
	/letter {(letter) FMBADEPSF} def
	/lettersmall {(lettersmall) FMBADEPSF} def
	/11x17tray {(11x17tray) FMBADEPSF} def
	/11x17 {(11x17) FMBADEPSF} def
	/ledgertray {(ledgertray) FMBADEPSF} def
	/ledger {(ledger) FMBADEPSF} def
	/legaltray {(legaltray) FMBADEPSF} def
	/legal {(legal) FMBADEPSF} def
	/statementtray {(statementtray) FMBADEPSF} def
	/statement {(statement) FMBADEPSF} def
	/executivetray {(executivetray) FMBADEPSF} def
	/executive {(executive) FMBADEPSF} def
	/a3tray {(a3tray) FMBADEPSF} def
	/a3 {(a3) FMBADEPSF} def
	/a4tray {(a4tray) FMBADEPSF} def
	/a4 {(a4) FMBADEPSF} def
	/a4small {(a4small) FMBADEPSF} def
	/b4tray {(b4tray) FMBADEPSF} def
	/b4 {(b4) FMBADEPSF} def
	/b5tray {(b5tray) FMBADEPSF} def
	/b5 {(b5) FMBADEPSF} def
	FMNORMALIZEGRAPHICS 
	[/fy /fx /fh /fw /ury /urx /lly /llx] {exch def} forall 
	fx fw 2 div add fy fh 2 div add  translate
	rotate
	fw 2 div neg fh 2 div neg translate
	fw urx llx sub div fh ury lly sub div scale 
	llx neg lly neg translate 
	/FMdicttop countdictstack 1 add def 
	/FMoptop count def 
	} bind def
/FMENDEPSF {
	count -1 FMoptop {pop pop} for 
	countdictstack -1 FMdicttop {pop end} for 
	FMEPSF restore
	FrameDict begin 
	} bind def
FrameDict begin 
/setmanualfeed {
%%BeginFeature *ManualFeed True
	 statusdict /manualfeed true put
%%EndFeature
	} bind def
/max {2 copy lt {exch} if pop} bind def
/min {2 copy gt {exch} if pop} bind def
/inch {72 mul} def
/pagedimen { 
	paperheight sub abs 16 lt exch 
	paperwidth sub abs 16 lt and
	{/papername exch def} {pop} ifelse
	} bind def
	/papersizedict FMLOCAL
/setpapername { 
	/papersizedict 14 dict def 
	papersizedict begin
	/papername /unknown def 
		/Letter 8.5 inch 11.0 inch pagedimen
		/LetterSmall 7.68 inch 10.16 inch pagedimen
		/Tabloid 11.0 inch 17.0 inch pagedimen
		/Ledger 17.0 inch 11.0 inch pagedimen
		/Legal 8.5 inch 14.0 inch pagedimen
		/Statement 5.5 inch 8.5 inch pagedimen
		/Executive 7.5 inch 10.0 inch pagedimen
		/A3 11.69 inch 16.5 inch pagedimen
		/A4 8.26 inch 11.69 inch pagedimen
		/A4Small 7.47 inch 10.85 inch pagedimen
		/B4 10.125 inch 14.33 inch pagedimen
		/B5 7.16 inch 10.125 inch pagedimen
	end
	} bind def
/papersize {
	papersizedict begin
		/Letter {lettertray letter} def
		/LetterSmall {lettertray lettersmall} def
		/Tabloid {11x17tray 11x17} def
		/Ledger {ledgertray ledger} def
		/Legal {legaltray legal} def
		/Statement {statementtray statement} def
		/Executive {executivetray executive} def
		/A3 {a3tray a3} def
		/A4 {a4tray a4} def
		/A4Small {a4tray a4small} def
		/B4 {b4tray b4} def
		/B5 {b5tray b5} def
		/unknown {unknown} def
	papersizedict dup papername known {papername} {/unknown} ifelse get
	end
	statusdict begin stopped end 
	} bind def
/manualpapersize {
	papersizedict begin
		/Letter {letter} def
		/LetterSmall {lettersmall} def
		/Tabloid {11x17} def
		/Ledger {ledger} def
		/Legal {legal} def
		/Statement {statement} def
		/Executive {executive} def
		/A3 {a3} def
		/A4 {a4} def
		/A4Small {a4small} def
		/B4 {b4} def
		/B5 {b5} def
		/unknown {unknown} def
	papersizedict dup papername known {papername} {/unknown} ifelse get
	end
	stopped 
	} bind def
/desperatepapersize {
	statusdict /setpageparams known
		{
		paperwidth paperheight 0 1 
		statusdict begin
		{setpageparams} stopped 
		end
		} {true} ifelse 
	} bind def
/DiacriticEncoding [
/.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef
/.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef
/.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef
/.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef
/.notdef /.notdef /.notdef /.notdef /space /exclam /quotedbl
/numbersign /dollar /percent /ampersand /quotesingle /parenleft
/parenright /asterisk /plus /comma /hyphen /period /slash /zero /one
/two /three /four /five /six /seven /eight /nine /colon /semicolon
/less /equal /greater /question /at /A /B /C /D /E /F /G /H /I /J /K
/L /M /N /O /P /Q /R /S /T /U /V /W /X /Y /Z /bracketleft /backslash
/bracketright /asciicircum /underscore /grave /a /b /c /d /e /f /g /h
/i /j /k /l /m /n /o /p /q /r /s /t /u /v /w /x /y /z /braceleft /bar
/braceright /asciitilde /.notdef /Adieresis /Aring /Ccedilla /Eacute
/Ntilde /Odieresis /Udieresis /aacute /agrave /acircumflex /adieresis
/atilde /aring /ccedilla /eacute /egrave /ecircumflex /edieresis
/iacute /igrave /icircumflex /idieresis /ntilde /oacute /ograve
/ocircumflex /odieresis /otilde /uacute /ugrave /ucircumflex
/udieresis /dagger /.notdef /cent /sterling /section /bullet
/paragraph /germandbls /registered /copyright /trademark /acute
/dieresis /.notdef /AE /Oslash /.notdef /.notdef /.notdef /.notdef
/yen /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef
/ordfeminine /ordmasculine /.notdef /ae /oslash /questiondown
/exclamdown /logicalnot /.notdef /florin /.notdef /.notdef
/guillemotleft /guillemotright /ellipsis /.notdef /Agrave /Atilde
/Otilde /OE /oe /endash /emdash /quotedblleft /quotedblright
/quoteleft /quoteright /.notdef /.notdef /ydieresis /Ydieresis
/fraction /currency /guilsinglleft /guilsinglright /fi /fl /daggerdbl
/periodcentered /quotesinglbase /quotedblbase /perthousand
/Acircumflex /Ecircumflex /Aacute /Edieresis /Egrave /Iacute
/Icircumflex /Idieresis /Igrave /Oacute /Ocircumflex /.notdef /Ograve
/Uacute /Ucircumflex /Ugrave /dotlessi /circumflex /tilde /macron
/breve /dotaccent /ring /cedilla /hungarumlaut /ogonek /caron
] def
/ReEncode { 
	dup 
	length 
	dict begin 
	{
	1 index /FID ne 
		{def} 
		{pop pop} ifelse 
	} forall 
	0 eq {/Encoding DiacriticEncoding def} if 
	currentdict 
	end 
	} bind def
FMPColor 
	
	{
	/BEGINBITMAPCOLOR { 
		BITMAPCOLOR} def
	/BEGINBITMAPCOLORc { 
		BITMAPCOLORc} def
	/BEGINBITMAPTRUECOLOR { 
		BITMAPTRUECOLOR } def
	/BEGINBITMAPTRUECOLORc { 
		BITMAPTRUECOLORc } def
	}
	
	{
	/BEGINBITMAPCOLOR { 
		BITMAPGRAY} def
	/BEGINBITMAPCOLORc { 
		BITMAPGRAYc} def
	/BEGINBITMAPTRUECOLOR { 
		BITMAPTRUEGRAY } def
	/BEGINBITMAPTRUECOLORc { 
		BITMAPTRUEGRAYc } def
	}
ifelse
/K { 
	FMPrintAllColorsAsBlack {
		dup 1 eq 2 index 1 eq and 3 index 1 eq and not
			{7 {pop} repeat 0 0 0 1 0 0 0} if
	} if 
	FrameCurColors astore 
	pop combineColor
} bind def
/graymode true def
	/bwidth FMLOCAL
	/bpside FMLOCAL
	/bstring FMLOCAL
	/onbits FMLOCAL
	/offbits FMLOCAL
	/xindex FMLOCAL
	/yindex FMLOCAL
	/x FMLOCAL
	/y FMLOCAL
/setPatternMode {
	FMLevel1 {
		/bwidth  exch def
		/bpside  exch def
		/bstring exch def
		/onbits 0 def  /offbits 0 def
		freq sangle landscape {90 add} if 
			{/y exch def
			 /x exch def
			 /xindex x 1 add 2 div bpside mul cvi def
			 /yindex y 1 add 2 div bpside mul cvi def
			 bstring yindex bwidth mul xindex 8 idiv add get
			 1 7 xindex 8 mod sub bitshift and 0 ne FrameNegative {not} if
			 {/onbits  onbits  1 add def 1}
			 {/offbits offbits 1 add def 0}
			 ifelse
			}
			setscreen
		offbits offbits onbits add div FrameNegative {1.0 exch sub} if
		/FrameCurGray exch def
	} { 
		pop pop
		dup patCache exch known {
			patCache exch get
		} { 
			dup
			patDict /bstring 3 -1 roll put
			patDict 
			9 PatFreq screenIndex get div dup matrix scale
			makepattern
			dup 
			patCache 4 -1 roll 3 -1 roll put
		} ifelse
		/FrameCurGray 0 def
		/FrameCurPat exch def
	} ifelse
	/graymode false def
	combineColor
} bind def
/setGrayScaleMode {
	graymode not {
		/graymode true def
		FMLevel1 {
			setCurrentScreen
		} if
	} if
	/FrameCurGray exch def
	combineColor
} bind def
/normalize {
	transform round exch round exch itransform
	} bind def
/dnormalize {
	dtransform round exch round exch idtransform
	} bind def
/lnormalize { 
	0 dtransform exch cvi 2 idiv 2 mul 1 add exch idtransform pop
	} bind def
/H { 
	lnormalize setlinewidth
	} bind def
/Z {
	setlinecap
	} bind def
	
/PFill {
	graymode FMLevel1 or not {
		gsave 1 setgray eofill grestore
	} if
} bind def
/PStroke {
	graymode FMLevel1 or not {
		gsave 1 setgray stroke grestore
	} if
	stroke
} bind def
	/fillvals FMLOCAL
/X { 
	fillvals exch get
	dup type /stringtype eq
	{8 1 setPatternMode} 
	{setGrayScaleMode}
	ifelse
	} bind def
/V { 
	PFill gsave eofill grestore
	} bind def
/Vclip {
	clip
	} bind def
/Vstrk {
	currentlinewidth exch setlinewidth PStroke setlinewidth
	} bind def
/N { 
	PStroke
	} bind def
/Nclip {
	strokepath clip newpath
	} bind def
/Nstrk {
	currentlinewidth exch setlinewidth PStroke setlinewidth
	} bind def
/M {newpath moveto} bind def
/E {lineto} bind def
/D {curveto} bind def
/O {closepath} bind def
	/n FMLOCAL
/L { 
 	/n exch def
	newpath
	normalize
	moveto 
	2 1 n {pop normalize lineto} for
	} bind def
/Y { 
	L 
	closepath
	} bind def
	/x1 FMLOCAL
	/x2 FMLOCAL
	/y1 FMLOCAL
	/y2 FMLOCAL
/R { 
	/y2 exch def
	/x2 exch def
	/y1 exch def
	/x1 exch def
	x1 y1
	x2 y1
	x2 y2
	x1 y2
	4 Y 
	} bind def
	/rad FMLOCAL
/rarc 
	{rad 
	 arcto
	} bind def
/RR { 
	/rad exch def
	normalize
	/y2 exch def
	/x2 exch def
	normalize
	/y1 exch def
	/x1 exch def
	mark
	newpath
	{
	x1 y1 rad add moveto
	x1 y2 x2 y2 rarc
	x2 y2 x2 y1 rarc
	x2 y1 x1 y1 rarc
	x1 y1 x1 y2 rarc
	closepath
	} stopped {x1 y1 x2 y2 R} if 
	cleartomark
	} bind def
/RRR { 
	/rad exch def
	normalize /y4 exch def /x4 exch def
	normalize /y3 exch def /x3 exch def
	normalize /y2 exch def /x2 exch def
	normalize /y1 exch def /x1 exch def
	newpath
	normalize moveto 
	mark
	{
	x2 y2 x3 y3 rarc
	x3 y3 x4 y4 rarc
	x4 y4 x1 y1 rarc
	x1 y1 x2 y2 rarc
	closepath
	} stopped
	 {x1 y1 x2 y2 x3 y3 x4 y4 newpath moveto lineto lineto lineto closepath} if
	cleartomark
	} bind def
/C { 
	grestore
	gsave
	R 
	clip
	setCurrentScreen
} bind def
/CP { 
	grestore
	gsave
	Y 
	clip
	setCurrentScreen
} bind def
	/FMpointsize FMLOCAL
/F { 
	FMfonts exch get
	FMpointsize scalefont
	setfont
	} bind def
/Q { 
	/FMpointsize exch def
	F 
	} bind def
/T { 
	moveto show
	} bind def
/RF { 
	rotate
	0 ne {-1 1 scale} if
	} bind def
/TF { 
	gsave
	moveto 
	RF
	show
	grestore
	} bind def
/P { 
	moveto
	0 32 3 2 roll widthshow
	} bind def
/PF { 
	gsave
	moveto 
	RF
	0 32 3 2 roll widthshow
	grestore
	} bind def
/S { 
	moveto
	0 exch ashow
	} bind def
/SF { 
	gsave
	moveto
	RF
	0 exch ashow
	grestore
	} bind def
/B { 
	moveto
	0 32 4 2 roll 0 exch awidthshow
	} bind def
/BF { 
	gsave
	moveto
	RF
	0 32 4 2 roll 0 exch awidthshow
	grestore
	} bind def
/G { 
	gsave
	newpath
	normalize translate 0.0 0.0 moveto 
	dnormalize scale 
	0.0 0.0 1.0 5 3 roll arc 
	closepath 
	PFill fill
	grestore
	} bind def
/Gstrk {
	savematrix
    newpath
    2 index 2 div add exch 3 index 2 div sub exch 
    normalize 2 index 2 div sub exch 3 index 2 div add exch 
    translate
    scale 
    0.0 0.0 1.0 5 3 roll arc 
    restorematrix
    currentlinewidth exch setlinewidth PStroke setlinewidth
    } bind def
/Gclip { 
	newpath
	savematrix
	normalize translate 0.0 0.0 moveto 
	dnormalize scale 
	0.0 0.0 1.0 5 3 roll arc 
	closepath 
	clip newpath
	restorematrix
	} bind def
/GG { 
	gsave
	newpath
	normalize translate 0.0 0.0 moveto 
	rotate 
	dnormalize scale 
	0.0 0.0 1.0 5 3 roll arc 
	closepath
	PFill
	fill
	grestore
	} bind def
/GGclip { 
	savematrix
	newpath
    normalize translate 0.0 0.0 moveto 
    rotate 
    dnormalize scale 
    0.0 0.0 1.0 5 3 roll arc 
    closepath
	clip newpath
	restorematrix
	} bind def
/GGstrk { 
	savematrix
    newpath
    normalize translate 0.0 0.0 moveto 
    rotate 
    dnormalize scale 
    0.0 0.0 1.0 5 3 roll arc 
    closepath 
	restorematrix
    currentlinewidth exch setlinewidth PStroke setlinewidth
	} bind def
/A { 
	gsave
	savematrix
	newpath
	2 index 2 div add exch 3 index 2 div sub exch 
	normalize 2 index 2 div sub exch 3 index 2 div add exch 
	translate 
	scale 
	0.0 0.0 1.0 5 3 roll arc 
	restorematrix
	PStroke
	grestore
	} bind def
/Aclip {
	newpath
	savematrix
	normalize translate 0.0 0.0 moveto 
	dnormalize scale 
	0.0 0.0 1.0 5 3 roll arc 
	closepath 
	strokepath clip newpath
	restorematrix
} bind def
/Astrk {
	Gstrk
} bind def
/AA { 
	gsave
	savematrix
	newpath
	
	3 index 2 div add exch 4 index 2 div sub exch 
	
	normalize 3 index 2 div sub exch 4 index 2 div add exch
	translate 
	rotate 
	scale 
	0.0 0.0 1.0 5 3 roll arc 
	restorematrix
	PStroke
	grestore
	} bind def
/AAclip {
	savematrix
	newpath
    normalize translate 0.0 0.0 moveto 
    rotate 
    dnormalize scale 
    0.0 0.0 1.0 5 3 roll arc 
    closepath
	strokepath clip newpath
	restorematrix
} bind def
/AAstrk {
	GGstrk
} bind def
	/x FMLOCAL
	/y FMLOCAL
	/w FMLOCAL
	/h FMLOCAL
	/xx FMLOCAL
	/yy FMLOCAL
	/ww FMLOCAL
	/hh FMLOCAL
	/FMsaveobject FMLOCAL
	/FMoptop FMLOCAL
	/FMdicttop FMLOCAL
/BEGINPRINTCODE { 
	/FMdicttop countdictstack 1 add def 
	/FMoptop count 7 sub def 
	/FMsaveobject save def
	userdict begin 
	/showpage {} def 
	FMNORMALIZEGRAPHICS 
	3 index neg 3 index neg translate
	} bind def
/ENDPRINTCODE {
	count -1 FMoptop {pop pop} for 
	countdictstack -1 FMdicttop {pop end} for 
	FMsaveobject restore 
	} bind def
/gn { 
	0 
	{	46 mul 
		cf read pop 
		32 sub 
		dup 46 lt {exit} if 
		46 sub add 
		} loop
	add 
	} bind def
	/str FMLOCAL
/cfs { 
	/str sl string def 
	0 1 sl 1 sub {str exch val put} for 
	str def 
	} bind def
/ic [ 
	0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0223
	0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0223
	0
	{0 hx} {1 hx} {2 hx} {3 hx} {4 hx} {5 hx} {6 hx} {7 hx} {8 hx} {9 hx}
	{10 hx} {11 hx} {12 hx} {13 hx} {14 hx} {15 hx} {16 hx} {17 hx} {18 hx}
	{19 hx} {gn hx} {0} {1} {2} {3} {4} {5} {6} {7} {8} {9} {10} {11} {12}
	{13} {14} {15} {16} {17} {18} {19} {gn} {0 wh} {1 wh} {2 wh} {3 wh}
	{4 wh} {5 wh} {6 wh} {7 wh} {8 wh} {9 wh} {10 wh} {11 wh} {12 wh}
	{13 wh} {14 wh} {gn wh} {0 bl} {1 bl} {2 bl} {3 bl} {4 bl} {5 bl} {6 bl}
	{7 bl} {8 bl} {9 bl} {10 bl} {11 bl} {12 bl} {13 bl} {14 bl} {gn bl}
	{0 fl} {1 fl} {2 fl} {3 fl} {4 fl} {5 fl} {6 fl} {7 fl} {8 fl} {9 fl}
	{10 fl} {11 fl} {12 fl} {13 fl} {14 fl} {gn fl}
	] def
	/sl FMLOCAL
	/val FMLOCAL
	/ws FMLOCAL
	/im FMLOCAL
	/bs FMLOCAL
	/cs FMLOCAL
	/len FMLOCAL
	/pos FMLOCAL
/ms { 
	/sl exch def 
	/val 255 def 
	/ws cfs 
	/im cfs 
	/val 0 def 
	/bs cfs 
	/cs cfs 
	} bind def
400 ms 
/ip { 
	is 
	0 
	cf cs readline pop 
	{	ic exch get exec 
		add 
		} forall 
	pop 
	
	} bind def
/rip { 
	   
	  
	  bis ris copy pop 
      is
      0
      cf cs readline pop 
      {       ic exch get exec 
              add 
              } forall 
	  pop pop 
	  ris gis copy pop 
	  dup is exch 
	  
      cf cs readline pop 
      {       ic exch get exec 
              add 
              } forall 
	  pop pop
	  gis bis copy pop 
	  dup add is exch 
	  
      cf cs readline pop 
      {       ic exch get exec 
              add 
              } forall 
      pop 
      
      } bind def
/wh { 
	/len exch def 
	/pos exch def 
	ws 0 len getinterval im pos len getinterval copy pop
	pos len 
	} bind def
/bl { 
	/len exch def 
	/pos exch def 
	bs 0 len getinterval im pos len getinterval copy pop
	pos len 
	} bind def
/s1 1 string def
/fl { 
	/len exch def 
	/pos exch def 
	/val cf s1 readhexstring pop 0 get def
	pos 1 pos len add 1 sub {im exch val put} for
	pos len 
	} bind def
/hx { 
	3 copy getinterval 
	cf exch readhexstring pop pop 
	} bind def
	/h FMLOCAL
	/w FMLOCAL
	/d FMLOCAL
	/lb FMLOCAL
	/bitmapsave FMLOCAL
	/is FMLOCAL
	/cf FMLOCAL
/wbytes { 
      dup dup
      24 eq { pop pop 3 mul }
      { 8 eq {pop} {1 eq {7 add 8 idiv} {3 add 4 idiv} ifelse} ifelse } ifelse
	} bind def
/BEGINBITMAPBWc { 
	1 {} COMMONBITMAPc
	} bind def
/BEGINBITMAPGRAYc { 
	8 {} COMMONBITMAPc
	} bind def
/BEGINBITMAP2BITc { 
	2 {} COMMONBITMAPc
	} bind def
/COMMONBITMAPc { 
		 
	/r exch def
	/d exch def
	gsave
	
	3 index 2 div add exch	
	4 index 2 div add exch	
	translate		
	rotate			
	1 index 2 div neg	
	1 index 2 div neg	
	translate		
	scale			
	/h exch def /w exch def
	/lb w d wbytes def 
	sl lb lt {lb ms} if 
	/bitmapsave save def 
	r                    
	/is im 0 lb getinterval def 
	ws 0 lb getinterval is copy pop 
	/cf currentfile def 
	w h d [w 0 0 h neg 0 h] 
	{ip} image 
	bitmapsave restore 
	grestore
	} bind def
/BEGINBITMAPBW { 
	1 {} COMMONBITMAP
	} bind def
/BEGINBITMAPGRAY { 
	8 {} COMMONBITMAP
	} bind def
/BEGINBITMAP2BIT { 
	2 {} COMMONBITMAP
	} bind def
/COMMONBITMAP { 
	/r exch def
	/d exch def
	gsave
	
	3 index 2 div add exch	
	4 index 2 div add exch	
	translate		
	rotate			
	1 index 2 div neg	
	1 index 2 div neg	
	translate		
	scale			
	/h exch def /w exch def
	/bitmapsave save def 
	r                    
	/is w d wbytes string def
	/cf currentfile def 
	w h d [w 0 0 h neg 0 h] 
	{cf is readhexstring pop} image
	bitmapsave restore 
	grestore
	} bind def
/ngrayt 256 array def
/nredt 256 array def
/nbluet 256 array def
/ngreent 256 array def
	/gryt FMLOCAL
	/blut FMLOCAL
	/grnt FMLOCAL
	/redt FMLOCAL
	/indx FMLOCAL
	/cynu FMLOCAL
	/magu FMLOCAL
	/yelu FMLOCAL
	/k FMLOCAL
	/u FMLOCAL
FMLevel1 {
/colorsetup {
	currentcolortransfer
	/gryt exch def
	/blut exch def
	/grnt exch def
	/redt exch def
	0 1 255 {
		/indx exch def
		/cynu 1 red indx get 255 div sub def
		/magu 1 green indx get 255 div sub def
		/yelu 1 blue indx get 255 div sub def
		/k cynu magu min yelu min def
		/u k currentundercolorremoval exec def
%		/u 0 def
		nredt indx 1 0 cynu u sub max sub redt exec put
		ngreent indx 1 0 magu u sub max sub grnt exec put
		nbluet indx 1 0 yelu u sub max sub blut exec put
		ngrayt indx 1 k currentblackgeneration exec sub gryt exec put
	} for
	{255 mul cvi nredt exch get}
	{255 mul cvi ngreent exch get}
	{255 mul cvi nbluet exch get}
	{255 mul cvi ngrayt exch get}
	setcolortransfer
	{pop 0} setundercolorremoval
	{} setblackgeneration
	} bind def
}
{
/colorSetup2 {
	[ /Indexed /DeviceRGB 255 
		{dup red exch get 255 div 
		 exch dup green exch get 255 div 
		 exch blue exch get 255 div}
	] setcolorspace
} bind def
} ifelse
	/tran FMLOCAL
/fakecolorsetup {
	/tran 256 string def
	0 1 255 {/indx exch def 
		tran indx
		red indx get 77 mul
		green indx get 151 mul
		blue indx get 28 mul
		add add 256 idiv put} for
	currenttransfer
	{255 mul cvi tran exch get 255.0 div}
	exch concatprocs settransfer
} bind def
/BITMAPCOLOR { 
	/d 8 def
	gsave
	
	3 index 2 div add exch	
	4 index 2 div add exch	
	translate		
	rotate			
	1 index 2 div neg	
	1 index 2 div neg	
	translate		
	scale			
	/h exch def /w exch def
	/bitmapsave save def
	FMLevel1 {	
		colorsetup
		/is w d wbytes string def
		/cf currentfile def 
		w h d [w 0 0 h neg 0 h] 
		{cf is readhexstring pop} {is} {is} true 3 colorimage 
	} {
		colorSetup2
		/is w d wbytes string def
		/cf currentfile def 
		7 dict dup begin
			/ImageType 1 def
			/Width w def
			/Height h def
			/ImageMatrix [w 0 0 h neg 0 h] def
			/DataSource {cf is readhexstring pop} bind def
			/BitsPerComponent d def
			/Decode [0 255] def
		end image	
	} ifelse
	bitmapsave restore 
	grestore
	} bind def
/BITMAPCOLORc { 
	/d 8 def
	gsave
	
	3 index 2 div add exch	
	4 index 2 div add exch	
	translate		
	rotate			
	1 index 2 div neg	
	1 index 2 div neg	
	translate		
	scale			
	/h exch def /w exch def
	/lb w d wbytes def 
	sl lb lt {lb ms} if 
	/bitmapsave save def 
	FMLevel1 {	
		colorsetup
		/is im 0 lb getinterval def 
		ws 0 lb getinterval is copy pop 
		/cf currentfile def 
		w h d [w 0 0 h neg 0 h] 
		{ip} {is} {is} true 3 colorimage
	} {
		colorSetup2
		/is im 0 lb getinterval def 
		ws 0 lb getinterval is copy pop 
		/cf currentfile def 
		7 dict dup begin
			/ImageType 1 def
			/Width w def
			/Height h def
			/ImageMatrix [w 0 0 h neg 0 h] def
			/DataSource {ip} bind def
			/BitsPerComponent d def
			/Decode [0 255] def
		end image	
	} ifelse
	bitmapsave restore 
	grestore
	} bind def
/BITMAPTRUECOLORc { 
	/d 24 def
        gsave
 	
	3 index 2 div add exch	
	4 index 2 div add exch	
	translate		
	rotate			
	1 index 2 div neg	
	1 index 2 div neg	
	translate		
	scale			
	/h exch def /w exch def
	/lb w d wbytes def 
	sl lb lt {lb ms} if 
        /bitmapsave save def 
        
	/is im 0 lb getinterval def	
	/ris im 0 w getinterval def	
	/gis im w w getinterval def	
	/bis im w 2 mul w getinterval def 
        
        ws 0 lb getinterval is copy pop 
        /cf currentfile def 
        w h 8 [w 0 0 h neg 0 h] 
        {w rip pop ris} {gis} {bis} true 3 colorimage
        bitmapsave restore 
        grestore
        } bind def
/BITMAPTRUECOLOR { 
        gsave
		
		3 index 2 div add exch	
		4 index 2 div add exch	
		translate		
		rotate			
		1 index 2 div neg	
		1 index 2 div neg	
		translate		
		scale			
		/h exch def /w exch def
        /bitmapsave save def 
        /is w string def
        /gis w string def
        /bis w string def
        /cf currentfile def 
        w h 8 [w 0 0 h neg 0 h] 
        { cf is readhexstring pop } 
        { cf gis readhexstring pop } 
        { cf bis readhexstring pop } 
        true 3 colorimage 
        bitmapsave restore 
        grestore
        } bind def
/BITMAPTRUEGRAYc { 
	/d 24 def
        gsave
	
	3 index 2 div add exch	
	4 index 2 div add exch	
	translate		
	rotate			
	1 index 2 div neg	
	1 index 2 div neg	
	translate		
	scale			
	/h exch def /w exch def
	/lb w d wbytes def 
	sl lb lt {lb ms} if 
        /bitmapsave save def 
        
	/is im 0 lb getinterval def	
	/ris im 0 w getinterval def	
	/gis im w w getinterval def	
	/bis im w 2 mul w getinterval def 
        ws 0 lb getinterval is copy pop 
        /cf currentfile def 
        w h 8 [w 0 0 h neg 0 h] 
        {w rip pop ris gis bis w gray} image
        bitmapsave restore 
        grestore
        } bind def
/ww FMLOCAL
/r FMLOCAL
/g FMLOCAL
/b FMLOCAL
/i FMLOCAL
/gray { 
        /ww exch def
        /b exch def
        /g exch def
        /r exch def
        0 1 ww 1 sub { /i exch def r i get .299 mul g i get .587 mul
			b i get .114 mul add add r i 3 -1 roll floor cvi put } for
        r
        } bind def
/BITMAPTRUEGRAY { 
        gsave
		
		3 index 2 div add exch	
		4 index 2 div add exch	
		translate		
		rotate			
		1 index 2 div neg	
		1 index 2 div neg	
		translate		
		scale			
		/h exch def /w exch def
        /bitmapsave save def 
        /is w string def
        /gis w string def
        /bis w string def
        /cf currentfile def 
        w h 8 [w 0 0 h neg 0 h] 
        { cf is readhexstring pop 
          cf gis readhexstring pop 
          cf bis readhexstring pop w gray}  image
        bitmapsave restore 
        grestore
        } bind def
/BITMAPGRAY { 
	8 {fakecolorsetup} COMMONBITMAP
	} bind def
/BITMAPGRAYc { 
	8 {fakecolorsetup} COMMONBITMAPc
	} bind def
/ENDBITMAP {
	} bind def
end 
	/ALDsave FMLOCAL
	/ALDmatrix matrix def ALDmatrix currentmatrix pop
/StartALD {
	/ALDsave save def
	 savematrix
	 ALDmatrix setmatrix
	} bind def
/InALD {
	 restorematrix
	} bind def
/DoneALD {
	 ALDsave restore
	} bind def
/I { setdash } bind def
/J { [] 0 setdash } bind def
%%EndProlog
%%BeginSetup
(4.0) FMVERSION
1 1 0 0 612 792 0 1 10 FMDOCUMENT
0 0 /Times-Roman FMFONTDEFINE
1 0 /Times-Italic FMFONTDEFINE
2 0 /Helvetica-Bold FMFONTDEFINE
3 0 /Helvetica FMFONTDEFINE
4 1 /Symbol FMFONTDEFINE
5 0 /Courier-BoldOblique FMFONTDEFINE
6 0 /Courier-Oblique FMFONTDEFINE
7 0 /Helvetica-Oblique FMFONTDEFINE
32 FMFILLS
0 0 FMFILL
1 0.1 FMFILL
2 0.3 FMFILL
3 0.5 FMFILL
4 0.7 FMFILL
5 0.9 FMFILL
6 0.97 FMFILL
7 1 FMFILL
8 <0f1e3c78f0e1c387> FMFILL
9 <0f87c3e1f0783c1e> FMFILL
10 <cccccccccccccccc> FMFILL
11 <ffff0000ffff0000> FMFILL
12 <8142241818244281> FMFILL
13 <03060c183060c081> FMFILL
14 <8040201008040201> FMFILL
16 1 FMFILL
17 0.9 FMFILL
18 0.7 FMFILL
19 0.5 FMFILL
20 0.3 FMFILL
21 0.1 FMFILL
22 0.03 FMFILL
23 0 FMFILL
24 <f0e1c3870f1e3c78> FMFILL
25 <f0783c1e0f87c3e1> FMFILL
26 <3333333333333333> FMFILL
27 <0000ffff0000ffff> FMFILL
28 <7ebddbe7e7dbbd7e> FMFILL
29 <fcf9f3e7cf9f3f7e> FMFILL
30 <7fbfdfeff7fbfdfe> FMFILL
%%EndSetup
%%Page: "1" 1
%%BeginPaperSize: Letter
%%EndPaperSize
612 792 1 FMBEGINPAGE
[0 0 0 1 0 0 0]
[ 0 1 1 0 1 0 0]
[ 1 0 1 0 0 1 0]
[ 1 1 0 0 0 0 1]
[ 1 0 0 0 0 1 1]
[ 0 1 0 0 1 0 1]
[ 0 0 1 0 1 1 0]
 7 FrameSetSepColors
FrameNoSep
0 0 0 1 0 0 0 K
J
0 0 0 1 0 0 0 K
0 9 Q
0 X
0 0 0 1 0 0 0 K
(Craig Chambers) 72 198 T
1 F
(et al.) 132.99 198 T
0 F
(1) 715.5 198 T
0 0 0 1 0 0 0 K
0 0 0 1 0 0 0 K
0 1 1 0 1 0 0 K
0 0 0 1 0 0 0 K
0 1 1 0 1 0 0 K
2 24 Q
0 1 1 0 1 0 0 K
(The Whirlwind Staged Compilation Architecture) 123.96 714 T
0 0 0 1 0 0 0 K
3 21 Q
0 0 0 1 0 0 0 K
(Craig Chambers, Susan Eggers,) 244.86 631 T
(Tapan Parikh, Jonathan Nowitz,) 247.18 600 T
(Matthai Philipose, Markus Mock, Brian Grant) 188.27 569 T
3 18 Q
(Department of Computer Science and Engineering) 194.41 492 T
(University of Washington) 296.47 464 T
0 0 0 1 0 0 0 K
FMENDPAGE
%%EndPage: "1" 1
%%Page: "2" 2
612 792 1 FMBEGINPAGE
[0 0 0 1 0 0 0]
[ 0 1 1 0 1 0 0]
[ 1 0 1 0 0 1 0]
[ 1 1 0 0 0 0 1]
[ 1 0 0 0 0 1 1]
[ 0 1 0 0 1 0 1]
[ 0 0 1 0 1 1 0]
 7 FrameSetSepColors
FrameNoSep
0 0 0 1 0 0 0 K
0 9 Q
0 X
0 0 0 1 0 0 0 K
(Craig Chambers) 72 198 T
(The Whirlwind Staged Compilation Architecture) 307.76 198 T
(2) 715.5 198 T
1 1 0 0 0 0 1 K
72 747 720 747 2 L
3 H
2 Z
1 1 0 0 0 0 1 K
N
72 208.72 720 208.72 2 L
N
0 0 0 1 0 0 0 K
0 0 0 1 0 0 0 K
1 1 0 0 0 0 1 K
2 24 Q
(Traditional Separate Compilation Model) 169.96 758 T
0 0 0 1 0 0 0 K
3 18 Q
0 0 0 1 0 0 0 K
(Perform most compilation & optimization work when compiling) 72 703 T
2 F
(individual files) 571.14 703 T
1 0 1 0 0 1 0 K
4 F
1 0 1 0 0 1 0 K
(+) 90 674 T
0 0 0 1 0 0 0 K
1 0 1 0 0 1 0 K
3 F
(amortize compilation work across all libraries & programs that include file) 108 674 T
0 0 0 1 0 0 0 K
1 0 1 0 0 1 0 K
4 F
(+) 90 646 T
0 0 0 1 0 0 0 K
1 0 1 0 0 1 0 K
3 F
(easy recompilation after program changes) 108 646 T
0 0 0 1 0 0 0 K
0 1 1 0 1 0 0 K
4 F
0 1 1 0 1 0 0 K
(-) 90 618 T
0 0 0 1 0 0 0 K
0 1 1 0 1 0 0 K
3 F
(limited scope for optimizations) 108 618 T
0 0 0 1 0 0 0 K
0 0 0 1 0 0 0 K
(Run-time profile feedback can help, if supported) 72 589 T
72 216 720 774 C
94.5 306 697.5 553 C
0 0 0 1 0 0 0 K
0 0 0 1 0 0 0 K
1 0 0 0 0 1 1 K
563.93 544 563.93 391 2 L
4 H
2 Z
0 X
1 0 0 0 0 1 1 K
N
231.59 544 231.59 391 2 L
N
397.76 544 397.76 391 2 L
N
0 0 0 1 0 0 0 K
1 1 0 0 0 0 1 K
3 18 Q
1 1 0 0 0 0 1 K
(File) 134 511.94 T
(Library) 287.17 511.94 T
(Program) 446.34 511.94 T
(Execution) 607.5 500.97 T
(Compilation) 100.99 493.94 T
(Linking) 286.16 493.94 T
(Linking) 452.33 493.94 T
0 0 0 1 0 0 0 K
1 0 1 0 0 1 0 K
439.78 451.61 462.85 445 439.78 438.39 439.78 445 4 Y
1 0 1 0 0 1 0 K
V
330 445 439.78 445 2 L
N
592.45 451.61 615.52 445 592.45 438.39 592.45 445 4 Y
V
493.5 445 592.45 445 2 L
N
273.6 451.61 296.67 445 273.6 438.39 273.6 445 4 Y
V
166.5 445 273.6 445 2 L
N
0 0 0 1 0 0 0 K
112.5 409 184.5 481 R
4 X
0 0 0 1 0 0 0 K
V
3 H
0 X
N
5 30 Q
(cc) 130.5 440.51 T
296.67 427 332.67 463 R
7 X
V
1 H
0 X
N
6 18 Q
(ar) 303.87 440.88 T
462.85 427 498.85 463 R
7 X
V
0 X
N
(ld) 470.05 440.88 T
0 0 0 1 0 0 0 K
0 0 0 1 0 0 0 K
615.52 427 678.52 463 R
7 X
V
0 X
N
(ld.so) 620.02 440.88 T
0 0 0 1 0 0 0 K
0 1 0 0 1 0 1 K
J
148.75 391.01 148.5 409 158.25 393.87 153.5 392.44 4 Y
0 1 0 0 1 0 1 K
V
[1.989 5.967] 0.994 I
647.02 427 M
 643.5 397 643.5 397 634.5 389.5 D
 625.5 382 625.5 382 396 382 D
 166.5 382 166.5 382 157.5 389.5 D
 155.9 390.83 154.59 391.74 153.5 392.43 D
2 H
N
7 F
(profile feedback) 328.5 358.94 T
1 0 1 0 0 1 0 K
1 0 1 0 0 1 0 K
(compiled) 195.5 451.94 T
(code) 212 429.94 T
0 0 0 1 0 0 0 K
J
0 0 0 1 0 0 0 K
72 216 720 774 C
0 180 792 792 C
0 0 0 1 0 0 0 K
FMENDPAGE
%%EndPage: "2" 2
%%Page: "3" 3
612 792 1 FMBEGINPAGE
[0 0 0 1 0 0 0]
[ 0 1 1 0 1 0 0]
[ 1 0 1 0 0 1 0]
[ 1 1 0 0 0 0 1]
[ 1 0 0 0 0 1 1]
[ 0 1 0 0 1 0 1]
[ 0 0 1 0 1 1 0]
 7 FrameSetSepColors
FrameNoSep
0 0 0 1 0 0 0 K
0 9 Q
0 X
0 0 0 1 0 0 0 K
(Craig Chambers) 72 198 T
(The Whirlwind Staged Compilation Architecture) 307.76 198 T
(3) 715.5 198 T
1 1 0 0 0 0 1 K
72 747 720 747 2 L
3 H
2 Z
1 1 0 0 0 0 1 K
N
72 208.72 720 208.72 2 L
N
0 0 0 1 0 0 0 K
0 0 0 1 0 0 0 K
1 1 0 0 0 0 1 K
2 24 Q
(Whole-Program Compilation Model) 195.98 758 T
0 0 0 1 0 0 0 K
3 18 Q
0 0 0 1 0 0 0 K
(Perform most compilation & optimization work when compiling) 72 703 T
2 F
(whole program) 571.14 703 T
1 0 1 0 0 1 0 K
4 F
1 0 1 0 0 1 0 K
(+) 90 674 T
0 0 0 1 0 0 0 K
1 0 1 0 0 1 0 K
3 F
(much better program context for optimization) 108 674 T
0 0 0 1 0 0 0 K
0 0 0 1 0 0 0 K
(\245) 126 647 T
(interprocedural analyses) 144 647 T
(\245) 126 621 T
(whole-program analyses) 144 621 T
1 0 1 0 0 1 0 K
0 0 0 1 0 0 0 K
0 1 1 0 1 0 0 K
4 F
0 1 1 0 1 0 0 K
(-) 90 594 T
0 0 0 1 0 0 0 K
0 1 1 0 1 0 0 K
3 F
(cannot amortize compilation time across programs) 108 594 T
0 0 0 1 0 0 0 K
0 1 1 0 1 0 0 K
4 F
(-) 90 566 T
0 0 0 1 0 0 0 K
0 1 1 0 1 0 0 K
3 F
(incremental recompilation hard \050although possible\051) 108 566 T
0 0 0 1 0 0 0 K
0 1 1 0 1 0 0 K
4 F
(-) 90 538 T
0 0 0 1 0 0 0 K
0 1 1 0 1 0 0 K
3 F
(shared precompiled libraries harder) 108 538 T
0 0 0 1 0 0 0 K
0 0 0 1 0 0 0 K
(Ex: UW\325s Vortex compiler for OOLs, some Fortran compilers,) 72 274 T
(some research C++, Java, ML, Scheme compilers) 99 251 T
72 216 720 774 C
94.5 298 697.5 503 C
0 0 0 1 0 0 0 K
0 0 0 1 0 0 0 K
1 0 0 0 0 1 1 K
563.93 494 563.93 350 2 L
4 H
2 Z
0 X
1 0 0 0 0 1 1 K
N
231.59 494 231.59 350 2 L
N
397.76 494 397.76 350 2 L
N
0 0 0 1 0 0 0 K
1 1 0 0 0 0 1 K
3 18 Q
1 1 0 0 0 0 1 K
(File) 134 461.94 T
(Library) 287.17 461.94 T
(Program) 446.34 461.94 T
(Execution) 607.5 450.97 T
(Compilation) 100.99 443.94 T
(Linking) 286.16 443.94 T
(Linking) 452.33 443.94 T
0 0 0 1 0 0 0 K
1 0 1 0 0 1 0 K
592.45 401.61 615.52 395 592.45 388.39 592.45 395 4 Y
1 0 1 0 0 1 0 K
V
493.5 395 592.45 395 2 L
N
0 0 0 1 0 0 0 K
615.52 377 678.52 413 R
7 X
0 0 0 1 0 0 0 K
V
1 H
0 X
N
6 F
(ld.so) 620.02 390.88 T
0 0 0 1 0 0 0 K
0 1 0 0 1 0 1 K
7 F
0 1 0 0 1 0 1 K
(profile feedback) 498.44 317.94 T
1 0 1 0 0 1 0 K
1 0 1 0 0 1 0 K
(compiled) 524.48 401.94 T
(code) 540.98 379.94 T
0 0 0 1 0 0 0 K
J
0 0 0 1 0 0 0 K
444.85 359 516.85 431 R
4 X
0 0 0 1 0 0 0 K
V
3 H
0 X
N
5 30 Q
(ld) 462.85 390.51 T
0 0 0 1 0 0 0 K
0 1 0 0 1 0 1 K
J
480.6 344.65 481.49 359 488.34 346.36 484.47 345.51 4 Y
0 1 0 0 1 0 1 K
V
[2.005 6.014] 1.002 I
647.02 377 M
 645.85 359 645.85 350 642.86 345.5 D
 639.87 341 639.87 341 563.67 341 D
 487.48 341 487.48 341 484.49 345.5 D
 484.49 345.5 484.49 345.5 484.49 345.5 D
2 H
N
0 0 0 1 0 0 0 K
J
72 216 720 774 C
0 180 792 792 C
0 0 0 1 0 0 0 K
FMENDPAGE
%%EndPage: "3" 3
%%Page: "4" 4
612 792 1 FMBEGINPAGE
[0 0 0 1 0 0 0]
[ 0 1 1 0 1 0 0]
[ 1 0 1 0 0 1 0]
[ 1 1 0 0 0 0 1]
[ 1 0 0 0 0 1 1]
[ 0 1 0 0 1 0 1]
[ 0 0 1 0 1 1 0]
 7 FrameSetSepColors
FrameNoSep
0 0 0 1 0 0 0 K
0 9 Q
0 X
0 0 0 1 0 0 0 K
(Craig Chambers) 72 198 T
(The Whirlwind Staged Compilation Architecture) 307.76 198 T
(4) 715.5 198 T
1 1 0 0 0 0 1 K
72 747 720 747 2 L
3 H
2 Z
1 1 0 0 0 0 1 K
N
72 208.72 720 208.72 2 L
N
0 0 0 1 0 0 0 K
0 0 0 1 0 0 0 K
1 1 0 0 0 0 1 K
2 24 Q
(Run-time Compilation Model) 233.33 758 T
0 0 0 1 0 0 0 K
3 18 Q
0 0 0 1 0 0 0 K
(Perform most compilation & optimization work by compiling) 72 703 T
2 F
(at run time) 547.13 703 T
1 0 1 0 0 1 0 K
4 F
1 0 1 0 0 1 0 K
(+) 90 674 T
0 0 0 1 0 0 0 K
1 0 1 0 0 1 0 K
3 F
(as much program context as whole program compiler) 108 674 T
0 0 0 1 0 0 0 K
1 0 1 0 0 1 0 K
4 F
(+) 90 646 T
0 0 0 1 0 0 0 K
1 0 1 0 0 1 0 K
3 F
(can exploit run-time values, classes, etc. too) 108 646 T
0 0 0 1 0 0 0 K
1 0 1 0 0 1 0 K
4 F
(+) 90 618 T
0 0 0 1 0 0 0 K
1 0 1 0 0 1 0 K
3 F
(dynamic on-line profile feedback is easy) 108 618 T
0 0 0 1 0 0 0 K
1 0 1 0 0 1 0 K
4 F
(+) 90 590 T
0 0 0 1 0 0 0 K
1 0 1 0 0 1 0 K
3 F
(can handle dynamic program changes \050e.g. class loading\051) 108 590 T
0 0 0 1 0 0 0 K
0 1 1 0 1 0 0 K
4 F
0 1 1 0 1 0 0 K
(-) 90 562 T
0 0 0 1 0 0 0 K
0 1 1 0 1 0 0 K
3 F
(cannot amortize compilation time even across) 108 562 T
7 F
(executions) 478.13 562 T
3 F
( of programs) 564.17 562 T
0 0 0 1 0 0 0 K
0 1 1 0 1 0 0 K
4 F
(-) 90 534 T
0 0 0 1 0 0 0 K
0 1 1 0 1 0 0 K
3 F
(harsh constraints on compilation time incurred) 108 534 T
0 0 0 1 0 0 0 K
0 0 0 1 0 0 0 K
(Ex: Java \322just in time\323 compilers, earlier research compilers) 72 270 T
72 216 720 774 C
94.5 294 697.5 499 C
0 0 0 1 0 0 0 K
0 0 0 1 0 0 0 K
1 0 1 0 0 1 0 K
603.35 415.86 580.33 422.46 603.35 429.06 603.35 422.46 4 Y
0 X
1 0 1 0 0 1 0 K
V
580.33 386.89 M
 678.36 386.89 678.36 386.89 678.36 404.68 D
 678.36 420.94 678.36 422.33 603.41 422.45 D
4 H
2 Z
N
1 0 0 0 0 1 1 K
454.5 490 454.5 346 2 L
1 0 0 0 0 1 1 K
N
207.17 490 207.17 346 2 L
N
330.83 490 330.83 346 2 L
N
0 0 0 1 0 0 0 K
1 1 0 0 0 0 1 K
3 18 Q
1 1 0 0 0 0 1 K
(File) 130.85 457.94 T
(Library) 241.5 457.94 T
(Program) 358.16 457.94 T
(Execution) 535.5 446.97 T
(Compilation) 97.83 439.94 T
(Linking) 240.49 439.94 T
(Linking) 364.15 439.94 T
0 0 0 1 0 0 0 K
0 1 0 0 1 0 1 K
7 F
0 1 0 0 1 0 1 K
(profile feedback) 469.81 313.94 T
1 0 1 0 0 1 0 K
1 0 1 0 0 1 0 K
(compiled) 587.05 392.74 T
(code) 603.55 370.74 T
0 0 0 1 0 0 0 K
J
0 0 0 1 0 0 0 K
481.5 355 580.5 427 R
4 X
0 0 0 1 0 0 0 K
V
3 H
0 X
N
5 30 Q
(ld.so) 486 386.51 T
0 0 0 1 0 0 0 K
0 1 0 0 1 0 1 K
J
495.92 339.43 494.45 353.93 503.38 342.42 499.65 340.92 4 Y
0 1 0 0 1 0 1 K
V
J
563.85 353.93 562.12 340.92 499.66 340.92 499.66 340.92 4 L
J
563.85 353.93 563.72 352.94 2 L
2 H
N
[1.59 4.769] 1.59 I
563.72 352.94 562.25 341.91 2 L
N
J
562.25 341.91 562.12 340.92 561.12 340.92 3 L
N
[1.95 5.851] 1.95 I
561.12 340.92 500.66 340.92 2 L
N
J
500.66 340.92 499.66 340.92 499.66 340.92 3 L
N
0 0 0 1 0 0 0 K
J
72 216 720 774 C
0 180 792 792 C
0 0 0 1 0 0 0 K
FMENDPAGE
%%EndPage: "4" 4
%%Page: "5" 5
612 792 1 FMBEGINPAGE
[0 0 0 1 0 0 0]
[ 0 1 1 0 1 0 0]
[ 1 0 1 0 0 1 0]
[ 1 1 0 0 0 0 1]
[ 1 0 0 0 0 1 1]
[ 0 1 0 0 1 0 1]
[ 0 0 1 0 1 1 0]
 7 FrameSetSepColors
FrameNoSep
0 0 0 1 0 0 0 K
0 9 Q
0 X
0 0 0 1 0 0 0 K
(Craig Chambers) 72 198 T
(The Whirlwind Staged Compilation Architecture) 307.76 198 T
(5) 715.5 198 T
1 1 0 0 0 0 1 K
72 747 720 747 2 L
3 H
2 Z
1 1 0 0 0 0 1 K
N
72 208.72 720 208.72 2 L
N
0 0 0 1 0 0 0 K
0 0 0 1 0 0 0 K
1 1 0 0 0 0 1 K
2 24 Q
(Whirlwind: A Staged Compilation Model) 168.65 758 T
0 0 0 1 0 0 0 K
3 18 Q
0 0 0 1 0 0 0 K
(Perform compilation & optimization work) 72 703 T
2 F
(at any stage) 398.09 703 T
1 0 1 0 0 1 0 K
4 F
1 0 1 0 0 1 0 K
(+) 90 674 T
0 0 0 1 0 0 0 K
1 0 1 0 0 1 0 K
3 F
(perform some work early to amortize costs, shared compiled results) 108 674 T
0 0 0 1 0 0 0 K
1 0 1 0 0 1 0 K
4 F
(+) 90 646 T
0 0 0 1 0 0 0 K
1 0 1 0 0 1 0 K
3 F
(perform some work late to gain best optimization context) 108 646 T
0 0 0 1 0 0 0 K
1 0 1 0 0 1 0 K
4 F
(+) 90 618 T
0 0 0 1 0 0 0 K
1 0 1 0 0 1 0 K
3 F
(spread some optimizations across multiple stages to get both) 108 618 T
0 0 0 1 0 0 0 K
0 0 0 1 0 0 0 K
(Each stage produces) 72 589 T
1 0 1 0 0 1 0 K
1 0 1 0 0 1 0 K
(partially compiled code) 246.1 589 T
0 0 0 1 0 0 0 K
0 0 0 1 0 0 0 K
( for later stages to complete) 429.16 589 T
(Each stage consumes) 72 559 T
0 1 0 0 1 0 1 K
0 1 0 0 1 0 1 K
(profile & other context info) 254.09 559 T
0 0 0 1 0 0 0 K
0 0 0 1 0 0 0 K
( from later stages) 463.19 559 T
(Subsumes previous compilation models) 72 252 T
72 216 720 774 C
76.22 276 715.78 523 C
0 0 0 1 0 0 0 K
0 0 0 1 0 0 0 K
1 0 1 0 0 1 0 K
702.84 425.19 680.18 433 703.53 438.38 703.18 431.79 4 Y
0 X
1 0 1 0 0 1 0 K
V
680.2 415 M
 706.22 415 706.22 415 706.22 424 D
 706.22 428.38 706.22 430.62 703.22 431.78 D
4 H
2 Z
N
1 0 0 0 0 1 1 K
536.65 514 536.65 361 2 L
1 0 0 0 0 1 1 K
N
213.3 514 213.3 361 2 L
N
379.48 514 379.48 361 2 L
N
0 0 0 1 0 0 0 K
1 1 0 0 0 0 1 K
3 18 Q
1 1 0 0 0 0 1 K
(File) 115.72 481.94 T
(Library) 268.89 481.94 T
(Program) 428.06 481.94 T
(Execution) 589.22 470.97 T
(Compilation) 82.71 463.94 T
(Linking) 267.88 463.94 T
(Linking) 434.05 463.94 T
0 0 0 1 0 0 0 K
1 0 1 0 0 1 0 K
412.49 421.61 435.57 415 412.49 408.39 412.49 415 4 Y
1 0 1 0 0 1 0 K
V
323.39 415 412.49 415 2 L
N
557.15 421.61 580.22 415 557.15 408.39 557.15 415 4 Y
V
489.57 415 557.15 415 2 L
N
246.32 421.61 269.39 415 246.32 408.39 246.32 415 4 Y
V
157.22 415 246.32 415 2 L
N
0 0 0 1 0 0 0 K
103.22 388 157.22 442 R
4 X
0 0 0 1 0 0 0 K
V
3 H
0 X
N
5 30 Q
(cc) 112.22 410.07 T
0 0 0 1 0 0 0 K
0 1 0 0 1 0 1 K
7 18 Q
0 1 0 0 1 0 1 K
(profile and other context feedback) 243.9 319.94 T
1 0 1 0 0 1 0 K
1 0 1 0 0 1 0 K
(compiled) 177.3 420.91 T
(code) 193.79 400.94 T
0 0 0 1 0 0 0 K
J
269.39 388 323.39 442 R
4 X
0 0 0 1 0 0 0 K
V
0 X
N
5 30 Q
(ar) 278.39 410.07 T
0 0 0 1 0 0 0 K
0 0 0 1 0 0 0 K
435.57 388 489.57 442 R
4 X
V
0 X
N
(ld) 444.56 410.07 T
0 0 0 1 0 0 0 K
0 0 0 1 0 0 0 K
579.24 388 678.24 442 R
4 X
V
0 X
N
(ld.so) 583.74 410.07 T
0 0 0 1 0 0 0 K
0 1 0 0 1 0 1 K
J
467.39 370.64 472.16 388 477.31 370.75 472.35 370.7 4 Y
0 1 0 0 1 0 1 K
V
[2.021 6.064] 1.011 I
616.22 388 M
 616.19 343 616.19 343 544.12 343 D
 482.83 343 473.67 343 472.36 370.69 D
2 H
N
J
298.57 370.64 303.33 388 308.49 370.76 303.53 370.7 4 Y
V
[2.004 6.012] 1.002 I
454.22 388 M
 454.18 343 454.18 343 378.7 343 D
 314.5 343 304.91 343 303.54 370.69 D
N
J
125.47 370.64 130.22 388 135.4 370.77 130.43 370.7 4 Y
V
[1.986 5.958] 0.993 I
287.72 388 M
 287.68 343 287.68 343 208.89 343 D
 141.88 343 131.87 343 130.44 370.69 D
N
J
568.21 343.01 207.97 343.01 2 L
J
568.21 343.01 567.21 343.01 2 L
N
[2.001 6.004] 2.001 I
567.21 343.01 208.98 343.01 2 L
N
J
208.98 343.01 207.97 343.01 2 L
N
J
646.98 370.72 652.01 388 656.91 370.68 651.94 370.7 4 Y
V
[2.028 6.084] 1.014 I
616.2 388 M
 616.21 343 616.21 343 634.13 343 D
 649.37 343 651.65 343 651.97 370.69 D
N
1 0 1 0 0 1 0 K
7 18 Q
1 0 1 0 0 1 0 K
(\050partly\051) 185.31 440.88 T
0 0 0 1 0 0 0 K
J
1 0 1 0 0 1 0 K
(compiled) 343.47 420.91 T
(code) 359.97 400.94 T
(\050partly\051) 351.48 440.88 T
0 0 0 1 0 0 0 K
J
1 0 1 0 0 1 0 K
(compiled) 500.64 420.91 T
(code) 517.14 400.94 T
(\050partly\051) 508.65 440.88 T
0 0 0 1 0 0 0 K
J
0 0 0 1 0 0 0 K
72 216 720 774 C
0 180 792 792 C
0 0 0 1 0 0 0 K
FMENDPAGE
%%EndPage: "5" 5
%%Page: "6" 6
612 792 1 FMBEGINPAGE
[0 0 0 1 0 0 0]
[ 0 1 1 0 1 0 0]
[ 1 0 1 0 0 1 0]
[ 1 1 0 0 0 0 1]
[ 1 0 0 0 0 1 1]
[ 0 1 0 0 1 0 1]
[ 0 0 1 0 1 1 0]
 7 FrameSetSepColors
FrameNoSep
0 0 0 1 0 0 0 K
0 9 Q
0 X
0 0 0 1 0 0 0 K
(Craig Chambers) 72 198 T
(The Whirlwind Staged Compilation Architecture) 307.76 198 T
(6) 715.5 198 T
1 1 0 0 0 0 1 K
72 747 720 747 2 L
3 H
2 Z
1 1 0 0 0 0 1 K
N
72 208.72 720 208.72 2 L
N
0 0 0 1 0 0 0 K
0 0 0 1 0 0 0 K
1 1 0 0 0 0 1 K
2 24 Q
(Staged Optimizations) 273.31 758 T
0 0 0 1 0 0 0 K
3 18 Q
0 0 0 1 0 0 0 K
(A) 72 703 T
2 F
(staged optimization) 89.01 703 T
3 F
(performs some planning work) 99 680 T
2 F
(early) 340.07 680 T
3 F
(, and) 382.1 680 T
(extends/completes the optimization) 99 657 T
2 F
(later) 385.13 657 T
3 F
( when additional info available) 423.14 657 T
(Get best of both worlds:) 72 597 T
1 0 1 0 0 1 0 K
4 F
1 0 1 0 0 1 0 K
(+) 90 568 T
0 0 0 1 0 0 0 K
1 0 1 0 0 1 0 K
3 F
(get benefits as if optimizations run in later stage with more optimization) 108 568 T
0 0 0 1 0 0 0 K
1 0 1 0 0 1 0 K
(opportunities) 126 546 T
0 0 0 1 0 0 0 K
1 0 1 0 0 1 0 K
4 F
(+) 90 518 T
0 0 0 1 0 0 0 K
1 0 1 0 0 1 0 K
3 F
(have lower cost by preplanning work in earlier stages) 108 518 T
0 0 0 1 0 0 0 K
0 0 0 1 0 0 0 K
(Generalizes interprocedural summaries,) 72 459 T
(hierarchical/modular interprocedural analysis) 99 436 T
0 0 0 1 0 0 0 K
FMENDPAGE
%%EndPage: "6" 6
%%Page: "7" 7
612 792 1 FMBEGINPAGE
[0 0 0 1 0 0 0]
[ 0 1 1 0 1 0 0]
[ 1 0 1 0 0 1 0]
[ 1 1 0 0 0 0 1]
[ 1 0 0 0 0 1 1]
[ 0 1 0 0 1 0 1]
[ 0 0 1 0 1 1 0]
 7 FrameSetSepColors
FrameNoSep
0 0 0 1 0 0 0 K
0 9 Q
0 X
0 0 0 1 0 0 0 K
(Craig Chambers) 72 198 T
(The Whirlwind Staged Compilation Architecture) 307.76 198 T
(7) 715.5 198 T
1 1 0 0 0 0 1 K
72 747 720 747 2 L
3 H
2 Z
1 1 0 0 0 0 1 K
N
72 208.72 720 208.72 2 L
N
0 0 0 1 0 0 0 K
0 0 0 1 0 0 0 K
1 1 0 0 0 0 1 K
2 24 Q
(Example: Staged Constant Propagation) 170.63 758 T
0 0 0 1 0 0 0 K
3 18 Q
0 0 0 1 0 0 0 K
(Intraprocedural constant propagation reveals some constants to optimize) 72 703 T
(\245) 90 674 T
(optimize them early) 108 674 T
4 F
(\336) 269.05 674 T
3 F
( no cost to later stages) 286.81 674 T
(Interprocedural constant propagation finds additional constants,) 72 615 T
(e.g. procedure formals and results) 99 592 T
(\245) 90 563 T
(optimize them when found, to get additional benefits) 108 563 T
(Intraprocedural stage can plan for what happens if they\325re found) 72 534 T
(\245) 90 505 T
(enables later stages to focus on productive work, be \050much\051 faster) 108 505 T
(Whole-program constant propagation finds more constants, e.g. globals) 72 446 T
(Run-time constant propagation finds still more constants) 72 386 T
(\245) 90 357 T
(earlier stages can produce) 108 357 T
2 F
(specialized run-time constant propagator) 325.1 357 T
3 F
(that is lightning-quick [see UW\325s DyC staged run-time compiler]) 126 335 T
(\245) 90 307 T
(preplanning can enable aggressive run-time optimizations, unlike JITs) 108 307 T
0 0 0 1 0 0 0 K
FMENDPAGE
%%EndPage: "7" 7
%%Page: "8" 8
612 792 1 FMBEGINPAGE
[0 0 0 1 0 0 0]
[ 0 1 1 0 1 0 0]
[ 1 0 1 0 0 1 0]
[ 1 1 0 0 0 0 1]
[ 1 0 0 0 0 1 1]
[ 0 1 0 0 1 0 1]
[ 0 0 1 0 1 1 0]
 7 FrameSetSepColors
FrameNoSep
0 0 0 1 0 0 0 K
0 9 Q
0 X
0 0 0 1 0 0 0 K
(Craig Chambers) 72 198 T
(The Whirlwind Staged Compilation Architecture) 307.76 198 T
(8) 715.5 198 T
1 1 0 0 0 0 1 K
72 747 720 747 2 L
3 H
2 Z
1 1 0 0 0 0 1 K
N
72 208.72 720 208.72 2 L
N
0 0 0 1 0 0 0 K
0 0 0 1 0 0 0 K
1 1 0 0 0 0 1 K
2 24 Q
(Context Information) 282 758 T
0 0 0 1 0 0 0 K
3 18 Q
0 0 0 1 0 0 0 K
(Earlier stages can exploit) 72 703 T
2 F
(run-time profile information) 278.08 703 T
3 F
(from run-time stage) 99 680 T
(E.g.) 72 650 T
(\245) 90 621 T
(what are program hot-spots?) 108 621 T
(\245) 90 593 T
(what are most common values/classes of variables?) 108 593 T
-0.8 (Earlier stages can exploit) 72 534 P
2 F
-0.8 (static interprocedural) 274.9 534 P
3 F
-0.8 ( or) 458.15 534 P
2 F
-0.8 (whole-program information) 482.57 534 P
3 F
(from later stages) 99 511 T
(E.g.) 72 481 T
(\245) 90 452 T
(what procedures can call this one? with what argument values? with what) 108 452 T
(aliasing patterns?) 126 430 T
(\245) 90 402 T
(what are the possible subclasses of this class?) 108 402 T
(what methods do they override?) 126 380 T
(Early stage can treat context information as a) 72 291 T
2 F
(hint) 438.17 291 T
3 F
( \050inserting run-time checks\051) 471.17 291 T
(or as a) 99 268 T
2 F
(guarantee) 159.03 268 T
3 F
( \050requiring recompilation if it changes\051) 245.05 268 T
0 0 0 1 0 0 0 K
FMENDPAGE
%%EndPage: "8" 8
%%Page: "9" 9
612 792 1 FMBEGINPAGE
[0 0 0 1 0 0 0]
[ 0 1 1 0 1 0 0]
[ 1 0 1 0 0 1 0]
[ 1 1 0 0 0 0 1]
[ 1 0 0 0 0 1 1]
[ 0 1 0 0 1 0 1]
[ 0 0 1 0 1 1 0]
 7 FrameSetSepColors
FrameNoSep
0 0 0 1 0 0 0 K
0 9 Q
0 X
0 0 0 1 0 0 0 K
(Craig Chambers) 72 198 T
(The Whirlwind Staged Compilation Architecture) 307.76 198 T
(9) 715.5 198 T
1 1 0 0 0 0 1 K
72 747 720 747 2 L
3 H
2 Z
1 1 0 0 0 0 1 K
N
72 208.72 720 208.72 2 L
N
0 0 0 1 0 0 0 K
0 0 0 1 0 0 0 K
1 1 0 0 0 0 1 K
2 24 Q
(Optimization Candidates) 255.31 758 T
0 0 0 1 0 0 0 K
3 18 Q
0 0 0 1 0 0 0 K
(Staged versions of traditional) 72 703 T
2 F
(intraprocedural) 309.11 703 T
3 F
( optimizations) 441.14 703 T
(\245) 90 674 T
(constant propagation) 108 674 T
(\245) 90 646 T
(copy/zero propagation) 108 646 T
(\245) 90 618 T
(dead code elimination) 108 618 T
(Staged versions of) 72 559 T
2 F
(interprocedural) 226.08 559 T
3 F
( optimizations) 358.11 559 T
(\245) 90 530 T
(constant propagation) 108 530 T
(\245) 90 502 T
(inlining) 108 502 T
(Staged versions of) 72 443 T
2 F
(object-oriented) 226.08 443 T
3 F
( optimizations) 356.09 443 T
(\245) 90 414 T
(class analysis \050at intraprocedural, interprocedural, and whole-program level\051) 108 414 T
(Dynamic profile/static context feedback for all these) 72 325 T
0 0 0 1 0 0 0 K
FMENDPAGE
%%EndPage: "9" 9
%%Page: "10" 10
612 792 1 FMBEGINPAGE
[0 0 0 1 0 0 0]
[ 0 1 1 0 1 0 0]
[ 1 0 1 0 0 1 0]
[ 1 1 0 0 0 0 1]
[ 1 0 0 0 0 1 1]
[ 0 1 0 0 1 0 1]
[ 0 0 1 0 1 1 0]
 7 FrameSetSepColors
FrameNoSep
0 0 0 1 0 0 0 K
0 9 Q
0 X
0 0 0 1 0 0 0 K
(Craig Chambers) 72 198 T
(The Whirlwind Staged Compilation Architecture) 307.76 198 T
(10) 711 198 T
1 1 0 0 0 0 1 K
72 747 720 747 2 L
3 H
2 Z
1 1 0 0 0 0 1 K
N
72 208.72 720 208.72 2 L
N
0 0 0 1 0 0 0 K
0 0 0 1 0 0 0 K
1 1 0 0 0 0 1 K
2 24 Q
(Project Status) 315.31 758 T
0 0 0 1 0 0 0 K
3 18 Q
0 0 0 1 0 0 0 K
(Building Whirlwind from Vortex) 72 703 T
(\245) 90 674 T
(adapt existing front-ends for C, C++, Java, Smalltalk, Cecil) 108 674 T
(\245) 90 646 T
-0.29 (based on general intermediate language supporting data layout optimizations) 108 646 P
([see Parikh poster]) 126 624 T
(\245) 90 596 T
(includes aggressive OO, interprocedural optimizations) 108 596 T
(Future research directions:) 72 537 T
(\245) 90 508 T
(developing staged versions of) 108 508 T
2 F
(more optimizations) 351.13 508 T
3 F
(\245) 90 480 T
2 F
(mechanizing) 108 480 T
3 F
( production of) 217.03 480 T
2 F
(staged optimizers) 331.09 480 T
3 F
(, given staging decisions) 484.13 480 T
(\245) 90 452 T
2 F
(mechanizing) 108 452 T
3 F
( production of) 217.03 452 T
2 F
(specialized compiler stages) 331.09 452 T
3 F
(,) 569.2 452 T
(given configuration of which optimizations in which stages) 126 430 T
(\245) 90 402 T
2 F
(automating) 108 402 T
3 F
( staging decisions) 205 402 T
(\245) 90 374 T
(investigating) 108 374 T
2 F
(architectural interactions) 213.05 374 T
3 F
(, e.g. with SMT, multiprocessors) 428.11 374 T
(\245) 90 346 T
(investigating applicability to wide range of) 108 346 T
2 F
(workloads) 444.15 346 T
3 F
(, e.g.) 533.18 346 T
(object-oriented programs, parallel programs, interpreters, simulators,) 126 324 T
(graphics programs) 126 302 T
0 0 0 1 0 0 0 K
FMENDPAGE
%%EndPage: "10" 10
%%Trailer
%%BoundingBox: 0 0 612 792
%%PageOrder: Ascend
%%Pages: 10
%%DocumentFonts: Times-Roman
%%+ Times-Italic
%%+ Helvetica-Bold
%%+ Helvetica
%%+ Symbol
%%+ Courier-BoldOblique
%%+ Courier-Oblique
%%+ Helvetica-Oblique
%%EOF

To: eggers@cs
cc: spin-comp@cs
Subject: intro comments
Date: Wed, 17 Feb 1999 11:56:37 PST
From: Brian Grant <grant@thistle.cs.washington.edu>

Here is the list of things I tried to fix in my intro for the paper.
Most need to be (re)incorporated into the old intro.

Intro:

	- pronunciation of DyC
	- specify "medium-sized programs"
	- distinction between mechanisms and solutions (i.e., that
	  our annotations really aren't an interface for average programmers,
	  but an interface to a future automatic DC tool)
	- make sure the paper's contribution is clear, but without the footnote
	- always call our run-time loop unrolling "complete loop unrolling"
	- emphasize that complete loop unrolling is an enabling optimization
	- emphasize that some optimizations only benefited applications, and
	  not kernels
	- more emphasis on staged zcprop and dce in third bullet
	- delete fourth bullet: "Safe dynamic compilation policies..."
	- add a bullet about low overhead
	- clarify or axe "certain combinations of language features"
	- clarify division vs. specialization here or in optimizations section
	- "varies" -> "vary"
	- add hyphen to "partial evaluation-style"
	- "mechanical transformations" -> "analysis and transformations"
	- define our brand of dynamic compilation before just jumping into it
	- at least say we optimize on the basis of program (run-time) values
	- mention staging

Abstract:
	- I think the size issue is dicey.  Certainly, we shouldn't say
	  "two orders of magnitude".

--Brian

Date: Wed, 17 Feb 1999 13:46:34 -0800
From: eggers@yakima (Susan Eggers)
To: eggers@cs, grant@cs.washington.edu
Subject: Re: intro comments
Cc: spin-comp@cs


Everything on this list was either there already or I added it.
In some way, shape or form.

Susan

Date: Wed, 17 Feb 1999 14:49:41 -0800
From: eggers@yakima (Susan Eggers)
To: spin-comp@cs
Subject: backup

Which one of you is going to stand in as Brian if he can't be
here tomorrow?  

And Markus, did you order an extra page?

Susnan

Date: Wed, 17 Feb 1999 14:56:05 -0800 (PST)
From: Markus Mock <mock@cs.washington.edu>
To: Susan Eggers <eggers@yakima>
cc: spin-comp@cs
Subject: Re: backup

I will stand in as a backup. 

As for the page:

No, I haven't requested one yet. Talking with Brian we were thinking that
we don't actually need one. I can request an extra page, if we need one,
however, the request has to be substantiated by an explanation what the
extra page will be used for.  What do you think needs an extra page?

	-- Markus




Date: Wed, 17 Feb 1999 15:04:05 -0800
From: eggers@yakima (Susan Eggers)
To: eggers@yakima, mock@cs.washington.edu
Subject: Re: backup
Cc: spin-comp@cs

The extra page was needed to incorporate all the reviewers comments,
and let's hold off a sec to see if we really need it.  I just
wanted to know who was the point man.

Susan

To: eggers@cs
cc: spin-comp@cs
Subject: number of annotations
Date: Wed, 17 Feb 1999 16:28:27 PST
From: Brian Grant <grant@thistle.cs.washington.edu>

Here is a breakdown of what types of annotations are used in the
benchmarks.  I have both the actual number of annotations
used and, arguably, how many should be used if we fixed some minor
problems with our system (e.g., how dead variables are treated).
Some reductions might even work with the current implementation,
since many bugs have been fixed since the kernels were originally
annotated.

The number of annotations isn't bad, except for @s on loads, which
most people would probably consider unreasonable.

actual# (ideal#)

Blank means zero.

		make_static	make_dynamic	load@	call@
dinero		1				48	0*
mipsi		2				1	1
pnmconvol	3(2)		3(2)		8	
m88ksim		2(1)		1		5	
viewperf
  project&clip	1				15	
  shader	5(3)		5(3)		23	1

binary		2(1)				2	
chebyshev	3(1)					2
dotproduct	2(1)				1	
query		2(1)				8(3)**	
romberg		4(1)		1(0)			

*  8 static calls were inserted for the strength reduction hack.
** A simple source-code change would eliminate the need for 5 of
   the annotations.

--Brian

Date: Wed, 17 Feb 1999 17:48:12 -0800
From: eggers@yakima (Susan Eggers)
To: spin-comp@cs
Subject: footnotes

Craig just noticed this.  A possible time sink.
Can one of you figure out how to generate the
[1] footnote
format that Brian says is required for PLDI?

Thanks,
Susan

Date: Wed, 17 Feb 1999 18:46:05 -0800 (PST)
From: chambers@klamath (Craig Chambers)
To: spin-comp@cs, eggers@yakima
Subject: Re: footnotes


> From eggers@yakima  Wed Feb 17 17:48:16 1999
> Delivery-Date: Wed, 17 Feb 1999 17:48:17 PST
> Date: Wed, 17 Feb 1999 17:48:12 -0800
> From: eggers@yakima (Susan Eggers)
> To: spin-comp@cs
> Subject: footnotes
> 
> Craig just noticed this.  A possible time sink.
> Can one of you figure out how to generate the
> [1] footnote
> format that Brian says is required for PLDI?
> 
> Thanks,
> Susan
> 

Susan means references.

-- Craig

And I don't think we need to adhere so strictly to their format.  I never
did before.

To: spin-comp@cs
Subject: Re: footnotes 
Date: Wed, 17 Feb 1999 22:49:44 PST
From: Brian Grant <grant@thistle.cs.washington.edu>

Craig wrote:
>> Susan means references.
>> 
>> And I don't think we need to adhere so strictly to their format.  I never
>> did before.

That's good, because I noticed that the format of the section headers
has been changed from what was specified by the format.

If we want to use the simpler reference style, it should just be a
matter of setting an environment varible for BibFrame.  The manual is
on my desk.  I can check it in the morning.

--Brian

Date: Thu, 18 Feb 1999 19:15:44 -0800 (PST)
From: chambers@klamath (Craig Chambers)
To: spin-comp@cs
Subject: paper lock

FYI, I have the lock on the paper.  I hope to do all my editing tonight,
and have a semi-final version available when you get in tomorrow.
(Except maybe for the example, which Matthai should be working on.)

-- Craig

Date: Fri, 19 Feb 1999 00:13:26 -0800 (PST)
From: chambers@klamath (Craig Chambers)
To: spin-comp@cs
Subject: paper

I've finished editing the paper.  See ~chambers/papers/pldi/99/final.doc.
I haven't looked at Brian's recent emailed suggestions yet, but a quick
skim suggests I've already done some of them.  I didn't touch the example
section; I'm assuming Matthai has a draft.

I'd like to move the example after the discussion of our opts (to the end of
section 2).

I'd like to drop the static & dynamic whole-program execution times, just
keeping the other columns.

I changed the input column of table 1; see what you think.

I added a paragraph on JITs.

I'm releasing the write lock, but if anyone edits anything, I'd like to
know what they did.  (I tried to make our paper grammatically correct by
inserting/removing commas, e.g., and I don't want that work undone, for
instance.)

-- Craig

To: chambers@klamath (Craig Chambers)
cc: spin-comp@cs
Subject: Re: paper 
Date: Fri, 19 Feb 1999 07:08:53 PST
From: Brian Grant <grant@thistle.cs.washington.edu>

>> I've finished editing the paper.  See ~chambers/papers/pldi/99/final.doc.

Why was contact information removed from the title area?  Not even a
footnote is left with this info.

Also, what title have we agreed on?  I noticed that "Staged" has been
reintroduced.

>> I'm releasing the write lock, but if anyone edits anything, I'd like to
>> know what they did.  (I tried to make our paper grammatically correct by
>> inserting/removing commas, e.g., and I don't want that work undone, for
>> instance.)

I'm claiming the lock for a little while, though I currently don't have
any specific plans to change anything until I've read the latest version.
Let me know if you want the lock.

>> I'd like to move the example after the discussion of our opts (to the end of
>> section 2).

Seems fine.

>> I'd like to drop the static & dynamic whole-program execution times, just
>> keeping the other columns.

Any particular reason?  Do you think it is not useful information?

--Brian




Date: Fri, 19 Feb 1999 07:54:12 -0800
From: eggers@yakima (Susan Eggers)
To: chambers@klamath, grant@thistle.cs.washington.edu
Subject: Re: paper
Cc: spin-comp@cs


I'm wondering about removing the execution times as well.  It
provides useful context information, and I don't see what taking
it out buys us.  

BTW I'll be preparing and giving class until 11:30 and will check
back in then.

Susan

To: spin-comp@cs
Subject: changes
Date: Fri, 19 Feb 1999 08:29:35 PST
From: Brian Grant <grant@thistle.cs.washington.edu>

I haven't finished reading the paper, but I'm giving up the lock
since I have some other things to do.  I put the latest version in
/projects/dyncomp/Papers/PLDI99/after-craig.fm

The list of minor edits I made is at the bottom of this message.


Question: why were so many of my formatting changes undone?  Do we
for some reason intentionally want to diverge from the format ACM
proposed?  I can understand not putting section numbers on the
abstract and not doing things that are a pain, but I spent a few
hours changing the format to conform to the template as much as
possible.  (Of course, that doesn't compare to the several days
I spent making other changes that were removed without discussion...)


Since I apparently have no power to make significant changes, I'll
just make more suggestions:

1) I still think we should mention automation in the intro.  Focusing
on programmers as the users of annotations seems to annoy some people,
and I also think it is unrealistic.

2) The referees and Dave's group found the footnote about division vs.
specialization confusing.  At that point in the paper, we haven't even
defined static vs. dynamic.  The description should be moved to section
2 and clarified somehow, perhaps by saying how they are implemented.
Roughly:
Polyvariant division requires keeping track of multiple sets of
binding times in the analysis and then a different version is created
for each set at static compile time.  Polyvariant specialization
causes multiple versions to be instantiated at run time for the
different run-time values.

3) Repeating an earlier comment to Craig:
The current "system overview" does not discuss our optimizations in common
terminology (such as "constant propagation") and does not mention the new
staged optimizations.  It also does not mention policies, which I mentioned
there because I removed the later discussion of them.  The description
of caching in the last paragraph is inaccurate (at least since the
optimizations I implemented over a year ago) and makes our system sound
even less efficient than it actually is.  The lookup happens before the
dynamic compiler is invoked.

4) I think we should put in the number of interpreted operations for
mipsi in table 3, and I think the amounts the dynamic regions were
executed in our whole-program times should be added to table 4:

dinero		1 invocation (1000000 memory references)
m88ksim		35817894 breakpoint checks
mipsi		1 invocation (114062852 operations interpreted)
pnmconvol	1 invocation (786432 pixels)
viewperf	1170 transformations

Skimming over the paper, it looked like many of my previous suggestions
are still outstanding/overruled/ignored.  The next time Craig or Susan gets
a lock on the paper, I would like to talk to you about some of them.


**********************************************************
Changes I made:

I globally changed "zero/copy" and "copy and zero" to "zero and copy"
or "zero&copy".  I used the latter only in the tables and in one subsection
title.

re-use to reuse (according to webster)

In the first bulletted paragraph of 2.1, "other annotated or derived" to
"annotated or other derived".

Hyphenation comment: I'm pretty sure English is right associative (at least,
according to my grammar book).

"at run-time" to "at run time" and "at dynamic compile-time" to "at
dynamic compile time"   

"dynamic region boundaries" to "dynamic-region boundaries"

Put a space between "Viewperf" and "benchmarks"

--Brian


To: spin-comp@cs
Subject: FYI: I've decided to leave at 11:45am today
Date: Fri, 19 Feb 1999 08:48:05 PST
From: Brian Grant <grant@thistle.cs.washington.edu>



To: spin-comp@franklin.cs.washington.edu
Subject: taking over paper lock
Date: Fri, 19 Feb 1999 09:47:09 PST
From: Matthai Philipose <matthai@franklin.cs.washington.edu>

I'm grabbing the after-craig.fm that Brian produced so I can munge 
the example a bit.

I agree strongly with Craig (and, as I remember it, Brian's original 
version) that the example should go after the section that describes 
our run-time optimizations. 

Right now, I will just clean up the example further; the re-ordering 
can be done later, I guess.
			Matthai

Date: Fri, 19 Feb 1999 10:45:14 -0800 (PST)
From: chambers@klamath (Craig Chambers)
To: spin-comp@cs
Subject: here

I'm in my office now, if people want to talk about things before they leave.
I'm going to send some email now explaining the changes I made and those that
I'd like to make.

-- Craig

Date: Fri, 19 Feb 1999 10:55:33 -0800 (PST)
From: chambers@klamath (Craig Chambers)
To: spin-comp@cs
Subject: paper lock

I have the lock on the paper, other than the example section that Matthai is
working on.

-- Craig

Date: Fri, 19 Feb 1999 11:11:00 -0800 (PST)
From: chambers@klamath (Craig Chambers)
To: spin-comp@cs
Subject: Re: changes

> Why was contact information removed from the title area?  Not even a
> footnote is left with this info.

I've never included all that stuff in the final paper before (just the
submission).  I looked over several papers in last year's PLDI, and
many included it, so I'm happy to put it back in if people want.

> 
> Also, what title have we agreed on?  I noticed that "Staged" has been
> reintroduced.

I talked to Susan about reintroducing it, because I wanted to distinguish our
approach from JITs.  I was nervous before about it (in the absence of "in DyC")
because it seemed to promise a more general study of staging than we've done.

> >> I'd like to drop the static & dynamic whole-program execution times, just
> >> keeping the other columns.
> 
> Any particular reason?  Do you think it is not useful information?

Because the numbers in the table don't match the computed ratios, I assume
due to round-off errors.  For the potential confusion, I thought it didn't
add significant value.

> Question: why were so many of my formatting changes undone?  Do we
> for some reason intentionally want to diverge from the format ACM
> proposed?  I can understand not putting section numbers on the
> abstract and not doing things that are a pain, but I spent a few
> hours changing the format to conform to the template as much as
> possible.  (Of course, that doesn't compare to the several days
> I spent making other changes that were removed without discussion...)

Because the format was so ugly, and I can't remember any other paper in PLDI
that had that attrocious format.  I'm sorry you spent a lot of time getting
in that format, but I think having a good-looking paper is more important
than following the given format.  (I doubt that the latex style uses the
same ugly format, for instance.)  (But it's true that I don't know for sure.)

> 1) I still think we should mention automation in the intro.  Focusing
> on programmers as the users of annotations seems to annoy some people,
> and I also think it is unrealistic.

I'm not sure exactly where it could be fit in smoothly.  Perhaps at the end of
the DyC intro paragraph.  Automation is quite beyond the scope of this work,
though, and might seem an empty promise.

> 
> 2) The referees and Dave's group found the footnote about division vs.
> specialization confusing.  At that point in the paper, we haven't even
> defined static vs. dynamic.  The description should be moved to section
> 2 and clarified somehow, perhaps by saying how they are implemented.
> Roughly:
> Polyvariant division requires keeping track of multiple sets of
> binding times in the analysis and then a different version is created
> for each set at static compile time.  Polyvariant specialization
> causes multiple versions to be instantiated at run time for the
> different run-time values.

You're right.  This is awkward.  Do you have a proposal for what to do to
the intro paragraph in place of these terms?

> 
> 3) Repeating an earlier comment to Craig:
> The current "system overview" does not discuss our optimizations in common
> terminology (such as "constant propagation") and does not mention the new
> staged optimizations.

It does mention staged constant propagation.  But as an overview, it can't
get into details of everything.  It's supposed to give people a quick intro.
They get the details in the later subsection.

> It also does not mention policies, which I mentioned
> there because I removed the later discussion of them.

There is discussion later on about caching policies.  This seems the 
appropriate place to me.  The overview is too early to get into that kind of
detail, since the reader may not understand how the system works yet, and so
can't appreciate what kinds of controls the user might want.  We also 
mention policies in the intro (in the same place we assert a bunch of other
things that the reader probably doesn't understand yet).

> The description
> of caching in the last paragraph is inaccurate (at least since the
> optimizations I implemented over a year ago) and makes our system sound
> even less efficient than it actually is.  The lookup happens before the
> dynamic compiler is invoked.

I can't see that this actually makes a difference.  I think you're reading
"invoke the d.c." too literally.  Since the d.c. is customized, it's all just
compiled code, some inline, some not inline.  "Invoke the d.c." is just an
abstract notion about starting to do work relating to d.c., the first step
of which is a cache lookup.  (Similarly, the cache lookup is a conceptual thing,
with physical implementations that may be real lookups or something much more
optimized, e.g. the cache-one-unchecked "lookup".)

> Skimming over the paper, it looked like many of my previous suggestions
> are still outstanding/overruled/ignored.  The next time Craig or Susan gets
> a lock on the paper, I would like to talk to you about some of them.

I said in an earlier email that I haven't had a chance to go over your 
suggestions in detail.  I did read over your comments and studied your notes
on the intro pretty carefully when I did my mark-up pass.  I have all your
comments printed out and now that I've gone through the paper with my edits
I plan to go back through looking at your suggestions one at a time.  Of course,
I may not want to follow your suggestions, just as the suggestions above I
didn't always want to follow or thought I'd followed in a somewhat different
way than you suggest.

Please come by to talk more about this.

> 
> 
> **********************************************************
> Changes I made:

(I wish you had cleared change bars before making your changes, so I could
find them more easily.)

> 
> I globally changed "zero/copy" and "copy and zero" to "zero and copy"
> or "zero&copy".  I used the latter only in the tables and in one subsection
> title.

Seems fine to me.

> 
> re-use to reuse (according to webster)

Fine.

> 
> In the first bulletted paragraph of 2.1, "other annotated or derived" to
> "annotated or other derived".

Good.

> 
> Hyphenation comment: I'm pretty sure English is right associative (at least,
> according to my grammar book).
> 
> "at run-time" to "at run time" and "at dynamic compile-time" to "at
> dynamic compile time"   
> 
> "dynamic region boundaries" to "dynamic-region boundaries"

Fine.

> 
> Put a space between "Viewperf" and "benchmarks"

Fine.

-- Craig

Date: Fri, 19 Feb 1999 12:14:03 -0800 (PST)
From: chambers@klamath (Craig Chambers)
To: spin-comp@cs
Subject: breakeven for mipsi

Do we know or can guess how many instructions need to be executed for mipsi
before it breaks even?  This would be better than "1 execution" and in line
w/ how dinero and pnmconvol are reported.

-- Craig

To: chambers@klamath (Craig Chambers)
cc: spin-comp@franklin.cs.washington.edu
Subject: Re: breakeven for mipsi 
Date: Fri, 19 Feb 1999 12:57:38 PST
From: Matthai Philipose <matthai@franklin.cs.washington.edu>

According to Brian's slide, we have to simulate 485k mips 
instructions before we break even.

From what I understood, the number is this high mainly because there 
are a bunch of instructions we produce that are not 
interpreted/executed more than once. This is because we end up 
specializing the whole interpreted program and not the heavily used 
parts of the interpreted program.

		Matthai


> Do we know or can guess how many instructions need to be executed for mipsi
> before it breaks even?  This would be better than "1 execution" and in line
> w/ how dinero and pnmconvol are reported.
> 
> -- Craig
> 




Date: Fri, 19 Feb 1999 13:23:35 -0800 (PST)
From: chambers@klamath (Craig Chambers)
To: spin-comp@cs
Subject: paper

I'm done with all my editing and doing all the references.  As far as I'm
concerned, all that's left is to incorporate Matthai's thinner example (and
move it to the end of section 2).  And have you all read what I've written.

See ~chambers/papers/pldi/99/final2.doc.

I'm off to class now.

-- Craig

To: chambers@klamath (Craig Chambers)
cc: spin-comp@franklin.cs.washington.edu
Subject: Re: paper 
Date: Fri, 19 Feb 1999 14:16:48 PST
From: Matthai Philipose <matthai@franklin.cs.washington.edu>

The latest version of the example is in /projects/dyncomp/Papers/PLDI9
9/after-craig.fm

Section 2.2, figure 2, figure 3 and figure 4 need to be copied over 
to the final version of the paper.
		Matthai

Date: Fri, 19 Feb 1999 14:22:26 -0800
From: eggers@yakima (Susan Eggers)
To: chambers@klamath, matthai@cs.washington.edu
Subject: Re: paper
Cc: spin-comp@franklin.cs.washington.edu

I'm back from affiliates.
I'll take a look for Craig's copy, incorporate your figures
and make a pass.  This means I have the lock.

Susan

Date: Fri, 19 Feb 1999 14:26:04 -0800
From: eggers@yakima (Susan Eggers)
To: chambers@klamath, matthai@cs.washington.edu
Subject: Re: paper
Cc: spin-comp@franklin.cs.washington.edu


This is what Brian had before.
in the table:
	1 invocation
	(484634 operations interpreted)
and in the text:
A meaningful break-even point for mipsi is more difficult to calculate,
because it depends on the number of reinterpreted instructions
(i.e., the number and size of the loops in mipsiÕs input program)
relative to the total size of the input program. For this input program,
each of the 1637 operations specialized needed to be executed at least
an average of 296 times to break even. (footnote)

the footnote:
When using other input programs that performed more indirect jumps or calls, the dispatch cost could also impact mipsiÕs performance.

Date: Fri, 19 Feb 1999 14:36:43 -0800 (PST)
From: chambers@klamath (Craig Chambers)
To: spin-comp@cs
Subject: copyright form

FYI, I have the copyright form in my office, from Brian.

-- Craig

Date: Fri, 19 Feb 1999 14:40:10 -0800 (PST)
From: chambers@klamath (Craig Chambers)
To: spin-comp@cs
Subject: paper

I'm grabbing back the write lock.

-- Craig

Date: Fri, 19 Feb 1999 14:44:07 -0800
From: eggers@yakima (Susan Eggers)
To: spin-comp@cs, chambers@klamath
Subject: Re: paper

Just to be redundant, I assume you have the lock for the example,
and I have it for the rest of the paper.

Susan

Date: Fri, 19 Feb 1999 16:45:52 -0800 (PST)
From: chambers@klamath (Craig Chambers)
To: spin-comp@cs
Subject: paper done!

The final version of the paper is in ~chambers/papers/pldi/99/final.{doc,ps}.

Yahoo!

-- Craig

Date: Mon, 22 Feb 1999 09:05:41 -0800
From: eggers@yakima (Susan Eggers)
To: support@cs
Subject: frame version 5 on the suns
Cc: spin-comp@cs, levy@cs, eggers@yakima, sparekh@cs, redstone@yakima

I need access to fminit/langdir in order to enable the spell
checker.  I have an fminit directory, but no langir in it.
And I find no langdir when I look for frame directories.

Can someone tell me where this directory is so that I can
link to it, assuming that is the correct fix?

Thanks,
Susan

To: spin-comp@franklin.cs.washington.edu
Subject: PLDI paper added to our page 
Date: Tue, 23 Feb 1999 15:47:20 PST
From: Matthai Philipose <matthai@franklin.cs.washington.edu>

FYI, I've added the PLDI99 paper to our project home page, in case 
people ask for a pointer to it.

Our project homepage is:
	http://www.cs.washington.edu/research/projects/unisw/DynComp/www/
		Matthai


Date: Thu, 25 Feb 1999 14:21:11 -0800
From: eggers@yakima (Susan Eggers)
To: spin-comp@cs
Subject: undergraduates working with us

I've been asked to give one of the presentations about research
opportunities to the undergraduates.  But I'm slightly hardpressed
to think of what an undergraduate could do.  Markus and Matthai --
are you free to meet briefly to talk about this after the colloq?
You two might have a better handle on what would help you out than
Craig and I.

Susan

To: spin-comp@cs
Subject: ref. info for pldi paper
Date: Sun, 28 Feb 1999 17:28:09 PST
From: Brian Grant <grant@thistle.cs.washington.edu>

FYI, our paper starts at page 293 in the proceedings.

--Brian

Date: Mon, 1 Mar 1999 13:19:24 -0800 (PST)
From: chambers@klamath (Craig Chambers)
To: spin-comp@cs, cecil@cs
Subject: FW: 03/02/99 Cache-Conscious Data Organization and Layout; Trishu

Trishul Chilimbi is giving a talk at MSR tomorrow morning @ 10am.  I'll 
probably be driving over, leaving my house around 9:30.  Do any of you want
to come and catch a ride with me?

-- Craig


-----Original Message-----
From: MS Research Lecture Room (Private) [mailto:cf312055@microsoft.com]

Sent: Monday, March 01, 1999 11:12 AM
To: 'Richard Ladner'
Subject: FW: 03/02/99 Cache-Conscious Data Organization and Layout;
Trishu al Chilimbi - University of Wisconsin-Madison




>  -----Original Appointment-----
> From: 	MS Research Lecture Room (Private)  
> Sent:	Tuesday, February 23, 1999 12:39 PM
> To:	MS Research Lecture Room (Private); Microsoft Research Tech
Talk,
> Sem. Notice; Tanya Kneeland
> Subject:	03/02/99 Cache-Conscious Data Organization and Layout;
> Trishual Chilimbi - University of Wisconsin-Madison
> When:	Tuesday, March 02, 1999 10:30 AM-12:00 PM (GMT-08:00) Pacific
Time
> (US & Canada); Tijuana.
> Where:	31/2053 Research Lecture Room 
> 
> You are invited to attend... please pass onto internal MS employees
that
> may be interested.
>
************************************************************************
**
> ******************************
> WHO:				Trishual Chilimbi 
> AFFILIATION:		University of Wisconsin-Madison
> TITLE:				Cache-Conscious Data
Organization
> and Layout
> WHEN:				Tue 3/2/99
> WHERE:			31/2053 Research Lecture Room 
> TIME:				10:30 AM-12:00PM
> HOST:				Todd Knoblock
> NETSHOW:			To Be Determined
>
************************************************************************
**
> *******************************
> ABSTRACT:
> In this talk I will show that cache-conscious pointer structure layout
can
> improve the performance of real programs by up to 30--40%.  I will
outline
> a wide variety of techniques for laying out pointer structures in
> languages such as C, C++, and Java. These include completely automatic
> techniques that require no programmer assistance or source code
> modification. 
> I will discuss one such technique-cache-conscious reorganization using
> copying garbage collection that co-locates objects with high temporal
> affinity in the same cache block-in detail. Measurements show that
this
> technique reduces cache miss rates by 21--42%, and improves program
> performance by 14--37% over a conventional copying algorithm (Cheney).
In
> addition it outperforms an algorithm (Wilson-Lam-Moher) designed to
> improve locality at the page level by 18--31%, indicating that
improving
> locality at the page level is not necessarily beneficial at the cache
> level. 
> Finally, for structures comparable in size to a cache block, structure
> splitting can increase the number of hot fields that can be placed in
a
> cache block. In five Java programs, structure splitting reduced cache
miss
> rates 10--27% and improved performance 6--18% beyond the benefits of
> cache-conscious reorganization.
> BIO:
> Trishul Chilimbi is a graduate student in the Computer Science
Department
> at the University of Wisconsin-Madison, working with Profs.  James
Larus
> and Mark Hill. He expects to complete his Ph.D. by June of 1999. His
areas
> of interest are programming languages, compilers, computer
architecture,
> and parallel and distributed systems. Currently, his specific research
> interests include memory system design and optimization, memory
> management, co-operative (hardware/software) performance optimization,
and
> dynamic feedback-driven compilation. His educational background
includes a
> B.Tech. from the Indian Institute of Technology, Bombay (1992), and a
M.S.
> from the University of Wisconsin at Madison (1993).
> 
> 
> 


----- End Included Message -----


Date: Tue, 2 Mar 1999 13:33:31 -0800 (PST)
From: Markus Mock <mock@cs.washington.edu>
To: spin-comp@cs.washington.edu
Subject: automation write-up

I've written up a summary of the model for automation and some of the
accomplishments in addressing the sub-problems in ~mock/tmp/automation.ps

It would be good if you could have a look at it before the meeting. I'll
also try to present the main ideas in the meeting.


	-- Markus


To: spin-comp@cs
Subject: pointer vs. structural invariance and invalidation
Date: Tue, 02 Mar 1999 16:25:57 PST
From: Brian Grant <grant@thistle.cs.washington.edu>

To account for different kinds of objects, you would want to allow
different actions at object-creation points, at object-modification points
(may and must), at object-deallocation points, and at the region entries.  

I thought of a few issues that could be considered wrt. invalidation
and dispatching:
1) What objects are used for specialization?  Only one object?
2) How are the objects modified?  Are they immutable?  Quasi-invariant?
3) Are different objects likely to be structurally equivalent?  If so, can
   this be tested efficiently, for example using fingerprinting or
   sampling techniques?

A few cases I've thought of:

1) mipsi's promotions at computed jumps.  The bytecode array is invariant,
and the same array is always used, but each jump can go to different positions
within it.

2) Invalidation with non-trivial dispatch at the entry:

Suppose you specialize a region for the contents of an array variable.
A number of different mutable but quasi-invariant arrays are used in the
region.  At the entry the system could dispatch on the pointer to the
array, rather than its contents.  A particular version of the specialized
code would be invalidated when its corresponding array were modified.

3) Would you ever want to test structural equivalence if a pointer-equivalence 
test failed but certain other run-time conditions held?

--Brian

Date: Tue, 2 Mar 1999 16:59:12 -0800 (PST)
From: chambers@klamath (Craig Chambers)
To: spin-comp@cs
Subject: Re: pointer vs. structural invariance and invalidation


----- Begin Included Message -----

From chambers Tue Mar  2 16:58:55 1999
To: grant@cs.washington.edu
Subject: Re: pointer vs. structural invariance and invalidation
X-Sun-Charset: US-ASCII

> To account for different kinds of objects, you would want to allow
> different actions at object-creation points, at object-modification points
> (may and must), at object-deallocation points, and at the region entries.  

I think you don't care about object-creation points (I assume this means the
place where the scalar is initially assigned or the data structure is allocated
and initialized); they have to happen before the initial region entry, and
before any other object-modification/-deallocation points.

I think you only care about object-deallocation points if you want to eagerly
flush entries from the cache of specializations.  With some LRU cache 
management scheme, this wouldn't be necessary.  But it might be worth writing
down as some kind of footnote to keep in mind if we ever care.

> I thought of a few issues that could be considered wrt. invalidation
> and dispatching:
> 1) What objects are used for specialization?  Only one object?

I'm not sure what you mean.  I'm assuming an object corresponds to a 
scalar variable or to some range of memory (e.g. all or part of some pointed-
to data structure).  A dynamic region would be specialized for the value of
some tuple of objects.

> 2) How are the objects modified?  Are they immutable?  Quasi-invariant?

This is captured by the invalidation cost for each of the different 
static points of possible invalidation.  Somehow (e.g. static analysis, maybe
profiling) each point is determined to possibly modify some set of objects; 
a singleton set is probably the same as definitely modifying one object.
An object which has no possible invalidation points is immutable.  An object
whose invalidation points are infrequently executed is quasi-invariant.
[Note: we'd like to have the static analysis limit the possible modification
points to those that can be executed after the first execution of the dynamic
region and before the last execution, e.g. by looking at the call graph.]

> 3) Are different objects likely to be structurally equivalent?  If so, can
>    this be tested efficiently, for example using fingerprinting or
>    sampling techniques?

Fingerprinting or other sampling (e.g. checksum) are only good for quickly
testing when things are different.  We need a quick test for when things 
are definitely the same.  I don't know of any way to do thus but scanning
bytes.  (Or moving to invalidation-based schemes.)

> 
> A few cases I've thought of:
> 
> 1) mipsi's promotions at computed jumps.  The bytecode array is invariant,
> and the same array is always used, but each jump can go to different positions
> within it.

Octal 40?  (Blank?)

I don't see what you're getting at here.

> 
> 2) Invalidation with non-trivial dispatch at the entry:
> 
> Suppose you specialize a region for the contents of an array variable.
> A number of different mutable but quasi-invariant arrays are used in the
> region.  At the entry the system could dispatch on the pointer to the
> array, rather than its contents.  A particular version of the specialized
> code would be invalidated when its corresponding array were modified.

Interesting.  Maybe this could be modeled as a polling-based scalar variable
(the pointer to the array) coupled with a set of invalidation-based variables
(the possible arrays that the pointer points to).

In general, there may be some index variables that can be tested quickly on
dynamic-region entry, whose values imply the values of larger backing data.
The pointer to the bytecode array for the function entry is one example of
this.  Maybe our current notion of objects (scalar or memory region) isn't
rich enough to adequately capture these kinds of dependencies.

> 
> 3) Would you ever want to test structural equivalence if a pointer-equivalence 
> test failed but certain other run-time conditions held?

Dunno.  Are you testing structural equivalence between the previous and the
current value of some memory object, e.g. at a cache lookup?  Certainly you
have to do the structural equivalence test in this case.  Are you thinking of
some other case?

> 
> --Brian
> 

-- Craig


----- End Included Message -----


To: chambers@klamath (Craig Chambers)
cc: spin-comp@franklin.cs.washington.edu
Subject: Re: pointer vs. structural invariance and invalidation 
Date: Tue, 02 Mar 1999 17:31:04 PST
From: Matthai Philipose <matthai@franklin.cs.washington.edu>

> fingerprints
I was also thinking fingerprinting might be a good way to identify 
invariant datastructures. This is not done while the user is finally 
running the program, but when you're doing value profiling.

Basically the fingerprint of a datastructure might be good way to 
represent it during value profiling. If you wanted to track the rate 
of change of a  datastructure, you could recompute fingerprints at 
regular intervals. This would give you a way, for e.g., to identify 
the bytecode array as a good candidate for specialization, even if it 
changed (infrequently).

On the other hand, maybe value profiling at each use of the 
datastructure's components is enough for capturing how relevant parts 
of the ds change.
 
---Craig said:
> We need a quick test for when things  are definitely the same.  I don't know of any way to do 
> thus but scanning bytes.

Actually (this is going to sound completely cracked, but I'll say it 
anyway), if the probablility that the fingerprint gives a false 
result (positive/negative) is sufficiently low, we can go ahead use 
fingerprinting for checking whether things are the same. Instead of 
saying our system is "definitely" correct, we just give a 
probabilistic guarantee about our system. As long as the probability 
of failure is much lower than that of the system without our code 
running on it, we're fine.

All this "definitely semantically equivalent" stuff is just a 
holdover from static compilation where you can compile for eons to 
preserve an illusory sense of security. :-)

Let the flames begin!

		Matthai



To: spin-comp@cs
Subject: Marlet et al. (Consel) PLDI paper now available on their web site
Date: Thu, 04 Mar 1999 09:42:10 PST
From: Brian Grant <grant@thistle.cs.washington.edu>

http://www.irisa.fr/compose/papers/incrpe.ps.gz

--Brian

Date: Thu, 4 Mar 1999 12:02:10 -0800 (PST)
From: chambers@klamath (Craig Chambers)
To: spin-comp@cs
Subject: cfp SAS'99 - Venice


----- Begin Included Message -----

From cortesi@dsi.unive.it  Thu Mar  4 11:04:51 1999
Delivery-Date: Thu, 04 Mar 1999 11:04:51 PST
Date: Thu, 4 Mar 1999 18:19:50 +0100 (MET)
From: Agostino Cortesi <cortesi@dsi.unive.it>
To: informatica@dsi.unive.it
Subject: cfp SAS'99 - Venice
MIME-Version: 1.0

*************************************************************************

                         Last Call For Papers

             International Static Analysis Symposium (SAS'99)

                           Venezia, Italy,
                        22--24 September 1999

                 Submission Deadline: 15 march, 1999

                    
       for info, please look at: http://www.dsi.unive.it/~sas99/

*************************************************************************



As usual, I deeply apologize for multiple copies....
_______________________________________________________________________
agostino cortesi, phd
dipartimento di informatica       tel: +39 041 290.8450
universita' ca' foscari, venezia  fax: +39 041 290.8419
via torino 155                    url: http://www.dsi.unive.it/~cortesi
30170 mestre-venezia (italy)      email: cortesi@dsi.unive.it




----- End Included Message -----


Date: Sat, 6 Mar 1999 08:13:08 -0800
From: eggers@yakima (Susan Eggers)
To: spin-comp@cs
Subject: from a conversation with a faculty candidate


----- Begin Included Message -----

From shiva@DB.Stanford.EDU Fri Mar  5 20:07:31 1999
To: eggers@cs.washington.edu, levy@cs.washington.edu, shiva@DB.Stanford.EDU
Subject: RE: improving databases
Content-Length: 3168
X-Lines: 57
Status: RO


Hello,

Susan's question
----------------
Re: the dynamic compilation stuff, I am not sure what impact it will have
in disk-based DB systems, since the I/O usually is the killer. However,
your compilation techniques that exploit specific constants may be useful 
in "Query Flock" systems that are gaining some interest in data mining
applications. Conceptually these are "flocks" of queries that have the same 
form, but have different parameters in each instantiation of the query. 
	http://www-db.stanford.edu/pub/papers/flocks.ps

Also there has been some recent work in "Query Scrambling" which is
similar to dynamic compliation in spirit, but uses information about
available resources at a "higher" level. That is, the optimizer generates
a bunch of plans and chooses the best one depending on conditions such
as how good the sampling information is, network bottlenecks, if underlying
sources have failed (this is similar to work that Alon is looking at in 
the context of Tiramisu). However, I am not sure if techniques such as
unfolding constants will lead to significant benefits in this domain. 
However, it is possible your declarative framework already captures what 
folks in this domain are doing in some procedural way? I am not sure...
	http://www.umiacs.umd.edu/research/CLIP/DARPA/projects.html


----- End Included Message -----


Date: Tue, 9 Mar 1999 08:08:05 -0800 (PST)
From: Markus Mock <mock@cs.washington.edu>
To: spin-comp@cs.washington.edu
Subject: meeting

I need to stay home today as both Patricia and Andrea are sick. I should
be able tio point you to an updated version of my write-up with modified
equations later today.

	-- Markus


To: spin-comp@cs
Subject: meeting agenda?
Date: Tue, 09 Mar 1999 09:19:40 PST
From: Brian Grant <grant@thistle.cs.washington.edu>

Ok, if Markus is out, what should be the meeting agenda?

--Brian

Date: Tue, 9 Mar 1999 09:33:36 -0800
From: eggers@yakima (Susan Eggers)
To: spin-comp@cs.washington.edu, mock@cs.washington.edu
Subject: Re: meeting

Given that Markus will not be here, and Craig is under time
pressure, do we need a meeting?  Does anyone else have something
the group should talk over?

Susan

Date: Tue, 9 Mar 1999 14:04:31 -0800
From: eggers@yakima (Susan Eggers)
To: levy@cs, eggers@yakima, sparekh@cs, redstone@yakima, spin-comp@cs,
Subject: meeting times next quarter

I'm being pressed to pin down my spring schedule.
Can you all confirm that our current meeting times
are ok for you next quarter?  Or suggest another.

Susan

Date: Wed, 10 Mar 1999 13:42:05 -0800 (PST)
From: chambers@klamath (Craig Chambers)
To: spin-comp@cs
Subject: Crary meetings?


----- Begin Included Message -----

From cecil-request@june  Wed Mar 10 13:40:53 1999
Delivery-Date: Wed, 10 Mar 1999 13:40:54 PST
Date: Wed, 10 Mar 1999 13:40:42 -0800 (PST)
From: chambers@klamath (Craig Chambers)
To: cecil@cs
Subject: Crary meetings?
X-Sun-Charset: US-ASCII

If any of you want to grab one of the last three slots with Crary, feel free.

I'll open up to the general public soon.

-- Craig


----- End Included Message -----


Date: Wed, 10 Mar 1999 13:42:48 -0800 (PST)
From: chambers@klamath (Craig Chambers)
To: cecil@cs, spin-comp@cs
Subject: re: Crary

P.S.  It's fine if pairs of you want to meet together for a half hour, too.

-- Craig

Date: Thu, 11 Mar 1999 10:38:22 -0800
From: eggers@yakima (Susan Eggers)
To: spin-comp@cs


----- Begin Included Message -----

From uli@takefive.rutgers.edu Thu Mar 11 07:40:34 1999
To: eggers@cs.washington.edu
Subject: PLDI99 student poster session
Cc: uli@cs.rutgers.edu
Content-Length: 2407
X-Lines: 56
Status: RO


Dear Prof. Eggers,

  Here is a brief reminder regarding the student poster session
  at this year's PLDI conference. The poster session will give
  students a chance to present their work to an academic and
  industrial audience. Please encourage your student(s) to submit 
  to this event. 

  Thanks,
    --Uli

  p.s.: It is fine if I get the submission by March 16

-------------------------------------------------------------------------
                             PLDI'99   
                       Student Poster Session 
                           May 2, 1999
-------------------------------------------------------------------------

    The ACM SIGPLAN 1999 Conference on Programming Language Design 
and Implementation (PLDI'99) will be held in Atlanta, Georgia, May 1-4, 
1999 as part of the Federated Computing Research Conference (FCRC'99).
Please see http://www.cs.rutgers.edu/pldi99 for details regarding
PLDI'99.

    A student poster session is planned for Sunday night, May 2, 1999 during 
the FCRC'99 Gather from 6:00-7:30pm. This one and a half hour evening event 
will feature concurrent short presentations by student participants organized 
in poster formats.  Each student will be allowed a 3' by 4' space on an
easel for the presentation.  FCRC'99 attendees, including non-students, will 
be able to wander among the posters and talk to the students about their 
research.  Refreshments will be provided.

    Students who wish to present a poster display of their research must
send the following information to Ulrich Kremer (uli@cs.rutgers.edu) 
by March 12, 1999:

     -  a title and 500 word abstract of their proposed presentation
     -  their email address, phone number and surface mail address
     -  their department and school
     -  a short email note of support of their participation from 
	their faculty research advisor 

    Selected participants will be notified by March 22, 1999. If there is more 
interest in this program than can be accommodated easily, each school will be 
asked to select its student presenter(s) on the basis of the size of their annual
Ph.D. class, with limited representation from each Computer Science department.

    Students participants may apply for travel support from ACM SIGPLAN PAC. 
Please see http://www.acm.org/sigplan/PAC for further information.  

    Best regards,
       Uli Kremer
       Poster Session Chair



----- End Included Message -----


Date: Fri, 12 Mar 1999 13:23:05 -0800
From: eggers@yakima (Susan Eggers)
To: spin-comp@cs
Subject: next week's meeting

Next Tuesday my entire day is filled with talking to prospective
students.  I assume it's similar for most of the rest of you.
Shall we cancel or reschedule?

Susan

Date: Mon, 15 Mar 1999 13:18:04 -0800
From: eggers@yakima (Susan Eggers)
To: spin-comp@cs
Subject: fyi


----- Begin Included Message -----

From rrh@tera.com Mon Mar 15 13:01:01 1999
To: eggers@cs.washington.edu
Subject: did yousee this?
Cc: pardo@cs.washington.edu
Content-Length: 5290
X-Lines: 114
Status: RO

  > From makholm@diku.dk Wed Feb 24 10:37 PST 1999
  > Received: from vidar.diku.dk (root@vidar.diku.dk [130.225.96.249])
  > 	by gershwin.tera.com (8.8.8/8.8.8) with ESMTP id KAA01463
  > 	for <rrh@tera.com>; Wed, 24 Feb 1999 10:37:46 -0800 (PST)
  > Received: from embla.diku.dk (makholm@embla.diku.dk [130.225.96.229])
  > 	by vidar.diku.dk (8.9.0/8.9.0) with ESMTP id TAA12206;
  > 	Wed, 24 Feb 1999 19:34:53 +0100 (MET)
  > Received: (from makholm@localhost)
  > 	by embla.diku.dk (8.9.0/8.9.0) id TAA00193;
  > 	Wed, 24 Feb 1999 19:34:52 +0100 (MET)
  > Date: Wed, 24 Feb 1999 19:34:52 +0100 (MET)
  > Message-Id: <199902241834.TAA00193@embla.diku.dk>
  > From: Henning Makholm <henning@makholm.net>
  > Subject: Announcing C-Mix 2.0
  > To: prog-lang@diku.dk, mjt-pe@cs.york.ac.uk, Aidan.Corey@St-Johns.Oxford.ac.uk,
  >         David.Baker@comlab.ox.ac.uk, Franz.Kriftner@source.at,
  >         Ronan.Gaugne@irisa.fr, alefrag@ee.upatras.gr.andretol@hotmail.com,
  >         arthur@vt.edu, bida@math.tau.ac.il, blazy@iie.cnam.fr,
  >         blecha@telecom.ksu.edu, chen+@cs.cmu.edu, chet@watson.ibm.com,
  >         cmo@cs.odu.edu, cwf@research.att.com, doh@han-7.hanyang.ac.kr,
  >         drror@math.tau.ac.il, facon@iie.cnam.fr, harrison@csrd.uiuc.edu,
  >         hugh@calcaphon.com, j.gallagher@abrltd.co.uk, jesper@carlstedt.se,
  >         jiglesia@cs.nmsu.edu, johnm@vlibs.com, lars.o.andersen@ac.com,
  >         lassen@diku.dk, ljocha@fi.muni.cz, manuvir@cs.wisc.edu,
  >         marlowe@cs.rutgers.edu, mjf@comlab.ox.ac.uk, mjy@pobox.com,
  >         nance@vt.edu, ob3@doc.ic.ac.uk, peter@makholm.net,
  >         P.H.Andersen@visionik.dk, pcgj@novo.dk, rasputin@why.net,
  >         rdc@mitre.org, reps@cs.wisc.edu, richardc@csd.uu.se, rrh@tera.com,
  >         ryder@cs.rutgers.edu, ryo@ori.hitachi-sk.co.jp, sagiv@cs.wisc.edu,
  >         snbrabec@cip.informatik.uni-erlangen.de,
  >         sperber@informatik.uni-tuebingen.de, todd@cs.arizona.edu,
  >         truve@carlstedt.se, ulfar@cs.cornell.edu, urs@cs.ucsb.edu,
  >         wang@agusa.nuie.nagoya-u.ac.jp, wilhelm@cs.uni-sb.de
  > Sender: makholm@diku.dk
  > Reply-to: cmix@diku.dk
  > Content-Type: text
  > Content-Length: 2758
  > Status: RO
  > 
  > Version 2.0 of C-Mix has been released
  > ======================================
  > 
  > C-Mix is an automatic partial evaluator for the C programming
  > language. It aims at being useful in a real-world setting and
  > being useable for people without deep knowledge about PE techniques.
  > 
  > C-Mix reads C source files and directly produces generating extensions
  > written in C++. The generating extension in turn produces C code for the
  > residual program.
  > 
  > Availability
  > ------------
  > 
  > C-Mix 2.0 is freely available as source and as binaries for a selected
  > range of platforms at
  >   http://www.diku.dk/research-groups/topps/activities/cmix/download
  > It is now also freely redistributable, so feel free to pass it on to
  > anyone you know who has a C program that could benefit from partial
  > evaluation.
  > 
  > Most of the system is written in C++. We expect it to compile straigt
  > out of the box on any unixish system with the GCC 2.8.x or Egcs
  > compilers. The DOS and Windows ports of Egcs are also supported.
  > 
  > Comparison with older C-Mixen
  > -----------------------------
  > 
  > With respect to the C-Mix that was presented at the PE'98 summer school:
  > 
  > * Can unfold functions while specializing.
  > 
  > * Can tell the user *why* something becomes dynamic.
  > 
  > * The annotated-program browser can show basic binding-time
  >   information in text mode without using a WWW browser.
  > 
  > * Numerous other bugs fixed.
  > 
  > With respect to pre-1998 versions of C-Mix:
  > 
  > * Simply, there is no comparison. 90% of the system has been completely
  >   redesigned and recoded at least once. Overall, the system has become
  >   much stabler.
  > 
  > * Accepts a much larger subset of ISO C, and does it correctly (so we
  >   think).
  > 
  > * The command line syntax has been redesigned to be more flexible and
  >   easier to incorporate as a single step in a larger build process.
  > 
  > * User-level annotations on the subject program can be done without
  >   changing the source files.
  > 
  > * A new annotation browser shows the annotated program as hypertext.
  >   Cause/effect chains in the binding-time analysis are easily inspected.
  > 
  > * Vastly improved support for specializing only parts of a program.
  >   A clean interface for linking to "external" code at specialization
  >   time as well as from the residual program has been added. Static
  >   input need not be passed through the generating extension's command
  >   line but can be supplied by a user-written main() routine.
  > 
  > * And probably other improvements which I forgot to mention here.
  > 
  > Why you get this announcement
  > -----------------------------
  > 
  > You receive this email either because you are subscribed to a relevant
  > mailing list or because we've previously communicated with you about
  > C-Mix.
  > 
  > If you want to get notified about future releases of C-Mix (bugfixes,
  > new features, etc.), please contact us at cmix@diku.dk.
  > 


----- End Included Message -----


Date: Tue, 16 Mar 1999 09:03:59 -0800
From: eggers@yakima (Susan Eggers)
To: mock@cs.washington.edu
Subject: Re: group meeting today?
Cc: spin-comp@cs

I assume we are doing prospectives.  Craig and I are, anyway.

Susan


----- Begin Included Message -----

From mock@cs.washington.edu Tue Mar 16 08:28:47 1999
Reply-To: Markus Mock <mock@cs.washington.edu>
To: Susan Eggers <eggers@cs.washington.edu>
Subject: group meeting today?
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Content-Length: 169
X-Lines: 8
Status: RO

Susan,

I didn't see a follow-up message last week to your inquiry about meeting
today. Is everyone booked because of prospectives or do we meet as usual?


	-- Markus



----- End Included Message -----


Date: Wed, 17 Mar 1999 20:47:55 -0800 (PST)
From: Markus Mock <mock@cs.washington.edu>
To: spin-comp@cs.washington.edu
Subject: PLDI 99 Online Registration

is now up at:
http://www.cs.rutgers.edu/pldi99/


	-- Markus


To: spin-comp@cs
Subject: IA-64 compiler job
Date: Thu, 18 Mar 1999 10:42:06 PST
From: Brian Grant <grant@thistle.cs.washington.edu>


------- Forwarded Message

Replied: Thu, 18 Mar 1999 10:35:29 PST
Replied: Allan Knies <aknies@mipos2.intel.com>
Received: from crotus.sc.intel.com (crotus.sc.intel.com [143.183.152.26]) by june.cs.washington.edu (8.8.7+CS/7.2ju) with ESMTP id NAA27998; Mon, 15 Mar 1999 13:08:20 -0800
Received: from mipos2.intel.com (mipos2.intel.com [143.183.48.42])
	by crotus.sc.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.6 1998/11/24 22:10:56 iwep Exp iwep $) with ESMTP id NAA11937;
	Mon, 15 Mar 1999 13:08:19 -0800 (PST)
Received: from mipos2 (aknies@zws315.sc.intel.com [143.183.43.125])
	by mipos2.intel.com (8.9.1a/8.9.1) with ESMTP id NAA11030;
	Mon, 15 Mar 1999 13:08:17 -0800 (PST)
Message-Id: <199903152108.NAA11030@mipos2.intel.com>
To: grant@cs.washington.edu, pvv@cs.washington.edu
cc: jpierce@mipos2.intel.com
Subject: FYI -- compiler opening
Date: Mon, 15 Mar 1999 13:08:15 -0800
From: Allan Knies <aknies@mipos2.intel.com>
X-UIDL: 58305197396beb20f50e28a9c813a780
Status: U


Brian/Peter,

If you (or someone you know), might be interested in this,
feel free to contact me or Jim.  Please forward/post to other
interested parties.

Allan

- ------- Forwarded Message

Replied: Mon, 15 Mar 1999 12:30:39 -0800
Replied: Jim Pierce <jpierce@mipos2.intel.com>
Received: from mipos2.intel.com (jpierce-desk.sc.intel.com [143.183.140.63])
	by mipos2.intel.com (8.9.1a/8.9.1) with ESMTP id LAA18845;
	Mon, 15 Mar 1999 11:44:05 -0800 (PST)
Message-ID: <36ED6303.341573F0@mipos2.intel.com>
Date: Mon, 15 Mar 1999 11:44:03 -0800
From: Jim Pierce <jpierce@mipos2.intel.com>
Organization: Intel Corp.
X-Mailer: Mozilla 4.5 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Knies, Allan" <aknies@mipos2.intel.com>,
        "Zahir, Rumi" <rumi.zahir@intel.com>,
        "Holm, John" <jholm@mipos2.intel.com>,
        "Kling, Ralph" <rkling@mipos2.intel.com>
Subject: Job description
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

When you visit schools this spring or run into someone interested in
compiler work, could you inform people of this job opening?

thanks,
jim



Job Opening:

                                       Code Generator Software Developer

                                        IA-64 Production Compiler Group
                                                  Intel Corp.

IA-64 is Intel's new 64-bit architecture.  Through features like
predication, speculation, software pipeline support, and a large
register file, the design emphasizes and demands a close relationship
with the compiler.  The code generator phase of the compiler is
responsible for the best use of the above listed features.  The compiler
is a key element to the success of the project.

We are looking to expand the code generator team of the IA-64 production
compiler group.  The small team is responsible for predication, cyclic
optimizations and scheduling, acyclic global scheduling, register
allocation, backend optimizations, and code emission.

The job responsibilities include code analysis, existing phase and
optimization tuning, in addition to new optimization design and
implementation.  Due to the newness of many of the architecture
features, there is a substantial amount of applied research involved.
The particular phase or optimization that the candidate will work on
will depend upon the candidate's expertise and the current needs of the
team.

We are looking for candidates with either industry experience in code
generation or recent college graduates who have done research in that
area.  We will also consider candidates with experience in other
compiler areas if they possess performance analysis experience or
architecture knowledge and an interest in learning code generation
design.

The perfect candidate would have the following qualifications:

  - Experience in some part of code generation development for an ILP
processor,
  - Experience in performance analysis to tune code generator or
optimization phases,
  - Computer architecture knowledge to better understand the complex
interaction between the   compiler and the hardware.

Candidates with only some of the qualification are still encouraged to
apply. The job location is Intel's site in Santa Clara, CA.

For more information, please contact Jim Pierce at 408-765-5350 or email
at jim.pierce@intel.com



- ------- End of Forwarded Message



------- End of Forwarded Message



To: spin-comp@cs
Subject: what can we sign up for?
Date: Thu, 18 Mar 1999 11:12:33 PST
From: Brian Grant <grant@thistle.cs.washington.edu>

Matthai and I are interested in whether we can sign up for any tutorials
at PLDI or for WCSSS.

WCSSS is $65.  Tutorials are $60.

--Brian

Date: Thu, 18 Mar 1999 12:48:39 -0800
From: eggers@yakima (Susan Eggers)
To: spin-comp@cs, grant@cs.washington.edu
Subject: Re: what can we sign up for?

Which tutorials were you interested in?

Susan

Date: Thu, 18 Mar 1999 17:26:04 -0800
From: eggers@yakima (Susan Eggers)
To: spin-comp@cs
Subject: next week's meetings

Let's give ourselves a break on the break, ok?
No meetings.

Susan

Date: Thu, 25 Mar 1999 17:45:37 -0800 (PST)
From: chambers@klamath (Craig Chambers)
To: cecil@cs, spin-comp@cs
Subject: I've arrived

After 5 days of 10-hour-a-day driving and 2975 miles, I've arrived in NY.
We've rented a house, which we move into Monday.  Monday I also start at
IBM, beginning with my drug test(!).

More once I have a real connection....

-- Craig

Date: Fri, 26 Mar 1999 15:37:45 -0800
From: eggers@yakima (Susan Eggers)
To: spin-comp@cs
Subject: PLDI travel money

I suggest we just divide it evenly among you three.
What usually happens is:
	you pay
	the grant pays you back
	PLDI pays the grant

Susan

Date: Sun, 28 Mar 1999 19:37:07 -0800 (PST)
From: chambers@klamath (Craig Chambers)
To: cecil@cs, lisas@cs, melody@cs, spin-comp@cs
Subject: new home address

FYI, my new home address (where you can mail my POPL reimbursement check, 
Lisa) and phone number (which won't be ready for a week or so) are:

218 Lakeview Ave.
West Harrison NY 10604
914-686-6876

I'll send my IBM work address and phone number when I get it, probably 
Monday.

-- Craig

Date: Mon, 29 Mar 1999 14:30:43 -0800 (PST)
From: chambers@klamath (Craig Chambers)
To: cecil@cs, lisas@klamath, melody@klamath, spin-comp@cs
Subject: IBM phone #

My office phone number at IBM is 914-784-7952.  I hope tomorrow to have
a US mailing address.

-- Craig

To: spin-comp@cs
Subject: changes to bin, mflow, regression committed
Date: Mon, 29 Mar 1999 17:31:26 PST
From: Brian Grant <grant@thistle.cs.washington.edu>

High bit:
This commit fixes significant bugs in mipsi and pnmconvol.  mipsi now
works with dinero as its input program (and all others I've tried).

Low bits:
The most significant change was a fix to a bug in the BTA that caused
it to crop annotated temps from the context.  The merge rule from the
paper was just plain wrong.  It rebuilt the StaticVarInfo set from the
Division, which basically didn't allow any derived temps to survive beyond
a merge.  Instead, it should kill monovariantly specialized static
variables with multiple reaching defs and non-annotated temps derived
from them.  For annotated temps, their roots and cache policies need to
be redefined if their roots are killed.  For polyvariantly specialized
variables, just their cache policies need to be changed, not their roots.
I also fixed ProcessDynAssigns to be consistent with the changes to the
merge rule (it had some of the same bugs).

This bug had caused the current PC in mipsi to be omitted from the context
in some units, which caused branches to be patched to the wrong locations
due to false code-cache hits in a certain obscure situation.  This took me
several days to track down.

--Brian

Date: Tue, 30 Mar 1999 12:10:09 -0800 (PST)
From: chambers@klamath (Craig Chambers)
To: cecil@cs, lisas@cs, lmn@sei.cmu.edu, melody@cs, spin-comp@cs
Subject: Mailing address


The mailing address for me at IBM is:

Craig Chambers
IBM T.J. Watson Research Center
30 Saw Mill River Road
Hawthorne NY  10532

That's for e.g. FedEx that requires a real address.  Normal mail would use
PO Box 704

My fax number here is 914-784-7105.

Correction: the US mail address, written out completely, is:

Craig Chambers
IBM T.J. Watson Research Center
PO Box 704
Yorktown Heights NY  10598


-- Craig

Date: Tue, 13 Apr 1999 09:11:51 -0700 (PDT)
From: Markus Mock <mock@cs.washington.edu>
To: spin-comp@cs.washington.edu
Subject: meeting today

I have a doctor's appointment at the UW hospital at 3pm. Since I have to
be there early, I won't be able to make today's group meeting.


	-- Markus



Date: Thu, 15 Apr 1999 15:36:02 -0700
From: eggers@yakima (Susan Eggers)
To: spin-comp@cs
Subject: next meeting

I'll be out of town for our meeting next week.  Or more accurately
I'll be coming back into town, but too late for the meeting.
Why don't you all meet without me?

Susan

To: cse590k@cs, cse590n@cs, spin-comp@cs, cecil@cs, echris@cs, brad@cs,
Subject: practice PLDI talk
Date: Fri, 16 Apr 1999 14:42:35 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

I'll be giving a practice of my PLDI talk in next week's 590k, so we'll
meet in Loew.

	An Evaluation of Staged Run-Time Optimizations in DyC
	Wednesday, April 21, 2:30pm
	Loew 113

The paper should soon be available upstairs.  You can also find it on our
web page:

	http://www/research/dyncomp/Papers/pldi99.ps
	/projects/unisw/DynComp/www/Papers/pldi99.ps

--Brian

To: spin-comp@cs
Subject: today's meeting
Date: Tue, 20 Apr 1999 13:51:31 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

In our office?

--Brian

To: spin-comp@cs
Subject: Dynamo `00
Date: Mon, 26 Apr 1999 16:03:09 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

http://domino.watson.ibm.com/confrnc/dynamo/dynamo00.nsf/

ACM SIGPLAN Workshop on 
Dynamic and Adaptive Compilation and Optimization 
(Dynamo'00) 

To be held January 18, 2000 in conjunction with:  
The 27th Annual ACM SIGPLAN-SIGACT Symposium on Principles of Programming Languages (POPL) 
Boston, Massachusetts, January 19-21, 2000

Research on Dynamic and Adaptive Compilation and related areas has been sporadic and spread out. The goal of the workshop is to bring together
researchers, practitioners, and implementors in these areas to present their experience and work in a forum that will allow them to colloborate and
exchange ideas. 

--Brian

To: spin-comp@cs
Subject: our TCS paper
Date: Thu, 06 May 1999 14:50:58 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

It looks like something is finally happening on the TCS front.
We seem to have to opportunity to fix bugs and send a new version.
Should we?  We have fixed the meets and merge function.  The meets
were the opposite of what they should have been, if I remember
correctly.

--Brian

------- Forwarded Message

X-Mailer: Novell GroupWise 4.1
Date: Mon, 03 May 1999 11:09:18 +0200
From: Stephanie Smit-Baich <s.smit@elsevier.nl>
To: grant@cs.washington.edu
Subject: TCSB paper 689 by Grant, B., M. Mock, M. Philipose, C.
	Chambers and S.J. Eggers
Mime-Version: 1.0
Content-Type: text/plain
Content-Disposition: inline
X-UIDL: 6542fdf42745c93f0bcb449357adcb0d
Status: U

3/5/1999

Dear Dr. Grant,

I acknowledge the safe receipt of your manuscript:

TCSB 689: DyC: an expressive annotation-directed dynamic compiler for
C 
(Grant, B., M. Mock, M. Philipose, C. Chambers and S.J. Eggers)

from Professor Consel, for publication in the TCS Special Issue
on Partial Evaluation and Semantics-Based Program Manipulation, 
PEPM'97

I kindly ask that you send me the TeX or LaTeX files of your 
paper by email (or send a floppy) at your earliest convenience. 

If the files are not available, please let me know so that we do 
not delay publication unnecessarily. 

It is essential that the paper version and electronic files must 
be exactly the same. If not, the paper version (which has been 
approved by the Editor) will be used. If in any doubt, send a 
paper copy to me with the files, and send a copy to Professor 
Consel as well. 

Please send me your complete (postal) address - and that of your 
co-authors (I asume that it is the same ?)

Thanking you for your cooperation, and looking forward to your 
reply, 

Kind regards,
- -- Stephanie Smit




------- End of Forwarded Message


Date: Fri, 7 May 1999 16:20:57 -0700
From: eggers@yakima (Susan Eggers)
To: spin-comp@cs, grant@thistle.cs.washington.edu
Subject: Re: our TCS paper

I would correct the errors, but no more.
We don't need to improve this publication
which few will actually see.

Susan

To: eggers@yakima (Susan Eggers)
cc: spin-comp@cs
Subject: Patents [Re: Tuesday at 3:30 is on ]
Date: Fri, 07 May 1999 17:32:50 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

Do you remember where the provisional applications are sitting?  I've
totally forgotten what we filed and wanted to look them over before the
meeting.

Also, do you still feel that this is a good use of our time?  It's still
not clear to me what we get out of it.  If another week is going to be
required to put together the final applications, I think we should open
this topic of discussion again.

--Brian

To: eggers@yakima (Susan Eggers)
cc: spin-comp@cs
Subject: Patents: examples [Re: what we promised ]
Date: Thu, 13 May 1999 17:05:21 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

I have written up some examples of conditions for conditional specialization.

"/projects/dyncomp/Papers/Patents/CondSpec Examples.fm"

(There is a space in that file name because I'm using Frame on a PC.)

--Brian

Date: Fri, 14 May 1999 13:03:06 -0700
From: eggers@yakima (Susan Eggers)
To: eggers@yakima, grant@thistle.cs.washington.edu
Subject: Re: Patents: examples [Re: what we promised ]
Cc: spin-comp@cs


Just in case Matthai and Markus have not yet written their stuff:
I don't think we need be quite as detailed as Brian's write-up.  The
lawyers already understand the context into which the examples fit
(after all, they asked for them).  I also don't think we should
introduce any new terminology.  So, for example, they may now 
think that a dynamic region is only conditionally dynamically
compiled.  I would get rid of the ski rental explanation and example.
as well.

My understanding is that, for example, Matthai just has to construct
code examples and identify what they are supposed to illustrate.

Susan

Date: Mon, 17 May 1999 14:27:27 -0700
From: eggers@yakima (Susan Eggers)
To: spin-comp@cs, levy@cs, eggers@yakima, sparekh@cs, redstone@yakima,
Subject: ROP

I'll have time to look over your progress reports for ROP on
Wed. morning.  (Read that as Wed. morning only.)  So could you
have your reports to me before then.

Matthai, I know I already have yours.

And since all the SMT students are OS students, I assume Hank will
handle those.  (Hank, you can thank me later ;-).)

Susan

Date: Mon, 31 May 1999 16:34:56 -0700
From: eggers@yakima (Susan Eggers)
To: spin-comp@cs
Subject: patents

I get back in town around noon.  Can one of you go into my
mailbox, get the patents, and have Melody/Linh start
xeroxing, so we can begin reading?

Thanks,
Susan
From rona@seanet.com Mon May 31 13:40:52 1999
Received: from june.cs.washington.edu (june.cs.washington.edu [128.95.1.4]) by yakima.cs.washington.edu (8.6.12/7.2ws+) with ESMTP id NAA12688 for <eggers@yakima.cs.washington.edu>; Mon, 31 May 1999 13:40:46 -0700
Received: from mx.seanet.com (dns2.seanet.com [199.181.164.2]) by june.cs.washington.edu (8.8.7+CS/7.2ju) with ESMTP id NAA05013 for <eggers@cs.washington.edu>; Mon, 31 May 1999 13:40:45 -0700
Received: from rona (host-93-34.dsl-sea.seanet.com [204.182.93.34]) by mx.seanet.com (8.9.3/Seanet-8.7.3) with SMTP id NAA10744 for <eggers@cs.washington.edu>; Mon, 31 May 1999 13:40:44 -0700 (PDT)
Message-ID: <000c01beaba5$f36f8c40$d50000c0@OFFICE>
From: "Ron Anderson" <rona@seanet.com>
To: "Susan Eggers" <eggers@cs.washington.edu>
References: <199905151438.HAA20702@yakima.cs.washington.edu>
Subject: Re: update on dates
Date: Mon, 31 May 1999 13:41:24 -0700
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Status: R

We mailed a copy of the draft application out last week.  If you haven't
received it by June 1, please call.  We can send the text via email
(encrypted zip file) if necessary and fax the drawings to you.  Please call
me at (425) 688-8816 tomorrow (June 1) to let me know status.

Regards,
Ron Anderson
----- Original Message -----
From: Susan Eggers <eggers@cs.washington.edu>
To: <rona@seanet.com>
Cc: <eggers@cs.washington.edu>
Sent: Saturday, May 15, 1999 7:38 AM
Subject: update on dates


> Ron and Alan --
>
> I was wrong about when I would be away -- it's June 3rd
> and 4th.  So I ask, can we have your patent draft to us
> earlier than the end of June 1.  I realize that's a holiday
> weekend, but any time you could give us would help.  Even
> earlier in the day.
>
> Thanks,
> Susan
>



To: Markus Mock <mock@cs.washington.edu>
cc: spin-comp@cs
Subject: Re: patent source 
Date: Tue, 01 Jun 1999 17:01:00 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

>> Can you send a pointer to the source?

It's in my PC directory on rfilesrv2:
\\rfilesrv2\students\grant\Patents

There is one word document and one visio document.  Visio is available for
installation, free of charge.  It can be found under the "Free Software"
link on the lab web page.

I've given one copy for Markus and I'm printing out two more copies now (one
for myself and one for Matthai).  I don't know if I'll be able to print a
third before leaving.

--Brian

To: spin-comp@cs
Subject: patent
Date: Wed, 02 Jun 1999 11:37:09 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

Is anybody else ready to discuss the patent?  

The first 80 pages is a structureless blob formed from our journal paper,
PLDI paper, provisionals, and supplementary examples and text we sent them.
The good news is that it seems largely correct, with few correctness changes
to be made.

The claims are more difficult to figure out.  There appear to be 19
claims.  I don't know which ones are indepedent or dependent.  I have
difficulty understanding what is supposed to be claimed by some of them.
The order of the claims also seems peculiar.  Here's my best guess as to
what the claims pertain:

Policies: 1-5
Automation: 7-8, 19
Conditional specialization: 8-10
Caching points: 11-14
On-demand: 15-16

I'm not really sure about the points of claims 1, 3, 6, 17, and 18.  I
know some claims are supposed to sound like we're claiming a computer,
compiler, etc., but these claims still seems a little off to me.  It
might help to know the rationale for how the claims are ordered, broken up,
made independent vs. dependent, etc.  Finally, except for claiming
computers and compilers, the claims don't seem as broad as I expected.

Other opinions?
--Brian

To: spin-comp@cs
Subject: patents [Ron Anderson]
Date: Wed, 02 Jun 1999 12:48:10 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

This message from Ron Anderson regarding reviewing the patent 
was included with the patent source files yesterday:

Please arrange for each of the inventors to review the draft application for technical accuracy and completeness, while bearing in mind that it must contain enough information to teach a person of ordinary skill in the art to make and use the invention, and must disclose the best mode known to the inventors for carrying out the invention. The numbered claims located near the end of the application should be given special attention in order to ensure that they appear to provide adequate protection for the invention if granted.  We have emphasised one of the four aspects disclosed in the Provisional applications in the claims, but have included at least one independent claim for each, with the expectation that we can add more claims in subsequent applications, particularly if the Examiner determines that there are multiple inventions being claimed.

After the review has been completed, please contact me or Alan Burnett to describe any changes or additions, or send us a marked-up copy of the draft.  We remind you that this application must be filed no later than June 11, 1999.  Thanks for your assistance.


Date: Wed, 2 Jun 1999 16:55:18 -0700
From: eggers@yakima (Susan Eggers)
To: spin-comp@cs
Subject: the patents

I'd like to get a sense of what people have done so far.
can you tell me?

Looks like Brian has made a quick pass over everything.
Don't know about anyone else.

We need, among all of us, to cover the whole thing well.
I'm reading everything, ok, almost everything, and I'll
need someone to read carefully those parts I'm not reading.

So here's a possible plan:
I discuss my changes to/questions about the body with Brian,
since he has at least skimmed that.
Can someone (Matthai?) take charge of the figures, and just make
sure that they are ok, so Brian and I don't even have to
read them.

I'm only on page 13, so that's the only plan I have so far.
If I come across another parcel like the diagrams, I'll
tap Markus.

I assume all 3 of you are reading the claims at the end.

And that Brian B. and Craig are not involved in this at all.

Susan

Date: Wed, 2 Jun 1999 17:53:29 -0700 (PDT)
From: Markus Mock <mock@cs.washington.edu>
To: Susan Eggers <eggers@yakima>
cc: spin-comp@cs
Subject: Re: the patents

I've now read most of it (I skipped some stuff in the middle) and I have
made one pass over the claims. As Brian noted, they are kind of hard to
figure out. I haven't looked much at the figures yet. 
As for the body of the text that I read: seems to be accurate, pasted
together from our papers which has introduced a couple of places where
terms where used that are only defined later.

	-- Markus



To: spin-comp@franklin.cs.washington.edu
Subject: patent stuff
Date: Thu, 03 Jun 1999 11:39:30 PDT
From: Matthai Philipose <matthai@franklin.cs.washington.edu>

I've gone through the figures and found a few errors.

Do I just grab the lock and annotate the word/visio document?
		Matthai

To: spin-comp@franklin.cs.washington.edu
Subject: Done with changes
Date: Thu, 03 Jun 1999 12:42:00 PDT
From: Matthai Philipose <matthai@franklin.cs.washington.edu>

I'm done with changes to the word and visio patent documents.

In word, my changes are annotated by  word "comments" (highlighted in 
yellow). The annotation contains the original sentence. These changes 
are minor.

In visio, I colored my changes in red. There were a few significant 
errors here.
			Matthai

To: matthai@cs, chambers@cs
cc: spin-comp@cs
Subject: deferred dataflow analysis
Date: Mon, 07 Jun 1999 09:18:31 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

Have you seen this?

--Brian

        http://www.cs.ucsb.edu/TRs/techreports/TRCS98-03.ps  

Details   Deferred Data-Flow Analysis Shamik D. Sharma - Anurag Acharya - Joel Saltz - Department of Computer Science - Department of
Computer Science - University of Maryland, College Park University of California, Santa Barbara - shamik@cs.umd.edu, acha@cs.ucsb.edu,
saltz@cs.umd.edu - Contact Phone   

Abstract: Loss of precision due to the conservative nature of compile-time dataflow analysis is a general problem and impacts a wide variety of
optimizations. We propose a limited form of runtime dataflow analysis, called deferred dataflow analysis (DDFA), which attempts to improve
precision by performing most of the analysis at compile-time and using additional information at runtime to stitch together information collected at
compile-time. We present an interprocedural DDFA framework that is applicable for arbitrary control structures including multi-way forks,
recursion, separately compiled functions and higher-order functions. We present algorithms for construction of region summary functions and for
composition and application of these functions. Dividing the analysis in this manner raises two concerns: (1) is it possible to generate correct and
compact summary functions for regions? (2) is it possible to correctly and efficiently compose and apply these functions at run-time? To address t...



......specialization time). The process usually involves generating parameterized code templates with holes in them; a runtime specializer plugs in these
holes with runtime values and stitches the templates. Engler et al. [8] allow programmers to construct and manipulate templates explicitly. Others, [5,
9, 13], generate templates automatically. These efforts are concerned with generating optimized code based on runtime values, so they focus on
lower-level optimizations like load-elimination, loop-unrolling, static branch-elimination etc. Similarly, DDFA generates information at
compile-time for the use...... 

To: spin-comp@cs
Subject: inline caches
Date: Tue, 13 Jul 1999 16:30:16 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

Inline caches are implemented.  The upshot is that m88ksim, chebyshev,
dotproduct, and romberg get essentially the same speedup with the inline
cache as with cache_one_unchecked.  binary no longer slows down, but the
speedup is significantly reduced. query still slows down, but by less.
I'm still timing mipsi.  For the others, cache_one_unchecked didn't matter.

--Brian

To: spin-comp@cs
Subject: commit of bin, lib, mflow, and regression
Date: Thu, 15 Jul 1999 14:29:01 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

Numerous changes supporting the Toplas and dispatching papers:
multiple inputs, instruction-mix analysis (IMA), breakdown of dynamic
compilation overhead (DCOB), inline caches, and direct table lookups.

If you're interested in trying out inline caches or direct table lookups,
let me know and I can explain how they work.

I also have a modified version of the SMT simulator for doing the
IMA and DCOB, if you're interested.  It isn't yet archived anywhere.

--Brian

To: cecil@cs.washington.edu, spin-comp@cs.washington.edu
Subject: POPL submission available
Date: Mon, 19 Jul 1999 13:00:01 -0400
From: Craig Chambers <chambers@watson.ibm.com>


Of the 3 POPL papers I started working on, one actually got submitted.  It's
"Combining Dataflow Analyses and Transformations," by Grove, Parikh, Dean,
and Chambers.  It's available in ~chambers/papers/popl/00/composed.{doc,mif,ps}
,
if you're interested.  It's not for further distribution, though.

-- Craig



Date: Fri, 23 Jul 1999 13:29:53 -0700 (PDT)
From: Markus Mock <mock@cs.washington.edu>
To: spin-comp@cs.washington.edu
Subject: HP Dynamo Techreport

is available at:

 http://www.hpl.hp.com/techreports/1999/HPL-1999-78.html


	-- Markus



Date: Thu, 5 Aug 1999 12:55:11 -0700
From: eggers@yakima (Susan Eggers)
To: spin-comp@cs
Subject: Vas Bala's talk

I trust you all are coming to Vas's talk at 2:30.  It would be
nice if you each dragged along a friend or two.  Notkin, who
would normally be supplying half the bodies, is out of town,
as is Ernst.

Other than Jake Cockrell (who's not here), who are Notkin's students?

Susan

To: spin-comp@cs
Subject: Patent: Prior art references for Initial Disclosure Statement
Date: Mon, 09 Aug 1999 16:24:47 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

So, which papers do we think are most relevant?

--Brian

------- Forwarded Message

From: "Alan Burnett" <ralanburnett@hotmail.com>
To: grant@cs.washington.edu
Subject: Prior art references for Initial Disclosure Statement
Date: Mon, 09 Aug 1999 15:59:25 PDT

Hello Brian,

I am preparing an Initial Disclosure Statement, which requires an applicant 
to provide a copy of any prior art the applicant is aware of which may be 
relevant to the patentability of the invention discosed and claimed in the 
patent application.
Do you happen to have access to any prior art that may be relevant to the 
patentability of your invention (other than your own papers - I already have 
a copy of those).  Your papers reference various publications (books, 
reports, papers, etc.), some of which the patent office may feel is relevant 
to your patent.  I would think the Consel & Noel 96 article would fall into 
this category, as would the Leone & Lee references - however, your group is 
much more knowledgable about the art of dynamic complilation, so you are in 
better position to decide what articles, if any, may be relevant.  There is 
no requirement to send copies of references that are not material to the 
patentability of your invention, which would include most of the other 
references in your papers.  Please let me know if your group has a copy of 
any of the relevant references, or know where a copy can be obtained.   
Thank you.

Regards,

Alan Burnett
Law Offices of Ron Anderson


_______________________________________________________________
Get Free Email and Do More On The Web. Visit http://www.msn.com


------- End of Forwarded Message



Date: Mon, 9 Aug 1999 16:32:52 -0700
From: eggers@yakima (Susan Eggers)
To: spin-comp@cs, grant@thistle.cs.washington.edu
Subject: Re: Patent: Prior art references for Initial Disclosure Statement

What does "relevant to the patentability" mean?
Related work in the normal sense?
Papers that show shortcomings relative to us?
Something else?

Susan

Date: Mon, 9 Aug 1999 17:31:41 -0700
From: eggers@yakima (Susan Eggers)
To: spin-comp@cs
Subject: reference

Does anyone have a reference for the Tera paper in which lookahead
is described?  And is it called lookahead?

Susan

Date: Tue, 10 Aug 1999 12:46:14 -0700
From: eggers@yakima (Susan Eggers)
To: spin-comp@cs
Subject: running jobs using yakima2's disks

Can you lower your priority so that I don't get such big pauses?

Thanks,
Susan

To: eggers@yakima (Susan Eggers)
cc: spin-comp@cs, sparekh@cs
Subject: Re: running jobs using yakima2's disks 
Date: Tue, 10 Aug 1999 12:48:21 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

>> Can you lower your priority so that I don't get such big pauses?

I haven't been able to access yakima2 today at all.  Sujay said he was doing
something (compiling the DEC OSF kernel?).

--Brian

Date: Tue, 10 Aug 1999 12:58:03 -0700 (PDT)
From: Sujay Parekh <sparekh@cs.washington.edu>
To: Brian Grant <grant@thistle.cs.washington.edu>
Cc: eggers@yakima.cs.washington.edu (Susan Eggers),
Subject: Re: running jobs using yakima2's disks 


Yup -- it's me.  The builds are, unfortunately, disk-intensive.  I'm moving
stuff onto the tennis alphas' local disks now, but it might take 20 mins or
so.  Sorry!

Brian, I don't see why you weren't able to access yakima2 all day -- I
didn't restart my builds until after 12.  Let's see if things improve after 
I move off.

Sujay

Brian Grant wrote:
|> Date: Tue, 10 Aug 1999 12:48:21 PDT
|> Subject: Re: running jobs using yakima2's disks 
|> 
|> >> Can you lower your priority so that I don't get such big pauses?
|> 
|> I haven't been able to access yakima2 today at all.  Sujay said he was doing
|> something (compiling the DEC OSF kernel?).
|> 
|> --Brian
|> 

To: spin-comp@cs
Subject: latest commit
Date: Mon, 23 Aug 1999 11:42:09 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

I just committed some fixes to the direct-table-lookup dispatches and
added support for invalidation-based dispatching.  The ms kernel in
regression uses these features, if you're interested in taking a look.

--Brian

To: cecil@cs.washington.edu, spin-comp@klamath, melody@cs.washington.edu,
Subject: my CMU addresses
Date: Tue, 24 Aug 1999 09:27:22 PDT
From: Craig Chambers <chambers@klamath.cs.washington.edu>


I am now starting to get settled in to my office at CMU.  No computer
yet (I'm using my laptop to dial out through my office phone line),
but I have a phone and mail.  Here is my work address & phone & fax
numbers:

Visiting Prof. Craig Chambers
Computer Science Department
Carnegie Mellon University
5000 Forbes Ave.
Pittsburgh, PA  15213-3891

Wean Hall Rm. 8116

Office phone: 412-268-8801
Department fax: 412-268-5576

-- Craig

To: spin-comp@klamath, cecil@cs.washington.edu
Subject: Mario Wolczko: we're hiring
Date: Thu, 26 Aug 1999 17:07:56 GMT
From: Craig Chambers <chambers@klamath.cs.washington.edu>


FYI.

------- Forwarded Message

Return-Path: Mario.Wolczko@Eng.Sun.COM
Received: from june.cs.washington.edu (june.cs.washington.edu [128.95.1.4]) by klamath.cs.washington.edu (8.8.5+CS/7.2ws+) with ESMTP id WAA23151 for <chambers@klamath.cs.washington.edu>; Thu, 29 Jul 1999 22:44:45 -0700 (PDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by june.cs.washington.edu (8.8.7+CS/7.2ju) with ESMTP id WAA25659 for <chambers@cs.washington.edu>; Thu, 29 Jul 1999 22:44:45 -0700
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA27289
	for <chambers@cs.washington.edu>; Thu, 29 Jul 1999 22:44:45 -0700 (PDT)
Received: from obj.Eng.Sun.COM (obj.Eng.Sun.COM [152.70.20.113])
	by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id WAA00027
	for <chambers@cs.washington.edu>; Thu, 29 Jul 1999 22:44:45 -0700 (PDT)
Received: (from mario@localhost)
	by obj.Eng.Sun.COM (8.9.1b+Sun/8.9.1) id WAA17287;
	Thu, 29 Jul 1999 22:44:44 -0700 (PDT)
Date: Thu, 29 Jul 1999 22:44:44 -0700 (PDT)
From: Mario Wolczko <Mario.Wolczko@Eng.Sun.COM>
Message-Id: <199907300544.WAA17287@obj.Eng.Sun.COM>
To: chambers@cs.washington.edu
Subject: we're hiring
Content-Length: 261

Craig,

I am looking to hire a researcher into my group
(www.sunlabs.com/research/kanban) in the coming months.  If you have
any good students looking for a job in that time frame and interested
in working at Sun Labs, please refer them to me...

Thanks,
Mario

------- End of Forwarded Message


To: spin-comp@cs
Subject: TCS paper
Date: Mon, 30 Aug 1999 08:31:35 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>


------- Forwarded Message

Received: from compose.irisa.fr (compose.irisa.fr [131.254.50.42]) by june.cs.washington.edu (8.8.7+CS/7.2ju) with ESMTP id DAA25794; Mon, 30 Aug 1999 03:29:29 -0700
Received: from irisa.fr (martinique.irisa.fr [131.254.50.8])
	by compose.irisa.fr (8.9.3/8.9.3) with ESMTP id MAA15520;
	Mon, 30 Aug 1999 12:29:27 +0200 (MET DST)
Message-ID: <37CA5D05.F8A5CF6E@irisa.fr>
Date: Mon, 30 Aug 1999 12:29:25 +0200
From: Charles Consel <consel@irisa.fr>
Organization: IRISA/INRIA/University of RENNES  I -- FRANCE
X-Mailer: Mozilla 4.04 [en] (WinNT; I)
MIME-Version: 1.0
To: grant@cs.washington.edu, chambers@cs.washington.edu
Subject: Special issue of TCS
References: <199805310525.WAA12314@thistle.cs.washington.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-UIDL: 8c41da0fb36b31d072d87af722e99b8f

I am happy to inform you that your paper

"DyC: An Expressive Annotation-Directed Dynamic Compiler for C"

has been tentatively scheduled to be published in Volume 248/1-2 to
appear in November 2000 as part of the special issue of Theoretical
Computer Science on Partial Evaluation and Semantics-Based Program
Manipulation (PEPM'97).

If you have any questions, please contact the issue manager of
Theoretical Computer Science, Mick van Gijlswijk
(m.gijlswijk@elsevier.nl).

Thanks for your contribution to this special issue.

Best regards,

Charles
- -- 
- ---------------------------------------------------------------
Charles Consel              | University of Rennes / Irisa 
 consel@irisa.fr            | Campus Universitaire de Beaulieu
 Phone: (33) 2 99 84 74 10  | 35042 Rennes Cedex
 Fax:   (33) 2 99 84 25 90  | France
- ---------------------------------------------------------------
  URL: http://www.irisa.fr/compose/consel
- ---------------------------------------------------------------


------- End of Forwarded Message



To: cecil@cs, spin-comp@cs
Subject: Gone Fishing
Date: Sun, 19 Sep 1999 12:14:46 PDT
From: Craig Chambers <chambers@klamath.cs.washington.edu>


FYI, I'll be away all next week, at SAS in Venice.  I'll be at work on
Monday till around 12 or 1pm my time, and I'll be back the following
Monday.

-- Craig

Date: Tue, 21 Sep 1999 20:14:48 -0700
From: eggers@yakima (Susan Eggers)
To: spin-comp@cs


----- Begin Included Message -----

From MAILER-DAEMON Tue Sep 21 19:40:15 1999
Subject: Returned mail: User unknown
To: eggers
Content-Length: 750
X-Lines: 23
Status: RO

The original message was received at Tue, 21 Sep 1999 19:40:07 -0700
from eggers@localhost

   ----- The following addresses had delivery problems -----
dyncomp  (unrecoverable error)

   ----- Transcript of session follows -----
550 dyncomp... User unknown

   ----- Original message follows -----
Return-Path: <eggers>
Received: (eggers@localhost) by yakima.cs.washington.edu (8.6.12/7.2ws+) id TAA00455; Tue, 21 Sep 1999 19:40:07 -0700
Date: Tue, 21 Sep 1999 19:40:07 -0700
From: eggers (Susan Eggers)
Message-Id: <199909220240.TAA00455@yakima.cs.washington.edu>
To: levy@cs, eggers, sparekh@cs, redstone, manu, dyncomp
Subject: yakima2's disk

We have a new one and it should be up and running.  Problems to
John Petersen x68507, jrp@cs.

Susan



----- End Included Message -----


To: spin-comp@cs
Subject: Fabius and annotations
Date: Mon, 27 Sep 1999 09:11:05 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

I'm looking at the "Lightweight Run-Time Code Generation" paper.  On
the fourth page, they show a multiple-argument style of "currying,"
which seems to indicate that they may have relied upon non-standard
currying syntax: "...syntax similar to curried application to
introduce a `division' of the actual arguments."  If they had an n-level
BTA instead of a 2-level one, they could have used standard currying
syntax, or just a modified dependency analysis (according to their
"Deferred Compilation" tech report).

They did admit that the currying was a programmer hint to Fabius, but they
claimed it was different from explicit annotations, and more analogous to
determining stages from loop nesting depths (top of second column on page 4).

--Brian

Date: Mon, 27 Sep 1999 09:31:12 -0700
From: eggers@yakima (Susan Eggers)
To: spin-comp@cs, grant@cs.washington.edu
Subject: Re: Fabius and annotations

thanks very much.  given what you say, i think "static" in quotes
is ambiguous enough.

s

To: spin-comp@cs
Subject: calpa comments
Date: Mon, 27 Sep 1999 10:56:34 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

Overall, it was pretty understandable, interesting, and novel.


Detailed comments:


Abstract:

"Calpa utilizes frequency"  -- execution frequency

It's _very_ bogus to say that Calpa came up with "better" annotations
than humans (us).  We could have easily put in different annotations, had
we chosen to do so, or had we written the driver programs to more
accurately reflect the chosen annotations.

Introduction:

p. 1:

Distinguish from other types of dynamic compilation.  We used "selective
dynamic compilation" in the PLDI paper.

The first paragraph could be more specific about executing enough times to
break even.

You could be even more vague/general about how variables are identified as
static by writing "programmer hints, such as annotations, ..." rather than
implying that all systems use explicit annotations.

p. 2:

It didn't take us several months to annotate the kernels and applications
we used for the PLDI study.  It took us several months to select applications
to use as benchmarks, and to debug our system.  For example, work on mipsi
was essentially all debugging.  Of our eventual benchmarks, only viewperf
(specifically, the shader) took significant time to profile and annotate.

p. 4 and 5:

I don't think so much detail about the system is necessary.  I think it
would be enough to mention the BTA, custom dynamic compilers, what
optimizations are performed, and the code cache.

p. 6:

You should make it clear which policies/annotations are unsafe.
If Calpa is using unsafe annotations, as we did, then you should say how
Calpa determined they were safe to use.  eager, promote_one_unchecked, 
cache_all_unchecked and @ are the primary unsafe annotations we used.  I see
you said that @ was used if loads were invariant during the profile run.
What about the others?

p. 7:

It sounds like Calpa already uses alias and heap analysis.

p. 9:

Do you put @ on function calls?  (No?) If so, how do you estimate the costs 
of calls?  

p. 10:

Read the section on dynamic compilation cost in the Toplas draft.  The
number of cycles per generated instruction depends, in part, on the numbers
and kinds of static operations and the control structure of the dynamic
code (e.g., dynamic branches).  With effort, you could probably come up with
a reasonable model of this (future work).

How do you determine monotonicity for cache_all_unchecked?

"re-reexecuting", "appllication" on the bottom line

p. 11:

"Interface Functions" could be more informative (e.g., "Profiler Interface").

By "exection frequency" do you mean proportion of total execution time?  Or,
do you mean, number of executions (with the same variable values?)?

Does Calpa account for optimizations relying on particular values, such as
strength reduction and dead-assignment elimination?

Part of dotproduct's annotation included a hacked form of zero propagation
and dead-assignment elimination.  What did you do about this?  Did you
leave in the test for zero in both the profiled and annotated versions?

p. 12:

From your experiments, I'm unconvinced that log-file size will not be
problematic.  I think you should admit that you may need clever schemes
for realistic applications.

p. 13:

What was the bug with query?  With romberg, you could easily put the second
region in a different file.  viewperf has two dynamic regions.

What happened to perl?  How is it annotated?  Do you think you can get
speedup?  What about the indirect function call in the execute loop?

More future work: Inlining could be done to extend dynamic regions
interprocedurally, as in dinero.  You could represent more optimizations,
such as the strength reduction, zero and copy prop, and dead-assignment
elim. that we used in dotproduct, pnmconvol, and dinero.  What challenges
do mipsi and the shader present?  More accurately modeled DC cost (not just
40 cycles/instr. generated).  Of course, you don't have to point out
all your weaknesses, I'm just providing fodder here. :-)

p. 14:

How would static analyses, like the glacial variable analysis or an n-level
staging analysis, be integrated with Calpa?  It isn't clear how this
additional information would be combined with the profiler's types of
information.

--Brian

To: spin-comp@cs
Subject: comments on Matthai's comments
Date: Mon, 27 Sep 1999 11:30:47 PDT
From: Brian Grant <grant@thistle.cs.washington.edu>

I thought all of Matthai's comments were great, but I wanteded to 
specifically support a few specific comments regarding spin/claims.

>>(2,1)
>>In what sense are DyC's annotation  simple and
>>straightforward? They are certainly powerful, but it's a stretch to
>>say their semantics are simple.

I definitely agree!!!!  For example, putting multiple-division-inducing
annotations inside a loop does things that we don't even understand yet.
You could call this a bug, but they truth is we decide what the "semantics"
of the annotations should be on a case-by-case basis.  That is, we tweak
them with nearly every new benchmark we add.  Additionally, we need to
sometimes modify the code for the annotations to have the effect we want.

>>(2,-2)
>>It's  mis-leading to imply that it took us months to annotate
>>the benchmarks in this paper.

Again, I agree.

>>(3,-3)
>>Are any of our BMs production quality? Maybe Mesa?

Only viewperf/mesa, IMO.

>>(15,-1)
>>I think the "great human time savings" is false for the small 
>>programs
>>in this study and should be removed. All these programs were 
>>annotated
>>using previous knowledge about code behavior, and given that
>>knowledge, it didn't take much time to annotate the stuff. The vast
>>majority of the time spent was in debugging the system once stuff was
>>annotated. 

I agree.

--Brian


Date: Wed, 29 Sep 1999 11:45:08 -0700
From: Markus Mock <mock@cs.washington.edu>
To: spin-comp@cs
Subject: FYI: FDO submission

can be found in 
/projects/dyncomp/Papers/FDO/submission.{fm,ps}

	-- Markus




Date: Wed, 29 Sep 1999 21:33:18 -0700
From: eggers@yakima (Susan Eggers)
To: spin-comp@cs
Subject: PLDI

I'd like to have 3 group meetings, in which we discuss each of the
PLDI submissions, to make sure that the work, at least as we know
it now, has no gotchas.  Better to find out now, than later.

So could each of Brian, Markus, and Matthai be prepared to present
to us, in words, what their paper is about:
the general outline
the motivation for the work
the results
the significance,
i.e., the case to the reviewers.

I think Brian should go first, since he's farthest along, and we don't
want to start writing if there are major holes.
And Matthai should go last, since his paper will be algorithmic, 
and might be the hardest to explain -- you don't want to go into
the algorithms in detail.
Which leaves Markus in the middle.

Now, a time.  I have Monday afternoons free from 2:30 on.  How about
Brian on 10/4, Markus on 10/11, Matthai on 10/18.  And then after this
is over, we probably won't meet until after the deadline, because we
could probably use the time more fruitfully working like beavers.

How does this sound?

Susan

Date: Wed, 29 Sep 1999 22:17:01 -0700 (PDT)
From: Markus Mock <mock@cs.washington.edu>
To: Susan Eggers <eggers@yakima>
cc: spin-comp@cs
Subject: Re: PLDI

Date, time & plan are fine with me.


	-- Markus



To: spin-comp@cs.washington.edu
Subject: test -- ignore
Date: Wed, 06 Oct 1999 13:49:35 PDT
From: Brian Grant <grant@cs.washington.edu>



To: spin-comp@cs.washington.edu
Subject: test2
Date: Wed, 06 Oct 1999 14:02:33 PDT
From: Brian Grant <grant@cs.washington.edu>



To: spin-comp@cs.washington.edu
Subject: test3
Date: Wed, 06 Oct 1999 14:05:12 PDT
From: Brian Grant <grant@cs.washington.edu>



To: cecil@cs.washington.edu, spin-comp@cs.washington.edu
Subject: progress report
Date: Mon, 11 Oct 1999 19:47:17 GMT
From: Craig Chambers <chambers@cs.washington.edu>


I figured I'd write a progress report, since I haven't written one for
a while and people might be interested to know what I've been working
on and what my plans are for this quarter.

*) I've been sitting in on Frank Pfenning automated theorem proving
class (learning about different forms of logics and in theorem proving
strategies), and in Bob Harper's type systems class (which is the
first-year-grad PL class, in which I'm learning how Bob teaches stuff
I mostly know already).

*) I had a debate proposal on design patterns accepted for POPL'00.
Bad news, as I now have to invest work in writing a paper presenting
our debate, and then in having the debate.  And I don't know how much
real disagreement the 3 of us (John Vlissides and Bill Harrison) have.
I've written a bunch of draft position statements and the like.  Final
deadline for our debate paper is Nov. 9.

*) I worked on a paper with Dave Grove & Tapan Parikh on formalizing
our composed dataflow analysis & transformation framework.  It was
rejected, mostly because of presentation problems.  It's being revised
(mostly by Dave) and is to be resubmitted to PLDI (due Nov. 12).

*) I spent a goodly amount of time over the last couple of months
working on the implementation of Whirlwind, focusing on getting the
main compilation path implemented and implementing the composed
dataflow analysis framework that we described in our POPL reject (to
make a later version of the paper stronger by being backed directly
with an implementation instead of indirectly by an implementation in
Vortex of an earlier, simpler design).  Whirlwind can now read in a
Wil program (produced by the Java->Wil front-end), parse it, do name
resolution & error reporting, do representation checking (a kind of
typechecking) & error reporting, and do some simple dataflow analyses
(right now, constructing reaching definitions which includes copy
propagation) using (a piece of) the dataflow analysis framework.
There's also an initial C code generator which produces output, but
the output is untested, as there is no run-time system (including
definitions of the macros called by the compiler output) against which
to compile the compiler output, nor have most of the necessary Java
native methods been implemented in order to be able to run a compiled
application.  So a fair about of grunt work remains in getting a real
compiler (even an unoptimizing one) to work.  I had to put aside this
implementation project in mid-September while I tackled other things I
needed to do.

*) Related to the Whirlwind compiler, I'd like to submit a grant
proposal to the NSF compilers program (due Nov. 23) on representation
optimization.  Unfortunately, I'm short on time and I'm not sure I
understand things well enough yet to really do it justice.  But I
should submit something.

*) I attended SAS.  Jonathan gave a very good presentation, although I
think the topic was a bit too applied (i.e. useful) for the typical
audience member.  Jonathan will be presenting a poster at OOPSLA, in
an effort to expose his SAS work more.  And there's hope for a PLDI
submission on this, although Jonathan and Gun are doing all the work.

*) I worked a bit on writing down the design for a partial form of
class hierarchy analysis (where only parts of the program's class
hierarchy and method definitions are known, and there are constraints
describing the possible forms of the unknown parts of the program),
which is what Jonathan Nowitz & I were working on when I left town
last March.  I would like to work this out more, defining the
algorithms e.g. for doing compile-time method lookup in the face of
partial knowledge of the class hierarchy and the methods in the
generic function, and working out more precisely what information
about the program is required for other optimizations & implementation
decisions, such as object layout (both per-field and overall) and
virtual function table layout (again, per-method and overall).  I'd
like to submit an ECOOP paper on this (due Nov. 27), if I get enough
done.  I also need to get this worked out before I implement a
class-analysis-based optimization pass in Whirlwind.

*) I've been exchanging email with Gary Leavens, Curtis Clifton
(Gary's student), and Todd about an extension to Java with
multimethods.  The key issue now is whether to write multimethods
separately from classes, over Tuples (see Gary and Todd's OOPSLA'98
paper), or to write them inside of classes in the same syntax as
single-dispatched methods.  The former doesn't bias the syntax towards
receiver-primacy, but requires knowing in advance when generic
functions are introduced which arguments they might dispatch on, and
encodes this division in all calls of the generic function.  (I favor
the receiver-oriented syntax, as it has the hard technical advantage
of not require advance planning of the set of dispatched arguments,
and has only a soft psychological argument of apparent bias against
it, but I think I'm outvoted.)  I suspect people are thinking about an
ECOOP submission, but maybe I've gummed up the works enough to cause
us to miss the deadline....

*) I gave a talk here to the PL faculty & students on Dubious.  I
think people here have such an ML way of thinking that it was hard for
them to understand the significance of what I was saying about modular
typechecking of multimethods.  After trying to re-explain it to people
in ML-like terms, I think they got it better.  As a result...

*) ... I've been working on an extension to SML'97 to support OO
programming, where I add extensible datatype declarations to define
class hierarchies and extensible function declarations to define
multimethods.  Explicit "open" keywords which datatypes and functions
are extensible (by default they are closed), enabling current ML
programs to have the same semantics, restrictions, and compilation
strategies as before.  Existing ML modules provide modularity & access
control.  Dubious's System M-style restrictions enable extensions to
function declarations to be typechecked in a safe and modular way.
(Compared to Dubious, new (small) technical results are in fitting
into existing ML syntax, in extending Dubious typechecking to handling
open vs. closed datatypes and functions, in making explicit signature
specifications, and in supporting additional features like "super".
And there is a lot of salesmanship in trying to sell the ML community
on multimethods and a more integrated treatment of OOP than previous
OO-in-ML papers.)  I hope to submit a PLDI paper on this.  I've talked
the ideas over with Karl Crary and Bob Harper here; they're favorable,
I think, but I don't know how strongly in favor, nor do I know how the
PLDI referees will react.

*) I've been thinking off and on about my work on extending Dubious to
first-class modules, which give parameterized modules, etc.  I wrote a
bunch of typing rules for a language, but stopped in the middle of the
subtyping rules, as I got tired (I then switched to hacking Whirlwind,
as described above, and never came back).  In working on the design
patterns debate proposal, though, I (re)gained a real appreciation for
a parameterized module construct that allows collections of aspects of
classes to be encapsulated in a module and applied in different
situations, to represent and implement various design patterns and
other higher-level abstractions.  So I really think it's important and
valuable to have such parameterized modules, and I think the Dubious
base is a good one as it offers many ways in which code can be
parameterized (a point of parameterization can appear anywhere an
identifier can appear, including the names of generic functions, the
names of method specializers, and the names of parents/superclasses).
I'd love to submit a paper to ECOOP on this, but once again, I need to
find time to work out the details and write the paper.

*) I've been working with Matthai on algorithms for automatic
construction of staged optimizations from monolithic ones, as the
foundation for the staged compilation aspect of Whirlwind.  We've
spent a bunch of time working out formal aspects of the system, such
as the representation for sets of programs compiled by early stages,
the notation for expressing analyses and transformations, and the
algorithms for producing the various staged versions of the system and
for coping with multiple compiler phases.  Still more tough details to
work out.  I've written a draft outline of the paper, with lots of
text and explanation in the motivation and in the technical sections
we understand best, as an aid to myself in understanding the remaining
problems.  We expect a PLDI submission on this.  (We *must* have one,
since we've been working on these algorithms (no implementation even!)
for most of a year, and we originally planned for a POPL
submission....)

*) I've done a little work thinking about Markus Mock's automatic
dynamic compilation project (Calpa).  A PLDI submission is hoped for.

*) Oh, and I have to make up my OOPSLA talk....

So as you can see, my future plate is pretty full: OOPSLA talk, OOPSLA
conference, POPL final paper, up to 5 PLDI submissions (2 of which
require substantial or complete writing by me), an NSF grant proposal,
and up to 3 ECOOP submissions (2 of which require complete writing by
me).  Ugh.  So much for "sabbatical."

-- Craig

Date: Mon, 11 Oct 1999 13:41:13 -0700
From: eggers@cs.washington.edu (Susan Eggers)
To: spin-comp@cs.washington.edu
Subject: our TOPLAS submission

I've put a copy of the TOPLAS submission in
/projects/dyncomp/Papers/Toplas/readThisOne.fm

Can you take a look and send your comments to Brian and me.  If we
don't hear from you by next Sunday, we'll assume that you think things
are ok and we'll send it off.

Thanks,
Susan

Date: Mon, 11 Oct 1999 15:22:54 -0700
From: eggers@cs.washington.edu (Susan Eggers)
To: spin-comp@cs.washington.edu, levy@cs.washington.edu,
Subject: disk cleanup

yakima3 is full.  If stuff you control lives there, can you
compress and delete?

Thanks,
Susan

Date: Tue, 12 Oct 1999 15:33:34 -0700
From: eggers@cs.washington.edu (Susan Eggers)
To: spin-comp@cs.washington.edu
Subject: accepted!

Our FDO submission breezed through.  Hardly any discussion --
everybody liked it.  Congratulations to Markus and Mark.

Susan

Date: Wed, 13 Oct 1999 09:57:05 -0700 (PDT)
From: Markus Mock <mock@cs.washington.edu>
To: spin-comp@cs.washington.edu
Subject: FDO reviews

Here are the reviews for our paper. Particularly reviewer 2 raises some
legitimate questions which we'll have to address for the future, if not
for final FDO then for PLDI, since they are likely to crop up again. 


	-- Markus


---------------------------------

The paper describes using value profiling to automate the authors
prior dynamic compilation system (DyC), which had previously been
guided by user annotations.  They show that the automated approach
achieves better performance than the user guided approach.

This is a really nice piece of research, and is a good step towards an
automated dynamic compilation system.  My only negative comment is
that the paper was hard to follow, because there are so many things to
talk about.  In the final version, it might be nice to give a more
detailed bigger picture in section 3 on how everything fits together,
and maybe concentrate on the feedback information and how you use
it to automate your DyC system.

In section 2.2, you say "polyvariant vs monovariant division policy
controls..." specialization.  Can you explain this in a little more
detail what tradeoffs you make between the two in controlling your
system?  

What do you profile? As I understand from the paper, you profile
everything, in the top 80% of the procedures?  So in these top
procedures, do you profile all variables using your use and variety
sets identify?  Please provide a little more detail on this.  Another
option would be to perform some compiler analysis before hand,
potentially identifying variables, which would be worth profiling in
to top 80% of procedures.  You could do some of your Benefit
Estimation described in 3.2.3 before deciding what to profile.  This
could significantly reduce your log file size and profiling time, by
reducing the amount of variables to examine.  If there is no potential
benefit from a variable being static, then don't profile it.  A good
example of this is the staging analysis used by Lee and Leone in their
ML compiler, and Knoblock and Ruf, both in PLDI96, and I thought you
had a similar in one of your prior papers.

In section 3.2.1, you say "the load of u[i] is static, if and only if
both i and the array address u is static...".  Just because the address
of array u and i are static, does not mean that the value of the load
is static, since there could be store that modifies it.  Why not just
profile the value of the load?

In this same section you describe how you keep track of the *use*
sets.  Did you also look at keeping track of the def sets?  By this I
mean that you might be able to get the same information by profiling
the result of a computation, then all of the uses in the computation,
or would this result in the same as what you are doing?  For example,
for the load of u[i], you can either profile the def (value of the
load) or the the use, the value of "i" and the address "u".  Just a
thought.

Please describe how the log is processed to get value profiling
information.  Is the log just one file, with all of the values for the
variables you are interested in, stored basically in a trace?  You
compare your work to Calder's, and say that you need to gather more
detailed relationships.  Please describe what these relationships are
and how you use them.

You say that you think the reason why your profiler is an order of
magnitude slower than Calder et. al. is because of the more detailed
information.  From what I can tell about your log file, I don't think
that is the reason, since Calder will process the same information.  I
think the main reason, is that you are writing to a log *file*.  Doing
that much I/O will definitely slow down your program a lot.  In
addition, I think you are comparing your profiling numbers to the
numbers Calder got from using intelligent sampling (convergent
profiling).  If you use sampling, I am sure your profiling time will
also come down.

In terms of related work, I wouldn't really say that Calder
et. al. had a "system".  The value profiling study was done to show
that value profiling could potentially be used to automatically guide
dynamic compilation and code specialization.  They proposed that value
profiling could be used to do this, and the focus of the study was to
just show that the semi-invariant behavior could be exposed using
value profiling.  They then went on to show in the journal paper that
the values found during profiling could be used to potentially guide
an automated optimization approach (like yours), by showing via hand
optimization that 2 codes could get substantial benefit from using the
value profiles.  For your results, when you get your system working on
larger programs, I'd be very interested in seeing results for m88ksim.
In the prior work, Calder et. al.  showed that value optimizing alignd
in m88ksim could provide a lot of improvement, and it would be nice to
see if your automated optimizer using value profiling would also find
this.  I assume it would.




////////////////////////////////////////////////////////////////////////////


The authors have previously built a system (DyC) for runtime specialization
of programs.  In that system, specialization is driven by annotations that 
have to be manually inserted by the programmer.  This is a tedious and
error-prone task.  The present paper describes Calpa, a preprocessor that 
can be used to automate the discovery and insertion of such annotations.
It carries out a binding-time analysis to determine the sets of variables
whose values, if known, could be used to specialize a piece of code at
runtime.  This is followed by a cost-benefit analysis to determine that
the runtime benefits of specialization will outweigh the cost of
specialization.  The results of these analyses are then used, together
with value profiles, to drive the generation of the specialization
annotations.

While the topic addressed is an important one, the paper leaves too many
important questions unanswered to be satisfactory.  In particular, the
cost-benefit analysis -- which is, in my opinion, the most important aspect
of the paper -- seems flawed, making it difficult to make any sort of 
prediction about the actual performance of the specialized code relative to
that of the original, unspecialized code.  The experimental evaluation is
also weak, with only a small number of (mostly small) programs.  I believe
that the topic of this work is interesting and important, but that the
publication of this paper in its current form is premature.

Detailed Comments:
=================
My primary concern is that the work does not seem very mature, and some
very important issues are not taken care of.  Because of this, I find it
hard to extrapolate from the present state of the system to imagine how
it would perform on "real" programs once it's in a mature state.

The binding time analysis described, while important, isn't too difficult:
conceptually related binding time analyses have been described, for 
example, in the CMIX partial evaluator for C [And92a,And92b].  The CMIX
system displays an annotated version of the program, with the static
variables highlighted, for the user's inspection; in principle one could do
something similar here, and let the user then produce the dynamic
specialization annotations.  Of course, this would leave the hard problem --
the cost-benefit analysis -- for the user; in my opinion that would not be a
great improvement on the status quo. 

What is most interesting and important about Calpa is that it attempts to
do the cost-benefit analysis as well.  My concern is that in the process
of doing so, it ignores many important aspects of system performance, which
makes it unclear how meaningful the costs/benefits computed are.  For
example:

-- Benefit estimation [Sec. 3.2.3]: I'm surprised that the size of the
   specialized code doesn't enter into the computation at all, since the
   effect this can have on the i-cache can be quite significant (for
   example, a number of authors have observed that "over-unrolling" a loop
   to the point where it doesn't fit in the i-cache can lead to significant
   performance degradations [DaJ96,Debr97]).  

   Also, benefit estimates that ignore for hardware characteristics such as
   instruction issue rules on a superscalar processor can be quite
   inaccurate.  For example, on the DEC Alpha processor, instructions are
   fetched in groups of 2 or 4 at a time (depending on the model); from the 
   group fetched, the hardware determines which instructions can be issued
   in the same cycle.  On such a processor, eliminating one instruction can
   mess up the "alignment" of subsequent instructions and lead to a
   performance degradation because of reduced multi-issues.      

-- Cost Estimation [Sec 3.2.4]:
   How close is the specialization cost estimate to the actual 
   specialization cost for a reasonably large suite of specialization
   opportunities?  With neither theoretical justification nor empirical
   validation for the way in which this cost is estimated, what can we say
   about the relationship between the estimate and the actual cost?  What
   if the estimate happens to be way off?

   A similar comment applies to the estimation of caching costs.

My concerns are primarily that, when I look at the cost/benefit
computations, I'm not sure what relationships I can guarantee between the
estimates obtained and the actual runtime costs.  For both the costs and
the benefits, the actual runtime costs/benefits could be either bigger or
smaller than the estimates.  As a result, it isn't clear to me what one can
say, a priori, about the performance of the specialized programs relative to
the unspecialized ones.  The experimental evaluation is also weak, with 
results given for only a small number of (mostly small) programs.

References:
==========
[And92a] L. O.Anderson, "Partial Evaluation of C and Automatic Compiler
	 Generation", in U. Kastens and P. Pfahler (eds), Compiler
	 Construction, Springer-Verlag LNCS vol. 641, 1992, pp. 251-257.

[And92b] L. O. Anderson, "C Program Specialization", MS Thesis, DIKU,
	 University of Copenhagen, Denmark, May 1992.

[DaJ96]  J. W. Davidson and S. Jinturkar,  "Aggressive Loop Unrolling in a
	 Retargetable Optimizing Compiler", in CC'96: Compiler
         Construction, April 1996. 

[Debr95] S. K. Debray, "Resource-Bounded Partial Evaluation",
	 Proc. PEPM-97, July 1997, pp. 179-192.

		

////////////////////////////////////////////////////////////////////////////


The paper describes Calpa, a tool that automatically annotates programs
so that the DyC compiler (previously developed by the authors) can
be used to perform dynamic compilation.

It is a fairly lengthy workshop paper, but well written, and interesting.

The paper describes work in progress -- the tool is incomplete, and
with one exception the benchmarks are quite small -- but this is
quite appropriate for workshop presentation.


////////////////////////////////////////////////////////////////////////////


Summary: This paper describes a tool for automatically inserting DyC
annotations into executables.  It comprises a profiling and an
analysis/rewriting program.  The early experimental results show that
this automated tool can identify the same basic set of annotations
that were identified by hand in early studies.

Overall, the paper is well written and the research is well done.
The topic is interesting, and it is clearly an important step toward
the general acceptance of dynamic compilation systems.

////////////////////////////////////////////////////////////////////////////




To: Markus Mock <mock@cs.washington.edu>
cc: spin-comp@cs.washington.edu
Subject: Re: FDO reviews 
Date: Thu, 14 Oct 1999 17:27:01 GMT
From: Craig Chambers <chambers@cs.washington.edu>


On Wed, 13 Oct 1999 09:57:05 MST, Markus Mock wrote:
> Here are the reviews for our paper. Particularly reviewer 2 raises some
> legitimate questions which we'll have to address for the future, if not
> for final FDO then for PLDI, since they are likely to crop up again. 

I just read through the reviews.  I actually think that reviewer 2 was
really anal and removed from reality with his comments.  He basically
complained that:

*) We aren't completely accurate in our cost/benefit analysis.
Duh....  Of course we can incrementally improve our model to be more
accurate.  Including instruction cache size overflow costs, for one,
is not hard to include.  The only response I can think to this is that
we describe the general problem of doing good cost/benefit analysis,
documenting all the costs/benefits of various forms that might exist,
and then marking which ones we account for today.

*) We can't guarantee any bounds on the relative efficiencies of the
optimized vs. unoptimized code.  This is a fact of life: nobody who's
practical proves bounds on their optimizations, since usually it's
very hard to argue there aren't cases or adverse interactions where an
optimization actually slows the program down, for some reason.  All we
are trying to do is make our best effort to, most of the time, do
something reasonable.  The only response to this I can think of, which
we've discussed before, is to protect our down-side by discussing how
the system can watch out for particularly bad inputs and avoid bad
"optimizations", via conditional specialization.

Why do people keep thinking CMIX is just like our BTA?  Just because
it handles C, too?  BFD....  Are there other aspects of CMIX that I
don't know about that we both do, that make our BTA look like CMIX's
to other PE people?

So I didn't get much from this review.

And I guess I'm a little grumpy this morning.

-- Craig

To: spin-comp@cs.washington.edu
Subject: TOPLAS submission
Date: Mon, 18 Oct 1999 19:30:11 GMT
From: Craig Chambers <chambers@cs.washington.edu>

I've read through much of the TOPLAS submission (through 6.2), and I
have some feedback.  Overall, it's good; all my comments are either
minor grammar-type things, or small issues about presentation and the
like.  Brian, can you call me to get the comments?  I think that'll be
faster than me trying to type in descriptions of them, and have you
all understand what I'm trying to say.

-- Craig

To: spin-comp@cs.washington.edu
Subject: dispatching paper abstract
Date: Tue, 19 Oct 1999 12:57:54 PDT
From: Brian Grant <grant@cs.washington.edu>

This was my first cut at an abstract for the dispatching paper. (to give
you a sense of the content and focus)

--Brian

Dispatching to the appropriate version of dynamically generated code
is one of the main overheads of run-time-specialization (RTS)
systems. A low dispatching cost is critical to some existing
applications of RTS, permits application of RTS to smaller regions of
code, and increases versatility of RTS systems. Low dispatching cost
also may be important for systems that automatically apply RTS, since
they may apply it in cases where little or no benefit is realized due
to imprecise RTS target-selection heuristics. Existing dispatching
techniques do not perform satisfactorily for some current and
anticipated applications of RTS, and have other disadvantages as well,
such as requiring whole-program analysis.

This paper discusses the chief issues in designing and implementing
efficient RTS dispatches and which known dispatching techniques, such
as those for type-based dispatching in object-oriented languages, are
most suitable to be adapted to RTS. We use microbenchmarks to
illustrate how various factors can affect the performance of different
dispatching techniques, code kernels to show how fast dispatching
benefits short specialized code regions, and actual applications to
show that the techniques can benefit realistic programs. Our
experiments were done using DyC, a selective dynamic compilation
system for C that performs run-time specialization guided by
source-code annotations. This work is done in anticipation of a system
that uses profile information and cost/benefit analysis automatically
selects RTS targets and inserts the annotations [Calpa].


Date: Tue, 19 Oct 1999 21:04:00 -0700 (PDT)
From: Markus Mock <mock@cs.washington.edu>
To: spin-comp@cs.washington.edu
Subject: a question about DyC (fwd)

Has this guy emailed anyone else in the group? If not, I'll just send him
the standard answer, ok?

	-- Markus

---------- Forwarded message ----------
Date: Tue, 19 Oct 1999 11:39:33 +0800
From: Jiang Zhiqiang <engp9405@nus.edu.sg>
To: mock@cs.washington.edu
Subject: a question about DyC

Dear Sir:

I'm a graduate research student in National University of Singapore. I'm
very interested in your Dynamic Compilation Project. And I think your
Dyc-An expressive annotation-directed dynamic compiler for C is really
useful for my present research. So I want to try it for one application
program. But  I wonder if your compiler could be open for other's use
now? If yes, could you please tell me how can I get or download it?

Thank you very much.

Sincerely yours,

Jiang Zhiqiang



To: Markus Mock <mock@cs.washington.edu>
cc: spin-comp@cs.washington.edu
Subject: Re: a question about DyC (fwd) 
Date: Tue, 19 Oct 1999 22:24:23 PDT
From: Brian Grant <grant@cs.washington.edu>

>> Has this guy emailed anyone else in the group? If not, I'll just send him
>> the standard answer, ok?

He emailed me as well.  I have not yet responded.  Feel free to send
him the standard response (and please cc the group), or I can do it.  We
could also potentially direct him to Tempo, which has a public (binary-only)
release.

--Brian

Date: Wed, 20 Oct 1999 10:38:42 -0700 (PDT)
From: Markus Mock <mock@cs.washington.edu>
To: Jiang Zhiqiang <engp9405@nus.edu.sg>
cc: spin-comp@cs.washington.edu
Subject: Re: a question about DyC

I'm afraid the answer is no.  DyC is embedded into the Multiflow
compiler.  In order to get the source for Multiflow from Digital,
we had to sign an agreement that prevents us from giving away the
code.

If you are simply looking for a dynamic compiler for C, Tempo may work for
you. It is is available for download at http://www.irisa.fr/compose/tempo/

Thanks for your interest.


	-- Markus

On Tue, 19 Oct 1999, Jiang Zhiqiang wrote:

> Dear Sir:
> 
> I'm a graduate research student in National University of Singapore. I'm
> very interested in your Dynamic Compilation Project. And I think your
> Dyc-An expressive annotation-directed dynamic compiler for C is really
> useful for my present research. So I want to try it for one application
> program. But  I wonder if your compiler could be open for other's use
> now? If yes, could you please tell me how can I get or download it?
> 
> Thank you very much.
> 
> Sincerely yours,
> 
> Jiang Zhiqiang
> 
> 
> 


Date: Fri, 22 Oct 1999 16:13:48 -0700
From: eggers@cs.washington.edu (Susan Eggers)
To: levy@cs.washington.edu, eggers@cs.washington.edu,
Subject: for a humor break


----- Begin Included Message -----

From voting-faculty-request@june.cs.washington.edu Fri Oct 22 13:52:26 1999
To: faculty <faculty@cs.washington.edu>, support@cs.washington.edu
Subject: Haiku Error Messages (fwd)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Content-Length: 1745
X-Lines: 104
Status: RO




In Japan, Sony Vaio machines have replaced the impersonal and unhelpful
Microsoft error messages with their own Japanese haiku poetry, each only 17
syllables.

------------------------

A file that big?
It might have been very useful.
But now it is gone.

------------------------

The Web site you seek
Can not be located but
Countless more exist.

------------------------

Chaos reigns within.
Reflect, repent, and reboot.
Order shall return.

------------------------

ABORTED effort:
Close all that you have worked on.
You ask way too much.

------------------------

Windows NT crashed.
I am the Blue Screen of Death.
No one hears your screams.

------------------------

Yesterday it worked.
Today it is not working.
Windows is like that.

------------------------

First snow, then silence.
This thousand dollar screen dies
So beautifully.

------------------------

With searching comes loss
And the presence of absence:
"My Novel" not found.

------------------------

The Tao that is seen
Is not the true Tao, until
You bring fresh toner.

------------------------

Stay the patient course.
Of little worth is your ire.
The network is down.

------------------------

A crash reduces
Your expensive computer
To a simple stone.

------------------------

Three things are certain:
Death, taxes, and lost data.
Guess which has occurred.

------------------------

You step in the stream,
But the water has moved on.
This page is not here.

------------------------

Out of memory.
We wish to hold the whole sky,
But we never will.

------------------------

Having been erased,
The document you're seeking
Must now be retyped.

------------------------

Serious error.
All shortcuts have disappeared.
Screen. Mind. Both are blank.




----- End Included Message -----


Date: Mon, 25 Oct 1999 12:08:52 -0700 (PDT)
From: Markus Mock <mock@cs.washington.edu>
To: spin-comp@cs.washington.edu
Subject: PLDI paper talk at 2:30 cancelled

Susan and I decided that I better spend the time on getting Calpa into
better shape.

Overall, our view of our PLDI paper is that it is going to be like the FDO
paper except a more general vision of what Calpa is going to be,
discussion of the cost benefit model, what costs are incurred and when in
the two different caching schemes, etc. 
And we'll try to validate our point by having real apps like m88ksim go
thru the system with good annotations coming out. 


	-- Markus


Date: Thu, 28 Oct 1999 13:26:36 -0700
From: eggers@cs.washington.edu (Susan Eggers)
To: levy@cs.washington.edu, eggers@cs.washington.edu,
Subject: yakima2

Could whoever is chewing on my machine nice your job?

Thanks,
Susan

Date: Fri, 29 Oct 1999 13:29:54 -0700
From: eggers@cs.washington.edu (Susan Eggers)
To: spin-comp@cs.washington.edu, levy@cs.washington.edu,

(Melody says that) Craig got a surprise machine from IBM that he can't
use and doesn't want.  Can we?

It's an IBM M/T model running 5692AIX
CD ROM
9.1GB (presumeably) disk
Ethernet connection
17" monitor
512 MB memory with some sort of expansion mechanism
200 MHz uniprocessor (a 630)
keyboard & mouse

Susan

Date: Fri, 29 Oct 1999 13:30:26 -0700
From: eggers@cs.washington.edu (Susan Eggers)
To: levy@cs.washington.edu, eggers@cs.washington.edu,
Subject: forgot to say

it's an RS6000

To: eggers@cs.washington.edu (Susan Eggers)
cc: spin-comp@cs.washington.edu, levy@cs.washington.edu,
Date: Fri, 29 Oct 1999 21:08:03 GMT
From: Craig Chambers <chambers@cs.washington.edu>

It came as part of an award/grant from them.  "surprise", "can't use",
and "doesn't want" are too strong.  "Expecting, but don't have a lot
of use for" is more accurate.  I'm happy for others to find good ways
to use it.

-- Craig

On Fri, 29 Oct 1999 13:29:54 MST, Susan Eggers wrote:
> (Melody says that) Craig got a surprise machine from IBM that he can't
> use and doesn't want.  Can we?
> 
> It's an IBM M/T model running 5692AIX
> CD ROM
> 9.1GB (presumeably) disk
> Ethernet connection
> 17" monitor
> 512 MB memory with some sort of expansion mechanism
> 200 MHz uniprocessor (a 630)
> keyboard & mouse
> 
> Susan

Date: Mon, 1 Nov 1999 15:04:21 -0800 (PST)
From: Markus Mock <mock@cs.washington.edu>
To: spin-comp@cs.washington.edu
cc: cs-grads@cs.washington.edu
Subject: Practice talk: Automating Dynamic Compilation with Calpa

Tuesday, November 2, at 2:30 in Sieg 422 I'll give a practice of my talk
at the FDO (Feedback-Directed Optimization) workshop titled 

"Calpa: A Tool for Automating Dynamic Compilation".

Everyone interested welcome, bribes will be provided.


	-- Markus



Date: Mon, 8 Nov 1999 17:48:31 -0800
From: eggers@cs.washington.edu (Susan Eggers)
To: levy@cs.washington.edu, eggers@cs.washington.edu,
Subject: Frame


Does anyone have my copy of the Frame documentation?
I'd like it back asap.

Thanks,
Susan

Date: Mon, 8 Nov 1999 17:58:48 -0800
From: eggers@cs.washington.edu (Susan Eggers)
To: spin-comp@cs.washington.edu
Subject: combined .bib

I'd like the lock on combined.bib

Susan

Date: Mon, 8 Nov 1999 19:55:03 -0800
From: eggers@cs.washington.edu (Susan Eggers)
To: spin-comp@cs.washington.edu, eggers@cs.washington.edu
Subject: Re: combined .bib

I'm releasing the lock on combined.bib.  I've made a lot of changes
in it, so that now the references in the Calpa paper look uniform.
Plus I've put Markus's new citations into it, so we no longer need
the *mock*.bib bib file.

Susan

Date: Tue, 9 Nov 1999 10:57:59 -0800
From: eggers@cs.washington.edu (Susan Eggers)
To: levy@cs.washington.edu, eggers@cs.washington.edu,
Subject: Micro30

Doi any of you have my Micro-30 proceedings from 1997?

Susan

Date: Tue, 9 Nov 1999 11:51:41 -0800 (PST)
From: Markus Mock <mock@cs.washington.edu>
To: spin-comp@cs.washington.edu
Subject: Final FDO program (fwd)

FYI: final program with downloadable papers is up. 


	-- Markus

---------- Forwarded message ----------
Date: Tue, 9 Nov 1999 11:28:11 -0800 (PST)
From: Bradley Calder <calder@cs.ucsd.edu>
To: Robert.Cohn@compaq.com,
    ealan@il.ibm.com,
    youfeng.wu@intel.com,
    zhwang@eecs.harvard.edu,
    cyoung@research.bell-labs.com,
    gene.albert@compaq.com,
    sjinturkar@lucent.com,
    erven@eecs.harvard.edu,
    seidl@cs.colorado.edu,
    rdbarnes@crhc.uiuc.edu,
    mock@cs.washington.edu
Cc: cnewburn@ichips.intel.com
Subject: Final FDO program


Take a look at the final FDO program to note when your talk is and who
your session chair is. Make sure to find your session chair at least
15 minutes before your session starts:

http://www-cse.ucsd.edu/users/calder/fdo/program.html

In addition, all of the papers can be found on this page.


-- Brad


To: Brian Grant <grant@cs.washington.edu>
Cc: cecil@cs.washington.edu, spin-comp@cs.washington.edu
Subject: Re: bibtex entries 
Date: Wed, 10 Nov 1999 17:49:16 GMT
From: Craig Chambers <chambers@cs.washington.edu>


On Wed, 10 Nov 1999 09:07:29 PST, Brian Grant wrote:
> I have one new ecoop99 entry.  Should I add it to oopsla-ecoop.bib?

I guess Emacs will do the right thing if you've written to a file that
I then try to write to, so go ahead and add it.

> Do you know where I could find page numbers for the papers in ecoop99?
> I looked at http://www.di.fc.ul.pt/ecoop99/, but didn't find that info.
> 
> --Brian

I found this cool resource for finding the details of bib entries
(unfortunately in HTML rather than BibTeX).  Go to 
http://www.informatik.uni-trier.de/~ley/db/
It's amazing.

If anyone knows where to find canonical bibtex entries for our
conferences & journals, please let me know.

-- Craig

Date: Thu, 11 Nov 1999 09:23:56 -0800 (PST)
From: Michael Ernst <mernst@cs.washington.edu>
To: chambers@cs.washington.edu
Subject: Re: bibtex entries

> I found this cool resource for finding the details of bib entries
> (unfortunately in HTML rather than BibTeX).  Go to 
> http://www.informatik.uni-trier.de/~ley/db/
> It's amazing.
> 
> If anyone knows where to find canonical bibtex entries for our
> conferences & journals, please let me know.

I use http://liinwww.ira.uka.de/bibliography/index.html#search.

					-Mike

Date: Mon, 15 Nov 1999 10:37:43 -0800
From: eggers@cs.washington.edu (Susan Eggers)
To: spin-comp@cs.washington.edu
Subject: PLDI papers

I've put copies of our papers in /projects.  Congratulations to
all of you who worked so hard on them.  They look good!  Now
we cross our fingers.

Susan

To: cecil@cs.washington.edu
cc: spin-comp@cs.washington.edu
Subject: EML PLDI submission
Date: Mon, 15 Nov 1999 18:57:47 GMT
From: Craig Chambers <chambers@cs.washington.edu>

My PLDI submission on an object-oriented version of ML, called EML, is
available internally at ~chambers/papers/pldi/00/ML/eml4.fm, FYI.

-- Craig

Date: Mon, 15 Nov 1999 13:06:01 -0800
From: eggers@cs.washington.edu (Susan Eggers)
To: spin-comp@cs.washington.edu
Subject: DCPI

Where does the DCPI software live?

Susan

To: eggers@cs.washington.edu (Susan Eggers)
cc: spin-comp@cs.washington.edu
Subject: Re: DCPI 
Date: Mon, 15 Nov 1999 13:19:22 PST
From: Brian Grant <grant@cs.washington.edu>

/projects/dyncomp/Tools/dcpi

--Brian

Date: Mon, 15 Nov 1999 16:25:00 -0800
From: eggers@cs.washington.edu (Susan Eggers)
To: eggers@cs.washington.edu, grant@cs.washington.edu
Subject: Re: DCPI
Cc: spin-comp@cs.washington.edu


Could one of you download the new version?

Thanks,
Susan


----- Begin Included Message -----

From owner-cpi@pa.dec.com Tue Nov  9 16:58:47 1999
X-Mailer: Pachyderm (client srcdhcp96-166.pa.dec.com, user mtv)
To: dcpi-external-users@pa.dec.com
Subject: DCPI-V3.8-EXTERNAL
Mime-Version: 1.0
Content-Type: text/plain
Content-Length: 3374
X-Lines: 98
Status: RO


There is a new external test release of DCPI (DCPI-V3.8-EXTERNAL). This 
is the first external release with support of ProfileMe on EV67 cpus.

For downloads, see
  http://www.research.compaq.com/SRC/dcpi/release.html

For a tutorial talk on using ProfileMe on EV67, see
  http://www.research.compaq.com/SRC/dcpi/pubs-and-talks.html

 -Mark Vandevoorde
 DCPI Team, Systems Research Center

N.B.  It may take several hours for the release to cross over to our http 
and ftp servers outside the Compaq firewall.

-----------------------------------------------------------------
DCPI-V3.8 Release Notes

Changes since release V3.4:

- Supports ProfileMe counters on EV67 (Alpha 21264a) cpus!
  (See "man dcpiprofileme" and "man dcpid")

- Dcpiprof and dcpilist require "-help" to list descriptions of their
  many flags.

- Dcpid's command syntax for selecting events has changed (see man dcpid).
  The new syntax supports multiplexing of profile-me modes with
  aggregate (i.e., non-profileme) modes.

- A new tool, dcpitopcounts, lists instructions with the highest event
  counts (see man dcpitopcounts).

- Dcpid supports a new -nice option to adjust its scheduling priority,
  and a new -gc option to automatically delete old epochs.

- Support for Tru64 V4.0c and earlier has been dropped.  Use DCPI-V3.4
  for V4.0 through V4.0c.

Known problems:

- When collecting data using multiple "-slot"s, each slot must have at
  least one event that occurs at least every 2^30 cycles, e.g.,
  retires, cycles, issues, or profileme mode.  Dcpid does not
  check this requirement

Changes since release V2.12:

- Pcount driver is dynamically loadable.

- Dcpid loads pcount at startup and unloads it at exit.

- A new underlying profile file format is used to store sample data
  for all events in a single file per image.  Backwards compatibility
  has been retained so that all tools support profiles collected with
  previous versions of DCPI.

- Dcpid supports a new -nice option to adjust its scheduling priority,
  and a new -gc option to automatically delete old epochs.

- Fixed a rare assertion failure in instruction-level analysis tools.

- This version works with Digital Unix T5.0 646.2 (a.k.a. BL17)

- Support for Digital Unix 3.2 has been dropped.  Use DCPI-V2.11 and
  pcount-13.3 build 15 for machines running 3.2.

Changes since release V2.11:

- Added support for Alpha 21066 and other 21064-compatible cpus.

Changes since release V2.10:

- Adds support for compressed kernel modules.

- dcpiprof listings now contain information about which named
  procedure is near an anonymous procedure to help the user in finding
  anonymous procedures.

Changes since release V2.5:

- DCPI releases V2.6 through V2.9 each had incompatibilities
  with various versions of Digital Unix.  We believe that these
  problems have been corrected.
  
- New loader for 4.0c and higher.
  Dynamically linked images can be profiled on machines running
  DU V3.2 or V4.0*, but not V5.0*.  The INSTALL script tests the
  DCPI loader before installing it as the default system loader.

- Minor improvements to dcpid image identification.
  Image maps for common DU V4.0c and V4.0d binaries are compiled into dcpid.
  Fixed identification of large images started before dcpid.

- Major update to dcpi2pix to generate more accurate data.

- Added support for new 21264 instructions.


----- End Included Message -----


Date: Thu, 18 Nov 1999 17:58:55 -0800
From: eggers@cs.washington.edu (Susan Eggers)
To: spin-comp@cs.washington.edu
Subject: the affiliates meeting


The call for affiliates talks has gone out.  Happily, we have a
lot to present this year.
I assume that Markus, Brian and Matthai will be able to give talks
on their new work (fdo, dispatching and/or DC costs, the staging
infrastructure).  BTW the meeting is Feb. 24. 

Talk also implies that you make a poster from your talk slides.

This ok with everyone?

Susan

Date: Fri, 26 Nov 1999 22:38:41 -0800
From: eggers@cs.washington.edu (Susan Eggers)
To: spin-comp@cs.washington.edu
Subject: applications

What was our experience with compress and li?  I'm seeing other
systems that are able to get speedups (PLDI reading).  And so am
wondering.

Susan

Date: Thu, 2 Dec 1999 18:43:07 -0800
From: eggers@cs.washington.edu (Susan Eggers)
To: smt@cs.washington.edu, spin-comp@cs.washington.edu, java@cs.washington.edu
Subject: meetings next quarter

The Dean's office is trying to pin me down to some meeting dates.
So before I do that, can we pin ourselves down?  Can you tell me
what you expect, i.e., is next quarter the same as this quarter?

Susan

To: cs-grads-jobs@cs.washington.edu, cecil@cs.washington.edu,
Subject: Rob Stets: 
Date: Fri, 03 Dec 1999 16:32:41 GMT
From: Craig Chambers <chambers@cs.washington.edu>



------- Forwarded Message

Return-Path: stets@pa.dec.com 
Delivery-Date: Thu, 02 Dec 1999 08:57:36 GMT
Return-Path: stets@pa.dec.com
Received: from june.cs.washington.edu (june.cs.washington.edu [128.95.1.4])
	by klamath.cs.washington.edu (8.9.3/8.9.3/0.3) with ESMTP id AAA23584
	for <chambers@klamath.cs.washington.edu>; Thu, 2 Dec 1999 00:57:35 -0800 (PST)
	(envelope-from stets@pa.dec.com)
Received: from mail1.digital.com (mail1.digital.com [204.123.2.50])
	by june.cs.washington.edu (8.9.3/8.9.3/0.3j) with ESMTP id AAA05146
	for <chambers@cs.washington.edu>; Thu, 2 Dec 1999 00:57:34 -0800
	(envelope-from stets@pa.dec.com)
Received: from pobox1.pa.dec.com (pobox1.pa.dec.com [16.1.240.19])
	by mail1.digital.com (8.9.2/8.9.2/WV2.0g) with SMTP id AAA01421
	for <chambers@cs.washington.edu>; Thu, 2 Dec 1999 00:57:33 -0800 (PST)
Received: from wera.pa.dec.com by pobox1.pa.dec.com (5.65v3.2/1.1.10.5/07Nov97-1157AM)
	id AA05144; Thu, 2 Dec 1999 00:57:33 -0800
Received: by wera.pa.dec.com; (8.8.8/1.1.8.2/06Jun96-0357PM)
	id AAA04992; Thu, 2 Dec 1999 00:57:33 -0800 (PST)
Date: Thu, 2 Dec 1999 00:57:33 -0800 (PST)
From: Rob Stets <stets@pa.dec.com>
Message-Id: <199912020857.AAA04992@wera.pa.dec.com>
Apparently-To: <chambers@cs.washington.edu>


                             SUMMER, 2000,
                    INTERNSHIP OPPORTUNITIES AT WRL

                      Western Research Laboratory
                      Compaq Computer Corporation
                          250 University Ave.
                          Palo Alto, CA 94301

The Western Research Laboratory is a computer systems research group
that was founded in 1982.  At present we have 19 full-time
researchers.  Our goal is to develop new hardware and software
technology that may lead to either new business opportunities for
Compaq or improvements to Compaq's existing products.  We test our
ideas by designing, building and using real systems. Examples of lab
projects that you may have heard of include the Itsy Pocket Computer,
Shasta: a software-only shared-memory system, the AltaVista web search
engine, and the ATOM program instrumentation system.

Every summer WRL employs several graduate students on projects related
to our research efforts.  We are now accepting applications for
positions during the upcoming summer (2000).  The positions usually
involve work that is of use to the full-time researchers and of a
scope that can reasonably be completed during the summer months.

To qualify, a student should be enrolled in a PhD program, although
exceptional Masters students will also be considered. While the
starting and ending times for these jobs are flexible and will depend
on a student's individual schedule, individuals will typically be
expected to spend three months at WRL.

WRL is located in the heart of cosmopolitan downtown Palo Alto, within
walking distance of a variety of restaurants and shops, and next to
the Stanford University campus. Palo Alto is situated 30 miles south
of San Francisco in the heart of Silicon Valley.

Ongoing research projects span the following areas:

      	Application Performance Studies (especially database applications)
      	Architectural Simulation
        Augmented Memory & Wearable Computing
      	Cluster Computing
      	Hardware and Software for Distributed Shared Memory
      	Innovative WWW Applications
      	Internet Performance
      	Operating Systems
        Pocket Computers: Hardware, Software, User Interfaces, and
           Power Management/Optimization
       	Profile-guided Compiler Optimizations
        Remote Telepresence
      	Scalable Computer Systems
        Speech Recognition
        Wireless Multimedia

The above list is not necessarily complete and we encourage excellent
students interested in related areas to apply.  Please see
http://www.research.compaq.com/wrl or e-mail
wrl-interns-coordinator@pa.dec.com for more information about our lab.
        
HOW TO APPLY

1. E-mail your resume to wrl-interns-coordinator@pa.dec.com with
   "INTERN RESUME" in the subject line.  Please ensure that your resume
   is in plain ASCII, not PostScript, and includes the names and e-mail
   addresses of three technical references.  It will be helpful if your
   message specifies the two or three research areas listed above that
   you are most interested in.  You are also encouraged to provide URLs
   to related information and/or to Postscript copies of your resume.

2. Arrange to have each of your references send a letter of
   recommendation to wrl-interns-coordinator@pa.dec.com with "INTERN
   RECOMMENDATION" in the subject line.  ASCII is preferred, but
   PostScript is acceptable too.  It is your responsibility to ensure
   that the letters are sent to us; WRL will not contact your references
   for you. For full consideration, your resume and recommendation
   letters must be received by February 11, 2000.  We expect decisions
   will be made on or before March 31, 2000.




------- End of Forwarded Message


Date: Wed, 15 Dec 1999 10:25:08 -0800
From: eggers@cs.washington.edu (Susan Eggers)
To: spin-comp@cs.washington.edu
Subject: affiliates

I didn't hear from most of you, so I volunteered you to J-L and
Gretchen for affiliates talks on your respective topics.

Susan


----- Begin Included Message -----

From eggers Wed Dec 15 10:07:46 1999
To: gretc@cs.washington.edu
And now I'm adding Matthai Philipose, Markus Mock and an outside
chance of Brian Grant (if he's not our of town interviewing).

Susan


----- End Included Message -----


Date: Wed, 15 Dec 1999 10:46:09 -0800
From: eggers@cs.washington.edu (Susan Eggers)
To: gretc@cs.washington.edu
Subject: RE: affiliates meeting
Cc: redstone@cs.washington.edu, spin-comp@cs.washington.edu,


Can you all get back to Gretchen with titles?

Gretchen:
Aldrich, Mock, Philipose, Grant are in compilers -- Chambers/Eggers
Redstone could be operating systems or architecture -- Eggers/Levy

Susan


----- Begin Included Message -----

From gretc@cs.washington.edu Wed Dec 15 10:35:33 1999
To: "'eggers@yakima'" <eggers@yakima>
Subject: RE: affiliates meeting
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="ISO-8859-1"
Content-Length: 925
X-Lines: 30
Status: RO

You're right, I do have Jonathan but I got his name from Jean-Loup so I
assumed that he was Jean-Loup's student.  Should I also be listing your name
as faculty advisor?

Can you please give me tentative titles for the next three students and also
the subject areas that they should be listed under?

Also, can you please give me a better title for Joshua Redstone?

I hate bugging you about this but I'm hoping to get this page done over the
next couple of days so that we can get the invitation out to the affiliates
early in January.  

Thanks,
Gretchen

-----Original Message-----
From: eggers@yakima [mailto:eggers@yakima]
Sent: Wednesday, December 15, 1999 10:08 AM
To: gretc@cs.washington.edu
Cc: eggers@yakima
Subject: RE: affiliates meeting



You should also have Jonathan Aldrich.
And now I'm adding Matthai Philipose, Markus Mock and an outside
chance of Brian Grant (if he's not our of town interviewing).

Susan


----- End Included Message -----


To: spin-comp@cs.washington.edu
Subject: practice talk
Date: Tue, 04 Jan 2000 10:42:43 PST
From: Brian Grant <grant@cs.washington.edu>

I'd like to try to give a practice of my job talk Thursday or Friday.
Please let me know if/when you'd be free.

--Brian

To: spin-comp@cs.washington.edu
Subject: Walid Taha: Wkshp Poll (Pls FWD)
Date: Wed, 05 Jan 2000 16:50:11 GMT
From: Craig Chambers <chambers@cs.washington.edu>



------- Forwarded Message

Return-Path: taha@venus.disi.unige.it 
Delivery-Date: Wed, 05 Jan 2000 15:15:35 GMT
Return-Path: taha@venus.disi.unige.it
Received: from june.cs.washington.edu (june.cs.washington.edu [128.95.1.4])
	by klamath.cs.washington.edu (8.9.3/8.9.3/0.3) with ESMTP id HAA22453
	for <chambers@klamath.cs.washington.edu>; Wed, 5 Jan 2000 07:15:32 -0800 (PST)
	(envelope-from taha@venus.disi.unige.it)
Received: from venus.disi.unige.it (taha@venus.disi.unige.it [130.251.61.100])
	by june.cs.washington.edu (8.9.3/8.9.3/0.3j) with SMTP id HAA09900
	for <chambers@cs.washington.edu>; Wed, 5 Jan 2000 07:15:31 -0800 (PST)
	(envelope-from taha@venus.disi.unige.it)
Received: (from taha@localhost) by venus.disi.unige.it (8.6.12/8.6.9) id QAA05049; Wed, 5 Jan 2000 16:15:26 +0100
Date: Wed, 5 Jan 2000 16:15:26 +0100 (MET)
From: Walid Taha <taha@venus.disi.unige.it>
To: Tim Sheard <sheard@cse.ogi.edu>, Frank Pfenning <fp@cse.cmu.edu>,
        Peter Lee <petel@cs.cmu.edu>,
        Dawson Engler <engler@leland.stanford.edu>,
        Suresh Jagannathan <suresh@research.nj.nec.com>,
        Peter Thiemann <thiemann@informatik.uni-freiburg.de>,
        Neil Jones <neil@diku.dk>, Flemming Nielson <fnielson@daimi.aau.dk>,
        Olivier Danvy <danvy@brics.dk>, Zino Benaissa <benaissa@cse.ogi.edu>,
        Rowan Davies <rowan@cs.cmu.edu>, Mark Leone <mleone@cs.indiana.edu>,
        Philip Wickline <wickline@cs.cmu.edu>, Robert Glueck <glueck@diku.dk>,
        Craig Chambers <chambers@cs.washington.edu>,
        Jon Walpole <walpole@cse.ogi.edu>,
        Todd Veldhuizen <veldhui@cs.indiana.edu>, Zhe Yang <zheyang@brics.dk>,
        Xavier Leroy <xavier.leroy@inria.fr>,
        Jon Riecke <riecke@bell-labs.com>, Don Batory <dsb@cs.utexas.edu>,
        John Hatcliff <hatcliff@cis.ksu.edu>
cc: taha@cs.chalmers.se, Eugenio Moggi <moggi@venus.disi.unige.it>,
        Cristiano Calcagno <calcagno@venus.disi.unige.it>
Subject: Wkshp Poll (Pls FWD)
Message-ID: <Pine.LNX.3.91.1000105160232.4360D-100000@venus>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII


Greetings,

This is a preliminary poll regarding a workshop.  Please replay, 
and kindly forward to anyone you think might be interested.  
I need your input by January 6th (!)

We're thinking of organizing a workship at ICFP this year with the theme:

	Semantics, Applications, and Implementation 
        of Run-Time Code Generation

The goal of the workshop is to provide forum for presenting and 
discussing new technical results of direct relevance to this area.

Dates:  ICFP/PLI will be Montreal, Canada, September 18-23, 2000.
        Workshop will be during the same period.

Question:  Would be interested a) participating, b) submitting
            work to the workshop?

Neither answers are binding, but accuracy would be very useful.  Results
are needed in order to formally propose the workshop.

Many thanks, and best regards,

Walid.

------- End of Forwarded Message


To: spin-comp@cs.washington.edu
Subject: practice talk Monday @ 3:30 in 422
Date: Thu, 06 Jan 2000 16:39:27 PST
From: Brian Grant <grant@cs.washington.edu>

However, I couldn't reserve the room past 4:30.  So, if we need more time
and get kicked out, maybe we can move into the hall or down to 114.  I'll
also look into other rooms.

--Brian

Date: Thu, 6 Jan 2000 18:44:58 -0800 (PST)
From: Susan Eggers <eggers@cs.washington.edu>
To: spin-comp@cs.washington.edu
Subject: are we interested?


----- Begin Included Message -----

From root@jacob.remcomp.fr Wed Jan  5 02:16:25 2000
Subject: Dynamic compilation from a debuggers perspective
To: eggers@cs.washington.edu
X-Mailer: ELM [version 2.5 PL0pre8]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Sender: root@remcomp.fr
X-Lines: 36
Status: RO

Madam,

I am Jacob Navia, the author of the lcc-win32 compiler system for windows.
I have developed a complete compilation chain, starting with the lcc
compiler, that I ported to windows, then an assembler, a linker, and a
debugger.

I am interested in dynamically generating code in the context of the debugger.
My objective would be to interpret C code from within the debugger, compiling
and dynamically linking the generated code in the fly, allocating a memory
chunk and setting the debuggee's EIP to it, running it, and showing the
results, if any.

This way users could dynamically correct bugs and continue the program instead
of stopping the debugger, recompiling, restarting.

This is the basic idea. I have the whole chain (from C source to the final
executable) so I can modify linker/assembler as needed.

Is this project interesting to you?

Would it be possible in principle to see if an adaptation of my toolchain
would yield an interesting tool under windows?

My toolchain can be downloaded (free of charge) from
http://www.cs.virginia.edu/~lcc-win32.

At that site you will find the documentation for the lcc-win32 project.

Thank you in advance for your attention

-- 
Jacob Navia	Logiciels/Informatique
41 rue Maurice Ravel			Tel 01 48.23.51.44
93430 Villetaneuse 			Fax 01 48.23.95.39
France


----- End Included Message -----


Date: Mon, 24 Jan 2000 08:03:53 -0800 (PST)
From: Susan Eggers <eggers@cs.washington.edu>
To: egs@cs.washington.edu, jonal@cs.washington.edu, chambers@cs.washington.edu,
Subject: PLDI

I actually don't know if the Calpa, dispatching and synchronization
papers got in.  If any did, there was only one (a little arithmetic
deduces this).  But the one could have belonged to another committee
member.  I think ours were all in the category of contenders and
discussable.

We just have to wait.
Susan

To: spin-comp@cs.washington.edu
Subject: dispatching paper didn't make it
Date: Thu, 27 Jan 2000 09:07:39 PST
From: Brian Grant <grant@cs.washington.edu>


------- Forwarded Message

Date: Thu, 27 Jan 2000 00:48:40 -0800
From: Monica Lam <lam@minnow.stanford.edu>
To: grant@cs.washington.edu
Subject: Your PLDI submission

Dear Brian Grant,

I regret to inform you that your paper

  Efficiently Dispatching to Run-time-specialized Code

was not accepted by the PLDI '00 program committee.  The competition
this year was extremely tough.  We received 173 abstracts, 33% more
than the number of submissions received last year!  In addition, there
are many quality submissions and it is simply not possible to include
all the papers that are publishable. 

We have enclosed below the reviews that we have collected on your
paper.  Hopefully, you will find the reviews useful for your future
work.

Sincerely, 
Monica Lam, Program Chair

Your reviews follow: 
*******************************************************

Paper Number: 111
Paper Title: Efficiently dispatching to run-time specialized code
Interest/Importance to PLDI: 5
Technical contribution of paper: 4
Novelty of the material in the paper: 5
Quality of presentation: 4
Confidence in your evaluation: 6
Recommended action for paper: 4


The paper compares several schemes for dispatching to code generated at
run-time with the intent of discovering their strengths and weaknesses.  While
the research has promise, this paper feels incomplete and falls short of
answering the questions the paper addresses.




The problem addressed by the study is an interesting one.  However, the
experimental results are not thorough enough to be conclusive.  Only two of
the schemes are fully implemented for the real benchmarks (HTL and IC) and the
microbenchmarks are not fully motivated.  The paper does not make a case for
whether or not the microbenchmarks sufficiently represent the behavior of real
programs.  More specific comments follow:

1. Table 3 contains execution time improvement only for 3 of the 5 schemes.
   The other two schemes: simple table lookup and polymorphic inline caches
   are very interesting and should also be in the table.  Particularly STL
   does very well in Figure 1 so it is worth seeing how well it does for the
   real benchmarks.
2. The numbers for InvC in Table 3 are optimistic since the current InvC
   implementation relies on the user to effectively disambiguate references to
   the key variables.  Any realistic implementation using a pointer analysis
   will do worse than InvC.  InvC is the best performing scheme in this table,
   but a realistic implementation of it may do less well.
3. Table 3 not contain whole program and dynamic region speedup data for InvC.
4. What is the size of the caches in PIC?  Does changing that affect its
   performance? What is the size of the hash table in HTL results?  How are
   conflicts handled?
5. Section "Key-value range" says: "The key-value range in figure 1 consisted
   of only two key values".  Does this mean when the key value alternates
   between two values in the experiments for Figure 1?  Is this realistic for
   keys to simply flip flop between two values in realistic programs?  Having
   only 2 key values favors PIC since both values are likely to be resident in
   the PIC cache.


*******************************************************

Paper Number: 111
Paper Title: Efficiently Dispatching to Run-Time-Specialized Code
Interest/Importance to PLDI: 8
Technical contribution of paper: 6
Novelty of the material in the paper: 6
Quality of presentation: 7
Confidence in your evaluation: 8
Recommended action for paper: 6.5


This paper evaluates several different schemes for dispatching to
one of several code segments selected at run time.  The evaluation is
done in the DyC infrastructure, since the cost of dispatching has
been shown to be an important component in the performance of
dynamic compilation systems.  The schemes are evaluated with respect
to DyC's characteristics for dynamic code generation, though the
characteristics are probably true for any staged compilation system
based on programmer-specified annotations.




Overall, I like your paper.  You have done an admirable job of
extending your analysis beyond your small set of "real" benchmarks and
annotated variables (see the bottom of page 10).  Still, I would have
liked to see a wider range of benchmarks and run-time generation
schemes, but I'm sure you would like this too.  I guess that I was
expecting more from your general title.  I was also concerned that
your technique of choice was potentially unsafe, and that it was made
safe by programmer inspection.  It would have been nice if you had the
alias analysis stuff done (see the bottom of page 7).

I have only a few specific comments.

The use of the term "caching" is somewhat confusing at the beginning
of the paper.  You use the term to refer to a specialization of the
dispatch code and to refer to the storing of the dynamically generated
code.  In particular, I first took the term "invalidation-based
caching" to mean that you were invalidating entries in the code cache.
Perhaps a few more words at the beginning of your paper would help.

Have you investigated how often the value of the key changed when it
was written?  I.e., invalidations occur only if the value of the key
changes and not just because the key was written.

I was confused by Figure 2 for a while until I found the phrase "while
holding the frequency of actual key-value changes constant ...."  I
suggest that you put something to this effect in the figure's caption.
Otherwise, your reader may spend time trying to figure out why "IC" in
Figure 1 doesn't match "IC" in Figure 2.


*******************************************************

Paper Number:  111
Paper Title:  Efficiently Dispatching to Run-Time-Specialized Code
Interest/Importance to PLDI:  6.0
Technical contribution of paper:  4.0
Novelty of the material in the paper:  4.0
Quality of presentation:  6.0
Confidence in your evaluation:  9.0
Recommended action for paper:  3.0


This paper examines the performance of several well-known techniques for
dispatching to runtime optimized code in the DyC dynamic compilation
system.  It examines how several factors such as key size and the
frequency of key change affect the performance of these techniques.  It
also demonstrates that efficient dispatching allows the dynamic
optimization of programs with small dynamic regions.  The performance of
three different dispatching techniques is demonstrated on a few
benchmarks and several small kernels.




While the results presented in your paper are interesting, they may
be more appropriately part of a larger work.  If you could present a
theoretical basis for determining an optimal dispatching
technique to use, or if you demonstrate a heuristic based approach that
is effective in selecting the technique, this would likely make a very nice
paper that would draw a great deal for the analysis you have done so far.
In addition, most results and conclusions in this work about how
different factors affect various dispatching techniques tended to seem
rather obvious.

One paper that you should definitely read that may helpful to you is
Daniel Connors' Computational Reuse paper from Micro-32.  While he
used a profile-driven compiler based approach to find regions of code
with a few inputs that take on only a few values, the algorithms presented
in that work could be used to effectively perform the annotation needed
by your runtime optimizing system.  In addition, his techniques could be
extended to provide the information needed to determine at compile-time for
each region which dispatching technique that might be the least expensive.
One drawback of his system is that his overall technique requires value
profiling, however, his algorithm for locating potential reuse
opportunities does not.  Also, if a programmer is unwilling to profile
their code, they likely may be unwilling to insert source-level
annotations as well.

One concern I have is that you never fully address the fundamental reason
why dispatching makes up such a large percentage of the overhead in your
system (78% of the overhead in dynamic compilation).  I assume that this
number is based only on the hash-table approach, and it would be
interesting to see how much this percentage overhead is decreased using
the other techniques.

Another area that should be addressed is how these applications were
compiled.  If the compiler did a poor job of constant folding,
your speedups will suffer for code that was properly optimized.  It would
be useful to know how much if any of the variables that are promoted
from dynamic to static are actually static at compile type.  In
addition, I assume that no profiling was done by the compiler.  Many
optimizing compilers can perform code specialization at compile-time
using value-profile information.  Comparison with such a technique would
be useful as compile-time specialization has virtually no dispatching
overhead.

The benchmarks that were chosen for the experiments were all very small.
It would be much more interesting to show numbers for all of the SPECint
applications, or at least for some other reasonable sized programs.  I
understand that your ability to do this is limited by the requirement
for source-level annotations, but better benchmarks would be much more
interesting.  The speedup results for the benchmarks were good, but it is
notable that for the two largest benchmarks the speedups are rather small.
Also, listing the size of the benchmarks in Table 2 in number of source
lines is probably not as good a metric as the number of instructions in
each program.


*******************************************************

Paper Number: 111
Paper Title: Efficiently Dispatching to Run-Time-Specialized Code
Interest/Importance to PLDI: 1
Technical contribution of paper: 3
Novelty of the material in the paper: 3
Quality of presentation: 8
Confidence in your evaluation: 9
Recommended action for paper: 2


This paper took several 'hashing' algorithms and their specialized cases
and performed efficiency analysis.  The basic premise is that the efficiency
of these algorithm affects the cost of run-time-specialization employed by
DyC.
Items of interest to dynamic dispatching in DyC such as frequency of change
in
key and number of keys are evaluated for these algorithms.




This is a well written evaluation paper, however without innovation.

The paper is divided distinctly into two parts, DyC and algorithm
evaluation.
Although the author links the efficiency factor into DyC, the evaluation
work done makes the two items unrelated.  This reviewers see no DyC
significance
in this paper.
1) The evaluation done is independent of the work in DyC.  The evaluation
can
be performed without Dyc.  This is supported by the fact that 1. the author
uses microbenchmarks to measure the efficiency of the algorithms through
varying the microbenchmark value ranges, and 2. the authors uses benchmarks
that have 1-2 constant points.  This may not be representative.  Some of the
findings could change.
2) In the reviewer's opionion, the authors did not mention and explain the
dynamic part of DyC.  When the actual run-time constants increases and
decreases, how does DyC changes the data operated by the hash algorithms.
This also loosens the bond between the evaluation and DyC.

As a recommandation, DyC should not be bothered with constant entry points
with
lots of variations.  DyC can place limit on the number of variants can
happen
per entry point/per program/per code size of variants.  Restricting the
number
of variants could also directly affect the findings.

Authors mentioned that the code examples for the various 'hashing' functions
will be included in the full paper, but it should be included in the draft.
Also, pseudo code for the actual implementation should be included as the
implementation is an important part of the evaluation.

If the authors are to use microbenchmarks for evaluation, more variants and
deeper understanding of the problem should be evaluated, as mentioned above.


*******************************************************

Paper Number: 111
Paper Title: Efficiently Dispatching to Run-Time-Specialized Code
Interest/Importance to PLDI: 7
Technical contribution of paper: 7
Novelty of the material in the paper: 6
Quality of presentation: 7.5
Confidence in your evaluation: 7
Recommended action for paper: 6.5


This paper focuses on code dispatch for run-time specialization.
Runtime specialization has the potential to greatly improve
code performance, but the dispatch cost represents an additional
overhead that prevents it from getting speedup as often as
one would like.  The authors run through key design decisions
and discuss their impact on dispatch cost.




The strength of this paper is its detailed evaluation
of a fairly focused problem.  Although it is somewhat
narrow (which is one reason why I didn't rate the paper
higher) it strikes me as an important enabler to making
dynamic compilation practical.

The key contribution of this paper is in unraveling
choices regarding keys and caching and determining
their performance costs.  This seems to be a very
useful high-impact research thrust.

One concern I had was related to the benchmark programs
chosen.  Several of the benchmarks were made smaller than
previously, in order to "highlight the use of short dynamic
regions".

A second methodological concern has to do with switching,
in Section 4.2, to a microbenchmark-based evaluation.  I
was left wondering how to gauge these results and determine
what they would look like if implemented within a full-fledged
system.

>From an English standpoint, I found the paper quite well-written.
I thought the intro did a very good job of establishing the
context of the problem.  And I thought that Section 4.3 did
a good job of tying together the experiments and conclusions
which could otherwise have been confusing to keep straight.


*******************************************************

Paper Number: 111
Paper Title:  Efficiently Dispatching to Run-Time-Specialized Code
Interest/Importance to PLDI: 5.0
Technical contribution of paper: 5.0
Novelty of the material in the paper: 5.0
Quality of presentation: 6.0
Confidence in your evaluation: 8.0
Recommended action for paper: 5.0


This paper briefly describes and evaluates a small collection of obvious
schemes for testing values and dispatching to run-time specialized code.
The findings are unexceptional, in that the efficient schemes from
virtual/multimethod dispatching are again proved efficient.




This seems like a very small result for a conference paper.  I could
understand why a systems implementer would like this information. However,
given that all the techniques are well-known and the outcome predictable,
this seems like a thesis chapter or a section in a journal article.

The algorithm descriptions in the paper could use further exposition, in the
form of sample code.




------- End of Forwarded Message



Date: Thu, 27 Jan 2000 09:53:57 -0800 (PST)
From: Markus Mock <mock@cs.washington.edu>
To: spin-comp@cs.washington.edu
Subject: Calpa submission didn't make it either

Extensive reviews, though, mainly pointing out the main weakness we were
aware of: lack of real apps. 


	-- Markus

---------- Forwarded message ----------
Date: Thu, 27 Jan 2000 00:48:40 -0800
From: Monica Lam <lam@minnow.stanford.edu>
To: mock@cs.washington.edu
Subject: Your PLDI submission

Dear Markus Mock,

I regret to inform you that your paper

  Calpa: A Tool for Automating Dynamic Compilation

was not accepted by the PLDI '00 program committee.  The competition
this year was extremely tough.  We received 173 abstracts, 33% more
than the number of submissions received last year!  In addition, there
are many quality submissions and it is simply not possible to include
all the papers that are publishable. 

We have enclosed below the reviews that we have collected on your
paper.  Hopefully, you will find the reviews useful for your future
work.

Sincerely, 
Monica Lam, Program Chair

Your reviews follow: 
*******************************************************

Paper Number: 113
Paper Title: Calpa: a tool for automating dynamic compilation
Interest/Importance to PLDI: 6
Technical contribution of paper: 5
Novelty of the material in the paper: 6
Quality of presentation: 6
Confidence in your evaluation: 7
Recommended action for paper: 5


The key contribution of this paper is that it describes the first system for
automatically generating annotations to enable dynamic compilation in a
traditional language (as opposed to languages such as Self where some forms of
continuous profiling are combined with with run-time optimizations
automatically).  While the framework described in the paper seems reasonable,
the effectiveness of the framework is not demonstrated fully in the paper,
thus limiting the potential impact of this paper.




The system described in the paper sounds like a good way to guide dynamic
compilation.  However, the paper feels premature and has insufficient
experimentation to justify the design of the framework.  More specific
comments:

1. To do the experiments in the paper, the authors manually edited profile
   logs to effectively inject pointer alias information into it.  The quality
   of the information you get out of Calpa depends highly on the quality of
   alias information that is available to Calpa.  If very weak information is
   available, then it will appear to Calpa that there are many assignment and
   uses of a variable when in reality there are very few.  This weakness will
   cause Calpa to make different decisions w.r.t. dynamic compilation than if
   Calpa had perfect pointer information.  Thus, the results at the end of the
   paper may be very different if you had used a real pointer analysis instead
   of a manual pointer analysis.  Given that you are planning to use
   Steensgaard's pointer analysis and Hendren's connection analysis, which are
   both quite weak, I doubt that the automatically generated pointer
   information will approach your manually inserted pointer information.
2. The experimental results section states that the same program inputs are
   used for profiling and final performance runs.  This is clearly not
   realistic.
3. The code size numbers for dinero use "." instead of ","
4. Where are the numbers for dinero in Table 1?
5. What does the "top 3 functions" and "top 10 functions" mean in Table 1?
6. What exactly does dot-product do which causes its vectors to be "constant"?
   Does it compute the same dot product multiple times in a loop?
7. The paper presents dynamic compilation speedup numbers only for the small
   kernel benchmarks.  Just because Calpa does a superset of annotations over
   manual annotations it does not mean that it leads to any better performance
   at run-time.  If the profiling and actual runs use different inputs then
   the additional annotations by Calpa may even reduce performance if in the
   profiling run some key variable appeared to be "static" whereas in reality
   it changes all the time.
8. Is Calpa practical in the presence of dynamic linking and loading which
   seems to be common in many of today's programs?


*******************************************************

Paper Number: 113
Paper Title: Calpa: A Tool for Automating Dynamic Compilation
Interest/Importance to PLDI: 4
Technical contribution of paper: 4
Novelty of the material in the paper: 6
Quality of presentation: 6
Confidence in your evaluation: 7
Recommended action for paper: 4.5


This paper describes the beginnings of a system that automates the
task of generating annotations for DyC, a system for dynamic
compilation.  This is an extremely important problem in the success
of dynamic compilation.




I feel that your paper is a bit premature.  As far as I can tell, you
have directly automated the manual process that you used to use.  This
is engineering, and without any new insights, I'm just not that
interested in reading about the system.

Furthermore, you have quite a bit of the automation process left to
do, as described in the middle of page 5 and the 2nd bullet at the top
of page 11.  For what you've done, it sounds like you've done a lot of
tuning for the small benchmarks tested in your experiments, and yet
you haven't provided any data showing how good your estimation process
is compared to the performance actually achieved.  How good will it be
for large applications.  Is this approach practical for large
applications given the instrumentation and off-line analysis costs?
I'm worried, and you haven't directly addressed this issue.  Lastly,
one of your small benchmarks (romberg) generates a variety set that
is not a small fraction of the theoretical maximum.  What happens if
an interesting large application shows the same characteristic?

Other small comments:

On page 5, Section 3.2, 1st paragraph:  What do you mean exactly by
monitoring and summarizing "variable definitions, and variable use"?

Bullet at the top of page 11: Why did the human miss the fact that the
vector v was also constant.  Is there an interesting observation here?


*******************************************************

Paper Number: 113
Paper Title: Calpa: A Tool for Automating Dynamic Compilation
Interest/Importance to PLDI: 8
Technical contribution of paper: 7
Novelty of the material in the paper: 6
Quality of presentation: 5
Confidence in your evaluation: 8
Recommended action for paper: 7


The paper presents an automated approach to dynamic compilation.  The
main contribution of the paper is the automation of the authors prior
DyC compilation system.  In prior research, the DyC system relied on
user annotations to guide the dynamic compilation.  In this paper, the
approach is fully automated using profiling to find the variables and
code regions that should be dynamically compiled/optimized at
run-time.




The paper is a much needed atomization of the authors prior work, and
would make a great PLDI paper.  The only concern is the status of the
system, since results are only reported for 2 programs, and the
authors plan to have results for more programs in the final version of
the paper.

The extended abstract talks at a high level about the approach, but
not about too much of the details.  I know this is an abstract, so the
final version should contain much more of the details.  In any case,
it would have made it much easier to follow the paper if there had
been 2 figures to help understand how the system works.  One figure
showing in detail each of the stages of the static compilation
(including the profiling, analysis, and code generation).  The other
figure showing the run-time system, the cache lookups, etc, code cache
management and how all of that interacts.

In section 3.3, how are the use sets tied together with the use of the
profiling information during the analysis?  This is not clear.  Do you
require that all the variables in a popular use set have
quasi-invariant behavior in order for the code section to be
considered for optimization?

Please expand more on how you choose the code region for dynamic
compilation, and how you use the profiling information to determine
this, along with the cost/benefit analysis and other details left out
of the abstract.

In the specialization section, Calpa creates a dynamic instance of the
routine for each value found.  Why is that?  Why not just create
specialized code for the most frequent values.  You could then execute
the general original piece of code for the non frequent values.  For
example, you could potentially have a variable that has a 100 values,
but 1 value occurs 99% of the time.  You could dynamically find this
value, by just monitoring the most frequent value the first few times
the variable is executed.


*******************************************************

Paper Number: 113
Paper Title: Calpa: A Tool for Automating Dynamic Compilation
Interest/Importance to PLDI: 5.0
Technical contribution of paper: 5.5
Novelty of the material in the paper: 6.0
Quality of presentation: 7.0
Confidence in your evaluation: 9.0
Recommended action for paper: 4.5


Declarative dynamic compilation systems require that the optimization
opportunities be identified at compile time.  Once these opportunities are
identified, the compiler generates code in the application that will
generate specialized code at runtime for the particular opportunity.  The
compiler generates purely static code for the remainder of the program.
This work utilizes a combination of profile information and program
analysis to automatically detect and identify optimization opportunities.
Results show that this is significantly faster and often more accurate
than requiring the programmer to identify the opportunities by hand.




At submission time, the authors had not completed the implementation
of the invalidation point detection.  My concern is two fold.  1) Due
to potentially aliased memory references, the number of invalidation
points could be very large, frequently invalidating translations (even
when not necessary).  2) The analysis must be very accurate as missed
assignments that should cause invalidations could lead to execution of
invalid translations.  This is a very important aspect to the accuracy
of the work and must be addressed in the final paper.

For PLDI, I think that a more theoretical discussion of what the
profile information and the pointer analysis each add to the detection
of quasi-static variables.  How could reliance on profile information
be lessened?

Would a genetic algorithm be useful for selecting the best combination of
variables for the best results?

The authors computation of cycles saved along the critical path may
not be accurate as removal of instructions from the critical path
might cause a different path to become the critical path.  As this is
only used for an estimate of cycle saved, it is probably acceptable,
but may result in poor predictions.  I'd also like to see a more
mathematical treatment of the various costs and benefits.

One of my growing concerns is the selection of applications used in this
study and other DyC works.  After several years of work on the DyC
system, I would like to see results for larger programs.  m88ksim,
in my perspective is not a very large program compared to many real
applications in industry.  Actually, the tool described in this work
will better allow further research by no longer requiring the long
process of hand annotating programs.  Note, though, that the original
authors might very well be able to annotate their programs much faster
and more efficiently than the DyC authors can.

There is a strong similarity between this work and developments in the
computation reused domain.  Connors in Micro-32 presented initial work
on compiler-directed computation reuse.  In his work, he detects
regions of code that consist of quasi-static variables, then is able
to look up the result of the entire computation in a hardware buffer
(the table is built up at runtime by executing the code once for each
combination of the static variables).  While they are different
approaches to similar problems, there are similarities in your region
selection and invalidation point determination.  I suggest that you
look at his work.

I'd like to see the size of the translations stored in the code cache for
each of the benchmarks.

While the paper organization is fine, some sections seem repetitive.  The
overview section seems to overlap too much with the intro and the
individual sections.  Some the sections are also hard to follow,
such as the Caching cost section.  The policies are not clearly defined
nor are requirements of using such policies discussed.  Because of this,
I am not as confident in Calpa's ability to guarantee correct selection of
the policy.

I generally have concern about profile-driven compile-time selection
of runtime optimization opportunities.  The problems associated with
profiling have been frequently discussed as of late.  Basing runtime
optimizations decisions on profile information seems to partially
defeat the purpose of optimizing at runtime.  The approach I see here
suggests that the regions of code used do not vary from run to run
(input to input) but that the values of the quasi-static variables do.
What happens when running perl with the jumble input after profiling
on primes?  I would suggest that runtime compilation/optimization
should be able to improve performance in this situation as well.
However, this work seems to indicate a reasonable first step toward
automating the analysis in its specified domain.

I am recommending this paper as a marginal reject.  Specifically, I
feel that the work isn't complete enough to convince me that it will
be ready, stable, and accurate by publication time.  While the system
described is useful for the DyC system, its general technical value
(over just being a tool) may not be highly interesting to the general
PLDI audience.  However, a more general theoretical discussion of how to
automatically detect and analyze quasi-static variables may be.


*******************************************************

Paper Number:113
Paper Title:Calpa: A Tool for Automating Dynamic Compilation
Interest/Importance to PLDI: 8.5
Technical contribution of paper: 7.0
Novelty of the material in the paper: 6.0
Quality of presentation:7.5
Confidence in your evaluation:8.0
Recommended action for paper:8.0

The important contribution of this paper lies in its demonstration of the
importance of using information collected at runtime to drive dynamic
optimization. The Calpa tool  is intended to complement the DyC Declarative
Compilation system; the paper not only displays this admirably, but moreover
I think it shows that such systems are barely feasible without such a tool.
Apparently the motivation such a tool was the tedious and time-consuming
process required to produce manual annotations; the results however
show that the automated process not only found more annotations fairly quickly,
but increased the speedup of the affected programs. Unfortunately the paper
does not quantify the speedup.
The major weakness of the contribution is that it does not address the issue
of the large potential overhead of such a system in an enviroment running
very large applications, where often it is even too much trouble to compile
programs with optimization.



1.This paper would benefit greatly from the addition of a couple of diagrams to
show the construction of the Calpa tool and where it fits with the DyC system.

2.In the introduction and conclusion the paper refers to DyC as a declarative
compilation system, but in the body of the text the adjective "declarative "
is dropped. This leads to some misleading, if not incorrect generic statements
such as that in the opening sentence of  the second paragraph of the
introduction. This sentence would be more precise if it read
"Today's Declarative dynamic compilation systems choose run-time constants
manually". There are a few other such instances throughout the paper.

3. The writer of the paper employs a somewhat irksome style of frequently
enclosing  comments in parentheses which could be better expressed with a
little more attention to sentence construction. The occurrences are numerous,
but the first and most offensive one occurs in the abstract.
4. If all the extra information which is promised actually materializes in the
full paper, I suspect it will be somehat lengthy and in need of some judicious
pruning.


*******************************************************

Paper Number: 113
Paper Title:  Calpa: A Tool for Automating Dynamic Compilation
Interest/Importance to PLDI: 7.0
Technical contribution of paper: 7.0
Novelty of the material in the paper: 7.0
Quality of presentation: 7.0
Confidence in your evaluation: 8.0
Recommended action for paper: 7.0


This paper describes a tool for profiling a program and analyzing the
resulting trace log to determine where to insert program annotations to
control the authors' dynamic compilation system.  Previously, these
annotations were inserted by hand.  This system equals or betters
human-produced annotations, at a large cost of computer time.  However, the
trade-off seems reasonable, since annotation is a one-shot process.




This paper would have benefited from a better description of the DyC
compilation process, so that a reader who does not know the details of your
previous work could understand what you were modeling.  Moreover, I would
like to know how specific your techniques are to that system, or whether the
same approach or system would work with the other dynamic compilation tools.
In general, the description of the system is unnecessarily vague.  I would
have preferred less motivation, and more details.

I would also like to know how well this system works on programs that were
not previously annotated by hand.  In particular, does it find any useful
(or
spurious?) annotations for programs that are ill-suited to dynamic
compilation?

Can you see anyway to reduce the cost of this process?  Although 2-3 orders
of magnitude is reasonable for programs that run for a fraction of second,
those are not the programs that anyone spends time optimizing.  I can't see
using this system for long running (hours-weeks) computations.  Before you
claim that a programmer could use a smaller input, you need to demonstrate
that the discovered optimizations are insensitive to program input.

Minor point: Table 1 lists log files in the Kb-Mb range, but the text below
talks about Gbs.  No where in the paper is the summarization process
described, so I can't tell whether anything is lost in it.


*******************************************************

Paper Number: 113
Paper Title:  Calpa: A Tool for Automating Dynamic Compilation
Interest/Importance to PLDI:  8
Technical contribution of paper: 6
Novelty of the material in the paper: 5
Quality of presentation: 6
Confidence in your evaluation: 8
Recommended action for paper:        5


The paper presents a system, Calpa, intended to use profiling information
to automatically detect when runtime code generation can be applied to
C programs.  The problem is a topical one, and the system, if built,
would be a good PLDI paper.

However, as it stands, the paper is too premature for publication.
The most important lack is that the authors have not implemented the
hardest part of this whole puzzle: detecting when ``quasi-constants''
change value.  In the context of C (and its exciting aliasing landscape)
this is a non-trivial problem, and the promise that they had solved it
made me eagerly skim through the paper.  Unfortunately, as the authors
note around page 5, they have not implemented this detection (though
they promise to in the final paper).  Thus, the system is unsound, since
it has no way to detect when the invariants used to specialize code
have been violated.  Without needing to solve this problem, automatic
annotation is relatively straightforward.

A second problem is that the technique seems very sensitive to
``over-specialization.''  I'd like to see convincing evidence it will work
on real programs whose usage differs from the profiling runs.  A concrete
effect of this problem is that some of their experimental results are
a little ridiculous.  For example, on their binary search benchmark
(presumably taken from Poletto et al's uncited `C work) their
profiling run only does lookups of three distinct keys and, as a result,
the routine gets specialized to only doing lookups of three values.
They claim this is a feature; I'm more inclined to believe it is
a bug.  A similar problem is their dotproduct benchmark (presumably
take from Engler et al's uncited "dcg" work) takes both vectors used
as quasi-constants.  This makes no sense in any setting other than
a benchmark.

If these two problems were fixed, I'd recommend this paper for
publication.  As it stands, however, it's is only a potentially cool
paper, rather than an actually cool one.




I'd tone down the spin, and be more forthcoming about what the system
actually does rather than what it could (possibly) do.  It was very
irritating to hit the qualifiers on page 5 and realize that a good chunk
of the present tense prose describing the system should have actually
been written in a future tense.

On a more technical note, the current profiling scheme seems really heavy
weight.  I'd be interested in whether a more ``pc-sampling'' approach
could be used to cut down the time/size of the logs.  (For example,
by identifying hot-spots and, through snapshots, identifying good
quasi-constant candidates.)  Also, is static analysis totally hopeless?
Or can it be used to identify plausible loop- and recursion-invariants?

I believe there has been a fair amount of recent work in a similar area
(e.g., Mike Smith's perpetually adapting binary work).  It might be
worthwhile updating the related work section.




Date: Wed, 2 Feb 2000 19:16:13 -0800 (PST)
From: Susan Eggers <eggers@cs.washington.edu>
To: spin-comp@cs.washington.edu, levy@cs.washington.edu,
Subject: has anyone been using my machine

like crazy the past few days?

Date: Thu, 3 Feb 2000 09:42:04 -0800
From: Joshua Redstone <redstone@cs.washington.edu>
To: Susan Eggers <eggers@cs.washington.edu>
cc: spin-comp@cs.washington.edu, levy@cs.washington.edu,
Subject: Re: has anyone been using my machine

I've been running simulations for the past few days, but I don't 
think they should use the drives mounted on your boxes (/projects/smt).

josh

On Wed, 2 Feb 2000, Susan Eggers wrote:

> like crazy the past few days?
> 


Date: Thu, 3 Feb 2000 13:27:20 -0800 (PST)
From: Susan Eggers <eggers@cs.washington.edu>
To: spin-comp@cs.washington.edu, levy@cs.washington.edu,
Subject: affiliats

We need to begin preparing for our affiliates talks.  The next
time I see you, let's pin ourselves down.  Can you come to the
meeting with a talk outline?

Matthai, this will mean we'll need to schedule a special time.
How about tomorrow afternoon?

Susan

Date: Mon, 7 Feb 2000 18:36:16 -0800 (PST)
From: Susan Eggers <eggers@cs.washington.edu>
To: spin-comp@cs.washington.edu, levy@cs.washington.edu,
Subject: do we want these?

----------
X-Sun-Data-Type: text
X-Sun-Data-Description: text
X-Sun-Data-Name: text
X-Sun-Charset: us-ascii
X-Sun-Content-Lines: 88


----- Begin Included Message -----

From lazowska@cs.washington.edu Mon Feb  7 17:06:40 2000
To: faculty <faculty@cs.washington.edu>
Subject: Sun development tools, in case anyone's interested
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF71D0.BE49545A"
X-Lines: 145
Status: RO
Content-Length: 7491

 
-----Original Message-----
From: Jessie Brooks [mailto:jbrooks@engr.washington.edu]
Sent: Monday, February 07, 2000 4:44 PM
To: lazowska@cs.washington.edu; chizeck@ee.washington.edu
Cc: rawson@engr.washington.edu; mdietz@u.washington.edu
Subject: Sun Microsystems


Ed and Howard:

My contact at Sun Microsystems forwarded this information to me and asked me
to distribute it. If you have previously received the information, please
disregard it.

*** SUN'S .COM DEVELOPMENT TOOLS NOW FREE TO GLOBAL EDUCATION COMMUNITY ***
Sun announces that its Forte product line of software development and 
integration tools are now available free to qualified educators, students
and 
educational institutions. Sun is a leading provider of open network 
computing solutions to libraries and institutions around the world, powering

academic research and high performance computing systems, campus 
administration, digital libraries, and student instruction systems. In 
addition, Sun is committed to connecting the world to the Internet,
beginning 
with primary and secondary schools and extending to all levels of higher 
education. For more information, GOTO: 
http://www.sun.com/smi/Press/sunflash/2000-02/sunflash.20000202.5.html
<http://www.sun.com/smi/Press/sunflash/2000-02/sunflash.20000202.5.html> 



*** SUN MAKES THE GRADE WITH LOWER DESKTOP COMPUTING PRICES FOR EDUCATION
***
Sun announces a new educational pricing schedule for select products in its 
desktop computing line. The new, lower prices will make it easier for 
schools, colleges, and universities to make use of Sun's industry-leading 
technology to enhance the educational opportunities provided to students at 
all levels and upgrade campus administrative capabilities. Included in the 
new educational pricing schedule are Sun's Ultra(TM) 5 and Ultra 10 
workstations. Special education pricing positions Sun to aggressively pursue

the growing number of performance-hungry users who want the best of both 
worlds. For more information, GOTO: 
http://www.sun.com/smi/Press/sunflash/2000-02/sunflash.20000202.4.html
<http://www.sun.com/smi/Press/sunflash/2000-02/sunflash.20000202.4.html> 

*** SUN OFFERS NEW ACADEMIC SERVICES ON THE WEB ***
Sun announces new academic services that allow students and professors to 
educate themselves about the latest Sun technologies. These new services are

available to selected colleges and universities through the Sun Web Learning

Center. With the new services, students in academic institutions can take 
courses on a wide range of topics and gain an understanding of Sun dot-com 
technologies and their applications. The Sun Web Learning Center provides 
quick and easy access to Sun's interactive information technology courseware

via the Internet and offers Web-based courses that are platform independent,

delivered through your web browser, and can be taken in sections. 
For more information, GOTO: 
http://www.sun.com/smi/Press/sunflash/2000-02/sunflash.20000202.10.
<http://www.sun.com/smi/Press/sunflash/2000-02/sunflash.20000202.10.html>
html
<http://www.sun.com/smi/Press/sunflash/2000-02/sunflash.20000202.10.html> 

Thanks,
Jessie



----- End Included Message -----

----------
X-Sun-Data-Type: html
X-Sun-Content-Length: 4057
X-Sun-Charset: us-ascii
X-Sun-Content-Lines: 59

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">


<META content="MSHTML 5.00.2919.6307" name=GENERATOR></HEAD>
<BODY>
<DIV>&nbsp;</DIV>
<DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma 
size=2>-----Original Message-----<BR><B>From:</B> Jessie Brooks 
[mailto:jbrooks@engr.washington.edu]<BR><B>Sent:</B> Monday, February 07, 2000 
4:44 PM<BR><B>To:</B> lazowska@cs.washington.edu; 
chizeck@ee.washington.edu<BR><B>Cc:</B> rawson@engr.washington.edu; 
mdietz@u.washington.edu<BR><B>Subject:</B> Sun 
Microsystems<BR><BR></FONT></DIV>Ed and Howard:<BR><BR>My contact at Sun 
Microsystems forwarded this information to me and asked me to distribute it. If 
you have previously received the information, please disregard it.<BR><BR><FONT 
size=3>*** SUN'S .COM DEVELOPMENT TOOLS NOW FREE TO GLOBAL EDUCATION COMMUNITY 
***<BR>Sun announces that its Forte product line of software development and 
<BR>integration tools are now available free to qualified educators, students 
and <BR>educational institutions. Sun is a leading provider of open network 
<BR>computing solutions to libraries and institutions around the world, powering 
<BR>academic research and high performance computing systems, campus 
<BR>administration, digital libraries, and student instruction systems. In 
<BR>addition, Sun is committed to connecting the world to the Internet, 
beginning <BR>with primary and secondary schools and extending to all levels of 
higher <BR>education. For more information, GOTO: <BR></FONT><FONT color=#0000ff 
size=3><U><A 
href="http://www.sun.com/smi/Press/sunflash/2000-02/sunflash.20000202.5.html" 
eudora="autourl">http://www.sun.com/smi/Press/sunflash/2000-02/sunflash.20000202.5.html<BR><BR><BR><BR></A></FONT></U><FONT 
size=3>*** SUN MAKES THE GRADE WITH LOWER DESKTOP COMPUTING PRICES FOR EDUCATION 
***<BR>Sun announces a new educational pricing schedule for select products in 
its <BR>desktop computing line. The new, lower prices will make it easier for 
<BR>schools, colleges, and universities to make use of Sun's industry-leading 
<BR>technology to enhance the educational opportunities provided to students at 
<BR>all levels and upgrade campus administrative capabilities. Included in the 
<BR>new educational pricing schedule are Sun's Ultra(TM) 5 and Ultra 10 
<BR>workstations. Special education pricing positions Sun to aggressively pursue 
<BR>the growing number of performance-hungry users who want the best of both 
<BR>worlds. For more information, GOTO: <BR></FONT><FONT color=#0000ff 
size=3><U><A 
href="http://www.sun.com/smi/Press/sunflash/2000-02/sunflash.20000202.4.html" 
eudora="autourl">http://www.sun.com/smi/Press/sunflash/2000-02/sunflash.20000202.4.html<BR><BR></A></FONT></U><FONT 
size=3>*** SUN OFFERS NEW ACADEMIC SERVICES ON THE WEB ***<BR>Sun announces new 
academic services that allow students and professors to <BR>educate themselves 
about the latest Sun technologies. These new services are <BR>available to 
selected colleges and universities through the Sun Web Learning <BR>Center. With 
the new services, students in academic institutions can take <BR>courses on a 
wide range of topics and gain an understanding of Sun dot-com <BR>technologies 
and their applications. The Sun Web Learning Center provides <BR>quick and easy 
access to Sun's interactive information technology courseware <BR>via the 
Internet and offers Web-based courses that are platform independent, 
<BR>delivered through your web browser, and can be taken in sections. <BR>For 
more information, GOTO: <BR></FONT><FONT color=#0000ff size=3><U><A 
href="http://www.sun.com/smi/Press/sunflash/2000-02/sunflash.20000202.10.html" 
eudora="autourl">http://www.sun.com/smi/Press/sunflash/2000-02/sunflash.20000202.10.</A><A 
href="http://www.sun.com/smi/Press/sunflash/2000-02/sunflash.20000202.10.html" 
eudora="autourl">html<BR><BR></A></FONT></U><FONT 
size=3>Thanks,<BR>Jessie<BR><BR></FONT></BODY></HTML>

Date: Tue, 22 Feb 2000 17:03:20 -0800 (PST)
From: Susan Eggers <eggers@cs.washington.edu>
To: cse590k@cs.washington.edu, spin-comp@cs.washington.edu


----- Begin Included Message -----

From vass@cs.washington.edu Tue Feb 22 13:55:00 2000
X-Authentication-Warning: maelstrom.cs.washington.edu: vass owned process doing -bs
X-Sender: vass@maelstrom.cs.washington.edu
To: Susan Eggers <eggers@cs.washington.edu>
Subject: Manuvir Das's guest lecture on ptr analyses
MIME-Version: 1.0
X-Lines: 18
Status: RO

Susan,

Manuvir Das, from Jim Larus's group, is going to give a CSE 501 lecture on
pointer analyses.  While it will mostly be an overview of various
approaches, he will also mention his work that will appear in the upcoming
PLDI.

As he doesn't mind other visitors at his lecture, maybe you can forward
this message to the DyC people and whoever else might be interested
(supposedly not the entire department, though).

Where:  EE1 042
When:  Wed 2/23 (tomorrow)
       10-11:20am

Thanks!
Vass



----- End Included Message -----


Date: Mon, 6 Mar 2000 18:16:02 -0800 (PST)
From: Susan Eggers <eggers@cs.washington.edu>
To: spin-comp@cs.washington.edu
Subject: I forget who does this


but thanks for doing it again.

Susan

----- Begin Included Message -----

From dcpi@yquarry.zk3.dec.com Mon Mar  6 17:57:43 2000
To: Alexandre.Farcy@prism.uvsq.fr, Auderset@linkvest.ch, Ben.DuBois@Sun.COM,
        Gregory.Watts@prism.uvsq.fr, Humphrey.Clerx@eurocontrol.be,
        J.Byrne@rlmsystems.com.au, JacksBN@zaphod.millsaps.edu,
        Joel.RACIQUOT@grenoble.sema.fr, Marc.Shapiro@inria.fr,
        Mark.Kiley@celera.com, Markus.Kowarschik@math.uni-augsburg.de,
        P.Leggett@gre.ac.uk, Scooter@gene.com, acs@r2tech.com, al.kidd@ps.net,
        anwar+dcpi@cs.stanford.edu, argon@mcs.com, bcarnes@llnl.gov,
        bchen@eecs.harvard.edu, benardi@maltanet.net,
        bershad@cs.washington.edu, bleeker@cs.utah.edu, bmeek@flycast.com,
        c_tantignone@sonda.cl, carlosm@bohemia.cs.colorado.edu,
        cavazos@cs.umass.edu, chee-seng.chan@citicorp.com,
        ckd@genome.wi.mit.edu, crabb2@llnl.gov, craig@aland.bbn.com,
        curtis@av.com, cxzhang@deas.harvard.edu, d.coote@rlmsystems.com.au,
        dav@mas.eurocontrol.be, davidopp@cs.berkeley.edu,
        diwan@cs.stanford.edu, dlarsen@i2.com, dnag@cup.hp.com,
        dwagner@amazon.com, edjlali@pvm5.univ-lyon1.fr,
        eggers@cs.washington.edu, engler@lcs.mit.edu, ew@deccc40.wdf.sap-ag.de,
        gdt@bbn.com, genco@erols.com, gideony@microsoft.com,
        gliss@edv.mpi-stuttgart.mpg.de, gregei@microsoft.com,
        grunwald@foobar.cs.colorado.edu, gyllen@llnl.gov, haydin@ece.neu.edu,
        hector@cs.stanford.edu, hosking@cs.purdue.edu, hrobitaille@encore.fr,
        hudson@aol.net, ingham@rincon.com, jathorp@gchq.demon.co.uk,
        jathorp@servalan.org, jchapin@cs.stanford.edu, jef@bhe.com,
        jennifer@vmware.com, jharm@llnl.gov, jkennedy@us.oracle.com,
        jlo@cs.washington.edu, joel@aol.net, johndetr@microsoft.com,
        jpatteeu@ford.com, kaashoek@lcs.mit.edu, kab@plaza.ds.adp.com,
        kamijo@suri.co.jp, khj@cs.appstate.edu, kmulcahy@desperado.CV.COM,
        knmeneze@eos.ncsu.edu, kschu@fnal.gov, kstanley@genome.wi.mit.edu,
        lam@cs.stanford.edu, liskov@lcs.mit.edu, maraz@ics.forth.gr,
        mario.fortier@domtar.com, mark.vandevoorde@av.com,
        marolpa@mail.northgrum.com, matthai@cs.washington.edu,
        mckinley@cs.umass.edu, mendel@cs.stanford.edu,
        merz@telematik.informatik.uni-karlsruhe.de, mfechne@gwdg.de,
        mitchell@cs.ucsd.edu, moss@cs.umass.edu,
        mugur.abulius@vz.cit.alcatel.fr, napo@ellebore.saclay.cea.fr,
        narayan@soochak.ncst.ernet.in, ohad.imer@optimark.com,
        otraub@eecs.harvard.edu, petdr@cs.mu.oz.au, peter.braack@sycor.de,
        petermanc@geon.com, rabbott@us.oracle.com, reint@sys.sol.no,
        rgh@wnt.sas.com, richdr@microsoft.com, riedel+@cmu.edu, rrosen@arl.mil,
        sbainwoh@crosskeys.com, sbk@cray.com, scott@cs.rochester.edu,
        sdawson@llnl.gov, singhai@cs.umass.edu, slg@sci.org,
        smaoz@us.oracle.com, stoclet@ipgp.jussieu.fr, tammo+@cmu.edu,
        vaningen@microsoft.com, vgokhale@us.oracle.com, vhammer@csi.com,
        vincent.hammer@alpha-processor.com, wbattist@us.oracle.com,
        weissc@in.tum.de, whsieh@cs.washington.edu,
        zawada@buckeye.cb.lucent.com, zhangapache@263.net,
        zhwang@das.harvard.edu, zieglerr@novachem.com, zosel@llnl.gov
Subject: Announcing DCPI v3.9.2.2
Content-Length: 6388
X-Lines: 174
Status: RO

Greetings!

We are pleased to announce the release of a new DCPI kit:

	DCPI-V3.9.2.2

This kit runs on v4.0d, v4.0e, v4.0f, and v5.0 operating systems.
Versions of Tru64 Unix before v4.0d are not supported.

Many of the recipients of this message have previously received DCPI
kit announcements from the original developers of DCPI at SRC. Note
that this and future releases of DCPI kits will be made by the Compaq
Tru64 Unix group.

Although the old DCPI pages hosted by SRC still exist, they are not
being updated or maintained. Please bookmark the following new page:

	http://www.unix.digital.com/dcpi

Feedback, questions, and problem reports should be directed to the
following mail address:

	dcpi@zk3.dec.com

Please include the output of "dcpiversion" and "psrinfo -v" with all
problem reports. Please also include the problematic command or
commands along with sample output.

Sincerely,

The DCPI Team

=========================================================================

DCPI-V3.9.2.2 Release Notes

Changes since release V3.8:

This is the first release by the Tru64 Unix group. The INSTALL process
is somewhat different, but all changes should be transparent to the
user. Please note that patch kit #4 is now required for DCPI on v4.0d
systems and patch kit #1 is now required for DCPI on v4.0e systems. We
will not be shipping and installing variants of /sbin/loader for these
systems.

There are two major additions: value profiling and upcall
handlers.

Dcpid now has builtin support for value profiling, which
collects data by periodically interpreting instructions and
saving, for each instruction, either its common result
values (dcpid -vprof) or the PCs of instructions that might
cause a replay trap on EV6 (dcpid -vreplay).

The two examples above, -vprof and -vreplay, are hardwired
into dcpid. However, DCPI's value-profiling support (see
man dcpivprofiler) also allows you to specify what values to
capture, how to process those values before merging them
into the profile files, and how to format the values for
printing. A value profiler is a dynamically loadable shared
library written by the user. It encapsulates the code to
perform all user-specified processing.

Two value profilers are included in the DCPI distribution:
vp-classic.so collects the same information as the "classic
value profiling" hardwired into dcpid (-vprof), and
vp-addr.so collects the effective addresses of memory
operands in load and store instructions.

The second major addition is experimental support for
performing user-level upcalls that deliver profiling
interrupts directly to user-level handlers in profiled
applications (see man dcpiupcalls). Kernel support for
upcalls is automatically included with the DCPI driver
kernel module. A preliminary shared library named
libuvprof.so that performs limited user-level value
profiling is also included with the DCPI release. Support
for upcalls is not complete and has not been extensively
tested. It works on simple programs, but fails, e.g., for
programs that use exceptions in signal handlers. See the
man page for many CAVEATS.

There were some minor changes: the default per-cpu hash
table size was doubled to 512KB to reduce overhead when
collecting profile-me data, and the dcpid man page
now includes 21264a (EV67) aggregate events.

In the release notes for V3.8, we neglected to report that
dcpid creates a "fake" PALcode image file (suitable for use
with dcpilist, dcpiprof, etc.) by reading memory. The
PALcode image is stored in the profile directory. The
disassembly of PALcode-specfic instructions is currently
very limited.

Changes since release V3.4:

- Supports ProfileMe counters on EV67 (Alpha 21264a) cpus!
  (See "man dcpiprofileme" and "man dcpid")

- Dcpiprof and dcpilist require "-help" to list descriptions of their
  many flags.

- Dcpid's command syntax for selecting events has changed (see man dcpid).
  The new syntax supports multiplexing of profile-me modes with
  aggregate (i.e., non-profileme) modes.

- A new tool, dcpitopcounts, lists instructions with the highest event
  counts (see man dcpitopcounts).

- Dcpid supports a new -nice option to adjust its scheduling priority,
  and a new -gc option to automatically delete old epochs.

- Support for Tru64 V4.0c and earlier has been dropped.  Use DCPI-V3.4
  for V4.0 through V4.0c.

Known problems:

- When collecting data using multiple "-slot"s, each slot must have at
  least one event that occurs at least every 2^30 cycles, e.g.,
  retires, cycles, issues, or profileme mode.  Dcpid does not
  check this requirement

<pre>
Changes since release V2.12:

- Pcount driver is dynamically loadable.

- Dcpid loads pcount at startup and unloads it at exit.

- A new underlying profile file format is used to store sample data
  for all events in a single file per image.  Backwards compatibility
  has been retained so that all tools support profiles collected with
  previous versions of DCPI.

- Dcpid supports a new -nice option to adjust its scheduling priority,
  and a new -gc option to automatically delete old epochs.

- Fixed a rare assertion failure in instruction-level analysis tools.

- This version works with Digital Unix T5.0 646.2 (a.k.a. BL17)

- Support for Digital Unix 3.2 has been dropped.  Use DCPI-V2.11 and
  pcount-13.3 build 15 for machines running 3.2.

Changes since release V2.11:

- Added support for Alpha 21066 and other 21064-compatible cpus.

Changes since release V2.10:

- Adds support for compressed kernel modules.

- dcpiprof listings now contain information about which named
  procedure is near an anonymous procedure to help the user in finding
  anonymous procedures.

Changes since release V2.5:

- DCPI releases V2.6 through V2.9 each had incompatibilities
  with various versions of Digital Unix.  We believe that these
  problems have been corrected.
  
- New loader for 4.0c and higher.
  Dynamically linked images can be profiled on machines running
  DU V3.2 or V4.0*, but not V5.0*.  The INSTALL script tests the
  DCPI loader before installing it as the default system loader.

- Minor improvements to dcpid image identification.
  Image maps for common DU V4.0c and V4.0d binaries are compiled into dcpid.
  Fixed identification of large images started before dcpid.

- Major update to dcpi2pix to generate more accurate data.

- Added support for new 21264 instructions.


----- End Included Message -----


Date: Thu, 09 Mar 2000 14:43:10 -0500
From: Craig Chambers <chambers@cs.washington.edu>
To: cecil@cs.washington.edu, spin-comp@cs.washington.edu,
Subject: my return

FYI, I'll start driving back to Seattle from Pittsburgh next Wednesday.  I
expect to come in to work at UW on Tuesday March 21.  See you then!

-- Craig

Date: Tue, 14 Mar 2000 07:56:00 -0800 (PST)
From: Susan Eggers <eggers@cs.washington.edu>
To: redstone@cs.washington.edu, spin-comp@cs.washington.edu,
Subject: Mike Smith

Can you sign up to talk with Mike Smith?  His schedule is in the
usual place.  Marc and Patrick could double-up, if the two of
you are both available.

And can you also suggest other students he might be interested in meeting?

Thanks,
Susan

Date: Tue, 14 Mar 2000 07:56:12 -0800 (PST)
From: Susan Eggers <eggers@cs.washington.edu>
To: redstone@cs.washington.edu, spin-comp@cs.washington.edu,
Subject: Mike Smith

Can you sign up to talk with Mike Smith?  His schedule is in the
usual place.  Marc and Patrick could double-up, if the two of
you are both available.

And can you also suggest other students he might be interested in meeting?

Thanks,
Susan

Date: Tue, 21 Mar 2000 17:04:28 -0800 (PST)
From: Craig Chambers <chambers@cs.washington.edu>
To: cecil@cs.washington.edu, spin-comp@cs.washington.edu
Subject: I'm back!

I'm back in town, and actually in my office now.  I'll be in the rest
of the week, trying to get my computers to work and planning my class.
Stop by and tell me what you're up to!

-- Craig