Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!samsung!uunet!mcsun!hp4nl!charon!dik
From: dik@cwi.nl (Dik T. Winter)
Newsgroups: comp.arch
Subject: Re: Compilers, architecture, and efficiency
Message-ID: <3429@charon.cwi.nl>
Date: 1 May 91 02:55:44 GMT
References: <1991Apr29.155945.29907@rice.edu> <1991Apr30.025904.13028@rice.edu> <11609@mentor.cc.purdue.edu>
Sender: news@cwi.nl
Organization: CWI, Amsterdam
Lines: 78

In article <11609@mentor.cc.purdue.edu> hrubin@pop.stat.purdue.edu (Herman Rubin) writes:
 > But what if I find Boolean operations useful in dealing with floats, which
 > I do for certain purposes?
Can you also specify the floating point format please?  Should the language
require a specific format?  And if it does *not* depend on the format, what
kind of Boolean operations are you thinking of?  Or should there be a
different language for every architecture?  Yes, I know you have mumbled about
user extensible languages.  Upto now I have seen no specification of the
things you want.  Algol 68 is very powerful, you can add all kinds of infix
operators, but I have this idea that that is not what you want.

 > One of the reasons why, in the late 50s and early 60s, binary was settled on
 > (there are many others) was that multiplication by powers of 2 was rather
 > common.
I have heard many reasons, but never this one.  Can you give a reference
please?

 >          Only a few machines have this very important operation in floating
 > hardware, and instead have to bring in the multiplier and use the relatively
 > slow multiplication.  It is true that with pipelined hardware this is not so
 > much of a problem, but I know of only a few machines which had it before then.
Mm, some 360's had it I think, but that was completely micro code, and if my
memory is right, later versions did it through a straight multiplication.
There must be some reason.  Also, multiplication by 2 is *not* easy on IEEE
conformant machines (think gradual underflow).  Kahan had some (good) reasons
to include gradual underflow.  But IEEE machines might use the 'adjust exponent'
primitive.  On the other hand, IEEE says nothing about what has to be done in
hardware and what can be done in software.  And on your favorite machine (Cyber
205) DP multiplication by 2.0 need not even be exact!
 > 
 > I agree that you know how to do certain types of optimizations.  I suggest
 > that you make these optimizations available to those who have a more varied
 > collection of things to optimize.  You (the computer science community) know
 > how to optimize, but have only a limited knowledge of what it is useful to
 > optimize.  I do not criticise you for this lack of knowledge, but only for
 > failing to realize that you should be looking for input on this from others.
Not so limited in fact.  They use several tools to asses the suitability of
different optimizations.  There is no lack of knowledge, they use input from
others: the programs that are normally run on their systems.
 > 
 > We, and I include all of mankind, do not know enough about to design a good
 > system of communicating between people and computers now.  We can design a
 > fair one by realizing this and allowing the users to extend the language, and
 > to communicate to the compiler this extension.
As has been asked before: give examples.  How would you like to write in your
favorite language your favorite examples:
1.  Check bit in a bit stream and mark as seen.
2.  Calculate length of a run of 0's or 1's in a bit stream and mark them as
    seen.
HINTS:
They could be done along the lines of:
	bitstream b;
	bit b1;
	int count;
	/* another gripe of you */
	external end_of_bits();

	trap_at_bits_end(b, end_of_bits);
	b1 = nextbit(b); /* I hear you about infix operators */
	count = countbits(b);  /* should it count the bit just consumed? */

Next question:  how do you envisage an *efficient* hardware implementation?
If there is one, compilers are quite able to translate the above code to
that implementation.  If you know of that *efficient* hardware implementation
and if it is present on a current architecture, just convince your compiler
vendor to put that optimization in your compiler.  If not, convince your
hardware vendor to put the operations required in the hardware (and show
how it can be done efficiently), and next convince your compiler vendor.

I am not entirely against you.  But both hardware designers and compiler
writers have their reason to do things.  At first I was disgusted to hear
that the new SPARC architecture provides an integer division instruction
without at the same time giving a remainder.  Now I know the reasons, and
I respect them.  Contrary to the WE32000 which also has a division without
remainder, *and* a remainder without quotient, without apparent reasons.
--
dik t. winter, cwi, amsterdam, nederland
dik@cwi.nl