RE: [Xen-devel] Definition of eax and rax

["Petersson, Mats" <Mats.Petersson@xxxxxxx>]

> -----Original Message-----
> From: Li, Xin B [mailto:xin.b.li@xxxxxxxxx] 
> 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@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel