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 Keywords: VLIW Message-ID: <1637@l.cc.purdue.edu> Date: 6 Oct 89 15:39:36 GMT References: <251FCB3F.12366@maccs.dcss.mcmaster.ca> <1050@m3.mfci.UUCP> <2311@munnari.oz.au> Organization: Purdue University Statistics Department Lines: 144 In article <2311@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) > 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. I admit I am not familiar with .il. How would you do the following: fabs(x) implemented as x &~ CLEARSIGN; where this clears the sign bit, and may depend on the precision of x. No moving of x to specific registers, etc., should be used. < > 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). And suppose I want to use << and >> on double longs? How do I get this in without using any unnecessary memory references, and keeping things which are already in registers there? I want to be able to define a heavily overloaded power operator with a reasonable notation such as a!b or something similar. I see no more reason why I should have to use prenex form for this than I should have to write sum(a,b) instead of a+b. To paraphrase, why should I be a slave to the compiler's notation rather than using familiar mathematical notation? > 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. When computers first came out, most of them would multiply an integer by an integer, giving a most and least significant part. Most of them would divide a double length integer by an integer, giving a quotient and a remainder. > 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.) Getting O(n) may or may not be appropriate. Algorithms for generating non-uniform random variables efficiently tend to be short, but with a fairly intricate structure. They will be used millions of times. The most efficient, from the standpoint of computational complexity, are difficult even knowing the hardware, and may be not even worth programming. Two of my operations are transferring on a bit and "removing" the bit whether or not the transfer occurs, and finding the distance to the next one in a bit stream and "removing" all bits scanned. These are tools, as basic as addition. As for not worrying about those stupid little details about multiple precision arithmetic, it is the difference between factoring a large number in a month and several years. I can give algorithms which anyone who understands even what is taught in computing will understand, but which the HLLs cannot express. In a university, it is almost impossible to get programming assistance in mathematics and statistics. Also, these supposedly highly optimizing compilers do not seem to be available. I doubt that I would have any more difficulty in writing a decent machine language than any HLL, because a decent machine language would be weakly typed and overloaded operator. > 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. When I design an algorithm, I _have_ to know. O'Keefe wants to master his language completely, but he is a slave to the language, whether or not he knows it. I will use different algorithms on different computers, and have no problem keeping them straight. I find it no problem whatever in seeing how the hardware interacts with the algorithm and exploiting it. -- Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907 Phone: (317)494-6054 hrubin@l.cc.purdue.edu (Internet, bitnet, UUCP)