Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!cs.utexas.edu!oakhill!steve
From: steve@oakhill.UUCP (steve)
Newsgroups: comp.lang.fortran
Subject: Re: DO loops, anyone?
Summary: They are all the problem
Message-ID: <1905@devsys.oakhill.UUCP>
Date: 16 Mar 89 15:12:01 GMT
References: <458@orange19.qtp.ufl.edu> <28506@sgi.SGI.COM> <1317@uw-entropy.ms.washington.edu>
Organization: Motorola Inc. Austin, Tx
Lines: 64

In article <1317@uw-entropy.ms.washington.edu>,
             charlie@mica.stat.washington.edu (Charlie Geyer) writes:
> 
> A simpler solution would have compilers do run-time error checking and
> not jump into inactive loops.  The beauty of this solution is that it
> does not not slow down structured code -- no checking necessary.
> 
> Unstructured code would take a performance hit.  Serves it right :-)
> 
> It's not failure to end every loop with its own CONTINUE that is the
> problem.  It is (surprise!) GOTO's are harmful.

As I stated in my previous post.  There is NO problem with the code as
posted.  It is not ambiguous.  The problem is that the compiler, in
order to prevent any posssible ambiguity, generates bad code.  The
true ambiguity results in the following three elements used together.

  1) Two or more do loops ending on the same line.
  2) One or more of the external do loops (not the inner most)
     jumping to the terminating statement.
  3) The terminating statement being executable (not a CONTINUE).

Admittedly the practice of ending do loops on the same line is not
sound programming.  But it is historic programming, and is still used
today.  As for the performance hit you talk about, well that's part of
the problem here. 

If you looked at the pseudocode I posted Tuesday, the proper code for
is large and slow.  Compiler writers don't like this.  It doesn't sell
compilers.

First you MUST use an iteration count.  Code generators don't like to.
More code.  You can only remove that iteration counter once you are
sure there are no jumps into the DO block (an illegal situation often
supported).  This checking to get things right slows down the
compiler.  The right code is larger and slower than your competition's
(who did things wrong but fast).

Also for the same reason you must check less than equal to zero on the
iteration count.  An operation that is slower on many computers.

Also one interpretation requires either generating the terminating
line's code twice, or making some mechanism which truely does the
checking.  Bulky and slow.  Won't sell the compiler. 

In order to speed up the code, the compiler maker took a short cut
they properly shouldn't have.  The compiler generates faster code on
all DO loops, but it gets a few marginal cases wrong.  Since the
workaround here is obvious and better programming methodology (Put two
terminal statements), they'll be glad to tell you the workaround
and say they are working on the problem.

                   enough from this mooncalf - Steven
----------------------------------------------------------------------------
To flame someone for bad spelling or grammer is a discouragement to net
discussion in a timely fashion.
----------------------------------------------------------------------------
These opinions aren't necessarily Motorola's or Remora's - but I'd like to
think we share some common views.
----------------------------------------------------------------------------
Steven R Weintraub                        cs.utexas.edu!oakhill!devsys!steve
Motorola Inc.  Austin, Texas 
(512) 440-3023 (office) (512) 453-6953 (home)
----------------------------------------------------------------------------