Definition of eax and rax

Definition of eax and rax

[Li, Xin B]

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

RE: Definition of eax and rax

[Petersson, Mats]

> -----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
> 
> 
> 

Re: Definition of eax and rax

[Jan Beulich]

>>> "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

RE: Definition of eax and rax

[Li, Xin B]

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
>

RE: Definition of eax and rax

[Jan Beulich]

>>> "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
>#endif

This 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

RE: Definition of eax and rax

[Li, Xin B]

>> 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

RE: Definition of eax and rax

[Petersson, Mats]

 

> -----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
> 
> 
>