Path: utzoo!attcan!uunet!husc6!mailrus!purdue!i.cc.purdue.edu!k.cc.purdue.edu!l.cc.purdue.edu!cik
From: cik@l.cc.purdue.edu (Herman Rubin)
Newsgroups: comp.arch
Subject: Re: Software Distribution
Summary: Vector processors are not compatible.  Too much is missing.
Message-ID: <944@l.cc.purdue.edu>
Date: 25 Sep 88 11:14:21 GMT
References: <5655@june.cs.washington.edu> <340@istop.ist.CO.UK> <15440@ames.arc.nasa.gov>
Organization: Purdue University Statistics Department
Lines: 47

In article <15440@ames.arc.nasa.gov>, lamaster@ames.arc.nasa.gov (Hugh LaMaster) writes:
> In article <340@istop.ist.CO.UK> itcp@ist.CO.UK (News reading a/c for itcp) writes:
> :
> >I have felt in my bones that an efficient Intermediate Language for
> >conventional processors (MC680xx, iAPX386, VAXen, NS32xxx and all RISC
> >architectures) is realistic proposition. This discussion has encouraged me

An intermediate language should exist, which should include everything that
these machines and others can do.  But we should realize that many, if not
most, machine operations do not exist on many machines.

> >As people have noted it has to have something like the functionality of
> >C, only with extensions to allow (where the source language required
> >it) the specific semantics of a data type (storage size and address
> >alignment) and operation (precision of operation).

The differences are even greater.  There are operations which are hardware
on some machines, and which are so clumsy, difficult, or expensive on others
that any decision as to whether or not to use them should be highly machine
specific.  I know of no machine for which I would attempt to restrict a
programmer to HLLs.

			..............

> I know many people will argue with this, so, feel free to argue - 
> but here goes anyway (Hugh LaMaster's $.02):
> 
> Prediction: In 4-6 years vector microprocessors will be "conventional"-
> they will not have replaced current architectures, but they will be out there,
> and will be fairly cheap.

I agree that vector microprocessors will be fairly cheap.  But which type of
architecture?  I am familiar with several of them.  I have used the CYBER 205,
and it has useful instructions which are not vectorizable at all, or vectoriz-
able only with difficulty and at considerable cost, on vector register
machines.  Or will we be using massive parallelism?  Try procedures which
are necessarily branched on vector or (even worse) parallel processors.
Some of them can be reasonably done on stream machines, but they are likely
to be difficult on vector register machines, and almost unworkable on SIMD
machines.  An IL should be highly expressible and with an easy-to-use (from
the human standpoint) syntax.  But if it is good, many of its features will
be directly usable only on few machines.  There seems to be more useful
constructs, Hugh, than are in your philosophy.
-- 
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907
Phone: (317)494-6054
hrubin@l.cc.purdue.edu (Internet, bitnet, UUCP)