From:	Richard Dawe <richdawe AT bigfoot DOT com>
Newsgroups:	comp.os.msdos.djgpp
Subject:	Re: Inline asm: lcall & various binutils versions
Date:	Thu, 01 Jun 2000 22:44:56 +0100
Organization:	Customer of Planet Online
Lines:	28
Message-ID:	<3936D958.20A71094@bigfoot.com>
References:	<Pine DOT SUN DOT 3 DOT 91 DOT 1000601092740 DOT 17554F-100000 AT is>
NNTP-Posting-Host:	modem-108.amantadine.dialup.pol.co.uk
Mime-Version:	1.0
X-Trace:	newsg3.svr.pol.co.uk 959896689 30215 62.136.77.108 (1 Jun 2000 21:58:09 GMT)
NNTP-Posting-Date:	1 Jun 2000 21:58:09 GMT
X-Complaints-To:	abuse AT theplanet DOT net
X-Mailer:	Mozilla 4.51 [en] (X11; I; Linux 2.2.14 i586)
X-Accept-Language:	de,fr
To:	djgpp AT delorie DOT com
DJ-Gateway:	from newsgroup comp.os.msdos.djgpp
Reply-To:	djgpp AT delorie DOT com

Hello.

Eli Zaretskii wrote:
> 
> On Wed, 31 May 2000, Richard Dawe wrote:
> 
> > BTW the __dpmi_paddr structure isn't padded. None of the structures in
> > dpmi.h seem to be. I wonder if they should be, perhaps for DJGPP 2.04?
> 
> What for?  What are the problems with them being unpadded?
> 
> (Btw, nothing prevents the compiler from padding them at will, and I
> think it actually will do that.  Did you look at sizeof(__dpmi_paddr)?)

No, I haven't looked at sizeof(__dpmi_paddr). My concern is that gcc could
pad between offset32 and selector, to align the data and increase access
speed. Clearly this will call the lcall to behave badly. I'm not bothered
about padding at the end - clearly this will have no effect.

[ My copy of K&R is at work, so maybe I misremember how padding works. If
it pads only at the end, then we have no problem, but ISTR that padding
can be added in the middle to improve alignment. ]

Bye,

-- 
Richard Dawe
richdawe AT bigfoot DOT com ICQ 47595498 http://www.bigfoot.com/~richdawe/

- Raw text -