pers@ifi.uio.no (Per Siljubergs}sen) (09/25/90)
I have a few questions I can't find any good answers too.
I've looked everywhere, I hope. :-)
I'm writing an extension to the system. It includes INIT
code, VBL task and a couple of trap patches. I need global
data so that the INIT and the patches can communicate.
I would like to use A5 (the SAGlobals module from TN256)
or a relocatable block in the system heap. Anyway, I need
to store A5 or a handle to my globals between the calls
somewhere.
The usual tips regarding stand-alone code don't seem to
help me. Say one of my patches need access to the globals:
1) The patch can't get it's hands on my A5 world or a
handle to the globals through the parameters, because
they (the parameters) must be the same as the trap.
2) I can't set up A5 before the patch gets called. I have
no way to predict when the system or the applications
will call the trap.
Some solutions have come up. They are not very elegant,
I think:
1) Save the A5 or the handle directly into my stand-alone
code resource. Will this work with new processors like
68030 and 68040? These processors have intruction
cache on the chip. Isn't this solution almost like
selfmodifying code?
2) Use a driver for the communication. Overkill?
3) System 7.0 IPC? Is it possible? Even if it is, I would
like this to work with System 6.x.x too.
4) A hack I read in Joel West's book "Programming with
MPW", is to store the globals as an unpurgeable
resource in the sys heap at INIT time. The type and ID
of the resource is known, so my patch rutines can get
access by a call to GetResource. Will this work at
interrupt time?
What is the best solution? Other solutions? Please, I need
all the help I can get. I think many others would like some
info on this too.
-Per
Per Siljubergsaasen, Dept. of Informatics, University of Oslo, Norway
EMail: pers@ifi.uio.norob@cs.mu.oz.au (Robert Wallen) (09/26/90)
In article <1990Sep24.231618.29949@ifi.uio.no> pers@ifi.uio.no (Per Siljubergs}sen) writes: >I'm writing an extension to the system. It includes INIT >code, VBL task and a couple of trap patches. I need global >data so that the INIT and the patches can communicate. > 1) Save the A5 or the handle directly into my stand-alone > code resource. Will this work with new processors like > 68030 and 68040? These processors have intruction > cache on the chip. Isn't this solution almost like > selfmodifying code? I store globals like that at a known offset from by VBL control block and just walk along the VBLQueue looking for a key signature which identifies it. Seems to work fine for my cdev/INIT combination where I use a VBL with a 9 second timer (biggest figure I could fit -- I dont need the VBL except for mapping between cdev and INIT) There shouldnt be a CPU data/code protection problem because the control block is DATA and thus the code is not self-modifying. Even if it were though, you should be able to use whatever mechanism Apple implements which allows code to read in code resources from files (at which point they are data) and then map them to code -- iff this sort of memory protection ever arrives that is..
pers@ifi.uio.no (Per Siljubergs}sen) (10/04/90)
Thanks to all of you who helped me out with this. In article <1990Sep24.231618.29949@ifi.uio.no> pers@ifi.uio.no (Per Siljubergs}sen) writes: >The usual tips regarding stand-alone code don't seem to >help me. Say one of my patches need access to the globals: > > 1) The patch can't get it's hands on my A5 world or a > handle to the globals through the parameters, because > they (the parameters) must be the same as the trap. > > 2) I can't set up A5 before the patch gets called. I have > no way to predict when the system or the applications > will call the trap. Most of the answers I got, recommended to store a reference to the globals inside the stand-alone code segment. Here follows a little subset of comments (in received order): David Shayer <das@apple.com> writes: >The way I would probably do it is to store the A5 inside my code. >This is way DTS usually recommends. With a little assembly code, >you can set up space in your code, and have it set to zero. Also, >set up an assembly routine which returns the address of this space. >If its zero, you know its the first time through, and you have to >set up the A5 world. Otherwise just set A5 to the stored value. Mark Valence <kurash@chocorua.dartmouth.edu> writes: > ... set aside a longword inside your patch. This >way, the INIT that installs the patch can store a pointer >to your global variables in the space you provided. This >gets around the problem of the instruction cache because >you are writing to that memory location before the code >is run (so it's not in the cache), and once you've >written to it, it never changes (so the instruction >cache will always be valid). Larry Rosenstein <lsr@apple.com> writes: >> 3) System 7.0 IPC? Is it possible? Even if it is, I would >> like this to work with System 6.x.x too. > >Actually in System 7 you can use the Gestalt manager to register your A5 >value under a 4-byt signature. Each piece of code can then look up the >value of A5 using that signature. [My comment: This works with System 6.0.4 and later.] Andrew D. Sonenblick <sonenbli@oxy.edu> writes: >I use A4--and Think C makes this very simple for me. All I have to do >is set it up to the the value A0 had the first time my init was called.. >and yes, I do save this to my own code. Apple said this isnt that bad >and shouldnt be a problem. I have done this and it works on all >processors and all systems... -Per ---------- Per Siljubergsaasen, Dept. of Informatics, University of Oslo, Norway pers@ifi.uio.no