[fpc-devel] Proposal/discussion: Simple nested functions and 'outlining'

[J. Gareth Moreton]

Ah crumbs, I thought it was too easy!  I can't believe I missed the 
obvious there!  Not much of a saving if it has to store the return 
address somewhere (mov @return(%rip),%rcx; mov %rcx, (somewhere on the 
stack)).

The advantage would be reducing the chance of additional memory caching 
since it's all together, and not having additional stack unwinding and 
function prologues.  But the requirement of a return address... yeah 
that complicates it!  Sorry, I feel silly now.  I might play around with 
it as a personal research project to see if it's viable though.

Gareth aka. Kit


On 01/10/2020 23:10, Martin Frb via fpc-devel wrote:
> On 01/10/2020 23:22, J. Gareth Moreton via fpc-devel wrote:
>> In a way, yes, but not quite the same, since multiple calls to the 
>> nested function would still redirect to the same block of code rather 
>> than being inlined at each call.  I suppose more similar to the old 
>> GOSUB; RETURN combination in old versions of Basic, and the nested 
>> routine slotted either at the end of the parent function or, if the 
>> compiler is intelligent enough, right after one of the function calls 
>> (in effect, inlining it at this point) so the peephole optimizer can 
>> then remove a zero-distance jump.
>
> And how to you get back?
>
> When you talk of jump instead of call, I imagine something like:
> nop
> nop
> jmp + 0 // to nested
> mov // in nested
> jmp ??? // back to outer
> nop  // continue outer
> nop
> jmp -5 // to nested
> nop // continue outer
>
> What is the advantage over "call"?
>
> ----
> Maybe the following (not sure if beneficial) goes into the same direction
>
> If a "nested proc" (which can have its own locals, and params) does 
> NOT recurse, then instead of generating a separate stack frame 
> (enter/leave) space for the locals could be allocated at the end of 
> the outer function. That means that the basepointer (rbp) can be kept 
> as it is. And that also means, that the framepointer for the outer 
> (access to outer variables) does not need to be passed, as it is the 
> basepointer.
> (This kind of extends the recent "do not pass the outer-fp", if there 
> is no access to outer vars, only this time outer vars may be accessed.)
> _______________________________________________
> fpc-devel maillist  -  fpc-devel at lists.freepascal.org
> https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
>