Hi Doug,
> After many merry rounds of compilation and discovery, it seems that
> the ndk-build's compiler -falign-functions[=n] and friends align
> functions relative to this option, but off by one (+1, or is that just
> |1?).;-)
Weird indeed. Can't believe ;-)
> In pico.h, sadly, I besmirched the code thusly,
>
> #ifdef ANDROID_ARM
> // android arm seems to have weird off-by-one alignment
> #define FUNCT2LISP_ALIGN(f) ((f)-1) // hopefully optimise to
> #define LISP2FUNCT_ALIGN(f) ((f)+1) // a single inc ...
> #else
> #define FUNCT2LISP_ALIGN(f) (f)
> #define LISP2FUNCT_ALIGN(f) (f)
> #endif
>
> #define evSubr(f,x) (*(fun)( LISP2FUNCT_ALIGN( num(f) ) & ~2 ) )(x)
>
> so in boxSubr in main.c,
>
> if (num(FUNCT2LISP_ALIGN(f)) & 3)
> giveup("Unaligned Function");
> return (any)(num(FUNCT2LISP_ALIGN(f)) | 2);
>
> (Er, I bet I missed some places, need to check.)
Yes. Looks good. I would say taking care of boxSubr() and evSubr() are
enough.
Explanation for other readers: The bit fiddling is necessary because
MiniPicoLisp depends on having bit zero of a cell's CDR pointer free, to
use it as the GC mark bit.
In "mini/doc/structures" we see
Primary data types:
num xxxxxx10
...
and
sym sym
| |
V V
+-----+-----+ +-----+-----+
| | | val | | txt | val |
+--+--+-----+ +-----+-----+
'val' is assumed to _always_ have a zero in the least significant bit,
as this is used as the GC mark bit.
Decrementing the function pointer with FUNCT2LISP_ALIGN has that effect.
Without it, the first call to the garbage collector would crash the
interpreter, as all built-in functions would be dumped.
Cheers,
- Alex
--
UNSUBSCRIBE: mailto:[email protected]?subject=Unsubscribe
