File: comptrees_3.html

package info (click to toggle)
eli-doc 4.4.0-4
links: PTS
area: main
in suites: sarge
size: 13,256 kB
ctags: 4,583
sloc: makefile: 42
file content (456 lines) | stat: -rw-r--r-- 20,110 bytes
<HTML>
<HEAD>
<!-- This HTML file has been created by texi2html 1.29
     from ../tnf/comptrees.tnf on 12 Febuary 2003 -->

<TITLE>LIDO -- Computations in Trees - Remote Dependencies in Trees</TITLE>
</HEAD>
<BODY TEXT="#000000" BGCOLOR="#FFFFFF" LINK="#0000EE" VLINK="#551A8B" ALINK="#FF0000" BACKGROUND="gifs/bg.gif">
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0" VALIGN=BOTTOM>
<TR VALIGN=BOTTOM>
<TD WIDTH="160" VALIGN=BOTTOM><IMG SRC="gifs/elilogo.gif" BORDER=0>&nbsp;</TD>
<TD WIDTH="25" VALIGN=BOTTOM><img src="gifs/empty.gif" WIDTH=25 HEIGHT=25></TD>
<TD ALIGN=LEFT WIDTH="600" VALIGN=BOTTOM><IMG SRC="gifs/title.gif"></TD>
</TR>
</TABLE>

<HR size=1 noshade width=785 align=left>
<TABLE BORDER=0 CELLSPACING=2 CELLPADDING=0>
<TR>
<TD VALIGN=TOP WIDTH="160">
<h4>General Information</h4>

<table BORDER=0 CELLSPACING=0 CELLPADDING=0>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="index.html">Eli: Translator Construction Made Easy</a></td></tr>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="gindex_toc.html">Global Index</a></td></tr>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="faq_toc.html" >Frequently Asked Questions</a> </td></tr>
</table>

<h4>Tutorials</h4>

<table BORDER=0 CELLSPACING=0 CELLPADDING=0>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="EliRefCard_toc.html">Quick Reference Card</a></td></tr>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="novice_toc.html">Guide For new Eli Users</a></td></tr>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="news_toc.html">Release Notes of Eli</a></td></tr>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="nametutorial_toc.html">Tutorial on Name Analysis</a></td></tr>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="typetutorial_toc.html">Tutorial on Type Analysis</a></td></tr>
</table>

<h4>Reference Manuals</h4>

<table BORDER=0 CELLSPACING=0 CELLPADDING=0>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="ui_toc.html">User Interface</a></td></tr>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="pp_toc.html">Eli products and parameters</a></td></tr>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="lidoref_toc.html">LIDO Reference Manual</a></td></tr>
</table>

<h4>Libraries</h4>

<table BORDER=0 CELLSPACING=0 CELLPADDING=0>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="lib_toc.html">Eli library routines</a></td></tr>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="modlib_toc.html">Specification Module Library</a></td></tr>
</table>

<h4>Translation Tasks</h4>

<table BORDER=0 CELLSPACING=0 CELLPADDING=0>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="lex_toc.html">Lexical analysis specification</a></td></tr>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="syntax_toc.html">Syntactic Analysis Manual</a></td></tr>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="comptrees_toc.html">Computation in Trees</a></td></tr>
</table>

<h4>Tools</h4>

<table BORDER=0 CELLSPACING=0 CELLPADDING=0>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="lcl_toc.html">LIGA Control Language</a> </td></tr>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="show_toc.html">Debugging Information for LIDO</a> </td></tr>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="gorto_toc.html">Graphical ORder TOol</a> </td></tr>
</table>
<p>
<table BORDER=0 CELLSPACING=0 CELLPADDING=0>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="fw_toc.html">FunnelWeb User's Manual</a> </td></tr>
</table>
<p>
<table BORDER=0 CELLSPACING=0 CELLPADDING=0>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="ptg_toc.html">Pattern-based Text Generator</a> </td></tr>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="deftbl_toc.html">Property Definition Language</a> </td></tr>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="oil_toc.html">Operator Identification Language</a> </td></tr>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="tp_toc.html">Tree Grammar Specification Language</a> </td></tr>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="clp_toc.html">Command Line Processing</a> </td></tr>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="cola_toc.html">COLA Options Reference Manual</a> </td></tr>
</table>
<p>
<table BORDER=0 CELLSPACING=0 CELLPADDING=0>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="idem_toc.html">Generating Unparsing Code</a> </td></tr>
</table>
<p>
<table BORDER=0 CELLSPACING=0 CELLPADDING=0>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="mon_toc.html">Monitoring a Processor's Execution</a> </td></tr>
</table>

