Pelles C > Announcements

Version 9.00 (RC2) is now available

<< < (3/3)

TimoVJL:
I don't quite understand what you mean :(

--- Code: ---long double ld_div(long double ld1, long double ld2)
{
return ld1/ld2;
}

--- End code ---
PellesC double:
--- Code: ---_ld_div:
00000000  55                       push ebp
00000001  89E5                     mov ebp, esp
00000003  DD4508                   fld st0, qword ptr [ebp+08h]
00000006  DC7510                   fdiv st0, qword ptr [ebp+10h]
00000009  5D                       pop ebp
0000000A  C3                       ret

--- End code ---
gcc long double:
--- Code: ---_ld_div
00000000  55                       push ebp
00000001  89E5                     mov ebp, esp
00000003  DB6D08                   fld st0, [ebp+08h]
00000006  DB6D14                   fld st0, [ebp+14h]
00000009  DEF9                     fdivp st1, st0
0000000B  5D                       pop ebp
0000000C  C3                       ret

--- End code ---
fpu control register handling is elsewhere and gcc set it for _FPU_EXTENDED ?

jj2007:

--- Quote from: TimoVJL on July 09, 2018, 11:18:04 AM ---I don't quite understand what you mean :(
--- End quote ---

The fdiv does the job under the hood, as you rightly show, but it cannot provide the extra two digits of precision:

--- Code: ---248.0925008213777242 MasmBasic (with REAL10 variables)
248.092500821377724237 Gcc
248.092500821377724236 Windows Calc (REAL16??)
--- End code ---

REAL10 precision stops at the ...242. It seems that some fanboy at cplusplus has fumbled the example so that it "looks precise". As soon as you modify the figures, e.g. 90613.3058 instead of 90613.305, the picture changes:

--- Code: ---248.09250301171832220337 Gcc
248.0925030117183222 MasmBasic
248.0925030117183221991 Windows Calc
--- End code ---
This is the max precision you can get with fdiv, using the fpu's full REAL10 precision. OllyDbg displays, directly after the fdiv, 248.09250301171832220. The CRT printf() is less shy and displays as many digits as you want, but everything after the 222 is fake.

Btw your disassembly shows what I suspected: fld st0, qword ptr [ebp+08h] - meaning that Pelles C's long double is a short double. Gcc uses fld tbyte ptr [esp+10].

TimoVJL:
For testing PellesC poasm and debugger:
--- Code: ---.686
.model flat,stdcall
option casemap:none

.const
f1 tbyte 90613.305
f2 tbyte 365.24

.data
f3 tbyte ?

.code
ld_div proc C ld1:tbyte, ld2:tbyte
fld ld1;tbyte ptr [ebp+08h]
fld ld2;tbyte ptr [ebp+14h]
fdivp ;st1, st0
ret
ld_div endp

mainCRTStartup PROC C
invoke ld_div, f1, f2
fstp f3
ret
mainCRTStartup ENDP
END mainCRTStartup

--- End code ---
It show ST0: 2.4809250082137771e+02

EDIT: f3 for result

jj2007:

--- Quote from: TimoVJL on July 10, 2018, 09:09:25 AM ---It show ST0: 2.4809250082137771e+02
--- End quote ---

Real8 vs Real10 ;-)

248.09250082137771   PoAsm debugger
248.0925008213777100   Visual C (strtod - there is no strtold)
248.0925008213777095   Pelles C
248.0925008213777242   MasmBasic (REAL10 variables)
248.0925008213777242   Windows Calc
248.0925008213777242361187164604095936918190778666082575840 Wolfram Alpha

Navigation

[0] Message Index

[*] Previous page