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@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
