Path: utzoo!attcan!uunet!mcvax!cernvax!hjm From: hjm@cernvax.UUCP (Hubert Matthews) Newsgroups: comp.lang.misc Subject: Re: Many people's opinions on computer languages Message-ID: <822@cernvax.UUCP> Date: 15 Sep 88 09:10:26 GMT References: <3938@enea.se> <923@l.cc.purdue.edu> <382@quintus.UUCP> <402@quintus.UUCP> Reply-To: hjm@cernvax.UUCP (Hubert Matthews) Organization: CERN European Laboratory for Particle Physics, CH-1211 Geneva, Switzerland Lines: 45 One of the main ideas behind high-level languages is to provide a virtual machine that is mostly independent of the low-level hardware. 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. 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. 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. 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 ..... Hubert Matthews