Groups | Search | Server Info | Login | Register

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

Re: Memory, objects, and TCollections

Show all headers | View raw

On 2012-07-22 21:07, Marco van de Voort wrote:
> 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.

There is a unit in SWAG that does this, actually, several near identical ones. 
I've assembler-ized one of them and used it until I made the switch to 32-bit.

There's also a unit to store data in XMS. It's not in SWAG (IIRC), but you might 
find it on Garbo, or rather a mirror of Garbo, as Garbo itself is dead (thanks 
to some bean-counters).

> 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.

+1

Robert
-- 
Robert AH Prins
robert(a)prino(d)org

Back to comp.lang.pascal.borland | Previous | Next — Previous 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