🚀 go-pugleaf

In article <1992Nov17.155855.4413@let.rug.nl>, bert@let.rug.nl (Bert Bos) writes:
> In article <1992Nov16.080647.26783@informatik.uni-ulm.de>, borchert@titania.mathematik.uni-ulm.de (Andreas Borchert) writes:
> > Agreed, programmers shouldn't be enforced to use VAR-parameters
> > for reasons of efficiency only. But, even with the semantics of
> > Oberon or Modula-2, it's not to difficult for the compiler to
> > detect that your 1000 x 1000 array isn't modified and, thus,
> > doesn't need to be copied.
> > 
> > Usually, the calling procedure passes a reference to the array onto
> > the stack in both cases and the called procedure then makes a copy
> > of the array if you have call-by-value and your array parameter
> > is subject to changes.
> 
> But what about a PROCEDURE p(a: Type; VAR b: Type) that is called as
> p(x, x). Both parameters will refer to x, but if b is modified, a
> should remain unchanged.

A nice case. Procedures like this one belong to the cases where we
need to know about all calling locations, i.e. p must be non-exported.

I agree with Cheryl Lins that this optimization technique is more
complex if it should apply to all possible cases. Nevertheless,
common procedures like

   PROCEDURE StringCompare(s1, s2: ARRAY OF CHAR);

which don't call anything can be optimized without great trouble.

In article <1992Nov16.221811.8761@gallant.apple.com>, cheryl@gallant.apple.com (Cheryl Lins) writes:

> While the symbol file could be enhanced to carry the interprocedural
> alias and side-effect information (and this could improve the analysis
> in modules calling imported procedures), there will still be situations
> where the compiler cannot determine the full effects. Additional
> analysis could be done at link-time, but a good deal of additional
> information would be necessary for a linker to do this. Probably not
> impossible, just a lot of work.

And not necessarily preferably, because including more informations
into a symbol file causes the symbol file to be changed more often
(even if the interface itself doesn't change) and, thus, requires more
recompilations.

Sounds like as we have to agree to Phil (mdlcpgs@lhn.gns.cri.nz):

> Hobby horse time again! I will re-assert my belief that the Wirth languages
> need other optional attributes on variable declarations and formal
> parameter definitions besides just TYPE (and VAR in the case of formal
> parameters).
> 
> Very useful are:  Static; (I dont like module level being only way to
> declare static variables when the scope of variable may be only one
> procedure. Local modules in M2 were about the most complicated away to
> achieve what the a static identifier could do imaginable)

But local modules allow your "static" variable to be shared by more
than one procedure -- a common case.

> 		  location; specifying the absolute memory address
> of variable (yes I know M2 implementation allow this).
> 		  Readonly; More power to compiler for finding logic
> errors and the solution to the by-value or by-reference versus
> efficiency problem in format parameters;

Readonly parameters don't protect from surprises. E.g. if we have
the above mentioned

   PROCEDURE p(a: Type; READONLY b: Type);
   BEGIN
      a[1] := ....;
      (* has b[1] been changed now? *)
   END;

where p is called as p(x, x). And all other cases are still not solved
where formerly VAR-parameters have been threatened by other procedures
in a non-obvious way.

I don't see a solution yet where in each case

(1)	everything is obvious (at least to the code generator) and
(2)	your parameters are not subject to changes and
(3)	copying is avoided.

-- 
_______________________________________________________________________________

Andreas Borchert, University of Ulm, SAI, D-W-7900 Ulm, Germany
Internet: borchert@mathematik.uni-ulm.de