[m-dev.] question about data representation decisions

Zoltan Somogyi zoltan.somogyi at runbox.com
Sun Apr 1 12:43:03 AEST 2018



On Sun, 1 Apr 2018 11:40:03 +1000, Peter Wang <novalazy at gmail.com> wrote:

> On Fri, 30 Mar 2018 17:31:02 +1100 (AEDT), "Zoltan Somogyi" <zoltan.somogyi at runbox.com> wrote:
> > 
> > I propose that we switch to a different approach. Instead of
> > recording in interface files the *information needed to reach
> > the right decisions* about data type representations, we should
> > record *the decisions themselves*. This would require adding
> > a new kind of item that can occur only in compiler generated
> > interface files, but we agreed several months ago that that is ok.
> > 
> > I see two advantages of the approach I am proposing.
> > 
> > First, it has a much simpler correctness argument about
> > ensuring consistency: the compiler decides the representation
> > of a du type when it compiles the module that defines that type,
> > and every compiler invocation on any other module uses the
> > record of that decision. If the defining module changes,
> > the decision may change, but then so will the interface file
> > containing that decision, which will require a recompile
> > of all other modules dependent on it.
> 
> Agreed.
> 
> > Second, and more subtly, in the scenario above, we *won't*
> > have to export the bar == float equivalence as a global equivalence;
> > we would export it only as something that applies to the fields of foo
> > that are bars. Occurrences of bars in other contexts would not be
> > affected.
> 
> It also affects whether arguments of type bar are passed via float
> registers, if used.

Yes, that is a consideration that must be taken into account.
Thanks for bringing that up.

Zoltan.


More information about the developers mailing list