Re: Crosspost: Help wanted from comp.compilers

[Marin David Condic <nobody@noplace.com>]

Not always the compiler maker either. I know that the DEC compilers had 
a "feature" wherein they could compile a file on two different occasions 
and get different code, despite there being no change in the file. The 
reason was that the optimizer took advantage of the available working 
set to bring in more code for optimization. Depending on the demand for 
memory, it might get more or less memory on two different passes and 
hence could (and did on at least three occasions I witnessed) produce 
different code for an unchanged file. It was rare, but it was a risk. 
For most people, this wouldn't be a problem, but for safety critical 
embedded systems, it was.

Maybe this example doesn't really apply to specifications, since there 
may not be much/any code generation going on and little/no optimization 
- but it illustrates the difficulties the compiler writers may have in 
knowing the consequences of what may happen in the field.

So, yes, I agree, compilers ought not to force recompilation when it is 
unnecessary. But sometimes it is difficult to know when "unnecessary" is 
  a certainty & I can be forgiving of implementations that try to err on 
the side of caution.

MDC

Hyman Rosen wrote:
> Marin David Condic wrote:
> 
>> Can you really be certain that if you recompile a spec with different
> 
>  > compiler options, that this will in no way impact the way other things
>  > might rely on it?
> 
> Me, no. The compiler maker, yes.
> 


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jast.mil/

Send Replies To: m c o n d i c @ a c m . o r g

     "In general the art of government consists in taking as
     much money as possible from one class of citizens to give
     to the other."

         --  Voltaire
======================================================================