X-Authentication-Warning: delorie.com: mailnull set sender to djgpp-workers-bounces using -f
From: sandmann AT clio DOT rice DOT edu (Charles Sandmann)
Message-Id: <10202112024.AA29687@clio.rice.edu>
Subject: Re: Alignment problem
To: eliz AT is DOT elta DOT co DOT il
Date: Mon, 11 Feb 2002 14:24:55 -0600 (CST)
Cc: djgpp-workers AT delorie DOT com, rudd AT cyberoptics DOT com
In-Reply-To: <5137-Mon11Feb2002215541+0200-eliz@is.elta.co.il> from "Eli Zaretskii" at Feb 11, 2002 09:55:41 PM
X-Mailer: ELM [version 2.5 PL2]
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
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

> > If it returns an address which isn't aligned it gets a bit ugly.
> > I suggest we sbrk() another 1-7 bytes at that point hoping it will be 
> > contig at the end of the current allocation.
> 
> Why not simply throw out those 7 bytes (in practice, probably just 4
> bytes, since Windows and CWSDPMI align on 4-byte boundary), by finding
> the next 8-byte aligned address, and starting to work from there.

We compute the size we want today, and sbrk() it.  If it returns 
unaligned quite often we don't have any additional bytes to discard
from the sbrk().  That's why I suggested the tiny additional sbrk().
Windows and CWSDPMI (and almost all DPMI providers) will provide 
DPMI blocks on page boundaries, and sbrk() does sizes in 64Kb chunks,
and malloc only asks for items in 8byte chunks, so I think a 1-7 byte
request would always be in the same memory zone, and right after the
original request (which would allow us to align shift up a few bytes).

If we are near an sbrk() boundary (different memory zone) then the extra 
few bytes might not be satisfied at the end - but this is only if the
logic above is messed up...

> Since malloc rounds the size to a multiple of 8 bytes, the rest should
> be fine as long as we get contiguous memory.  Whenever we get
> noncontiguous chunk, we can again align its beginning and continue.

Agreed.  (This is all in one place - probably 2-3 lines of code).

Another idea:

We could add a sbrk(0) call before calling sbrk() with the expected 
size - and if it's aligned the sbrk() value should be also.  If
sbrk(0) not aligned, we sbrk() the small number of bytes to align - 
which will always work (unless there's a equality bug right at the
boundary in sbrk...)

A new DPMI block allocation is always aligned (pmode may only be
paragraph aligned instead of page, but that should be good enough).

By the way, I think the reason we are off by 4 is stubinfo is 0x54 
bytes and it's the very first thing we sbrk() :-P