home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / sys / atari / st / 18567 < prev    next >
Encoding:
Internet Message Format  |  1992-12-17  |  2.9 KB
  1. Path: sparky!uunet!pipex!warwick!uknet!yorkohm!minster!mjl-b
  2. From: mjl-b@minster.york.ac.uk
  3. Newsgroups: comp.sys.atari.st
  4. Subject: Re: Virtual Memory on MultiTos
  5. Message-ID: <724600898.9501@minster.york.ac.uk>
  6. Date: 17 Dec 92 14:01:39 GMT
  7. References: <1992Dec16.043917.1193@cc.umontreal.ca>
  8. Reply-To: mjl-b@minster.york.ac.uk (Mathew Lodge)
  9. Organization: Department of Computer Science, University of York, England
  10. Lines: 48
  11.  
  12. In article <1992Dec16.043917.1193@cc.umontreal.ca> kosmatoo@JSP.UMontreal.CA (Kosmatos Odisseas) writes:
  13. >I was wondering whether there are any plans on supporting virtual memory
  14. >with MultiTos. Virtual Memory seems like a great feature. Example, with
  15. >v.m. one will never have to worry about their terminal program's capture
  16. >buffer getting full. Now, I have a feeling MultiTos does not yet support
  17. >v.m. because nobody seems to have mentioned it as one of its features.
  18.  
  19. There is no VM at the moment. However, the ideas on memory ownership in the
  20. current version of MiNT are what is required for a basic VM implementation.
  21. I would guess that it's just a matter of time before it's added, but I guess
  22. that Eric has other priorities right now!
  23.  
  24. >(At our university, we have tons of 16Mhz,68020-based workstations for the
  25. > first-to-third year students that use virtual memory THROUGH A NETWORK,
  26. > [meaning no local hard disk, a virual memory page swap has to be done 
  27. >  through a busy network] and run quite well. You NEVER (ever) have to
  28. > worry about running out of memory.
  29.  
  30. Not quite true -- you can run out of swap space on the server, and there is
  31. a limit to the total amount of memory a process/user can have. And swapping
  32. over the network is still much slower than swapping onto a local hard disk.
  33.  
  34. >------- topic 2 -------
  35. >
  36. >Another topic I was wondering about was whether MiNT (and thus MultiTos)
  37. >does the following: When a program is loaded, say program X. If the program
  38. >is loaded again in another window / by another user / by a background shell
  39. >script, will the operating system notice that it is already loaded and just
  40. >use the copy in memory (but having a local stack and program pointers)
  41. >or will it load the program all over again (thus wasting precious primary
  42. >memory)?
  43.  
  44. You mean sharable code segments? A good idea, but there are problems with
  45. programs that use self-modifying code. I hope that these are few and far
  46. between (because they'll cause problems with processor caches as well).
  47. Llamamtron is an example of such a program -- the sample replay routine is
  48. self modifying :-(
  49.  
  50. Perhaps there could be a bit set in the program header to indicate that its
  51. code can be shared... Eric?
  52.  
  53. >"''''" Odisseas Kosmatos "'"'' kosmatoo@jsp.umontreal.ca "'"''" My Idol. Please
  54.  
  55. Mat
  56.  
  57. | Mathew Lodge                      | "What think you, my lord, of... Love?" |
  58. | mjl-b@minster.york.ac.uk          | "You mean rumpy-pumpy?"                |
  59. | Langwith College, Uni of York, UK |  -- Blackadder II                      |
  60.