Hi!
Andy Wingo writes:
>> These specialized subr types allow for faster dispatch, as opposed to
>> the argument count checks (and argument copies) that are done in
>> `scm_i_gsubr_apply ()'. Thus, I think replacing all of them with gsubrs
>> may have a negative impact performance-wise.
>
> That
Hi Ludovic,
On Mon 31 Aug 2009 10:42, l...@gnu.org (Ludovic Courtès) writes:
> Andy Wingo writes:
>
>>> scm_tc7_subr_2oSCM (*) () -- 0 arguments.
>>> scm_tc7_subr_1 SCM (*) (SCM) -- 1 argument.
>>> scm_tc7_subr_1oSCM (*) (SCM) -- 1 optional argument.
>>> s
Hi!
Andy Wingo writes:
[...]
>> scm_tcs_closures Interpreted procedures
>
> I am hoping to devise a way never to see these in the VM, on the
> eval-cleanup branch.
Cool!
>> scm_tc7_subr_2oSCM (*) () -- 0 arguments.
>> scm_tc7_subr_1 SCM (*) (SCM) -- 1 argu
Hey folks,
I'd like to outline something of a plan.
The general outline is first to simplify dispatch, then to pull it into
the VM.
Ideally I would like to have only three kinds of procedures: VM
procedures, subrs, and applicable structs. It might not be possible to
simplify all of these, but we
Hey all,
I'm working on pulling dispatch of non-VM procedure applications into
the VM -- so invoking primitives written in C can happen quickly from
within the VM.
This is also a step along the path towards native compilation. Procedure
dispatch right now has so many cases -- it is feasible to in
