[comp.lang.pascal] Compiling OPro

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