5 ms·
Dashboard was simply a way to get basic mobile apps prototyped on Mac before iOS existed. Apple does this a lot - make hay about something that's foundational
by r00fus 7y ago
Dashboard was simply a way to get basic mobile apps prototyped on Mac before iOS existed. Apple does this a lot - make hay about something that's foundational to their next step.
A good example was usage of LLVM on the PPC->Intel transition which then helped when they ported OSX to ARM (ie, iOS, nee iPhoneOS).
Another is Safari (which was useful/needed on Mac at the time) but more importantly was critical in making the iPhone successful - mobile browsing sucked before the iPhone.
- woodruffw 7y ago> A good example was usage of LLVM on the PPC->Intel transition which then helped when they ported OSX to ARM (ie, iOS, nee iPhoneOS). I’m not an Apple insider, but I don’t believe LLVM played a substantial role in either the PPC-to-x86 or x86-to-ARM-for-iOS ports — the former was accomplished with Rosetta and a lot of bugs. The current rumor, OTOH, is that Apple’s collection of LLVM bitcode for apps is intended to allow painless migration for applications when macOS is switched over to ARM.
- 0x0 7y agoIsn't that rumor solidly debunked by the fact that LLVM bitcode is strictly tied to the cpu architecure and kernel/system ABI which varies quite a bit between arm/arm64/x86/x86_64? Has anyone been able to execute built-for-x86_64 bitcode on aarch64 ever?
- scarface74 7y agoYes and it was debunked by no less than Chris Lattner himself on the Accidental Tech Podcast. https://atp.fm/205-chris-lattner-interview-transcript https://atp.fm/205-chris-lattner-interview-transcript
- woodruffw 7y agoOh well, I guess the rumor is junk then. I will say, however, that executing LLVM bitcode on different targets than the compilation machine is a subject of active research. It's one of the things that I work on in my day job.
- scarface74 7y agoRelevant quote: Bitcode is not [12:30] a magic solution, though. You can't take a 32-bit app, for example, and run it on a 64-bit device. That kind of portability isn’t something that Bitcode can give you, notably because that is something that's visible in C. As you're writing C code, you can write #ifdef pointer size equals 32, and that’s something that Bitcode can't abstract over. It's useful for very specific, low-level kinds of enhancements, but it isn't a panacea that makes everything [13:00] magically portable. What’s funny, is later on after Apple shipped a 64 bit chip for the Apple Watch. He admitted that forcing developers to ship watch apps as bitcode allowed Apple to recompile all of the third party Watch apps on the fly to support it, he knew that was coming, but couldn’t say anything at the time. https://twitter.com/clattner_llvm/status/1046960724646465541 https://twitter.com/clattner_llvm/status/1046960724646465541
- mrpippy 7y agoThe bitcode requirement was driven by the Apple Watch launching with a 32-bit ARM core, but Apple knowing they would move to AArch64 3 years later and not wanting to make devs recompile their apps (or have to support both ISAs on the Watch). The ABIs were designed to be compatible, and apps in the store were statically recompiled to AArch64 for the S4 launch last year.
- 0x0 7y agoCorrect me if I'm wrong, but I believe it's not regular aarch64, but instead a 32/64 hybrid called arm64_32 ?
- deleted 7y ago[deleted]