Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!mcvax!ukc!reading!onion!riddle!domo
From: domo@riddle.UUCP (Dominic Dunlop)
Newsgroups: comp.sys.ibm.pc
Subject: Re: Large linear memory space for 80x86 machines ?
Message-ID: <504@riddle.UUCP>
Date: Mon, 26-Oct-87 15:30:36 EST
Article-I.D.: riddle.504
Posted: Mon Oct 26 15:30:36 1987
Date-Received: Wed, 4-Nov-87 04:42:27 EST
References: <668@rna.UUCP>
Reply-To: domo@riddle.UUCP (Dominic Dunlop)
Organization: Sphinx Ltd., Maidenhead, England
Lines: 62
Summary: 386 UNIX implementations can do it

In article <668@rna.UUCP> dan@rna.UUCP (Dan Ts'o) writes:
>I want to write a (semi-real-time) C program that uses single data arrays that
>are 2-8Mb each. What about...
>
>	- Running Xenix with protecte mode, possibility on a '386. Do any
>current or planned implementation of Xenix support such large linear address
>spaces ? How about virtual memory support ?

Having Compaq 386 machines running both Xenix/386 (release 2.2.1) and
386/ix (release 1.0.3) handy, I threw the following trivial program at
them:

char	blunge[0x400000];	/* 4 megabytes */

main()
{
	register char *bp;

	for (bp = blunge;
	     bp < blunge + sizeof blunge / sizeof *blunge;
	     bp++)
		*bp = (unsigned) bp & 0xff;
}

Both ran it.  When I upped the array size to 8 megabytes, 386/ix still ran
it, but XENIX complained (``cannot run...''), I suspect because it was too
large.  As the XENIX system had two megs of RAM, against six for 386/ix, I
don't think this is unreasonable.  In any event, maximum user process size
is sysgenable on both systems, and both will refuse to run programs if
there's a chance they may run out of swap.  The only difference is that
XENIX is very liable to panic if it runs out of swap, whereas 386/ix (and
V.3 in general) just whistles nonchalantly, in the hope that the problem
will resolve itself (which it generally does).

Getting bolder, I made blunge into a local variable inside main().  This
makes 386/ix dump core, and crashes XENIX (which, not knowing the root
password, I can't reboot successfully -- boy, am I going to be popular
tomorrow...).  For good measure, I tried it on a 3B2/400 (UNIX V,
release 3.0.2, four megs RAM).  It would run with a 4 meg external array,
and a 4 meg stack array, refused to run with an 8 meg external array, and
dumped core with an 8 meg stack array.  To summarise this lot:

				4 meg	4 meg	8 meg	8 meg
				extern	auto	extern	auto
				------  -----   ------  -----
3B2/400, 4 meg, UNIX V.3	runs	runs	no run	core

Compaq 386, 6 meg, 386/ix	runs	core	runs	core

Compaq 386, 2 meg, XENIX/386	runs	panic	no run	?

In short, the 386 UNIX implementations will do what you want, but you'd
better make your arrays external, not local (auto).  I strongly suspect
that the cause of the core dumps with auto variables is the
attempt to build a stack frame with stuff on it which is so far from the
last valid page allocated to the stack that the kernel thinks there's
something screwy going on when an attempt is made to reference it.  I'm
probably going to be accused of being mean and nasty to have tried anything
so unreasonable in the first place.

Dominic Dunlop
domo@riddle.uucp   domo@sphinx.co.uk