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

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


            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.

- Alex
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Reply via email to