Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!asuvax!stjhmc!p88.f15.n300.z1.fidonet.org!Lawson.English
From: Lawson.English@p88.f15.n300.z1.fidonet.org (Lawson English)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Animation
Message-ID: <3258.27C3D62E@stjhmc.fidonet.org>
Date: 20 Feb 91 06:28:21 GMT
Sender: ufgate@stjhmc.fidonet.org (newsout1.26)
Organization: FidoNet node 1:300/15.88 - Tucson Apple Core, Tucson AZ
Lines: 28

Rick Holzgrafe writes in a message to All

RH> GetTrapAddress may not work forever either (we are recommending 
RH> against its use, as Brent implies) but directly accessing some 
RH> low-memory globals is already broken in some environments, while 
RH> GetTrapAddress at least still works. If you *must* bypass the 
RH> trap mechanism, GetTrapAddress is safer than accessing Ticks 
RH> directly

I can understand that given protected memory, the supervisor mode, etc, that
GetTrapAddress may someday be inadvisable for patching, but why is its use for
finding the trap table entry and jumping directly there a future no-no? Our
ROM-use-profiler broke after System 4.2, and would be totally useless in a MultiFinder
environment anyway, but we found out stuff about ROM/trap use that probably
will never change using the 68xxx, and I can guaruntee that some programs will
show significan speedups by using NGetTrapAddress, no matter how fast the CPU
(especially using a fast CPU?).

As long as traps are used, wouldn't it be advisable to have NGetTrapAddress
available?


Lawson
 

--  
Uucp: ...{gatech,ames,rutgers}!ncar!asuvax!stjhmc!300!15.88!Lawson.English
Internet: Lawson.English@p88.f15.n300.z1.fidonet.org