home *** CD-ROM | disk | FTP | other *** search
/ OS/2 Shareware BBS: 10 Tools / 10-Tools.zip / snip9707.zip / MMODELS.FAQ < prev    next >
Text File  |  1997-07-05  |  6KB  |  140 lines
  1. +++Date last modified: 05-Jul-1997
  2.  
  3. ---------
  4. QUESTION:
  5. ---------
  6.  
  7.   I haven't been able to find anything that explains the memory models to my
  8. satisfaction.
  9.  
  10. -------
  11. ANSWER:
  12. -------
  13.  
  14.   It's pretty simple. 80x86 CPUs (in real, as opposed to protected or flat,
  15. mode) form 32-bit segmented addresses of the form ssss:oooo, where ssss is
  16. the 16-bit segment address and oooo is the 16-bit offset address. The "real"
  17. address is (16 * ssss) + oooo, so the actual range is limited to only 20 bits
  18. of significance.
  19.  
  20.   Given this fact, the code still has to access data and program memory. It
  21. has to access program memory in order to call other functions, perform
  22. conditional branches, etc. It also obviously has to access the data stored in
  23. memory.
  24.  
  25.   To facilitate memory access, the 80x86 CPUs provide segment registers, the
  26. principle ones being the CS and DS registers which hold the segment values of
  27. the Code Segment and Data Segment respectively.
  28.  
  29.   If your code or data are small enough to each fit within 64K, your program
  30. can become more efficient by simply setting the segment registers once and
  31. then forgetting them for the rest of the program's execution. Internally,
  32. whenever your programs needs data, it only specifies a 16-bit offset and the
  33. segment is provided by the DS register. Similarly, when you need to call
  34. another function, you only need to provide a 16-bit offset address and its
  35. segment is provided by the CS register.
  36.  
  37.   If either your code or your data outgrow the bounds of a single 64K
  38. segment, your program is then forced to access them with a full 32-bit
  39. ssss:oooo address. A further complication is if any of your data objects
  40. overflow a 64K segment. In such a case, you have to readjust your DS register
  41. every time you access such a data object based on where within the object you
  42. need to access.
  43.    
  44.   This is where memory models come in.
  45.  
  46. Tiny:           Code and Data both fit within the same 64K segment.
  47. Small:          Code and Data each fit within their own 64K segments.
  48. Compact:        Code fits in a 64K segment but Data doesn't.
  49. Medium:         Data fits in a 64K segment but Code doesn't.
  50. Large:          Neither Code nor Data will fit in a 64K segment.
  51. Huge:           Same as large, but individual objects may be over 64K.
  52.  
  53. (Note: Symantec/Zortech C++ breaks several of the above rules; 1) its Tiny
  54. model works just like Small model, 2) Huge model isn't suported, 3)
  55. additional features are supported as additional memory models - V model for
  56. smart overlays, X model for 32-bit extended DOS applications, R model for
  57. 16-bit extended DOS apps, etc.)
  58.  
  59.  
  60. ---------
  61. QUESTION:
  62. ---------
  63.  
  64.   How do memory models relate to near and far pointers? What's the
  65. difference? And what are the various _fmem???() and _fstr???() functions used
  66. for?
  67.  
  68. -------
  69. ANSWER:
  70. -------
  71.  
  72.   It's simple once you understand the concept of segment registers. A near
  73. pointer is simply a pointer that doesn't require a segment to be specified. A
  74. far pointer includes both a segment and offset.
  75.  
  76.   Relating this to the previous question, in Small and Tiny models, all
  77. pointers are near pointers. In Large and Huge models, all pointers are far
  78. pointers. In Compact model, function (code segment) pointers are near
  79. pointers and data pointers are far pointers. In Medium model, function (code
  80. segment) pointers are far pointers and data pointers are near pointers.
  81.  
  82.   Sometimes, however, you may need to use a far pointer in a memory model
  83. that otherwise uses near pointers. Some examples would be:
  84.  
  85. 1.  Your program is written in Tiny, Small, or Medium model, yet you want to
  86.     access the PC's video memory which requires specifying the video RAM
  87.     segment to use. You would have to specify the video RAM address using a
  88.     far pointer. Since standard library funtions assume that all pointers
  89.     conform to the current memory model, functions such as memcpy() will not
  90.     work. What's needed in this example would be a memcpy() work-alike that
  91.     uses explicit far pointers - in other words, you need to use _fmemcpy().
  92.     Note that in Compact, Large, or Huge memory models, such functions
  93.     already expect far pointers and so the use of the _fstr???() and
  94.     _fmem???() functions is unnecessary, although benign.
  95.  
  96. 2.  You're writing an interrupt service routine (ISR). All ISR's specify a
  97.     far function pointer. This is why you'll always see them specified in
  98.     portable code in a manner similar to this:
  99.  
  100. extern void (_interrupt _far *oldint9)(void);
  101.  
  102.  
  103. ---------
  104. QUESTION:
  105. ---------
  106.  
  107.   I always have used the tiny memory model, and when I use libraries I use
  108. the small memory model because that's as small as these particular libraries
  109. support.
  110.  
  111. -------
  112. ANSWER:
  113. -------
  114.  
  115.   The difference between Tiny and Small models is in the startup code - the
  116. libraries for each are identical since each assumes that CS and DS will be
  117. set once and for all by the startup code.
  118.  
  119.  
  120. ---------
  121. QUESTION:
  122. ---------
  123.  
  124.   What I want to know is how big does my program have to be before I would
  125. start using a larger memory model?  So far small has been more than adequate
  126. even though I consider some of my programs quite large. Although maybe not
  127. nearly as large as I think.
  128.  
  129. -------
  130. ANSWER:
  131. -------
  132.  
  133.   Maybe not. :-) You'll know when 1) you begin to get linker errors about
  134. segment overflows, 2) you get runtime errors when memory allocation functions
  135. begin failing.
  136.  
  137.   For folks needing to port code from other systems, Large or Huge are the
  138. ticket since they make no assumptions about addressing. Using Large or Huge
  139. model is always safe, but will obviously pay a run-time performance penalty.
  140.