[info-mcl] Fwd: Can we get some price quotes?

[Ron Garret]

On Oct 14, 2007, at 11:15 AM, svspire at sandia.gov wrote:

>> On 10/14/07 9:41 AM, "svspire at sandia.gov" <svspire at sandia.gov> wrote:
>>
>>> There's some good info about exceptions in OpenMCL here:
>>> http://openmcl.clozure.com/Doc/index.html#Threads-and-exceptions
>>>
>>> Much of this information is applicable to MCL as well, with the
>>> notable exception (n.p.i.) that MCL doesn't use native threads.
>>
>> Is this really applicable to MCL? OpenMCL uses Mach exceptions,  
>> and MCL is a
>> CFM application.
>
> Doesn't matter. Both Lisps invoke exceptions for many of the same
> purposes. Remember that they both forked from a common ancestor code
> base. Post-fork, some things changed but a lot remained the same.
>
> At some point, the software exceptions generated by MCL or OpenMCL (at
> whatever abstraction layer) result in a hardware exception on the
> PowerPC processor, and it is these exceptions that Rosetta is bungling
> in its emulation of the PPC hardware.
>
> Fixing this aspect of Rosetta would, for all practical purposes,
> instantly make existing MCL and existing OpenMCL-PPC32 applications
> "just work" on Intel Macs.

But that's not going to happen.

What I don't understand is why it is hard to replace all the software  
exceptions with MCL's own code that emulates the exception.  After  
all, software exceptions just fram the contents of registers  
somewhere and jump to a handler, right?

The hard part, it seems to me, is if Rosetta doesn't handle hardware  
exceptions (like guard pages) properly.  That's much harder to work  
around, but even that seems doable if you don't care about  
efficiency.  You need to add a software check after every instruction  
that could potentially produce an exception.  Ugly, horribly slow,  
but it ought to work.  That's the kind of solution I had envisioned  
when I asked for estimates on the condition that speed is not a concern.

rg