home *** CD-ROM | disk | FTP | other *** search
/ ftp.whtech.com / ftp.whtech.com.tar / ftp.whtech.com / Geneve / 9640news / CAT24 / MMRY9640.ARK < prev    next >
Text File  |  2006-10-19  |  14KB  |  405 lines
  1. ?
  2.  
  3. THE FOLLOWING DOCUMENT (C) Copyright 1988, Paul Charlton, ALL RIGHTS RESERVED
  4.  
  5. ================================================================================
  6. = memory management:
  7. ================================================================================
  8.  
  9. definitions:
  10.  
  11. page: 8k bytes of memory, addressed by the 13 least significant address bits
  12.  
  13. execution page: these are numbered 0 to 7, indexed solely by the
  14.                 3 most significant bits of the cpu's address
  15.  
  16. physical page: these are numbered from 0 to 255
  17.  
  18. function of the mapper: to translate an execution page into a physical page
  19.  
  20. example:
  21.  
  22.        EXECUTION ADDRESS:            eee iiiii iiiiiiii    64 Kbyte range
  23.                                     /        |
  24.                                     v        |
  25.                                  mapper      |
  26.                                     |        |
  27.                                     v        v
  28.        PHYSICAL ADDRESS:      p pppp ppp iiiii iiiiiiii     2 Mbyte range
  29.  
  30. "eee"      is the execution page
  31. "pppppppp" is the physical page
  32.  
  33. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
  34.  
  35. in our case:
  36.  
  37. local page = virtual page
  38. virtual addressing: a method of allowing a task to access more memory than
  39.                     is directly accessible through the address bits
  40.                     of the CPU. allowing a task to own more physical pages
  41.                     than the 8 execution pages which are directly accessible
  42.                     through the mapper
  43.  
  44. in the mapping of MDOS, the execution pages for a task are a subset of the
  45. virtual pages belonging to the task.
  46.  
  47. for each task, MDOS maintains a list of physical pages which can be used
  48. by the task.  If the pages in this list are numbered, beginning with 0, the
  49. number assigned to each position in the list is the same as the virtual
  50. page number within the task.  The list is allowed to have holes it, which
  51. correspond to no physical page.
  52.  
  53. An example of the virtual page list maintained by MDOS for a task
  54. with 128k of memory:
  55.  
  56. physical page numbers:
  57. >3f >3e >3d >b8 >b8 >b8 >b8 >3c >3b >3a >39 >38 >37 >36 >35 >34
  58.  
  59.  
  60. virtual (local) page numbers:
  61.  0   1   2   3   4   5   6   7   8   9   10  11  12  13  14  15
  62.  
  63.             <--- HOLE ---->  (physical page >b8 does not correspond
  64.                               to any device which can be located in the
  65.                               PE BOX )
  66.  
  67. the virtual address is:
  68.  
  69.        >2000 * (virtual page number) + ( index into page <13 bits> )
  70.  
  71. note: the virtual page list is limited to 256 bytes in length. therefore,
  72.       no task may have more than 2 Mbyte of virtual memory
  73.  
  74. since this task has a hole containing 4 pages, it really only uses 96k
  75. of physical memory, even though it has 128k of virtual memory.
  76.  
  77. *** this example is the basis of the examples which follow ***
  78.  
  79. memory mangement opcodes:
  80.  
  81. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
  82.  
  83. #0     this returns the number of unassigned physical pages in the system
  84.  
  85. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
  86.  
  87. #1     this routines allows you to fill holes in your virtual
  88.        page list, it will also create a new hole if the first page
  89.        you are allocating has a higher virtual page number than
  90.        any which have been previously assigned.
  91.  
  92.        in the above example, if this routine were passed the arguments:
  93.        r1=2                   # of pages to get
  94.        r2=4                   Virtual page #
  95.        r3=don't care
  96.  
  97.        then the routine would take unassigned physical pages
  98.        (if available) and assign them to virtual pages #4 & #5
  99.        creating a virtual page map like:
  100.  
  101. physical page numbers:
  102. >3f >3e >3d >b8 >33 >32 >b8 >3c >3b >3a >39 >38 >37 >36 >35 >34
  103.  
  104. virtual (local) page numbers:
  105.  0   1   2   3   4   5   6   7   8   9   10  11  12  13  14  15
  106.              |           |
  107.           <hole>      <hole>
  108.  
  109.        the routine could create a new hole if you gave it arguments like:
  110.  
  111.        r1=1
  112.        r2=17
  113.        r3=don't care
  114.  
  115. results:
  116.  
  117. physical page numbers:
  118. >3f >3e >3d >b8 >b8 >b8 >b8 >3c >3b >3a >39 >38 >37 >36 >35 >34 >b8 >33
  119.  
  120. virtual (local) page numbers:
  121.  0   1   2   3   4   5   6   7   8   9   10  11  12  13  14  15  16  17
  122.                                                                  |
  123.           <---- hole ------>                                  <hole>
  124.  
  125. notice that this routine only _fills_ holes, it does not assign
  126. a new physical page to a virtual page which is already assigned
  127.  
  128. example:
  129.  
  130.        r1=5
  131.        r2=1
  132.        r3=don't care
  133.  
  134. results:
  135.  
  136. physical page numbers:
  137. >3f >3e >3d >33 >32 >31 >b8 >3c >3b >3a >39 >38 >37 >36 >35 >34
  138.  
  139. virtual (local) page numbers:
  140.  0   1   2   3   4   5   6   7   8   9   10  11  12  13  14  15
  141.      <--- 5 pages --->   |
  142.      <had><new pages ><hole>
  143.  
  144. notice that the arguments asked for 5 pages, but only 3 were actually
  145. assigned, since two of the target pages had already been assigned
  146.  
  147. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
  148.  
  149. #2     this routine releases pages which have been assigned to the
  150.        virtual address space of a task, thus creating holes in the list
  151.        it also ensures that there is no hole at the end of the list which
  152.        is not followed by an assigned page
  153.        note: you can not release page #0 (it isn't really owned by the task,
  154.              it belongs to MDOS and is also the "header" page for the task)
  155.  
  156.        arguments:
  157.        r1=9
  158.        r2=2
  159.  
  160. results:
  161.  
  162. physical page numbers:
  163. >3f >3e >b8 >b8 >b8 >b8 >b8 >b8 >b8 >b8 >b8 >38 >37 >36 >35 >34
  164.  
  165. virtual (local) page numbers:
  166.  0   1   2   3   4   5   6   7   8   9   10  11  12  13  14  15
  167.  
  168. note that some of the pages released were already unassigned, this is
  169. quite ok...
  170.  
  171.        arguments:
  172.        r1=10
  173.        r2=12
  174.  
  175. physical page numbers:
  176. >3f >3e >3d >b8 >b8 >b8 >b8 >3c >3b >3a >39 >38
  177.  
  178. virtual (local) page numbers:
  179.  0   1   2   3   4   5   6   7   8   9   10  11
  180.  
  181. the list was truncated, since all of the pages at the tail of the list
  182. were unassigned. Also note that we really told it to release
  183. pages 12 to 21, but we only had pages up to 15 to begin with...this is
  184. ok.
  185.  
  186.        arguments:
  187.        r1=12
  188.        r2=2
  189.  
  190. physical page numbers:
  191. >3f >3e >b8 >b8 >b8 >b8 >b8 >b8 >b8 >b8 >b8 >b8 >b8 >b8 >35 >34
  192.  
  193. virtual (local) page numbers:
  194.  0   1   2   3   4   5   6   7   8   9   10  11  12  13  14  15
  195.         <--- giant hole ------------------------------>
  196.  
  197. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
  198.  
  199. #3     map a virtual page into the execution (cpu visible) address space
  200.  
  201.        arguments:
  202.        r1=virtual page number (index into list of physical pages)
  203.        r2=execution page number (index into the mapper)
  204.  
  205. physical page numbers:
  206. >3f >3e >3d >b8 >b8 >b8 >b8 >3c >3b >3a >39 >38 >37 >36 >35 >34
  207.  
  208. virtual (local) page numbers:
  209.  0   1   2   3   4   5   6   7   8   9   10  11  12  13  14  15
  210.  
  211. mapper:
  212.  
  213. >3f >b8 >b8 >b8 >b8 >b8 >b8 >b8
  214.  
  215. example arguments:
  216.  
  217.        r1=14
  218.        r2=2
  219.  
  220. result---new contents of mapper:
  221.  
  222. >3f >b8 >35 >b8 >b8 >b8 >b8 >b8
  223.          |
  224.        virtual page # 14 is now located at >4000 (cpu address)
  225.  
  226.        another way to see this is to say that data at a virtual address of
  227.        >0001_c000 is addressable at >4000
  228.  
  229. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
  230.  
  231. #4     return a list of virtual pages
  232.  
  233.        r1= execution address at which to place the list
  234.        r2= length reserved for list
  235.  
  236.        you'll get an error code if the list is longer than the reserved area
  237.  
  238. returns (  *R2 ), physical pages numbers:
  239.  
  240. >3f >3e >3d >b8 >b8 >b8 >b8 >3c >3b >3a >39 >38 >37 >36 >35 >34
  241.  
  242.  
  243.        getting such a list is useful if your application does
  244.        _lots_ of paging around to get at the data it needs to use.
  245.        it is quite useful if your application also needs to use
  246.        pointers longer than 16 bits to maintain some complex data
  247.        structure, if you are maintaining 32 bit pointers, here is
  248.        how to get at the data addressed by the pointer:
  249.  
  250.        assume: r1,r2 = 32 bit pointer, @paglst are bytes from opcode #4
  251.  
  252.        movb r2,r1             ok, since only low 5 bits of r1 are used
  253.        andi r1,>e01f          keep 8 bits, zap the others
  254.        src  r1,13             rotate them to make an index into the page list
  255.        andi r2,>1fff          mask off the high three bits, they're now
  256. *                             in R1 ...
  257. *
  258.        movb @paglst(r1),@mapper+4            put it at >8000
  259.        movb @paglst+1(r1),@mapper+5          put next page at >a000
  260. *
  261. * it is not necessary to place two pages into the mapper if you
  262. * know for certain that the record accessed by the pointer does not
  263. * cross page boundaries, the above code is just a method of playing it
  264. * safe
  265. *
  266.        mov  @>8000+field_offset(r2),r3
  267. *
  268. * this of course assumes that there is some record addressed by the
  269. * initial pointer, and that the record contains fields of some
  270. * data structure.  fields are easy to set up with a DORG statement
  271. * for each record type in use by an application
  272. *
  273.  
  274. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
  275.  
  276. #5     declare shared pages
  277.  
  278.        any task may declare a subset of its virtual address space to be
  279.        "shared"
  280.  
  281.        each set of shared pages is given a "type" so that other applications
  282.        can later assign a certain "type" of shared pages into their
  283.        virtual address spage without knowlege of which physical pages
  284.        belong to a "shared" group
  285.  
  286.        it is recommended that "types" be assigned by the distributor of MDOS,
  287.        so that incompatible applications do not try to use the same "type"
  288.        if you decide to use a "type" please correspond with the distributor
  289.        of MDOS to coordinate your development efforts with others.
  290.  
  291.        a "shared" type may only be declared once, and always resides in a group
  292.        of consecutive virtual pages.  If all applications using a "shared"
  293.        group of pages release those pages, the "type" may be redeclared
  294.  
  295.        (MDOS keeps a count of the number of applications using a shared group,
  296.         and if the count ever becomes zero, the type is made free for re-use)
  297.  
  298. *** it is not possible to declare page 0 to be part of a shared group
  299. *** page 0 is _always_ private, since it contains the information
  300. *** which MDOS uses to distinguish between tasks.
  301.  
  302.        arguments:
  303.        r1=5 number of pages to be shared in this "type" ( 40 Kbytes)
  304.        r2=8 beginning virtual page number
  305.        r3=1 type
  306.  
  307. results:
  308.  
  309. physical page numbers:
  310. >3f >3e >3d >b8 >b8 >b8 >b8 >3c >3b >3a >39 >38 >37 >36 >35 >34
  311.  
  312. virtual (local) page numbers:
  313.  0   1   2   3   4   5   6   7   8   9   10  11  12  13  14  15
  314.                                  <-- shared pages ->
  315.                                  <-- type #1      ->
  316.  
  317. let us call the above page list "task #1", for the next few examples
  318.  
  319. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
  320.  
  321. #7     get "shared" pages     (we'll come back to opcode #6 later)
  322.  
  323.        1) the "type" must have be declared by a previous call to #5
  324.           by another task
  325.        2) if shared type has 5 pages, there must be a hole of at least
  326.           5 pages in the virtual page list for the shared type to map into
  327.           it is not possible to overlay shared and non-shared pages, nor
  328.           is it possible to overlap different "types" of shared pages
  329.  
  330. task #2, initially 24k
  331.  
  332. vp:  1   2   3   4   5   6   7   8   9
  333. pp: >20 >21 >22 >b8 >b8 >b8 >b8 >b8 >23
  334.  
  335.        task #2 calls opcode #7
  336.  
  337.        arguments:
  338.        r1=1
  339.        r2=3
  340.  
  341. results, task #2
  342.  
  343. vp:  1   2   3   4   5   6   7   8   9
  344. pp: >20 >21 >22 >3b >3a >39 >38 >37 >23
  345.  
  346.                <-- shared pages -->
  347.  
  348.        note that arguments of: r1=1, r2=4 would generate an error,
  349.        since page #9 has already been assigned
  350.  
  351.        also note that it is ok to have the shared group at
  352.  
  353.        >1 0000 in task #1, but at
  354.        >0 6000 in task #2
  355.  
  356.        also note that physical pages >37 to >3b can now be accessed
  357.        by both tasks.
  358.  
  359. also: a task may use more than one "shared type" simultaneously
  360.  
  361.        shared pages can be a good way to communicate between tasks,
  362.        it is also a good way to reduce memory usage for
  363.        an application which is used by more than one user at a time,
  364.        since you could "share" the object code of the application
  365.        between the users, and have more memory available for
  366.        each users' data.
  367.  
  368. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
  369.  
  370. #6     release shared pages
  371.  
  372.        only the "type" argument is needed, since MDOS keeps track of
  373.        the number of pages in each "type", and its location within the
  374.        virtual address space of the tasks which are using the "type"
  375.  
  376. if task #2 were to call opcode #6 with
  377.        r1=1
  378.  
  379. the following would result:
  380.  
  381. vp:  1   2   3   4   5   6   7   8   9
  382. pp: >20 >21 >22 >b8 >b8 >b8 >b8 >b8 >23
  383.                 <- the shared pages are no longer here ->
  384.  
  385. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
  386.  
  387. #8     get size of shared group
  388.  
  389.        if any task were to call this, they can obtain the number of pages
  390.        used by each active type
  391.  
  392. example:    task #3
  393.  
  394.        argument:
  395.        r1=1
  396.  
  397. return:
  398.        r0=0                   (assuming task #1, above, still had shared pages)
  399.        r1=5                   size of shared type #1 in above example
  400.  
  401.  
  402. Download complete.  Turn off Capture File.
  403.  
  404.  
  405.