home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / sys / amiga / programm / 15967 < prev    next >
Encoding:
Internet Message Format  |  1992-11-17  |  5.1 KB
  1. Path: sparky!uunet!haven.umd.edu!purdue!ames!elroy.jpl.nasa.gov!usc!news.service.uci.edu!ucivax!ofa123!Aric.Caley
  2. From: Aric.Caley@ofa123.fidonet.org
  3. Newsgroups: comp.sys.amiga.programmer
  4. Subject: Re: physical memory prot
  5. X-Sender: newtout 0.02 Nov  5 1992
  6. Message-ID: <n0e9ft@ofa123.fidonet.org>
  7. Date: 15 Nov 92  11:15:04
  8. Lines: 89
  9.  
  10. > Organization: University of California; Santa Cruz
  11. > From: davids@cats.ucsc.edu (Dave Schreiber)
  12. > Message-ID: 1duvk4INN65q@darkstar.ucsc.edu
  13. > Newsgroups: comp.sys.amiga.programmer
  14. >
  15. > Who says you need an eight byte page size, i.e. why does every memory
  16. > allocation need to be treated as a separate page?  You could implement
  17. > something like this:
  18. > When a task starts, create two lists of memory:  memory allocated by the
  19. >  task and memory in the task's address space ("owned" by the task) but not
  20. >  allocated.
  21. > When the task wants to allocate a memory block of size n, do the following:
  22. >    1. Search the owned-but-not-allocated memory list for a block of size n.
  23. >    2. If no large enough block exists, allocate the necessary memory
  24. >       (rounded up to a multiple of the page size, of course) from the
  25. >       system heap, change its protection so that it is owned by the task,
  26. >       allocate the amount of memory required by the task, and put the
  27. >       remaining memory in the owned-but-not-allocated list.
  28. > When the task frees a block of memory, check to see if this free results
  29. >  in an entire page of memory being freed.  If so, remove that page from
  30. >  the owned-but-not-allocated list, change its protections back to "unowned,"
  31. >  and return it to the system heap.  Note that this can be done occasionally
  32. >  instead of on every FreeMem() if it turns out to be too expensive an
  33. >  operation to run frequently.
  34. >
  35. > Using this technique will let you keep the 8-byte minimum allocation size
  36. > yet work with large (>=4K on the '040) page sizes.
  37.  
  38. Sounds great.
  39.  
  40. > The real problem with memory protection on the Amiga is that it is
  41. > possible for one task to share its memory with another without explicitly
  42. > telling the OS that the shared memory is in fact shared.  This is a big
  43. > nono under a protected OS.  However, it is an exaggeration to say that
  44. > 99.9% of Amiga programs do this.  Out of the dozens or so I've written
  45. > (some PD, most for my own use), I doubt more than one or two share data
  46. > with other tasks (aside from those that have ARexx ports;  I sure hope
  47. > MinRexx doesn't break under a protected OS :-)).  Also, I suspect that most
  48. > of those programs that do share data with other tasks share data with
  49. > child tasks that are created by the original program using CreateTask(),
  50. > CreateNewProc();  I'd bet that if, under a version of AmigaDOS with
  51. > protected memory, CreateTask() etc. created threads (i.e. tasks
  52. > that exist in the same address space with their creators, and thus which
  53. > can share their creators' data), a lot of compatibility issues could be
  54. > minimized.  This would require new system calls that the system program
  55. > loader could use to create new address spaces, but that wouldn't affect
  56. > user programs.
  57.  
  58. Well, how about two memory lists?  Each task has its own private, protected
  59. memory  list  (as  you  described), and then there would be "shared" memory
  60. list.  Memory that was intended to be passed around would be allocated from
  61. the  public memory list (or basicly, the way all memory is alloceted now!).
  62. Now, this would require simply using the right memory flags in AllocMem() -
  63. which  probably most applications do not.  So there's still a compatibility
  64. problem, even though it should be easily fixed by correcting the AllocMem's
  65. in your application and recompiling.
  66.  
  67. -so-
  68.  
  69. Why  not  have  a little controler program that the user runs.  This little
  70. program  would  allow  you choose memory protection by default (which would
  71. cause  most programs to break until they got fixed), or set it on a program
  72. by  program basis (you'd have, I suppose, a small database of program names
  73. and flags indicateing what level [if any] of MP could be done).
  74.  
  75. Furthermore,  you  could add a library of MP/VM and related functions - any
  76. application  accessing  it could tell the system directly that it supported
  77. MP/VM.
  78.  
  79. All the code in AmigaOS should be changed to support MP (everything - prefs
  80. editors,   workbench,   libraries,  etc).   Even  if  NO  applications  can
  81. immediately  use  MP,  at  least AmigaOS would!  And that would make things
  82. more stable.
  83.  
  84. Now  perhaps  I  am  completely  off  here...   but it seems like this is a
  85. reasonable  solution.   What don't I understand, if this idea is completely
  86. unfeasable?   Third parties have developed VM that uses a similar system to
  87. what  I described (from what I understand, I dont have an MMU to see how it
  88. works).
  89.  
  90. > Dave Schreiber  "Look.  Don't touch."  davids@cats.ucsc.edu (until 6/20/93)
  91.  
  92.  - Dances With Coyotes - World's slowest programer -Given that the universe-
  93.  --- AKA Dances V2.0, Coyote, Magnet, Major, etc ---is infinate, and god is-
  94.  --- Former Net-Lurker - YES, an AMIGA godammit! ---all powerful, would you-
  95.  - If it says SEX and FREE BEER I'll mess with it! -like some toast?       -
  96.  
  97.  
  98. --- Maximus 2.00
  99.