CDCKAB%EMUVM1.BITNET@cunyvm.cuny.edu ( Karl Brendel) (09/27/90)
In article <1026@massey.ac.nz>, John Lockhart <ABurton@massey.ac.nz> [sic] writes: >My problem is that I can't compile my Borland OOP pascal program, the >symptoms are that the TPC compiler is running out of RAM. > >I'm using the object professional toolbox (which is HUGE), does anybody >now if Borland has any plans to utilise extended memory. The version I >am using is 5.5. (And concludes: >I would prefer direct email responses as I don't usually read this >group. >Email J.W.Lockhart@massey.ac.nz ) I have emailed this information to him, but post it here for the sake of the list, at the risk of mostly stating the obvious: A section of the TurboPower Object Professional documentation discusses compiling OPro files. The first step is to read that material. Among the actions to consider are: 1) Use TPC rather than TURBO.EXE. 2) Compile with maximum available DOS RAM, even if it means running without your favorite disk cache, with reduced buffers, etc. (If you are using QEMM as a 386 memory manager, use VIDRAM to enable an additional 64K of DOS RAM.) 3) Set the link buffer to disk with the /L (note: NOT /$L) directive on the command line or in TPC.CFG. 4) Use the compiler directives $L+ and $D+ only in the portions of code where you actually need debugger access. 5) Undocumented, as far as I know: Some users have reported better success by placing their main program into a unit file, which becomes the only one used by a dummy main program. I.e., instead of program Main; uses opCRT,opEntry, ... ; var ... ; procedure foo; begin ... end; ... function foof : boolean; begin ... end; ... begin {main} ... end. we have unit MainUnit; interface uses opCRT,opEntry, ... ; var ... ; procedure foo; ... function foof : boolean; ... procedure MainRoutine; implementation procedure foo; begin ... end; ... function foof : boolean; begin ... end; ... procedure MainRoutine; begin {main} ... end; end. and program Main; uses MainUnit; begin MainRoutine; end; The claim is that structure like this reduces the RAM requirements of the linker. I have not tried it myself, and I fail to see how it will be easier to compile MAINUNIT.PAS than it was to compile MAIN.PAS, but I present it as the suggestion of others. +-------------------------------------------------------------------------+ | Karl Brendel Centers for Disease Control | | CDCKAB@EMUVM1.BITNET Epidemiology Program Office | | InterLink/RIME: KARL BRENDEL Atlanta, GA, USA | | GEnie: K.BRENDEL phone 404/639-2709 | | fts 236-2709 | | Home of Epi Info 5.0 | +-------------------------------------------------------------------------+
decomyn@penguin.uss.tek.com (09/28/90)
In article <24635@adm.BRL.MIL> CDCKAB%EMUVM1.BITNET@cunyvm.cuny.edu ( Karl Brendel) writes: >I have emailed this information to him, but post it here for the sake of >the list, at the risk of mostly stating the obvious: [ ... stuff deleted ... ] >5) Undocumented, as far as I know: Some users have reported better >success by placing their main program into a unit file, which becomes >the only one used by a dummy main program. I.e., instead of > [... more stuff deleted so my news program doesn't complain ... ] >The claim is that structure like this reduces the RAM requirements of >the linker. I have not tried it myself, and I fail to see how it will be >easier to compile MAINUNIT.PAS than it was to compile MAIN.PAS, but I >present it as the suggestion of others. Just a guess -- the compiler probably doesn't link in the required SYSTEM unit start-up code until it compiles the main program. If the program is placed into a UNIT with a dummy main, most of the heavy-duty linking and compiling will be finished by the time the dummy main compiles -- this could do it if the amount of free space you have is marginal. >+-------------------------------------------------------------------------+ >| Karl Brendel Centers for Disease Control | >| CDCKAB@EMUVM1.BITNET Epidemiology Program Office | Brendt Hess decomyn@penguin.uss.tek.com