home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / sys / amiga / programm / 15747 < prev    next >
Encoding:
Internet Message Format  |  1992-11-12  |  1.8 KB
  1. Path: sparky!uunet!think.com!yale.edu!ira.uka.de!math.fu-berlin.de!uni-paderborn.de!chandler
  2. From: chandler@uni-paderborn.de (Martin Grote)
  3. Newsgroups: comp.sys.amiga.programmer
  4. Subject: Re: physical memory protection with MMU
  5. Date: 12 Nov 1992 17:28:37 GMT
  6. Organization: Uni-GH Paderborn, Germany
  7. Lines: 36
  8. Distribution: world
  9. Message-ID: <1du485INNdbn@uni-paderborn.de>
  10. References: <1992Oct26.162400@uni-paderborn.de> <heinz.04a3@edohwg.adsp.sub.org> <1992Nov10.154421.18725@cbis.ece.drexel.edu> <1dtp0rINN9jk@uni-paderborn.de>
  11. NNTP-Posting-Host: greco.uni-paderborn.de
  12. Keywords: mmu, memory, task
  13.  
  14. tron@uni-paderborn.de (Matthias Scheler) writes:
  15. >> [stuff emphasizing memory protection deleted]
  16. > It would be nice, but you would loose 99.9999% of the software.
  17.  
  18. So here we are at the beginning again. My original suggestion was:
  19. > As the memory protection would have to be optional anyway because not all
  20. > machines have an MMU, make it optional for all users!
  21. > [...]
  22. > Just open a window asking the user what to do, e.g.
  23. > 'Kill task - Ignore forever - Ignore'.
  24. > [...]
  25.  
  26. > The advantages would be that all new software would definitely have to avoid
  27. > MMU hits and the user could still use old buggy software if she really needs
  28. > to ...
  29.  
  30.  
  31. Besides, you write:
  32. > you would loose 99.9999% of the software
  33.                   ^^^^^^^^
  34. Hmm. Ever went to a statistics lesson here? :^>
  35. So let's say 90%. But as I wrote before:
  36.  
  37. > The advantages would be that all new software would definitely have to avoid
  38. > MMU hits and the user could still use old buggy software if she really needs
  39. > to ...
  40.  
  41. However, to focus on my original intention again:
  42. - is it impossible / too difficult?
  43. - any disadvantages (does it have slow down the system)?
  44. - if not, how about implementing it?
  45.  
  46. --
  47. Martin Grote
  48. chandler@uni-paderborn.de
  49.  
  50.