🚀 go-pugleaf

In article <1992Dec15.174802.15272@emr1.emr.ca>, jagrant@emr1.emr.ca (John Grant) writes:
|> In article <711@lax.lax.pe-nelson.com> twbrown@PE-Nelson.COM (Tom W. Brown) writes:
|> >In article <wf=Fjj_00WB8QZoUYr@andrew.cmu.edu>, ak10+@andrew.cmu.edu (Andrew Joseph Kompanek) writes:
|> [...stuff deleted about segmented memory confusion...]
|> 
|> >Certainly it's possible to do that though I've tried to stay away from huge
|> >pointers because; 1) of the overhead in their use,
|> 	Yes, but it's really not that bad is it?

Dunno, it depends on how much pointer arithmetic you're doing on the huge
pointers. 

But a statement like "p++" becomes either a function call or a block of inline
code that increments the offset, checks to see whether the segment (selector)
should be modified, and possibly then resets the offset back within some
range.  Sounds like a lot of overhead to me.

|> 
|>  2) they chew up selectors, 
|> 	Tom, could you please explain this - I don't understand.

This is a protected mode consideration only.  To allocate a huge block of
memory and be able to access it you would need to reserve some number of
segment selectors from the descriptor table.  Since we still only have 16
bit offsets you need to reserve a segment selector for each 64 Kb block in
your huge array, and that assumes that the huge pointer implementation
makes maximum use of the offset portion of the pointer which may not be
true.

There are only ~8192 total selectors available in enhanced mode, ~4096
selectors available in standard mode.  Every code segment, data segment,
resource, etc. takes up a selector (i.e. every separate line item that you
see in HeapWalker).

We ran up hard against this selector limit in our application, building
our C++ data structures where a list of objects, each containing lists of
smaller objects, and so on caused enough global allocation to use up the
descriptor table entries.  We switched to a 3rd party memory manager
(OptiMem from MicroQuill) which has a much better subsegment allocator than
the Borland runtime.

I'm probably over reacting to the extra use of selectors because of our
recent problems with this limit -- a single "huge" array probably won't
get you into trouble.  A 1 Mb array would need 16 segment selectors to
fully access it, probably not a big deal (but then, who knows?)


|> 
|> >and 3) the "conventional" normalized huge pointers can't be used in
|> >protected mode Windows programming.
|> 	I don't understand this either.  Are there 2 kinds of huge
|> 	pointers? - "conventional" & "non-conventional"?  And why
|> 	can't they be used in protected mode?

Well, normalized huge pointers are for real mode and they are probably what
most DOS programmer's are used to.  A normalized huge pointer always ensures
that the offset portion is between 0x0000 and 0x000F inclusive.  Once the
offset would increment to 0x0010, the segment is incremented instead and the
offset is reset to zero.  This, of course, relies on the real mode property
that the segment corresponds to part of the physical address.

The reason this is done is to guarantee that two different pointer bit
patterns can't point to the same memory which in turn allows pointer
comparisons to be done more efficiently (compare the segments and only if
equal do you need to compare the offsets).

In protected mode you can't do this, simply incrementing a segment selector
will almost certainly generate a GPF.  You would need to reserve a selector
for every 16 bytes of your array and guarantee that they were consecutive
(perhaps with an offset) in order for this type of normalization to work.

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

Anyway, in a C++ environment it's easy to create an class (template) that
looks and feels like an array, allows you to access more than 64K of data,
and doesn't need to use huge pointers.  This is definitely the way to go!


----------------------------------------------------------------------------
Tom Brown               |  "She turned me into a newt...
PE Nelson Systems       |                                  ... I got better"
twbrown@pe-nelson.com   |                    Monty Python and the Holy Grail
----------------------------------------------------------------------------