On Thursday, 31 December 1998,
     DENIS TONN wrote to IVAN TODOROSKI about Some weird addressing...

IT>>   Hey, what's all this 64 KB allocation stuff?!

 DT>  It's not 64K allocation, it's allocation units occuring on 64K
 DT> boundries.

  Aaahhhh... OK! This single sentence explained it for me! What was I
  thinking?! So DosAllocMem (in addition to setting up the page tables
  appropriately and returning a single offset in the 512MB descriptor)
  just creates an aditional set of descriptors in the LDT for every
  allocation, which just sit there unused until there is need to make
  them available to a 16 bit process which understands only 16:16
  addresses. Is this what "thunking" is?

  And does the word "thunk" has any actual meaning in English? I don't
  have the dictionary handy to check it out (it went with the fallen
  drive)

IT>>   I thought that was gone?

 DT>  It is. A 32 bit program uses a "flat" selector with a base of zero
 DT> and a limit of 512MB (448MB for Warp 3 GA).

IT>>    Do you get a single descritor with a 1000000 byte limit, or a bunch
IT>>    of small descriptors with 65536 limits?

 DT>  The 32 bit program uses 3 "flat" 32 bit selectors (CS,
DS, and ES),
 DT> all with a base of zero and a limit of 512MB. A 32 bit application can
 DT> ignore selectors. It is ONLY when it needs to pass an address to a
 DT> 16:16 piece of code that the tiling of the LDT comes into play...

  And here you've fixed another misconception of mine...

  When I was grinding through the Intel 386 reference, I saw descriptors
  (with their limits) as the most natural and ideal way to control
  memory access by different processes. If I were to design an OS, I
  would have probably had DosAllocMem create a brand new descriptor in
  the LDT of the calling process for each allocation and return a
  selector to it. This way, if a process hits an address outside the
  descriptor limit, the OS would be immediately notified via the
  exception handler, and if the allocation was less than 1MB I would
  have a byte granularity (I would know IMMEDIATELY when a process
  wanders outside the allocated memory, I would not have to wait for it
  to hit the next 4KB page boudary).

  But now I can see why this is the wrong way to go :( If the process
  were to alternately access the memory chunks from different
  allocations, it would cause a lot of reloading of selector registers.

  If I understood you correctly, you DON'T use descriptors to control
  memory access in OS/2. You just give three big (512MB limit)
  descriptors to every process, and the selectors in that 32-bit process
  DON'T change during its execution. It only uses OFFSETS to access the
  memory in that 512MB range.

  The question is, HOW do you stop the process from accessing the parts
  of that 512 megs that it hasn't allocated yet. The answer is, by
  cleverly managing the page mapping tables. You're doing it on a whole
  different level. DosAllocMem just returns an OFFSET into the already
  given 512 MB descriptor (created by the OS at the initialization of
  the process), and sets up the page tables and directories for the
  process in such a way that any attempt to access any other part of
  that 512MB descriptor would cause a page fault.

  Very clever, I must say. You lose some precision that way (invalid
  memory accesses can be detected only when they cross a 4KB boundary),
  but you save an awful lot of descriptors and greatly speed up memory
  access! I would have *never* thought of this...

  It is not the descriptors that control and restrict the memory access
  in a single process in OS/2, it is actually the page tables! You are
  using the page mapping mechanism to its fullest extent.



  Ummmm... does this make any sense to you?! :)


IT>>   What's going on inside there? :)

 DT>  OK.. As you suggest, and example might help.

 DT>  Lets say you have a 32 bit app that call DosAllocMem for 132K bytes.
 DT> Alloc returns an address to you of (say) 00050000h where you have 132K
  [...]

  Thanks for this thorough example. No amount of explanation can
  substitute a well thought out example!

 DT>   Selector 002F    Base 00050000 Limit FFFF \
 DT>   Selector 0037    Base 00060000 Limit FFFF   Maps 132K allocation
 DT>   Selector 003F    Base 00070000 Limit 0FFF /
 DT>   Selector 0047    Base 00080000 Limit FFFF \
 DT>   Selector 004F    Base 00090000 Limit FFFF   Maps 204K allocation
 DT>   Selector 0057    Base 000A0000 Limit FFFF
 DT>   Selector 005F    Base 000B0000 Limit 2FFF /
 DT>   Selector 0067    Base 000C0000 Limit 0FFF   Maps 4K allocation
 DT>   Selector 006F    Base 000D0000 Limit 0FFF   Maps 4K allocation

 DT>  Now, *IF* your application needed to convert one of the 32 bit
 DT> addreses to a 16:16 form, it can easily do so. Say that you wanted a
 DT> field at address 000B1234 to be updated by some 16:16 code (an old DLL
 DT> for example). You need to convert this 32 bit address into something
 DT> the 16:16 code can handle. Because of the tiling of the LDT, this is
 DT> very simple. Take the upper 16 bits of the 32 bit address and shift to
 DT> the left by 3 bits (times 8) and (since you are trying to convert this
 DT> into a ring 3 LDT selector) turn on the last 3 bits (plus 7). In this
 DT> example 000B*8+7=005F. That becomes our "selector" part
of the 16:16
 DT> address. The last 16 bits of the 32 bit address become the offset part
 DT> of the 16:16 address, thus 005F:1234 is the address we pass to the
 DT> 16:16 code to use. The LDT entry (and the page tables) prevents the
 DT> 16 bit code from accessing beyond the allocation unit (limit of 2FFF).

  I was wondering about that strange choice of LDT selectors
  (37,3F,47,4F etc) when I saw it in that first big message from you on
  this subject, but I finally see the light now... this double
  descriptor coverage scheme is simply ingenious!

  It is very sad indeed that those people making marketing decisions at
  IBM don't appreciate at all the creativity and inovative efforts of
  the programmers that made OS/2... it makes me sick!

                                                            - Ivan -

.!. Only one good: Knowledge. One evil: Ignorance.   Socrates
--- Terminate 5.00/Pro [OS/2]
 þ TerMail/QWK þ