Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!zaphod.mps.ohio-state.edu!mips!pacbell.com!tandem!zorch!xanthian From: xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) Newsgroups: comp.sys.amiga.tech Subject: Re: Files larger than available memory. Message-ID: <1990Oct9.061755.15112@zorch.SF-Bay.ORG> Date: 9 Oct 90 06:17:55 GMT References: <1990Oct7.032409.22928@zorch.SF-Bay.ORG> Organization: SF-Bay Public-Access Unix Lines: 47 lron@easy.HIAM (Dwight Hubbard) writes: > xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) writes: >> lron@easy.HIAM (Dwight Hubbard) writes: >[previous junk removed] [ditto] > Are we talking about software VM (which in my opinion is a waste of > time) or editing files larger than physical memory (a very nice > ability to have) adding VM just to edit files larger than memory is a > waste.[...] The basic principles for editing a file larger than > physical memory are quite different than writing a software VM system > that would have to worry whether or not the system is going to crash > if this particluar chunk of code gets swaped out. I think we agree on the right thing to do, but maybe not on how to do it. I'm not really interested in virtual memory for code, just for data. Truely huge pieces of code that overwhelm the hardware need to be overlaid anyway; the intelligence that can be added by a careful overlay scheme will always allow it to beat software code VM. Another poster has suggested, and I wish to promote the idea, that we should have a library (or handler, I'm not clear on the implications of one against the other) that captures the best available design for software data VM, so that this facility is easily available to programmers otherwise not capable of developing it, or with other work to do than redeveloping the wheel. As a checklist for what this facility should provide, an editor is a pretty good worst case, particularly one, like emacs, that is capable of opening multiple windows in multiple files simultaneously, and in multiple instances of the editor running at once. You can't just work in blocks, since the addition of text in any of the windows will change the byte boundaries of all the blocks, and scrolling multiple, modified windows at once in the same file (a facility of some multiple windows editors) is going to keep any design hopping to keep up. I guess what I want to say is that this is such a complex task that it needs to be done well once, and made generally available, rather than done as a compromise of the available time to devote to each product. It doesn't have to do "magic" (capture every pointer use and resolve it to currently in-RMA data); just provide a way to get and confirm handles on data, with the necessary paging in and out, and shifting of bytes within blocks, done as needed. Kent, the man from xanth.