cvs commit: src/sys/amd64/amd64 support.S

[Kostik Belousov]

On Tue, Aug 15, 2006 at 09:34:46PM +0800, David Xu wrote:
> On Tuesday 15 August 2006 21:13, John Baldwin wrote:
> > On Tuesday 15 August 2006 08:45, David Xu wrote:
> > > davidxu     2006-08-15 12:45:51 UTC
> > >
> > >   FreeBSD src repository
> > >
> > >   Modified files:
> > >     sys/amd64/amd64      support.S
> > >   Log:
> > >   Because fuword on AMD64 returns 64bit long integer -1 on fault, clear
> > >   entire %rax to zero instead of only clearing %eax, otherwise it will
> > >   leave garbage data in upper 32 bits.
> >
> > Are you sure that 'xorl %eax,%eax' doesn't actually clear all 64 bits? 
> > This practice of just using xorl rather than xorq is all over the place in
> > the amd64 code, and I think I've even seen gcc generate it, so I'm guessing
> > that the xorl actually is a xorq.
> 
> >From my understanding, they are different.
> 
> before my change, generated binary code:
> 
> 0000000000003ba0 <fusufault>:
>     3ba0:       65 48 8b 0c 25 20 00    mov    %gs:0x20,%rcx
>     3ba7:       00 00
>     3ba9:       31 c0                   xor    %eax,%eax
>     3bab:       48 89 81 a8 02 00 00    mov    %rax,0x2a8(%rcx)
>     3bb2:       48 ff c8                dec    %rax
>     3bb5:       c3                      retq
>     3bb6:       66                      data16
>     3bb7:       66                      data16
>     3bb8:       66                      data16
> 
> =======================================
> after this change:
> 
> 0000000000003ba0 <fusufault>:
>     3ba0:       65 48 8b 0c 25 20 00    mov    %gs:0x20,%rcx
>     3ba7:       00 00
>     3ba9:       48 31 c0                xor    %rax,%rax
>     3bac:       48 89 81 a8 02 00 00    mov    %rax,0x2a8(%rcx)
>     3bb3:       48 ff c8                dec    %rax
>     3bb6:       c3                      retq
> 
> 
> I have only checked fuword while I am working on userland mutex
> priority propagating, I have not checked suword and others yet.

From the IA32 Software Developer Manual, 3.4.1.1:

When in 64-bit mode, operand size determines the number of valid bits in
the destination general-purpose register:

   64-bit operands generate a 64-bit result in the destination
general-purpose register.

   32-bit operands generate a 32-bit result, zero-extended to a 64-bit
result in the destination general-purpose register.

So, it seems that xorq %rax, %rax and xorl %eax, %eax will make the
same results, but in the different ways. And xorq requires REX prefix,
that shall make the decoding longer.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/cvs-src/attachments/20060815/43c2c1c3/attachment.pgp