Derivative/collective works and OSL

[Chuck Swiger]

On Feb 7, 2005, at 11:56 AM, Chris F Clark wrote:
> Chck swiger wrote:
>> However, there exists a branch of software engineering known as 
>> compiler
>> design, and there exist experts in that field who have written working
>> compilers who share a common understanding of how a compiler toolchain
>> operates: compilers perform a mechanical, deterministic, and 
>> reversible
>                                             ^^^^^^^^^^^^^      
> ^^^^^^^^^^
>> transformation on source code to produce object code.
>
> The underlined words are incorrect and important.
>
> Almost all compilers perform irreverisble transformations (in fact, I
> can't think of any "compilers" that perform reversible
> transformations, although some Java compilers are close).

There is a specific, essential context to my comments about compiler 
theory:

"First, a transformation must preserve the meaning of programs.  That 
is, an 'optimization' must not change the output produced by a program 
for a given input, or cause an error, such as a division by zero, that 
was not present in the original program."

A potential transformation which changes the output of a valid program 
for any input by definition is not a permissible transformation for the 
compiler to make.

> Many compilers perform non-deterministic trnasformations
> (i.e. transformations that depend on external factors not present in
> the source code (e.g. the time-of-day, the location where the compiler
> was run, etc.)).

There exist object formats (DWARF?) which encode the time which the 
code was compiled into the object file, agreed.  That information, 
these "external factors not present in the source code" are effectively 
inputs into the compiler system and thus effect the resulting program.

Consider the 3-stage bootstrap of GCC discussed in:

http://gcc.gnu.org/install/build.html

"For a native build issue the command make bootstrap. This will build 
the entire GCC system, which includes the following steps:
	• 	 Build host tools necessary to build the compiler such as texinfo, 
bison, gperf.
	• 	 Build target tools for use by the compiler such as binutils (bfd, 
binutils, gas, gprof, ld, and opcodes) if they have been individually 
linked or moved into the top level GCC source tree before configuring.
	• 	 Perform a 3-stage bootstrap of the compiler.
	• 	 Perform a comparison test of the stage2 and stage3 compilers.
[ ... ]

If the comparison of stage2 and stage3 fails, this normally indicates 
that the stage2 compiler has compiled GCC incorrectly, and is therefore 
a potentially serious bug which you should investigate and report. (On 
a few systems, meaningful comparison of object files is impossible; 
they always appear “different”. If you encounter this problem, you will 
need to disable comparison in the Makefile.)"

In fact, you can even do a "make compare" on a system using DWARF, 
because gcc's Makefile will ignore the first 16 bytes of the object 
files to avoid paying attention to that timestamp:

# Compare the object files in the current directory with those in the
# stage2 directory.

# ./ avoids bug in some versions of tail.
compare compare3 compare4 compare-lean compare3-lean compare4-lean: 
force
         -rm -f .bad_compare
         case "$@" in compare | compare-lean ) stage=2 ;; * ) 
stage=`echo $@ | sed -e 's,^compare\([0-9][0-9]*\).*,\1,'` ;; esac; \
         for file in *$(objext); do \
           tail +16c ./$$file > tmp-foo1; \
           tail +16c stage$$stage/$$file > tmp-foo2 \
             && (cmp tmp-foo1 tmp-foo2 > /dev/null 2>&1 || echo $$file 
differs >> .bad_compare) || true; \
         done

Why is it normally possible to compare the stage2 and stage3 compiler?  
Because the output of the compiler for a well-defined input is 
deterministic.

> The transformation is mechanical.
>
> If compilers performed reversible tranformations, there would be no
> point in "open source".  However, compilers perform irreversible
> transformations that lose information.

Sure.  The compiler performs transformations which discard comments, 
sections which are "#if 0"ed out, and so forth.  Since this is so 
obviously true, please consider the possibility that the point I am 
making does not contradict that truth.

Let me try to express this point by rephrasing your comment: "Compilers 
perform reversible transformations which do not change the output of 
the program."

Compiling the code using no optimization, "-O", and "-O2" results in 
different object code.  The object code very probably will perform 
differently in terms of resource usage like CPU time and memory access. 
  But the object code must compute the same results-- must produce the 
same outputs for a given set of inputs-- or else the compiler itself is 
buggy.

-- 
-Chuck