Why did Turbo Pascal implement its own heap manager?

[Jim Leonard]

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.

[Gene Buckle]

To: Jim Leonard

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?

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]

Post by Gene Buckle
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.

Post by Gene Buckle
What version of Turbo Pascal are you referencing?

7.0, although the heap manager is the same as when it was changed in 6.0.

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]

Post by Jim Leonard
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 ?

[sillyluis]

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