[Chicken-hackers] ABI woes

[felix . winkelmann]

> > - There is no need for "rest-arg wrappers", functions that extract the rest
> >   argument and then call the actual compiled C function. This can be done
> >   directly from the argvector.
>
> This is cool, but if I understand correctly it also means that all the
> C_fast_retrieve_proc(lf[123])(a, b, c) calls now need to be preceded by
> the filling of a stack-allocated vector, where before the arguments would
> be passed in registers on most platforms.  That means (even) more stack
> usage in CPS calls, which slows stuff quite a bit as we've seen with the
> numbers integration.

That's right. But I wouldn't know what to do about it, besides trying
tremendous hacks.

>
> Also, having to read arguments from a pointer will be slower than passing
> them in a register, and potentially slower than reading them from the top
> of the stack (though that may not be the case).

Still faster and simpler than using varargs. I agree that it would be 
nicer to do it differently, but so far there are few alternatives.

>
> > How this will influence performance, I can't say. This will reduce code size
> > (many trampolines go, as do rest-arg wrappers). Allocation of arg-vectors 
> > will
> > use more stack-space, but removal of trampolines will remove 
> > activation-frames.
>
> > Calls to known targets can still be done as normal C calls.
>
> But only if all the callers are known, correct?

Correct.

> Do you think there's a possibility to make a limited prototype, to see
> what the performance impact will be, and whether the approach is viable
> at all (ie, it works on ios)?

I'm currently trying to make the necessary backend changes, but the hard part
will be to cover all special cases (known/unknown, customizable, direct, direct
recursion, rest-args, etc.) Then the primitives need to be adapted (manually).
It's a lot of work, regardless of what we do.

>
> Finally, have you considered my idea of using macros for the calls and
> function definitions to switch between approaches?  If the performance
> is too bad, we can keep using the current approach for platforms where
> it does not break.  Unfortunately, C macrology is even worse than Scheme
> macrology.

I tried this, but it IMHO turns out to be nearly the same amount of work.
All primitives need to be touched for this, and it would remain a temporary
hack, messing up the codebase excessively.

I'm aware of all the disadvantages, but I (we) don't have the time to try
out a lot of things. And I don't want to start with a hack that is only for
one platform, and breaks next time someone has a great idea about changing
C compilers with regard to UB. If we put any work into this, then it should
at least promise some advantages (simplifications in the call interface and
in rest-arg handling, together with reduced code size.)

Or in other words: Apple has not deserved that we put a lot of effort into
changing the codebase just because they like to change the rules...


felix