Re: i386 misassembly?

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: i386 misassembly?

Alan Modra
On Mon, Oct 31, 2005 at 06:18:09PM -0800, Eric Christopher wrote:
> 00000000 <.text>:
>    0:   de f1                   fdivp  %st,%st(1)
>
> I was reading the manual (vol 2a) and it looks like this is supposed  
> to assemble as de f9,
> am I nuts or reading something wrong?

See the comment at the start of include/opcode/i386.h.  gcc is nuts.  :)

--
Alan Modra
IBM OzLabs - Linux Technology Centre
Reply | Threaded
Open this post in threaded view
|

Re: i386 misassembly?

Eric Christopher-2

On Oct 31, 2005, at 6:36 PM, Alan Modra wrote:

> On Mon, Oct 31, 2005 at 06:18:09PM -0800, Eric Christopher wrote:
>> 00000000 <.text>:
>>    0:   de f1                   fdivp  %st,%st(1)
>>
>> I was reading the manual (vol 2a) and it looks like this is supposed
>> to assemble as de f9,
>> am I nuts or reading something wrong?
>
> See the comment at the start of include/opcode/i386.h.  gcc is  
> nuts.  :)

Gar.

Ooookay. So, what does this mean to the processor? I mean, the
assembly is kinda wrong yes?

-eric
Reply | Threaded
Open this post in threaded view
|

Re: i386 misassembly?

Alan Modra
On Mon, Oct 31, 2005 at 10:17:18PM -0800, Eric Christopher wrote:

>
> On Oct 31, 2005, at 6:36 PM, Alan Modra wrote:
>
> >On Mon, Oct 31, 2005 at 06:18:09PM -0800, Eric Christopher wrote:
> >>00000000 <.text>:
> >>   0:   de f1                   fdivp  %st,%st(1)
> >>
> >>I was reading the manual (vol 2a) and it looks like this is supposed
> >>to assemble as de f9,
> >>am I nuts or reading something wrong?
> >
> >See the comment at the start of include/opcode/i386.h.  gcc is  
> >nuts.  :)
>
> Gar.
>
> Ooookay. So, what does this mean to the processor? I mean, the
> assembly is kinda wrong yes?

All the processor cares about is the 0xDEF1, which is "Divide ST(0) by
ST(1), store result in ST(1), and pop the register stack."

--
Alan Modra
IBM OzLabs - Linux Technology Centre
Reply | Threaded
Open this post in threaded view
|

Re: i386 misassembly?

Eric Christopher-2

On Oct 31, 2005, at 11:21 PM, Alan Modra wrote:

> On Mon, Oct 31, 2005 at 10:17:18PM -0800, Eric Christopher wrote:
>>
>> On Oct 31, 2005, at 6:36 PM, Alan Modra wrote:
>>
>>> On Mon, Oct 31, 2005 at 06:18:09PM -0800, Eric Christopher wrote:
>>>> 00000000 <.text>:
>>>>   0:   de f1                   fdivp  %st,%st(1)
>>>>
>>>> I was reading the manual (vol 2a) and it looks like this is  
>>>> supposed
>>>> to assemble as de f9,
>>>> am I nuts or reading something wrong?
>>>
>
> All the processor cares about is the 0xDEF1, which is "Divide ST(0) by
> ST(1), store result in ST(1), and pop the register stack."

But shouldn't it be assembling as de f9 instead of de f1? I thought  
fdivrp was
de f1?

-eric
Reply | Threaded
Open this post in threaded view
|

Re: i386 misassembly?

Eric Christopher-2
>
> But shouldn't it be assembling as de f9 instead of de f1? I thought  
> fdivrp was
> de f1?

Nevermind, Ian explained the wackiness to me.

-eric
Reply | Threaded
Open this post in threaded view
|

Re: i386 misassembly?

Alan Modra
In reply to this post by Eric Christopher-2
On Tue, Nov 01, 2005 at 09:34:33AM -0800, Eric Christopher wrote:
> But shouldn't it be assembling as de f9 instead of de f1? I thought  
> fdivrp was
> de f1?

That's what the following is about.

#if SYSV386_COMPAT
/* Someone forgot that the FloatR bit reverses the operation when not
   equal to the FloatD bit.  ie. Changing only FloatD results in the
   destination being swapped *and* the direction being reversed.  */
#define FloatDR FloatD
#else
#define FloatDR (FloatD|FloatR)
#endif

--
Alan Modra
IBM OzLabs - Linux Technology Centre
Reply | Threaded
Open this post in threaded view
|

Re: i386 misassembly?

Eric Christopher-2

On Nov 1, 2005, at 2:15 PM, Alan Modra wrote:

> On Tue, Nov 01, 2005 at 09:34:33AM -0800, Eric Christopher wrote:
>> But shouldn't it be assembling as de f9 instead of de f1? I thought
>> fdivrp was
>> de f1?
>
> That's what the following is about.
>
> #if SYSV386_COMPAT
> /* Someone forgot that the FloatR bit reverses the operation when not
>    equal to the FloatD bit.  ie. Changing only FloatD results in the
>    destination being swapped *and* the direction being reversed.  */
> #define FloatDR FloatD
> #else
> #define FloatDR (FloatD|FloatR)
> #endif

Thanks. After Ian explained I gathered that too. :)

-eric