[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: towards a more unified procedure application mechanism
From: |
Andy Wingo |
Subject: |
Re: towards a more unified procedure application mechanism |
Date: |
Thu, 03 Sep 2009 10:39:43 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/23.0.92 (gnu/linux) |
Hi Ludovic,
On Mon 31 Aug 2009 10:42, address@hidden (Ludovic Courtès) writes:
> Andy Wingo <address@hidden> writes:
>
>>> scm_tc7_subr_2o SCM (*) () -- 0 arguments.
>>> scm_tc7_subr_1 SCM (*) (SCM) -- 1 argument.
>>> scm_tc7_subr_1o SCM (*) (SCM) -- 1 optional argument.
>>> scm_tc7_subr_2o SCM (*) (SCM, SCM) -- 2 required args.
>>> scm_tc7_subr_2o SCM (*) (SCM, SCM) -- 2 optional args.
>>> scm_tc7_subr_3 SCM (*) (SCM, SCM, SCM) -- 3 required args.
>>> scm_tc7_lsubr SCM (*) (SCM) -- list subrs
>>> scm_tc7_lsubr_2 SCM (*) (SCM, SCM, SCM)
>>
>> I would like to make these all be gsubrs. There are very few places
>> where these constants actually exist in code "out there" -- normally the
>> way to do this is to use scm_c_define_gsubr, and it does the right
>> thing.
>>
>> I'll probably do a:
>>
>> #define scm_tc7_subr_2o \
>> scm_tc7_subr_2o_NO_LONGER_EXISTS_USE_scm_c_define_gsubr
>>
>> or something like that.
>
> You can't do that because such subrs are created by `create_gsubr ()'
> when the signature allows it. Or did you mean `create_gsubr ()' would
> now create only gsubrs?
Yes, I mean for create_gsubr to return gsubrs.
> 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 might be true with the current implementation, but it need not be
true with dispatch in the VM. The specialized subr types don't actually
gain us anything; you can do a gsubr dispatch just as fast, comparing
the tc16 instead of the tc7.
>>> scm_tc7_dsubr double (*) (double) -- double subrs
>>
>> I'll remove these, changing their implementations to be gsubrs. This
>> only affects $sin et al; I'll probably roll the transcendental versions
>> into the subrs as well.
>
> Yes, it seems to be seldom used. However, it might be a semi-public
> API...
Undocumented of course. I seriously doubt this removal will cause
problems.
> Sounds like a nice plan!
We'll see how it goes :) This will be on my subr-simplification branch.
A
--
http://wingolog.org/
- Re: towards a more unified procedure application mechanism,
Andy Wingo <=