Re: [Chicken-hackers] "argvector" chicken (was: ABI woes)

[Peter Bex]

On Tue, Jul 21, 2015 at 06:28:19PM +0200, address@hidden 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 chicken.h/runtime.c.

This refers to C_AMD64_ABI_WEIRDNESS, and the weird macrology which were
both dropped in rev 550d787f.  Another nice improvement indeed!

> - 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 my todo-list for a while to get rid of that limitation as well.
Unless I'm missing something, it shouldn't be too hard, to make the temp
stack dynamically (re)allocated.  Anyway, there's no hurry for that.

> - I have pushed to branches: "argvector" and "argvector-bootstrap" (containing
>   only the changes in the C compiler backend.)
> 
> - To compile it, you need a modified bootstrapping compiler. The simplest way
>   is to checkout "argvector-bootstrap", make a static "boot-chicken", checkout
>   "argvector", touch all *.scm files and recompile with the static 
> bootstrapping
>   compiler.

A note about that for others trying to build this branch: making the
boot-chicken in the argvector-bootstrap branch will fail after compiling
a stage 1 compiler.  This seems to be expected, so you can just use the
chicken-boot-stage1 static binary to build the argvector branch.
Thanks to Mario for figuring that one out!

> Feedback is welcome. As this seems to run well, is not significantly slower, 
> solves current and future ABI problems, and simplifies the runtime-system 
> quite 
> a lot, I strongly recommend to consider changing CHICKENs code generation 
> generally to use this approach.

This seems like a good idea, especially considering Mario's benchmark
results and the fact that this considerably simplifies things.  However,
I would advise waiting until Bevuta has been able to field-test this.
This change has been made for a live product so I'm sure if there are
any unexpected consequences of this change, that will be found out.

Two things I've noticed:

First, the bug I reported when testing 4.10.0rc1 where programs built
with clang on macppc would crash seems to have disappeared.  This
probably means that clang on PowerPC uses an internal calling convention
for vararg functions that aren't exported which differs from the
"official" one.  Or something like that...

Second, the "numbers" egg no longer compiles because it makes use of
things like C_do_apply.  I'll have to look into that and perhaps #ifdef'ing
my way out of this.  Shouldn't be too much effort, I think.

> Porting this to CHICKEN 5 should be some work, 
> but doable. The changes for hand-coded CPS functions (in runtime.c, which 
> grew 
> considerably in CHICKEN 5) are straightforward, but still need manual 
> adaption. 
> I can help here, but would like to hear Peter's opinion about this, since he 
> wrote the bignum code (the largest part of the changes in runtime.c.) 

No problem.  I'll take a look at that, but I think we should first merge
Evan's modularisation code.  He's had to rework that partly due to the
numbers stuff being integrated, it would be a shame if he had to redo
some things yet again if we change everything around again.

Maybe the best approach is to merge Evan's module stuff, wait for reports
from Bevuta about the state of the new branch.  Then we can merge it into
master, and cherry-pick the changes into CHICKEN 5.  This will be quite a
bit of work, so it will be a while before we have this completely
integrated, I'm afraid.  The tricky part is bootstrapping our way into
a working CHICKEN 5 because so much other stuff has changed already.
The timing of finding a fundamental problem with our calling convention
is unfortunate, but we'll manage, as always.

Cheers,
Peter

signature.asc
Description: Digital signature