Newsgroups: comp.theory,comp.lang.scheme,comp.software-eng
Path: cantaloupe.srv.cs.cmu.edu!rochester!cornellcs!newsstand.cit.cornell.edu!news.kei.com!newsfeed.internetmci.com!news.sprintlink.net!mv!usenet
From: ENGR@GSSI.MV.COM (Michael Furman)
Subject: Re: Style: multiple returns and relatives
Distribution: inet
Message-ID: <DIpn31.BCt@mv.mv.com>
Mime-Version: 1.0
Organization: GSSI
Date: Mon, 27 Nov 1995 16:28:13 GMT
References: <alberto.534.00162922@moreira.mv.com> <skfVWbO00VohAJimgc@andrew.cmu.edu> <48nni8$klj@ixnews4.ix.netcom.com> <48q9f4$2sj@camelot.ccs.neu.edu> <48rptn$fup@ixnews2.ix.netcom.com>
X-Newsreader: WinVN 0.93.10
X-Nntp-Posting-Host: gssi.mv.com
Lines: 145
Xref: glinda.oz.cs.cmu.edu comp.theory:14717 comp.lang.scheme:14411 comp.software-eng:39412

In article <48rptn$fup@ixnews2.ix.netcom.com>, JEThomas@ix.netcom.com says...
>
>In <48q9f4$2sj@camelot.ccs.neu.edu> will@ccs.neu.edu (William D Clinger) 
>writes: 
>
>>In article <48nni8$klj@ixnews4.ix.netcom.com>
>>JEThomas@ix.netcom.com (Jonah Thomas) writes:
>
>>>Any program in any language,
>>>  if it specifies unambiguously
>>>    what outputs should result from any given inputs,
>>>can (theoretically) be compiled to
>>>  the same optimal code
>>>    as that from any program in any other language
>>>      that specifies the same outputs for the same inputs.
>
>>>Is this wrong?  How would you test it?
>
>>This might not be wrong, but it has no practical consequences for
>>optimizing compilers.
>
>Thank you.  Several people have Emailed me that it is wrong, that I've
>stated a variation on the halting problem.  That wasn't what I meant to
>say, but I can see that it could be taken that way.  I'll drop that
>approach for now since I find the one with real examples more
>interesting.
>
>>To test it, I will define two programming
>>languages L1 and L2.  Let L1 be the trivial programming language
>>whose complete grammar is
>
>>    <program>  ::=  print 0
>
>>In other words, there is only one program you can write in L1.
>>Call it P1.  P1 ignores its input, and outputs 0.
>
>>Let L2 be Scheme.  Let <white_wins> represent Scheme code for a
>>brute force search of the game tree for chess, returning #t if
>>the search shows that white has a winning strategy, and returning
>>#f if white does not have a winning strategy.  Then either
>
>>    (write (if <white_wins> 0 1))
>>or
>>    (write (if (not <white_wins>) 0 1))
>
>>is equivalent to P1.  Let P2 be whichever program is equivalent
>>to P1.
>
>>Although it is (theoretically) true that an optimizing compiler can
>>compile P2 into the same optimal code that can be generated for P1,
>>it does not follow that efficiency is merely an implementation issue.
>
>I don't care about deciding whether _any_ L2 program is equivalent to
>the L1 program, I care that we can decide that _some_ L2 program is
>equivalent to the L1 program.  We can easily write an L2 program P3
>that's equivalent to P1 (if we know Scheme, which I don't). It would
>look something roughly like
>
>        (write ( 0 ))
>
>Anything we can do in L1 we can also do in L2, and we can optimise P3
>just as well as we could P1.
>
>>May we return to practical issues?  Consider the following C code:
>
>>    int f (int x[]) {
>>        int t1 = x[0];
>>        h(t1);
>>        return t1 + x[0];
>>    }
>
>>If h is defined in a separate file, then f is not equivalent to
>
>>    int g (int x[]) {
>>        int t1 = x[0];
>>        h(t1);
>>        return t1 + t1;
>>    }
>
>>because h might side effect x[0].  It is truly impossible for a C
>>compiler to generate the same code for both f and g, because the
>>C language allows the file containing f or g to be compiled before
>>the code for h has even been written.
>
>>In languages that require the code for h to be compiled before (or
>>as part of) the code that refers to h, the compiler can remember
>>that h has no side effects.  That allows the compiler to generate
>>the same optimized code for f and g.
>
>This looks to me like a similar issue to L1 and L2.  You have the
>option in C to do things that you can't do in Fortran, and some of the
>extra functionality is impossible to optimise.  So we have 4 cases:
>
>Case 1.  The program cannot be written in Fortran because the
>indeterminate side effects are necessary.  Then it can't be optimised
>in Fortran either.
>
>Case 2.  The program that requires indeterminate side effects can be
>written in Fortran by finding a way to simulate the indeterminate side
>effects.  Then it can't be optimised in Fortran either.
>
>Case 3.  The program does not require indeterminate side effects.  It
>can be written and optimised in Fortran.  It can be written with
>indeterminate side effects in C, or written without indeterminate side
>effects in C.  C allows you to write programs that can be optimised and
>also allows you to write programs that can't be optimised.  If
>optimisation is important to you, then you should write the former
>programs and not the latter.

But how compiler will know that program does not have such side effect?
(see my other posting)

>
>Case 4.  The program can be written without indeterminate side effects
>in Fortran, but can't be written without indeterminate side effects in
>C.  Then Fortran allows optimisation that C can't achieve.
>
>>So the efficiency of optimized code is a language issue, not just
>>an implementation issue.
>
>You've shown that C allows programs that can't be optimised.  Maybe
>every Fortran program can be optimised.  I've seen no evidence that C
>doesn't allow you to write programs that can be optimised.  It's only
>in Case 4 that optimisation is a language issue.

No! The real problem is with case 3.


>
>Is Case 4 for real?  I tend to disbelieve it.  But maybe proving it one
>way or the other would be a variation on the halting problem.  In that
>case, I say that the question whether optimisation is a language issue
>is a variation on the halting problem and is indeterminate.
>
>8-)
>

-- 
---------------------------------------------------------------
Michael Furman,                       (603)893-1109
Geophysical Survey Systems, Inc.  fax:(603)889-3984
13 Klein Drive - P.O. Box 97          engr@gssi.mv.com 
North Salem, NH 03073-0097            71543.1334@compuserve.com
---------------------------------------------------------------

