info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Why did Turbo Pascal implement its own heap manager?
70 views
Skip to first unread message
Jim Leonard
Feb 8, 2017, 6:31:41 PM2/8/17
to
As the subject says. Since MS-DOS ever since version 2.0 has memory management functions (INT 21h/AH=48h, INT 21h/AH=49h, and INT 21h/AH=4Ah), why did Borland feel it necessary to implement their own heap manager?
The only possible reason I can think of is that Borland's management only uses 8 bytes of overhead instead of DOS's 16 bytes per overhead (per MCB), so I guess the advantage was that you could use 8 less bytes per allocation, and also allow a minimum allocation of 8 bytes instead of DOS's 16 bytes. The thing is, the heap manager compiles to nearly 1K, so it seems like this would have eaten up any savings gained by a smaller heap structure...? Any thoughts or comments welcome.
The only possible reason I can think of is that Borland's management only uses 8 bytes of overhead instead of DOS's 16 bytes per overhead (per MCB), so I guess the advantage was that you could use 8 less bytes per allocation, and also allow a minimum allocation of 8 bytes instead of DOS's 16 bytes. The thing is, the heap manager compiles to nearly 1K, so it seems like this would have eaten up any savings gained by a smaller heap structure...? Any thoughts or comments welcome.
Gene Buckle
Feb 14, 2017, 5:27:54 PM2/14/17
to
To: Jim Leonard
Jim wrote:
> From Newsgroup: comp.lang.pascal.borland
What version of Turbo Pascal are you referencing?
g.
--
Proud owner of F-15C 80-0007
http://www.f15sim.com - The only one of its kind.
http://www.diy-cockpits.org/coll - Go Collimated or Go Home.
Some people collect things for a hobby. Geeks collect hobbies.
ScarletDME - The red hot Data Management Environment
A Multi-Value database for the masses, not the classes.
http://scarlet.deltasoft.com - Get it _today_!
--- Synchronet 3.16c-Win32 NewsLink 1.103
The Retro Archive - telnet://bbs.retroarchive.org
Jim wrote:
> From Newsgroup: comp.lang.pascal.borland
>
> As the subject says. Since MS-DOS ever since version 2.0 has memory management functions (INT 21h/AH=48h, INT 21h/AH=49h, and INT 21h/AH=4Ah), why did Borland feel it necessary to implement their own heap manager?
> The only possible reason I can think of is that Borland's management only uses 8 bytes of overhead instead of DOS's 16 bytes per overhead (per MCB), so I guess the advantage was that you could use 8 less bytes per allocation, and also allow a minimum allocation of 8 bytes instead of DOS's 16 bytes. The thing is, the heap manager compiles to nearly 1K, so it seems like this would have eaten up any savings gained by a smaller heap structure...? Any thoughts or comments welcome.
Is it likely that their heap manager is more efficient or faster?
> As the subject says. Since MS-DOS ever since version 2.0 has memory management functions (INT 21h/AH=48h, INT 21h/AH=49h, and INT 21h/AH=4Ah), why did Borland feel it necessary to implement their own heap manager?
> The only possible reason I can think of is that Borland's management only uses 8 bytes of overhead instead of DOS's 16 bytes per overhead (per MCB), so I guess the advantage was that you could use 8 less bytes per allocation, and also allow a minimum allocation of 8 bytes instead of DOS's 16 bytes. The thing is, the heap manager compiles to nearly 1K, so it seems like this would have eaten up any savings gained by a smaller heap structure...? Any thoughts or comments welcome.
What version of Turbo Pascal are you referencing?
g.
--
Proud owner of F-15C 80-0007
http://www.f15sim.com - The only one of its kind.
http://www.diy-cockpits.org/coll - Go Collimated or Go Home.
Some people collect things for a hobby. Geeks collect hobbies.
ScarletDME - The red hot Data Management Environment
A Multi-Value database for the masses, not the classes.
http://scarlet.deltasoft.com - Get it _today_!
--- Synchronet 3.16c-Win32 NewsLink 1.103
The Retro Archive - telnet://bbs.retroarchive.org
Jim Leonard
Mar 8, 2017, 11:49:38 AM3/8/17
to
On Tuesday, February 14, 2017 at 4:27:54 PM UTC-6, Gene Buckle wrote:
> Is it likely that their heap manager is more efficient or faster?
I've looked at the code for both, and they seem to have roughly the same runtime.
> Is it likely that their heap manager is more efficient or faster?
> What version of Turbo Pascal are you referencing?
I've come to the conclusion that the reason for the change was likely the need for more granular allocation. 5.5 introduced objects, which dramatically increased the load on the heap manager, so in 6.0 they cut the slack/waste down to 8 bytes from 16. It is possible to create more granular heap management, but not without drastically increasing the overhead (both time and storage) which eliminates the gains you'd get. So the TP 6.0+ heap manager represents the sweet spot of complexity, storage efficiency, and flexibility.
The whole thing came up when I was looking into ways to create more size-optimized code and realized there was a lot of duplication of effort along the way. If I really need size, I'll code in assembler :)
Marco van de Voort
Mar 9, 2017, 4:22:41 AM3/9/17
to
On 2017-02-08, Jim Leonard <Moby...@gmail.com> wrote:
> The only possible reason I can think of is that Borland's management only
> uses 8 bytes of overhead instead of DOS's 16 bytes per overhead (per MCB),
> so I guess the advantage was that you could use 8 less bytes per
> allocation, and also allow a minimum allocation of 8 bytes instead of
> DOS's 16 bytes.
Or something requiring control in e.g. overlays ?
> The only possible reason I can think of is that Borland's management only
> uses 8 bytes of overhead instead of DOS's 16 bytes per overhead (per MCB),
> so I guess the advantage was that you could use 8 less bytes per
> allocation, and also allow a minimum allocation of 8 bytes instead of
> DOS's 16 bytes.
sillyluis
Mar 14, 2017, 1:31:38 PM3/14/17
to
> ... Since MS-DOS ever since version 2.0 has memory management functions (INT 21h/AH=48h, INT 21h/AH=49h, and INT 21h/AH=4Ah), why did Borland feel it necessary to implement their own heap manager?
Another probable reason is a bug in MS-DOS memory manager wherein requesting a block bigger than the bigest available block produced an error *but* also "reserved" the available memory w/out returning a pointer to it (depending on he DOS version).
Note also that MS-DOS allocated memory in multiples of a paragraph (16 bytes), which at that time was considered somewhat wasteful; thus the proliferation of custom intra-application memory managers one could find everywhere.
--
Luis Caballero
Another probable reason is a bug in MS-DOS memory manager wherein requesting a block bigger than the bigest available block produced an error *but* also "reserved" the available memory w/out returning a pointer to it (depending on he DOS version).
Note also that MS-DOS allocated memory in multiples of a paragraph (16 bytes), which at that time was considered somewhat wasteful; thus the proliferation of custom intra-application memory managers one could find everywhere.
--
Luis Caballero
0 new messages