Hello!
I have implemented an alternative approach for compiling CPS calls in CHICKEN
to avoid the problem our current way of doing CPS calls.
To recapitulate the situation: Apple uses a modification of the ARM64 ABI that
ruthlessly punishes C code that assumes that non-vararg function calls ar
> Scripsit felix.winkelm...@bevuta.com:
>
> > The new approach passes all arguments in a stack-allocated C_word array.
>
> I would expect this to deeply suck on systems that have lots of registers
> and whose C compilers routinely pass arguments in registers. In particular,
>
> > not significan
> Scripsit felix.winkelm...@bevuta.com:
>
> > CPS calls are surprisingly expensive in general in CHICKEN,
>
> Ah, I'm confused now. Are "CPS calls" a specific type of call? I had
> assumed that all calls (except to C primitives) are CPS calls.
Yes, that's true. There is support for so-called "
> > - The maximal number of arguments is limited by the "temporary stack". Note
> > that this is not fixed (and depends on temp-stack usage), and I had to
> > remove
> > some code in "apply-test.scm", as it assumed a fixed limit. The "official"
> > arg-limit is 2000 now.
>
> It's been on m
Hi Felix,
If you are interested in further testing for potential performance
impact, the rb-tree and kd-tree libraries rely heavily on CPS calls
for tree traversal, and the test data size can be easily increased to
millions of elements. Unfortunately I won't have time to test this
until mid-Aug
Scripsit felix.winkelm...@bevuta.com:
> The new approach passes all arguments in a stack-allocated C_word array.
I would expect this to deeply suck on systems that have lots of registers
and whose C compilers routinely pass arguments in registers. In particular,
> not significantly slower
is p
Scripsit felix.winkelm...@bevuta.com:
> CPS calls are surprisingly expensive in general in CHICKEN,
Ah, I'm confused now. Are "CPS calls" a specific type of call? I had
assumed that all calls (except to C primitives) are CPS calls.
> I assume that the continuous growth of the stack
> and/or th
On Tue, Jul 21, 2015 at 06:28:19PM +0200, felix.winkelm...@bevuta.com wrote:
> Some notable changes in the source code:
>
> - The "apply hack" is gone, completely.
I'm loving this!
> - The hackery for AMD64 is gone, as is the evil way we generate C_procXXX
> types and the generic apply code in
