From: Pulsar 
To: news@xlr8yourmac.com 
Subject: GetNextEvent/WaitNextEvent and Non-nativeness
Date: Monday, November 23, 1998 2:51 PM

Hi Mike, 

I hope I'm not contributing too much to your collosal pile of email, but 
I wanted to comment on what was stated about GetNextEvent (and 
WaitNextEvent). 

There is a very good reason why it has taken so long to make parts of the 
OS native. A lot of thought has to go into it or else it can make the 
computer perform _slower_! (Really!)

The whole Tool Box is based on the concept of the 68k trap table. There 
is a series of instructions beginning with the hex value 'A' that are 
unimplemented on the 68k line of chips. When one of these instructions is 
called, an exception is generated and an OS defined handler for that 
exception is invoked. The instruction called is used as an index into 
what is called the trap dispatch table. This is a table containing the 
memory locations of the functions that make up the Mac OS ToolBox. When a 
program calls a ToolBox routine, it basically goes through the trap 
dispatch table and eventually the apropriate ToolBox function winds up 
being called. (Things are a little more complicated than this, but it's 
fundamentally correct I think.)

In the case of a PPC application calling on a PPC native ToolBox 
function, only the trap dispatch table needs to be loaded (though I'm not 
absolutely sure on this point). This does not incur a mode switch from 
PPC to 68k code (I think). If the ToolBox function is not native or if it 
is and the calling application is not, then there is a mode switch which 
entails not only loading the Trap Dispatch Table, but also the 68k 
emulator. This mode switch is costly in time. Loading the trap dispatch 
table is enough to make things somewhat slow, but also loading the 
emulator makes the operation a whole lot slower.

Certain things cannot be made native in the Mac OS without breaking every 
application ever written for the Mac (and huge swaths of the OS too). One 
of these is the interrupt handler. Because of the Mac OS's reliance on 
the 68k architecture for OS function calling, the interrupt handler must 
remain emulated. Anything that relies on interrupts (things like the File 
Manager, the Event Handler, certain parts of the Process Manager, and 
others) eventually end up calling 68k code. Because the mode switch can 
take a relatively long time, it is often _faster_ to leave these services 
emulated just to avoid that mode switch from PPC to 68k code and back 
(often times repeatedly within the same function call).

When making an OS function native, you have to check to see if your 
function will be calling on any other non-native OS function(s). If it 
is, then you have to carefully consider whether the speed up by going 
native at the upper level function offsets the slow down caused by the 
mode switches when calling these emulated functions. Most often, it 
won't. In order to make one OS function native, you frequently have to 
make a whole cascade of other functions native in order not to sacrifice 
performance.

Certain things absolutely rely on parts of the OS that cannot be made 
native so they in turn can't be made native without slowing things down. 
This is why most of the File Manager, and Event Manager are still 
emulated. Believe or not, it's actually faster to leave them emulated 
than to make them native. 

This can't be fixed without basically scrapping the Mac OS and going with 
something new. :(

Copland tried to keep compatability with old applications in the same 
environment as "new" applications. It was doing this with the goal of 
eventually allowing those same  "new" applications to move to a fully 
preemptive/protected scheme that was supposed to exist in the next OS 
release (Gershwin). This is one of the primary reasons Copland failed 
(though there were others). It's just far too complex to try and do that. 

Carbon in Mac OS X completely sacrifices backwards compatability by 
forcing applications to be recompiled and rewritten (not completely, but 
somewhat). This is what makes Carbon at least more feasible than Copland 
ever was. 

Both are/were schemes for making the Mac OS native, but they take 
different approaches. Yellow Box on Mac OS X doesn't have any Mac OS 
heritage to rely on and its design was such that it can be made entirely 
PPC native without sacrificing performance as in the current Mac OS. 

Anyhow, thanks for reading this far. I hope I didn't take up too much of 
your time. 

Your site is a great resource. It is a twice daily visit for me, and has 
been tremendously useful at times. Thank you for keeping it up!  I and 
other Mac users I know really appreciate and enjoy it.

Ryan Tokarek
http://www.cloudmaster.ml.org/pulsar/