dhp@ihlpa.ATT.COM (Douglas H. Price) (12/22/87)
Well folks, THE PROBLEM rears its ugly head again. I am attempting to bring
up elm 1.7 under xenix, and the usual 286 difficulties have occurred.
Flame 1. Here is another example of the-world-is-a-vax code. As much as I
like flat address spaces, I accept the existence of non-flat address
space machines (much like I am forced to accept the possibility of
nuclear war). Moral: USE LINT! Integers are not necessarily the
size of pointers!
Flame 2. The stack is allocated in the same segment as static data in large
model! This is penny-wise and pound-foolish. Sure is speeds up execution,
but only if you have enough stack space left over to run the program
at all!
Flame 2a. I know, I KNOW we have talked about this before, but why didn't
INTEL make the 286 architecture so that you could FAKE a larger
linear addres space by making segment addressing contiguous! It
would have saved us all alot of headaches. As it is, even if you
had an entire 64K of stack, many existing programs would still
bite the dust for lack of stack space!
So, we come to the question: How do I allocate the stack in a separate segment
so that it has room to grow? Elm uses up too much of the static segment as
it is to permit the stack and static data to coexist.
I have tried:
/bin/ld -P: Normally, alike named segments are packed into as few physical
segments as possible. The -P option disables this. There are
approximately 40 modules in elm, so I ended up with 40 sparsely
populated TEXT segments. The DATA segements were not affected.
Dead end.
cc -ND _DATA2 This resets the name of the default data segment to _DATA2.
It built correctly, but the program blew up with a segment
violation in the first system library routine executed (getenv()).
Apparently, this breaks down due to the Flame 2 assumption that
DS register == SS register in the compiled library code.
cc -M2ld The Md option disables the DS == SS assumption in the compiled
code. But, it turns out that for some reason it is mutually
exclusive with the -ND option above. /bin/cc will refuse to
accept it.
I assume that I might be able to play some game with the location of the stack
through the use of declarations in the assembler, but I suspect I am going to
be shot in the foot by /lib/libc no matter what I do. Suggestions?
--
Douglas H. Price
Analysts International Corp.
@ AT&T Bell Laboratories
..!ihnp4!ihlpa!dhpchip@ateng.UUCP (Chip Salzenberg) (12/23/87)
In article <6596@ihlpa.ATT.COM> dhp@ihlpa.ATT.COM (Douglas H. Price) writes: >Well folks, THE PROBLEM rears its ugly head again. I am attempting to bring >up elm 1.7 under xenix, and the usual 286 difficulties have occurred. I have a set of patches to make Elm 1.7 Beta compile under Xenix. If enough people show interest, I'll post them. (Oh boy, there goes my mailbox again!) In the meantime, you can compile all modules with "cc -LARGE -Ml2t63". The `t63' means "any data item larger than 63 bytes gets its own segment." This makes a lot of segments, but it leaves enough room in DGROUP for your 16K stack. (That's "-F 4000" when linking.) -- Chip Salzenberg "chip@ateng.UUCP" or "{codas,uunet}!ateng!chip" A T Engineering My employer's opinions are not mine, but these are. "Gentlemen, your work today has been outstanding, and I intend to recommend you all for promotion -- in whatever fleet we end up serving." - JTK
dws@cseg.UUCP (David W. Summers) (12/31/87)
In article <132@ateng.UUCP>, chip@ateng.UUCP (Chip Salzenberg) writes: > In article <6596@ihlpa.ATT.COM> dhp@ihlpa.ATT.COM (Douglas H. Price) writes: > >Well folks, THE PROBLEM rears its ugly head again. I am attempting to bring > >up elm 1.7 under xenix, and the usual 286 difficulties have occurred. > > I have a set of patches to make Elm 1.7 Beta compile under Xenix. If > enough people show interest, I'll post them. (Oh boy, there goes my > mailbox again!) > I'm definitely interested in patches to make ELM 1.7 Beta compile under Xenix. Please post them or E-mail them to me! Thanks in advance! - David Summers ..!rutgers!pbox!romed!actsn!cseg!dws ..!ihnp4!okstate!romed!actsn!cseg!dws
shocking@nswitgould.OZ (Stephen Hocking) (01/04/88)
in article <6596@ihlpa.ATT.COM>, dhp@ihlpa.ATT.COM (Douglas H. Price) says: > > Much stuff about 286 Xenix stack being stuck in same segment as > data. My solution was to use the -F nnnnn flage to ld (or cc depending on taste) when porting xlisp, which likes to use the heap, which is also in the same segment as the stack... What you do is have nnnn as large as possible, which forces the linker to stuff the stack into a seperate segment. Start off at 64k (well, you have to specify it in hex) and work your way down until you stop getting the not enuff core message. This seems to work ;^). Best of luck Stephen -- "Lay orf Arfur, 'e doesnt know wot 'es saying" UUCP.net: {ukc,uunet}!munnari!nswitgould.oz!shocking ACS.net: shocking@nswitgould.oz {ARPANET,BITNET}: Who knows?