mwilkins@jarthur.Claremont.EDU (Mark Wilkins) (05/25/90)
I will try to clear up the raging confusion about 32-bit mode and Virtual Memory in System 7. All Macs have the 24-bit memory manager. What this means is that when your program requests memory, it is pointed to by an address for which only the bottom 24 bits are valid. The Mac IIci and the Mac IIfx ALSO have a 32-bit memory manager. With this memory manager, all 32 bits are valid for every address, and the stuff that was kept in the other 8 are pushed off elsewhere. This memory manager is ONLY available on a IIci or IIfx. The ONLY upgrade path which will get you there is the one which takes you to those machines. This upgrade is NOT free. (Bear with me, Ted, I'm getting to you.) However, all Mac II class machines as well as the SE/30 have what is known as 32-bit addressing mode. This means that if the processor is accessing an address, it TRIES to use all 32 bits. On any machine other than the IIci or the IIfx, this can (generally) only be used to access the NuBus slots. If you turn this mode on and send the processor a 24-bit address, the machine crashes. Virtual memory, by the way, doesn't need 32-bit addressing of any kind to work. That's why it works great on Mac IIs and SE/30s. On with the circus... In an earlier article ted@cs.utexas.edu (Ted Woodward) challenges: >Just like the 24 bit mem managers in ROM in the older machines, this is fixed >in software. Or I guess that really wasn't sys 7 I played with on that SE/30. >Or AUX (1.0, but still 32bit) on that IIx... A/UX doesn't use the ROM memory manager at all. It has its own memory manager, designed just like that of the very UNIX system you're probably using. However, this type of software solution will not be built into System 7. As for the SE/30 question, see below. >My boss (service manager for the Texas Union Microcenter here at UT Austin, >which has just won some Apple service award or somesuch) has told me that >early Mac II's have ROMS that aren't compatable, and there is a FREE (I think >he said free) ROM upgrade. Early Mac IIs don't like 32-bit mode, new ones can tolerate it. That doesn't mean that they have a 32-bit memory manager. True, that fix is free. It is, however, separate from the PMMU wiring problem. You can have the newer ROMs and your PMMU still won't work because some of the connectors are just hanging there. >And yes, that SE/30 mentioned earlier was using VM, for a total of 11MB >(not enough space on the disk partitioned for more...sigh) Note that Virtual Memory can get you up to 16 megabytes WITHOUT 32-bit cleanliness of any sort. (What's 2^24? Anyone? Anyone?) Note that each NuBus card takes up 1 megabyte of the bottom 16 in the address space, and that the ROM takes up another. I guess my point is that needless upgrading can be a waste of money. There is a lot of misinformation about this stuff. So before Mr. Woodward sells you his IIx, please learn the facts and decide for yourself whether another hardware platform will better suit your needs. :-) -- Mark
mwilkins@jarthur.Claremont.EDU (Mark Wilkins) (05/25/90)
In article <7258@jarthur.Claremont.EDU> mwilkins@jarthur.Claremont.EDU (Mark Wilkins) writes: > Early Mac IIs don't like 32-bit mode, new ones can tolerate it. That > doesn't mean that they have a 32-bit memory manager. True, that fix is > free. Just to make clear what I said here, FIXED Mac IIs can only tolerate 32-bit mode when you don't make system calls other than StripAddress. -- Mark Wilkins
nick@lfcs.ed.ac.uk (Nick Rothwell) (05/25/90)
In article <7258@jarthur.Claremont.EDU>, mwilkins@jarthur (Mark Wilkins) writes: > I will try to clear up the raging confusion about 32-bit mode and Virtual >Memory in System 7. And I think I understand it now, ta... > However, all Mac II class machines as well as the SE/30 have what is known >as 32-bit addressing mode. This means that if the processor is accessing an >address, it TRIES to use all 32 bits. So (correct me if I'm wrong) the only reason this isn't running all the time is that there is software around which uses the top byte for it's own ends. A "32-bit clean" program is one that doesn't care that addresses of things are 32 bit significant. Yes? I recall from Inside Mac way back when, that handles can have the top byte reserved (something to do with CDEF's?), so this isn't clean. I presume there's a tech note explaining what to do these days. I'm only an occasional Mac programmer, so I don't keep that up-to-date, but I'm in the process of selling my Mac+ and buying an SE/30, so I might need to know one day... >-- Mark Nick. -- Nick Rothwell, Laboratory for Foundations of Computer Science, Edinburgh. nick@lfcs.ed.ac.uk <Atlantic Ocean>!mcsun!ukc!lfcs!nick ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ Ich weiss jetzt was kein Engel weiss
davew@hp-ptp.HP.COM (Dave_Waller) (05/26/90)
mwilkins@jarthur.Claremont.EDU (Mark Wilkins) writes: > > Note that Virtual Memory can get you up to 16 megabytes WITHOUT 32-bit > cleanliness of any sort. (What's 2^24? Anyone? Anyone?) Note that > each NuBus card takes up 1 megabyte of the bottom 16 in the address > space, and that the ROM takes up another. Let me see if I have this straight -- My IIcx (purchased in March... I assume it has the latest ROMs available for the IIcx) uses a memory manager that has 24 bits of addressing. This is 16MB of address space. Does that mean that I can address 16MB of Virtual Memory on my 4MB system? But "no", you say, "each NuBus card takes up 1 megabyte of the bottom 16 in the address space, and that the ROM takes up another." What exactly does this mean? I interpret "bottom 1MB" to mean addresses 0x000000 - 0x0FFFFF... so is the only addressing space available on my Mac from 0x200000 to 0xFFFFFF = 14MB (I have one NuBus card)? Further, how should this affect *virtual* addressing anyway, that faults to pages in a backing store (i.e. swap area) on the disc? All of this sounds like hardware limitations to addressing _real_ memory to me, not limitations on virtual addressing. My IIcx has the same damn HARDWARE as the IIci in terms of the integrated PMMU in the '030. Why is it not possible for Apple to offer a ROM upgrade to the IIcx that supports Clean, full 32-bit Memory managment? I would appreciate a clear answer to this from someone that knows... Don't worry about getting too technical. Dave Waller \ The opinions expressed are solely my own, and in no way Hewlett-Packard Co. \ represent those of my employer (but we all know dave@hpdstma.ptp.hp.com | hplabs!hpdstma!dave \ they should!)
mwilkins@jarthur.Claremont.EDU (Mark Wilkins) (05/27/90)
In article <9390003@hp-ptp.HP.COM> davew@hp-ptp.HP.COM (Dave_Waller) writes: >mwilkins@jarthur.Claremont.EDU (Mark Wilkins) writes: >> >> Note that Virtual Memory can get you up to 16 megabytes WITHOUT 32-bit >> cleanliness of any sort. (What's 2^24? Anyone? Anyone?) Note that >> each NuBus card takes up 1 megabyte of the bottom 16 in the address >> space, and that the ROM takes up another. > >Let me see if I have this straight -- My IIcx (purchased in March... I >assume it has the latest ROMs available for the IIcx) uses a memory >manager that has 24 bits of addressing. This is 16MB of address space. >Does that mean that I can address 16MB of Virtual Memory on my 4MB >system? If I implied that the NuBus cards and ROM took up the bottom several megabytes of the address space, I wasn't clear enough. "each NuBus card takes up 1 megabyte of the bottom 16 in the address space, and that the ROM takes up another." That means that of the address space which can be accessed with 24-bit addressing, you lose 1 MB for each card and 1 for ROM. The addresses you lose are at the high end of the 16MB address space. Actually, under the current version of System 7, you lose 1MB for each SLOT, not each CARD. However, Connectix' Virtual 2.0 solves this problem and later versions of Apple's VM might also. 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. >My IIcx has the same damn HARDWARE as the IIci in terms of the >integrated PMMU in the '030. Why is it not possible for Apple to offer a >ROM upgrade to the IIcx that supports Clean, full 32-bit Memory >managment? I would appreciate a clear answer to this from someone that >knows... Don't worry about getting too technical. It sure is possible. Apple just hasn't chosen to. Quite possibly, they are working on it. However, if they were to announce such a thing, I would guess that they'd wait until System 7 was announced to do so, because under 6.0.5 there's no reason to have a 32-bit clean memory manager. In fact, they might even come up with a better, software solution. I'm not contending that such a thing can't be done, I'm just saying that it hasn't been announced and that there's no way to get the 32-bit memory manager using EXISTING UPGRADES unless you go to a IIci or IIfx. -- Mark Wilkins
philip@Kermit.Stanford.EDU (Philip Machanick) (05/29/90)
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