4 ms·
While the conversation is moot, I have tried to use bitcode to target multiple Apple targets. You are correct that bitcode is architecture specific. This makes
by bluejekyll 10y ago
While the conversation is moot, I have tried to use bitcode to target multiple Apple targets. You are correct that bitcode is architecture specific. This makes sense if you start thinking about endianness and how instructions are generated. Inaddition to that, even the default platform address size, e.g. 64 or 32 bit, needs to be encoded.
In fact Apples requirement for submitting bitcode for tvOS and watchOS confounds me, b/c as far as I can tell it only gives them a minor set of instructions that they can actually change. Then on top of that it locks you into their toolchain, see this discussion on Rust around this: https://users.rust-lang.org/t/ios-rust-integration/6928/2 https://users.rust-lang.org/t/ios-rust-integration/6928/2
- coldtea 10y ago>Inaddition to that, even the default platform address size, e.g. 64 or 32 bit, needs to be encoded. Isn't that moot, as all platforms used by Apple are 64-bit by now?
- bluejekyll 10y agoI was talking more generally about bitcode limitations. Maybe one day central CPUs will become 128 bits, it would be neat if you could just recompile the bitcode, but that won't work.
- fulafel 10y agoThere's an architecture neutral close relative to LLVM bitcode: Google's PNaCl. "PNaCl bitcode is based to a large extent on LLVM IR as of version 3.3" (https://developer.chrome.com/native-client/reference/pnacl-bitcode-abi https://developer.chrome.com/native-client/reference/pnacl-b...) It's targeting x86, amd64, arm and mips and shipping for a good while. Seems a bit quiet lately though.