Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!van-bc!ubc-cs!fs1!ee.ubc.ca!mikeb
From: mikeb@ee.ubc.ca (Mike Bolotski)
Newsgroups: comp.lang.misc
Subject: Re: The Forbiden
Message-ID: <1990Aug16.213113@ee.ubc.ca>
Date: 17 Aug 90 04:31:13 GMT
References: <24294@megaron.cs.arizona.edu>
Sender: root@fs1.ee.ubc.ca
Reply-To: mikeb@salmon.ee.ubc.ca
Organization: Dept of EE, University of British Columbia
Lines: 59

In article <24294@megaron.cs.arizona.edu>, gudeman@cs.arizona.edu (David
Gudeman) writes:
> 
> Let's design FORTRAN++, a proper extension of FORTRAN.  Legal FORTRAN
> programs are compiled exactly the same way in FORTRAN++ as in
FORTRAN,
> including the optimizations that come from assuming no aliasing.  But
> in FORTRAN++, there is a subroutine declaration that tells the
> compiler a given subroutine _can_ have aliased arguments.  When it
> sees this declaration, a FORTRAN++ compiler does not do the
> optimizations, and does not check for aliasing in procedure calls (if
> it does otherwise).

This sounds rather like the #pragma facility in C, but on a 
per-procedure basis.  [Discussions to the portability of #pragma
will be ignored].

> I have this silly idea that the programmer (at coding time) is better
> at making decisions on how to write a particular program than is the
> language designer at language-design time.  Face it, the programmer

The above may true for an experienced programmer who is aware of
all the various levels between his language and execution on the
bare metal.   I'll bet that 50% of existing C programmers don't know
what aliasing is.

> knows a lot more about the problem area and resource constraints than
> the language designer does (who had no idea that anyone would be
using
> his language to solve that problem in that environment).

On the other hand, the resource constraints may change dramatically
when the program is moved to a different platform, and the programmer
may not be aware of the change.

Example: 

a version of a CAD program I developed on a 68K based machine
used 'short' integers for flags and small loop counters.  When
the program was moved to a sparc, the "fast" short integers cost
a lot more than the 32-bit ones since the compiler kept inserting
logical ANDs to ensure the value stayed at 16 bits. 

Sure, eventually I typedef'ed loop counters as "fastints" and did
conditional definition based on #ifdef sparc [I bet Herman would
enjoy this level of performance twiddling], but the point is
that I wouldn't want to change this for every machine the program
was ever ported to.

The point is, a program may be installed and run under resource
constraints that were unknown to the programmer at the time the
code was written.   This argues for letting the language do the
optimization without programmer intervention.

--
Mike Bolotski           VLSI Laboratory, Department of Electrical
Engineering
mikeb@salmon.ee.ubc.ca  University of British Columbia, Vancouver,
Canada