[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Chicken-hackers] Argvector handling - maybe we could do better at t
From: |
Jörg F . Wittenberger |
Subject: |
Re: [Chicken-hackers] Argvector handling - maybe we could do better at that |
Date: |
Wed, 17 Feb 2016 13:22:48 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux armv7l; rv:38.0) Gecko/20100101 Icedove/38.4.0 |
Am 16.02.2016 um 22:54 schrieb Peter Bex:
> On Tue, Feb 16, 2016 at 10:43:08PM +0100, address@hidden wrote:
>>>> So if we could convince the C compiler to pass the argvector - and as we
>>>> where about changing things the argument count too - in a global
>>>> *register* variable, then we needed zero allocation for most cps calls.
>>
>> Careful. Global register variables increase register pressure in the
>> compiler,
>> expose optimizer bugs and aren't overly portable. A simple static variable
>> should
>> be the better alternative.
>
> How about the stack-allocated vector I proposed? It'd also be the
> smallest change from what we currently have, I think.
How about trying the following. This should make it easy to experiment.
I chicken.h we reserve identifiers for passing actual argvector size and
a global argvector. But we don't use them. That is we #define them away.
#define C_current_argvector_size 0 /* reserved */
#define C_default_argvector_value 0 /* reserved */
#define C_allocate_argvector(cs, cc, cv, nc) ( (cc) >= (nc) ? cv :
C_alloc(nc))
Arguments: cs: current allocated argvector size, cc the "c" argument,
cv: the "av" argument, i.e., the current argvector possibly to be
reused, nc the new "c" argument, i.e., the size to be passed to C_alloc
if we allocate.
And we change the compiler to use our C_allocate_argvector:
Instead of
if(c >= 2) {
av2=av; /* Re-use our own argvector */
} else {
av2=C_alloc(2);
}
Issue
av2=C_allocate_argvector(C_current_argvector_size, c, av, next_c);
IMHO this should work right out of the box. Should and not change a
thing. Next we could take our time to go over runtime.c and make it use
the macro. Once done we can try ticks.
Having a macro indicating argvector allocation as opposed to other
allocations seems not to bad to have anyway. So it would not hurt the
code base at all.
Best
/Jörg
- [Chicken-hackers] Argvector handling - maybe we could do better at that, Jörg F . Wittenberger, 2016/02/16
- Re: [Chicken-hackers] Argvector handling - maybe we could do better at that, Peter Bex, 2016/02/16
- Re: [Chicken-hackers] Argvector handling - maybe we could do better at that, felix . winkelmann, 2016/02/16
- Re: [Chicken-hackers] Argvector handling - maybe we could do better at that, Peter Bex, 2016/02/16
- Re: [Chicken-hackers] Argvector handling - maybe we could do better at that,
Jörg F . Wittenberger <=
- Re: [Chicken-hackers] Argvector handling - maybe we could do better at that, Jörg F . Wittenberger, 2016/02/17
- Re: [Chicken-hackers] Argvector handling - maybe we could do better at that, Jörg F . Wittenberger, 2016/02/19
- Re: [Chicken-hackers] Argvector handling - maybe we could do better at that, Peter Bex, 2016/02/19
- Re: [Chicken-hackers] Argvector handling - maybe we could do better at that, Jörg F . Wittenberger, 2016/02/19
- Re: [Chicken-hackers] Argvector handling - maybe we could do better at that, Peter Bex, 2016/02/19
- Re: [Chicken-hackers] Argvector handling - maybe we could do better at that, Jörg F . Wittenberger, 2016/02/23