From: Richard Dawe 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: NNTP-Posting-Host: modem-108.amantadine.dialup.pol.co.uk Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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/