Re^2: Oh noooooo!!

Andrew P. Mullhaupt amull at Morgan.COM
Wed Sep 27 14:46:12 AEST 1989


In article <14052 at lanl.gov>, jlg at lanl.gov (Jim Giles) writes:
> 
> The problem here is that C allows GOTOs in all the same contexts
> that Fortran does.  More importantly, C allows GOTOs that even 
> Fortran doesn't.  For example:
> 
>    C                                          Fortran
> 
>    if (a<b) {                               IF (A.LT.B) THEN
>       ...                                      ...
> lab1: ...                             10    CONTINUE
>       ...                                      ...
>    }                                        ENDIF
> ...                                         ...
> goto lab1                                   GOTO 10
> 
> This jump is allowed by C but not by Fortran.  In fact, even the
> So, the optimizer for C _cannot_ be any simpler than that for
> Fortran.

 If you have Sun's f77 "fortran" compiler, or any other BSD "fortran"
monstrosity, do not expect to have the preceding construct outlawed.
F77 forbids it, but f77 on Suns will compile and run the following
"outflawed" program:

      END DO
      IF (I.LT.100000) GOTO 2
      DO 1 I = 3, 10
    2 WRITE(*,*) I
    1 CONTINUE
      STOP
      END

with the output 0, 1, 2, ... 10. Now you can twiddle with the useless
"-ansi" switch on the compiler all you want. I believe that the last
few postings in this thread are essentially correct: FORTRAN is a
more optimizable language than C. However, almost all UNIX based f77
implementations use the same intermediate language as the C compiler,
and the identical code generation. I believe that this economy measure
may have introduced limitations on the optimization of the FORTRAN, 
and perhaps even on some aspects of the F77 standard flow of control
conformance, but the main point is that FORTRAN is simpler than C to
optimize, but "fortran" may not be.

Flaming replies that comp.lang.c is not the right group for this post
will be ignored on the grounds that this post is about the detrimental
side effect of the C language in the UNIX environment. All other 
flaming replies will be cheerfully extinguished...

Later,
Andrew Mullhaupt
Disclaimer: Morgan Stanley bears no responsibility for any opinions
expressed in this posting.



More information about the Comp.lang.c mailing list