Book : alert : The Art of 64-Bit Assembly

[jj2007]

Hi HSE,

deb works perfectly.

Edit: I see you found out ;-)

[HSE]

Edit: I see you found out ;-)

Yes. I maked that totally wrong at first 

[ttribelli]

In the past we were free to manipulate half a register, say AX in 32-bit mode, and the other half, EAX:31..16, would remain unchanged. That's no longer true

Check your assumptions.

It was certainly true in the 32-bit

Code: [Select]

xor  ax,  ax
xor eax, eax
vs 64-bit

Code: [Select]

xor eax, eax
xor rax, rax
context being discussed. :-)
I don't believe newcomers to 64-bit can put off learning the oddities like the zero extending to 64-bit that happens on some 32-bit operations.

[jj2007]

In the past we were free to manipulate half a register, say AX in 32-bit mode, and the other half, EAX:31..16, would remain unchanged. That's no longer true

So you are not ready to admit that you were wrong? Nice attitude

[ttribelli]

In the past we were free to manipulate half a register, say AX in 32-bit mode, and the other half, EAX:31..16, would remain unchanged. That's no longer true

So you are not ready to admit that you were wrong? Nice attitude

I was not making a universal statement. I was pointing out a new behavior in 64-bit mode and arguing a beginner needs to be aware. The automatic zero extension to the full register size on some basic 32-bit operations. In 32-bit mode xor ax, ax did not change the upper half of EAX. In 64-bit mode xor eax, eax does change the upper half of RAX.

I am perfectly happy to admit it when I am actually wrong. But my point about a new behavior, the necessity to be aware of it, and my example showing it are all correct. Care to point out an error in something I actually said?

[ttribelli]

In the past we were free to manipulate half a register, say AX in 32-bit mode, and the other half, EAX:31..16, would remain unchanged. That's no longer true

Check your assumptions.

Code: [Select]

include \Masm32\MasmBasic\Res\JBasic.inc ; ## console demo, builds in 32- or 64-bit mode with UAsm, ML, AsmC ##
usedeb=1 ; 1=use the deb macro
Init ; OPT_64 1 ; put 0 for 32 bit, 1 for 64 bit assembly
  PrintLine Chr$("This program was assembled with ", @AsmUsed$(1), " in ", jbit$, "-bit format.")
  mov rax, 1234567890123456h
  deb 4, "init", x:eax
  mov al, 11h
  deb 4, "mov al", x:eax
  mov ax, 2211h
  deb 4, "mov ax", x:eax
  mov eax, 44332211h
  deb 4, "mov eax", x:eax
EndOfCode

Code: [Select]

This program was assembled with ml64 in 64-bit format.
init    x:eax   1234567890123456h
mov al  x:eax   1234567890123411h
mov ax  x:eax   1234567890122211h
mov eax x:eax   44332211h

This is proving my point. Moving 2211h into AX did not change the upper half of EAX. Moving 44332211h into EAX did change the upper half of RAX. I apologize if I was not clear enough but what is it you think I am saying?

[hutch--]

I confess I don't see what the big deal is, 64 bit is a different animal and you simply learn how it works. MacroShaft (whoops I mean Microsoft) publish the range of integer registers as well as the later ones and there are so many other options in register choice that splitting EAX in AX, then rotating EAX so you read the other end as AX is hardly worth the effort when you have so many other options.

One thing you must be aware of is trying to load an immediate vaule larger than 4 gig into a memory operand directly. So that it does not get truncated to 32 bit, you load it into a 64 bit register first then MOV the register into the 64 bit memory operand.

mov rax, really_big_number
mov mem_operand, rax

[jj2007]

Moving 2211h into AX did not change the upper half of EAX

Same for 64-bit code: Moving 2211h into AX does not change the upper half of EAX. But a mov eax, 44332211h does change the upper half of rax. As Hutch wrote: simply learn it.

[ttribelli]

Moving 2211h into AX did not change the upper half of EAX

Same for 64-bit code: Moving 2211h into AX does not change the upper half of EAX. But a mov eax, 44332211h does change the upper half of rax. As Hutch wrote: simply learn it.

You misread what I wrote at the start. I never said the upper half of EAX changes, 32-bit or 64-bit. I said only that the upper half of RAX changes.
Again, I apologize if I was unclear. When I said "it is no longer true" I was referring to RAX not EAX.

[daydreamer]

Hutch doesn't 64 bit have the m2m macro?
Eax/ ax rotate is MS-DOS thing,lot of use ax in 32bit mode = 1byte extra prefix, don't Know how it's in 64 bit
In wndproc probably are necessary to be extra careful not zero out upper half of hidword, when working with lower and higher 32bits of wparam are used for different things
64 bit has plenty of registers, mostly 32bit winapi code needs tricks get more registers, lots of push and pop need to unlearn when go 64bit

[jj2007]

I said only that the upper half of RAX changes.

The point is that with a mov al, 123 or a mov ax, 12345 the upper half of RAX does not change. You are right, though, that if you manipulate half a register, say EAX in 64-bit mode, then rax will change. It just needed to be crystal clear ;-)

[hutch--]

magnus,

I am not going tpo try and interpret something that sounds like it came out of Aliice In Wonderland. Win64 is something you learn, not make guesses about.