NO

Author Topic: Version 5.00 Beta 2 available  (Read 12786 times)

Offline Pelle

  • Administrator
  • Member
  • *****
  • Posts: 2266
    • http://www.smorgasbordet.com
Version 5.00 Beta 2 available
« on: February 15, 2008, 11:54:12 AM »
Pelles C version 5.0, Beta #2, is now available for download:
http://www.smorgasbordet.com/pellesc/download.htm

  • Added relocation section to resource-only DLLs in the Bin\Intl subdirectory (apparently needed on some computers).
  • Added some missing (GUID) libraries to the 64-bit Setup.
  • Fixed a typedef problem in addin.h for ANSI mode (UNICODE/_UNICODE not defined).
  • Added 'CALLBACK' to list of special Windows symbols in pobr(64).dll - will help with some 'type (CALLBACK *pfnMember)(...)' declarations.
  • Fixed problem with symbol annotations in debugger and PODUMP disassembler.
  • Added check for sysdefs.tag file in POIDE folder (if moved there manually).
  • Fixed some problems with INVOKE and stack parameters in POASM (AMD64 mode, parameter 5+).
  • Fixed sort-by-address problem in POVIEWP64.
  • Fixed a compiler problem with <floating-point-expression>*I in AMD64 backend.

Pelle
/Pelle

Offline AlexN

  • Global Moderator
  • Member
  • *****
  • Posts: 394
    • Alex's Link Sammlung
Re: Version 5.00 Beta 2 available
« Reply #1 on: February 15, 2008, 01:28:48 PM »
Pelles C version 5.0, Beta #2, is now available for download:

  • Added check for sysdefs.tag file in POIDE folder (if moved there manually).


Pelle, thank you!  :) (On my Notebook sysdefs.tag was created for each user, who uses Pelles C.)
best regards
 Alex ;)

Offline Christian

  • Administrator
  • Member
  • *****
  • Posts: 142
    • http://www.pellesc.de
Re: Version 5.00 Beta 2 available
« Reply #2 on: February 16, 2008, 03:03:26 PM »
Nice as usual  ;D

I've changed the files on the mirror too.

One question:

Is there no french translation anymore?
www.pellesc.de - German PellesC mirror (now available in german and english)

Offline Pelle

  • Administrator
  • Member
  • *****
  • Posts: 2266
    • http://www.smorgasbordet.com
Re: Version 5.00 Beta 2 available
« Reply #3 on: February 16, 2008, 04:38:40 PM »
@AlexN - OK, thanks.

@Christian - no French translation until another translator steps forward, I'm afraid...
/Pelle

Freddy

  • Guest
Re: Version 5.00 Beta 2 available
« Reply #4 on: February 16, 2008, 10:16:06 PM »
Thanks Pelle!

Talking about unicode builds. How do I activate it? I've never used unicode before.

Thank you

JohnF

  • Guest
Re: Version 5.00 Beta 2 available
« Reply #5 on: February 17, 2008, 08:44:00 AM »
Thanks Pelle!

Talking about unicode builds. How do I activate it? I've never used unicode before.

Thank you

Convert any file you want to be UniCode using a suitable editor (NotePad), the PellesC IDE will use that new file - on the file tab in the IDE you will see 'filename (UTF-16E)'

Then just build the project as normal.

John





skirby

  • Guest
Re: Version 5.00 Beta 2 available
« Reply #6 on: February 18, 2008, 09:59:32 AM »
@Christian - no French translation until another translator steps forward, I'm afraid...
Hello Pelle, do you need a French translator?
I can help you if you want.

Let me know if you are interested.

JohnF

  • Guest
Re: Version 5.00 Beta 2 available
« Reply #7 on: February 19, 2008, 08:43:32 AM »
@Christian - no French translation until another translator steps forward, I'm afraid...
Hello Pelle, do you need a French translator?
I can help you if you want.

Let me know if you are interested.

PellesC could benefit from a few translations - I guess anyone interested should just do it and present the result to Pelle. Now that one can use Unicode many more languages can be supported.

Edit:
Or, if Pelle doesn't want them I could have them on my web site.

John

« Last Edit: February 19, 2008, 09:00:13 AM by JohnF »

skirby

  • Guest
Re: Version 5.00 Beta 2 available
« Reply #8 on: February 19, 2008, 01:46:59 PM »
Hello JohnF,

If you or Pelle need my help in order to translate something into French, I am your man.
Just send me a private message and tell me what you want me to do ;)
I will do my best.

Have a nice day.

severach

  • Guest
Re: Version 5.00 Beta 2 available
« Reply #9 on: February 26, 2008, 05:24:53 AM »
When you click away from the DEBUG window the toolbar icons go gray and the Debug menu disappears. Even stranger, if you click to change a value the Debug menu disappears but the icons don't go gray.

The the menu should stay and the icons should stay lit so long as the debugger can be interacted with. Disabling the buttons because the focus is in another "debugger" window is not appropriate.

Offline Pelle

  • Administrator
  • Member
  • *****
  • Posts: 2266
    • http://www.smorgasbordet.com
Re: Version 5.00 Beta 2 available
« Reply #10 on: February 27, 2008, 05:28:08 PM »
Re Unicode: the encoding may be changed within the IDE through 'Properties' for a source code Window. You may also want to read 'Handling both ASCII and Unicode characters' in the help file appendix.

Re translations: it's probably good to have translations for some of the more 'popular' languages in the Setup, and French should qualify here, but I don't want a long list of languages since this will bloat the Setup, and each new language will also cause additional work for me which I'm not terribly happy about. I would be nice to have as many translations as possible, but I don't want to end up in a situation where I have to decide which languages should go into the Setup, and which should be kept separate. Any and all suggestions about how the translations should be handled are more than welcome...

