[M3devel] more flailing on STATIC_CHAIN_EXPR

[Jay K]

so.. I have managed to get all of m3core to compile...all the way up to two or so errors in m3front.
  Not sure the generated code is correct yet, haven't run it.
  I'll keep digging esp. on the existing errors.


However I'm still a bit "confused".


What is the point of STATIC_CHAIN_EXPR?


I still have to try the man/boy example, sorry and thank you.


Back to the question of STATIC_CHAIN_EXPR.


I can see it used in tree-nested.
So it doesn't seem pointless.


However, notice the following:
 gcc figures out seemingly everything from the fact that DECL_CONTEXT(function) != NULL.
 It knows the function is nested. It figures out what references resolve how.
  Locals that are referenced by a nested function are put in a local struct.
  Sometimes by value, sometimes by pointer, depending.
  Non-local references go through the chain, n levels, etc.
  I believe it figures out itself to pass the static link.
  It creates trampolines as needed -- but that is easily suppressed. In 4.5 they seemed to introduce the change we had here.


Now, the parts that I recognize are less automatic:
  static link use can't be optimized away, because it is part of function pointer equality.
  That is what some of our changes to tree-nested are about.
  Furthermore, if it can't be optimized away, it might also be forced to exist in the first place. 
   Even if we have no local variables and no parameters, I guess, one can have unequal function pointers.
  

The part in 4.5 that says:
DECL_STATIC_CHAIN (decl) = 0;


should be removed I gather, and even the DECL_STATIC_CHAIN (decl) = 1 seems unnecessary, I think
we can reliably set it in parse.c.


One thing I'm sure I'm missing though is indirect calls.
>From gcc's point of view, indirect calls never? have a static link?
And from ours they always do?
??


This must be key. Direct nested calls need no special support. 
  So a lot will just work.
And all indirect calls need special support, since they might be to a closure.
?


I'll keep trying to understand.


I can get stuff to compile by having m3cg_load_static_link just push nul.
  Feels wrong though. I have to look at the code, but in the RtExFrame example, 
   it seems to pass 2 parameters instead of 3, though I don't know what the 3rd is, 2 already
   seems to contain an extra.
When I tried to have m3cg_load_static_link "do nothing", balanced with "nothing" in m3cg_pop_static_link, I get some
wierd behavior like compiler hanging, busy growing arrays very large.


If I do generate STATIC_CHAIN_EXPR, I have to do /something/ with it elsewhere,
at least to make it go away, else gimplification reasonably complains that it doesn't
know what to do with it.


 - Jay