Index
> Main > Memory floating point value |
| Author |
|
|
donn 03 Dec 2014, 18:46
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
|
|||||||||||
03 Dec 2014, 18:46 |
|
|
AsmGuru62 03 Dec 2014, 19:41
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/ |
|||
|
03 Dec 2014, 19:41 |
|
|
HaHaAnonymous 03 Dec 2014, 20:13
[ Post removed by author. ]
Last edited by HaHaAnonymous on 28 Feb 2015, 18:01; edited 1 time in total |
|||
|
03 Dec 2014, 20:13 |
|
|
revolution 04 Dec 2014, 00:48
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 |
|||
|
04 Dec 2014, 00:48 |
|
|
l_inc 04 Dec 2014, 00:53
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 |
|||
|
04 Dec 2014, 00:53 |
|
|
HaHaAnonymous 04 Dec 2014, 01:45
[ Post removed by author. ]
Last edited by HaHaAnonymous on 28 Feb 2015, 18:01; edited 1 time in total |
|||
|
04 Dec 2014, 01:45 |
|
|
l_inc 04 Dec 2014, 02:29
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 |
|||
|
04 Dec 2014, 02:29 |
|
< Last Thread | Next Thread > |
Forum Rules:
|