[m-rev.] For review: Implemention of the region runtime system

Quan Phan quan.phan at cs.kuleuven.be
Tue Oct 9 18:56:02 AEST 2007


On Tue, Oct 09, 2007 at 05:57:27PM +1000, Zoltan Somogyi wrote:
> On 08-Oct-2007, Quan Phan <quan.phan at cs.kuleuven.be> wrote:
> > Zoltan, do you have a running rbmm system yet?
> 
> Yes. It passes bootcheck with flying colours.

That's great. It sounds like we can bootcheck the rbmm compiler ;-).
> 
> > To compile crypt.m, I
> > need to use --no-inlining, otherwise the region analysis falls into an
> > infinite loop. If you can run crypt and reproduce the error, we can
> > discuss this problem in another email.
> 
> I found the infinite loop myself, though haven't yet looked for a workaround
> when I found your mail.
The infinite loop is the problem of the region analysis. Another problem
here is the compiled program, where the runtime support does not work as
expected yet.

> 
> > Yes, not only the corresponding #defines, but also the corresponding
> > type structs if we will use any of them. The effort to keep the comment
> > consistent seems worth it because I once got a bug due to the change of
> > size_region_disj_protect from 2 to 1 and I forgot to delete a field in
> > MR_Disj_Protection struct. The bug is not easy to detect.
> 
> Which is we should switch over to using structures, instead of pointer
> arithmetic. I will do that tomorrow or the day after.
Ok, if you have no time to add the comments I can do it after your
changes.

> 
> > Because you also produce a diff, i.e., making changes here and there,
> > could you also make the small changes you mentioned above (variable
> > names, ite style, etc)?
> 
> I have done most of those changes. I will do the rest soon.

Ok, thank you.

> 
> The updated log message and diff follow. Since I have tested it several
> different ways, and in any case any problems shouldn't affect anyone but
> Quan and me, I am committing it.
> 
> Quan, please do the following.
> 
> 1.	Keep unchanged the workspace that you did your work in, the one
> 	that your original diff was derived from.
I did not make any changes since posting the diff.

> 2.	Check out a fresh workspace that includes my commit of the updated
> 	diff.
I will do this anyway.

> 3.	Run diff to compare the runtime, library and compile directories
> 	of your old workspace and the new one.
> 4.	Check the diff output to see if there is anything that looks
> 	suspicious. (I did some of the work after midnight.)
> 
Ok, I will do this and let you know the result.

Regards,
Quan.
> 
> Zoltan.
--------------------------------------------------------------------------
mercury-reviews mailing list
Post messages to:       mercury-reviews at csse.unimelb.edu.au
Administrative Queries: owner-mercury-reviews at csse.unimelb.edu.au
Subscriptions:          mercury-reviews-request at csse.unimelb.edu.au
--------------------------------------------------------------------------



More information about the reviews mailing list