Version 6.50, Release Candidate #1 available

[Pelle]

Pelles C version 6.50, Release Candidate #1, is now available for download:
http://www.smorgasbordet.com/pellesc/download.htm

Changes:
http://www.smorgasbordet.com/pellesc/changes_600_650.htm

The German translation will come later.

Pelle

[MrBcx]

Hello Pelle,

It's very good to hear from you - thank you for 6.5 RC1.

-FYI-

Compiling BCX with Pelles C 6.00      (30,671 lines of code) ->  compile time 0 minutes 45 seconds

Compiling BCX with Pelles C 6.5 RC1  (30,671 lines of code) ->  compile time 4 minutes 50 seconds


Memory usage during Pelles C compile peaks at about 500MB with 50% CPU utilization.

Development laptop is an Intel dual core Windows 7 Ultimate  32-bit 4GB  2.1GHZ

[frankie]

Hi Pelle, Welcome back!

[AlexN]

Hi Pelle,
I am happy, that you are back!

I will take a look at your new baby.

[Stefan Pendl]

Bug reported at http://forum.pellesc.de/index.php?topic=3324


I would suggest to report bugs with the RC here, so Pelle only needs to monitor one thread.

[Vortex]

Hi Pelle,

Thanks for the announcement.

[Pelle]

Thank you all!

MrBCX: could you please post the actual C code? I havn't seen any problems like that on my machine. It sounds like it may be a matter of disk swapping. The compilation speed is either the same or faster here - but then again, I have plenty of RAM. How much RAM do you have installed in your machine?

AlexN: I will look at the bug...

[Pelle]

AlexN: myassert.h, winvi.h and page.h are missing. At least one of them must be important. Can you make sure I have *all* the needed files to compile search.c ...?

[AlexN]

AlexN: myassert.h, winvi.h and page.h are missing. At least one of them must be important. Can you make sure I have *all* the needed files to compile search.c ...?

Sorry, but I thought only the half way.

At this link http://forum.pellesc.de/index.php?topic=2647.0, I posted the complete project some time before. But be careful it is posted in two parts (with the same name).

[TimoVJL]

Thanks for new version to test!

Even with this version i can't get Add-In function/macro AddIn_GetProjectShells to work ?

With TestGetProjectShells Add-In i get these results:

Code: [Select]

C:\code\PellesC\test_6.5\output\TestGetProjectShells.obj
nLen=30, 00 28 43  43
(CC) $(CCFLAGS) "$!" -Fo"$@"
C:\code\PellesC\test_6.5\TestGetProjectShells.dll
nLen=35, 00 28 4C  49
(LINK) $(LINKFLAGS) -out:"$@" $**

In PPj-file those lines are:
$(CC) $(CCFLAGS) "$!" -Fo"$@"
$(LINK) $(LINKFLAGS) -out:"$@" $**

[MrBcx]

MrBCX: could you please post the actual C code?

Sure -- The attached zip contains 'Bc.c' and 'PC.Bat',  the batch file I use to compile and link BCX using the Pelles C system.
There are actually 40,275 lines, including comments.

I havn't seen any problems like that on my machine. It sounds like it may be a matter of disk swapping. The compilation speed is either the same or faster here - but then again, I have plenty of RAM. How much RAM do you have installed in your machine?
I have 4gb but Windows 7 (32-bit) uses just under 3gb of that.
This HP laptop has a Intel T4300 dual core running @ 2.1ghz and is less than 6 months old.

[Romashka]

First of all, thank you for the new version!

The bug with non-trivial switch stamements seems to be fixed now.
UAC popup under Windows 7 is not fixed yet.

Found two new annoying bugs:
1) clicking on .ppj file opens it in POIDE's hex editor instead of opening the project
2) it is impossible to select non-TTF fonts in Options->Source->Font->Name selectbox
this is important because many fonts specifically designed for programmers are not TTF (e.g. my favourite Dina)
the only way to get them usable in 6.50 is to have them selected with 6.00 (like in my case), and do not clean the registry after 6.00 deinstallation.

EDIT: also, the font on help pages is smaller and harder to read now

[Robert]

Thank you all!

MrBCX: could you please post the actual C code? I havn't seen any problems like that on my machine. It sounds like it may be a matter of disk swapping. The compilation speed is either the same or faster here - but then again, I have plenty of RAM. How much RAM do you have installed in your machine?

In July 2007 I reported a similar problem to the Visual C++ Team at
Microsoft. The Borland compiler was compiling an optimized (-Ox flag)
BCX in less than 2 seconds while the Microsoft compiler was taking 324
seconds for an equivalently flagged compile.

Their final reply was, in part,

"Thanks for your feedback. The Visual C++ team has evaluated the bug and
determined it does not meet the guidelines necessary to warrant a fix.
To understand these guidelines please refer to

http://blogs.msdn.com/vcblog/articles/621116.aspx.

In particular, function that takes longest to compile is
RunTimeFunctions, which is a pretty big function. Compiler is not aware
that vast majority of the instructions are the printf calls, so it tries
to optimize the code the best possible. Also, there is a lot of control
flow which is based on global variables, so we can't really optimize
those--yet we spend a lot of time trying. We will consider changing our
optimizer technology in the future to add more analysis up-front, which
will enable us to wind down optimization in a function like this. In the
meantime, an easy workaround is to put #pragma optimize("g",off) around
this function."

I have unsuccessfully attempted to use the suggestion to turn off
#pragma optimize for the RunTimeFunctions sub while compiling BCX
with Pelle's C 6.5 RC1. If anyone can get this to work I
would appreciate knowing the specific details.

At that time, 2007, the Borland compiler produced a BCX.exe that ran faster
than that produced with any other compiler but I think that now the
Pelle's C 6.5 beta -Ot compiled BCX.exe has beat that time by about 10%.

Robert Wishlaw

[Pelle]

AlexN: the problem should now be fixed. In the future, it would be helpful if you could reduce the problem to a smaller test case (the problematic function was indicated in the error message). Now I had to spend an hour creating a smaller case, and ten minutes to fix the problem. There are more of you than me, so I need all the help I can get.

MrBCX: Thank you for the code. Yes, more information is better. The biggest problem here is that the program contains a large number of literal strings. The compiler will always attempt to pool strings (fold indentical copies into a single copy, to reduce space). I have now increased the number of hash buckets for literal strings, to reduce the chain of strings hashed to the same bucket. On my machine this reduces the compilation time from 125 seconds down to 38 seconds. This is a few seconds slower than 6.0, but 6.50 does more work so this is expected. There are other problems here (like the ones in Robert's post), but I can't do much about that for the moment...

timovjl: Yes, AddIn_GetProjectShells() seems totally broken. The last recorded change was in 2007 when it was split into ANSI and Unicode versions. Maybe something happend then. Anyway, it should be fixed now.

[Pelle]

UAC popup under Windows 7 is not fixed yet.

Which UAC popup?! You need to be admin to run the IDE, if that's what you mean. This is by design.

1) clicking on .ppj file opens it in POIDE's hex editor instead of opening the project

I will look at it.

2) it is impossible to select non-TTF fonts in Options->Source->Font->Name selectbox

Not really. What I want to do is to remove 80% of the fonts on my machine - installed by Windows, or more likely some other application - for languages I don't understand, with characters I can't read. If I don't do this, the list of fonts is annoyingly long here. You can play with the attached program to see which condition is filtering out your favorite font...

EDIT: also, the font on help pages is smaller and harder to read now

There is a new button in the help window specifically for changing the font size. I suggest you use it!!