[M3commit] [modula3/cm3] 89f779: More versatile interface to CopyOpenArray.
GitHub
noreply at github.com
Fri Nov 10 17:56:57 CET 2017
Branch: refs/heads/master
Home: https://github.com/modula3/cm3
Commit: 89f77958fc54511387e3fa8257e43960113c0206
https://github.com/modula3/cm3/commit/89f77958fc54511387e3fa8257e43960113c0206
Author: Rodney Bates <rodney.m.bates at acm.org>
Date: 2017-11-10 (Fri, 10 Nov 2017)
Changed paths:
M m3-sys/m3front/src/types/Type.i3
M m3-sys/m3front/src/types/Type.m3
M m3-sys/m3front/src/values/Formal.m3
M m3-sys/m3front/src/values/Variable.i3
M m3-sys/m3front/src/values/Variable.m3
Log Message:
-----------
More versatile interface to CopyOpenArray.
Also misc comments.
NOTE: It turns out that a call site open array copy is not needed.
For a READONLY array formal, the only time a call site copy is
required is when the actual is a nondesignator. This can only
be an array constructor or function result. In either case, the
size is statically known, so CG's GenCopy can be used, even when
the formal and/or actual is open.
This is very fortunate, because CopyOpenArray needs to generate
a call to RTS' NewTracedArray, and that would be a nested call,
which would be quite unpleasant to avoid.
NOTE2: Except for prolog-located copy of an open array, (which
happens when the formal is VALUE open array), all by-value copying
of in-memory types is done at the call site. This is unfortunate
from a performance standpoint, because it can make for poor use of
temp space, not to mention duplication of copy code at multiple
calls to the same procedure. But changing this would upset binary
compatability with previously compiled code and such things as C
bindings.
More information about the M3commit
mailing list