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
What value did you use? Maybe it's greater than 32 bits and you should use RAX for it rather than EAX (in dwtoa)?
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.
mov al,[esi]
Excuse my ignorance: Are 32-bit pointers legal in 64-bit code?
Since they work, they must be legal. But the instruction is one byte longer.
Jochen,
Quote from: jj2007 on April 21, 2014, 10:29:32 PM
Excuse my ignorance: Are 32-bit pointers legal in 64-bit code?
here's an interesting article (http://www.codeproject.com/Articles/28818/bit-pointers-in-a-bit-world) about that topic.
Gunther
Quote from: Yuri on April 21, 2014, 11:27:44 PM
Since they work, they must be legal.
The x32 ABI (http://beta.slashdot.org/story/196027) uses 32-bit pointers, but it requires an appropriate OS setup. Without that, one should check if it works
always with ASLR enabled...
Quote from: jj2007 on April 22, 2014, 12:56:57 AM
The x32 ABI (http://beta.slashdot.org/story/196027) 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.
Yuri,
Quote from: Yuri on April 22, 2014, 01:54:19 AM
Yes, you are right. They are better avoided.
no doubt about that.
Jochen,
we had a discussion about the point (http://masm32.com/board/index.php?topic=2134.0) some months ago. Do you remember?
Gunther
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:
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.