[m-dev.] Large MR_join_and_continue() macros in runtime.

Paul Bone pbone at csse.unimelb.edu.au
Fri Nov 20 10:34:12 AEDT 2009


On Fri, Nov 20, 2009 at 10:20:03AM +1100, Peter Stuckey wrote:
>
> On 18/11/2009, at 8:18 PM, Paul Bone wrote:
>
>>
>> Hi Zoltan and Peter.
>>
>> I've found myself modifying and maintaining the large  
>> MR_join_and_continue()
>> macros in the runtime.  The C preprocessor language is very clumsy,  
>> and I'd
>> rather write these as native C procedures.  This will also reduce the 
>> code size
>> of programs that use MR_join_and_continue() as the code would no- 
>> longer be
>> inlined.  My aim is to make it easier to maintain this code.  I  
>> believe this is
>> a strong argument since I will probably be modifying this code in the 
>> future,
>> and if not someone will have to maintain it.
>>
>> The obvious argument against doing this is that they may be more  
>> efficient as
>> macros.  Of course the difference in performance could be negligible  
>> or worse
>> as inlining increases the size of procedures.
>>
>> There's a less obvious argument against doing this.   
>> MR_join_and_continue uses
>> MR_GOTO to jump to the join label, or to tailcall MR_do_runnext (via  
>> the
>> MR_runnext macro).  This means that this code can't easily be made  
>> into a C
>> function, not without returning from it and then using MR_GOTO.
>>
>> Alternatively we can use the asm_fast execution model and make this a 
>> low-level
>> C mercury procedure, (see MR_do_runnext for an example).  This is also
>> non-trivial, since MR_join_and_continue takes arguments we would want 
>> to place
>> these arguments in abstract machine registers, this requires changes  
>> to the
>> code generation for MR_join_and_continue and doesn't look like too  
>> much effort.
>> This is my preferred option.
>>
>> What do you think?  Which option(s) do you prefer?  Leaving it as a  
>> macro,
>> making it a C function or making it a Mercury low level C procedure?
>
> For G12 the most important backend is hlc. What is the likely effect on 
> hlc?

None at all.  MR_join_and_continue is not compiled in HLC grades as it's only
used in parallel low level C grades, and then only for programs that make use
of parallel conjunctions.

I should have been more specific, I was addressing Peter Wang.  I hope this
didn't confuse anyone.

Thanks.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 489 bytes
Desc: Digital signature
URL: <http://lists.mercurylang.org/archives/developers/attachments/20091120/b061ce30/attachment.sig>


More information about the developers mailing list