Recent posts

#31

Assembly discussions / Basic like put command

Last post by Vortex - March 28, 2026, 08:43:49 PM

Basic like put command sample :

Code Select Expand

include     OpenNewTxtForOutput.inc

.data

msg         db 'This is a test.',0
msg2        db 'Another test',0
file        db 'Test.txt',0

.data?

hFile       dd ?

.code

OpenNewTxtForOut PROC filename:DWORD

LOCAL mode:DWORD

    mov     mode,'w'
    invoke  fopen,filename,\
            ADDR mode
    ret

OpenNewTxtForOut ENDP

put PROC handle:DWORD,pMemory:DWORD
   
    invoke  lstrlen,pMemory
    invoke  fwrite,pMemory,1,\
            eax,handle
    ret

put ENDP
   
close PROC handle:DWORD

     invoke fclose,handle
     ret

close ENDP

start:

    invoke  OpenNewTxtForOut,ADDR file
    mov     hFile,eax
   
    invoke  put,eax,ADDR msg
    invoke  put,hFile,ADDR msg2
    invoke  close,hFile
   
    invoke  ExitProcess,0

END start


#32

Beginner questions / Re: same code pelles c and gcc...

Last post by Pelle - March 28, 2026, 12:34:09 PM

Downloaded n3220 working draft.

Problem is not your English - it is the inconsistency in the proposed spec.

Thanks for looking at this! Glad it's not just me, then...

Until there is a clearer picture, I will not change anything. The GCC distribution for Windows, that I have found in recent years (they seem to come and go), have been of somewhat dubious quality. I havn't seen this for LLVM yet. Microsoft may get to <stdbit.h> in 2035. Maybe.

For now, there are other functions doing the same job; for Windows: _BitScanForward(), _BitScanReverse(), _BitScanForward64(), and _BitScanReverse64(); more generic: _bit_scan_forward(), _bit_scan_forward64(), _bit_scan_reverse(), _bit_scan_reverse64(). No requirement on C23.

#33

Beginner questions / Re: same code pelles c and gcc...

Last post by John Z - March 28, 2026, 10:56:36 AM

Downloaded n3220 working draft.

Problem is not your English - it is the inconsistency in the proposed spec.

Sections 7.18.3 through 7.18.6 clearly indicate the direction to 'count' from. 'Leading' is from MSB to LSB,
'Trailing' is from LSB to MSB these are specifically spelled out in each of these sections under item #2.

However

Sections 7.18.7 through 7.18.12 drop the clarity. They seem to assume that everyone will guess "Leading" always means counting from MSB to LSB, and "Trailing" always means counting from LSB to MSB but do not ever specifically say so as in the previous sections.

Also have to be careful where some times use index as in Bit[0] - Bit[15] verses position Bit[1] - Bit[16]. or they say index +1 which is position or using w-1 which would be index  different authors I'm guessing.

IMO -

John Z

#34

Feature requests / Re: Enhanced editor suggestion

Last post by Pelle - March 27, 2026, 08:05:20 PM

It 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.

#35

Beginner questions / Re: same code pelles c and gcc...

Last post by Pelle - March 27, 2026, 07:58:36 PM

gcc 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...

#36

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 ?

[n3220.pdf]

#37

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):

The 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.

First 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.

First 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...?

#38

Bug reports / Re: TEXTEQU statement freezing...

Last post by Pelle - March 27, 2026, 05:13:39 PM

MessageBoxA 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...

[MOVBE]

#39

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.

#40

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.