delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1999/07/04/17:35:28.1

From: "Charles Sandmann" <sandmann AT clio DOT rice DOT edu>
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: <ehYc3.1130$Dl DOT 33483 AT news DOT clear DOT net DOT nz>
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.

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019