Version 9.00 (RC2) is now available

[Pelle]

Pelles C version 9.00 (RC2) is now available for download:
http://www.smorgasbordet.com/pellesc/download.htm

Major changes:
http://www.smorgasbordet.com/pellesc/changes_800_900.htm

Changes for RC2:

• Added definitions of far, near, pascal, FAR, NEAR to Windows includes (Go Win16, or whatever ).
• Added reposition of mode ComboBox also for some Add-In messages sent to main window (AIM_ADD_COMMAND_W, AIM_REMOVE_COMMAND).
• Added resource compiler protection to most C runtime includes (added #ifndef RC_INVOKED .. #endif). For projects using the same master include file for both C and RC files.
• Dropped handling of conflicting typedef names in the debugger, never display as "type1/type2/..." (just too confusing).
• Enhanced precision for last digit when converting from string to floating-point. This affects at least strtof(), strtod(), strtold(), atof(), wcstof(), wcstod(), wcstold(), and %e, %g, %f, %a conversion specifiers for scanf family of functions.
• Fixed painting problem when starting the IDE with an empty workspace on a non-maximized main window.
• Fixed one problem in the compilers register allocator.
• Added attempt at a more sequential layout of machine code when full debug info is requested from the compiler (hopefully helping the debugger associate source code with machine code, and accepting more breakpoints).
• Added new linker behavior: adjust default operating-system version down to any specified subsystem version.
• Fixed problem with missing callback annotation (calling convention) in Windows aclapi.h.
• Fixed problem with internal debugger exception during loading of X64 exception info (room for irony here ). Only happended for some projects, and only when assembly files were part of the project; "interesting problem".
• Fixed problem in compiler optimizer with weirdly written "C" code.

/Pelle

[Christian]

Great to have a new version coming up :-)

[akee]

Thanks Pelle.

[Pelle]

Thanks!

[MrBcx]

Hi Pelle!

I just discovered version 9 - thank you very much.

Now that I'm retired, I do much less programming but to borrow from a popular internet meme,

"I may not program often but when I do, I prefer to use Pelles C"

Thanks again.
MrBcx

[rchockxm]

Nice Jobs

Thanks Pelle.

[Pelle]

MrBcx, rchockxm: Thank you!

[jj2007]

Enhanced precision for last digit when converting from string to floating-point. This affects at least strtof(), strtod(), strtold(), atof(), wcstof(), wcstod(), wcstold(), and %e, %g, %f, %a conversion specifiers for scanf family of functions.

Congrats, I just installed RC3, and it works fine. I was curious, so I did a quick test with this strtold() example:

Code: [Select]

/* strtold example */
#include <stdio.h>      /* printf, NULL */
#include <stdlib.h>     /* strtold */

int main ()
{
  char szOrbits[] = "90613.305 365.24";
  char * pEnd;
  long double f1, f2;
  f1 = strtod (szOrbits, &pEnd);
  f2 = strtod (pEnd, NULL);
  printf ("Pluto takes %.20d years to complete an orbit.\n", f1/f2);
  return 0;
}
Results:

Code: [Select]

-3127531395801304400 Gcc (rubbish...)
248.0925008213777100 Visual C (strtod - there is no strtold)
248.0925008213777095 Pelles C
248.0925008213776989 MasmBasic REAL8 f1/f2
248.0925008213777242 MasmBasic using fdiv
248.0925008213777242 Windows Calc
Same for

Code: [Select]

printf ("Pluto takes %.20llf years to complete an orbit.\n", strtold (szOrbits, &pEnd)/strtold (pEnd, NULL));It seems that f1 and f2 are doubles, i.e. REAL8, and not long doubles, i.e. REAL10. Is that correct?

[TimoVJL]

Results:-3127531395801304400   Gcc (rubbish...)

gcc/mingw needs __USE_MINGW_ANSI_STDIO for printf and %Lf for long doubles

Code: [Select]

Pluto takes 248.092500821377724238 years to complete an orbit.

It seems that f1 and f2 are doubles, i.e. REAL8, and not long doubles, i.e. REAL10. Is that correct?

Sadly, with msvc and compatible, yes, long double is just an alias for double.
Visual C++ started using it ?

With gcc and icc, no, they have long double.

With mingw gcc use:

Code: [Select]

#define __USE_MINGW_ANSI_STDIO 1
#define __USE_MINGW_STRTOX 1
...
printf ("Pluto takes %.20Lf years to complete an orbit.\n", strtold (szOrbits, &pEnd)/strtold (pEnd, NULL));

EDIT:
Why function printf does not support long double?

So Microsoft Quick C dropped original long double.

[jj2007]

Thanks, Timo. I actually meant Pelles C when I asked if "short" doubles are being used.

With #define __USE_MINGW_ANSI_STDIO 1, the order is now:

Code: [Select]

248.0925008213777100 Visual C (strtod - there is no strtold)
248.0925008213777095 Pelles C
248.0925008213777242 MasmBasic (fdiv)
248.0925008213777242 MasmBasic (REAL10 variables)
248.0925008213777242 Windows Calc
248.092500821377724237 Gcc (#define __USE_MINGW_ANSI_STDIO 1)
248.092500821377724236 Windows Calc
So how can GCC achieve two more digits of precision...? The answer is under the hood (surprise, surprise):

Code: [Select]

  asm("int $3");
  f3=f1/f2;
  asm("nop");

[TimoVJL]

I don't quite understand what you mean

Code: [Select]

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

Code: [Select]

_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
gcc long double:

Code: [Select]

_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
fpu control register handling is elsewhere and gcc set it for _FPU_EXTENDED ?

[jj2007]

I don't quite understand what you mean

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

Code: [Select]

248.0925008213777242 MasmBasic (with REAL10 variables)
248.092500821377724237 Gcc
248.092500821377724236 Windows Calc (REAL16??)
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: [Select]

248.09250301171832220337 Gcc
248.0925030117183222 MasmBasic
248.0925030117183221991 Windows CalcThis 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: [Select]

.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
It show ST0: 2.4809250082137771e+02

EDIT: f3 for result

[jj2007]

It show ST0: 2.4809250082137771e+02

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