🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.arch
Article #2455

Re: VLIW Architecture

#2455
From: Herman Rubin
Date: Thu, 05 Oct 1989 12:42
67 lines
4264 bytes
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.
> 
> How about PL-360 and Bliss-10, both of which let you generate any instruction
> you like?  Come to that, how about the C compiler that comes with UNIX in
> System V.3 for the 386, which lets you write assembly-code routines that
> are expanded in-line?  Or how about the SunOS C/Fortran/Pascal/Modula2
> compilers, which have a pass that replaces apparent procedure calls with
> arbitrary assembly code of your choice (specified in .il files) before
> final code optimisation?

I do not believe that the .il approach is quite adequate.  As to the others
you mention, I am unfamiliar with them.  And even that is inadequate; I want
to be able even to introduce overloaded infix operators in addition to the
usual ones. Another feature missing from most languages since day 1 is to
allow the return of a list (NOT a struct).

> 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 would like to be able to travel to any place in the world at low cost
by stepping into a booth and pressing a button.  I would like a computer
which has a rather large number of machine instructions now lacking with
a gigabyte memory, a reasonable screen, good color graphics, a WYSIWYG
editor capable of handling mathematical expressions well, at a cost of $1000.  

These machines do not exist.  Does that mean that I should not use the ones
that are available?  I should not travel by airplane because there are no
teleportation booths?  That I should do no computing because the machines
I would like do not exist?  That I should write no papers because the 
processors I want are not there?  What would O'Keefe do in these situations?

My travel intentions depend on what is available and how long it will take.
I would like to go to more meetings than I do.  So I state that my intention
is to go to such-and-such meetings for X dollars and return home to sleep
each night.  Okay, machines; obey me!

I have clearly stated that the performance of an algorithm depends on the 
hardware, so much so that a single hardware instruction can be crucial.
The current languages do not provide a conceptual model for the operations
which I have thought of.  I ask O'Keefe to tell me how to find his Utopian
machine and language situation for my problems.

> 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.

How can it be otherwise?

-- 
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907
Phone: (317)494-6054
hrubin@l.cc.purdue.edu (Internet, bitnet, UUCP)
Technical Details
Message-ID: <1632@l.cc.purdue.edu>
Path: arc1-ca.pugleaf.net!utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!purdue!mentor.cc.purdue.edu!l.cc.purdue.edu!cik
References: <251FCB3F.12366@maccs.dcss.mcmaster.ca> <1050@m3.mfci.UUCP> <2307@munnari.oz.au>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!purdue!mentor.cc.purdue.edu!l.cc.purdue.edu!cik
From: cik@l.cc.purdue.edu (Herman Rubin)
Newsgroups: comp.arch
Subject: Re: VLIW Architecture
Summary: What if your view is impossible?
Keywords: VLIW
Message-ID: <1632@l.cc.purdue.edu>
Date: 5 Oct 89 12:42:38 GMT
References: <251FCB3F.12366@maccs.dcss.mcmaster.ca> <1050@m3.mfci.UUCP> <2307@munnari.oz.au>
Organization: Purdue University Statistics Department
Lines: 67