Path: utzoo!attcan!uunet!intercon!amanda@intercon.UUCP From: amanda@intercon.UUCP (Amanda Walker) Newsgroups: comp.sys.mac.programmer Subject: Re: Re: System 7.0 Q & A -- memory protection (none) Message-ID: <18-May-89.120607@192.41.214.2> Date: 18 May 89 15:56:39 GMT References: <7350@hoptoad.uucp> <1838@internal.Apple.COM> <7320@hoptoad.uucp> <1906@internal.Apple.COM> Sender: news@intercon.UUCP Reply-To: amanda@intercon.UUCP (Amanda Walker) Organization: InterCon Systems Corporation, Sterling, VA Lines: 40 Tim, I'm beginning to wonder what axe you have to grind; you seem to be shooting from the hip more often than usual these days... In article <7350@hoptoad.uucp>, tim@hoptoad.uucp (Tim Maroney) writes: > The so-called large address space of 14 megabytes imposed by the > unclean ROM, you mean? So processes can't even grow, and you can have > a grand total of seven processes each sitting in its own dinky > two-megabyte address space? Sheesh. This is sounding sillier and > sillier. OK. I'm looking at the document titled, "Macintosh System Software Release 7.0 Virtual Memory Preliminary Developer Note." It was part of the System 7.0 binder collection that was given out at the Developer Conference. Nothing said about a discontigous virtual address space, two-megabyte limits, or anything else. The only limitation mentioned is that on a system using 24 bit addressing, such as a Mac II, you can have a maximum of 14 megabytes, minus one for each occupied slot. Not bad for a backward-compatible system. Between your posting and a previous one about an "8 megabyte" limit, I wonder if you understand virtual memory and the Mac II architecture. Wake up and pay attention: The current ROMs, while not 32-bit clean, *are* position-independent. They don't have to be mapped in at their (unmapped) physical address. The same is true of the I/O space on NuBus cards. There's *nothing* to prevent Apple from mapping the ROMs and occupied slots as high in the 16-megabyte space allowed by 24-bit addressing as they will go, leaving the rest to act as RAM space. All existing drivers, ROMs, etc. still work fine, since nothing is based on absloute physical addresses. Sure seems like a simple, useful way to do it between now and the time that the ROMs (and all those applications) can handle a 32-bit clean environment... -- Amanda Walker InterCon Systems Corporation -- Usenet: where people who should know better prove that they don't.