From:	Richard Dawe <richdawe AT bigfoot DOT com>
Newsgroups:	comp.os.msdos.djgpp
Subject:	Re: Inline asm: lcall & various binutils versions
Date:	Wed, 31 May 2000 22:06:59 +0100
Organization:	Customer of Planet Online
Lines:	34
Message-ID:	<39357EF3.68F1A575@bigfoot.com>
References:	<Pine DOT UW2 DOT 3 DOT 95 DOT 1000531092156 DOT 22132A-100000 AT bryggen DOT bgnett DOT no>
NNTP-Posting-Host:	modem-27.erythromycin.dialup.pol.co.uk
Mime-Version:	1.0
X-Trace:	news7.svr.pol.co.uk 959808780 30987 62.136.93.27 (31 May 2000 21:33:00 GMT)
NNTP-Posting-Date:	31 May 2000 21:33:00 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.

Gisle Vanem wrote:
> 
> Richard Dawe <richdawe AT bigfoot DOT com> said:
> 
> > I took a look at this problem at the weekend and I couldn't find a way
> > to avoid this syntax. I tried loading the selector into es and then
> > referencing the offset's memory location, like so:
> >
> > lcall %%es:_myoffset
> 
> How about something like this:
> 
>  __dpmi_paddr entry;
>  entry.selector = your_selector;
>  entry.offset = func_offset;
>  __asm__ __volatile__ (
>           "lcall (%%edi)"
>           :: "D" (&entry) );
> 
> I've used this in a BIOS32 service module.

I confess that I don't really know assembly. This seems to be what I was
trying to do. I'll give it a try at the weekend.

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?

Thanks! Bye,

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

- Raw text -