[Openmcl-devel] More Intel: Rosetta & Universal Binaries

[Raffael Cavallaro]

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.

regards,

Ralph

Raffael Cavallaro, Ph.D.
raffaelcavallaro at mac.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.clozure.com/pipermail/openmcl-devel/attachments/20050610/ecbc11b9/attachment.htm>