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: Complex Instructions Summary: Wrong analogy Message-ID: <1281@l.cc.purdue.edu> Date: 4 May 89 11:56:40 GMT References: <57252@yale-celray.yale.UUCP> <4101@tolerant.UUCP> <134@dg.dg.com> <2249@pembina.UUCP> Organization: Purdue University Statistics Department Lines: 77 In article <2249@pembina.UUCP>, cdshaw@alberta.UUCP (Chris Shaw) writes: > In article <1277@l.cc.purdue.edu> cik@l.cc.purdue.edu (Herman Rubin) writes: > >In article <504@daitc.daitc.mil>, jkrueger@daitc.daitc.mil (Jonathan Krueger) writes: ....................... > >And what if your users find that the language is inadequate? I know of > >no adequate one. Do not cripple the programmer. > > What if your stock Ford Escort doesn't do 180MPH on the straights? Don't cripple > the driver! What if your 2 micron CMOS gate array doesn't give 0.3 nanosecond > inverter propagation delay with fanout of 8? Don't cripple the logic designer! This is the wrong analogy. YOU are saying that I should not complain if the hardware is not capable of doing everything I want it to. I do complain about this, but not very loudly. I do not ask for technological impossi- bilities, or things requiring great cost. I may ask for better brakes, but not to stop the car from 100mph in 50 feet. But my real complaint has nothing to do with the hardware. You would provide me with detailed instructions about how to get from one location to another, but you would not allow me to use a road map to change the route. You would not even allow me to back the car into the driveway to clean out the garage. The car has a steering wheel. I do not wish to put it under your control. > The point I'm illustrating is that if you want to do something that 99% of the > rest of the world is unwilling to pay for, ......................... What I am asking for is cheap. I am asking that you unchain the steering wheel. > Frankly, I'm getting very tired of reading Herman Rubin's complaints about C, > because he never seems to have a coherent solution. All I see is calls > for someone else to solve his particular problem, coupled with the unspoken > attitude that his particular complaint should have been taken care of long ago. You jump to conclusions and assume more than was stated. I have consistently stated that the best that can be produced is a fair language, and that to produce such a language, the producers must be aware that that is all that it possible. Also, one person cannot produce a language. I am not in a CS department. Funding for people in mathematics and statistics to hire programmers is difficult and niggardly, even to hire students. I have made one concrete suggestion for something which is not a language, but which would make for versatile relatively easy programming. It is a versatile macro processor; maybe one should call it a user-controlled semi-compiler. Let me give an example for the use of a single machine instruction on the CYBER 205. The format of the way I would like to write the macro is c{'z} ={t} {-}{|} a{'x} OP{mod} {|} b{'y} { /\ {~} w} where the {} delineate optional fields. The interpretation of this depends on the types of the arguments, and covers more than 40 instructions, some of which have up to 8 optional bits. For starters, I would like to translate expressions like this into other statements which are in the syntax recognized by a processor. Of course, macros could be recursive. Such a processor would allow me to produce a customized means of writing machine instructions, or sequences of machine instructions, instead of the clumsy assembler mnemonics. With this type of macro assembler, I believe it would be easy to produce good semi-portable code. Since I am customizing the way I write instructions, I expect to have to provide you with the description of what I am doing. We may get groups of people to agree on some of these; that could be called a partial language. I am not asking for the perfect language. I am asking for a means whereby a programmer can use a reasonable notation to tell the modified assembler what instructions to use. It should be possible to use more complicated macros to achieve what the current languages do, and more. The current languages are specialized macro statement languages. -- Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907 Phone: (317)494-6054 hrubin@l.cc.purdue.edu (Internet, bitnet, UUCP)