Groups | Search | Server Info | Login | Register
Groups > comp.lang.pascal.borland > #109
| 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> |
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 | Next — Previous in thread | Next in thread | Find similar
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