[Chicken-hackers] Argvector all the things! (was: Re: "argvector" chicken (was: ABI woes))

[Peter Bex]

On Fri, Jul 24, 2015 at 06:08:50PM +0200, Peter Bex wrote:
> 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.

This has been fixed in the TRUNK version of numbers.  I would appreciate
it if people would be able to test this with argvector and non-argvector
versions of CHICKEN 4.

So far it seems that the performance is really crippled by argvector, due
to the increased stack use of CPS functions.  Luckily, this affects only
the numbers _egg_, not numbers in core (because that's heavily inlined).

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

It turned out not to be so hard after porting numbers; it provided me
with a template from which to resolve the cherry-picked merge conflicts.

So if you pull the repo, you'll now find a chicken-5-argvector branch
in it!

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

Bootstrapping is simple, once you have a working argvector CHICKEN 4.
You just build a boot-chicken with an argvector CHICKEN 4, and then use
said boot-chicken to build the CHICKEN 5 version.  Because this is so
easy to do, I decided to skip making a chicken-5-argvector-bootstrap
branch.

Now, what shall we do with these argvector things?  It looks like
SayHEY (Bevuta's application which needed the argvector changes) is
working perfectly on ARM64, so I think that proves the viability of
this new approach.  We can try to make it faster, later, I think.

I am in favor of merging both branches.  This will cause massive
breakage on all the Salmonella boxes, so I think this needs to be
rolled out carefully.  Perhaps we can make a development snapshot
for CHICKEN 4.10.1 (which includes the argvector changes)?
This cannot be done in the usual way, because that is automated:
by tagging the branch, a compilation process is automatically
triggered on call-cc.org.  So we'd have to do the tagging and version
bumping locally, then build the snapshot manually and upload it,
and only *then* push the git repo, I think.

Mario: Is that the correct way of doing it?

We could do the same for CHICKEN 5, but that would have to have
a slightly different naming convention because there is no 5.0.0
release yet (so "5.0.1" would be weird).  Perhaps use a tag name
like "5.0.0pre1" or something?

Finally, I would really like a clean Salmonella comparison of "before"
and "after" the argvector version, but as soon as we push the
merged version, all the Salmonella boxes will start breaking until
the branches are reconfigured to be built with the argvector snapshots.
Is there an easy way to do this in a sane way, such that we can compare
the breakage caused by argvector?

Cheers,
Peter

signature.asc
Description: Digital signature