[M3devel] closure marker

[Jay K]

gcc generates code on the stack.
 Which Tony and I both don't like.
  I think you could change it to generate on an executable heap though -- after all, Java and C# do still work.
  And ATL even does this, to get the this pointer to a WindowProc.


We could use a per-target marker if necessary.


We do pass function pointers to C -- window procs, thread entry.
However, we could handled through a little glue code.


As well, we could disallow passing function pointers to <* external *> functions.
Or taking the address of <* external *> functions.


So interesting idea then -- change procedure pointers to be two words, function pointer and static link?
 Too inefficient? Too incompatible? Too big of a change?


Actually toplevel could benefit from non-null static link, for the sake of position independence.
Some C calling conventions do this sort of thing.


 - Jay


----------------------------------------
> Date: Sun, 30 May 2010 02:56:47 -0400
> From: hendrik at topoi.pooq.com
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] closure marker
>
> On Sun, May 30, 2010 at 07:45:38AM +0000, Jay K wrote:
>>
>>> On the target in question, native word is 64 bits. Closures are three words, as
>>> usual, all 64-bits and aligned to 64 bits.
>>
>> Right.
>> Though I think for IA64 we might need 128bit marker.
>>  At least that is the easy conclusion barring deeper understanding.
>>
> ...
> ...
>>
>>
>> Size and density are the generally dominant performance factors in most systems.
>> Touching the disk to page in stuff is among the slowest operations by far, so
>> reducing size, in order to reduce the number of pages touched, is important.
>>   Bigger code that is deemed "faster" is rarely preferred.
>>   Smaller code is also preferred in "embedded" systems.
>>
> ...
> ...>
>> No. Really, no. How much are you willing to bet that valid code can't being with 16_FF.
>> I'm not willing to make that bet.
>> Even the notion of 4 or 8 byte -1 I find tenuous.
>> You cannot portably/easily guarantee that such bytes aren't valid/existant code.
>> You must research all the various architecture encodings.
>>   Granted, we are only talking about function prologues..
>> The longer the sequence, the statistically less likely it is valid or existant code.
>> And there is a limit, per-architecture.
>> Many architectures have fixed length instructions.
>> On such architectures, going beyond that length does not change the odds of validity,
>> though does change the odds of existance (if valid). But our hope is really for invalidity,
>> not mere non-existance.
>>
> ...
> ...
>>
>> Again though, my real goal is to try to remove platform-specificity.
>> Something that can be made true for all architectures with no downside, should be made so,
>> and the variable removed.
>>
>>
>> I'd also like to understand what this all might look like with a portable C generating backend.
>> Clearly, reasonably the generated code might need to be able to say:
>>  #if WORD_SIZE == 4
>>  #if ENDIAN == LITTLE_ENDIAN
>>
>>
>> but hopefully not much else.
>> And maybe not even those. :)
>>
>>
>>  - Jay
>>
> If you can't find a bit pattern that's code on all architectures,
> neither as code address or as instructions, and you insist on being
> completely target-independent, the only solution I see is to make
> procedure addresses into two-word objects. Instead of using the pointer
> to the code as procedure address, you use the two-word closure as
> procedure address, and copy those two words around as the address of a
> procedure. For top-level procedures, use NIL as the environment poi
> ter.
>
> I was really surprised when I discovered that Modula 3 didn't do it this
> way.
>
> It's really a trade-off between data size (procedure pointers being
> bigger) and code size (procedure calls should be fast and avoid a lot of
> run-time checks)
>
> What does gcc use for the addresses of nested procedures? Does it
> generate code dynamically on the stack or heap to make it fit into one
> word?
>
> Oh. There's also a compatibility issue. To what extent are we
> constrained to use the same coding as C for procedure addresses?
>
> -- hendrik