davet@oakhill.UUCP (David Trissel) (05/19/89)
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
phil@Apple.COM (Phil Ronzone) (05/20/89)
In article <2065@oakhill.UUCP> davet@oakhill.UUCP (David Trissel) writes: >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. The case in point was dealing with clock ticks. The point was a process, say a game, wanted to wait say 32 milliseconds for display/animation purposes. If it watched the low memory global, waiting for it to changed, it essentially had to run "un-context-switchable", otheriwise animation would be "jerky". If it told the operating system it wanted control back in 32 milliseconds, things would happen (hopefully) a lot smoother. An Excel app recalculating in the background isn't helped by an idiot app that is spinning on a low memory global. Tens apps spinning can make like miserable for background processes. Philosophical point more than a Mac OS specific point. +-----------------------------------------------------------------------------+ |Philip K. Ronzone, Apple Computer, 10440 Bubb Rd, MS 58A, Cupertino, CA 95014| |{amdahl,decwrl,sun,voder,nsc,mtxinu,dual,unisoft,...}!apple!phil | +-----------------------------------------+-----------------------------------+ | All "IMHOs" disclaimed and copyrighted. | Self defense is a human right ... | +-----------------------------------------+-----------------------------------+