Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

LuaJIT maintainer's take on Apple/Clang

osdir.com

Post reply on HN
Print view View original

11–20 of 27 posts

Re: LuaJIT maintainer's take on Apple/Clang

#11

Post by mikemike »

flatline3 wrote: post #10

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 compi…

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

Re: LuaJIT maintainer's take on Apple/Clang

#12

Post by [deleted] »

mikemike wrote: post #11
flatline3 wrote: post #10

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 compi…

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

[deleted]

Re: LuaJIT maintainer's take on Apple/Clang

#15

Post by 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...

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

Re: LuaJIT maintainer's take on Apple/Clang

#17

Post by ohmantics »

mikemike wrote: post #9
acqq wrote: post #6

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?

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.

Hard-float has worked for quite some time.

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

Re: LuaJIT maintainer's take on Apple/Clang

#18

Post by ohmantics »

mikemike wrote: post #11
flatline3 wrote: post #10

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 compi…

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

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.

Re: LuaJIT maintainer's take on Apple/Clang

#19

Post by drats »

gregholmberg wrote: post #15

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... [1] "LLVM Backend Compiler Engineer" http://jobs.apple.com/index.ajs?BID=1&method=mExternal.s...

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.

Re: LuaJIT maintainer's take on Apple/Clang

#20

Post by bonch »

drats wrote: post #19
gregholmberg wrote: post #15

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... [1] "LLVM Backend Compiler Engineer" http://jobs.apple.com/index.ajs?BID=1&method=mExternal.s...

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 dodg…

You're not telling hard truths. You're just embarrassing.
Post reply on HN