The MASM Forum
Projects => Rarely Used Projects => GoAsm => Topic started by: shankle 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
-
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,
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
-
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...
-
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,
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.