Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!cuae2!ihnp4!aicchi!ignatz
From: ignatz@aicchi.UUCP (Ihnat)
Newsgroups: net.lang.c,net.unix
Subject: Re: Microport and SCO Xenix Memory Managment Problems
Message-ID: <832@aicchi.UUCP>
Date: Fri, 24-Oct-86 17:26:58 EDT
Article-I.D.: aicchi.832
Posted: Fri Oct 24 17:26:58 1986
Date-Received: Sat, 25-Oct-86 07:09:49 EDT
References: <646@chinet.UUCP> <4004@amdahl.UUCP>
Reply-To: ignatz@aicchi.UUCP (Ihnat)
Organization: Analysts International Corp; Chicago Branch
Lines: 80
Keywords: sbrk, brk, 286, memory managment, Microport, SCO Xenix
Xref: watmath net.lang.c:10813 net.unix:9687
Summary: Yes, I knew what I was saying

I recently posted a bit to the net about the apparently anomalous behavior
of sbrk() under Microport Sys V and Xenix.  I have, as you might guess,
received a number of responses to both the primary item in my original
posting, and to some incidental comments I made.  Possibly the simplest
item to address is the observation made in article <4004@amdahl.UUCP>
by Andrew Sharpe on my comment that the value returned isn't to be considered
more than a marker:

	This is not quite correct. The System V/286 version (for sbrk(0)
	in large model) will return a memory location that is the
	_beginning_ of the next segment, so that the pointer may be
	remembered and used later after an sbrk(+n). 

He goes on to comment that they worked quite hard to emulate the Vax behavior,
(which I'm sure they did), and that he hopes that Microport didn't change
anything; and I'm sure they did not.  I simply repeated a caveat in the
man page that warned the user not to consider this address to be something
the program can use in address calculations, because it won't be meaningful
in terms of contiguous memory address calculations with previous values
returned by calls to sbrk().  In light of this fact, no program with claims
to portability should consider the returned value anything more than a
"magic cookie" to be passed to subsequent sbrk(+/- n) calls.

Now, as to the other responses I've received via mail...I'd truly forgotten
how rapidly people can type; often long before the brain can engage.  There's
some line noise somewhere between the brain and fingers of some people
that translates into sarcastic and abusive aspersions on the intelligence,
experience, and professional competence of the target (me).  Now, mind
you, I did receive intelligent, well-written queries that simply asked
if I knew the problems inherent in a memory architecture implemented on
a segmented machine, with a memory managment unit that doesn't lend itself
to a flat address space.  I just want some of the apparently technically
competent people who sent the *other* type of response to be aware that
you can question someone else's conclusions or statements without turning
it into a contest of egos or a professional challenge.

Now...back to issues.  Yes, I *do* know the problems with the 286, and
segmented architecture, and the screwy memory managment addressing.  I
know just how hard it is/would be to recreate the flat address space that
the traditional sbrk() attempted to provide.  However, it can be done,
and must be if the portable operating system standard is to be followed.
No, every reference need not be checked; the huge model Microsoft compiler
generates inline code to build the segment/offset reference on the fly,
and it's not "500 times slower" than the corresponding small model that
assumes that references are within the current 64K segment.  It's
more inefficient, certainly; but it works well enough to use.

I definitely think that the 286 architecture could have used some more
thought when it was designed--say, put those two mode bits in the high-
order bits of the segment, instead of the low end, and then provide a
memory incrementing scheme that allowed the offset increment overflow to
bump the associated segment; you could then easily have modelled a flat
contiguous address space.  But working with what we've got, it would make
sense to offer a version that either follows the Xenix model--allocates
increments in the current segment until the request would go off the end--
or jumps to a new segment, but guarantees that all addresses from the
old break value to the new segment are actually mapped to valid real
memory.  It would then be the responsibility of the compiler, or the
programmer, not to fall into the 64K offset wraparound trap; but at least
you could count on contiguous addresses.  (Yes, I know--contiguous meaning
you go from offset 0-64K, then increment the upper 14 bits of the segment
while preserving the two mode bits...)

I didn't really want to go into a discussion of the whole issue; I assumed
that anyone reading the original posting would realize that I understood
the issues, and was pointing out that the model, as implemented, changed
the basic assumptions of the "classic" Unix brk()/sbrk() behavior; and,
particularly, clobbers the traditional shell stack allocation method.
Oh, well...I'll individually answer the people who were either kind enough
to write decent letters, or were hasty enough to write flames.  But this
is my "technical" explanation.  I don't intend to say anything more on
the net about this; please mail to me if you wish to express any other
opinions or ideas.  Of course, if something truly significant is brought
up, I'll summarize, but otherwise, this is really an issue that's probably
run its course in terms of net discussion.
-- 
	Dave Ihnat
	Analysts International Corporation
	(312) 882-4673
	ihnp4!aicchi!ignatz || ihnp4!homebru!ignatz