Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!bbn!drilex!dricejb
From: dricejb@drilex.UUCP (Craig Jackson drilex1)
Newsgroups: comp.arch
Subject: Re: VLIW Architecture
Keywords: VLIW
Message-ID: <5159@drilex.UUCP>
Date: 6 Oct 89 13:28:49 GMT
References: <251FCB3F.12366@maccs.dcss.mcmaster.ca> <1050@m3.mfci.UUCP> <1630@l.cc.purdue.edu> <2307@munnari.oz.au>
Reply-To: dricejb@drilex.UUCP (Craig Jackson drilex1)
Organization: DRI/McGraw-Hill, Lexington, MA
Lines: 55

In article <2307@munnari.oz.au> ok@cs.mu.oz.au (Richard O'Keefe) writes:
>In article <1630@l.cc.purdue.edu>, cik@l.cc.purdue.edu (Herman Rubin) writes:
>> If the language the compiler compiles does not have the operations to be used
>> in my program, I cannot use them.  I have seen NO language designed for 
>> the efficient use of hardware operations.  The choice of the algorithm 
>> depends on the hardware, and there can be lots of different algorithms.
>
>Herman Rubin clearly enunciates a policy which I believe is responsible
>for much of the unreliability of present-day software:
>	the machine is what it is,
>	the programmer's job is to exploit the machine,
>	the language's job is to expose the machine to the programmer.
>The view that I take is
>	the programmer's job is to express his intentions clearly,
>	the machine's job is to obey the programmer,
>	the language's job is to provide a *simple* conceptual model.
>Rubin is willing to be the servant of his machines.  I'm not.
>I've exchanged E-mail with a floating-point expert who had some
>illuminating things to say about the work being done for Ada; it turns
>out that they can do amazing things without needing to know the details
>of the hardware instructions, but what does hurt them is the extent to
>which Ada already lets hardware vagaries show through.

I think you have probably guess Herman Rubin's view pretty well (I don't
know him).  It is a view which was very common up until around 1980,
when computers finally began to be fast enough for many uses.  (Before then,
there were few users who really thought the computer that they worked on
was fast enough.)  I choose 1980 because that is when the VAX 11/780 and
the 4341 became common; before those machines, few organizations had
more than one 32-bit machine with more than one MIPS or so of power.

Your view is conventional wisdom in computer science today, partially
driven by the common surfeit of computational power available today.
When there is enough computing power so that few tasks run into
compute-hours, and compilers are good enough to translate rather
abstract programming languages to good-enough machine code, this is a
reasonable idea.

I think that the difference is that Mr. Rubin still doesn't see himself
as having a surfeit of computing power available to him.  I am not familiar
with his area of work, but I know that there remain many problems which
still cannot be solved in reasonable time by today's fastest computers.
When you are at the bleeding edge of technology, you *do* want to know
about the relative speeds of various instructions, and other capabilities
of the processor.  It might make a difference if multiply were 3 or 10
times faster than divide--a differences of minutes, if not hours.  If
your compute times were on that order, you would care about how you used
the underlying hardware.

We should be thankful for the people at the bleeding edge of computability
--it is they who keep the MIPS (VUPS, whatever) increasing every year...
-- 
Craig Jackson
dricejb@drilex.dri.mgh.com
{bbn,ll-xn,axiom,redsox,atexnet,ka3ovk}!drilex!{dricej,dricejb}