[Openmcl-devel] More Intel: Rosetta & Universal Binaries
raffaelcavallaro at mac.com
Fri Jun 10 10:26:24 EDT 2005
On Jun 10, 2005, at Fri, Jun 10, 9:26 31 AM, David Steuber wrote:
> To elaborate a bit more on what I said above, it seems to me that
> only the kernel needs to have the kludge. I don't know how long
> PPC support will be needed, but I'm guessing the time frame is in
> years. Perhaps enough years to justify going with the Universal
> Binaries approach just for the kernel. The kernel will know which
> image files it needs to load based on the host and can then just
> run native. Sure, that is more image files to produce for an app
> bundle, but having two in Contents:MacOS is probably already one
> more than is typical. Multiple architecture support only matters
> for distribution of apps and other binaries. Development doesn't
> need that capability. At least not app development. Compiler
> development is another story. I have no ideas there at the moment.
A few thoughts. There's no inherent reason that the image of an
openmcl app has to live in /Contents/MacOS - the image(s) could just
as well be in Resources. This would leave just a universal binary
kernel which would know which image to load. As for development, I
think that Gary's idea of focusing on X86-64 is realistic give how
long it would likely take to complete an intel back-end. It is also
quite reasonable that Gary should want to wait for confirmation from
Apple that they are in fact moving to X86-64 in the near future
(i.e., not just IA32 which is all that's been mentioned so far).
> While watching the keynote, I couldn't help noticing the obscene
> bias for Xcode. Telling Metroworks users they have to switch to
> Xcode! Really! Jobs clearly isn't even considering vendors of
> other language implementations.
Some of us have noted in other fora that Apple have been pushing
Cocoa and Xcode for quite some time. Some of us have considered that
Apple was not so subtly hinting that taking the Carbon or Carbon/
CodeWarrior path was one day going to lead to a world of pain. Some
have speculated that this might explain why all of Apple's own
applications were done in Cocoa with the sole exceptions of legacy
apps from Mac OS Classic such as Finder and iTunes. Some have even
speculated that Apple has been pushing Cocoa/Xcode because this
pairing has been capable of cross compiling for years and that Steve
"Marklar" Jobs has been "keeping our options open."
In effect there's no way that Jobs could have been more helpful to
other language implementors without revealing outright that a cpu
architecture switch was in the pipeline. Naturally Apple wanted to
limit the Osborne effect of this announcement, so the best they
could do until now was to strongly suggest that developers move to
XCode, and move from Carbon to Cocoa. Apple have also helped out
other language implementors by making available a public API to the
Objective-C runtime which has been used to bridge a number of
languages to Cocoa. One recent story has the maintainers of PyObjC
porting their bridge to intel in just a couple of hours. So if you
followed Apple's advice, you're in good shape.
The issue for openmcl of course is that unlike Python it is not an
interpreter which can just be written in portable C. It is a native
code compiler. These are inherently less portable (though still
portable of course if you compile to some intermediate representation
and then do different architecture back ends). So, as Gary said, it
would be good to know what the ultimate target architecture is before
starting this fairly time consuming process. If any lurkers on this
list have any knowledge about this ultimate direction it would be
nice if such persons could share this information with Gary at the
earliest possible date.
Raffael Cavallaro, Ph.D.
raffaelcavallaro at mac.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Openmcl-devel