jrv@siemens.UUCP (05/16/86)
Whether you can gain anything by compiling in "medium" model will depend
on just what is meant by "medium". There are two classes of information
in the program: data and code. These can independently be selected to use
offset only or segment/offset addressing which makes a total of 4
combinations. The Lattice C compiler gives you 4 memory options so that
you can mix things as needed. If the "medium" model on the MS C compiler
is large CODE and small DATA then your comment is correct. Everything
which is data must fit into one 64k segment. The code for MicroEMACS is
not large enough to warrant large code space addressing.
With the Lattice compiler the D model (small code, large data) is the best
one to use. However, static data size could become a problem. The Lattice
compiler has the requirement that all static data must exist in one 64k
segment (no if ands or buts). Large data model only buys you something
if you dynamically allocate memory storage. Any memory which is obtained
this way comes from outside of the static data segment so you have all of
memory to play with. MicroEMACS allocates buffer storage for files
dynamically using malloc() allowing it to go beyond the 64k limit.
I have a very small amount of experience with MS C (Microsoft right?).
One feature that I vaguely remember is a command line switch which allows
you to place static data in many segments. The option specified a value
and if the data item being declared was larger than that value it was
placed into its own segment rather than the common data segment. This is
a nice feature if you have a lot of static data. I appologize if my memory
of this option is totally contorted.
Jim Vallino
Siemens Research and Technology Lab.
Princeton, NJ
{allegra,ihnp4,seismo,philabs}!princeton!siemens!jrvlawrence@duncan.UUCP (05/20/86)
Thanks for the porting info. I will make every attempt to itigrate your changes with the MicroEMACS 3.7 coming out in late june. Daniel Lawrence ihnp4!itivax!duncan!lawrence
caf@omen.UUCP (05/23/86)
In article <23900019@siemens.UUCP> jrv@siemens.UUCP writes: > > > >Whether you can gain anything by compiling in "medium" model will depend >on just what is meant by "medium". There are two classes of information >in the program: data and code. These can independently be selected to use >offset only or segment/offset addressing which makes a total of 4 >combinations. The Lattice C compiler gives you 4 memory options so that >you can mix things as needed. If the "medium" model on the MS C compiler >is large CODE and small DATA then your comment is correct. Everything >which is data must fit into one 64k segment. The code for MicroEMACS is >not large enough to warrant large code space addressing. > >With the Lattice compiler the D model (small code, large data) is the best >one to use. However, static data size could become a problem. The Lattice >compiler has the requirement that all static data must exist in one 64k >segment (no if ands or buts). Large data model only buys you something >if you dynamically allocate memory storage. Any memory which is obtained >this way comes from outside of the static data segment so you have all of >memory to play with. MicroEMACS allocates buffer storage for files >dynamically using malloc() allowing it to go beyond the 64k limit. > >I have a very small amount of experience with MS C (Microsoft right?). >One feature that I vaguely remember is a command line switch which allows >you to place static data in many segments. The option specified a value >and if the data item being declared was larger than that value it was >placed into its own segment rather than the common data segment. This is >a nice feature if you have a lot of static data. I appologize if my memory >of this option is totally contorted. > Here is the Makefile I hacked to compile a DOS version of Emacs using the Xenix to DOS cross compiler. The -NT _TEXT merely puts all the code in one segment (default is a different code segment for each file) to make debugging easier. This is one of the bloody few programs that compile and seem to work when passed through this compiler. I must admit I haven't used it much, I don't have the time to give it a serious checkout and therefore prefer to use an editor I can trust (Epsilon). But Emacs does run quickly on a 9 mHz AT. CFLAGS = -dos -pack -O -K -M0 -Ml -DLATTICE=1 -NT _TEXT LIB = /usr/lib/dos FLOP = B: OBJS = ansi.o basic.o buffer.o display.o file.o fileio.o line.o main.o \ meta.o random.o region.o search.o spawn.o termio.o window.o word.o cp:emacs.exe doscp -r emacs.exe C:/tmp emacs.exe:$(OBJS) dosld -M -F 2000 -m emacs.map -o emacs.exe \ $(OBJS) $(LIB)/Ldlibc.a -ls -l emacs.exe clean: rm -f *.o nohup.out *.tmp