
Apple will "take at least several months" to release LLVM backend for 64-bit A7 - yapcguy
http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-September/065480.html
======
jnbiche
I'm not the biggest Apple fan around, but if this is meant to be some kind of
expose of wrongdoing, I completely disagree. First, under the BSD, they're
under no obligation to do anything with their improvements to LLVM, which is
exactly how supporters of permissive licenses (like me) like it, even though
we often also encourage users to contribute back if they can.

Second, although they're under no obligation to contribute back, they're going
to do so anyway, because they 1) understand that this is probably in their
best interest, and 2) presumably want to help support and foster the LLVM
community.

Merging in all this code -- necessarily done in private since it was a
confidential company project -- is likely a major undertaking, so they want to
be sure to get it right. And yet they're giving the LLVM community heads-up
not to spend time working on that particular solved problem.

All in all, nothing to see here.

~~~
azakai
> I'm not the biggest Apple fan around, but if this is meant to be some kind
> of expose of wrongdoing, I completely disagree.

Why would you think it is such a thing?

~~~
firat
Have you read past the first sentence?

------
threeseed
Nothing to see here.

There is an existing implementation, Apple's implementation and hence it will
take at least several months to merge the two, legal sign off and then
committed.

~~~
yapcguy
In the mean-time, the community will be wasting time and effort in trying to
solve ARM 64-bit issues which Apple has already solved.

If LLVM were under a copyleft license like the GPL, Apple could still have
created it's backend in secret to time its release with the new iPhone.

BSD style licenses leave the community at the mercy of corporate interests. If
Apple decides not to release[1] its backend, too bad, and we all play catch-
up.

[1] "We're going to the standards bodies, starting tomorrow, and we're going
to make FaceTime an open industry standard." Steve Jobs

~~~
klodolph
We already have a copyleft compiler, GCC, and under the stewardship of the FSF
it has turned into a total mess. The community has been wasting effort for
years duplicating issues that have already been solved in GCC because the FSF
refused to merge patches that would make it modular. On the other hand, you
can download Clang and make your own tools from it now. Go ahead, I dare you
to do either of the following:

* Use GCC's C frontend to write a code analysis tool of any sort,

* Write a new frontend to GCC.

FSF's damage to the GCC code base proved that you can still sabotage freedom
while adhering to the letter of a copyleft license.

I suspect the KHTML mess is still fresh in the minds of many engineers at
Apple.

~~~
LukeShu
Since 1999, GCC has been under the stewardship of the GCC steering
committee[1], not the FSF.

[1]: [http://gcc.gnu.org/steering.html](http://gcc.gnu.org/steering.html)

------
maxharris
Kudos to Apple for doing the right thing.

It is within Apple's rights to not release the code at all. Or they could have
just dumped what they had, warts and all, leaving the mess for other
maintainers to sort out. Or they could have plugged away silently, getting
ready for a release without notifying anyone (which would have resulted in
unnecessary duplication of effort - think Linux on IBM mainframes). What
they've done here is the most respectful and responsible thing possible.

~~~
ajross
I'm reading this over and over and still not understanding how withholding
source code is "the right thing" and worthy of praise. Either it's an open
source toolchain or it's not. Apple's iOS compiler isn't. There's no
particular shock there -- the platform it targets certainly isn't open either.
We don't freak out when MSVC is released without source. But we don't praise
Microsoft either.

Maybe it will be open source some day. If it is, _then_ is the appropriate
time to deliver "kudos" \-- certainly not now.

~~~
gilgoomesh
The "right thing" is merging it back into LLVM instead of hoarding it in their
private repository.

Apple, like many proprietary companies, don't use the public repository for
any working branches, so a meticulous and time-consuming merge back into the
trunk (which will have changed on its own in the meantime) is required.

Additionally, since large companies like Apple tend to be magnets for
lawsuits, everything the company publishes (even in open-source code
repositories) may need to be reviewed by lawyers (or at least more senior
engineers) to make sure there's no plagiarism, accidental inclusion of
privately licensed code or leaking of confidential information.

~~~
ajross
Sure. But the "right thing" hasn't been done yet, so why are we sitting here
praising (!) Apple for not having done it yet?

This is the kind of stockholm syndrome that drives me crazy in the iOS world.
People have internalized that Apple is a "good guy" that supports open source
projects and uses an open source compiler, so suddenly when they don't there
is this need to rationalize the behavior. Just stop.

They shipped a closed source compiler. That's not immoral but it's not
praiseworthy either. They promise it will be open in the future, and I trust
that the developers are sincere (though often management has other priorities
attached to their time). When it happens, that's when you should praise. Doing
it now is just encouraging poor development practices.

And let's be clear: from the perspective of open source this is poor practice.
It certainly doesn't have to be this way. Itanium and x86_64 both had working
gcc implementations _months to years_ in advance of hardware availability. ARM
did their part releasing the specs (again, well over a year ago). On the other
side of the fence Linaro et. al. have done great work porting gcc to the
architecture.

But LLVM/clang doesn't support it yet, because the implementation is an Apple-
proprietary closed source compiler. To repeat: very much not praiseworthy.

------
ianstallings
Must be a significant fork and/or the code is not "pretty". No one wants to
embarrass themselves and they probably have to peer review it, etc. All with
managers breathing down their necks :D

~~~
general_failure
I guess they kept it secret because no-one has a 64-bit embedded cpu.

~~~
kps
It seems obvious that they kept it secret because if Apple had been pushing
out improvements to the ARM64 code generator for the past months, someone
would have connected the dots and understood they were building an ARM64
device.

All Chris Lattner's message is saying is that Apple's contributions here are
subject to the same process as anyone else, namely incremental commits with
community review.

~~~
AnthonyMouse
>It seems obvious that they kept it secret because if Apple had been pushing
out improvements to the ARM64 code generator for the past months, someone
would have connected the dots and understood they were building an ARM64
device.

Existing high end mobile devices have on the order of 2GB of memory. It
doesn't take a genius to work out that they're soon going to have 4GB or more
and hit the ceiling of a 32-bit address space. Why bother keeping a secret
something the entire market already knows is going to happen in short order?

~~~
derefr
Because the timing between "when that information comes out" and "when apple
have something to show that people can buy" greatly affects their stock price.

------
gdonelli
Reminds me when Darwin (Leopard days) went to x86 and the sources of Darwin
were stale for a very long time

