Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ukma!rutgers!att!alberta!cdshaw From: cdshaw@alberta.UUCP (Chris Shaw) Newsgroups: comp.arch Subject: Re: Complex Instructions Message-ID: <2254@pembina.UUCP> Date: 7 May 89 02:26:21 GMT References: <57252@yale-celray.yale.UUCP> <4101@tolerant.UUCP> <134@dg.dg.com> <2253@pembina.UUCP> <1287@l.cc.purdue.edu> Reply-To: cdshaw@pembina.UUCP (Chris Shaw) Organization: U. of Alberta, Edmonton, Alberta, Canada Lines: 103 HR>In article <1287@l.cc.purdue.edu> cik@l.cc.purdue.edu (Herman Rubin) writes: me>In article <2253@pembina.UUCP>, cdshaw@alberta.UUCP (Chris Shaw) writes: 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.... HR>So we should not train professional sports figures. We should not produce HR>Ph.D.'s. We should not produce professional programmers. We should not HR>produce doctors. More than 99% of the population is unable to use the HR>training and education for these fields. Therefore we should not provide HR>it for those who can use it. This corellation is too fallacious to be taken seriously. The training of professionals has demonstrable value to society, so society as a whole pays some of the expense for such training. By contrast, SL is an unproven concept. It's not even clear that its goals are achievable. The burden of proof for SL therefore rests upon its advocates. Therefore, they must pay all costs. HR>But what if only junk is portable? We agree on the technical aspects of SL, but we fundamentally disagree on its worth. HR wants a language and compiler system that programs as well in assembler as is humanly possible. He wants maximum efficiency. If necessary, machine-specific detail must be provided, since the paramount goal is speed. My point is that with a specification such as this, HR is really looking for a more friendly assembler, since the machine specific statements that MUST be provided for (say) the 205 are useless on the 3090. In other words, one must state the algorithm differently for each target machine. This is called unportability. So why not just use 205 assembler and not bother with SL at all? Well, I can see a few reasons why you'd want SL -- control, storage allocation, etc. But if half your code is 205 specific, then you're wasting your time with a high level language. A syntactically-sugared assembler is still an assembler. Why is portability important? Because one might want to run your program on a machine different from the one you originally wrote it for. HR>You (CDS) would insist that a good program on a machine, easy to envision, HR>not be used because another machine cannot use it efficiently. I have no idea where HR got this from what I was saying. What I'm saying is that this mythical easily-envisioned program must be written in one language that can be compiled on all machines. If for the sake of speed, the program is really 7 programs mutually excluded by #ifdefs, then this program could be better written in the assembly language for each of those 7 machines. In fact, if it's 7 different programs, then the choice of language is moot. The specifics of the compiler and the machine matter a lot more than the features of the language itself. HR>It is not the problem of getting people to agree it is worthwhile. I can do HR>that. (but) the NSF budget does not permit the funding of enough faculty.. Well, it would seem that SL is low on the list of priorities. A pity, perhaps, but I think that HR is tilting at windmills. me>I'd wager that the grail --portable and maximally efficient-- is impossible. HR>I agree. But semi-portable and close to efficient is not impossible. You HR>may have to abandon an algorithm completely on some machines. Then this is UNportable, and for good reason. HR's example of correct random numbers shows that you can't do some things portably. Fine. This is no different than device driver code. But if HALF your code is device driver code, why bother with portability at all? You can have portability or speed. Not both. The boundaries are being pushed, but I don't thing that a syntactic patch-up job will do what you want. HR>There is a heck of a lot of portability which can be achieved, but not in any HR>of the current HLLs. The problem of adding vectors is portable, but the C HR>code to do it efficiently on one machine is inefficient on another. I think this might have a lot to do with a lack of consensus on what is a "good" vector add instruction. Or maybe the C compiler sucks on one of the machines. Sue the compiler manufacturer. It's not the language's fault. Anyway, QUANTIFY "heck of a lot". Quantify that across 3 machines. You may be able to hand compile your C program nicely, but can a program (or 3 programs) do it? HR>But C does not handle transfers too well. There are situations where what is HR>wanted is a branch to subroutine, not a subroutine call. C does not handle HR>this at all. And what about a recursion in which HR>one wishes to force the use of quantities unchanged in registers? This is bogus. The implementation of a subroutine call is up to the compiler writer, and a bad implementation does not imply that C is bad. HR>There may be similarities, but full portability is totally incompatible HR>with even fair efficiency. Exactly. So what's your point? You want your cake and eat it too, it seems, and are crying because nobody will deliver. Tough bananas. Prove how stupid the rest of the world is, and come up with a better alternative. I doubt you can do it, because the maximal use of a particular machine probably requires too much specific and hence non-portable information about that machine. If portability is not your goal, then who cares? Assembler fits your bill. >Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907 -- Chris Shaw cdshaw@alberta.UUCP (or via watmath or ubc-vision) University of Alberta CatchPhrase: Bogus as HELL !