Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!gem.mps.ohio-state.edu!ginosko!uunet!munnari.oz.au!cs.mu.oz.au!ok From: ok@cs.mu.oz.au (Richard O'Keefe) Newsgroups: comp.arch Subject: Re: VLIW Architecture Keywords: VLIW Message-ID: <2311@munnari.oz.au> Date: 6 Oct 89 05:23:26 GMT References: <251FCB3F.12366@maccs.dcss.mcmaster.ca> <1050@m3.mfci.UUCP> <1632@l.cc.purdue.edu> Sender: news@cs.mu.oz.au Lines: 88 In article <1630@l.cc.purdue.edu>, cik@l.cc.purdue.edu (Herman Rubin) complained that he had "seen no language designed for the efficient use of hardware operations". In article <2307@munnari.oz.au>, ok@cs.mu.oz.au (I) listed several languages (PL-360, Bliss-10, SunOS C) which provide full access to all hardware instructions. In article <1632@l.cc.purdue.edu>, cik@l.cc.purdue.edu (Herman Rubin) replied > I do not believe that the .il approach is quite adequate. What, precisely, can it not do? Admittedly, this approach relies on the back-end optimiser being able to handle any assembly code you throw at it, but then, so must any scheme giving you access to all the operations. > As to the others > you mention, I am unfamiliar with them. And even that is inadequate; If you don't know them, how can you know they are 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). Having used Fortran, Algol, SNOBOL, Lisp, Prolog, APL, COBOL, PL/I, and lots of other languages, I gave up thinking that the syntax of programming languages had any great importance a long time ago. I should have mentioned Ada as one of the languages which provides full machine access; it has both assembly code inserts and overloaded operators. I don't know precisely what Rubin means by returning a list; Algol 68 permits the return of anything (except pointers into the local frame). The reason that most languages don't return lists is precisely that they are designed to let the hardware show through, and you can't fit much in a register. I wrote > 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. Rubin replied that he would like transmatters and the ultimate computer. > 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? Why, I would do the same as I do now. Nowhere in the text cited above do I say that machines should be ideal! The language's job is to conceal the deficiencies of the computer. The computer can only do 32-bit arithmetic? Then it is the language's job to implement arbitrary-precision integers on top of that and not bother me with stupid little details. For a more common example, I really do not want to be bothered with the MC68010 limitation that a shift-by-literal can shift by at most 8. (I have used a language where this limit showed through, and I did _not_ like it.) A C compiler papers over this limit, and so it should. I normally use a language which runs 2 to 4 times slower than C; I do this gladly because the reduction in _language_ complexity means that I can manage more complex _algorithms_, and win back O(n) speed that way. (Yes, such algorithms can then in principle be recoded in C. But it is much harder to _develop_ complex algorithms in complex languages.) I wrote > 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. Rubin replied: > How can it be otherwise? But that's _my_ point; letting the hardware show through is precisely what _he_ is asking for, and _that_ is the problem! This is not unlike the RISC/CISC debate. I want simple regular languages (C is a monster of complexity) which I can master completely. I don't care whether it's a ROMP or a WM or a /360 underneath. I particularly don't want to _have_ to know.