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

[David Steuber]

Hi Gary & Co,

I just watched the 2005 Keynote on Apple's site.  I have a few OpenMCL 
questions (I know you must be sick of this by now, but please bear with 
me) that don't have to be answered straight away since there is a one 
to two year transition time from the PPC switch to Intel plus 
additional time in which legacy hardware needs to be supported.

The first question is, will OpenMCL work under Rosetta?  From the talk 
on Xcode 2.1, the "tweaks" needed for source code for Cocoa require are 
fairly minor (presumably for Objective-C code) while the tweaks for 
Carbon are not much worse.  OpenMCL has a fairly decent FFI, so I 
expect to possibly still have access to the APIs even with PPC code 
generation if Rosetta doesn't break the way Lisp works.

The second question is how complicated will Universal Binaries be?  The 
C portion of OpenMCL has never given me any compile troubles.  So it 
seems fair to speculate that with Xcode 2.1 or later, the kernel 
portion may build with the flick of a switch, so to speak, so that part 
is a Universal Binary.  As for the image file, could there perhaps be 
one image each for PPC and Intel?  Or would it be better if they were 
Universal as well?  And what about the .dfsl files produced?

I was surprised to hear in the keynote that the $999 development 
machines have to be given back.  Will that $999 be refunded?  I don't 
know how much of that is a simple security deposit and how much is a 
lease.

I've been thinking about this transition Apple is making.  I've had a 
lot of emotion about it.  I had been planning at some point to look 
into OpenMCL's LAP to take advantage of PPC special features like 
Altivec.  Now I don't see myself doing that.  I would rather just wait 
for Intel before doing LAP.  More of an immediate concern to me is the 
fact that OpenMCL, imho, is the best free Lisp going for OS X.  SBCL is 
nice and fast for floating point math, but OpenMCL seems to be faster 
with generic function calls.  Then of course there is the native 
threading and C callbacks that make using Carbon possible.  If I ever 
become a fan of Cocoa, there is that also.  In short, I would like to 
see OpenMCL continue on over the years.

Gary, if there is a road plan for OpenMCL, will you post it to this 
list?