Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!samsung!dali!ogicse!decwrl!shelby!neon!Kermit.Stanford.EDU!philip
From: philip@Kermit.Stanford.EDU (Philip Machanick)
Newsgroups: comp.sys.mac.system
Subject: Re: There are 2 different 32-bit modes, folks!  (Was Re: System 7...)
Message-ID: <1990May28.183229.21148@Neon.Stanford.EDU>
Date: 28 May 90 18:32:29 GMT
References: <7285@jarthur.Claremont.EDU> <7258@jarthur.Claremont.EDU> <9390003@hp-ptp.HP.COM>
Sender: news@Neon.Stanford.EDU (USENET News System)
Reply-To: philip@pescadero.stanford.edu
Organization: Computer Science Department, Stanford University
Lines: 23

In article <7285@jarthur.Claremont.EDU>, mwilkins@jarthur.Claremont.EDU
(Mark Wilkins) writes:
>   The addressing space available to your programs, on a IIcx, therefore, is 
> 0x000000 to  0xBFFFFF.  0xC00000 to 0xFFFFFF is allocated to NuBus slots and
> ROM.  Yes, it's a hardware thing.  However, it MUST take up part of the
> virtual address space because user programs access that memory directly, and
> user programs have no means of bypassing the PMMU's memory mapping.  If you
> had 16 MB of virtual RAM, there would be no part of the 24-bit address space
> left which a program could use to get directly at video RAM, say, or the
> ROM.

Actually, the real problem as I see it is that the Mac OS clumps everything
into 1 address space - even if VM is in use. This is why there is a static
partitioning of the addesses between ROM, slots, applications etc. Also, if
you use VM, you do not escape from the MultiFinder partitioning scheme, in
which each application is given a fixed slice of the total address space.
A "real" VM operating system with a separate address space for each application
would get rid of these nasties, but the current OS is too tightly locked into
the notion of every application sharing its address space with the system
(QuickDraw globals, etc.) for an easy transition to such a VM system. 

Philip Machanick
philip@pescadero.stanford.edu