Path: utzoo!attcan!uunet!pyrdc!netsys!ames!lamaster
From: lamaster@ames.arc.nasa.gov (Hugh LaMaster)
Newsgroups: comp.arch
Subject: Re: Software Distribution
Message-ID: <15440@ames.arc.nasa.gov>
Date: 24 Sep 88 18:43:58 GMT
References: <5655@june.cs.washington.edu> <340@istop.ist.CO.UK>
Reply-To: lamaster@ames.arc.nasa.gov.UUCP (Hugh LaMaster)
Organization: NASA Ames Research Center, Moffett Field, Calif.
Lines: 71

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
:
>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).  Use of these
>specifications may reduce performance on some architectures so the IL
:
>Good though this would be for the advancement of Computer Science I
>cannot see it being commercial.  That is, I could not imagine a
>
>
>
>
>
>
>
>
>
>
>
>
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.

Request: If anyone is actually contemplating creating such a fairly
portable IL, please include linear arrays (of whatever your basic data 
types are) in your IL, so people can write conforming
vectorizing front ends and vector generating code generators.

The cost of including it in the IL is practically nil.  It is trivial to
generate code for a non-vector machine from vectorized IL, and, in fact,
it makes certain optimizations much easier, so it will usually result in
faster code on pipelined machines.  Non-vectorizing front-ends will still
work just fine on vector machines (the generated code will not be as fast
as possible, of course).

Also, please do not make assumptions about the size of addresses, or the
interchangeability of integers, addresses, chars, or floating point, 
in your IL.  It should not be necessary, and, a smart code generator 
will be able to optimize as necessary for specific architectures.

Please note that CDC has presumably come up with an IL which is portable
in the above sense: 
In order to solve the MxN problem for their machines, they decided to
build a set of compilers around common, portable front ends (written
in a common C-like (but not C) language), with vector constructs, and
with the ability to target multiple back end machines with different
integer and address sizes ( I believe all the target machines have 
64 bit floating point, but I don't know if any assumptions are made there).
Anyway, I don't know if the IL has been published.  I am sure the compilers
haven't been! (How many person-years of development?)  Anyway, I think
that this, and other examples, may be an existence proof.  But there are
many subtleties to defining a portable IL, and I don't think it is a trivial
job. 
 


-- 
  Hugh LaMaster, m/s 233-9,  UUCP ames!lamaster
  NASA Ames Research Center  ARPA lamaster@ames.arc.nasa.gov
  Moffett Field, CA 94035     
  Phone:  (415)694-6117