Groups | Search | Server Info | Login | Register


Groups > comp.lang.pascal.borland > #109

Re: Memory, objects, and TCollections

From Marco van de Voort <marcov@toad.stack.nl>
Newsgroups comp.lang.pascal.borland
Subject Re: Memory, objects, and TCollections
Date 2012-07-22 21:07 +0000
Organization Stack Usenet News Service
Message-ID <slrnk0oqt8.1kcg.marcov@toad.stack.nl> (permalink)
References <45fb5804-296d-43f4-bd0d-ec3d109a5d27@y12g2000yqe.googlegroups.com>

Show all headers | View raw


On 2012-07-22, Jim Leonard <mobygamer@gmail.com> wrote:
> tell, these are limited to using the heap for storage.  (They return
> pointers to objects, and objects are stored in main RAM on the heap.)
> At some point, I will run out of the lower 640K DOS memory to hold all
> my objects.

That points to 16-bit protected mode. But you rule that out also.

> What is the recommended way to get past this?  I can't compile to 286
> protected mode because I'm working with some pretty hairy inline
> assembler (that I CANNOT change) that doesn't work in protected mode.
> I could store my objects on an EMS or XMS stream (or even disk if I'm
> desperate), but manipulating them (ie. sorting them, insertion/
> deletion) could get unacceptably slow.  How did people solve
> TCollection/Object memory issues in the past?

By not setting umpteen conflicting borderconditions :-)

Since the real mode TP memory model is fundamentally limited to 1MB, there
is not much you can do easily. 

Basically all I can think of is using upper memory blocks (since the limit
is 1MB not 640k) and (data) overlays. 

Overlay (swapping in blocks in and out of high mem) is rarely fully
transparent, since simply not everything can't be in addressable memory at
the same time, and this boundery condition must be manually enforced.

One could e.g. stuff very large arrays in EMS, and map the relevant parts
in when needed.

In theory one could also use UMBS as real heap, but that would require
modifying the heapmanager. Maybe there already is such one in SWAG.

In short, there was a reason why people were happy to go from real mode
towards 32-bit and protected mode.  This is the reason, memory management
this way is manual (and thus time intensive and errorprone) and often not
very reusable from application to application.

Back to comp.lang.pascal.borland | Previous | NextPrevious in thread | Next in thread | Find similar


Thread

Memory, objects, and TCollections Jim Leonard <mobygamer@gmail.com> - 2012-07-22 11:02 -0700
  Re: Memory, objects, and TCollections Marco van de Voort <marcov@toad.stack.nl> - 2012-07-22 21:07 +0000
    Re: Memory, objects, and TCollections Robert AH Prins <spamtrap@prino.org> - 2012-07-23 02:31 +0000
      Re: Memory, objects, and TCollections Jim Leonard <mobygamer@gmail.com> - 2012-07-23 11:33 -0700
        Re: Memory, objects, and TCollections Marco van de Voort <marcov@toad.stack.nl> - 2012-07-24 16:20 +0000
          Re: Memory, objects, and TCollections Jim Leonard <MobyGamer@gmail.com> - 2012-07-26 14:19 -0700
            Re: Memory, objects, and TCollections Marco van de Voort <marcov@toad.stack.nl> - 2012-07-27 10:46 +0000
    Re: Memory, objects, and TCollections Jim Leonard <mobygamer@gmail.com> - 2012-07-23 11:42 -0700
      Re: Memory, objects, and TCollections Marco van de Voort <marcov@toad.stack.nl> - 2012-07-25 12:10 +0000
        Re: Memory, objects, and TCollections Jim Leonard <MobyGamer@gmail.com> - 2012-07-26 14:21 -0700
          Re: Memory, objects, and TCollections Marco van de Voort <marcov@toad.stack.nl> - 2012-07-27 11:13 +0000

csiph-web