[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: Running LuaJIT on iOS (was: Lua/LuaJIT2 performance on Android)
- From: Adam Strzelecki <ono@...>
- Date: Tue, 19 Apr 2011 15:19:51 +0200
Sorry for lots of text and logs below, but I hope this will be useful for these wanting to run LuaJIT on iOS, also changed thread subject to more appropriate.
> In other words: remove the check for EABI and see if it works.
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.
(2) Then I have compiled LuaJIT with:
make HOST_CC='gcc -m32 -arch i386' CROSS=/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/ CC='gcc -arch armv6 -isysroot /Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS4.2.sdk' TARGET=arm
Compilation went through without issues.
(3) Made simple iOS program with Xcode linking to libluajit.a:
- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions
{
[self.window makeKeyAndVisible];
lua_State *L = lua_open();
luaL_openlibs(L);
if(luaL_dofile(L, [[[NSBundle mainBundle] pathForResource:@"scimark" ofType:@"lua"] fileSystemRepresentation])) {
lua_error(L);
}
lua_close(L);
return YES;
}
Again no issues during compilation.
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))
Tried both scripts with official Lua 5.1.4 compiled for iOS similar way and they work fine, they also work fine on my Mac 64-bit with LuaJIT. So I guess there's something wrong with structures, maybe because data alignment in iOS being different than in standard EABI.
>> However got no clue how much it is different from standard ARM's EABI.
>
> Well, it will only work on iOS 3.0 or higher. And the debugger may
> not report backtraces properly. And the FFI may be partially
> broken wrt. struct field alignment, due to the idiotic changes to
> the alignment rules.
Okay, I see __ARM_EABI__ means the compiler follows AAPCS or AAPCS Linux ABI (http://infocenter.arm.com/help/topic/com.arm.doc.ihi0042d/IHI0042D_aapcs.pdf), seems that Apple's iOS ABI is just fancy modification of AAPCS. Indeed they have changed the alignment so it is now 4 bytes max, while in AAPCS alignment is exactly size of the type (except 128bit vector). So double is aligned 4 bytes instead 8 in regular AAPCS (EABI) :/
Also they have changed registers assignment, quoting Apple docs:
• Although the AAPCS document defines R7 as a general purpose nonvolatile register, iOS uses it as a frame pointer. Failure to use R7 as a frame pointer can prevent debugging and performance tools from generating valid backtraces. In addition, some ARM environments use the mnemonic FP to refer to R11. In iOS, R11 is a general-purpose nonvolatile register. As a result, the term FP is not used to avoid confusion.
• 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.
> There are a couple of builtins that are missing in versions prior
> to 4.3. It's not hard to replace them, though. Try removing the
> version checks in lj_arch.h and lj_def.h and see what breaks.
Seems that only one builtin marked to require GCC 4.3 was __builtin_bswap32, and that works with Apple GCC 4.2.1.
> Adding support for the strange (un)alignment rules is possible,
> but requires extra work. I cannot do anything about the other
> issues.
I think the alignment is the only issue so far, but maybe these PANICs above are due wrong register assignment too.
> Oh and I wonder what ABI it defines instead. Mail me the output
> of the 4.2 cross-compiler for: echo | arm-whatever-gcc -E - -dM
#define __DBL_MIN_EXP__ (-1021)
#define __FLT_MIN__ 1.17549435e-38F
#define __DEC64_DEN__ 0.000000000000001E-383DD
#define __CHAR_BIT__ 8
#define __ENVIRONMENT_IPHONE_OS_VERSION_MIN_REQUIRED__ 30000
#define __WCHAR_MAX__ 2147483647
#define __DBL_DENORM_MIN__ 4.9406564584124654e-324
#define __FLT_EVAL_METHOD__ 0
#define __DBL_MIN_10_EXP__ (-307)
#define __FINITE_MATH_ONLY__ 0
#define __ARMEL__ 1
#define __GNUC_PATCHLEVEL__ 1
#define __DEC64_MAX_EXP__ 384
#define __SHRT_MAX__ 32767
#define __LDBL_MAX__ 1.7976931348623157e+308L
#define __APPLE_CC__ 5664
#define __UINTMAX_TYPE__ long long unsigned int
#define __DEC32_EPSILON__ 1E-6DF
#define __block __attribute__((__blocks__(byref)))
#define __LDBL_MAX_EXP__ 1024
#define __SCHAR_MAX__ 127
#define __ARM_ARCH_6K__ 1
#define __USER_LABEL_PREFIX__ _
#define __STDC_HOSTED__ 1
#define __LDBL_HAS_INFINITY__ 1
#define __DEC64_MIN_EXP__ (-383)
#define __DBL_DIG__ 15
#define __FLT_EPSILON__ 1.19209290e-7F
#define __APCS_32__ 1
#define __LDBL_MIN__ 2.2250738585072014e-308L
#define __DEC32_MAX__ 9.999999E96DF
#define __strong
#define __APPLE__ 1
#define __DECIMAL_DIG__ 17
#define __LDBL_HAS_QUIET_NAN__ 1
#define __DYNAMIC__ 1
#define __GNUC__ 4
#define __FLT_HAS_DENORM__ 1
#define __DBL_MAX__ 1.7976931348623157e+308
#define __DBL_HAS_INFINITY__ 1
#define __DEC32_MIN_EXP__ (-95)
#define __THUMB_INTERWORK__ 1
#define OBJC_NEW_PROPERTIES 1
#define __LDBL_HAS_DENORM__ 1
#define __DEC128_MAX__ 9.999999999999999999999999999999999E6144DL
#define __USING_SJLJ_EXCEPTIONS__ 1
#define __DEC32_MIN__ 1E-95DF
#define __weak __attribute__((objc_gc(weak)))
#define __DBL_MAX_EXP__ 1024
#define __DEC128_EPSILON__ 1E-33DL
#define __LONG_LONG_MAX__ 9223372036854775807LL
#define __GXX_ABI_VERSION 1002
#define __FLT_MIN_EXP__ (-125)
#define __DBL_MIN__ 2.2250738585072014e-308
#define __DBL_HAS_QUIET_NAN__ 1
#define __DEC128_MIN__ 1E-6143DL
#define __REGISTER_PREFIX__
#define __DBL_HAS_DENORM__ 1
#define __NO_INLINE__ 1
#define __DEC_EVAL_METHOD__ 2
#define __FLT_MANT_DIG__ 24
#define __VERSION__ "4.2.1 (Apple Inc. build 5664) (dot 2)"
#define __arm 1
#define __DEC64_EPSILON__ 1E-15DD
#define __DEC128_MIN_EXP__ (-6143)
#define __SIZE_TYPE__ long unsigned int
#define __DEC32_DEN__ 0.000001E-95DF
#define __FLT_RADIX__ 2
#define __LDBL_EPSILON__ 2.2204460492503131e-16L
#define __VFP_FP__ 1
#define __LDBL_DIG__ 15
#define __FLT_HAS_QUIET_NAN__ 1
#define __FLT_MAX_10_EXP__ 38
#define __LONG_MAX__ 2147483647L
#define __FLT_HAS_INFINITY__ 1
#define __DEC64_MAX__ 9.999999999999999E384DD
#define __DEC64_MANT_DIG__ 16
#define __DEC32_MAX_EXP__ 96
#define __DEC128_DEN__ 0.000000000000000000000000000000001E-6143DL
#define __LITTLE_ENDIAN__ 1
#define __LDBL_MANT_DIG__ 53
#define __CONSTANT_CFSTRINGS__ 1
#define __WCHAR_TYPE__ int
#define __pic__ 2
#define __FLT_DIG__ 6
#define __INT_MAX__ 2147483647
#define __FLT_MAX_EXP__ 128
#define __BLOCKS__ 1
#define __DBL_MANT_DIG__ 53
#define __DEC64_MIN__ 1E-383DD
#define __WINT_TYPE__ int
#define __LDBL_MIN_EXP__ (-1021)
#define __arm__ 1
#define __MACH__ 1
#define __LDBL_MAX_10_EXP__ 308
#define __DBL_EPSILON__ 2.2204460492503131e-16
#define __INTMAX_MAX__ 9223372036854775807LL
#define __FLT_DENORM_MIN__ 1.40129846e-45F
#define __PIC__ 2
#define __FLT_MAX__ 3.40282347e+38F
#define __FLT_MIN_10_EXP__ (-37)
#define __INTMAX_TYPE__ long long int
#define __DEC128_MAX_EXP__ 6144
#define __GNUC_MINOR__ 2
#define __DEC32_MANT_DIG__ 7
#define __DBL_MAX_10_EXP__ 308
#define __LDBL_DENORM_MIN__ 4.9406564584124654e-324L
#define __STDC__ 1
#define __PTRDIFF_TYPE__ int
#define __DEC128_MANT_DIG__ 34
#define __LDBL_MIN_10_EXP__ (-307)
#define __GNUC_GNU_INLINE__ 1
Best regards,
--
Adam Strzelecki
