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: <6963@hoptoad.uucp> Date: 11 Apr 89 21:03:23 GMT References: <12964@dartvax.Dartmouth.EDU> <28737@ucbvax.BERKELEY.EDU> <12968@dartvax.Dartmouth.EDU> <6944@hoptoad.uucp> <3756@sybase.sybase.com> Reply-To: tim@hoptoad.UUCP (Tim Maroney) Organization: Eclectic Software, San Francisco Lines: 88 In article <3756@sybase.sybase.com> dg@okra.UUCP (David Gould) writes: >Sorry, Tim, but Earle is right, even if for the wrong reasons. In a protected >or virtual memory environment, it is very common to use the MMU to map 'pure' >code and constant data pages as read only. Sure, and I expect that when Apple comes out with a memory protected OS, probably in 1990, application CODE resources and possibly some definition routines (WDEFs, MDEFs, CDEFs, LDEFs) will be mapped into read-only space. It is also possible that this will be done with DRVRs and CDEVs, though I doubt it -- too many of them stash things in code space so they can access them at the interrupt level without wasting time searching through system queues. Possibly even XCMDs/XFCNs will be mapped read-only. However, there are some resources that won't ever be marked as read-only unless they conspire to do it themselves, and that's the kind I usually write. For instance, INITs that install themselves in the system heap or BufPtr and patch traps won't be marked read-only because the system doesn't know what's going on -- as far as it's concerned, this is data. Once this kind of code is installed, it's not even a resource any more. Or, utility libraries that provide database services or implement a help system, stored as a code resource with a "routine selector" type dispatch routine at the start of the resource. These may remain resources, but of a non-standard type that the system has no way of recognizing. >It is quite likely that in Apple's future multitasking virtual memory system >that code resources will be mapped read only. Thus, under system N.0 (for some >large N) any code that writes on code resources will break. Not "any", for the reasons cited above. Some. Furthermore, I expect that Apple will have to provide a way to override this protection. For instance, suppose that your application implements a network protocol that installs a socket listener or protocol handler. There's no way around it -- that listener *must* stash its globals register (at least) in code space. If it doesn't, it has no way to communicate packets received to the rest of the application. Furthermore, it must be linked with the rest of the application, not as a separate code resource, because otherwise it can't know what offset to use for the "packets received queue" global. Other code that can't get around running at the interrupt level will also need to use this trick. Apple may or may not do this in a backwards-compatible way -- I hope they do. MultiFinder is backwards compatible because "no MultiFinder resource" means "not MultiFinder friendly". The same could be accomplished by a resource indicating "make my code resources read-only". If it's missing, they're read-write; otherwise, they're read-only. The same approach could be used with CDEVs and DRVRs, using an owned "make me read-only" resource. Or Apple could just use the reserved resource flags bit for that purpose (bit 0; see IM I-111.) Nobody's got it set now, so this would work correctly. On the other hand, a clean but incompatible way to do this would be to provide a new trap that temporarily turns off memory protection, or a version of BlockMove that ignores memory protection. Notice that the application socket listener only needs to write into code space once. This could easily be accomplished using these traps, albeit breaking existing code in the process. Apple's usually pretty good about compatibility, since computers get sold by their software base, so I expect they will probably use some variant on the "read-only resource", rather than requiring calls to new traps. So why don't older OS's like UNIX have to do this? Typically, they use absolute globals rather than globals relative to an offset, because they had some form of MMU built in from the start. If the Mac used this approach, then the issue would be irrelevant -- the socket listener would just stash it at global location 0x2500 or something. The OS is also statically linked -- the system maintainer has to relink the system whenever something is added, barring special hacks for run-time drivers that have been made in some UNIXes this decade. If Apple had done this to globals, they could never have expanded the system heap, nor provided Switcher or MultiFinder, on their existing machines. With register-relative globals, relocatability does not require an MMU. Good design decision for a low-end computer. Semi-related PS: John Gilmore wrote to inform me that non-executed data *can* find its way into the instruction cache because of prefetch. However, since the cache is only consulted during instruction fetch, not data fetch, there's still not a problem with PC-relative data. The instruction cache may have an invalid copy, but the processor won't look there unless it's executing that location. -- Tim Maroney, Consultant, Eclectic Software, sun!hoptoad!tim "Mere opinion without supporting argument is no more than the American Bandstand school of literary evaluation." -- Tom Maddox