[M3devel] closure marker

[hendrik at topoi.pooq.com]

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