Date: Fri, 27 Apr 2001 09:51:55 +0300 (EET DST)
From: Esa A E Peuha <peuha AT cc DOT helsinki DOT fi>
Sender: <peuha AT sirppi DOT helsinki DOT fi>
To: djgpp workers list <djgpp-workers AT delorie DOT com>
Subject: Re: sbrk() storing the size of memory blocks
In-Reply-To: <Pine.LNX.4.10.10104261414430.592-200000@acp3bf>
Message-ID: <Pine.OSF.4.30.0104270824300.13482-100000@sirppi.helsinki.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Reply-To: djgpp-workers AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

On Thu, 26 Apr 2001, Hans-Bernhard Broeker wrote:

> [Attached, you'll find another patch that adds lots of comments to crt0.S.
> I wrote those as I dug my way through all this assembly, I could see
> what's happening. May be useful for others who want to work on this,
> later...]

Please don't send anything as attachments; with many email programs,
it appears to be nearly impossible to send even plain text attachments
unencoded, and many programs won't allow to include attachments with
the main body of text when replying.

> Content-Type: TEXT/PLAIN; charset=US-ASCII; name="crt0.S.commenting.diff"
> Content-Transfer-Encoding: BASE64
> Content-ID: <Pine DOT LNX DOT 4 DOT 10 DOT 10104261430450 DOT 592 AT acp3bf>

I knew that some braindead M$ programs will happily encode us-ascii in
base64, but I didn't think that Pine would do so.  It would be easy to
calculate how much base64 and quoted-printable will bloat any given
attachment and pick the smaller one (for plain text that would be qp,
which is readable even undecoded), but no program seems to bother...

> --- nimrod.c	Wed Apr 11 00:48:06 2001
> +++ dpmiexcp.c	Thu Apr 26 04:05:12 2001
> @@ -248,6 +248,13 @@
>  	  if (mem_block_list[j].address - mem_block_list[i].address < mem_block_list[i].size)
>  	    mem_block_list[i].size = mem_block_list[j].address - mem_block_list[i].address;
>
> +#ifndef DONT_STORE_BLOCKSIZES
> +  /* Get the base addresses, and size */
> +  for (i = 0; i < num_mem_blocks; i++)
> +  {
> +    mem_block_list[i].size = __djgpp_memory_handle_list[i].size;
> +  }
> +#else
>    /* Now try the DPMI call; if it works, we can override the previous
>     * data; however, I have yet to find a DPMI server that supports it
>     */
> @@ -258,7 +265,7 @@
>      if (__dpmi_get_memory_block_size_and_base (&info) != -1)
>        if (info.size) mem_block_list[i].size = info.size;
>    }
> -
> +#endif /* DONT_STORE_BLOCKSIZES */
>    return num_mem_blocks;
>  }
>

You don't ifdef away enough of the code. :-)  The line

   mem_block_list[i].size = __djgpp_memory_handle_list[i].size;

should be in the same for loop as

   mem_block_list[i].address = __djgpp_memory_handle_list[i].address;

and *all* the code that modifies mem_block_list[i].size after that
should disappear.

BTW, do you intend to leave the DONT_STORE_BLOCKSIZES ifdefs in the
final code?  I don't think that would be very useful.

> +#if 0
>  	addl	$4, %edi		/* FIXME: checks stored *base* ??? */

Do we really need the "#if 0"'d part here, or anywhere else in crt0.S?
These unused sections are available in CVS, if anyone should need them,
and crt0.S certainly wouldn't be too easy to read even without them. :-)

> +#ifndef DONT_SAVE_BLOCKSIZES

This (and the other one) should probably be DONT_STORE_BLOCKSIZES.

-- 
Esa Peuha
student of mathematics at the University of Helsinki
http://www.helsinki.fi/~peuha/