🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.lang.misc
Article #838

Re: NOT Educating FORTRAN programmers to use C

#838
From: Jim Giles
Date: Wed, 24 Jan 1990 00:34
50 lines
2490 bytes
From article <9738@stealth.acf.nyu.edu>, by brnstnd@stealth.acf.nyu.edu:
> [...]
> The only problem with aliasing is parallel optimization. C compilers for
> vector machines provide directives to indicate that arrays x and y don't
> overlap. Fortran doesn't even have a standard way to specify extensions.

The above argument is not true.  Consider the following code sequence
in C:

   z = compilcated_expression;
   *a= 0;
   *b= complicated_expression;

Where the "complicated_expression" is the same for both 'z' and '*b'.
The optimization you would like to use _ON_ANY_MACHINE_ is to compute
the expression, store it into both 'z' and '*b' and then store zero
into '*a'.  Or, store the zero in '*a' first - or _while_ you're computing
the expression.  Any one of these would work correctly - and be FASTER -
provided that you KNOW that '*a' is not aliased to 'z', '*b', or part
of the expression.  If you don't know that, then you have to assume the
worst and generate code accordingly - including computing the expression
twice!!  Furthermore, aliasing effects the scheduling of cache, registers,
and possibly even stack for similar reasons.  I don't know of _ANY_ machine
which cannot benefit from the knowledge of whether things are aliased or
not.

>   [ parentheses ]
> 
> If you really want to force evaluation order, use a temporary variable.
> C's as-if optimization is logical and powerful; [...]

This assumes that you compiler is smart enough not to really reserve space
for the temporary variable - or, at the very least, it doesn't actually
generate the unnecessary store/load.  

>   [ assignment as an expression ]
> 
> I've found C's expressions to be useful syntactic devices. Sometimes
> I've wished for even more: something analogous to a = b the same way
> that a++ is analogous to ++a. I find it difficult to believe that the
> presence of these operators decreases productivity.

Some of the people doing studies of such operators were expecting different
results as well.  The problem is that evidence doesn't wait upon your
difficulty in believing.  




J. Giles
Technical Details
Message-ID: <14209@lambda.UUCP>
Path: arc1-ca.pugleaf.net!utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!yale!cmcl2!lanl!lambda!jlg
References: <9738@stealth.acf.nyu.edu>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!yale!cmcl2!lanl!lambda!jlg
From: jlg@lambda.UUCP (Jim Giles)
Newsgroups: comp.lang.misc
Subject: Re: NOT Educating FORTRAN programmers to use C
Message-ID: <14209@lambda.UUCP>
Date: 24 Jan 90 00:34:43 GMT
References: <9738@stealth.acf.nyu.edu>
Distribution: usa
Lines: 50