Author Topic: negative value  (Read 5988 times)

shankle

  • Member
  • ****
  • Posts: 837
negative value
« on: April 21, 2014, 04:34:26 PM »
 Thanks for any help.
 The following code produces a negative value in FileBuffer,
  when it should be a positive value.

   FileBuffer       db  59 DUP (0)
   BufAdd           dq  0
   GTotalAccum      dq  0

   1st I clear FileBuffer to 0h
   GTotalAccum is a positive value
   after the below code FileBuffer is negative
   It should be a positive value
   
    mov rcx,Q[GTotalAccum]    ; input
    lea rbx,FileBuffer        ; output
    mov Q[BufAdd],rbx
;   changed rdx to rcx in a 64 bit program
    invoke dwtoa, rcx,[BufAdd]      ; Hex DD to string
                                     ; output is in FileBuffer

dwtoa:
     FRAME dwValue,lpBuffer
     USES esi,edi
   
    ; -------------------------------------------------------------
    ; convert DWORD to ascii string
    ; dwValue is value to be converted
    ; lpBuffer is the address of the receiving buffer
    ; EXAMPLE:
    ; invoke dwtoa,edx,ADDR buffer
    ;
    ; Uses: eax, ecx, edx.
    ; -------------------------------------------------------------
      mov   eax,[dwValue]
      mov edi,[lpBuffer]

      test eax, eax         ; is the value negative
      jns >
      mov B[edi], '-'         ; store a minus sign
      inc edi
      neg eax              ; and invert the value
:
      mov esi, edi           ; save pointer to first digit
      mov ecx, 10
.convert
      test eax,eax           ; while there is more to convert   
      jz >
      xor edx, edx
      div ecx              ; put next digit in edx
      add dl, '0'           ; convert to ASCII
      mov [edi],dl           ; store it
      inc edi
      jmp <.convert
:   
     mov B[edi], 0          ; terminate the string

.reverse                    ; We now have all the digits,
                            ; but in reverse order.
      cmp esi,edi
      jae >
      dec edi
      mov al,[esi]
      mov ah,[edi]
      mov [edi],al
      mov [esi],ah
      inc esi
      jmp <.reverse
:
    ret
ENDF

Yuri

  • Member
  • **
  • Posts: 175
Re: negative value
« Reply #1 on: April 21, 2014, 09:41:19 PM »
What value did you use? Maybe it's greater than 32 bits and you should use RAX for it rather than EAX (in dwtoa)?

shankle

  • Member
  • ****
  • Posts: 837
Re: negative value
« Reply #2 on: April 21, 2014, 10:22:55 PM »
Thanks Yuri for replying.
I have the same program written in MASM32 that is working.
Am trying to convert it to GoAsm 64-bit. So far all the values
written to the screen work, except for the Grand total line,
which is turning up negative.

jj2007

  • Member
  • *****
  • Posts: 9909
  • Assembler is fun ;-)
    • MasmBasic
Re: negative value
« Reply #3 on: April 21, 2014, 10:29:32 PM »
mov al,[esi]

Excuse my ignorance: Are 32-bit pointers legal in 64-bit code?

Yuri

  • Member
  • **
  • Posts: 175
Re: negative value
« Reply #4 on: April 21, 2014, 11:27:44 PM »
Since they work, they must be legal. But the instruction is one byte longer.

Gunther

  • Member
  • *****
  • Posts: 3585
  • Forgive your enemies, but never forget their names
Re: negative value
« Reply #5 on: April 21, 2014, 11:35:04 PM »
Jochen,

Excuse my ignorance: Are 32-bit pointers legal in 64-bit code?

here's an interesting article about that topic.

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

jj2007

  • Member
  • *****
  • Posts: 9909
  • Assembler is fun ;-)
    • MasmBasic
Re: negative value
« Reply #6 on: April 22, 2014, 12:56:57 AM »
Since they work, they must be legal.
The x32 ABI uses 32-bit pointers, but it requires an appropriate OS setup. Without that, one should check if it works always with ASLR enabled...

Yuri

  • Member
  • **
  • Posts: 175
Re: negative value
« Reply #7 on: April 22, 2014, 01:54:19 AM »
The x32 ABI uses 32-bit pointers, but it requires an appropriate OS setup. Without that, one should check if it works always with ASLR enabled...
Yes, you are right. They are better avoided.

Gunther

  • Member
  • *****
  • Posts: 3585
  • Forgive your enemies, but never forget their names
Re: negative value
« Reply #8 on: April 22, 2014, 04:04:06 AM »
Yuri,

Yes, you are right. They are better avoided.

no doubt about that.

Jochen,

we had a discussion about the point some months ago. Do you remember?

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

shankle

  • Member
  • ****
  • Posts: 837
Re: negative value
« Reply #9 on: April 24, 2014, 05:56:55 AM »
The program that is giving me so much trouble is a working program in MASM32.
Evidently MASM32 is very forgiving about signed and unsigned numbers and the math
done on them. The same input data is used both programs. I am just trying to
convert the MASM32 program to GoAsm 64-bit. It doesn't seen to have anything to do
with the MASM32 "dwtoa" code submitted above. Rather I think it has to do with my
dubious knowledge of how GoAsm plays with the sign bit. I have tested each field I am
trying to process and the test shows that each field is negative when it can't be
negative. ALL input data is POSITIVE. :icon_redface:


 

sinsi

  • Member
  • *****
  • Posts: 1201
Re: negative value
« Reply #10 on: April 24, 2014, 07:07:23 AM »
You are passing rcx to dwtoa but only processing the low 32-bits.
What happens when rcx is a positive dq but the low 32-bits are negative?
e.g. rcx=1ffffffff (positive) but ecx=ffffffff (negative).

Change dwtoa to use 64-bit registers.
I can walk on water but stagger on beer bourbon.