1. Forum
  2. Usenet
  3. COMP.LANG.PASCAL.BORLAND

  • Why did Turbo Pascal implement its own heap manager?

    From Jim Leonard@21:1/5 to All on Wed Feb 8 15:31:40 2017
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Gene Buckle@21:1/5 to Jim on Tue Feb 14 14:17:05 2017
    To: Jim Leonard
    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?

    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jim Leonard@21:1/5 to Gene Buckle on Wed Mar 8 08:49:37 2017
    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.

    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 :)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Marco van de Voort@21:1/5 to Jim Leonard on Thu Mar 9 09:22:40 2017
    On 2017-02-08, Jim Leonard <MobyGamer@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 ?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From sillyluis@21:1/5 to All on Tue Mar 14 10:31:37 2017
    ... 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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)