Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!lll-lcc!ames!ucbcad!ucbvax!BRAHMS.BERKELEY.EDU!ballou
From: ballou@BRAHMS.BERKELEY.EDU (Kenneth R. Ballou)
Newsgroups: comp.unix.xenix
Subject: Re: sbrk in Xenix
Message-ID: <8705040618.AA10741@brahms.Berkeley.EDU>
Date: Mon, 4-May-87 02:18:10 EDT
Article-I.D.: brahms.8705040618.AA10741
Posted: Mon May  4 02:18:10 1987
Date-Received: Tue, 5-May-87 00:44:23 EDT
References: <5816@shemp.UCLA.EDU> <203@cascabel.UUCP>
Sender: daemon@ucbvax.BERKELEY.EDU
Reply-To: brahms.Berkeley.EDU!ballou@brahms.Berkeley.EDU (Kenneth R. Ballou)
Distribution: world
Organization: Math Dept. UCB
Lines: 61

In article <203@cascabel.UUCP> kelvin@cascabel.UUCP (Kelvin Nilsen) writes:
>
>... When
>writing Large or Huge memory model program, sbrk is able to return
>more than 64K of memory to the user program.  however, the allocated
>data is not necessarily contiguous.

	Wait, just how can that be?  Unless something has changed
*dramatically* (I am looking at the manual for version 2.1.3), the argument to
sbrk is declared as type int.  This means that it is a signed 16 bit quantity,
between -32K and 32K-1.  How then can one request more than 32K at one time
with sbrk?

	Moreover, the manual entry states quite clearly that "in large model
programs, if the argument is greater than the number of unallocated bytes
remaining in the current data segment, sbrk automatically allocates all the
requested bytes in a new data segment.  This guarantees that the requested
bytes will reside entirely in one segment.

>				  this was a great inconvenience to
>us, 

	... and to anybody who tries to port a program with large
data structures/arrays to the 80286.  (Sometimes I really can't answer
the question of why I like programming for the chip.)

>so we complained to SCO about the feature.  their response was that
>it was not their fault, but Intel's.  They suggested we wait for 
>Xenix-386.

	Well, it wasn't the most helpful suggestion, but it really
isn't their fault.  What are their options?

	1.  Have a nonstandard sbrk call which takes a long as its argument.
This new sbrk would return memory in consecutive segments.  Yet you still
have to be using the huge model for your code, since the address space is
still not linear.  (Although I suppose I can understand that it is faster for
the hardware to have the global/local and DPL bits in the low three bits of
the descriptor, I still claim that there was an opportunity of finally having
a linear address space by putting these bits in the high bits of the
descriptor.  Then any carry from offset to segment would have simply referred
to the next segment.  No flames, please; I really don't understand such things
that well, and it would not surprise me to find that this would extract a
horrible performance penalty.  However, if anyone would care to enlighten me,
...

>
>unlike real Unix on a VAX, for example, "sbrk(0) does not necessarily
>return the starting address of the next sbrk call."  makes it kind
>of hard to allocate using brk().

True.  One kludge would be to allocate the remaining bytes in the current
segment.  Then, allocate in some even part of 64K bytes.  Then, sbrk(0)
would work.

>i just noticed a man page for brkctl which seems to give a little more
>explicit control over where memory is allocated from.

	Perhaps you should notice a bit further that there is a very definite
warning about using the brkctl system call in small and middle model programs
only.