C++: 64 bit performance vs. 32 bit
|
From: Casper H.S. Dik on 5 Mar 2006 14:46 anton(a)mips.complang.tuwien.ac.at (Anton Ertl) writes: >What problems do you see? IIRC AMD64 always zero-extends 32-bit >operations. In what cases would pointer masking be needed? My guess >is that it would be pretty rare. Address space wrap perhaps? Casper -- Expressed in this posting are my opinions. They are in no way related to opinions held by my employer, Sun Microsystems. Statements on Sun products included here are not gospel and may be fiction rather than truth.
From: Anton Ertl on 5 Mar 2006 15:04 Casper H.S. Dik <Casper.Dik(a)Sun.COM> writes: >anton(a)mips.complang.tuwien.ac.at (Anton Ertl) writes: > >>What problems do you see? IIRC AMD64 always zero-extends 32-bit >>operations. In what cases would pointer masking be needed? My guess >>is that it would be pretty rare. > >Address space wrap perhaps? I can see a few cases where this could happen. There seem to be two good ways to deal with this: - Use the address-size override prefix (67H). This truncates the effective address to 32 bits and zero-extends it. - Write the code such that no address space wrap happens; for those instructions where you know that (which will probably be the majority), you can leave the address-size override away. How are these problems dealt with in other architectures? Ok, having only reg+offset addressing helps, but at least SPARC also has reg+reg. - anton -- M. Anton Ertl Some things have to be seen to be believed anton(a)mips.complang.tuwien.ac.at Most things have to be believed to be seen http://www.complang.tuwien.ac.at/anton/home.html
From: Eric Gouriou on 5 Mar 2006 19:18 Anton Ertl wrote: > Casper H.S. Dik <Casper.Dik(a)Sun.COM> writes: >> anton(a)mips.complang.tuwien.ac.at (Anton Ertl) writes: >> >>> What problems do you see? IIRC AMD64 always zero-extends 32-bit >>> operations. In what cases would pointer masking be needed? My guess >>> is that it would be pretty rare. >> Address space wrap perhaps? > > I can see a few cases where this could happen. There seem to be two > good ways to deal with this: > > - Use the address-size override prefix (67H). This truncates the > effective address to 32 bits and zero-extends it. > > - Write the code such that no address space wrap happens; for those > instructions where you know that (which will probably be the > majority), you can leave the address-size override away. > > How are these problems dealt with in other architectures? Ok, having > only reg+offset addressing helps, but at least SPARC also has reg+reg. On Itanium, the 32 bit ABI I am familiar with (HP-UX ILP32) uses pointer swizzling to convert 32 bit values into 64bit virtual addresses. See "32-bit Virtual Addressing" on page 2:65 of the Volume 2 of the architecture, <URL:http://download.intel.com/design/Itanium/manuals/24531805.pdf> found under <URL:http://www.intel.com/design/itanium/manuals/iiasdmanual.htm> When Apple announced their transition to x86, I thought they'd wait for Merom/Conroe to allow them to use the 64-bit mode for both ILP32 and LP64 ABIs. I'd be curious to learn why they chose not to. My uninformed guesses it that they couldn't wait and/or that introducing a new ABI was deemed too risky and not worth the effort/delay (the "old" ILP32 ABI had been in-use for years internally). Eric
From: Seongbae Park on 6 Mar 2006 00:51 Anton Ertl <anton(a)mips.complang.tuwien.ac.at> wrote: .... > How are these problems dealt with in other architectures? Ok, having > only reg+offset addressing helps, but at least SPARC also has reg+reg. > > - anton SPARC has a mode bit (PSTATE.AM bit) which zeroes away the upper 32bit of any memory access. (AM == address mask) I think it isn't really necessary to have such a bit (and probably hurts to have it), but my guess is it was considered "cheap enough" when SPARC v9 was developed. -- #pragma ident "Seongbae Park, compiler, http://blogs.sun.com/seongbae/"
From: Casper H.S. Dik on 6 Mar 2006 04:14
anton(a)mips.complang.tuwien.ac.at (Anton Ertl) writes: >How are these problems dealt with in other architectures? Ok, having >only reg+offset addressing helps, but at least SPARC also has reg+reg. SPARCv9 uses the exact same instruction set and encoding as SPARCv8 (except for new instructions) and chose to implement 32 bit compatibility using two mechanisms: - a truncate address to 32 bits processor status flag the processor will not load from address with any of the top 32 bits set. - a second set of conditional codes for 64 bit ops (so 32 bit and 64 bit arithmetic ops generally use the same instructions but you'd test different condition codes) Casper -- Expressed in this posting are my opinions. They are in no way related to opinions held by my employer, Sun Microsystems. Statements on Sun products included here are not gospel and may be fiction rather than truth. |