[m-rev.] [zs at unimelb.edu.au: Re: for review: Conform to memory alignment requirements on doubles.]

[Peter Wang]

On Wed, 9 Oct 2013 08:27:28 +1100, Zoltan Somogyi <zs at unimelb.edu.au> wrote:
> I accidentally sent to this only to Paul, instead of the whole list.
> 
> Zoltan.
> 
> ----- Forwarded message from Zoltan Somogyi <zs at unimelb.edu.au> -----
> 
> Date: Wed, 9 Oct 2013 08:25:14 +1100
> From: Zoltan Somogyi <zs at unimelb.edu.au>
> To: Paul Bone <paul at bone.id.au>
> Subject: Re: [m-rev.] for review: Conform to memory alignment requirements
> 	on doubles.
> 
> On 08-Oct-2013, Paul Bone <paul at bone.id.au> wrote:
> > Is it easy to move this hidden word to the end of the cell or add padding?
> 
> The hidden word cannot be moved without redesign of the term size profiling
> system. However, I don't see any problem with disabling term size profiling
> on 32 bit systems, which should be easy to do.
> 

Is term-size profiling still useful?

> > > It would be trickier for the nondet stack.  Multiple frame types exist
> > > on the nondet stack, and the different frame types are identified by
> > > their sizes: 3-word and 4-word temporary frames, and 5/6+ word ordinary
> > > frames. Rather than rounding up frame sizes to even numbers of words,
> > > we would probably want to dynamically pad ordinary frame allocations,
> > > such that any doubles in the frame will be at aligned addresses.
> > > 
> > > However, in this change, we simply store box floats on the nondet stack.
> 
> I think that is the only pragmatic solution. Any other solution would
> require some other way to distinguish the different frame types, and I don't
> see how that could be without imposing a cost (in both space and time)
> that would have to be paid even if the absence of float variables.

Temporary frames don't contain doubles so can remain 3 and 4 words.
Ordinary frames may need to be padded by up to one word, depending on
where the stack pointer is at runtime, and only if the frame contains
doubles.  So frame types can still be distinguished.

> 
> In Mercury programs, both nondet code and floats are fairly rare; the
> combination should be rarer still. That's why I think the performance
> impact of this change shouldn't be too bad.
> 
> > > 	Remember det_stack_float_width in exprn_opts.
> > 
> > What does this mean?  Is this a reminder to yourself?
> 
> The exprn_opts data structure stores information that the code generator
> needs when generating code for things that look like expressions in a typical
> compiler (though in Mercury, they are all terms). I presume that sentence
> means that this change adds a flag about the treatment of floats in det stack
> slots to this data structure. Though I do agree with Paul, that this should
> be reworded.

It should read:
    Remember the width of floats stored on the det stack in exprn_opts.

> 
> > I will read the rest after this is anwsered.
> 
> I haven't read the diff itself either, but the log message looks good.
> 

Thanks.

Peter