[Openmcl-devel] OpenMCL Versions

[Cyrus Harmon]

Having ported the SBCL linux/x86 port to Darwin/x86, I'd claim that  
it's a bit more than just some #ifdefs and cutting-and-pasting to  
port a lisp from linux or windows to MacOS. Of course somebody like  
Gary could probably have done it in a fraction of the time it took  
me, but issues like working around bugs in Mac OS's handling of  
SIGTRAP, finding all the places where the stack needs to be 16-byte  
aligned to make MacOS happy, frobbing the lisp stack when calling  
into C so that it properly returns to lisp, getting the LDSO stubs  
working etc..., all served to make this much more difficult than it  
seemed like it should be. All of these things are fairly trivial, at  
least after you've spent the requisite week trying to figure out why  
the hell you're pseudo-atomic calls aren't really pseudo-atomic  
(MacOS's busted SIGTRAP) all without the benefit of a debugger  
because GDB can't be used to debug programs that intentionally  
trigger memory protection violations because GDB can't step across an  
EXC_BAD_EXCESS. And don't get me started about the changes required  
to support the (still unstable) threaded version of SBCL.

I guess that's "should have been more nearly..." in the sense that  
OpenMCL _should_ have run under Rosetta, but thanks to Rosetta's  
"impercise exceptions" are whatever Apple called it, neither OpenMCL  
nor SBCL did, but that's yet another story.

But this is openmcl-devel, not macos-porters-rants, so I'll be quiet  
now. But I would like to point out that even if lispworks runs on x86  
and windows, getting things working properly on MacOS is probably a  
fair amount of work. Much less than that required to port the x86-64  
openmcl to x86, as you don't have different sets of instructions and  
registers to deal with, but it's still some effort.

Cyrus

On Aug 17, 2006, at 5:48 PM, Hamilton Link wrote:

> Strictly speaking, for LispWorks it should have been more nearly a
> matter of #ifdeffing things or comparable cut-and-pasting, because
> LispWorks ran on x86 on windows and linux already.  So if they get a
> dozen customers they're probably not far from recovering their  
> expenses.
>
> In contrast, it's been quite some time since openmcl ran on something
> with less than 32 or however many general-purpose registers (well... I
> think there was a strongarm port, what does that have 16 regs?), and
> it's a big hassle to change the way a compiler does register  
> allocation,
> particularly when it's a lisp compiler which has to allocate registers
> in a garbage-collection-friendly way, and wants to have a lot of  
> things
> with register-speed access to begin with.  If you find LispWorks
> difficult to afford it will probably be difficult to adequately
> compensate Gary for the required effort... Plus for something  
> comparable
> to an openmcl port fee, it's my understanding any Intel Mac Mini or  
> new
> iMac user can buy a Merom (already on the market, just not in Apples,
> right?), pop it in their system,* and be running the 64-bit version of
> Tiger, without distracting Gary from bigger things.
>
> 'scuse me, I think I'm going to go run out and buy a Mini, I've  
> just got
> to try this...
>
> h
>
> * OK, so any Apple Mini or iMac owner who wants the hassle and doesn't
> mind probably invalidating their warrantee...
>
> Phil wrote:
>
>> Any language/application that includes its own compiler (i.e.
>> OpenMCL) can't take advantage of the 'little checkbox'/ifdefs that
>> other apps can.  They must to write the behind the scenes code to
>> make the checkbox/ifdefs possible.  It's a tough situation as it's
>> bad enough that there was one architecture switch, but now we're on
>> the second in less than a year (I've always bought the rumor that
>> Apple never wanted IA32 but had to use it from a product timing
>> standpoint.)  I'm sure the Lispworks guys aren't any happier... they
>> just got their IA32 product out the door a couple of weeks before  
>> WWDC.
>>
>> The first generation of Intel machines has me experiencing a bit of
>> deja vu as I seem to recall the first generation of PPC machines were
>> rather quickly not capable of running later software releases due to
>> differences/limitations between the 601 processors and it's
>> successors.  It will likely not be to the same degree, but does seem
>> like the same type situation.
>>
>> On Aug 17, 2006, at 4:29 PM, Justin Fagnani-Bell wrote:
>>
>>
>>
>>> I'm surprised at the amount of work you
>>> estimate. I know hardly anything about the x86 ISA or what's  
>>> involved
>>> in a Lisp implementation (I gather it's very low level). It's too  
>>> bad
>>> that it can't be written so that a few #DEFs and compiler flags will
>>> produce either a IA32 or EM64T version.
>>>
>>>
>>
>> _______________________________________________
>> Openmcl-devel mailing list
>> Openmcl-devel at clozure.com
>> http://clozure.com/mailman/listinfo/openmcl-devel
>>
>>
>>
>>
>
>
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel