Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!princeton!njin!uupsi!sunic!lth.se!newsuser
From: bengtl@maths.lth.se (Bengt Larsson)
Newsgroups: comp.arch
Subject: Re: Compilers and efficiency
Message-ID: <1991Apr28.151831.2768@lth.se>
Date: 28 Apr 91 15:18:31 GMT
References: <9782@mentor.cc.purdue.edu> <4082@batman.moravian.EDU> <11411@mentor.cc.purdue.edu>
Sender: newsuser@lth.se (LTH network news server)
Reply-To: bengtl@maths.lth.se (Bengt Larsson)
Organization: Lund Institute of Technology, Sweden
Lines: 77

In article <11411@mentor.cc.purdue.edu> hrubin@pop.stat.purdue.edu 
(Herman Rubin) writes:
>In article <4082@batman.moravian.EDU>, halkoD@batman.moravian.EDU (David Halko) writes:
>> What do you mean how is a compiler suppoosed to recognize that this is wanted?
>
>I mean exactly that.  I am assuming that the operations are done by means of
>a sequence of instructions, and not a call to some (possibly inlined) function.
>I know of NO hardware on which I would consider calls to be reasonable where
>short sequences of code will do the job.

What is the difference between an _inlined_ function and a "short sequence
of code"? Explanation, please.

>It is not the case that the algorithm to be used is the same on different
>machines.  Hardware differences can cause major problems, as was seen when
>cache/paging first came in; ...

This no news.

>1.  Examine a bit, and take some action depending on it.  Also, the next time
>this is to be done, this bit effectively no longer exists.  It is necessary
>to make provision at least somewhere for replenishing the supply of bits.

You are being obscure. What is this if not a shift instruction?

>2.  Find the distance to the next one in a bit stream.  The same considerations
>as above apply.

True. And some hardware has instructions for "find first set bit". The
Vax has, for example. That may be a useful addition, though it's
somewhat specialized. Useful for cryptography, I hear.

>Try coding this in any present language, including assembler, in such a way
>that a compiler can be expected to recognize one of these without being 
>explicitly instructed.

It isn't doable to make a compiler which can recognize _anything_ without
being instructed. If you want an extensible language, you'll have to show how it
can be made extensible. I can assure you that it isn't quite as easy as it
looks.

>I am not saying that this should not be the case.  But it is the user, not
>the language designer, who has to do this.  Whatever language, present or
>future, is used, human beings are going to come up with extremely simple
>operations which the language designers have not thought of, and for which
>doing those operations using the language primitives will be clumsy.

This is utterly obvious.

>The user must be able to instruct the compiler about these operations
>in a manner similar to the way it now looks at addition and multiplication.

OK, you like infix notation.

>If there are competing ways to do something, the compiler must know the
>available variety.  This is even the case for adding vectors in C.

You don't seem to know anything about the problems in what you are
talking about. 

>If this was the case, the hardware was deficient.  To a mathematician, floating
>point arithmetic is a complicated version of fixed point arithmetic.  

Hardware integer multiply should probably be provided for, yes. 

>Have any language designers or hardware designers ever asked for input on the
>variety of operations which are readily understood by people like Silverman,
>Lehmer, etc.?  

Why do you assume that people should come and ask you (a matematician)
about computer language development?  What makes you an expert in the
field? 

Bengt L.
-- 
Bengt Larsson - Dep. of Math. Statistics, Lund University, Sweden
Internet: bengtl@maths.lth.se             SUNET:    TYCHE::BENGT_L