Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watmath!clyde!cbosgd!ihnp4!ptsfa!ames!hao!boulder!sunybcs!rutgers!im4u!ut-sally!utah-cs!utah-gr!uplherc!esunix!bpendlet From: bpendlet@esunix.UUCP Newsgroups: comp.lang.c,comp.misc Subject: Re: 32bit = 16bit x 16bit (Really: Compiler deficiencies) Message-ID: <546@esunix.UUCP> Date: Wed, 28-Oct-87 10:00:31 EST Article-I.D.: esunix.546 Posted: Wed Oct 28 10:00:31 1987 Date-Received: Sat, 31-Oct-87 19:49:52 EST References: <593@l.cc.purdue.edu> Organization: Evans & Sutherland, Salt Lake City, Utah Lines: 54 Xref: utgpu comp.lang.c:4963 comp.misc:1378 in article <593@l.cc.purdue.edu>, cik@l.cc.purdue.edu (Herman Rubin) says: > Xref: esunix comp.lang.c:4825 comp.misc:1454 > > In article <146MAXHAM@RICE>, MAXHAM@RICE.BITNET (Mark Maxham) writes: >> But the 68000 MULS and MULU commands multiply two sixteen bit words >> into a 32 bit longword. Thus they are defined. Is the question >> how C translates from multiplicitive expressions into actual machine >> instructions? >> >> Mark Maxham maxham@icsa.rice.edu >> > > A general problem with HLL's is that they do not have the necessary > flexibility to handle situations like this. I do not know of any language > which has in its operation list an operation to multiply two 16 bit object > and get a 32 bit object. Whether or not you consider forth to be a high level language is a matter of taste. But, in the last version of the forth standard that I read ( quite old actually ) there was an operator named */ that multiplies two 16 bit ints giving a 32 bit int and then divides by a 16 bit int to give a 16 bit result. not quite what you asked for, but very close. > I know > of no way to tell the compiler that here is an operation with a given syntax, ^^^^^^ I think the term you are looking for here is "signature", the name of the operator, plus the number of arguments, the type of the arguments, the order of the arguments and type of the result. > and the compiler should put it in its set of operations. If the syntax is > different from other syntaxes for that operator, the compiler should perform > the overloading. It is clear that the languages need more flexibility > and that the gurus who claim that they have the solutions are wrong. Operator overloading has been implemented in many compilers. It is pretty trivial to implement. I know, I've implemented it. If this is meant as a criticism of C, well there is a lot to criticise about C. But, one of the hallmarks of C is its lack of features, especially syntactic features. C is rather elegant in its syntactic simplicity. If you are looking for a modern language with a lot of syntactic features and a lot of flexibility, try reading a good book on ADA. If you want flexibility with a minimum of syntose, look a LISP. Programming language syntax is a cancer. The bigger it is, the harder it is to live with. Bob P. -- Bob Pendleton @ Evans & Sutherland UUCP Address: {decvax,ucbvax,ihnp4,allegra}!decwrl!esunix!bpendlet Alternate: {ihnp4,seismo}!utah-cs!utah-gr!uplherc!esunix!bpendlet I am solely responsible for what I say.