🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: net.micro.pc
Article #6627

Re: More info on porting MicroEmacs 3.5

#6627
From: caf
Date: Fri, 23 May 1986 05:50
59 lines
3357 bytes
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
Technical Details
Message-ID: <341@omen.UUCP>
Path: arc1-ca.pugleaf.net!utzoo!watmath!clyde!burl!ulysses!bellcore!decvax!decwrl!pyramid!hplabs!tektronix!reed!omen!caf
References: <2628@yale.UUCP> <23900019@siemens.UUCP>

Show Full Headers
Complete Article Headers
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: arc1-ca.pugleaf.net!utzoo!watmath!clyde!burl!ulysses!bellcore!decvax!decwrl!pyramid!hplabs!tektronix!reed!omen!caf
From: caf@omen.UUCP
Newsgroups: net.micro.pc
Subject: Re: More info on porting MicroEmacs 3.5
Message-ID: <341@omen.UUCP>
Date: Fri, 23-May-86 01:50:25 EDT
Article-I.D.: omen.341
Posted: Fri May 23 01:50:25 1986
Date-Received: Sun, 25-May-86 11:41:27 EDT
References: <2628@yale.UUCP> <23900019@siemens.UUCP>
Reply-To: caf@omen.UUCP (Chuck Forsberg WA7KGX)
Organization: Omen Technology, Portland
Lines: 59