Hi,
I am testing a new version of my "string to whatever number" macro (Val/MovVal (http://www.webalice.it/jj2006/MasmBasicQuickReference.htm#Mb1179))
Inter alia, I added negative bin and hex strings (e.g. -10101010y and -FFh) because ML.exe accepts them. Hex strings are recognised as $123abc or 0x123abc (but x123abc throws an error) or 123abch.
Any opinions on the validity of formats used below, and their interpretation? Anything missing in the list of formats? Thanks, JJ
P.S.: type is 0 for dec, 1 for bin, 2 for hex (returned in dh); used is the number of chars used (returned in dl)
# type.used Result (rounded) expected ... from string
0 0.39 OK 1.00000e+36 = 1.00000e+36 999999999999999999999999999999999999 ...
1 0.29 OK 1.2346e+25 = 1.2346e+25 12345678901234567890123456 ...
2 0.6 OK 123.00 = 123.00 123 ...
3 0.9 OK 10101.0 = 10101.0 10101d ...
4 0.12 OK -1010.1 = -1010.1 -10101e-1 ...
5 0.24 OK 1.2345e-123 = 1.2345e-123 ( 1.2345E-123 ) ... brackets OK?
6 0.16 OK -0.12340 = -0.12340 -1.23400E-1 ...
7 0.15 OK -0.12340 = -0.12340 -1.2340E-1 ...
8 0.9 OK 1.2300e+11 = 1.2300e+11 123.E9 ...
9 0.2 OK 0.0 = 0.0 . (just a dot followed by whitespace...)
10 0.6 OK 1.2000 = 1.2000 1.2 ...
11 0.5 OK 1.0000 = 1.0000 1. ...
12 0.5 OK 0.20000 = 0.20000 .2 ...
13 #?? 0.0 = -127.00 10101E invalid: trailing e but no exponent
14 #?? 0.0 = -127.00 just a text (invalid)
15 0.18 OK -1.2300e-99 = -1.2300e-99 ( -1.23e-99 ) ... eof bracket?
16 0.16 OK -1.2346e+05 = -1.2346e+05 -1.23456789e5 ...
17 0.16 OK -1.2346e+12 = -1.2346e+12 -12345678.9e5 ...
18 0.16 OK 1234.6 = 1234.6 1.234567890e3 ...
19 0.16 OK 1.2346e+11 = 1.2346e+11 123456789.0e3 ...
20 0.15 OK 1.2346e+12 = 1.2346e+12 1234567890e3 ...
21 0.8 OK 1.2300e+05 = 1.2300e+05 123e3 ...
22 0.5 OK 12.000 = 12.000 12 ...
23 1.9 OK 21.000 = 21.000 10101b ...
24 1.9 OK 21.000 = 21.000 10101y ...
25 2.9 OK 65793.0 = 65793.0 10101h ...
26 2.9 OK 74565.0 = 74565.0 $12345 ...
27 2.10 OK 74565.0 = 74565.0 0x12345 ...
28 2.5 OK 4835.0 = 4835.0 12e3h OK for e3_trailing h
29 2.19 OK 8.1986e+16 = 8.1986e+16 123456789012345h ...
30 0.8 OK 1.2346e+05 = 1.2346e+05 123È456d abc commas to char200
31 0.19?? 123.00 = 1.2346e+12 (123,456,789,0e3))abc commas and brackets
32 2.6 OK 7.0356e+05 = 7.0356e+05 $abc45 OK for the $012 format
33 2.7 OK 7.0356e+05 = 7.0356e+05 0xabc45 OK for the 0x12 format
34 #?? 0.0 = 7.0356e+05 xabc45 no 0 before x
35 2.17 OK 9.2181e+18 = 9.2181e+18 7fed6fed5fed4fedh OK for a hex qword
40 2.12 OK 4.2950e+09 = 4.2950e+09 (0FFFFFFF0h)
41 2.12 OK 4.2950e+09 = 4.2950e+09 (0FFFFFFF4h)
44 0.18 OK 7777.7 = 7777.7 7777.6666666666 ...
50 0.9 OK -0.0010000 = -0.0010000 -1.e-3 ...
51 0.8 OK 2.0000e-04 = 2.0000e-04 .2e-3 ...
52 0.9 OK -2.0000e-04 = -2.0000e-04 -.2e-3 ...
60 2.5 OK -255.00 = -255.00 -0ffh
61 1.9 OK 170.00 = 170.00 10101010Y
62 1.10 OK -170.00 = -170.00 -10101010y
4 errors, MbValNew=1118 bytes, 4 errors expected
what about hexadecimal notation of floating point values (with the 'r' suffix).
e.g. 3F800000r = 1.0
Quote from: qWord on February 11, 2013, 10:08:16 PM
what about hexadecimal notation of floating point values (with the 'r' suffix).
e.g. 3F800000r = 1.0
Never seen. How do they work, where are they used?
MASM knows them.
It is common to write constants in hxadecimal format, because this avoid eventual problem of conversion (I've seen this often in publications).
The format is strict: MASM expected 8 digits for REAL4, 16 for REAL8 and 20 for REAL10. One more leading zero is allowed and required if the numbers begins with A-F or has leading zeros.
Is that what you see when you double-click in Olly on a FPU reg?
Could you give me a simple usage example?
Quote from: jj2007 on February 12, 2013, 03:12:51 AM
Is that what you see when you double-click in Olly on a FPU reg?
Could you give me a simple usage example?
It is simply the hexadecimal string of that number. For example a REAL8 is treated as a QWORD that is written in hexadecimal notation.
I've recently used this representation to create coefficients of the form 2^x with a macro.
Another example from a table based approximation, where the values had been calculated with a high precision library:
REAL8 04060000000000000r ; i=0 ; rep. cnt.: 0
REAL8 03F80000000000000r ; distance = 0
REAL8 0401C000000000000r
REAL8 040601FFFFFFFAB41r ; i=1 ; rep. cnt.: 7505107
REAL8 03F7FC07F01FCAED0r ; distance = -6.166E-010
REAL8 0401C0B7F285B5930r
REAL8 0406040000000476Er ; i=2 ; rep. cnt.: 4681233
REAL8 03F7F81F81F816DA0r ; distance = 5.197E-010
REAL8 0401C16E79685DC30r
...
that's good to know, qWord :t
so - if you have the value in binary form....
no need to convert it to decimal float,
then let the assembler convert it back
that avoids 2 possibilities of rounding errors :P
Jochen...
i had to try :biggrin:
mov edx::eax,3f80000000000000r
INVOKE WindowFromPoint,3f80000000000000r
no go on those
this one assembles, but does not generate what i expected
68 7AB68052 push 3f80000000000000r
rPI REAL10 4000C90FDAA22168C235r
...
fld rPI ; works fine, and you got PI in ST0
push 3f80000000000000r
generates
push 7AB68052
very odd ::)
OK, I think I got "the r thing" running:
include \masm32\MasmBasic\MasmBasic.inc
.data?
MyR4 REAL4 ?
MyR8 REAL8 ?
Init
MovVal xmm0, "400921FB54442D18r" ; load xmm0 as integer
Print Str$("Xmm0:\t%If\n", f:xmm0) ; print xmm0 as float
MovVal MyR4, "40490FDBr"
Print Str$("MyR4:\t%If\n", MyR4)
MovVal MyR8, "400921FB54442D18r"
Print Str$("MyR8:\t%If\n", MyR8)
push Val("40490FDBr")
fld REAL4 PTR stack
Print Str$("On FPU:\t%Hf\n", ST(0))
pop eax
PrintLine CrLf$, "Generate the 'r' string:"
fldpi
fst MyR8
PrintLine "[",Hex$(MyR8), "r]", Tb$, "as REAL8"
PrintLine "[",Hex$(ST), "r]", Tb$, "as REAL10"
Inkey
Exit
end start
Output:
Xmm0: 3.14159265358979312
MyR4: 3.14159274101257324
MyR8: 3.14159265358979312
On FPU: 3.1415927410125732
Generate the 'r' string:
[400921FB54442D18r] as REAL8
[4000C90FDAA22168C235r] as REAL10
It works only with the attached beta - don't even try with the current MB version 8)