Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!cs.utexas.edu!oakhill!davet
From: davet@oakhill.UUCP (David Trissel)
Newsgroups: comp.sys.mac.programmer
Subject: Re: PMMU and low memory sharing
Message-ID: <2065@oakhill.UUCP>
Date: 18 May 89 19:08:18 GMT
References: <811@key.COM> <30353@apple.Apple.COM> <4666@okstate.UUCP> <1787@internal.Apple.COM> <7266@hoptoad.uucp> <13472@dartvax.Dartmouth.EDU> <7321@hoptoad.uucp> <30935@apple.Apple.COM> <18-May-89.104411@192.41.214.2>
Reply-To: davet@oakhill.UUCP (David Trissel)
Organization: Motorola Inc., Austin Tx.
Lines: 32

In article <18-May-89.104411@192.41.214.2> amanda@intercon.UUCP (Amanda Walker) writes:
>In article <811@key.COM>, perry@key.COM (Peter Kiehtreiber) writes:
>> Could somebody please explain to me WHY all the applications
>> in a Mac with PMMU have to share their low-memory globals?
>
>I think Phil's point was that a number of applications use low memory
>globals to monitor real-time status (such as the tick count), and it
>gets pretty uneconomical to have to update this all the time.

If you are able to "think" at the processor's microsecond level of operation
this turns out to be simply untrue.

Let's take the slow "Classic" Mac which runs at an effective MC68000 rate of 
about 5.2 Mhz once the standard vertical interrupt handler and screen refresh 
are taken into account. Let's use worst case assumptions here and say your 
Mac is running 50(!) applications. The 60'th second tick update should 
certainly take less than 100 cycles to find the next application's low memory 
global base and write the new value in.  A simple calculation shows that 
5,000 cycles per second amounts to only .1% lost processing power.

To those people (and I'm sure there are a few out there) who will gripe about 
such an insignificant loss of computing power I suggest that they avoid moving
their mouse in the future. The processing time required for mouse movement 
(especially if the cursor is over the menu bar) is much more significant.

It may be that there are good reasons for not providing private virtual low 
memory globals for each application. But initially this is the obvious place
from which to start a design investigation because of the high portability
considerations.


 -- Dave Trissel  -  Motorola Semiconductor