Original from  Eddy Thilleman  to Denis Tonn on 12-20-1998
Original Subject: more power

                         ---------------------------------------

 DT> Ram is allocated in 4K pages, but "address space" is allocated
 DT> in 64K blocks. 
 
ET> Has the 64KB blocks something to do with the GDT selectors in the processor?
 
 DT> If you want to discuss the differences between ram, address
 DT> space, and memory, come on over to the OS2PROG echo. 
 
ET> OK, please fill me in! :-)

 I'll do this in 2 parts/messages. First the specifics of why 
allocating in 64K pieces is more efficient. Then a little discussion
on the differences between RAM, address space, and memory. 
 
 DT> This topic is usually only interesting to programmers.
 
ET> That I'm.
 
 DT> The most efficient use of address space under OS/2 (up until
 DT> now) means allocating 64K (or exact multiples of) blocks.
 
ET> Is that because the smallest allocation unit the GDT 
ET> selectors in the processor can address is 64 KB ?

 It is related to the descriptor tables, but nothing so obvious. In 
fact the 386 LDT and GDT selectors can have units of allocation from 1 
byte to 4GB. 16 bit apps were limited to a MAXIMUM of 64K per 
selector (the 286 limit).

 Here is a little of the "why" back ground first: 
 OS/2 1.x was all 16 bit. It ran on 286 processors. There were quite a
few 16 bit applications written for OS/2 1.x. Most of these were 
"corporate" apps. An "app" that would consist of a
dozen or more EXE 
modules and upwards of a 100 DLLs, all interacting. When OS/2 2.0 came
along, 32 bit apps could be written, and former 16 bit apps could be 
converted to 32 bit app. BUT, the job of converting one of these 
"corporate sized" apps to 32 bit would be a massive one if they were 
forced to do so all at once. These corps needed a way that they could 
write (or convert a 16 bit "piece") and still have it interoperate 
with all the 16 bit pieces. The major problem with this is that the 
older 16 bit pieces have no way of understanding the 32 bit addresses 
(pointers) supplied by the 32 bit piece. The 32 bit piece could handle
16:16 addresses, but it loses the benefits of 32 bit addresses. A way 
of "converting" these addresses needs to be made available. This 
conversion process is genericly called "thunking" (an academic term, 
not an IBM one). 
 Thunking can be either expensive (in CPU overhead) or cheap depending
on how it is done. 

 16:16 apps use the GDT and LDT directly (and the base addresses in 
the descriptor mapped directly to a RAM address in OS/2 1.x). 32 bit 
apps also use a descriptor but the base is usually at zero and the 
limit is arbitrarily large. Most 32 bit apps use whatever descriptor 
is supplied by the system and ignore it. It is still there. 

 In OS/2 2.0, they elected to "tile" the LDT in order to make the 
process of thunking cheap and fast. This means that all allocations 
occur on a 64K boundry, but they are still "sized" appropriately. Even
32 bit allocations are all done on a 64K boundries and the LDT is 
updated "behind the scenes" in order to keep potential 16:16 addresses
available so that the 32 bit app can convert and pass a pointer to a 
16:16 app. Only the LDT is tiled, not the GDT. An example might help 
at this point: 
 A 32 bit piece of code allocates 132K of memory. The DosAllocMem call
returns an address to the app, say 50000, where this memory is 
"located" for the app to use. Behind the scenes, the kernel has also 
updated the LDT so that descriptors 2F, 37, and 3F contain valid 
entries. the limit fields of 2F and 37 are both 64K, and the limit 
field of selector 3F is 4K. EG:
         Base 70000 Limit 0FFF
         Base 60000 Limit FFFF
         Base 50000 Limit FFFF
 The 32 bit portion of the app will continue to use the "flat" 
addresses starting at 50000 thru 70FFF, but the LDT will be "ready" 
for an easy conversion to 16:16 format for any 16:16 portions of the 
code.
 Each additional allocation unit will start at the "next" 64K boundry.
 When the 32 bit app needs to "pass" an address to one of the 16 bit 
portions of code, it can easily "thunk" the address to a 16:16 form by 
spliting the 32 bit address into 2 parts. The lower 16 bits will 
directly become the offset used by the 16:16 code. The upper 16 bits 
can be "converted" to a selector value by the formula a*8+7 where a is
the uppper 16 bits of the 32 bit address. In the above case, say it 
wanted to pass address 00061212 to the 16 bit app; 6*8+7=37 so the
resultant 16:16 address would be 37:1212. Likewise, converting 16:16 
addresses is just the reverse. An integer divide (s/8 ignoring the 
remainder) to create the upper 16 bits of the 32 bit address, the 
offset is lifted directly into the bottom 16 bits.. 

 Couple of points: All allocations will still take up "RAM" in 4K 
increments (when used). Even a 1 byte allocation by a 16 bit app will 
require a 4K RAM page to back it, even though the descriptor table 
will still have a limit of 1 byte for the allocation (when used by the
16:16 app). 
 Only the LDT is tiled, not the GDT. The "flat" selectors used by 32 
bit code are allocated out of the GDT, and (current releases) will 
always be CS=5B and DS/SS/ES=53. The base address of these 2 selectors
is zero and the limit field is 448MB on Warp 3 GA and 512MB on Warp 4 
GA (and later fixpacks for Warp 3). The largest 32 bit address that 
can be thunked back to 16:16 using the tiled LDT is 512MB. Memory 
above 512MB cannot be "shared" between 16 and 32 bit apps in this 
fashion. Currently, the only version of OS/2 that allows an 
*application* to allocate memory above 512MB is Warp server SMP and 
the upcoming e-business server (in beta). 



   Denis       

 All opinions are my very own, IBM has no claim upon them
. 
. 
.
 

 



--- Maximus/2 3.01