[Openmcl-devel] OpenMCL, Intel, Rosetta

Gary King gwking at metabang.com
Fri Jan 13 02:47:19 UTC 2006


Thanks Gary, this is excellent information well presented.

On Jan 12, 2006, at 2:56 PM, Gary Byers wrote:

> [I have not tried to run anything on a "released" MacIntel system,
> and the last DTK update that I saw was in mid-November.  It's possible
> that the released system differs from what I've tried to test on.]
>
> A few days ago, Apple released updated Rosetta documentation which
> says (in part):
>
> "Rosetta does not support precise exceptions. Any application that
> relies on register states being accurate in exception handlers or
> signal handlers will not function properly running with Rosetta."
>
> I think that that passage was newly introduced.  I'd been reporting
> the fact that exception handlers have invalid values for (some)
> registers as a bug, and was still holding out hope that Apple'd
> fix it.  I have no idea why it's hard to get this right or whether
> this limitation will be lifted in the future.  My personal,
> subjective opinion is that things may have rushed/priorities
> changed (the original Rosetta emulated a G3 without AltiVec;
> the current version seems to support AltiVec), and that getting
> this right may have been of lower priority than emulating
> AltiVec was.  This is pure speculation on my part.
>
> OpenMCL does expect exception/signal handlers to have accurate
> context information.  (It's especially frustrating, because it
> seems that Rosetta's able to get -most- register values right;
> the PC/srr0 and the MSR/srr1 seem to be wrong, but at least
> some of the others seem to be reliably correct.)
>
> If you try to run OpenMCL under Rosetta, the first thing that
> you'll find is that it's not possible to reserver ~2GB of memory
> on startup (I don't know whether Rosetta's in the way of whether
> there are other issues.)   Invoking the lisp with (for instance)
>
> shell> openmcl --heap-reserve 1GB
>
> gets around that.
>
> The released 1.0 image will eventually die (after mapping the
> heap image into memory and taking a LONG time to emulate some
> cache-flushing operations) because attempts to set up Mach-level
> failed and the first exception is unhandled.
>
> A fairly recent bleeding-edge image will try to detect Rosetta
> and install POSIX signal handlers instead of counting on Mach
> level exception handling in an emulated environment, and it
> dies trying to determine what the exception was (it segfaults
> trying to read the instruction at the (bogus) PC, the segfault
> handler segfaults doing the same thing, and eventually the
> stack overflows.)
>
> I'm sure that this limitation affects -some- other applications
> (including MCL and at least some other lisp implementations);
> if Apple believes that it's acceptable to release Rosetta with
> "imprecise" exception handling (I asked someone in Apple DTS
> what that meant; they didn't know for sure), I hope that they
> can be convinced otherwise.   I'll certainly try to do so.
>
>
> On Thu, 12 Jan 2006, Gary King wrote:
>
>> I haven't seen mention of this on the mailing list but I have heard
>> rumors that Digitool's MCL does not run under Intel Macs. Has anyone
>> tried OpenMCL on a DTK or new Macintosh yet?
>>
>> Thanks,
>> -- 
>> Gary Warren King
>> metabang.com
>> http://www.metabang.com/
>>
>>
>> _______________________________________________
>> Openmcl-devel mailing list
>> Openmcl-devel at clozure.com
>> http://clozure.com/mailman/listinfo/openmcl-devel
>>
>>


-- 
Gary Warren King
metabang.com
http://www.metabang.com/





More information about the Openmcl-devel mailing list