Path: utzoo!attcan!uunet!lll-winken!lll-tis!mordor!joyce!ames!mailrus!tut.cis.ohio-state.edu!bloom-beacon!bu-cs!purdue!i.cc.purdue.edu!k.cc.purdue.edu!l.cc.purdue.edu!cik From: cik@l.cc.purdue.edu (Herman Rubin) Newsgroups: comp.lang.misc Subject: Re: Many people's opinions on computer languages Summary: Subroutine calls are unacceptable Message-ID: <929@l.cc.purdue.edu> Date: 16 Sep 88 20:47:24 GMT References: <3938@enea.se> <923@l.cc.purdue.edu> <382@quintus.UUCP> <822@cernvax.UUCP> Organization: Purdue University Statistics Department Lines: 105 In article <822@cernvax.UUCP>, hjm@cernvax.UUCP (Hubert Matthews) writes: > > One of the main ideas behind high-level languages is to provide a virtual > machine that is mostly independent of the low-level hardware. Whose virtual machine? Just as I find that a student who has had a statistical methods course has a much harder time understanding statistical concepts than one who does not, I suspect that someone who learns to program in a highly restricted language will never understand what hardware is capable of and can be capable of. My virtual machine would have all operations that can be thought of, not just the ones I can imagine. > So, trying > to make a language that allows full access to the low-level destroys this > abstraction which language designers have fought so hard to achieve. If > Herman wants machine features, then why does he insist on using a high-level > language which, by its very nature, is designed to rid him of having to > be concerned about such things? Destroying this illusion makes such code > much more difficult to understand as the machine environment must be included > as well as the semantics of the language. Why do you think that assembler > is so much less portable than an HLL? That is the major issue here; the > level of abstraction. I agree completely that machine language is less portable. I find that the assemblers use unnecessarily messy code, with an unnatural format which is designed to be easy for the machine. A weakly typed overloaded operator infix notation language would do well; C is partly in that direction, C++ a little more so (and would be much better if additional operators could be introduced), but I know of no reasonable implementations. > On a slightly less ethereal level, if Herman wants a 32 x 32 -> 64 multiply > instruction, then I suggest that the real problem is not that the language > doesn't let him specify this particular instruction, but that the language > doesn't let him specify his data to a sufficiently high degree. PL/I allows > a declaration including the number of bits of storage. Occam allows BYTE, > INT, INT16, INT32 and INT64 (so the 32/32 -> 64 will work) for integer types. > What should be done to circumvent this is to force all integer variables to > be declared using ranges, so that the abstraction is retained by implying > that you don't particularly care how something is done, as long as it is > done. Herman could then declare i,j : -2**31..2**31-1 and k : -2**63..2**63-1 > and expect a decent compiler to pick the right machine instructions to do > > k := i * j > > as a 32*32 -> 64. I have seen no decent compilers. Actually, your idea of typing integers quite agrees with mine, except that I am not sure that ranges are needed so much, and you do not go far enough. You also seem to go along with overloaded operators; if you read K&R, you will find that no consideration is given to product being done in such a way that the type of the result is not the type of the factors actually multiplied. My idea of an overloaded operator assembler would do this if the types are as stated and the operation is either hardware on the appropriate storage classes or defined in a macro. This is what is not available in languages and compilers, and I know of no overloaded assemblers. There is "standard" software which gives conditional definitions given machine parameters; the definition of multiplication should be such that the user can supersede the compiler if the compiler does not do the right thing. > If you want to use other, more perverse, instructions, then why not use small > functions to do it. On VMS, there are several function such as LIB$INSQHI > to access some of the special instructions *that are peculiar to the VAX*? > (There is even a LIB$EMUL for doing 32*32 -> 64 multiplication :-) ). > Put such things in a library - don't junk up a language to do it. The cost of a subroutine call is so high that it usually pays to use a much worse procedure. In every implementation of C that I have seen, abs is a subroutine call, and it is necessary to have a separate fabs for floating. At least on every machine I know, the inline absolute value would not only be faster but even shorter. LIB$EMUL uses at least 4 instructions in the program doing the call (I would have to check out if it would take 6) to accomplish the results of one, not counting the 4 instructions used by the subroutine. Thus, even if the subroutine call were very fast (which it is not), 8 instructions are run instead of one. > No other > machine that I can think of has interlocked queue instructions, so what use > is carrying around VAX stuff in a language that is to be used on 68k/*86 > and any other type of stuff. I don't want to pay (in terms of compiler cost > and complexity, bugs and size) for your little, one-off, instruction hacks. > That's one of the good things about K&R C. Everything's in libraries, so > I don't have to use your stuff if I don't want it. Don't destroy my > abstraction for your "do it all in one instruction" bodge. I want a lean, > mean, hungry and beautiful language and not a kludge-up like C or PL/I or > ADA or FORTRAN or ..... I am willing to give up a lot to get a powerful, mean, hungry and beautiful language. Your lean language is undernourished so much as to be feeble. I am willing to give up the denial of registers, the use of operator precedence, the inability to control storage, etc. BTW, I have never used the queue instructions, or even the decimal instructions, so I would not use that part of the language. But I see no reason why the arithmetic operations should not be overloaded to include the decimal operations. I do not want a computerized automobile which will take me to a street address by an automatic route. I want to be able to reroute it around rush hour traffic if I think I know a better way. And I want to be able to back the car out of the garage into the driveway to clean out the garage. > > Hubert Matthews -- Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907 Phone: (317)494-6054 hrubin@l.cc.purdue.edu (Internet, bitnet, UUCP)