[info-mcl] some issues (Rosetta, ia32 port of MCL)
Bob Futrelle CCIS
futrelle at ccs.neu.edu
Wed Oct 17 16:49:08 EDT 2007
When MacSpeech was trying to get started, they asked for $100 each
from people they would then call "Founders". I sent them $100, they
created a good product, and sent me a free copy, and a t-shirt.
They're still in business after some years now.
I'm willing to pay in advance for an up-to-date MCL of some flavor.
- Bob Futrelle
On Oct 17, 2007, at 3:11 PM, Alexander Repenning wrote:
> Hi Gary,
>
> took a while to absorb all this. Thank you for the detailed and
> cautiously optimistic analysis.
>
> I have only one big question: WHEN CAN YOU START?
>
>
>
> Also given the optimistic answer of Alice regarding Mach-O
> compatibility I would think it would be almost crazy not to make MCL
> 5.3 (or whatever one would like to call the Rosetta compliant version
> of MCL 5.2). Clearly this will require some exploratory surgery and a
> lot of testing but I am sure you can easily manage to recruit some
> eagerly awaiting MCL developers to help with this.
>
> It appears that MCLs non-preemptive/synchronous threading is a
> blessing that will help making the patch. I wonder if there are any
> ideas that could be gotten from LispWorks? They managed to deliver
> Rosetta compliance via patch and even achieve pretty good performance.
>
>
> Seriously, what are the next steps to make this happen?
>
>
> more technical feedback below.
>
> On Oct 14, 2007, at 5:01 PM, Gary Byers wrote:
>
>> [I tried to resubscribe to info-mcl a week or so ago; I found that I
>> needed to hold my head in both hands to keep it from exploding and
>> quickly unsubscribed; I just resubscribed in digest mode, so at worst
>> I'll only need to assume the Edvard Munsch "Scream" pose once a day.]
>
> sorry about that...
>>
>> To try to answer (in no particular order) a few questions that've
>> come
>> up:
>>
>> - MCL is a CFM application (though I think that I've heard Alice
>> say that 5.2 uses bridging technology to make "native" OSX Carbon
>> stuff accessible via #_ and friends.) CFM (the classic MacOS
>> Code Fragment Manager) is PPC-only, so any ia32 port would have
>> to involve making MCL into a native ("Mach-o") application and
>> addressing all of the issues that come up. Those issues are
>> probably a good deal less significant than the issues related
>> to changing to a different architecture, but they're certainly
>> significant.
>
> aside of creating the Mach-O bundle MCL 5.2 is almost there (see
> Alice's email)
>
>>
>> - It's been a few years since I looked at MCL sources and about
>> as long since I've thought about it, but I think that all exceptions
>> in MCL are synchronous (caused by various combinations of illegal/
>> trap
>> instructions and by memory protection faults.) Changing MCL's
>> compiler
>> and runtime to not generate synchronous exceptions is certainly
>> possible,
>> but there are lots of subtle issues and interactions among those
>> subtle
>> issues.
>
> I don't think much has changed.
>
>> (build-stack-frame-and-save-return-address-and-callers's-
>> context-in-it)
>> (compare nargs 0)
>> (beq+ @ok) ; branch if equal, predict taken
>> (call wrong-number of-args-error)
>>
>> which might work OK for things that took a fixed number of arguments
>> (goodbye, leaf function optimization!) but would require some changes
>> to how things are done in other cases. I'd believe that most of
>> those
>> changes are pretty small in and of themselves, but I'd also believe
>> that there'd be something of a snowball effect (where a group of
>> changes winds up affecting something far removed from "inability to
>> use synchronous exceptions".) I wouldn't want to estimate how long
>> it might take to make these changes, but "longer than it might seem
>> at first glance" is often a good answer to that question, and that
>> may be especially true in this case. (And yes, I do realize that
>> replacing a trap with a comapare-and-branch sounds like a simple,
>> localized change.) There'd almost certainly be a tunnel somewhere
>> with light at the end of it.
>
> We can live without the leaf function optimization.
>
> Much of our code is calling APIs such as OpenGL. OpenGL, for
> instance, is not really thread safe anyway. The non preemptive MCL
> threading has not been an issue for us in this respect. In other
> words this should not cause a problem for Rosetta with the scheme you
> are suggesting. Of course, it would be nice if the necessary stack
> frame building overhead would be kept minimal. If so, a code base
> like ours calling a lot of functions via FFI and balancing CPU and
> GPU processing may actually work pretty well via Rosetta on a Intel
> Mac. Just to illustrate an example from MCL 5.2
>
> a high frequency OpenGL call like this: (glvertex3f 1.0 1.0 1.0)
>
> will be mapped to:
>
> (CCL::PPC-FF-CALL (CCL::MACHO-ADDRESS
> #<MACHO-ENTRY-POINT "glVertex3f"
> "Carbon.framework" #x3F6696E>)
> :SINGLE-FLOAT
> GL::ARG1
> :SINGLE-FLOAT
> GL::ARG2
> :SINGLE-FLOAT
> GL::ARG3
> :VOID)
>
> ? (disassemble 'glvertex3f)
> (TWNEI NARGS 12)
> (MFLR LOC-PC)
> (BLA .SPSAVECONTEXTVSP)
> (VPUSH ARG_X)
> (VPUSH ARG_Y)
> (VPUSH ARG_Z)
> (LWZ NARGS 331 RNIL)
> (TWGTI NARGS 0)
> (STWU SP -80 SP)
> (STW RZERO 8 SP)
> (LWZ ARG_Z '#<MACHO-ENTRY-POINT "glVertex3f" "Carbon.framework"
> #x3F6696E> FN)
> (SET-NARGS 1)
> (LWZ TEMP3 'CCL::MACHO-ADDRESS FN)
> (BLA .SPJMPSYM)
> (VPUSH ARG_Z)
> (LWZ TEMP3 12 VSP)
> (CLRLWI IMM0 TEMP3 30)
> (CMPWI IMM0 2)
> (BNE L80)
> (LBZ IMM0 -3 TEMP3)
> L80
> (TWNEI IMM0 15)
> (LFS FP0 -2 TEMP3)
> (STFS FP0 24 SP)
> (LWZ TEMP3 8 VSP)
> (CLRLWI IMM0 TEMP3 30)
> (CMPWI IMM0 2)
> (BNE L112)
> (LBZ IMM0 -3 TEMP3)
> L112
> (TWNEI IMM0 15)
> (LFS FP0 -2 TEMP3)
> (STFS FP0 28 SP)
> (LWZ TEMP3 4 VSP)
> (CLRLWI IMM0 TEMP3 30)
> (CMPWI IMM0 2)
> (BNE L144)
> (LBZ IMM0 -3 TEMP3)
> L144
> (TWNEI IMM0 15)
> (LFS FP0 -2 TEMP3)
> (STFS FP0 32 SP)
> (LFS FP1 24 SP)
> (LFS FP2 28 SP)
> (LFS FP3 32 SP)
> (LWZ ARG_Z 0 VSP)
> (LA VSP 4 VSP)
> (BLA .SPFFCALLADDRESS)
> (MR ARG_Z RNIL)
> (BA .SPPOPJ)
> ?
>
>
> I don't think stack frame building overhead would make a big
> difference to this.
>
>
>>
>> I did want
>> to point out that there'd be at least some of this snowball effect
>> and that some obvious changes are a little subtler than they might
>> first appear to be.
>
> Makes sense but I think this would definitely be worth an effort to
> try.
>
>>
>> - To state the obvious: -if- someone made MCL run under Rosetta,
>> the result would probably offer a high degree (possibly total)
>> source compatibility with existing MCL 5.x code. It wouldn't
>> offer much in the way of binary compatibility: existing fasl
>> files (containing code that generates exceptions) would have to
>> be recompiled, etc.
>
>
> no problem whatsoever. I think most MCL users would have no issue
> with this.
>
>>
>> - There are some other MacOS PPC emulators (besides Rosetta) that
>> might offer the ability to run legacy MCL code on Intel Mac hardware.
>> (Try Googling for "SheepShaver" or "pearpc" or "QEMU"; there may be
>> others.) I have no idea whether any of these things would offer a
>> reasonable solution for people interested in the general idea of
>> running PPC MCL under emulation, but that might be worth exploring.
>
> They may work indeed for some people but we cannot force users of our
> apps to buy/download/install these apps. Also, as emulators, as
> opposed to the Rosetta dynamic translator, at least the one that I
> tried are hopelessly slow. An app with many API call may run actually
> surprisingly fast on Rosetta. There is a good chance that an MCL
> OpenGL app may run faster on a new Intel Mac via Rosetta than on a
> 2006 PPC Mac.
>
> all the best, Alex
>
>>
> Prof. Alexander Repenning
>
> University of Colorado
> Computer Science Department
> Boulder, CO 80309-430
>
> vCard: http://www.cs.colorado.edu/~ralex/AlexanderRepenning.vcf
>
>
> _______________________________________________
> info-mcl mailing list
> info-mcl at clozure.com
> http://clozure.com/mailman/listinfo/info-mcl
More information about the info-mcl
mailing list