home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / lang / c / 16857 < prev    next >
Encoding:
Internet Message Format  |  1992-11-19  |  1.4 KB
  1. Path: sparky!uunet!olivea!charnel!sifon!thunder.mcrcim.mcgill.edu!mouse
  2. From: mouse@thunder.mcrcim.mcgill.edu (der Mouse)
  3. Newsgroups: comp.lang.c
  4. Subject: Re: Virtual memory Management Systems
  5. Message-ID: <1992Nov20.101929.21132@thunder.mcrcim.mcgill.edu>
  6. Date: 20 Nov 92 10:19:29 GMT
  7. References: <1992Nov17.103746.20006@di.unipi.it> <1992Nov18.081123.29057@di.unipi.it>
  8. Organization: McGill Research Centre for Intelligent Machines
  9. Lines: 22
  10.  
  11. In article <1992Nov18.081123.29057@di.unipi.it>, ntranqu@caticsuf.cati.csufresno.edu (Nico Tranquilli) writes:
  12. > In article <1992Nov17.143327@gese.ge14.mdadv.gv.at> Petzi Schweda, sca@gese.ge14.mdadv.gv.at writes:
  13.  
  14. > Perhaps I should have asked : "What is the name of HARDWARE devices
  15. > which allocate virtual memory on disks whenever the internal memory
  16. > become full ?
  17.  
  18. This is (usually) done in OS software, not in hardware.  Typically, the
  19. OS will set up the MMU [memory management unit] so that all pages are
  20. valid, then when it wants to make room, it will write a page out to
  21. disk and reset the MMU so the page is invalid.  Upon next access to
  22. that page, the MMU will generate a trap to the OS, which does whatever
  23. is appropriate (typically reading the page back in, resetting the MMU,
  24. and resuming the interrupted process).
  25.  
  26. In short, someone else's answer - CPUs - is, while rather flippant,
  27. nonetheless basically correct.
  28.  
  29.                     der Mouse
  30.  
  31.                 mouse@larry.mcrcim.mcgill.edu
  32.