<h4>Administration</h4>

<table BORDER=0 CELLSPACING=0 CELLPADDING=0>
<tr valign=top><td><img src="gifs/gelbekugel.gif" WIDTH=7 HEIGHT=7 ALT=" o"> </td><td><a href="sysadmin_toc.html">System Administration Guide</a> </td></tr>
</table>

<HR WIDTH="100%">
<CENTER>&nbsp;<A HREF="mailto:elibugs@cs.colorado.edu"><IMG SRC="gifs/button_mail.gif" NOSAVE BORDER=0 HEIGHT=32 WIDTH=32></A><A HREF="mailto:elibugs@cs.colorado.edu">Questions, Comments, ....</A></CENTER>

</TD>
<TD VALIGN=TOP WIDTH="25"><img src="gifs/empty.gif" WIDTH=25 HEIGHT=25></TD>

<TD VALIGN=TOP WIDTH="600">
<H1>LIDO -- Computations in Trees</H1>
<P>
<IMG SRC="gifs/empty.gif" WIDTH=25 HEIGHT=25 ALT=""><A HREF="comptrees_2.html"><IMG SRC="gifs/prev.gif" ALT="Previous Chapter" BORDER="0"></A>
<IMG SRC="gifs/empty.gif" WIDTH=25 HEIGHT=25 ALT=""><A HREF="comptrees_4.html"><IMG SRC="gifs/next.gif" ALT="Next Chapter" BORDER="0"></A>
<IMG SRC="gifs/empty.gif" WIDTH=25 HEIGHT=25 ALT=""><A HREF="comptrees_toc.html"><IMG SRC="gifs/up.gif" ALT="Table of Contents" BORDER="0"></A>
<IMG SRC="gifs/empty.gif" WIDTH=25 HEIGHT=25 ALT="">
<HR size=1 noshade width=600 align=left>
<H1><A NAME="SEC5" HREF="comptrees_toc.html#SEC5">Remote Dependencies in Trees</A></H1>
<A NAME="IDX40"></A>
<P>
In the previous section we considered dependencies between computations
within one rule context and computations that are associated to pairs of
adjacent contexts. It is often necessary to specify that a precondition
of a computation is established rather far away in the tree, e. g. a
value computed in the root context is used in several computations down
in the tree. Instead of propagating it explicitly through all
intermediate contexts it may be accessed directly by notations for
remote dependencies.
<A NAME="IDX41"></A>
<A NAME="IDX42"></A>
<A NAME="IDX43"></A>
<P>
In the following we introduce three constructs for remote dependency
specification:
<UL>
<LI>
   access to a subtree root from contexts within the subtree
   (<CODE>INCLUDING</CODE> construct),
<LI>
   access to contexts within a subtree from its root context
   (<CODE>CONSTITUENTS</CODE> construct),
<LI>
   computations at certain subtree contexts that depend in depth-first
   left-to-right order on each other (<CODE>CHAIN</CODE> construct).
