🚀 go-pugleaf

In article  <6529@brazos.Rice.edu> preston@titan.rice.edu (Preston Briggs) writes:
>And why not be practical?  Implementing pointers with triples!?
>Going to be hard to keep in a register.  Going to be hard to cast
>into a long int and back.

Obviously the triple method is only intended to be used for code
developement, the finished product would be compiled without bounds
checks of any kind.  The casting is going to cause some trouble, but
then anyone doing that kind of thing is on his own.  (Actually, I
think I could handle that case also, but I'm not sure it would be
worth the effort.)

>With enough work by the compiler, the penalty for array bounds checking
>can be reduced to less than 10% on systems code.
>
>Care to speculate on the cost of a 3-tuple scheme for pointers?
>If not, can we dispose of them as a topic?

Dispose of them as a topic because they are inapropriate for one
particular application (finished products)?  Hardly sounds reasonable.
I usually don't keep the "asserts" in my finished products either,
does that make them useless?

>Aliasing due to pointers can be introduced at any assignment.
>It's possible to detect aliasing, but the analysis is either
>very imprecise or very expensive or both.  By imprecise, I mean
>overly conservative -- pointers will appear to point to many places.

True enough for general pointer use.  However, the statement made by
Jim Giles -- that array indexes can be optimized more than pointer
arithmetic used for the same purpose -- is incorrect.  When a pointer
is being used with pointer arithmetic in such a way that it could be
easily replaced by array indexing, then the structure of the
operations is such that it can be optimized just like the indexing
could (in most cases).
-- 
					David Gudeman
Department of Computer Science
The University of Arizona        gudeman@cs.arizona.edu
Tucson, AZ 85721                 noao!arizona!gudeman