|[10 earlier articles]|
|Re: programmer optimizations? firstname.lastname@example.org (Dave Gillespie) (1995-01-11)|
|Re: programmer optimizations? email@example.com (David Toland) (1995-01-11)|
|Re: programmer optimizations? firstname.lastname@example.org (1995-01-23)|
|Re: programmer optimizations? email@example.com (1995-01-27)|
|Re: programmer optimizations? firstname.lastname@example.org (1995-01-31)|
|Re: programmer optimizations? c1veeru@WATSON.IBM.COM (Virendra K. Mehta) (1995-02-02)|
|Re: programmer optimizations? email@example.com (1995-02-01)|
|Re: programmer optimizations? firstname.lastname@example.org (1995-02-01)|
|Re: programmer optimizations? email@example.com (1995-02-02)|
|Re: programmer optimizations? firstname.lastname@example.org (Ronald F. Guilmette) (1995-02-04)|
|From:||email@example.com (Henry Baker)|
|Date:||Wed, 1 Feb 1995 03:58:00 GMT|
firstname.lastname@example.org (Henry Baker) wrote:
> Before everyone gets too upset here, it is quite difficult--in
> general--for a compiler to keep track of whether a number is positive,
> negative or zero.
> When it comes to range information in which one or both ends of the range
> are a run-time variable, the complexity of static analysis skyrockets.
email@example.com (Christopher Glaeser) wrote:
> I was referring to the negative constant divisor, not variable dividend.
> For example, consider the following expression.
> foo / -8
> All the power-of-two optimizations I listed in the previous message are
> easy to implement (e.g. do not require flow information).
> In early releases of Nullstone, we only tested a few combinations of
> power-of-two optimizations, thinking that if a compiler optimized
> (foo / (1 << 3)), that it probably optimized (foo / (1 << 15)).
> Our analysis of twenty compilers on a variety of platforms revealed
> that very few compilers generate efficient code for all combinations
> of positive/negative signed/unsigned power-of-two multiply/divide/mod.
Well, part of the reason is the brain-damaged hardware that doesn't
provide both 'trunc' and 'floor' forms of division. 'trunc' division
is Fortran 'round' towards zero division, while 'floor' division is
APL/Knuth 'round' towards -infinity division. Then there are brain-
damaged languages -- e.g., C -- that don't provide for a rounding
(see ftp://ftp.netcom.com/pub/hb/hbaker/AB-mod-N.html (also .ps.Z) for
an example of where C falls down.)
It's looooong past time for some inter-language standards committee to nail
down these issues wrt to division and integer conversion. I highly recommend
the goals (though not necessarily the final results) of the Common Lisp
language, which provides all four operations: floor, ceiling, truncate, and
(see also ftp://ftp.netcom.com/pub/hb/hbaker/Gaussian.html (also .ps.Z)
for some uses of some of these.)
Return to the
Search the comp.compilers archives again.