</UL>
<P>
These constructs can be used for value dependencies as well as for state
dependencies. Since these constructs avoid specifications in the contexts
between the remote computations, they abstract from the particular tree
structure in between: It may be designed according to other aspects or
be altered without invalidating those remote dependencies.
<P>
<H2><A NAME="SEC6" HREF="comptrees_toc.html#SEC6">Access to a Subtree Root</A></H2>
<A NAME="IDX44"></A>
<P>
Assume that we have a language where <CODE>Blocks</CODE> are arbitrarily
nested. We want to compute the nesting depth of each <CODE>Block</CODE>, and
mark each <CODE>Definition</CODE> with the nesting depth of the smallest
enclosing <CODE>Block</CODE>.
<P>
<PRE>
   ATTR depth: int;

   RULE: Root ::= Block COMPUTE
     Block.depth = 0;
   END;

   RULE: Block ::= '{' Sequence '}' END;
   RULE: Sequence ::= Sequence Statement END;
   RULE: Sequence ::= Sequence Definition END;
   RULE: Sequence ::= END;

   RULE: Statement ::= Block COMPUTE
     Block.depth = ADD (INCLUDING Block.depth, 1);
   END;

   RULE: Statement ::= Usage END;
   RULE: Usage ::= 'use' Ident END;

   TERM Ident: int;

   RULE: Definition ::= `define' Ident  COMPUTE
     printf ("%s defined on depth %d\n",
              StringTable (Ident), INCLUDING Block.depth);
   END;
</PRE>
Figure 6: Nesting Depth of Blocks
<A NAME="IDX45"></A>
<P>
The specification of Figure 6 solves the stated problem by remote
dependencies (<CODE>INCLUDING</CODE>).  The tree contexts between <CODE>Block</CODE>
and <CODE>Statement</CODE> or <CODE>Definition</CODE> do not need any computations. They
are only mentioned here to show a complete example. The
expression
<P>
<PRE>
   INCLUDING Block.depth
</PRE>
<P>
used in two computations accesses the <CODE>depth</CODE>
value of the next enclosing <CODE>Block</CODE>.
<P>
In general, alternative subtree root symbols may be specified, e. g.
<P>
<PRE>
   INCLUDING (Block.depth, Procedure.depth, Module.depth)
</PRE>
<P>
Then the root of the smallest enclosing subtree is accessed which
represents one of the given symbols.  The tree grammar must guarantee
that such a subtree root can always be found. Such an alternative
has to be used especially 
in an <CODE>INCLUDING</CODE> that refers to a recursive construct
like <CODE>Block</CODE>.
<P>
<CODE>INCLUDING</CODE> constructs may also be used as preconditions in
<CODE>&#60;-</CODE> constructs, and they may refer to state attributes.
<P>
<H2><A NAME="SEC7" HREF="comptrees_toc.html#SEC7">Access to Contexts within a Subtree</A></H2>
<A NAME="IDX46"></A>
<P>
Assume that we have a language for sequences of definitions and uses of
names in arbitrary order. We want to produce an output text for each
definition and each use, such that definition texts precede the use
texts in the output. No specific order is required within the two text
blocks.
<P>
<PRE>
   RULE: Block ::= '{' Sequence '}' COMPUTE
     Block.DefDone = CONSTITUENTS Definition.DefDone;
   END;

   RULE: Definition ::= 'Define' Ident COMPUTE
      Definition.DefDone =
        printf ("%s defined in line %d\n",
                StringTable(Ident), LINE);
   END;

   RULE: Usage ::= 'use' Ident COMPUTE
       printf ("%s used in line %d\n",
               StringTable(Ident), LINE),
       &#60;- INCLUDING BLOCK.DefDone;
   END;
</PRE>
Figure 7: Sequencing Classes of Computations in a Subtree
<P>
The solution of the problem given in Figure 7 uses a state attribute
<CODE>Block.DefDone</CODE>. It describes the state where all definition texts
are printed. Hence in that state the condition <CODE>Definition.DefDone</CODE>
must hold at each <CODE>Definition</CODE> in the subtree below the
<CODE>Block</CODE> context, as stated by the <CODE>CONSTITUENTS</CODE> construct.
The state <CODE>Block.DefDone</CODE> in turn is the precondition for the print
computation in the <CODE>Usage</CODE> context.
Such a pair of <CODE>CONSTITUENTS</CODE> and <CODE>INCLUDING</CODE> uses
is a common depedency pattern.
<P>
The following example demonstrates the remote access to values within a
subtree. We simply want to compute the number of <CODE>Usage</CODE> constructs
in a program of the above language.
<P>
<PRE>
   ATTR Count: int;

   RULE: Block ::= '{' Sequence '}' COMPUTE
     printf  ("%d uses occurred\n",
              CONSTITUENTS Usage.Count
              WITH (int, ADD, IDENTICAL, ZERO));
   END;

   RULE: Usage ::= 'use' Ident COMPUTE
     Usage.Count = 1;
   END;
</PRE>
Figure 8: Adding Values of Subtree Components
<A NAME="IDX47"></A>
<P>
The <CODE>CONSTITUENTS</CODE> construct in Figure 8 combines the values
<CODE>Usage.Count</CODE> of each <CODE>Usage</CODE> node within the
<CODE>Block</CODE> subtree. The <CODE>WITH</CODE> clause specifies how the values
are combined, in this case they are added yielding an <CODE>int</CODE>-value.
<P>
The <CODE>WITH</CODE> clause is a scheme to combine an arbitrary number of
values by a binary function. The general form is
<P>
<PRE>
   WITH (t, combine, single, none)
</PRE>
<P>
where <CODE>single</CODE> is a function that yields a value of type <CODE>t</CODE>
applied to an attribute accessed by the <CODE>CONSTITUENTS</CODE>. The
function <CODE>combine</CODE> yields a <CODE>t</CODE> value applied to two
<CODE>t</CODE> values. <CODE>none</CODE> is a constant function yielding a
<CODE>t</CODE> value applied to no argument. 
(It is applied at subtrees that do not contain the
accessed symbol, although the tree grammar would allow them to contain
it). Typical examples for <CODE>WITH</CODE> clauses are given in Figure 9.
<P>
<PRE>
      WITH (int, ADD, IDENTICAL, ZERO)
      WITH (int, Maximum, IDENTICAL, ZERO)
      WITH (int, OR, IDENTICAL, ZERO)
      WITH (int, AND, IDENTICAL, ONE)
      WITH (listtype, Append, SingleList, NullList)
</PRE>
Figure 9: Typical <CODE>WITH</CODE> Clauses
<P>
The applications of the <CODE>combine</CODE> functions obey the left-to-right
order of the tree nodes where their arguments stem from. The
<CODE>combine</CODE> function should be associative, the <CODE>none</CODE> function
should not affect the resulting value.  The calls of the three functions
may occur in any suitable order; hence one should not rely upon
side-effects.
Suitable implementations of the functions and the type must be made
available for the evaluator. (see  <A HREF="comptrees_6.html#SEC16">Implementing Tree Computations</A>)
<P>
We must be aware that in our example the <CODE>CONSTITUENTS</CODE> is applied
in a recursive tree structure, i. e. blocks are nested in our language.
In fact the above specification causes that <CODE>Usage</CODE> constructs in
inner blocks do not contribute to the <CODE>CONSTITUENTS</CODE> in outer
<CODE>Block</CODE> context: Inner <CODE>Block</CODE> subtrees are shielded from it.
We better make that explicit by
<P>
<PRE>
   CONSTITUENTS Usage.Count SHIELD Block WITH (...)
</PRE>
<P>
In general we may shield any class of subtrees from the
<CODE>CONSTITUENTS</CODE>-access, e. g. by
<P>
<PRE>
   SHIELD (Block, Procedure, Module) ...
</PRE>
<P>
If no subtree should be shielded an empty <CODE>SHIELD</CODE> clause is used:
<A NAME="IDX48"></A>
<P>
<PRE>
   ... SHIELD () ...
</PRE>
<P>
In this case our example would count the <CODE>Usage</CODE> constructs of all
inner blocks too.
<P>
In general several attributes may be specified for being accessed by a
<CODE>CONSTITUENTS</CODE>:
<P>
<PRE>
   CONSTITUENTS (X.a, Y.b)
</PRE>
<P>
<H2><A NAME="SEC8" HREF="comptrees_toc.html#SEC8">Left-to-Right Dependencies</A></H2>
<A NAME="IDX49"></A>
<P>
As an example for a simple left-to-right dependent computation we
rewrite the translation of expressions into postfix form of Figure 4.
<P>
In Figure 10 the <CODE>CHAIN</CODE> <CODE>print</CODE> specifies a sequence of
computations that depends on each other in left-to-right depth-first
order throughout the tree. It takes over the role of the pair of state
attributes <CODE>print</CODE> and <CODE>printed</CODE> in Figure 5.  Hence the
<CODE>CHAIN</CODE> is introduced with type <CODE>VOID</CODE>.
<P>
<PRE>
   CHAIN print: VOID;

   RULE: Root ::= Expr COMPUTE
     CHAINSTART HEAD.print = "yes";
     printf ("\n") &#60;- TAIL.print;
   END;

   RULE: Expr ::= Number COMPUTE
     Expr.print = printf ("%d ", Number. Sym)
                 &#60;- Expr.print;
   END;

   RULE: Opr ::= '+' COMPUTE
     Opr.post = printf ("+") &#60;- Opr.pre;
   END;

   RULE: Expr ::= Expr Opr Expr COMPUTE
     Opr.pre = Expr[3].print;
     Expr[1].print = Opr.post;
   END;
</PRE>
Figure 10: <CODE>CHAIN</CODE> for Producing Postfix Expressions
<A NAME="IDX50"></A>
<A NAME="IDX51"></A>
<A NAME="IDX52"></A>
<P>
The <CODE>CHAIN</CODE> computations are initiated in the <CODE>Root</CODE> context;
<CODE>HEAD.print</CODE> refers to the <CODE>CHAIN</CODE> at the leftmost subtree,
<CODE>Expr</CODE> in this case.
<CODE>TAIL.print</CODE> refers to the end of the <CODE>CHAIN</CODE> at the rightmost
subtree, again <CODE>Expr</CODE>. It is the precondition for printing the
final newline.
<P>
In the second context the <CODE>printf</CODE> computation is specified to
lie on the <CODE>CHAIN</CODE> by stating <CODE>Expr.print</CODE> to be a
precondition (<EM>incoming</EM> <CODE>CHAIN</CODE>) as well as to be a postcondition
(<EM>outgoing</EM> <CODE>CHAIN</CODE>).
<P>
The <CODE>Opr</CODE> context together with the binary operation context
specifies that operators are not
printed in <CODE>CHAIN</CODE> order, but are appended after the right operand
is printed. For that purpose two state attributes <CODE>Opr.pre</CODE> and
<CODE>Opr.post</CODE> are used, as in Figure 5.
<P>
If it is necessary to locally deviate from <CODE>CHAIN</CODE> order, like here in
case of the binary operation context, it has to be made sure, that the
chain is not cut into separate pieces which are not linked by dependencies:
If by some reason we would add another computation to the <CODE>Opr</CODE> context
of our example,
e. g.
<P>
<PRE>
     Opr.print = printf("Operator encountered\n")
                 &#60;- Opr.print;
</PRE>
<P>
it looks like being integrated into the print <CODE>CHAIN</CODE>. But the two
computations of the binary <CODE>Expression</CODE> context shortcut the
<CODE>CHAIN</CODE> across the <CODE>Opr</CODE> symbol. Hence, this computation may be
executed later than intended.
<P>
The above example specifies a single <CODE>CHAIN</CODE> of computations through the
tree. In general there may be several instances of a <CODE>CHAIN</CODE> in several
subtrees, which may be nested, too. For example, we may allocate variable
definitions to storage addresses relative to their smallest enclosing
<CODE>Block</CODE>, as shown in Figure 11. Here the <CODE>CHAIN</CODE> computations 
propagate values in depth-first left-to-right order.
<P>
<PRE>
   CHAIN RelAdr: int;

   RULE: Block ::= '{' Sequence '}' COMPUTE
     CHAINSTART HEAD.RelAdr = 0;
   END;

   RULE: Definition ::= 'define' Ident COMPUTE
     Definition.RelAdr = ADD (Definition.RelAdr, VariableSize);
   END;
</PRE>
Figure 11: Computing Addresses of Variables
<P>
An individual <CODE>CHAIN</CODE> is started for each <CODE>Block</CODE>.  In
the computation of the Definition context the two occurrences of
<CODE>Definition.RelAdr</CODE> refer to different values on the <CODE>CHAIN</CODE>:
The access in the <CODE>ADD</CODE> computation is the incoming current
<CODE>CHAIN</CODE> value (the address of this variable), the result left to
the <CODE>=</CODE> symbol denotes the outgoing next <CODE>CHAIN</CODE> value.
<P>
<HR size=1 noshade width=600 align=left>
<P>
<IMG SRC="gifs/empty.gif" WIDTH=25 HEIGHT=25 ALT=""><A HREF="comptrees_2.html"><IMG SRC="gifs/prev.gif" ALT="Previous Chapter" BORDER="0"></A>
<IMG SRC="gifs/empty.gif" WIDTH=25 HEIGHT=25 ALT=""><A HREF="comptrees_4.html"><IMG SRC="gifs/next.gif" ALT="Next Chapter" BORDER="0"></A>
<IMG SRC="gifs/empty.gif" WIDTH=25 HEIGHT=25 ALT=""><A HREF="comptrees_toc.html"><IMG SRC="gifs/up.gif" ALT="Table of Contents" BORDER="0"></A>
<IMG SRC="gifs/empty.gif" WIDTH=25 HEIGHT=25 ALT="">
<HR size=1 noshade width=600 align=left>
</TD>
</TR>
</TABLE>

</BODY></HTML>