Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site calgary.UUCP Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!ihnp4!alberta!calgary!radford From: radford@calgary.UUCP (Radford Neal) Newsgroups: net.lang.c Subject: Re: Vectorizing C compiler for the Cray Message-ID: <351@calgary.UUCP> Date: Sun, 7-Apr-85 22:59:17 EST Article-I.D.: calgary.351 Posted: Sun Apr 7 22:59:17 1985 Date-Received: Tue, 9-Apr-85 01:21:18 EST References: <486@lll-crg.ARPA> <1555@ut-ngp.UUCP> <35@utastro.UUCP> Distribution: net Organization: University of Calgary, Calgary, Alberta Lines: 43 >A committee at LLNL has studied the language and its suitability for numerical >work and is implementing the full C language with one minor modification. >In order to have compatibility with Fortran all subroutine parameters will >be passed by address. A small price to pay for good floating point performance >don't you think? > (Insert lots of comments posted about the resulting language not being C.) The reaction to this MAY be premature. One could write a C compiler which passed parameters by the address of a temporary location which has been set to the value of the actual parameter. I.e. the call fred(x,1); would be compiled as t1 = x; t2 = 1; fred(&t1,&t2); Assuming corresponding dereferencing when the parameter is accessed, this is just a rather inefficient way of implementing call-by-value and would not make the language "not C". This might be justified by the ability to call a FORTRAN routine like fred(x,1); without having to manually convert it to t = 1; fred(&x,&t); and without having to declare it as being a special FORTRAN routine. Of course, this only works if the FORTRAN routine doesn't return information in its parameters (i.e. if it is essentially treating parameters as call-by-value). This would be true of many numerical routines (e.g. SQRT). Of course, if this ISN'T what the original poster meant, I would certainly agree that the language isn't C. Radford Neal The University of Calgary