dlt@csuna.UUCP (Dave Thompson) (01/12/89)
On the front page of this week's MacWeek (10 January 1989) there is an article entitled: "Virtual memory ends RAM jam." Connectix Corporation has come out with a package containing a PMMU and an INIT for $695 that creates an 8mb swapfile on disk, far cheaper that an 8mb DRAM upgrade. The article states that there is "some" performance degradation on 1mb RAM machines but performs adequately on 2mb machines and with no noticeable degradation on 4mb machines. Sounds great!! My question is: are there any beta testers of this software out there on the net who would be willing to attest to the quality of this product? Comments? -- Dave Thompson uucp: dlt@csuna.csun.edu Computer Center Cal State University, Northridge phone: (818) 885-2790 18111 Nordhoff Street, Northridge, CA 91330
hodas@eniac.seas.upenn.edu (Josh Hodas) (01/13/89)
In article <1542@csuna.UUCP> dlt@csuna.UUCP (Dave Thompson) writes: >On the front page of this week's MacWeek (10 January 1989) there is an >article entitled: "Virtual memory ends RAM jam." Connectix Corporation >has come out with a package containing a PMMU and an INIT for $695 that >creates an 8mb swapfile on disk, far cheaper that an 8mb DRAM upgrade. >The article states that there is "some" performance degradation on 1mb >RAM machines but performs adequately on 2mb machines and with no noticeable >degradation on 4mb machines. Sounds great!! > >My question is: are there any beta testers of this software out there on >the net who would be willing to attest to the quality of this product? >Comments? >-- >Dave Thompson uucp: dlt@csuna.csun.edu Sounds real great to me too. I am expecting literature from them next week. I'll tell you what little I learned from their sales rep on the phone yesterday, though. Price for init + 68851 MMU = $695 Price for init alone = $295 The product is supposed to ship next week at macworld, there will be show special prices of ~600 and ~250 respectively. The init will supposedly work with any off the shelf 68851 so it would probably be worth shopping around. (This leads to the question of does anyone know sources for the 68851? I called all the places from the back of BYTE yesterday, ie JDR, Jameco, Microprocessors Unlimited, and they all acted like they had never heard of it.) Also, a special version of the init designed to work with the 030 (in the IIX and SE/30) will be forthcoming soon. The rep was unable to answer questions like "What's the page size? What's the page replacement algorithm?" Any additional info would be greatly appreciated. Josh ------------------------- Josh Hodas (hodas@eniac.seas.upenn.edu) 4223 Pine Street Philadelphia, PA 19104 (215) 222-7112 (home) (215) 898-5423 (school office)
bmug@garnet.berkeley.edu (BMUG) (01/14/89)
In article <1542@csuna.UUCP> dlt@csuna.UUCP (Dave Thompson) writes: >On the front page of this week's MacWeek (10 January 1989) there is an >article entitled: "Virtual memory ends RAM jam." Connectix Corporation >has come out with a package containing a PMMU and an INIT for $695 that >creates an 8mb swapfile on disk, far cheaper that an 8mb DRAM upgrade. >The article states that there is "some" performance degradation on 1mb >RAM machines but performs adequately on 2mb machines and with no noticeable >degradation on 4mb machines. Sounds great!! > >My question is: are there any beta testers of this software out there on >the net who would be willing to attest to the quality of this product? >Comments? Connectix came to BMUG's weekly meeting last night and demoed the product. Comments: The demo was done on a 2 meg Mac II. The program (i.e., INIT), ran without breaking, with the demonstrator running Excel, PageMaker, ImageStudio, Word, LightSpeedC 2.0, HyperCard, and about four other applications. The hard disk, btw, was Apple's stock 40 meg Quantum, with a 29 mS access time. Response was very good, even on memory (disk) intensive tasks such as ImageStudio manipulations and the like. MultiFinder context switching was smooth. The only programs to date which will not work well with the Connectix setup are debuggers like TMON and MacsBug (nobody thought to ask about disassemblers like MacNosy). The faster the hard disk, the better performance will be. Performance on a 1 meg machine will be sluggish during certain operations. Performance on a 4 or 5 meg machine will be apparently unaffected (the last three statements made by the demoer). The company is planning to produce an INIT package for accellerated SE's with boards able to accommodate a PMMU (Levco and a few others) or with a 68030. These are in beta test right now. Availability of the Mac II product is now. Connectix will have a booth at MacWorld Expo (Brooks Hall, perhaps Moscone also) with the following show prices: INIT and PMMU: $595; INIT only (for Mac IIx and other 030 configurations): $249 (usually $295). Seemed like a neat thing. We're trying to get one to beat on before recommending it. Definitely worth a look, though. John Heckendorn /\ BMUG ARPA: bmug@garnet.berkeley.EDU A__A 1442A Walnut St., #62 BITNET: bmug@ucbgarnet |()| Berkeley, CA 94709 | | (415) 549-2684 | |
bmug@garnet.berkeley.edu (BMUG) (01/14/89)
In article <7124@netnews.upenn.edu> hodas@eniac.seas.upenn.edu.UUCP (Josh Hodas) writes: >In article <1542@csuna.UUCP> dlt@csuna.UUCP (Dave Thompson) writes: >>On the front page of this week's MacWeek (10 January 1989) there is an >>article entitled: "Virtual memory ends RAM jam." >Sounds real great to me too. I am expecting literature from them next >week. (stuff deleted) >The rep was unable to answer questions like "What's the page size? What's the >page replacement algorithm?" > >Any additional info would be greatly appreciated. > >Josh According to the BMUG meeting demoer, the page size is 2k. Nobody asked about the algorithm (I'm not sure he would have answered that one!). John Heckendorn /\ BMUG ARPA: bmug@garnet.berkeley.EDU A__A 1442A Walnut St., #62 BITNET: bmug@ucbgarnet |()| Berkeley, CA 94709 | | (415) 549-2684 | |
bmug@garnet.berkeley.edu (BMUG) (01/14/89)
In an earlier message I reported the show price for the Connectix
PMMU/INIT combo at MacWorld Expo as $595; I *should* have typed $495.
Many apologies for the error.
John Heckendorn
/\
BMUG ARPA: bmug@garnet.berkeley.EDU A__A
1442A Walnut St., #62 BITNET: bmug@ucbgarnet |()|
Berkeley, CA 94709 | |
(415) 549-2684 | |jgc@uoregon.uoregon.edu (James Gerald Campbell) (01/14/89)
The availability of a virtual memory init package for the mac II and the soon availability of the same for the 68030 based IIx and SE/30 makes me wonder: Is it possible to upgrade a Mac II to a pseudo IIx by dropping in a 68030 in place of the processor? If so, I'd rather do this then add a PMU. Is there a wait state saving? Whats the current price for 030s? I wasn't planning on doing anything until I needed/could afford/liked A/UX or the Mac OS really supported multitasking, but this init, if proved out in the trenches, could change my mind real fast. jc
seghers@hpccc.HP.COM (David Seghers) (01/14/89)
>/ hpccc:comp.sys.mac / dlt@csuna.UUCP (Dave Thompson) / 12:42 pm Jan 11, 1989 / > >On the front page of this week's MacWeek (10 January 1989) there is an >article entitled: "Virtual memory ends RAM jam." Connectix Corporation > has come out with a package containing a PMMU and an INIT for $695 that >creates an 8mb swapfile on disk, far cheaper that an 8mb DRAM upgrade. >The article states that there is "some" performance degradation on 1mb >RAM machines but performs adequately on 2mb machines and with no noticeable >degradation on 4mb machines. Sounds great!! >My question is: are there any beta testers of this software out there on >the net who would be willing to attest to the quality of this product? >Comments? I'm not a beta site for this product, but I did see a demo of it at SMUG (Stanford). It was very impressive, and showed no performance degradation on a 2 Meg Mac II with 8 meg of programs loaded (graphics, spreadsheet, C plus debugger, etc.). I called the company the next day to find out when I could get mine, and was told that it will be ready for MacWorld, and the price will be $495 as a show special. This includes a PMMU which is required for thisprogram to run. I was also told that the reason there was no performance penalty on the 2 meg machine was that each individual program would fit into the 2 megs when swapped in, and this is why the 1 meg machine might be slower depending on the programs being run. Cautions: Needs 8 meg contiguous free disk space on the boot disk, and if you already have 8 meg DRAM, it won't give you another 8. There was a typo in the MacWeek article on the phone #. It is 415-324-0727. I have no connection with the company that sells this, David Seghers (Waiting for DRAM prices to fall! Ha! Now I won't care!) Generic disclaimer, my opinions are my own, keep my employer out of it.! (including "I HATE vi"!!!! Hold your flames for better issues)
kaufman@polya.Stanford.EDU (Marc T. Kaufman) (01/14/89)
In article <1542@csuna.UUCP> dlt@csuna.UUCP (Dave Thompson) writes: >My question is: are there any beta testers of this software out there on >the net who would be willing to attest to the quality of this product? >Comments? I would specifically be interested in what happens to SCSI transfers that cross page boundaries, when one of the pages is not in memory. There are some SCSI devices that cannot abort and retry easily. What does this INIT do? Marc Kaufman (kaufman@polya.stanford.edu)
ts@cup.portal.com (Tim W Smith) (01/15/89)
What happens if I get a page fault in the middle of a SCSI operation? For instance, suppose my code does this: SCSIGet(); SCSISelect( id ); SCSICmd( cmdBuf, 6 ); and the memory pointed to by cmdBuf has been paged out. How does the init manage to read that page off the disk? Tim Smith
name@PORTIA.STANFORD.EDU (tony cooper) (01/15/89)
According to my calculations 2^24 is 16 Megabytes. So why is the virtual memory INIT limited to just 8Mb? Then the next question is: Why stop at 2^24? Why can't the virtual memory be as big as the disk? If no program uses more than 2Mb then you could have 40 such programs on the disk with each program being swapped into the 4MB of ram whenever it is it's turn to get some CPU time. If it were possible to have, say, 16 MB of virtual memory on the Mac I guess most people would have trouble using it all. What would you do with all that much memory? I guess you could use it as a RAM disk!?! Tony Cooper
jmunkki@kampi.hut.fi (Juri Munkki) (01/16/89)
In article <13566@cup.portal.com> ts@cup.portal.com (Tim W Smith) writes: >What happens if I get a page fault in the middle of a SCSI operation? >For instance, suppose my code does this: > > SCSIGet(); > SCSISelect( id ); > SCSICmd( cmdBuf, 6 ); > >and the memory pointed to by cmdBuf has been paged out. How does the >init manage to read that page off the disk? Good question! I haven't seen the product and all I know about is what has been written about it on Comp.sys.mac, but I guess they could have patched FSRead and FSWrite so that the calls make sure that they are operating on available pages. A really long read or write would then have to be split into several smaller segments so that 1 or 2 megabytes of RAM would be enough. Along the same lines: how do they know which parts of the system heap they can swap out. I thought about writing a virtual memory INIT, but I couldn't think of a way to let it swap out parts of the system heap. We're definitely going to try the product at our university. I might even get one myself, if I can't get a NeXT this year. They should sell it for $150...I think they'd make a lot more money that way... _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._ | Juri Munkki jmunkki@hut.fi jmunkki@fingate.bitnet I Want Ne | | Helsinki University of Technology Computing Centre My Own XT | ~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~
ephraim@think.COM (Ephraim Vishniac) (01/16/89)
In article <8901151644.AA17944@Portia.stanford.edu> name@PORTIA.STANFORD.EDU (tony cooper) writes: >According to my calculations 2^24 is 16 Megabytes. So why is the virtual >memory INIT limited to just 8Mb? Then the next question is: Why stop at >2^24? Why can't the virtual memory be as big as the disk? Mostly because the Mac OS isn't 32-bit yet. In the 24-bit addressing version, it needs space for things other than user memory. The ROM is mapped at 8M, and above the ROM is I/O space and slot space. Ephraim Vishniac ephraim@think.com Thinking Machines Corporation / 245 First Street / Cambridge, MA 02142-1214 "Arlo Guthrie, it seems, has found what he was looking for: God, and the Macintosh." (Boston Globe)
jfm@ruddles.sprl.umich.edu.engin.umich.edu (John F. Mansfield) (01/17/89)
In article <1542@csuna.UUCP> dlt@csuna.UUCP (Dave Thompson) writes: >has come out with a package containing a PMMU and an INIT for $695 that >creates an 8mb swapfile on disk, far cheaper that an 8mb DRAM upgrade. It sounds great, but it also said that if you have the PMMU, which I have, then the software alone would be something like $250. Also in the article it said the init was something like 10K, isnt this rather a lot for such a small piece of software or am I missing something? John Mansfield North Campus Electron Microbeam Analysis Laboratory 2455 Hayward, Ann Arbor, Michigan 48109-2143. 313-936-3352 Internet: jfm@ruddles.sprl.umich.edu or john_mansfield.um.cc.umich.edu
shane@chablis.cc.umich.edu (Shane Looker) (01/17/89)
In article <8901151644.AA17944@Portia.stanford.edu> name@PORTIA.STANFORD.EDU (tony cooper) writes: > What would you do with all that >much memory? I guess you could use it as a RAM disk!?! I sure hope you are joking about this... Shane Looker | Looker@um.cc.umich.edu America works less, when you say "Union Yes!"
bob@accuvax.nwu.edu (Bob Hablutzel) (01/18/89)
Talking about the virtual memory INIT: > It sounds great, but it also said that if you have the PMMU, which I > have, then the software alone would be something like $250. Also in > the article it said the init was something like 10K, isnt this rather > a lot for such a small piece of software or am I missing something? Am _I_ missing something? 10K _IS_ a small piece of software. Especially if you consider that this code has to patch the memory manager, io system, and god knows what. Personally, I'm rather impressed - in this day of obese programming, I expected the INIT to be much larger. Bob Hablutzel Wildwood Software BOB@NUACC.ACNS.NWU.EDU Disclaimer: Opinions come free. Facts cost you.
sbb@esquire.UUCP (Stephen B. Baumgarten) (01/18/89)
In article <40e7a0d1.a590@mag.engin.umich.edu> jfm@ruddles.sprl.umich.edu.UUCP (John F. Mansfield) writes: >In article <1542@csuna.UUCP> dlt@csuna.UUCP (Dave Thompson) writes: >>has come out with a package containing a PMMU and an INIT for $695 that >>creates an 8mb swapfile on disk, far cheaper that an 8mb DRAM upgrade. > >It sounds great, but it also said that if you have the PMMU, which I >have, then the software alone would be something like $250. Also in >the article it said the init was something like 10K, isnt this rather >a lot for such a small piece of software or am I missing something? Would you be happier if it were 100K rather than 10K? :-) But seriously, assuming it works well, think about how much memory you could buy for that same $250. That's why they can charge what they're charging (a price which does not seem at all out of line to me). -- Steve Baumgarten | "New York... when civilization falls apart, Davis Polk & Wardwell | remember, we were way ahead of you." cmcl2!esquire!sbb | esquire!sbb@cmcl2.nyu.edu | - David Letterman
fjo@ttrdf.UUCP (Frank Owen ) (01/19/89)
in article <40e7a0d1.a590@mag.engin.umich.edu>, jfm@ruddles.sprl.umich.edu.engin.umich.edu (John F. Mansfield) says: > >>creates an 8mb swapfile on disk, far cheaper that an 8mb DRAM upgrade. > > It sounds great, but it also said that if you have the PMMU, which I > have, then the software alone would be something like $250. Also in > the article it said the init was something like 10K, isnt this rather > a lot for such a small piece of software or am I missing something? Yes, this does seem like a lot for such a small piece of software, but I think their objective is to make as much money as possible before their product becomes obsolete. This WILL occur in the not too distant future due to one or more of the following: a) REAL memory will eventually come down in price, making the swapper less desirable from a cost (and speed) standpoint. b) Someone else will figure out how to write a similiar INIT. (I think there are probably some listeners on the net capable of doing this.) And will provide it as shareware/freeware/cheaperware c) Apple may build this into a future version of system software. If the RAM prices do not go down, they will probably be forced to do this to accomodate increasingly memory-hungry system enhancements. As of right now, the only other product that gives the same functionality is RAM upgrades, so that's what they will compete against from a price standpoint. -- Frank Owen (fjo@ttrdf) 312-982-2182 AT&T Bell Laboratories 5555 Touhy Ave., Skokie, IL 60077 PATH: ...!att!ttrdf!fjo
jimc@vax.3Com.Com (Jim Christy) (01/19/89)
In article <8901151644.AA17944@Portia.stanford.edu>, name@PORTIA.STANFORD.EDU (tony cooper) writes: > According to my calculations 2^24 is 16 Megabytes. So why is the virtual > memory INIT limited to just 8Mb? Then the next question is: Why stop at > 2^24? Why can't the virtual memory be as big as the disk? If no program > uses more than 2Mb then you could have 40 such programs on the disk with > each program being swapped into the 4MB of ram whenever it is it's turn > to get some CPU time. ... > > Tony Cooper The ROM on a Mac II is mapped in starting at 8 Meg. Jim Christy 3Com Corp.
wb1j+@andrew.cmu.edu (William M. Bumgarner) (01/19/89)
Even when real memory comes down in price, there will still be a place for the virtual memory INIT>.. System 7.0 should be able to deal with 32bit addressing, meaning that the effective limit of memory becomes 1 gigabyte. Currently the INIT can only deal with up to an 8Meg swap space because of the system software, not itself. It will be a long time before the price of 4 meg SIMMS (for a 16 meg Mac II) will be as inexpensive as simply setting the INIT to a 16 meg swap space... and if you need more memory, clear a little more space on the hard drive. One might think that no one will ever need that much memory-- wrong. Have you ever tried to process a good-sized image in ImageStudio@300 DPI? w/undo enabled? can take way more than 8 megs-- an 8X10 image at 300 DPI w/undo takes a little over 14 megabytes of RAM. Using the virtual memory INIT not only gives you the ability to attempt processing images that large, but to be able to do it under MultiFinder! Other applications need loads of memory, or at least would be happy w/a lot more than allocated to them; HyperCard, FullWrite Professional, MacNet.... b.bum wb1j+@andrew.mcu.edu
bob@accuvax.nwu.edu (Bob Hablutzel) (01/19/89)
>> It sounds great, but it also said that if you have the PMMU, which I >> have, then the software alone would be something like $250. Also in >> the article it said the init was something like 10K, isnt this rather >> a lot for such a small piece of software or am I missing something? >Am _I_ missing something? 10K _IS_ a small piece of software. >Especially if you consider that this code has to patch the memory manager, >io system, and god knows what. Personally, I'm rather impressed - in this >day of obese programming, I expected the INIT to be much larger. Good Morning! Yup, I'm missing something. Sorry about this, people - someday I'll get around to taking that course in English I've been looking at... Bob Hablutzel Wildwood Software BOB@NUACC.ACNS.NWU.EDU Disclaimer: Opinions come free. Facts cost you. ----------
blm@cxsea.UUCP (Brian Matthews) (01/20/89)
Shane Looker (shane@chablis.cc.umich.edu) writes: |In article <8901151644.AA17944@Portia.stanford.edu> name@PORTIA.STANFORD.EDU (tony cooper) writes: |> What would you do with all that |>much memory? I guess you could use it as a RAM disk!?! | |I sure hope you are joking about this... I don't know if Tony was joking or not, but I would certainly consider using the extra memory as a RAM disk. In fact, I have a paged RAM disk on my Unix machine. Why is this not as silly as it sounds? Because an application usually doesn't use all of your physical memory, you generally only use a small part of the RAM disk (within a small amount of time, you may fill the thing up eventually), and even if the application is using all of physical memory (or more), it isn't touching all of those pages very often. Say that you have 2 Meg of physical memory, and the application you happen to be running only uses 1.5 Meg. Then you've got .5 Meg for the RAM disk to be paged into, even if the application is touching all of its memory. Maybe 1 Meg of the applications memory can be paged out. Unless you're dealing with some large files, chances are your data will fit in the 1.5 Meg, and run at RAM disk speed. If the application snarfs some more memory, the least recently used pages of the RAM disk will get paged out. In the worst case, when the application grows larger than physical memory, the RAM disk will work like a normal drive. But even in this case, the chances are pretty high that some pages owned by the application aren't being touched, and will get paged out for the RAM disk. Basically the RAM disk gives you a cache that uses whatever unused memory is available, and in the worst case acts like a normal disk drive. And consider that this worst case only happens when the application owns more memory than is available in physical memory, and is touching all of these pages fairly often. A paged RAM disk can be a smart way to go. -- Brian L. Matthews blm@cxsea.UUCP ...{mnetor,uw-beaver!ssc-vax}!cxsea!blm +1 206 251 6811 Computer X Inc. - a division of Motorola New Enterprises
jasons@tekred.TEK.COM (Jason Scheck) (01/20/89)
Is there any real good reason that Multifinder couldn't swap on a application by application basis? I mean, when the Set Aside option of the new beta multifinder were chosen, why couldn't its entire application heap and process variables be written to disk, freeing up the memory it used. This would work on any generation of macs. The only problem is, Apple is the only one with enough internal Multifinder information to do it (right?). I rarely (very rarely; I have 1 Mb) run anything in the background under multifinder. On the other hand, the ability to quickly switch applications could be nice. Jason Scheck jasons@tekred.CNA.TEK.COM
c60a-2ce@e260-2b.berkeley.edu (Mikey) (01/20/89)
Whoa! Can someone enlighten me about this? I missed any earlier relevant messages. Thanks. -------------------------------------------------------------------------- I'd appreciate it if you could reply via EMAIL. I'm not able to access the net that often. Thanks a lot!! c60a-2ce@web.berkeley.edu............................................Mikey *** Call Tanelorn III! (415) 540-1180. The Apple/Mac BBS of Berkeley. ***
gillies@p.cs.uiuc.edu (01/21/89)
Virtual memory is not the type of software some self-taught programmer
can knock off in a weekend with a couple of pots of coffee :-) In
fact, most self-taught programmers probably couldn't hack the problem
at all. Ask someone with a C.S. degree whether they think it would be
challenging to retrofit an operating system AND applications with
virtual memory. Ask them "When has it EVER been done before?"
Furthermore, nobody believed that VM could be implemented so quickly
on the macintosh, once there was a PMMU. Well, Connectix has done the
R & D necessary to solve the problem. They should be applauded. $295
is cheap when you think of the risk they took.
Don Gillies, Dept. of Computer Science, University of Illinois
1304 W. Springfield, Urbana, Ill 61801
ARPA: gillies@cs.uiuc.edu UUCP: {uunet,harvard}!uiucdcs!gilliespkahn@meridian.ads.com (Phil Kahn) (01/21/89)
In article <QXpKSoy00WA4A1dmZB@andrew.cmu.edu> wb1j+@andrew.cmu.edu (William M. Bumgarner) writes: >Even when real memory comes down in price, there will still be a place for >the virtual memory INIT>.. > >System 7.0 should be able to deal with 32bit addressing, meaning that the ^^^ ^^^^^^^^^^^^^^^^ Is this true!??? I'd like to hear where this came from, and comments by an APple person in the know. phil...
wb1j+@andrew.cmu.edu (William M. Bumgarner) (01/21/89)
The ability to be able to run more applications under MultiFinder is an excellent and needed ability of the Virtual Mem Init, but it isn't the main purpose. By using a virtual memory manager, it allows an application to run as if it had a lot more memory available then the physical RAM in the machine. This function causes the need for the PMMU. The possibility of swapping in/out partitions under MultiFinder would work well for applications that DON'T support backgrounding. With the whole partition out of RAM and on disk, every time the application does something in the background, the partition would have to be swapped in to memory (meaning a write of the current partition and a read of the one executing if everything won't fit in memory). The performance wouldn't be real stupendous... For something like HyperCard, it would be wonderful-- I would like to keep HyperCard open all the time (I have set up Dazzl's Organizer+ to replace all file/launching management, plus I keep all my assignments/due dates in the stacks with links to the associated word-processing stacks-- avoids the SFGetFile folder mazes or a cluttered desktop), but sometimes it is simply impossible because of memory constraints. Considering that Hypercard doesn't support backgrounding (it kind of does, but not reall), and I often don't go to the Hypercard partition for 3+ hours, it would be incredibly useful to free up that layer! How about another bit in multifinder that allows a move-partition-to-disk on suspend/resume events? Multifinder basically does what it does with BlockMoves, so why not drop the mem out on a hard drive? Apple? Is it possible or not? b.bum wb1j+@andrew.cmu.edu
mha@batcomputer.tn.cornell.edu (Mark H. Anbinder) (01/22/89)
In article <8901151644.AA17944@Portia.stanford.edu> name@PORTIA.STANFORD.EDU (tony cooper) writes: >... >If it were possible to have, say, 16 MB of virtual memory on the Mac I guess >most people would have trouble using it all. What would you do with all that >much memory? I guess you could use it as a RAM disk!?! > >Tony Cooper I can just imagine Steve Jobs and Steve Wozniak twelve years ago reading this through a time portal and thinking, "He means sixteen kilobytes, not sixteen megabytes, right?" Of course, they soon realized that a computer really DID need at least 16K. Soon they were selling 48K machines. Of course, the epitome of luxurious amounts of memory was with the 128K Apple //e (the standard model had 64K, I think). "They're putting *512K* in the new version of their computer? WHAT FOR?!" Enter the Fat Mac. And you're wondering what people could possibly put in 16 megabytes? :-) -- Mark H. Anbinder ** MHA@TCGould.tn.cornell.edu NG33 MVR Hall, Media Services Dept. ** THCY@CRNLVAX5.BITNET Cornell University H: (607) 257-7587 ******** Ithaca, NY 14853 W: (607) 255-1566 ******* Ego ipse custodies custudio
siegel@endor.harvard.edu (Rich Siegel) (01/23/89)
In article <76000334@p.cs.uiuc.edu> gillies@p.cs.uiuc.edu writes: > >Virtual memory is not the type of software some self-taught programmer >can knock off in a weekend with a couple of pots of coffee :-) In >fact, most self-taught programmers probably couldn't hack the problem >at all. And what other problems couldn't a self-taught programmer hack? :-| --Rich Rich Siegel Staff Software Developer THINK Technologies Division, Symantec Corp. Internet: siegel@endor.harvard.edu UUCP: ..harvard!endor!siegel Phone: (617) 275-4800 x305 Any opinions stated in this article do not necessarily reflect the views or policies of Symantec Corporation or its employees.
bcase@cup.portal.com (Brian bcase Case) (01/24/89)
>Furthermore, nobody believed that VM could be implemented so quickly >on the macintosh, once there was a PMMU. Well, Connectix has done the >R & D necessary to solve the problem. They should be applauded. $295 >is cheap when you think of the risk they took. [Hi Don!] Right, and it still hasn't been done. Connectix hasn't done real virtual memory: Mac applications must still be assigned and wired-down to places in the 8 MByte memory space. When they are paged out, they can only be paged back into the same place. The applications do not see their own 8MByte partition, they must still share. There is no protection. This might be virtual memory, but it certainly is not what is meant when the term is used to describe the facility in other contexts. Note, I am not knocking what they have done, rather I applaud it! But they have not done what will be done when the MacOS of the future allows pre-emptive multitasking, private, large address spaces, protection, interprocess communication, etc. etc. etc. They have done a brilliant thing! But it is no substitute for the years of work needed. As far as paying so much for so few bytes of software, the fewer the better since the connectix software itself is also stealing from that 8 MByte "virtual" space....
holland@m2.csc.ti.com (Fred Hollander) (01/24/89)
In article <2598@cxsea.UUCP> blm@cxsea.UUCP (Brian Matthews) writes: >Shane Looker (shane@chablis.cc.umich.edu) writes: >|In article <8901151644.AA17944@Portia.stanford.edu> name@PORTIA.STANFORD.EDU (tony cooper) writes: >|> What would you do with all that >|>much memory? I guess you could use it as a RAM disk!?! >| >|I sure hope you are joking about this... > >I don't know if Tony was joking or not, but I would certainly consider >using the extra memory as a RAM disk. In fact, I have a paged RAM disk >on my Unix machine. > >out. In the worst case, when the application grows larger than physical >memory, the RAM disk will work like a normal drive. But even in this I don't think so. First the pages of the RAM disk (now on disk) need to be paged into RAM, then another RAM access for the application to get the data. It would certainly be faster to read directly off the disk. I also don't believe that this worst case situtation will be that rare. You seem to be thinking of a single application in memory. We're not talking about paging entire applications, but, small blocks (1-2K). So, the RAM disk will be paged out just as often as any other block that is not used frequently/recently. But seriously, with all the system patches, there's a lot of unused ROM code. How about paging that to disk :). Fred Hollander Computer Science Center Texas Instruments, Inc. holland%ti-csl@csnet-rela The above statements are my own and not representative of Texas Instruments.
barmar@think.COM (Barry Margolin) (01/25/89)
In article <13871@cup.portal.com> bcase@cup.portal.com (Brian bcase Case) writes: [Someone else writes:] >>Furthermore, nobody believed that VM could be implemented so quickly >>on the macintosh >Right, and it still hasn't been done. Connectix hasn't done real >virtual memory: Mac applications must still be assigned and wired-down >to places in the 8 MByte memory space. Virtual memory is any scheme that allows applications to be fooled into thinking that there is more memory than there actually is. Individual applications don't have to have independent address spaces for the memory to be virtual. My Symbolics lisp machine provides preemptive multitasking, but all applications (and the OS) still live in the same 256-megabyte address space. And on Multics, each login session is a single process, with all applications that the user runs during that session in that address space. It's possible to have time sharing, protected applications, inter-process communication, etc. without virtual memory, too. For example, a system that simply provides each application with the normal physical address space and swaps all of physical memory in and out is possible (and very similar to the first computer I used, a PDP-8 running TSS-8). The point is that these are independent aspects of an OS. There are advantages and disadvantages to each. I think you are also misusing the term "wired-down". In operating systems, this term is used to mean locking a particular portion of virtual memory to a portion of physical memory, and preventing it from being swapped out. It's generally used for things like I/O buffers in DMA systems, where the device must be told a physical address in which to store or retrieve its data, and it wouldn't be nice if the VM mechanism were to replace it when the device isn't looking. You're using it to mean that an application is loaded into a particular place in VM and it stays there, which is true on every system I'm aware of (on systems where each application gets its own address space, every application is normally "wired-down" to the same location (e.g. 0) in its own space). Barry Margolin Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar
grg@berlin.acss.umn.edu (George Gonzalez) (01/25/89)
I don't understand all the amazement about this virtual memory INIT. It would be amazing if it did full-blown virtual memory, with variable sized segments, rings of protection, gates, access levels, et. al. But if it is to be transparent to the current Mac OS and applications, it can't be that fancy. It sounds like it's just doing *paging* of fixed sized blocks between RAM and the disk. This is less than trivial, but perhaps only 20% of the complexity of full virtual memory. Not all that difficult to do. It also does not sound that computer-sciency. It probably involved more trial-and-error experimenting than pure computer science. I'm sure there was a lot of cut-and-try, as the Mac OS's internals are not too well documented. As others have mentioned, there are some tricky areas if a page fault occurs during a disk operation! They probably attacked the problem by patching the Mac I/O system, not by referring to Knuth.
friedman@porthos.rutgers.edu (Gadi ) (01/26/89)
Can this Virtual Memory Init run on a 68030 mac (IIx,SEx)
without the PMMU? If so, it would be much more accessable.
(Cheaper..)
Gadi
--
uucp: {ames,att,harvard,ucbvax,iuvax}!rutgers!aramis.rutgers.edu!friedman
arpa: FRIEDMAN@ARAMIS.RUTGERS.EDUephraim@think.COM (Ephraim Vishniac) (01/26/89)
In article <Jan.25.11.10.25.1989.14904@porthos.rutgers.edu> friedman@porthos.rutgers.edu (Gadi ) writes: >Can this Virtual Memory Init run on a 68030 mac (IIx,SEx) >without the PMMU? If so, it would be much more accessable. >(Cheaper..) I got the sales literature from Connectix yesterday; we're expecting the actual product next week. In the fine print, their letter says, "The software-only version currently being released is not designed for use on the Mac IIx." They plainly intend on doing a 68030 version, but it's not soup yet. BTW, show prices were $495 for software + 68851 or $259 for software only. Too late now! Regular prices (after 1/22/89) are $695 and $295. Hints about future releases: "Can VIRTUAL use the extra memory installed on an expansion board? Not in this release..." "I have 2 hard drives. Can I move VIRTUAL off my boot drive? Not with this release, however allowing virtual memory storage on volumes other than the start-up drive is one of the planned upgrades." Disclaimer: I have no connection with these folks other than as a customer eagerly awaiting shipment. Ephraim Vishniac ephraim@think.com Thinking Machines Corporation / 245 First Street / Cambridge, MA 02142-1214 "Arlo Guthrie, it seems, has found what he was looking for: God, and the Macintosh." (Boston Globe)
holland@m2.csc.ti.com (Fred Hollander) (01/27/89)
In article <288@berlin.acss.umn.edu> grg@berlin.acss.umn.edu (George Gonzalez) writes: > >I don't understand all the amazement about this virtual memory INIT. >It would be amazing if it did full-blown virtual memory, with variable >sized segments, rings of protection, gates, access levels, et. al. The interest is due to the price difference between the INIT ($695) and an 8Meg memory upgrade ($2400). Although, it may not be publishable in a journal of computer science, it is worthy achievement for the Macintosh. >But if it is to be transparent to the current Mac OS and applications, it >can't be that fancy. It sounds like it's just doing *paging* of fixed >sized blocks between RAM and the disk. This is less than trivial, but >perhaps only 20% of the complexity of full virtual memory. Not all that >difficult to do. Sounds like you could be their first competitor. And since it will be so easy, you could sell it for say $50 (software only) and release it in say a month - you'll certainly put Virtual out of business. But, don't make the same mistake they made but fitting into a 10K INIT. Make yours at least 150K so that it will be more credible. >It also does not sound that computer-sciency. It probably involved more >trial-and-error experimenting than pure computer science. I'm sure there >was a lot of cut-and-try, as the Mac OS's internals are not too well >documented. As others have mentioned, there are some tricky areas if >a page fault occurs during a disk operation! They probably attacked the >problem by patching the Mac I/O system, not by referring to Knuth. Are you sure you're in the right newsgroup. This is comp.sys.mac. I agree that it's no breakthrough in computer science. Of course it's a patch. Does Knuth hack Macintosh!? I can see it now, The Art of Computer Programming, Vol 4, Macintosh Internals :) Fred Hollander Computer Science Center Texas Instruments, Inc. holland%ti-csl@csnet-rela The above statements are my own and not representative of Texas Instruments.
mo@prisma (01/27/89)
The notion that the Connetix gadget "ain't *really* virtual memory because they didn't solve the static allocation problem" is silly. OS/VS1 provided a 16 megabyte 370 running MFT, and the first versions of OS/VS2 provided a 16 megabyte machine running MVT. OS/MVS now provides each job with a separate address space, but that surely ain't required. So, don't mistake dynamic relocation in logical addresses with dynamic relocation in physical addresses. Yes, Virgil, it really is virtual memory. They, quite wisely, didn't try to fix everything else at the same time..... -Mike
bcase@cup.portal.com (Brian bcase Case) (01/27/89)
>>>Furthermore, nobody believed that VM could be implemented so quickly >>>on the macintosh >>Right, and it still hasn't been done. Connectix hasn't done real >>virtual memory: Mac applications must still be assigned and wired-down >>to places in the 8 MByte memory space. > >Virtual memory is any scheme that allows applications to be fooled >into thinking that there is more memory than there actually is. Ok, ok. I was wrong. I'll agree: what has been done by Connectix is, by the simplest definition, virtual memory.
kehr@felix.UUCP (Shirley Kehr) (01/27/89)
In article <Jan.25.11.10.25.1989.14904@porthos.rutgers.edu> friedman@porthos.rutgers.edu (Gadi ) writes:
<Can this Virtual Memory Init run on a 68030 mac (IIx,SEx)
<without the PMMU? If so, it would be much more accessable.
<(Cheaper..)
The original MacWeek article says "The software alone will be available for
$259 for users who already have a PMMU." However, I called the company and
mentioned IIx and SE/30. They said the init needs to be changed to work
with the 030 machines. Their number is (415) 324-0727 if you want to
check on availability. If you do, please post the information.
Shirley Kehr