FloatToStr function - how to use it?

[nunos]

Hi there.

I have been trying to the very simple computation 5.0 + 3.4 and display on the screen 8.4, but still haven't been able to do that.

Code Select Expand


.data

res real8 ?
x1 real8 5.0
x2 real8 3.4

buff db 128 dup(0)
   
; «««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««

.code

main:
   
    fld x1     
    fadd x2   
    fstp res
   
    invoke FloatToStr, res, esi

    invoke StdOut, addr res
   
    exit

But this doesn't work, in fact it crashes.

What am I doing wrong?

Thanks.

[oex]

or
lea esi, buff

or better still

.data
buff db 20 dup(0)

.code
lea esi, buff

[jj2007]

Code Select Expand

00401013             |. BE 18204000        mov esi, 00402018
00401018             |. 8D35 18204000      lea esi, [402018]


[oex]

:p I saved 108 bytes

[jj2007]

Me only one :bg
Ok, since there are newbies around here, let's do it properly:

include \masm32\include\masm32rt.inc

.data
x1   real8 5.0
x2   real8 3.4

.data?
res   real8 ?
buff   db 128 dup(?)
   
.code
start:
   fld x1     
   fmul x2   
   fstp res
   mov esi, offset buff
   invoke FloatToStr, res, esi
   invoke StdOut, esi
   exit

end start

And mov esi, offset buff is indeed a byte shorter than lea esi, buff ;-)

[oex]

buff   db 128 dup(?)    ::)

[jj2007]

buff   db 128 dup(?)    ::)

Wheresdaproblem?

[oex]

lol sorry just being pedantic

The buffer for the string should be at least 19 bytes long as the procedure always write an 18 byte long string in szDbl. For alignment considerations, a 20 byte long buffer is recommended.

buff   db 20 dup(?)

[nunos]

Thanks all for you answers. I have succesfully printed out 8.4 as wished.

Me only one :bg
Ok, since there are newbies around here, let's do it properly:

include \masm32\include\masm32rt.inc

.data
x1   real8 5.0
x2   real8 3.4

.data?
res   real8 ?
buff   db 128 dup(?)
   
.code
start:
   fld x1     
   fmul x2   
   fstp res
   mov esi, offset buff
   invoke FloatToStr, res, esi
   invoke StdOut, esi
   exit

end start

And mov esi, offset buff is indeed a byte shorter than lea esi, buff ;-)

As you have already noticed, I am a newbie in assembly. I wasn't aware of the .data? directive. This is for unknown variables? Why not just use .data?

Thanks.

[jj2007]

I wasn't aware of the .data? directive. This is for unknown variables? Why not just use .data?

The values in .data must be supplied in the executable.
The values in .data? are zeroed at program start, so no need to store them in the executable.
In short: .data increases the size of your exe, .data? doesn't.
:thumbu

[nunos]

I wasn't aware of the .data? directive. This is for unknown variables? Why not just use .data?

The values in .data must be supplied in the executable.
The values in .data? are zeroed at program start, so no need to store them in the executable.
In short: .data increases the size of your exe, .data? doesn't.
:thumbu

That makes sense. Thanks once again.

[raymond]

In short: .data increases the size of your exe, .data? doesn't.

That statement is 100% correct.

However, from experience, it would seem that the MS linker increases the size of the EXE by a standard minimum of 2kb whenever you include any data (even a single byte) in the .data section. Thus, if the variables in the .data? section would not increase the overall data size beyond the 2kb limit, including them in the .data section would not increase the size of the exe.

(I am not familiar with other linkers such that the above may not hold true for some of them.)