[M3devel] closure marker

Rodney M. Bates rodney_bates at lcwb.coop
Thu May 27 01:20:38 CEST 2010


After the marker, a closure also has two pointers, one to executable code,
and one to an environment of nonlocal variables.  These will always have
to be aligned to whatever pointers require on the target.  So making the
marker smaller than a native pointer would then require padding the
closure to get the pointers aligned.  This uses as much space as just
keeping the marker word-sized.

And no, I don't think it makes any sense to (on a 64-bit target) start
a closure on an odd multiple of 4 bytes, just so you can make the marker
smaller while keeping the following pointers word-aligned.

Jay K wrote:
> A little bit of research done (just searching the web):
>  Mips, Alpha, PowerPC, HPPA, ARM, SPARC
> 
> 
> all appear to use a 32bit instruction
> presumably aligned but I couldn't confirm for all of them.
>   It seems likely that if the processor cares about data alignment, then code will be aligned the same.
> 
> 
> Looks like SH has 16bit instructions.
> 
> 
> I think we should go ahead soon and change the marker to be elementsize, count, initialize size=32bits, count = 1 for all targets.
> With IA64 the expected exception with size=64bits, count=2.
>   It packs 3 41bit instructions + 5bit template code into 128bit quantities, presumably 64bit aligned.
>   We can revisit at that time.
> And really size=64, count=1 might suffice.
> 
> I'm a little torn.
> A 64bit marker is more certain.
> Code has been this way forever.
> etc.
> 
>  - Jay
> 
> 
> ----------------------------------------
>> From: jay.krell at cornell.edu
>> To: hosking at cs.purdue.edu; m3devel at elegosoft.com
>> Subject: closure marker
>> Date: Wed, 26 May 2010 15:13:38 +0000
>>
>>
>> As I understand, currently we define the "closure marker" to be INTEGER sized and -1, and guaranteed aligned or not.
>> 64bit systems that care about alignment pay quite a penality imho.
>>
>>
>> I need to research, but I strongly suspect we should have Target.ClosureSize (bits) instead of Target.AlignedProcedures.
>>
>>
>> If a system with a 64bit INTEGER has 4 byte instructions, that are always 4 byte aligned, and has instructions that can load a 4 byte integer, then we'd just set Target.ClosureSize = 32. The alignment stuff would fall away.
>>
>>
>> I suspect this covers PPC64, SPARC64, ALPHA64, HPPA64, but I'd have to research their intruction sets.
>>   Do they have 4 byte instructions, that are always 4 byte aligned?
>>
>>
>> IA64 probably would have Target.ClosureSize=128 and the frontend would generate two guaranteed-aligned 64bit loads.
>>
>>
>> More general might be
>>   Target.ClosureElementSize  (bits)
>>   Target.ClosureElementCount
>>
>>
>> IA64 could then use Target.ClosureElementSize = 64, Target.ClosureElementCount = 2.
>> Whereas most others would have Target.ClosureElementSize  = 32, Target.ClosureElementSize  = 1.
>> ClosureElementSize would be chosen to be match guaranteed code alignment.
>>
>>
>>
>>   - Jay
>>
>>
>  		 	   		  



More information about the M3devel mailing list