Re: [LuaJIT] Compiling for ARM (cortex-m4, bare-metal)

[Mike Pall <mikelu-1204@...>]

Wolfgang Pupp wrote:
> I'm trying to compile LuaJIT for an ARM-Cortex-M4F (168MHz, ARMv7
> based, single precision FPU).

The Cortex-M chips are not supported. They only support the
Thumb/Thumb2 instructions sets, but not the original ARM
instruction set. Both the LuaJIT interpreter as well as the JIT
backend only use ARM instructions.

[A mixed-mode build with the C parts compiled as interworking
Thumb2 and the assembler parts as ARM instructions _does_ work.
But not on Cortex-M.}

> - Will 100KiBytes of RAM get me anywhere, or will I (predictably) need
> more (assuming I won't do anything too fancy)?

Umm, I'm assuming you're talking about the dynamic memory usage?
I.e. the C code is in ROM somwhere? Anyway, that's still very
little and will be a real hassle to deal with.

> - I'm currently making LuaJIT use the system memory allocator
> (newlib)- is there an easy way to tell the custom one "just take as
> much memory as you want, starting somewhere (&_end) until you bump
> into the stack"? Would this pay off in terms of performance? (doing
> this currently via _sbrk for the system-malloc)

IMHO having one contiguous area wouldn't make it any faster.

> - Is the FFI module gonna work on this target (for accessing C-code
> that is statically linked with the interpreter)?

Yes, if you export the relevant symbols from the resulting
executable. Alternatively, pass a pointer to a static struct
holding the function pointers as lightuserdata, ffi.cast() it back
to the struct pointer and call the functions from there.

> - Would it be relatively simple to implement single precision
> arithmetic (via ffi) myself (I'd publicdomain it, but I assume it
> would take more skill and knowledge about LuaJIT intrinsics than I can
> muster). Also I don't need it too badly.

That's not a simple task. Mainly because it doesn't fit in well
with the numeric tower that LuaJIT uses internally.

> PS: About -mfloat-abi=softfp: it's the same as -mfloat-abi=hard,
> except that float-arguments are not passed via FP-registers? You also
> can't use the hard fp-abi if the toolchains libc wasn't specifically
> compiled for that? Information on the net is somewhat sketchy and
> contradictory :(

-mfloat-abi=soft:   soft-float EABI + soft-float library calls (armel)
-mfloat-abi=softfp: soft-float EABI + VFP code generation (armel option)
-mfloat-abi=hard:   hard-float EABI + VFP code generation (armhf)

Only the first two variants are (mostly) compatible.

--Mike