Path: utzoo!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: Bandwidth and RISC vs. CISC Summary: Who to blame? Message-ID: <1267@l.cc.purdue.edu> Date: 29 Apr 89 11:34:05 GMT References: <38853@bbn.COM> <423@bnr-fos.UUCP> <288@ctycal.UUCP> <1984@trantor.harris-atd.com> Organization: Purdue University Statistics Department Lines: 88 In article <1984@trantor.harris-atd.com>, chuck@melmac.harris-atd.com (Chuck Musciano) writes: > Oh well, into the breach... > > In article <1262@l.cc.purdue.edu> cik@l.cc.purdue.edu (Herman Rubin) writes: > >No apologies are due to the compiler writers. Rather, criticism is due to > >them for the arrogance they took in leaving out the possibility for the > >programmmer to do something intelligent. The HLLs are woefully inadequate, > >and I would not be surprised that the ability to do intelligent coding using > >the machine capabilities may be destroyed by learning such restrictive coding > >procedures first. > > Some misdirected flames here. If you want to blame anyone, blame the > language designer, not the compiler writer. Us poor compiler writers just > sit around, horrified, as the hardware guys take more and more of the hard > part and give it to us. :-) Not all blames go to the language designer. The implementation of asm in C can be done to give much more benefit to the programmer. The implementation knows where the variable xyz is and can substitute it in the assembler instruction. This has nothing to do with the language. And this atrocious use of underscores! Why should C prefix an underscore to all its names for systems purposes? I know the reason, but I cannot respect the intelligence of those who did not take the other action. If we have programs created by several languages, we should have no more than a calling sequence problem, not a name problem. If I call a buffer refill program with the calling sequence I advocate, passing the pointer descriptor, it should make no difference whether the subroutine is written in Fortran, C, Pascal, APL, or anything else, and it should make no difference whether it is called from any of those languages. If they all prepended an underscore, and each could use the others' names, it would not be too bad. But some Fortrans leave the name alone, some prepend and postpend, Pascal does not allow underscores in the middle of a name, etc. > If you dislike the current crop of HLLs so much, you are free to design > your own. As one who has designed and implemented several languages on a > variety of systems, I know how easy it is to take potshots at the language > implementors. Go through the loop yourself, and then complain. Designing > anything which will please some segment of the world is very difficult. > Designing a language which is elegant, orthogonal, easy to learn and use, > easy to implement on a variety of machines and that will appeal to a large > number of users is almost impossible. I am asking for one thing you have left out; it should be able to write efficient code. I will throw out elegant and orthogonal completely. If the machine is not orthogonally designed, why should the language be. And most machines are not. The first thing needed is a macro assembler in which the "macro name" can be a pattern. For example, I would like x = y - z to be the =- macro. Allow the user to use these ad lib. This way the language can be extended. The #defines, and even the user-overloaded operators in C++ do not achieve this. If a machine instruction is complicated, it may be necessary to have a complicated design, as well as type overrides, etc. An example from the CYBER 205 is the following large class of vector instruction, where A or B can be either vector or scalar. There are many options in this, and I point this out. C'W =t -|A'X opmod | B'Y /\ ~ W 11 2 34 55 666 7 88 99 a 9 notice that I have 10 options for each opcode (someone might say that option 6 is part of the opcode, but there are natural defaults). Since this is a single machine instruction on this machine, I MUST be able to use it, and I do not wish to have to use the clumsy notation provided by the "CALL8" procedures. I do not claim that this is optimal notation, and I would expect you to write it somewhat differently. For example, you could always leave out the /\; I put it in merely for clarity. The best semi-portable procedures for generating such random variables as normal are easily described. Coding them on a CYBER 205 efficiently is trivial. Coding a slightly different version of them on an IBM 3090 is not difficult. Coding them (any version) on a CRAY X-MP is an interesting challenge. Coding them on a CRAY 1 is a major headache, and not vectorizable for much of the procedure. These vector machines are that different. So should the code be easy to implement on a large variety of machines? But the programmer who does not understand the machine cannot code well on that machine. Some C-like language with macro augmentation is probably the answer. But types and operation symbols should be introduced by the user at will. And all manners of arrays should be included, and whatever else the user can come up with. -- Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907 Phone: (317)494-6054 hrubin@l.cc.purdue.edu (Internet, bitnet, UUCP)