Author Topic: coding problem  (Read 8899 times)

shankle

  • Member
  • ****
  • Posts: 868
coding problem
« on: July 11, 2014, 08:49:17 PM »
            07-11-2014
somefld  dq  0         
    xor rax,rax
    mov eax,D[iVscrollPos]
    mov Q[somefld],rax
   
This code doesn't work in 64-bit GoAsm.
I don't understand why?
Other conditions make me have to use the 64-bit fields.
How can I solve this?   

qWord

  • Member
  • *****
  • Posts: 1475
  • The base type of a type is the type itself
    • SmplMath macros
Re: coding problem
« Reply #1 on: July 11, 2014, 11:37:19 PM »
Maybe you need sign extension (MOVSXD) rather than zero extension?
Also, what is the purpose of XOR?
MREAL macros - when you need floating point arithmetic while assembling!

Gunther

  • Member
  • *****
  • Posts: 4050
  • Forgive your enemies, but never forget their names
Re: coding problem
« Reply #2 on: July 12, 2014, 12:59:58 AM »
Hi qWord,

Also, what is the purpose of XOR?
Code: [Select]
        xor        rax, rax            ; produce a zero in RAX

Gunther
Get your facts first, and then you can distort them.

shankle

  • Member
  • ****
  • Posts: 868
Re: coding problem
« Reply #3 on: July 12, 2014, 01:37:52 AM »
Thanks guys for responding.
I assumed iVscollPos was an unsigned number.
So I thought xoring rax would do the trick.
If I am correct that IVscrollPos is an unsigned number, then
that's the only way I know to zero out the upper register.

qWord

  • Member
  • *****
  • Posts: 1475
  • The base type of a type is the type itself
    • SmplMath macros
Re: coding problem
« Reply #4 on: July 12, 2014, 01:56:05 AM »
32 bit result in registers are automatically zero extend to 64bit. An exception for this rule is XCHG EAX,EAX aka NOP.
MREAL macros - when you need floating point arithmetic while assembling!

Gunther

  • Member
  • *****
  • Posts: 4050
  • Forgive your enemies, but never forget their names
Re: coding problem
« Reply #5 on: July 12, 2014, 05:11:57 AM »
Hi qWord,

32 bit result in registers are automatically zero extend to 64bit. An exception for this rule is XCHG EAX,EAX aka NOP.

Of course, but
Code: [Select]
        xor        rax, rax
will work, too.

Gunther
Get your facts first, and then you can distort them.

qWord

  • Member
  • *****
  • Posts: 1475
  • The base type of a type is the type itself
    • SmplMath macros
Re: coding problem
« Reply #6 on: July 12, 2014, 05:40:09 AM »
The shown combination xor rax,rax; mov eax,... is useless!
MREAL macros - when you need floating point arithmetic while assembling!

Gunther

  • Member
  • *****
  • Posts: 4050
  • Forgive your enemies, but never forget their names
Re: coding problem
« Reply #7 on: July 13, 2014, 08:16:51 PM »
Hi qWord,

The shown combination xor rax,rax; mov eax,... is useless!

that makes sense. In that case would be xoring eax the better choice.

Gunther
Get your facts first, and then you can distort them.

qWord

  • Member
  • *****
  • Posts: 1475
  • The base type of a type is the type itself
    • SmplMath macros
Re: coding problem
« Reply #8 on: July 14, 2014, 01:52:35 AM »
In that case would be xoring eax the better choice.
no it isn't, because he won't zero the register. Instead he wants to load a 32 bit value with zero extension to 64 bit, which is implicitly done by the MOV instruction.
MREAL macros - when you need floating point arithmetic while assembling!

shankle

  • Member
  • ****
  • Posts: 868
Re: coding problem
« Reply #9 on: July 17, 2014, 08:16:04 AM »
I think, but do not know for sure,  that the globalalloc functions might be some of my
problem. I really hate to get into the heap functions. No tuts and nothing in the Petzold
book I have from 10 years ago. So it will be a true trial and error programming procedure.
I have many other more simple programs for GoAsm 64 that seem to work with the
old globalalloc functions.
Reason I say this is because I am getting a lot of C00005 and C000374 error messages.

shankle

  • Member
  • ****
  • Posts: 868
Re: coding problem
« Reply #10 on: July 17, 2014, 08:06:49 PM »
         7-17-2014

GoAsm code used here

linetot    dq  0   ; defined as 8 bytes
linetot has to be defined this way because of usage in other
parts of the program.
Local scr:SCROLLINFO
Scrollinfo is defined as a structure in Windows
of which scr.nmax is part of.
So how would this code be defined since items in the
Scrollinfo structure are double words?????
    mov rax,Q[linetot]
    mov   D[scr.nMax],eax ??

Is this an example of a POINTER?
prog1lnectr      db   '     ',0    ; defined as 5 bytes
    xor rsi,rsi
.loop1
    cmp rsi,5
    jge >>.loop2
    mov B[prog1lnectr+rsi],030h
    inc rsi
    jmp <.loop1
.loop2
 

Yuri

  • Member
  • **
  • Posts: 179
Re: coding problem
« Reply #11 on: July 18, 2014, 01:39:08 PM »
If they are double words, you can move them to/from EAX. If they are signed and you want to use them as 64-bit values later, you can use MOVSXD instead of MOV when moving them to a register, so that the double word will be sign extended to a quad word.
Code: [Select]
movsxd rax,[scr.nMax]

shankle

  • Member
  • ****
  • Posts: 868
Re: coding problem
« Reply #12 on: July 18, 2014, 11:10:18 PM »
Thanks Yuri for responding.
As far as I know the items in the Scrollinfo structure are not signed.
So does my previous example work or not?

Yuri

  • Member
  • **
  • Posts: 179
Re: coding problem
« Reply #13 on: July 19, 2014, 01:36:15 AM »
Yes, then you can simply use EAX.  The upper half of RAX will be zeroed automatically when you move a number to EAX. So you can then use the full RAX register in calculations or to store the number as a quad word to memory.

shankle

  • Member
  • ****
  • Posts: 868
Re: coding problem
« Reply #14 on: July 19, 2014, 02:13:40 AM »
Thanks again Yuri.
But I am doing just the opposite from what you said in your last message.
I'm filling rax with the value in linetot.
Then moving eax to scr.nMax. NOT rax to scr.nMax.
     mov rax, Q[linetot]
    D[scr.nMax],eax