"Out of Near Heap" in summary

[Jainbai Wang]

Since I posted the message of looking for help on MSC compiler's
problem of  "out of the near heap space", about two dosen people
have responded and given different advices. Thanks to all of you.
Please excuse me not reply your mail individually and please stop
sending further response to me.

One net reader suggested me to post here the out come of the problem 
to benifit others. Any one interested may read the following paragraphs.

First of all, the problem is with Microsoft's newly deleivered version 
called QC2, not MSC5.x. (no message has been received on QC2 yet). I 
called Microsoft's technical service line and was told the QC2 compiler 
hits itselves limit and the only cure is to decompose the program being 
compiled. QC2 is a nicer compiler for prototyping but is not as phased 
as MSC and does more jobs at the same, which means its working space is 
smaller. I tried to compile my program using MSC5.1 the problem disappeared.

The following is a summary of all the suggestions received :

***Class 1 (removing a preprocessor) :
>This C compiler has two preprocessors : c1s and c1l. Copy the c1l to c1.exe.
>   or "cl /B1 C1L.EXE ...options... file.c" (See \source\doc\readme.doc)
>It may applies to all versions of MSC.
>The special version of the preprocessor/parser has more symbol-table memory.

***Class 2 (freeing RAM) :
>A symptom of memory hogging by network or CD-ROM drivers.Free the ram used by
>   the network software.
>Remove those big TSRs, do not use MAKE or bat file, reduce BUFFERS= & FILES=,&
>   DEVICE=, & unnecessary #include header files.
>Use the far heap. Control the memory to a degree by unloading all TSR's and
>   other garbage hogging memory. Boot with TSR's to do your editing, re-boot
>   without TSR's to do your compile, boot do editing,....

***Class 3 (blaming /LA) :
>If you are using Version 5.1 and the LARGE memory model, you may have problems
>   with near default data segments. 
>Switch "LARGE" invokes a slower version of the compiler which is built with
>   /LA and can handle larger modules. Make sure the /AL is installed.
>"cc -ML" asks that the compiler output be generated "large" model, and has
>   nothing to do with the compiler itself.
>The compiler itself was probably compiled with /AL and is using up the heap.
>   Recompile the compiler with /AL or make the compiler to use far heap. 
>Large memory model makes your data go in one 64k segment and the heap and 
>   stack in another.  Still a limitation on the near heap.

***Class 4 (changing you source)
>More than 64k "global scope" data.The # of symbols defined is irrelevant. Their
>   SIZE isn't. Moving the larger elements declared outside of any function into
>   data file. Recompiling both in /AL.You can have >64k through MULTIPLE FILES.
>If the compiler itself is running out of near heap space, the ONLY thing 
>   availble to you is to decompose your program.

***Class 5 (adjusting the stack) : 
>Set the /Gt switch ... (See MSC Manual)

***Class 6 (blaming YACC) :
>Try to get YACC to generate several small source files.

--------------------------------------
After all, I would like add my comment :

 1. It's a problem with the compiler itself. I agree that /AL model won't
    help much. If using MSC, first try the /B1 switch, second, decompose
    you source code.
 2. The error probably is not very precisely reported. Because when I moved
    a big data object (~10k, in the yacc generated file) to far heap, and
    compile with /AL, the problem is still there. But when I deleted about
    30 lines of executable code (no function calls involved, only normal
    if.. assignment types), the program passed the compilation! What
    could the heap has to do with the code segment ?