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

[felix . winkelmann]

> > - 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.

Yes, that should be possible, but I'm not sure if this is worth the complexity.
We can also choose a fairly large default, and provide a build-time setting.

>
> > - 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!

Ah, sorry. When I said "boot-chicken", I meant a static chicken-compiler,
you can build it like this:

  make PLATFORM=... STATICBUILD=1 PREFIX=/nowhere chicken

>
> > 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.

That's right, good point.

> 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...

Very much possible. PowerPC calling conventions are pretty involved,
as are most ABIs for "modern" CPUs.

>
> 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.

Right, in the end things always become simpler, at least from the porting
work I did on the core. But it may mess up the code, of course.

>
> > 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.

Yeah, true. :-)


felix