/Pelle

JohnF

  • Guest
Re: Version 5.00 Beta 2 available
« Reply #11 on: February 28, 2008, 08:26:58 AM »
Re translations: it's probably good to have translations for some of the more 'popular' languages in the Setup, and French should qualify here, but I don't want a long list of languages since this will bloat the Setup, and each new language will also cause additional work for me which I'm not terribly happy about. I would be nice to have as many translations as possible, but I don't want to end up in a situation where I have to decide which languages should go into the Setup, and which should be kept separate. Any and all suggestions about how the translations should be handled are more than welcome...

If it helps I could host any of the translations on my web site.

The current convention for naming the dll would surely need to be changed slightly to accommodate other languages - more digits ?

For example
Russian ID is 0x0419 
English US ID is 0x0409

rsrc0409.dll and rsrc0419.dll ?

John
« Last Edit: February 28, 2008, 08:45:48 AM by JohnF »

severach

  • Guest
Re: Version 5.00 Beta 2 available
« Reply #12 on: February 29, 2008, 06:59:06 AM »
_BitScanForward() isn't working. With #include <windows.h> I get this:
Quote
POLINK: error: Unresolved external symbol '__BitScanForward'.

If I add #include <intrin.h> before or after I get 14 functions that clash between intrin.h and winnt.h with this error:
Quote
error #2120: Redeclaration of '_bittest' previously declared at

#include <intrin.h> without #include <windows.h> works so I commented out the offending lines in winnt.h. That works but now #include <windows.h> doesn't work unless #include <instrin.h> is placed before it.

Other questions:
Why is there no ffr()?
Why is there no _bswap16() or a suitably named XCHG WORD alternative? The Rotate functions should have a 16 bit variant too.
Why is INLINE_WORD_FLIP() and INLINE_DWORD_FLIP() not programmed to use _bswap() and _bswap16()?
Why does the function variant of _bswap() not use this code available on the i386 or BSWAP if the i386 platform is not supported:
Code: [Select]
  XCHG AH,AL
  ROR EAX,16
  XCHG AH,AL


Why does _BitScanForward() use SETNE; TEST AL,AL; JZ ...; when it could just use JZ directly without trashing a register?
Why does if (condition && ((assignment),1)) meaning perform the assignment if the condition is true optimize so poorly?
« Last Edit: February 29, 2008, 06:34:00 PM by severach »

severach

  • Guest
Re: Version 5.00 Beta 2 available
« Reply #13 on: March 03, 2008, 08:26:56 AM »
_BitScanForward needs work. The following code crashes when optimizations are turned off. It works when optimizations are turned on.

Code: [Select]
struct tagCrasher {WORD w1,w2;};
static void Crashit(struct tagCrasher *ptc) {
  _BitScanForward((DWORD *)&ptc->w2,ptc->w1);
}

int main(int argc,char *argv[]) {
  struct tagCrasher tc={1234,0};
  Crashit(&tc);
}
It seems that the unoptimizer does not know that EAX is clobbered by BSF AX,...

severach

  • Guest
Re: Version 5.00 Beta 2 available
« Reply #14 on: March 06, 2008, 08:25:28 AM »
Now we have an inline bug. Pelles C 5 inliner has been beefed up to inline more code than v4.5 can. Here is a divider that will use a shift instruction if code elsewhere has determined that the denominator is a power of two. wShift is the >> shift value or 0 if a divide must be used.

Code: [Select]
// compile with Maximize Speed or Maximize Speed More
#if 0
#define seekdivshift2(x,wShift,wSize) ((wShift)?((x)>>(wShift)):((x)/(wSize)))
#else
inline DWORD seekdivshift2(DWORD x,unsigned uiShift,WORD wSize) {
  return uiShift?(x>>uiShift):(x/wSize);
}
#endif

static void sdtest(unsigned uiShift,WORD wSize) {
  volatile DWORD x=atoi("12345");
  DWORD st=seekdivshift2(x,uiShift,wSize);
  printf("%u%s%u = %u\n",x,uiShift?">>":"/",uiShift?uiShift:wSize,st);
}

    sdtest(0,3); // this will divide by 3
    sdtest(3,0); // this will shift by 3

Volatile was added to get the bug to show. The shift divider always works. The non shift divider is broken. Change seekdivshift2() to non inline, remove the volatile, change to a macro, or change the compile optimization and the bug might go into remission depending on the surrounding code.

Code: [Select]
mov ebx,dword ptr[uiShift]
//eax=atoi("12345");
mov dword ptr  [x],eax // x=ebp-4
test ebx,ebx // uiShift from above
je divide
mov eax,dword ptr [x] // this numerator load is right
// remainder of shift code that works
divide:
mov eax,dword ptr [ebp-8] // this compiler generated location was never set. It is set in the macro version but only for the shift code path. It contains an unknown value for the divide code path.
// divide with an unknown  numerator

The volatile was required to get this simple example to show the bug. When this is inlined into normal code where there aren't lots of unused registers available the code looks like this:

Code: [Select]
mov eax,dword ptr [shift value]
mov [compiler generated location],eax // sloppy register handling created this location
test eax,eax
je divide
mov edx,[numerator] // move this up 1 or more instructions and we have a winner!
mov eax,edx // prepare the numerator
mov ecx,[compiler generated location]
// shift code
divide:
mov eax,edx // prepare the numerator with an unknown value from edx. edx has the value we want in the shift code path.
// divide with random numerator
Looks to me that the load in the shift code is out of place.