NetNews Usenet Archive 1992 #20/NN_1992_20.iso/spool/comp/edu/1558

Internet Message Format | 1992-09-08 | 3.9 KB

Xref: sparky comp.edu:1558 comp.arch:9255 comp.lang.misc:2955
Path: sparky!uunet!gatech!purdue!mentor.cc.purdue.edu!pop.stat.purdue.edu!hrubin
From: [e-mail] (Herman Rubin)
Newsgroups: comp.edu,comp.arch,comp.lang.misc
Subject: Re: Scientists as Programmers (was Re: Small Language Wanted)
Message-ID: <[e-mail]>
Date: 6 Sep 92 18:03:04 GMT
References: <[e-mail]> <[e-mail]> <amos.715786635@shum>
Sender: [e-mail] (USENET News)
Organization: Purdue University Statistics Department
Lines: 63

In article <amos.715786635@shum> [e-mail] writes:
>[e-mail] (Herman Rubin) writes:

>>The present compilers translate such things as +, *, &, etc., into
>>some version of assembler.  Why not allow the user to say how other
>>operations will be similarly translated, and add them to the list?
>>These operations often produce temporaries; why not tell the user
>>how this is done, and let them be added to the list?  These would
>>not really complicate the language design or the compiler, except
>>insofar as precedence is affected.

>You want C++, then; or the GNU compilers, which do allow you to dive
>into the compiler's source and create whatever language extensions you
>wish to.  The problem is, you'll have no time left in which to do the
>job originally intended...

I know that C++ does not have this capability.  There are other useful
operations not conveniently defined in terms of the usual primitives.
Among these are fairly simple operations such as getting the next bit,
or getting the distance to the next 1, or even branch on overflow,
intended not as an exception, but as a common occurrence.  Also,
for operations like looking at the next bit, having some preparatory
work done before it is needed in a loop, so that the pointers do not
have to be continually checked.  But even standard Boolean operations
are not always best defined in terms of the C primitives.

Someone asked why a particular machine had an instruction which was,
in effect, z = max (0, a-b).  Why not?  How much does this add to the
cost in hardware?  Now a compiler might recognize it, but a language
designer, looking a "typical" code in other people's programs, would
never see that there is another operation.

>The point is, we can use very simple and flexible meta-tools like
>assembler or FORTH to create our own tools - and end up each using a
>personal hand-tailored language, unique and non portable; or use a
>standard tool which does implement some constructs efficiently and
>portably, but never all we'd ever need.

Things like the above can often be portably written, but very little
is completely portable other than character manipulation or exact
integer arithmetic.  Even writing these portably might get the
hardware designers to put back some of the features which are no
longer present, like good fixed-point arithemetic, because the
language designers do not seem able to see the need for them.
These are features which cost little in hardware, but very much
in software.

Even the operations of + and * are not completely portable across
machines, especially in floating point.

One of my students came up with the following, which is a much more
common situation than most believe.  It is desired to read an element
from a buffer location, with an interrupt if the buffer empties.  Now
this is very much like reaching a cache page boundary, but a user
program is needed to correct this exception.  Since the hardware
for handling this, and some of the software, is essentially already
in place, could it not be extended?  With the present setup, only with
considerable difficulty; at design time, easily.
--
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399
Phone: [phone]
[e-mail] (Internet, bitnet)
{purdue,pur-ee}!pop.stat!hrubin(UUCP)