[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: [LuaJIT] Compiling for ARM (cortex-m4, bare-metal)
- From: Mike Pall <mikelu-1204@...>
- Date: Thu, 19 Apr 2012 01:00:14 +0200
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.