Hi Noah,
Thanks for the thoughts.
On Fri 03 Aug 2012 00:21, Noah Lavine noah.b.lav...@gmail.com writes:
That sounds interesting, but I have a question - why not make the MVRA
return address immediately after the call, instead of immediately
before it? In the common case when returning to the
Heya Mark,
Thanks for the comments :-)
So the current thing is:
CALL:
call f
MVRA:
truncate
RA:
return
In interpreted code it's fine that we return to a different address, as
they are all indirect jumps anyway. For compiled code, the call
instruction won't be just
Hi interesting thoughts Mark,
The below refere to to (very) simplistic vm compiler I'm working on right
now.
The current overhead found in function call's, function setup and
function return means that it's hard to factor in the lowest level
of optimizations. I view the call overhead so large
On Fri 03 Aug 2012 13:54, Stefan Israelsson Tampe stefan.ita...@gmail.com
writes:
A though:
assert_nargs_ee
reserve_locals
assert_nargs_ee_locals
bind_rest
bind_kwargs
Could we not implement this logic in the call instructions?
This is a characteristic of the callee -- more work is
in the normal case you just have
assert-nargs-ee/locals which is very cheap, no?
Sure it's not the slowest of instructions, but in the VM it's an extra jump
and for the Native part it either bloats the code or one has to jump out
to supporting code subs in the VM. Considering the other call
That sounds interesting, but I have a question - why not make the MVRA
return address immediately after the call, instead of immediately
before it? In the common case when returning to the regular return
address, that would eliminate the extra branch (although it's a very
small branch anyway).
I
Hi Andy, thanks for the update! Exciting times for Guile :)
On 08/02/2012 10:29 AM, Andy Wingo wrote:
Instead I'd rather just use Dybvig's suggestion: every call instruction
is preceded by an MV return address. For e.g. (values (f)), calling `f'
would be:
...
goto CALL
MVRA:
