From: "Charles Sandmann" Newsgroups: comp.os.msdos.djgpp Subject: Re: Linear addressing using brk() and sbrk() Date: Sun, 4 Jul 1999 15:21:13 Organization: Aspen Technology, Inc. Message-ID: <377f7be9.sandmann@clio.rice.edu> References: NNTP-Posting-Host: ptdemo.aco.aspentech.com X-NewsEditor: ED-1.5.8 Lines: 52 To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Reply-To: djgpp AT delorie DOT com > I want to be able to specify a fixed memory location at which I > will place the binary image so that the Forth's internal > addressing can be done with absolute (linear) addresses. I know > this can be done using DPMI virtual addressing. It can also be > done in Linux and Win98 using specific system calls. > > Question 1: Is there a way to do it using malloc? I think not. If you allocate the memory with either sbrk() or direct DPMI calls you can set the fixed memory address using new selectors with the appropriate base address. This is how DJGPP actually works. It starts it's images at "0" memory (even though the interrupt table lives there) using the magic of selectors. But as you note earlier, DPMI calls won't be portable, but using sbrk() with the unixy flag is pretty close to portable. > Question 2: Is there a way to place a separate heap at a fixed > (linear) address using brk or sbrk? The answer to that is "it depends". You might need to waste some memory to do it, use the selector magic above, and do you need a linear looking address space which assumes ES=DS=SS (probably want to avoid selectors to be porable?)? You could use the trick we used for Aout format in early DJGPP, which assumed the total amount of executable code was less than 4Mb and data started at 4Mb. Lots of potential tricks. > Question 3: Is it very bad to do the following? > > unsigned desired_address = 0x100000; > unsigned desired_size = 0x80000; > if(sbrk((void *)desired_address - sbrk(0)) == (void *)-1) { > printf("Can't adjust brk to %X\n", desired_address); > return memory_error1; > } > if(sbrk(desired_size) == (void *)-1) { > printf("Can't allocate %X bytes for image\n", > desired_size); > return memory_error2; > } There needs to be a lot more protection here, and there are some worries about wasting memory and/or overlaps. If those are not concerns, this is fine, but it might mess up the alignment of malloc calls, which is just a performance issue. > And what happens when I malloc some more memory? How do I keep > the heap from overlapping desired_address ? sbrk() manages the memory so you don't overlap. But using the non-unixy sbrk may give you some unexpected behavior above, so if you are playing these games you need to set the unixy sbrk bit.