flat assembler
Message board for the users of flat assembler.

Index > Main > Memory floating point value

Author
Thread Post new topic Reply to topic
donn



Joined: 05 Mar 2010
Posts: 184
donn
Hi, I'm still looking for the answers on my own, and making much progress, but reached a stumbling block. To resolve, it looks like it might take a lot of time shooting in the dark. I hacked the "BEER.asm" bundled example to run some floating point tests. Before the message box appears, I inserted:

Code:

        mov ebx, value1   ; put 0.11 addr in ebx
        mov edx, value2   ; put 0.10 addr in edx
        fld dword [ebx]     ; put 0.11 in st0
        fadd dword [edx]  ; add 0.10 to 0.11
        mov eax, value3   ; put 0.0 addr in eax to replace later
        fst dword [eax]     ; replace value at addr where 0.0 was with 0.21 (sum of 0.11 and 0.10)
        mov ecx, [value5] ; mov value 0.21 to ecx (want this to be equal to result of above add op)
        mov eax, [eax]     ; mov the value at eax addr to eax (may be a random statement, but did this in haste, didn't think cmp could compare to mem locations)

        ;cmp eax, ecx       ; used to check to make sure result was as expected, would print below messagebox depending what we set expected result to, changed jne to je, etc. Used different numbers initially but it worked pretty well.

        bt eax, 1             ; what should contents in eax look like? This is the question now. Not exactly as expected yet.

        jne exit               ; skip below message box as test verification

        invoke  MessageBoxA,0,_message,_caption,MB_ICONQUESTION+MB_YESNO
    


And placed some values at the end:

Code:
value1 dd 0.11        ; put in st0
value2 dd 0.10        ; add st0 with this val
value3 dd 0.0          ; mem location to have value replaced
value4 dd 34.5        ; old expected result value, not used anymore, actually haven't used this label much, but had 34.5 in value5
value5 dd 0.21        ; expected result
    


I was able to successfully test that the fadd operation and fst statement outputted the correct result, comparing values from memory locations value1 and value5. I started off with different numbers. I now changed value1 to be somewhat simple, as "0.11" and the other values also.

Since I'm dealing with doublewords, how should the value in eax look in binary? I changed the numbers for this test (using bt now, not cmp anymore) so eax should contain 0.21. Shouldn't this be single precision? Bit 31 tested true, so the exponent is negative, which is good I think, bit 0 tested true, which I thought was good, but so did bit 1. 21 in binary is 10101, so was guessing this would be the significand, bits 0-22.

I eventually wanted to be able to convert this to a string, or at least be able to, I don't think fxtract is necessary? One of the other examples I read in the message board used this at some point.

Next steps are to check the precision the fpu is using, test more of the result bits, try without the addition, use different precision, etc.

Thanks very much


Description:
Download
Filename: BEER2.ASM
Filesize: 1.14 KB
Downloaded: 243 Time(s)

Post 03 Dec 2014, 18:46
View user's profile Send private message Reply with quote
AsmGuru62



Joined: 28 Jan 2004
Posts: 1413
Location: Toronto, Canada
AsmGuru62
You do not need to load address every time you need a value at the address.
This works OK:
Code:
fld     [value1]
fadd    [value2]
fstp    [value3]
    

Also, dword is not needed, because values are declared as DD - so FASM 'knows' the types.

The FPU binary formats you can find here:
http://www.website.masmforum.com/tutorials/fptute/fpuchap2.htm#floats

The Contents is here:
http://www.website.masmforum.com/tutorials/fptute/
Post 03 Dec 2014, 19:41
View user's profile Send private message Send e-mail Reply with quote
HaHaAnonymous



Joined: 02 Dec 2012
Posts: 1180
Location: Unknown
HaHaAnonymous
[ Post removed by author. ]


Last edited by HaHaAnonymous on 28 Feb 2015, 18:01; edited 1 time in total
Post 03 Dec 2014, 20:13
View user's profile Send private message Reply with quote
donn



Joined: 05 Mar 2010
Posts: 184
donn
Appreciated. Bt updates the carry flag, not the zf, was using je/jz mistakenly. The links reinforced some of the representations of the real4, real8, etc data types (masm?). I went along and compared wfasm's built in calculator binary evaluation of 0.21 and it looked pretty close!

wfasm:

1 1111111001 010111000010100011110101110000101000111101011100001b


bt 31..0:
001111100 10101110000101000111110


Thanks again very much for the tips also.
Post 03 Dec 2014, 21:08
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17467
Location: In your JS exploiting you and your system
revolution
Comparing floating point values for equality is a bad idea. For example 0.3 + 0.3 + 0.4 != 1.0 because of rounding errors from inexact storage of values. One way around that is to have some error margin and check a result is within the range. i.e. 0.3 + 0.3 + 0.4 == (1.0 ± error margin)


Last edited by revolution on 04 Dec 2014, 00:57; edited 1 time in total
Post 04 Dec 2014, 00:48
View user's profile Send private message Visit poster's website Reply with quote
l_inc



Joined: 23 Oct 2009
Posts: 881
l_inc
HaHaAnonymous
Quote:
It is not needed by FASM but helps the reader/coder

In fact it's not only of no help, but is also harmful, because it prevents the compiler from doing type safety checks. If a variable is declared as a byte, an accidentally explicitly specified dword modifier will override the variable type, and the operation could possibly result in memory corruption. Explicit type specification should therefore be discouraged unless the type is ambiguous or an override is required.

_________________
Faith is a superposition of knowledge and fallacy
Post 04 Dec 2014, 00:53
View user's profile Send private message Reply with quote
HaHaAnonymous



Joined: 02 Dec 2012
Posts: 1180
Location: Unknown
HaHaAnonymous
[ Post removed by author. ]


Last edited by HaHaAnonymous on 28 Feb 2015, 18:01; edited 1 time in total
Post 04 Dec 2014, 01:45
View user's profile Send private message Reply with quote
l_inc



Joined: 23 Oct 2009
Posts: 881
l_inc
HaHaAnonymous
Firstly, please, read the whole post (in particular the "unless" part) before answering.
Secondly, demonstrating an even worse coding style does not prove anything.

_________________
Faith is a superposition of knowledge and fallacy
Post 04 Dec 2014, 02:29
View user's profile Send private message Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  


< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2020, Tomasz Grysztar. Also on YouTube, Twitter.

Website powered by rwasa.