[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