wb1j+@andrew.cmu.edu (William M. Bumgarner) (04/08/89)
I'm in the process of converting a set of XFCN's from LSC to MPW C v3.0. The LSC code contained inline assembly to set-up and restore the A4 register so that global (?) strings could be used... Something similar must be required in MPW C v3.0, but is A4 valid? Should I use the same inline code (code that worked under a different environment)? Anyone have any experience with such a thing? thanks in advance, b.bum wb1j+@andrew.cmu.edu
earleh@eleazar.dartmouth.edu (Earle R. Horton) (04/09/89)
In article <kYDWlFy00VQE8JCEES@andrew.cmu.edu> wb1j+@andrew.cmu.edu (William M. Bumgarner) writes: >I'm in the process of converting a set of XFCN's from LSC to MPW C v3.0. > >The LSC code contained inline assembly to set-up and restore the A4 register >so that global (?) strings could be used... > >Something similar must be required in MPW C v3.0, but is A4 valid? Should I >use the same inline code (code that worked under a different environment)? > There is no way to implement global variables in non-application code resources created using MPW C. You will have to find an alternate means of storing this information. I suggest putting everything in a data structure, and passing the pointer to the data structure down your function chain. Strings which are considered constant, you might want to store in a 'STR#' resource. Using A4 as a base for global variables is a hack, anyway. There are situations I know of which will invalidate A4, making your global variables useless. (Dialog filter procs, for example.) There is a package on sumex which you might find useful, /info-mac/hypercard/xfcn-xcmd-glue.hqx. It contains source for a bunch of hypercard XCMDs implemented in MPW C and MPW Pascal. Earle R. Horton Graduate Student. Programmer. God to my cats.
austing@Apple.COM (Glenn L. Austin) (04/10/89)
In article <kYDWlFy00VQE8JCEES@andrew.cmu.edu> wb1j+@andrew.cmu.edu (William M. Bumgarner) writes: >I'm in the process of converting a set of XFCN's from LSC to MPW C v3.0. > >The LSC code contained inline assembly to set-up and restore the A4 register >so that global (?) strings could be used... > >Something similar must be required in MPW C v3.0, but is A4 valid? Should I >use the same inline code (code that worked under a different environment)? If you compile with the -b option on MPW C, the strings are referenced off of the PC, which means that you don't need to worry about strings. However, global variables are out. ----------------------------------------------------------------------------- | Glenn L. Austin | The nice thing about standards is that | | Apple Computer, Inc. | there are so many of them to choose from. | | Internet: austing@apple.com | -Andrew S. Tanenbaum | ----------------------------------------------------------------------------- | All opinions stated above are mine -- who else would want them? | -----------------------------------------------------------------------------
oren@apple.com (Tim Oren) (04/11/89)
In article <28684@apple.Apple.COM> austing@Apple.COM (Glenn L. Austin) writes: > If you compile with the -b option on MPW C, the strings are referenced off > of the PC, which means that you don't need to worry about strings. However, > global variables are out. We've found a way to get the effect of globals. In the same stack where the XCMD lives, create a dummy resource with known name and type, e.g., STUB 1. When the XCMD runs the first time, load the resource, detach it, mark it non-purgable and grow it to whatever size you need for your data, then do any initialization. On following calls, get the resources handle by name to reacquire your "globals". The overhead of the resource manager could make this too slow if your XCMD is called from an inner loop. For a slight speedup, lock the resource when entering the XCMD and dereference the handle to address things. Unlock it before exiting to avoid sandbarring the memory manager. Tim Oren oren@apple.com "As always, if you are caught or killed, the CEO will disavow all knowledge of your actions."
ech@pegasus.ATT.COM (Edward C Horvath) (04/12/89)
From article <1264@internal.Apple.COM>, by oren@apple.com (Tim Oren): > We've found a way to get the effect of globals. In the same stack where > the XCMD lives, create a dummy resource with known name and type, e.g., > STUB 1. When the XCMD runs the first time, load the resource, detach it, ^^^^^^^^^ > mark it non-purgable and grow it to whatever size you need for your data, > then do any initialization. On following calls, get the resources handle > by name to reacquire your "globals"... NO! do NOT detach! If you do, you will no longer be able to reacquire with Get(Named)Resource: after DetachResource, a call to Get(Named)Resource will get a fresh copy of the original resource, not the detached (and now orphaned!) copy. Also, don't call ChangedResource unless you want changes to your globals retained in the resource. This is almost certainly NOT what you want. I know, you didn't even THINK of calling ChangedResource until I mentioned it... =Ned Horvath=
wb1j+@andrew.cmu.edu (William M. Bumgarner) (04/12/89)
Thanks for all the advice on this one-- much appreciated. I used the -b compiler flag to get what was needed... another case of not reading the docs quite close enough. The idea for globals is interesting-- I will pursue that one... thanks. b.bum wb1j+@andrew.cmu.edu
oren@apple.com (Tim Oren) (04/12/89)
In article <2774@pegasus.ATT.COM> ech@pegasus.ATT.COM (Edward C Horvath) writes: > NO! do NOT detach! If you do, you will no longer be able to reacquire > with Get(Named)Resource: after DetachResource, a call to > Get(Named)Resource will get a fresh copy of the original resource, not the > detached (and now orphaned!) copy. > > Also, don't call ChangedResource unless you want changes to your globals > retained in the resource. This is almost certainly NOT what you want. > I know, you didn't even THINK of calling ChangedResource until I > mentioned it... Right you are - detach is not the right thing. That's what I get for posting without rechecking the original code :-) And yes, we did try ChangedResource, but that's only a good idea if you want to make your globals persistant between runs - which could be very useful if you are saving something like user preferences... Tim Oren oren@apple.com "As always, if you are caught or killed, the CEO will disavow all knowledge of your actions."