Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!hoptoad!tim
From: tim@hoptoad.uucp (Tim Maroney)
Newsgroups: comp.sys.mac.programmer
Subject: Re: System 7.0 Q & A
Message-ID: <7356@hoptoad.uucp>
Date: 18 May 89 17:25:58 GMT
References: <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>
Reply-To: tim@hoptoad.UUCP (Tim Maroney)
Organization: Eclectic Software, San Francisco
Lines: 46

In article <7321@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes:
>And all of these low memory locations can be trapped by the MMU and handled
>transparently to the application.

In article <30935@apple.Apple.COM> phil@Apple.COM (Phil Ronzone) writes:
>Well, that is not economical. When we launched a version of Lode Runner
>under A/UX, guess who was watching the clock ticks rather than using an
>A-line trap? (A/UX normally updates the ticks much less frequently).

Interestingly, when I was talking by e-mail with an Apple employee last
year about all the compatibility problems with 6.0, he told me that
Lode Runner was an example that proved that perfectly conforming
applications could be written.  Guess that's now out the window.

Anyway, I agree that this is a problem with Ticks.  However, most low
memory globals, and especially the error storage globals that were
under discussion, are not going to have to be accessed that often and
certainly don't need to be updated by the system every sixtieth of a
second.  The clock globals are in a rather unique position.  Other
globals are far more economical.

>You can now set an environment variable, and A/UX will issue signals to update
>the clock ticks lowmem much faster -- except now that process is taking a lot
>of signals.

Also, I don't know that this is neccessarily the most economical way to
do this.  If you page fault on access to the page containing Ticks, then
the page fault handler can fill it in for the software without actually
updating a real page anywhere.  You do this once per access, so it may
turn out to be just as slow, but I'd like to see some benchmarks.

>Point is -- a lot of looking at the low memory globals CAN be caught, but
>would (could) be very expensive in cycles.

Some, definitely.  But, say, ResErr and PrintErr?  I don't think so.  I
don't think the clock globals accurately reflect the virtual economics
of most of the low memory globals.
-- 
Tim Maroney, Consultant, Eclectic Software, sun!hoptoad!tim
 "Those Mayas were sacrificing not only pagan children, but baptized
 Christian children, for crying out loud!  And they were carrying out
 those sacrifices, those barbarities, with great savagery, without
 giving the victims the benefit of the humane types of death that the
 European Church accorded even to heretics and witches during that
 century, such as burning at the stake."
		-- Matthew Rosenblatt, rec.arts.books