🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.lang.misc
Article #1860

Re: Answers, Chapter 1: TeX

#1860
From: Jim Giles
Date: Tue, 30 Oct 1990 23:44
54 lines
3252 bytes
From article <26971@megaron.cs.arizona.edu>, by gudeman@cs.arizona.edu (David Gudeman):
> [...]                  You are comparing apples and oranges.  The
> appropriate comparison is to compare the optimization potential of
> arrays vs. pointers either both with or both without the 'alias'
> declaration.

Ok.  First _without_ the 'aliased' attribute:
   If your language doesn't have the ability to declare aliasing
   status, arrays are a direct win over pointers (which is why
   Fortran is usually faster than C on array intensive code).  Of
   course, optimizing the arrays this way is unsafe unless the
   loader checks all passed arguments to enforce the constraint that
   distinct arrays are NOT aliased.  Most Fortran environments
   _don't_ test this - so you can have strange and difficult to find
   errors arising from this cause.  Meanwhile, C converts all array
   args to pointers and generates inefficient code.  I don't regard
   either solution satisfactory.

Now _with_ the 'aliased' attribute:
   If your language _does_ have the ability to declare aliasing status
   (like the one I'm recommending), then pointers don't give you any
   capability you don't already have _without_ them.  Pointers in such
   a language are neither more powerful, more legible, nor more
   efficient than an appropriate combination of the other features
   I've mentioned.  So, what do we need pointers for?

   In fact, there are other distinctions between the different data
   types I've recommended _besides_ their aliasing status which yield
   optimization possibilities in addition to the alias free nature of
   the language.  Using pointers to simulate these data types
   (sequences for example) deprives the compiler of information which
   _could_ be used to improve the performance of the code.

So, arrays (and/or the other data types I've mentioned) are an
improvement on pointers - with or without the 'aliased' attribute.

I recommend the 'aliased' attribute in order to provide the
capability (especially in connection with recursive data types) to
do all the things that Pascal pointers do.  The aliased attribute
achieves this and at the same time allows easier optimization: the
compiler has an explicit local declaration of all possible aliasing
in each routine - the rest of the variables are _guaranteed_ not to
be aliased.

The price of testing this constraint is the load-time test that
Fortran compiler/loader environments _should_ already be doing.
This can be made considerably easier with a requirement of function
interface/prototype declarations of all procedures that are to be
called.  The compiler can then test the aliasing constraint at
compile-time and the loader need only make sure that the
interface/prototype information actually matches the corresponding
procedure declaration.

J. Giles
Technical Details
Message-ID: <4464@lanl.gov>
Path: arc1-ca.pugleaf.net!utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!rutgers!cmcl2!lanl!jlg
References: <26971@megaron.cs.arizona.edu>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!rutgers!cmcl2!lanl!jlg
From: jlg@lanl.gov (Jim Giles)
Newsgroups: comp.lang.misc
Subject: Re: Answers, Chapter 1: TeX
Message-ID: <4464@lanl.gov>
Date: 30 Oct 90 23:44:53 GMT
References: <26971@megaron.cs.arizona.edu>
Organization: Los Alamos Natl Lab, Los Alamos, N.M.
Lines: 54