🚀 go-pugleaf

In article <28396@necntc.nec.com> pec@necntc.nec.com (Paul Cohen) writes:
>I have a program which has just slightly too large a code size to fit in
>one segment.  It has one function which is executed only once so putting
>it into another segment seems a way to avoid changing to the Large
>memory model (which slows down execution noticeably).  

Use overlaying.  Read it up in your compiler manual or dos manual,
compile the offending routine in a separate file, and specify it as 
not part of the permanent code.  You may need to place something alse
in that state so there is some space for the two to swap between them.

					Gunther W. Anderson
					gunther@jhunix.hcf.jhu.edu

In article <4327@jhunix.HCF.JHU.EDU> eisen@jhunix.UUCP (Gunther Wil Anderson)
writes:

>>In article <28396@necntc.nec.com> pec@necntc.nec.com (Paul Cohen) writes:
>>I have a program which has just slightly too large a code size to fit in
>>one segment.  It has one function which is executed only once so putting
>>it into another segment seems a way to avoid changing to the Large
>>memory model (which slows down execution noticeably).  

>Use overlaying.  Read it up in your compiler manual or dos manual,
>compile the offending routine in a separate file, and specify it as 
>not part of the permanent code.  You may need to place something alse
>in that state so there is some space for the two to swap between them.

Thanks for the suggestion, but I prefer not to use overlays because of 
the extra file and extra overhead involved.  

I also received some mail from Microsoft, giving some incorrect advice 
on the matter.  Since it appears that I am not the only
one who did not know how to do this, let me explain what I have
discovered since my original posting.  As I suspected, it is possible to 
put one function into a far segment and stay with the SMALL/COMPACT model 
for the rest of the program.  It is not even difficult to do.

I put the one "far" function into its own separate source file.  In 
linking, this particular module HAD TO BE LISTED AS THE LAST .obj file 
file.  Otherwise LINK would put it into the same segment as the rest of 
the program and then complain that there was not enough space.

Listing a particular .obj file last required some trickery because 
of a pecular shortcomming in Microsoft's MAKE utility.  Because this MAKE
utility permits only fairly short lines it was not possible for me to
list all of the object files separately on the LINK command line, but 
instead had to use the "*.obj" syntax.  In order to control which file 
appeared last, I put it into a separate directory so that I could specify 
it separately, after the *.obj specification.