Re: By value-result vs by reference

hbaker@netcom.com (Henry G. Baker)
Thu, 21 Apr 1994 16:59:48 GMT

          From comp.compilers

Related articles
By value-result vs by reference guerin@iro.umontreal.ca (1994-04-21)
Re: By value-result vs by reference graham@pact.srf.ac.uk (1994-04-21)
By value-result vs by reference ssimmons@convex.com (1994-04-21)
Re: By value-result vs by reference hbaker@netcom.com (1994-04-21)
Re: By value-result vs by reference Dik.Winter@cwi.nl (1994-04-21)
Re: By value-result vs by reference nebbe@lglsun.epfl.ch (1994-04-22)
Re: By value-result vs by reference andrewd@apanix.apana.org.au (1994-04-24)
Re: By value-result vs by reference hbaker@netcom.com (1994-04-23)
Re: By value-result vs by reference nebbe@lglsun.epfl.ch (1994-04-26)
Re: By value-result vs by reference Theo.Norvell@comlab.oxford.ac.uk (1994-04-26)
[6 later articles]
| List of all articles for this month |

Newsgroups: comp.compilers
From: hbaker@netcom.com (Henry G. Baker)
Keywords: design
Organization: nil
References: 94-04-140
Date: Thu, 21 Apr 1994 16:59:48 GMT

guerin@iro.umontreal.ca (Frederic Guerin) writes:
>I would like to hear about call-by-value-result vs call-by-reference,
>which one is better ?


Neither one is 'better'; they have very different semantics. Call-by-
value-result is a poor SW attempt at a 'write-back' cache, but
unfortunately, SW caches of this kind are incapable of preserving cache
consistency (or 'object identity') at any reasonable cost, so they don't
bother. Unfortunately, due to significant differences in efficiency, many
language designers weasel out at the last minute and allow implementations
to defy a consistent semantics. The results of this weaselling are fast,
unportable programs and slow, portable programs.


The biggest weasel hole around is in Ada, which refuses to take a stand at
all, and therefore if your program can tell the difference, it is
'erroneous'.


The simplest example that shows the non-scalability of the 'anything goes'
approach is that of arithmetic functions which can take either
fixed-precision (e.g., C 'int') or arbitrary-precision ('bignum')
arguments/results. Due to the high cost of managing the storage
associated with bignums, the best calling sequences for them are
substantially different from those for fixed-precision functions. Thus,
although the intent of the 'anything goes' approach was supposed to be
efficiency, it results in an implementation which is considerably worse
than optimum.


In a world of ever-changing hardware, where machines with 16, 32 and 64
bits must coexist, the only safe policy is a consistent semantics which
can then be implemented using every trick in the book.
--


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.