[comp.unix.xenix] sbrk in Xenix

dberry@CS.UCLA.EDU (05/02/87)

If I understand the documentation correctly sbrk allocates within
_DATA. Is this correct? How can I increase the amount that I am able
to sbrk? is there anyway to change which segment it works off of?
does -F affect the space that this has available?

thanks
Dan

kelvin@cascabel.UUCP (Kelvin Nilsen) (05/03/87)

> If I understand the documentation correctly sbrk allocates within
> _DATA. Is this correct? How can I increase the amount that I am able
> to sbrk? is there anyway to change which segment it works off of?
> does -F affect the space that this has available?
> 
> thanks
> Dan

we ran into some problems with this in porting Icon to Xenix.  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.  this was a great inconvenience to
us, 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.

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().

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

good luck,
-- 

kelvin nilsen

UUCP: {ut-sally,seismo,mit-eddie,gatech,cbosgd}!ihnp4!arizona!cascabel!kelvin 
INTERNET: cascabel!kelvin@arizona.edu

ballou@BRAHMS.BERKELEY.EDU (Kenneth R. Ballou) (05/04/87)

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.