News:

Download Pelles C here: http://www.pellesc.se

Main Menu

Recent posts

#71
Feature requests / Re: Enhanced editor suggestion
Last post by Pelle - March 27, 2026, 08:05:20 PM
Quote from: PhilG57 on February 14, 2026, 05:58:31 PMIt would be helpful to me if the editor would show which #ifdef/#else/#endif paths were active.  This might be done by highlighting, or not, the appropriate code sections.  Sometime I run into multiple, nested #ifdef's and sorting it all out is a big pain.  Thanks.
I actually would want this too, and have invested some time investigating this in the past. The problem is that it's not trivial to do accurate and fast enough. Inaccurate is unhelpful, and waiting on the editor is useless.
#72
Beginner questions / Re: same code pelles c and gcc...
Last post by Pelle - March 27, 2026, 07:58:36 PM
Quote from: TimoVJL on March 27, 2026, 07:44:02 PMgcc is multitarget compiler and see things in that way.
memory layout can be different in little-endian / big-endian things ?
Yes, but these functions should operate on the loaded value, disregarding the memory byte-order.
I would like a second opinion to GCC, but few compilers seems to care about C23 in general, and <stdbit.h> especially...
#73
Beginner questions / Re: same code pelles c and gcc...
Last post by TimoVJL - March 27, 2026, 07:44:02 PM
gcc is multitarget compiler and see things in that way.
memory layout can be different in little-endian / big-endian things ?
#74
Beginner questions / Re: same code pelles c and gcc...
Last post by Pelle - March 27, 2026, 07:16:45 PM
This is from the C23 draft n3220.pdf (since I will never waste money on the real C23 standard; I don't know if the draft differs from the final version):

QuoteThe most significant index is the 0-based index counting from the most significant bit, 0, to the least significant bit, w − 1, where w is the width of the type that is having its most significant index computed.

The least significant index is the 0-based index counting from the least significant bit, 0, to the most significant bit, w − 1, where w is the width of the type that is having its least significant index computed.

QuoteFirst Leading Zero
Returns the most significant index of the first 0 bit in value, plus 1. If it is not found, this function returns 0.

QuoteFirst Leading One
Returns the most significant index of the first 1 bit in value, plus 1. If it is not found, this function returns 0.

What the <beep> <beep> <beep> are they actually saying here?! Can someone with better English skills than mine explain: from which direction is what counted...?
#75
Bug reports / Re: TEXTEQU statement freezing...
Last post by Pelle - March 27, 2026, 05:13:39 PM
Quote from: Vortex on March 23, 2026, 09:03:13 PMMessageBoxA TEXTEQU <MessageBoxA> is not meaningful but this should not lock the assembler.
I agree, but not trivial to detect the way this is implemented.
I will have to think about it...
#76
Announcements / Re: Release Candidate #1 for v...
Last post by Pelle - March 27, 2026, 05:02:16 PM
Thank you all!

( I got side-tracked hunting down an elusive ARM64 bug )

The MOVBE support isn't essential. I can' live without it. Seems like less hassle to simple comment out the eight code generator rules producing this instruction.

I will rebuild everything (as usual) for Release Candidate #2. I need a few days for this.

#77
Announcements / Re: Release Candidate #1 for v...
Last post by Vortex - March 27, 2026, 12:33:03 PM
Attached is a simple GUI built with Pelles C V14 RC1. Can be Useful to test the movbe issue.
#78
Announcements / Re: Release Candidate #1 for v...
Last post by John Z - March 27, 2026, 11:37:20 AM
Thanks Timo,

Quote from: TimoVJL on March 27, 2026, 10:39:41 AMIf project build as stdcall, it didn't crash.

So the problem/issue or bug is with _fastcall in V14 acting differently from V13.

Appreciation,

John Z
#79
Announcements / Re: Release Candidate #1 for v...
Last post by John Z - March 27, 2026, 11:34:39 AM
Thanks Michele

Quote from: Michele on March 27, 2026, 09:12:40 AMI had a similar problem, the cause was an addin that increments the build number at each compilation.

You nailed it in one!  Seems the V14_RC1 did not include Timo's update for that Add-In.
Disabling it fix that issue.

Thanks,
John Z
#80
Announcements / Re: Release Candidate #1 for v...
Last post by TimoVJL - March 27, 2026, 10:39:41 AM
Quote from: John Z on March 26, 2026, 10:50:20 AMTesting many programs now, but a question -

Will each program compiled in V14_RC1 on a 'modern' CPU then need to be run/tested on a Windows 7 system and/or with an older CPU not supporting the MOVBE op code?

Essentially will programs completed with V14 possibly include the MOVBE op code in the exe?

GDIpTest program fails under V14, but OK under V13. Not sure why yet no error during creation but crashes on opening file to display. Sources , picture and exe files included.  The picture is what makes the upload so large but wanted to include exact test case.  Can be deleted later to release space.  Didn't find MOVBE in the exe btw


John Z

Seems you can use a HEX Editor and search for HEX 0F38F1 (found in several places poide.exe) or 0F38F0
If project build as stdcall, it didn't crash.