Path: utzoo!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: XFCN/XCMD string in LSC C v3.0 Message-ID: <6952@hoptoad.uucp> Date: 10 Apr 89 17:33:40 GMT References: <12964@dartvax.Dartmouth.EDU> <28737@ucbvax.BERKELEY.EDU> <12968@dartvax.Dartmouth.EDU> <6944@hoptoad.uucp> <12970@dartvax.Dartmouth.EDU> Reply-To: tim@hoptoad.UUCP (Tim Maroney) Organization: Eclectic Software, San Francisco Lines: 80 Recap to avoid excessive quotation: We're discussing the problems of using globals in non-application code, specifically with respect to stashing globals in code space and providing globals in non-apps under MPW C. In article <12970@dartvax.Dartmouth.EDU> earleh@eleazar.dartmouth.edu (Earle R. Horton) writes: > > Well, Apple thinks that this *is* self-modifying code. To be >honest, I don't know if this kind of thing gets into the code cache or >not, but it might someday. If you want to write straight-up code >then writing to logical code blocks is to be avoided. If you want to >write tricky code, then you may do so. The best advice seems to be to >avoid being tricky if you want your programs to last. ("This" being putting globals in code space.) In my opinion, the Tech Note is being loose in its definitions. Most people reserve the phrase "self-modifying code" for software that rewrites its INSTRUCTIONS. If you review the Tech Note, you will also find that no rationale is given for not putting globals into code space; he just says that since it's "self-modifying code" (it isn't) it's tricky and shoudl be avoided. The fact remains that such non-executable and non-executed data is not stored in the instruction cache and is very unlikely to be on any future processor. Motorola understands that its processors need to make the minimum of assumptions about the operating environment, and when it has an approach in place that works in every conceivable situation (only caching instructions that it has executed, and only consulting the instruction cache during instruction fetch) it is inconceivable to me that they would change it to a less general appraoch that has no apparent advantages. It's always best to avoid trickiness. I don't consider this technique particularly tricky. I do think the Tech Note you cited was employing a tricky definition, however. > Programming the Macintosh is difficult. Relying on a compiler >which uses questionable tricks to make that task appear easier is >risky at best. MPW compilers do not implement global read/write >variables for non-application code resources, presumably because Apple >has not found a safe place to stash the base register. It doesn't implement them in the sense of holding your hand at every step of the process. However, it doesn't put up much of a fuss if you decide to do it yourself. The compiler and linker will happily churn out a consistent set of offsets from A5. As for where to stash the data register, newer Technical Notes explicitly state that if you must, you can stash your globals register in code-relative space. (This is primarily for interrupt-driven code, but it works fine for maintaining your own globals register.) > Conclusion: Using global variables in non-application code >resources is at present risky business. Even though the compiler >writer says "Go ahead and do it," the choice to be tricky or not is >yours. Conclusion based on what? At present, it's perfectly safe. In the future, it is remotely possible that this culd break if Motorola does something tremendously stupid, or if Apple implements a memory-protected OS that destroys many of its major third-party products. As I've said, it is practically impossible to write medium-and-larger programs that completely eschew globals. Something of the magnitude of TOPS never could. TOPS is a user-level protocol; programmer protocols like TCP also have a need to maintain connection tables and access them when a packet comes in. It might seem that a protocol could avoid globals by letting the protocol caller maintain a copy of a connection record, but the software needs to access the tables on the fly, not just when the caller accesses the protocol implementation. And so on. A small code resource like a definition routine or XCMD can probably get by with no globals, and ought to do so if possible. But as I said previously, globals are a neccessary evil in modern programming languages. Cavalier dismissals of their necessity are not too likely to convince someone who has been involved in large projects and lots of large code resources. -- Tim Maroney, Consultant, Eclectic Software, sun!hoptoad!tim "The above opinions and suggestions have absolutely nothing to do with the little, fat man putting crisp, $100 bills in my pocket." -- Alan Vymetalik