Keir, just noticed the macro:
#define __DECL_REG(name) union { uint64_t r ## name, e ## name; }
So, rax and eax are both 64bit, but I think we''d better define eax to
32bit, how do you think?
-Xin
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
And I don''t think it can work for none GCC compiler, since we use eax
from time to time :-(
#ifdef __GNUC__
/* Anonymous union includes both 32- and 64-bit names (e.g., eax/rax). */
#define __DECL_REG(name) union { uint64_t r ## name, e ## name; }
#else
/* Non-gcc sources must always use the proper 64-bit name (e.g., rax). */
#define __DECL_REG(name) uint64_t r ## name
#endif
Am I right?
-Xin
>-----Original Message-----
>From: xen-devel-bounces@lists.xensource.com
>[mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Li, Xin B
>Sent: 2006年12月13日 20:13
>To: Keir Fraser
>Cc: Xen Development Mailing List
>Subject: [Xen-devel] Definition of eax and rax
>
>Keir, just noticed the macro:
>#define __DECL_REG(name) union { uint64_t r ## name, e ## name; }
>So, rax and eax are both 64bit, but I think we''d better define eax
to
>32bit, how do you think?
>-Xin
>
>_______________________________________________
>Xen-devel mailing list
>Xen-devel@lists.xensource.com
>http://lists.xensource.com/xen-devel
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
> -----Original Message----- > From: xen-devel-bounces@lists.xensource.com > [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Li, Xin B > Sent: 13 December 2006 12:13 > To: Keir Fraser > Cc: Xen Development Mailing List > Subject: [Xen-devel] Definition of eax and rax > > Keir, just noticed the macro: > #define __DECL_REG(name) union { uint64_t r ## name, e ## name; } > So, rax and eax are both 64bit, but I think we''d better define eax to > 32bit, how do you think?I believe the purpose of the double-declaration is to have the ability to do generic code that uses eax for both 32- and 64-bit code, avoiding having to write two different pieces of code for 32- and 64-bit code. If you want to use the lower 32-bits of rAX in 64-bit mode, I''d suggest a more explicit way (like casting it to 32-bit size, for exmple). Note also that the x86_64 specification says that a 32-bit write to a 64-bit register should zero-fill the upper 32 bits, which won''t happen if you have : union { uint64_t rax; uint32_t eax } rAX; rAX.eax = 7; You''d end up with whatever was there from before in the upper bits of rAX.rax... -- Mats> -Xin > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel > > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
>> Keir, just noticed the macro: >> #define __DECL_REG(name) union { uint64_t r ## name, e ## name; } >> So, rax and eax are both 64bit, but I think we''d better define eax to >> 32bit, how do you think? > >I believe the purpose of the double-declaration is to have the ability >to do generic code that uses eax for both 32- and 64-bit code, avoiding >having to write two different pieces of code for 32- and 64-bit code. > >If you want to use the lower 32-bits of rAX in 64-bit mode, I''d suggest >a more explicit way (like casting it to 32-bit size, for exmple).Still a little bit confusing if eax is 64bit here :-(, people need keep this in mind when programming on x86_64 xen.> >Note also that the x86_64 specification says that a 32-bit write to a >64-bit register should zero-fill the upper 32 bits, which won''t happen >if you have : > > union { uint64_t rax; uint32_t eax } rAX; > rAX.eax = 7; > >You''d end up with whatever was there from before in the upper bits of >rAX.rax... >Agree! And a little bit hate of the zero-fill. Thanks -Xin _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
>>> "Li, Xin B" <xin.b.li@intel.com> 13.12.06 13:15 >>> >And I don''t think it can work for none GCC compiler, since we use eax from time to time :-( >#ifdef __GNUC__ >/* Anonymous union includes both 32- and 64-bit names (e.g., eax/rax). */ >#define __DECL_REG(name) union { uint64_t r ## name, e ## name; } >#else >/* Non-gcc sources must always use the proper 64-bit name (e.g., rax). */ >#define __DECL_REG(name) uint64_t r ## name >#endifThis is meant to help non-Xen sources including Xen headers. Xen itself is always assumed to be compiled with gcc as I understand it. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
>>> "Li, Xin B" <xin.b.li@intel.com> 13.12.06 13:12 >>> >Keir, just noticed the macro: >#define __DECL_REG(name) union { uint64_t r ## name, e ## name; } >So, rax and eax are both 64bit, but I think we''d better define eax to >32bit, how do you think?The 32on64 patches will add _eax etc. to have a true reflection of 32-bit registers. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> -----Original Message----- > From: Li, Xin B [mailto:xin.b.li@intel.com] > Sent: 13 December 2006 12:31 > To: Petersson, Mats; Keir Fraser > Cc: Xen Development Mailing List > Subject: RE: [Xen-devel] Definition of eax and rax > > >> Keir, just noticed the macro: > >> #define __DECL_REG(name) union { uint64_t r ## name, e ## name; } > >> So, rax and eax are both 64bit, but I think we''d better > define eax to > >> 32bit, how do you think? > > > >I believe the purpose of the double-declaration is to have > the ability > >to do generic code that uses eax for both 32- and 64-bit > code, avoiding > >having to write two different pieces of code for 32- and > 64-bit code. > > > >If you want to use the lower 32-bits of rAX in 64-bit mode, > I''d suggest > >a more explicit way (like casting it to 32-bit size, for exmple). > > Still a little bit confusing if eax is 64bit here :-(, people > need keep > this in mind when programming on x86_64 xen.Yes. It makes code work without rewriting it for 64-bit, but it makes it slightly more confusing, I agree. But having all code that is 32- and 64-bit compatible written in two versions isn''t a better option in my mind.> > > > >Note also that the x86_64 specification says that a 32-bit write to a > >64-bit register should zero-fill the upper 32 bits, which > won''t happen > >if you have : > > > > union { uint64_t rax; uint32_t eax } rAX; > > rAX.eax = 7; > > > >You''d end up with whatever was there from before in the upper bits of > >rAX.rax... > > > > Agree! And a little bit hate of the zero-fill.Well, considering the other option (explicit zero-fill) isn''t a good idea either, as that would lead to much more code in the common cases where a 32-bit integer is sufficient to calculate something. For example: long x; unsigned int y; .... x += y; ... This type of addition isn''t completely unusual, so adding extra code to mask off the upper bits would make it slightly longer, right? -- Mats> Thanks > -Xin > > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel