Path: utzoo!utgpu!water!watmath!clyde!rutgers!rochester!PT.CS.CMU.EDU!IUS1.CS.CMU.EDU!edw
From: edw@IUS1.CS.CMU.EDU (Eddie Wyatt)
Newsgroups: comp.lang.c
Subject: Re: Power operator?
Summary: Are we posting only to be heard
Message-ID: <622@PT.CS.CMU.EDU>
Date: 10 Jan 88 19:14:31 GMT
References: <11169@brl-adm.ARPA> <1559@rtech.UUCP>
Sender: netnews@PT.CS.CMU.EDU
Organization: Carnegie-Mellon University, CS/RI
Lines: 49

In article <1559@rtech.UUCP>, wong@llama.rtech.UUCP (J. Wong) writes:
> One of the original motivations of the people who designed C was
> that no operation should result in a function call being generated
> in order to implement the language.  Although, structure assignment
> and return might seem to violate this, it's true on some machines
> that they can be implemented through machine instructions.  So, in
> general I think that the orginal motivation is still valid, and no
> operation (such as a power operator) should be introduced if the
> only way it can be implemented is through a function call.
> 
> 				J. Wong		ucbvax!mtxinu!rtech!wong

   Actually any operation in a languge need not generate functions calls -
have we heard of inline expansion?  Assuming what you really meant
was that there should be hardware support for the operation, well
I don't think this case should be ruled by precedence.  That is
even if what you state was a design goal of the language.

  As I stand on my soap box .... Computer languages should be designed
with providing a reasonable abstraction for a programming model
while keeping in mind that the constructs used should be inexpensive to
implement.  I don't think anyone will question the reasonableness
of an infixed notion for exponentiation.  So the question remains
is it too expensive to implement.

 On machines with hardware support, the answers should be no.  In fact,
it may be worst to use a function format because of some optimizations
that can be realized when operands have special properties. These
properties become harder to detect when using a functional format
(integers must be typed coerced into doubles).  On machines with
no hardware support for exponetiation, the answer maybe one could
do better with an fix notion then without it.  Not only are
the optimizations harder to detected with functional format, but also
optimization coded by the programmer may have detrimental effects on timing.
A classic of mine is the sqr(x) ((x)*(x)) macro.  A seemingly harmless 
macro.  When used in the context sqrt((double) sqr(x1-x2) + sqr(y1-y2)) 
you may start to realize its affects.  The expressions (x1-x2) and
(y1-y2) may be evaluated twice, that is unless the compiler does
some common subexpression elimination.

  Aside : this last example illustrates  a point I was trying to 
make to someone else about the side effects of macros.  Some of the
side effects macros may have are very illusive.


						
-- 

Eddie Wyatt 				e-mail: edw@ius1.cs.cmu.edu