
LuaJIT maintainer's take on Apple/Clang - zachwill
http://osdir.com/ml/general/2012-02/msg27471.html
======
anonymoushn
You can browse this with dates and with 7 less ads per page here: <http://lua-
users.org/lists/lua-l/2012-02/msg00597.html>

------
chj
From what I know without jailbreak iOS doesn't support JIT at all.

------
pygy_
FWIW, Mike Pall (mikemike 'round these parts) is much more than the maintainer
of LuaJIT.

He's the sole author of the project, which is being actively developed.

------
protomyth
am I missing something or should the title be "LuaJIT linker error on iOS" and
the current version of XCode is 4.4 not 4.2 mentioned.

------
FigBug
This is 6 months old on a version of XCode that is now two versions out of
date. Is there a reason it's being brought up now?

~~~
mikemike
No there's no reason to bring this up now. First, it has been worked around
and second, VFP support for the LuaJIT ARM port is already in progress (parts
are in the git repo, not enabled yet).

~~~
schwa
What is the work-around? I'm trying to get luajit working on iOS 6+ on ARMv7
and above...

------
acqq
So all ARM processors that Apple uses have the real hardware floating point
and LuaJit (which is a very cool engineering feat) which is supposed to speed
up the execution of the Lua scripts still uses the "soft-only" calls. How much
that slows down LuaJit? I guess the "soft calls" can be redirected to the pure
hardware instructions? How big is the speed penalty vs. using the hardware
directly?

~~~
mikemike
The initial LuaJIT ARM port was targeted at low- to middle-end ARM devices
without an FPU. It took some time to find another sponsor for the VFP port.

Work on VFP and hard-float EABI (armhf) is already in progress and will be
available soon.

~~~
ohmantics
Hard-float has worked for quite some time.

All that's happened recently is that the Debian name for it "gnueabihf" is
recognized.

------
gregholmberg
Apple is actively trying to fix this problem.

If you know any talented compiler gurus who want to work at Apple, you could
refer them. [0][1]

.

[0] "LLVM Backend Compiler Engineer"
[http://jobs.apple.com/index.ajs?BID=1&method=mExternal.s...](http://jobs.apple.com/index.ajs?BID=1&method=mExternal.showJob&RID=113414&CurrentPage=1)

[1] "LLVM Backend Compiler Engineer"
[http://jobs.apple.com/index.ajs?BID=1&method=mExternal.s...](http://jobs.apple.com/index.ajs?BID=1&method=mExternal.showJob&RID=118224&CurrentPage=1)

~~~
drats
I would recommend people don't work for Apple. It's one thing to lie about
computing history and say you invented everything so that customers believe it
and give you lots of money (which you then use to outsource jobs and stop the
company charity program) it's another thing entirely to drink your own kool-
aid and start a series of the most embarrassing lawsuits I've ever seen. Apple
is now officially not just a dodgy liar, but they are a joke. Work there at
your own peril, I personally think they are a complete disgrace.

~~~
krickle
I think regardless of the lies, they had a superior operating system up until
Lion. Now their business practices and complete disregard for their
developers' comfort is fairly inexcusable. Nor do I like the draconian systems
of the App Stores.

------
flatline3
The LuaJIT maintainer is missing that Apple does not claim any conformance to
ARM EABI. Apple's ABI is defined to be based on the AAPCS standard, but Apple
makes no claims to it being exact.

In other words, it's not Linux, and it sounds like the LuaJIT maintainer is
annoyed that it doesn't follow a common approach used on Linux.

Anyone that works on low-level implementations that sit below the standard
platform compiler should expect this kind of thing when supporting multiple
platforms.

Source:
[http://developer.apple.com/library/ios/#documentation/Xcode/...](http://developer.apple.com/library/ios/#documentation/Xcode/Conceptual/iPhoneOSABIReference/Introduction/Introduction.html#//apple_ref/doc/uid/TP40009020-SW1)

~~~
mikemike
This is not about Linux. Every brittle OS on ARM uses the standard ABIs. But
Apple can't? Gimme a break.

~~~
ohmantics
Apple's ABI for iOS is a custom derivative of APCS, not AAPCS. They do not
even try to conform to the AAPCS ABI, nor should they need to. iOS has a soft-
float ABI, but uses the float glue names from libgcc, not the EABI names.

This whole thing reads like the LuaJIT guy whining that he has to do some work
to port to iOS. The compiler-rt library provides these functions and it
shouldn't take him more than 10 minutes to figure out the proper names to use
on iOS.

~~~
mambodog
Just so you know, it's the "LuaJIT guy" that you're replying to there.

~~~
acqq
That doesn't mean that ohmantics here doesn't have a good point (that it's not
realistic to assume that porting to the different platforms doesn't involve
some work specific to the platform) and gives the precise information where
the soft-float functions on iOS can be found.

I can also understand Mike too that he didn't want to spend the time on that
port (I think, because iOS doesn't allow apps any Jiting, thereby limiting the
power of LuaJit on iOS). Still the information that ohmantics gives regarding
compiler-rt library can help us obtain a balanced view.

