Path: 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 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)