Author: Gerd Isenberg
Date: 14:23:27 09/27/05
Go up one level in this thread
On September 27, 2005 at 16:14:53, Dezhi Zhao wrote: >On September 27, 2005 at 15:42:32, Gerd Isenberg wrote: > >>On September 27, 2005 at 14:28:42, Dezhi Zhao wrote: >> >>>On September 27, 2005 at 12:20:27, Bo Persson wrote: >>> >>>>On September 27, 2005 at 00:56:20, Dezhi Zhao wrote: >>>> >>>>>VS2005 RC is finally up and running on Win x64 for me. >>>>>However I cannot find a template for a simple 64 bit console project. >>>>>Or, do I have to use command line? >>>>>I want to try some simple int and bit operations and take a look at the x86-64 >>>>>asm output. >>>>> >>>>>Any hints? Thanks >>>> >>>>Despite the name, you have to choose a Win32 Console Project. Then (if you have >>>>installed the 64 bit compiler) you can add an x64 target in the project >>>>properties. >>>> >>>>At least in the beta versions, the installer didn't install the 64 bit compiler >>>>unless you explicitly selected it... >>>> >>>> >>>> >>>>Bo Persson >>> >>>Thanks! Your trick works fine for me. >>> >>>Just took a look at the asm code and it seems to me there are no name for the >>>upper 32 bit part of a general 64 bit register. If you want to extract the upper >>>32 bits, the compiler generates a right shift operation. >> >>Yes, same already for x86-32 with 16-bit short values. >>32-bit eax and 16-bit ax, but for the upper 16bit you have to shift 16 right ;-) >> >>Only bytewise registers are accessible in low/high manner from a 64/32/16-bit >>register. >> > >You said it! They keep this bad tradition. The problem is shift operations are >slow on P4 class processors. Shift is still slow on x86-64, right? No, best case on x86-64, direct path, 1 cycle latency with 8/16/32/64-bit registers, regardless of the number of immediate or variable (cl) shifts. And of course a huge win for 64-bit shifts! > >>Note that operating on a 32-bit target register implicitely clears the 32-upper >>bits. Therefor the hint to use unsigned int as index, because the zero extension >>of the required 64-bit address operand register is free, while signed int >>requires explicite sign extension. >> >>Gerd > >I think this is probally a price for backward compatiblity. I would prefer an >explicit extension. This makes the upper 32 bits more useful. Yes, of course backward compatibility. At least they doubled the number of gp- and of xmm-regsiters, also R08..R15 can be used QWORD-, DWORD, WORD and BYTE wise. But there are issues with partial register stalls, and one should avoid that: xor ah, ah mov bl, al ; partial register stall, al depends on ah! So using 16-upper bits in eax or 32-upper bits in rax as partial hiWORDofDWORD or hiDWORDofQWORD-register seems not a good idea to me, despite one additional opcode rm-bit or an additional prefix-byte. AMD decited to go to virtual 64-bit addresses in 64-bit mode, 4Gigs is too "small" for huge database application, so we have: mov eax, [index32bit] ; implicit zero extension mov rax, [unsignedBase + 8*rax] but mov eax, [index32bit] ; implicit zero extension CDQE ; explicit sign extend possible negative index mov rax, [signedBase + 8*rax] So you have to deal with 64-bit address- or index-registers and don't like to explicitly keep track what is in the upper DWORD. I miss a "compact"-64-bit mode as well ;-) mov rax, [signedBase + eax] Gerd
This page took 0.01 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.