Path: utzoo!attcan!utgpu!news-server.csri.toronto.edu!mailrus!uunet!know!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: <1990Sep30.201119.14610@zorch.SF-Bay.ORG> Date: 30 Sep 90 20:11:19 GMT References: <14646@cbmvax.commodore.com> <1089@ucsvc.ucs.unimelb.edu.au> Organization: SF-Bay Public-Access Unix Lines: 22 Lou's postings subsequent to his original question raised the question of a library to support software virtual memory. Back in the old days of core memory, software virtual memory was all there was available to evade the limits of dinky real memories, and was occasionally implemented for both code and data. As soon as hardware assist became available, however, software virtual memory was deprecated as "ungodly slow" in comparision to the hardware solution, and essentially abandoned. It's 1990, processors are faster, RAM is bigger, disks are faster, and the folks writing code are either smarter or taking lots of advantage of a better knowledge base. Just how bad would software virtual memory have to be today? We can already overlay code with our compilers, so it's probably okay to think about data virtual memory only, and only for data explicitly allocated there, which simplifies the task substantially. Have we lost track of a useful technique that could be ported to our desktop machines which are now much bigger than those old mainframes? Kent, the man from xanth.