Initial and final read and write

"Rick LaMont" <>
14 Aug 2002 02:18:53 -0400

          From comp.compilers

Related articles
Initial and final read and write (Rick LaMont) (2002-08-14)
| List of all articles for this month |

From: "Rick LaMont" <>
Date: 14 Aug 2002 02:18:53 -0400
Organization: Dot C Software, Inc.
Keywords: optimize, question, comment
Posted-Date: 14 Aug 2002 02:18:53 EDT

In the paper "A Language for Shading and Lighting Calculations" by
Hanrahan and Lawson (SIGGRAPH 1990), the authors describe how the
shader object file (.slo) contains an extensive symbol table for
run-time optimizations. In particular, they write:

        For each symbol referenced by the shader, the symbol contains
        pointers to the initial and final read and write references in
        the shader code. This is used to determine if a shader requires
        access to a [sic] external variable, or if the shader changes
        the variable, to ensure that a local copy is made or that
        related properties (position and normals for instance) are
        updated consistently.

Can someone please explain why it's beneficial to know four line numbers
(initial_write, final_write, initial_read, final_read) for every variable
in the symbol table? The line numbers in question refer to the bytecode,
not the original SL source. This is not a case of temporary allocation,
which has already taken place at compile-time.

As far as the reasons given in the above excerpt, it seems that the
presence of an external variable in the symbol table would indicate
that the shader requires access to it. A simple read/write flag could
signify that the shader may change the variable. What's all this about
line numbers?


Rick LaMont
Dot C Software, Inc.
[I suggested it'd make it easier to assign variables to machine registers
when the byte code was translated to machine code, he said that the current
version of the software interprets the byte code. -John]

Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.