Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!purdue!mentor.cc.purdue.edu!l.cc.purdue.edu!cik From: cik@l.cc.purdue.edu (Herman Rubin) Newsgroups: comp.arch Subject: Re: Complex Instructions Summary: All machines are not the same. Perfect portability is not desirable. Message-ID: <1287@l.cc.purdue.edu> Date: 6 May 89 13:10:23 GMT References: <57252@yale-celray.yale.UUCP> <4101@tolerant.UUCP> <134@dg.dg.com> <2253@pembina.UUCP> Organization: Purdue University Statistics Department Lines: 119 In article <2253@pembina.UUCP>, cdshaw@alberta.UUCP (Chris Shaw) writes: > In article <1281@l.cc.purdue.edu> cik@l.cc.purdue.edu (Herman Rubin) writes: > me>In article <2249@pembina.UUCP>, cdshaw@alberta.UUCP (Chris Shaw) writes: > HR>>In article <1277@l.cc.purdue.edu> cik@l.cc.purdue.edu (Herman Rubin) writes > HR>>>And what if your users find that the language is inadequate? I know of > HR>>>no adequate one. Do not cripple the programmer. > > me>> > > HR>This is the wrong analogy. I do not ask for technological impossi- > HR>bilities, or things requiring great cost. > > On the contrary, special cases that HR desires DO come at great cost. Read on. > > HR>The car has a steering wheel. I do not wish to put it under your control. > > Granted. Of course, cars aren't computers, so chasing this analogy is a waste of > time. Explaining an analogy is worse than explaining a joke. > > me>>The point I'm illustrating is that if you want to do something that 99% of > me>>the rest of the world is unwilling to pay for.... So we should not train professional sports figures. We should not produce Ph.D.'s. We should not produce professional programmers. We should not produce doctors. More than 99% of the population is unable to use the training and education for these fields. Therefore we should not provide it for those who can use it. > HR>What I am asking for is cheap. I am asking that you unchain the steering > HR>wheel....Also, one person cannot produce a language.... > > I dispute this. Many one-person languages exist and are in use today. A one > person language has the advantage of conceptual wholeness. Now I admit, it won't > be easy to create SL all by yourself, but if it was easy, your solution would > be for sale on PC's for $75. Or you could hack it in an afternoon. If you think I want a language for statistics, you are wrong. I want a language in which a lot of things in mathematics and statistics can be done. And I do not want the language to restrict my thinking. You want a program to be portable. But what if only junk is portable? You would insist that a good program on a machine, easy to envision, not be used because another machine cannot use it efficiently. > HR>I am not in a CS department. Funding for people in mathematics and statis- > HR>tics to hire programmers is difficult and niggardly, even to hire students. It is not the problem of getting people to agree it is worthwhile. I can do that. It is the fact that universities will not fund things in mathematics and statistics; they insist that the money be obtained from the government. And the NSF budget does not permit the funding of enough faculty, and graduate students are more expensive than faculty. We have no problem getting computing time, but no faculty member in our department can get non-routine programming help. And we are considered one of the top statistics departments. >. It's going to be expensive, because you can't amortize the development > cost over a lot of customers. > > HR>I have made one concrete suggestion for something which is not a language,but > HR>which would make for versatile relatively easy programming. It is a versatile > HR>macro processor; maybe one should call it a user-controlled semi-compiler. I believe that I could do this with one CS hacker in a few months. > HR>...an example for the use of a single machine instruction on the CYBER 205... > > I think that HR's goals conflict. He wants something portable but at the same > time able to maximize machine performance. In other words, you need an > expression syntax that is able to encompass all available modifications of > a particular 205 instruction, plus all mods for Cray, plus SX-1, etc. > But at the same time, portability is desired. What if 205 option A is not > available on Cray? What do you do? Cut the expression into inefficient little > bits? How is this different from normal C code? > > I guess my point is that if you only want nifty expressions for the 205, you're > simply asking for a spoonful of syntactic sugar, assuming that the #asm > thing allows proper data structure access. If the compiler-asm link is > inadequate, then this is probably a straightforward system fix. I'd wager that > the grail -- portable and maximally efficient -- is impossible. I agree. But semi-portable and close to efficient is not impossible. You may have to abandon an algorithm completely on some machines. In some cases the algorithm may have to be entirely abandoned. This is especially the case in generating random variables, where it is the method which must be correct, NOT the answer. The CRAY-1 is so bad I consider it a basket case for vectorization. I would suggest connecting a mini, or even a micro, to do this part of the job. The algorithm I would use on the 205 differs from what I would use on the IBM 3090; the 205 algorithm could be implemented on the 3090, but would be decidedly more costly. Implementing the 3090 algorithm on the 205 would require breaking up the vector into short pieces, which is required on vector register machines such as the 3090 and CRAY, but is not required on vector stream machines such as the 205. But to me, these considerations are immediate and obvious. > HR>I am asking for a means whereby a programmer can use a reasonable notation to > HR>tell the modified assembler what instructions to use. > > Machine specific, unportable, and therefore window dressing, unless you are > content with giving hints only. But this means you have to say the same thing > twice. A hard problem. There is a heck of a lot of portability which can be achieved, but not in any of the current HLLs. The problem of adding vectors is portable, but the C code to do it efficiently on one machine is inefficient on another. In this respect C is too low level. The same holds for string management. But C does not handle transfers too well. There are situations where what is wanted is a branch to subroutine, not a subroutine call. C does not handle this at all. Here C is too high level. C can do recursion, but not coroutines. And what about a recursion in which one wishes to force the use of quantities unchanged in registers? The ideal language does not exist, and never will. Portability means using the same strategies with the automobile and airplane as with the horse and buggy. There may be similarities, but full portability is totally incompatible with even fair efficiency. -- Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907 Phone: (317)494-6054 hrubin@l.cc.purdue.edu (Internet, bitnet, UUCP)