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.