🚀 go-pugleaf

In article <14823@pur-ee.UUCP> hankd@pur-ee.UUCP (Hank Dietz) writes:
>In article <5919@brazos.Rice.edu> preston@titan.rice.edu (Preston Briggs) writes:

>>	x = y + i;

>>This means assign the sum of y and i*5.  Not too bad, 1 shift and 3 adds.

								I mean 2 adds.

>>	j = x - y;

>>Hmmm.  A subtract and a DIVISION by 5!?

>True, but so what?

I think a lot of C pointer fiends write a lot of code deliberately
using pointer arithmetic and then saying proudly:

	"Look, only adds and subtracts!  Must be fast."

I was trying to say that lots of pointer arithmetic is an ugly
way to achieve no extra efficiency, and in fact to occasionally
get bit badly.

I'm familier with the bite; it's happened to me.
I had a pretty little set manipulation package I used in my
register allocator.  One day I looked at the assembly.  A call to the
divide routine!?  "What's all this then!  I don't do division.
Division is for dumb people."  After we noticed what was happening
and massively rewriting chunks of the allocator, we got a factor of
three improvement in code generation time.

>The only aspects in which C pointers are harder to
>analyze than Fortran array references are:
>
>[1] C pointers can be multi-level, i.e., pointers-to-pointers.
>[2] C supports recursion, hence pointers/subscript expressions can be
>    more difficult to decipher.

I think C's pointer are used for too much.
If we want array-like behaviour, we should use arrays.
If we want interesting, dynamic structures, we should use
recursive data types.  C uses pointers for both.  I would
rather not use pointers at all.

>Well, I usually agree with you, Preston, but I think your "Fortran is easy
>to understand" bias is showing on this one.  ;-)
>						-hankd@ecn.purdue.edu

Ah, the "F word".  I hate fortran!  I don't use it.  I (almost) never
have.  However, I do like constructs that are easy to optimize. :-)

--
Preston Briggs				looking for the great leap forward
preston@titan.rice.edu