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