Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!mephisto!tut.cis.ohio-state.edu!snorkelwacker!bloom-beacon!bu.edu!mirror!necntc!pec
From: pec@necntc.nec.com (Paul Cohen)
Newsgroups: comp.sys.ibm.pc.programmer
Subject: Re: Far code segments in the small or compact memory model
Keywords: far code, compact model
Message-ID: <28397@necntc.nec.com>
Date: 1 Mar 90 22:36:41 GMT
References: <28396@necntc.nec.com> <4327@jhunix.HCF.JHU.EDU>
Reply-To: pec@necntc.UUCP (Paul Cohen)
Distribution: usa
Organization: NEC Electronics Inc.  Natick, MA 01760
Lines: 37


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.