|By value-result vs by reference firstname.lastname@example.org (1994-04-21)|
|Re: By value-result vs by reference email@example.com (1994-04-21)|
|By value-result vs by reference firstname.lastname@example.org (1994-04-21)|
|Re: By value-result vs by reference email@example.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 firstname.lastname@example.org (1994-04-22)|
|Re: By value-result vs by reference email@example.com (1994-04-24)|
|Re: By value-result vs by reference firstname.lastname@example.org (1994-04-23)|
|Re: By value-result vs by reference email@example.com (1994-04-26)|
|Re: By value-result vs by reference Theo.Norvell@comlab.oxford.ac.uk (1994-04-26)|
|[6 later articles]|
|From:||firstname.lastname@example.org (Henry G. Baker)|
|Date:||Thu, 21 Apr 1994 16:59:48 GMT|
email@example.com (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
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
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.
Return to the
Search the comp.compilers archives again.