Vitus Jensen wrote in a message to Mike Bilow:

 MB> I just use small model and put IORB space in the default data 
 MB> segment.  The only requirement is that IORB space be accessible 
 MB> as "near" data and never be swapped or moved, and the default 
 MB> data segment of any OS/2 device driver will fulfill those 
 MB> requirements.  There is no need for _based.

 VJ> You're copying every IORB to local data segment??? Not very
 VJ> usefull if your targets are up to 8 Disk Array Controllers
 VJ> accepting up to 124 commands each (even if OS/2 doesn't use
 VJ> that much IORBs at the same time). 

Maybe we're not on the same wavelength here.  I don't copy IORBs at all. 
From the point of view of a DMD, IORBs should be in the default data
segment, and some of the API requires this as a practical matter.  If you
are processing inside an ADD, then the IORB is owned by some other module,
and you have no say in where it is allocated, nor can you assume anything
about it.

 VJ> As the ADD entry points are passed a linked list of IORBs
 VJ> (linked with far pointers!) you have to use them to access
 VJ> the IORB.  But there is no need to use a far pointer to an
 VJ> area inside this IORB as shortcut if you have one to the
 VJ> header.  There is not even a need to use any shortcuts if
 VJ> the compiler would  optimize better (and I wouldn't be to
 VJ> lazy to write all that casts on every single access :-).

I see what you are saying now, but I am not sure that the compiler will
generate any different code this way.  After all, you only have so many
segment registers, and a _based pointer occupies one just like a far
pointer.  I suppose it is possible that you manage to suppress a segment
register reload of the same value by using a _based pointer, but that would
depend upon a gross inefficiency being present in the compiler.  If the
segment register is being reloaded with a different value, then you have to
do the reload no matter how the pointer is declared.  The ADD could not
afford to lose access to its own default data segment so as to speed up
access to another module's.

Part of the problem is that there are number of unspoken conventions which
are not really documented.  You can figure them out yourself or study the
IBM source examples, but is not explicitly stated that the tail end of
memory space after an IORB is valuable for use as a status block or other
structure. MS C 6.0 also achieves powerful optimizations if the IORBs are
allocated on a power-of-two boundary, such as 128 or 256 bytes, with the
slack space used as described.  These are really tricks to take advantage
of the compiler, but most device driver programmers do not know them.
 
-- Mike


---