Re: Running LuaJIT on iOS (was: Lua/LuaJIT2 performance on Android)

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

Adam Strzelecki wrote:
> Okay, (1) I removed checks (actually added __APPLE__ as
> alternative constraint) for EABI and GCC 4.3, also did that for
> lj_bswap at lj_def.h and it works fine with __builtin_bswap32,
> so maybe Apple backported that into own GCC 4.2.1.

Well, that builtin is definitely not in the FSF GCC 4.2 sources.
The changelog says it was introduced in GCC 4.3. Actually the
builtin generates pretty slow code. I'm tempted to use my own
replacement on ARM. I'll try to sort that out later.

> Unfortunately when running I receive following error:
> PANIC: unprotected error in call to Lua API (...256D674B-A0B0-4F8D-8A1B-209ABC32764E/Lua.app/scimark.lua:42: attempt to index local 'MIN_TIME' (a number value))
> 
> Tried also with "nsieve.lua" but then I get:
> PANIC: unprotected error in call to Lua API (.../256D674B-A0B0-4F8D-8A1B-209ABC32764E/Lua.app/nsieve.lua:20: attempt to perform arithmetic on local 'nsieve' (a function value))

These error messages are a bit strange. They do not correspond to
the original sources. Looks like some problem with the bytecode.

> So I guess there's something wrong with structures, maybe
> because data alignment in iOS being different than in standard
> EABI.

I'm not sure. The data structures inside the VM are all carefully
arranged to not leave holes, if possible. So the alignment rules
wouldn't come into play. The FFI is certainly affected, though.
But we're not at this point, yet.

> In iOS 2.x, register R9 is reserved for operating system use and
> must not be used by application code. Failure to do so can
> result in application crashes or aberrant behavior. However, in
> iOS 3.0 and later, register R9 can be used as a volatile scratch
> register. These guidelines differ from the general usage
> provided for by the AAPCS document.

Oh, I read that again ... and I think I got it: r9 is a
NON-volatile register in EABI, but a volatile register in iOS 3.0.
That would imply it may get trashed by any C call. Yuck.

Actually that register is used to hold a mask for bytecode
decoding. To test my theory, can you try to edit buildvm_arm.dasc
and swap the register assignments of DISPATCH and MASKR8? [This
requires Lua in the path to rebuild some generated files.]

If my theory is correct, then this ought to crash hard and fast.

A fix for the r9 issue would be somewhat complicated, though.

> #define __APPLE__ 1

Looks like that's the only useful indication for the different ABI.

--Mike