Hello!

Andy Wingo <wingo@igalia.com> skribis:

> Honestly I would prefer not to do this.  If I understand correctly, the
> problem is in FFI calls -- you have a bytevector and you want to pass it
> as a pointer.  In that case the "right" optimization is to avoid the
> scm_tc7_pointer altogether and instead having an unboxed raw pointer.
> The idioms used in FFI are local enough that a compiler can do this.

I agree!  I have a patch from the 2.0 era (attached), but it doesn’t
work because all the tc3s are already taken.  I don’t think this has
changed but I could well be missing something about the tag space.
WDYT?

> More broadly -- the current FFI is an interpreter but it should be a
> compiler.  When a call happens, the code interprets the description of
> the ABI.  Instead, pointer->function should ideally *compile* a
> trampoline.  In an ideal world this compilation can happen
> ahead-of-time, when the .go file is compiled.

Yes, agreed.

> In the short term, what about allowing bytevectors as arguments
> whereever a pointer is allowed?  Perhaps it's bad to expand the domain
> of these functions but it may be the right trade-off.

So in practice, every time there’s '* in the FFI, it’d accept a
bytevector, right?

I would prefer immediate pointers if that’s possible, and then one of
the two other solutions.

Thanks!

Ludo’.