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)