[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


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

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

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?


> Thanks
> -Xin

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.