[M3devel] aligned_procedures: suggest "closure_marker_size"

[Jay K]

Thanks, understood.
No "mainstream" target would be affected -- no x86 target (32bit or 64bit), probably not any 32bit target.
 
 
For IA64 either we we probably want a 128 bit marker, since that is the instruction size, sort of (multiple instructions packed into 128 bit chunks).
 
 
Basically any architecture that has a fixed size 4 byte instruction, 4 byte aligned instructions, where alignment is checked, where pointer is 8 bytes, would be a little more efficient with a 4 byte marker instead of an 8 byte marker. Like, probably any MIPS64 or SPARC64 platform, and maybe some others (HPPA, Alpha, PPC64). Not any x86 or AMD64 though.
 
 
The closure would be smaller and the alignment would naturally be ok. Currently such architectures have to fiddle around with the pointer since it might not be 8 byte aligned. Any call through a function pointer would save a few instructions.
 
 
Really what bugs me most about this area is the time I have wasted in the past learning about it bringing up new platforms!
 
 
It bugs me otherwise -- the assumption that -1 is invalid code. The lack of a good solution here in general -- gcc has nested functions, but it doesn't do it in a good way either -- they generate code on the stack, on some platforms use mprotect to make the page executable, and on some platforms just fail completely (I think iPhone for example).
 
 
I suppose another improvement would be to make the value (-1) configurable per target. I haven't gone to the trouble of disasm'ing -1 on various platforms yet. Probably it is ok. It doesn't even have to be invalid, it just has to not to be the first instruction of a function.
 
 
 - Jay


----------------------------------------
> Date: Wed, 27 Jan 2010 16:19:21 -0600
> From: rodney_bates at lcwb.coop
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] aligned_procedures: suggest "closure_marker_size"
>
> Before anybody fiddles with closure markers, *please* do *both* the following:
>
> 1) Let me know. M3gdb needs to both recognize and construct closures
> (and it currently does.) Changing them will break it, unless it is
> modified accordingly.
>
> 2) Make sure there is some reasonable way m3gdb can tell by looking at
> the object code being debugged, whether it was generated by a
> compiler version that uses the old or the new closure marker
> representation.
>
> I have worked hard to make m3gdb able to adapt to the various compilers
> and versions, but periodically I get undermined on 1) and/or 2) above
> by some quiet change somebody makes without thinking about m3gdb.
>
> Also, think about the implications on linking together code produced
> by different compiler versions. I am quite sure changing the closure
> representation would mean *all* linked-in libraries would have to be
> recompiled, along with the main program, by the same compiler version.
>
> Right now, closure markers are always the same size as pointers, and I think
> there are multiple places in the compiler and runtime, in addition to m3gdb,
> that rely on this. They would all have to be located and fixed. And I
> don't think they all key off any single declaration, e.g. closure_marker_size.
>
> Jay K wrote:
>> yes, but I think it is target-specific. IA64 would use 16 bytes.
>> It isn't even in library code, but generated code.
>>
>> - Jay
>>
>>
>> ------------------------------------------------------------------------
>> From: hosking at cs.purdue.edu
>> Date: Wed, 27 Jan 2010 10:57:09 -0500
>> To: jay.krell at cornell.edu
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] aligned_procedures: suggest "closure_marker_size"
>>
>> If we declare it as a 32-bit subrange it should just work, right?
>>
>> Antony Hosking | Associate Professor | Computer Science | Purdue University
>> 305 N. University Street | West Lafayette | IN 47907 | USA
>> Office +1 765 494 6001 | Mobile +1 765 427 5484
>>
>>
>>
>>
>> On 27 Jan 2010, at 09:01, Jay K wrote:
>>
>> MIPS64, SPARC64 and maybe others could probably all benefit slightly
>> from
>> the closure marker being a 4 byte -1 instead of an INTEGER.
>>
>>
>> That is: 64bit architectures with a fixed size 4 byte instruction
>> where alignment is checked
>>
>>
>> That is, we should probably make their be a per-target variable
>> "closure marker size"
>> that is 4 for all current targets (IA64 should probably be 16 though),
>> though one would have to look into the various instruction encodings.
>>
>>
>> - Jay
>>
>>