soper@encore.UUCP (Pete Soper,Cary NC,9194813730,9193624635) (03/15/91)
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? ----------------------------------------------------------------------- Pete Soper (soper@encore.com) +1 919 481 3730 Encore Computer Corp, 901 Kildaire Farm Rd, bldg D, Cary, NC 27511 USA
amb43790@uxa.cso.uiuc.edu (Anthony M Brummett) (03/16/91)
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? >----------------------------------------------------------------------- >Pete Soper (soper@encore.com) +1 919 481 3730 >Encore Computer Corp, 901 Kildaire Farm Rd, bldg D, Cary, NC 27511 USA I have only TP 5.5, but they are probably all similar in these areas. The limit for total data is 64K this includes the main program and any units the program uses. This does not include any data on the heap, it is limited only by the amount of memory is installed. The limit on code is 64K for each "part". The main program and each unit get 64K each. I don't know when it was introduced, but TP 5.5 has a standard unit aptly named OVERLAY.TPU. The only problem with OVERLAY is that you can overlay only units, not just any old code. Your olny other option would be to use EXEC (But probably not). Antoine----------------amb43790@uxa.cso.uiuc.edu
dmurdoch@watstat.waterloo.edu (Duncan Murdoch) (03/17/91)
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
ebergman@isis.cs.du.edu (Eric Bergman-Terrell) (03/21/91)
I believe that TP 5.0 & 6.0 use the medium memory model. They both support overlays (VERY WELL, in fact). Simple to use & fast running. Terrell