Hi :) On Mon 25 Nov 2019 23:03, Ludovic Courtès <l...@gnu.org> writes:
> Andy Wingo <wi...@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? I was actually thinking about raw pointer values -- i.e. not immediate-tagged values. If you think about it these values are generally live only between the bytevector->pointer and the FFI call -- the compiler is capable of safely unboxing values in spaces like that. But this would work better with a more compiler-focussed FFI than with the current "interpreted" FFI. But, immediate pointers would be nice too; nicer, in some ways. See also Mark's fixrat work. >> 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? That was the idea :) > I would prefer immediate pointers if that’s possible, and then one of > the two other solutions. In that case I am not sure what a good solution is. Having to add an additional 2-word internal displacement is a bit unfortunate, if that's the case! Andy
