Newsgroups: comp.lang.pascal
Path: utzoo!utgpu!watserv1!maytag!watstat.waterloo.edu!dmurdoch
From: dmurdoch@watstat.waterloo.edu (Duncan Murdoch)
Subject: Re: TP memory model question
Message-ID: <1991Mar17.153340.13824@maytag.waterloo.edu>
Sender: daemon@maytag.waterloo.edu (Admin)
Organization: University of Waterloo
References: <14312@encore.Encore.COM>
Date: Sun, 17 Mar 1991 15:33:40 GMT
Lines: 33

In article <14312@encore.Encore.COM> soper@encore.UUCP (Pete Soper,Cary NC,9194813730,9193624635) writes:
>
>  What memory model does TP 5.0 and/or 6.0 use? What are the 
>limits for code and data? Is there an overlay mechanism
>or some other means of accommodating large amounts of highly
>transient code? 

I don't think its memory model corresponds exactly to any of Microsoft's.  Here
are the details:

 - Static and global data live in a 64K data segment
 - Local variables live on the stack, which may be up to 64K, and is separate
   from the data segment
 - The coprocessor emulator uses part of the stack segment to store its state
 - Every unit (and the main program) is in a separate code segment, with
   individual 64K limits, but no limits on the total size.  Calls within a
   unit are near calls, calls between units are far calls.
 - Code overlays are supported, in a buffer that can be as large as desired
   (there were changes to the overlay manager in 5.5, so there may be 
   restrictions in 5.0 that I don't remember; I'm working with 6.0)
 - The heap gets whatever memory is left over.

Pointers to variables are always far pointers (32 bits), as are variable
references passed on the stack.  This is (IMHO) the main deficiency of the
memory model:  sometimes it would be nice to be able to use near pointers,
but there's no support for that at all.  (It wouldn't be easy, with SS<>DS.
But I can think of ways to handle it.)

Duncan Murdoch
dmurdoch@watstat.waterloo.edu