sdcc-devel — Development chatter about SDCC

Re: [sdcc-devel] [Sdcc-user] No longer omitting the integer promotion on explicitly typecast arguments

[Maarten B. <sou...@ds...>]

Philipp Klaus Krause schreef op 2025-11-24 14:22:
> Am 24.11.25 um 13:54 schrieb Maarten Brock:
>> 
>> I would not qualify the stack as large for the mcs51 large & huge
>> memory models. Medium, large and huge do not place every variable in
>> the <= 248 bytes data memory, but still use it for itemps. So stack
>> space (= unallocated idata) remains very limited.
>> 
>> And when using --xstack the stack still is limited to 256 bytes pdata.
>> There is no stack implementation in xdata.
>> 
> […]
>> 
>> So my recommendation is to keep this behaviour for all targets with a
>> stack space of 256 bytes or less.
> 
> Except pdk, where despite the the stack being small, there is no point
> in omitting the promotion (and AFAIR pdk never omitted it). I'm not
> sufficiently familiar with ds390 to make changes there, so I guess for
> now, we'd keep the omission for ms51, mos6502, mos65c02, ds390.

For ds390 it would probably be OK to do the promotion as the stack space
is 1024 bytes there, IIRC.

Maarten

Re: [sdcc-devel] What happened to the GNU/Linux on amd64 and i386 snapshots?

[Philipp K. K. <pk...@sp...>]

Am 28.11.25 um 06:08 schrieb Erik Petrich:
> 
> The bigger problem was that a network connection went down; this is now
> fixed. A few other problems remain. In the 32-bit Linux regression
> tests are these errors:
> 
> cases/tinyaes/tinyaes_mode_CBC_keylen_128.c:586: error 9: FATAL
> Compiler Internal Error in file '/home/sdcc-builder/build/sdcc-
> build/orig/sdcc/src/SDCCicode.c' line number '1348' : IFFUNC_ISBUILTIN
> (ftype)
> Contact Author with source code
> […]

I noticed them yesterday, as they also happened on powerpc64: 
https://sourceforge.net/p/sdcc/code/15895/

Apparently the operand keys are not unique between iTemps and global 
stuff, which can mess up redundancy elimination. I think we were very 
lucky to get a reproducible bug, where a function in a call got replaced 
by an iTemp, thus triggering assertions. This bug probably could instead 
have manifested as a sporadic bug where once in a while the value of a 
global variable is replaced by the value of some iTemp.

Philipp

Re: [sdcc-devel] What happened to the GNU/Linux on amd64 and i386snapshots?

[<jan...@ec...>]

And, thinking more, probably L+1, and not L, would be the
right minimal size in that _WIN32 specific line:

          wassert (!pipe (p, L+1, _O_BINARY));

--- Ursprüngliche Nachricht ---
Von: "Janko Stamenović" via sdcc-devel  <sdc...@li...>
Datum: 28.11.2025 09:06:34
An: "Development chatter about sdcc" <sdc...@li...>
Betreff: Re: [sdcc-devel] What happened to the GNU/Linux on amd64 and 	
i386	snapshots?


          wassert (!pipe (p, L, _O_BINARY));

Re: [sdcc-devel] What happened to the GNU/Linux on amd64 and i386 snapshots?

[Janko S. <jan...@ec...>]

Regarding the Windows-related part, its _pipe is documented here

https://learn.microsoft.com/
 en-us/cpp/c-runtime-library/reference/pipe?view=msvc-170

so maybe this could be a fix:

1)

make sure this is included to be able to use _O_BINARY:

#include <fcntl.h>

2)

then the relevant sequence instead:

      if (port->c_preamble && strlen (port->c_preamble))
        {
          int p[2];
          FILE *preamble;
#ifdef _WIN32
          wassert (!_pipe (p));
#else
          wassert (!pipe (p));
#endif

would be something like:

      unsigned L; 
      if (port->c_preamble 
          && (L = strlen (port->c_preamble))!=0 )
        {
          int p[2];
          FILE *preamble;
#ifdef _WIN32
          wassert (!_pipe (p));
#else
          wassert (!pipe (p, L, _O_BINARY));
#endif            


I still haven't tried to compile or run, this is only based on my
reading of the docs. 


--- Ursprüngliche Nachricht ---
Von: Erik Petrich <epe...@iv...>
Datum: 28.11.2025 06:08:34
An: Development chatter about sdcc <sdc...@li...>
Betreff: Re: [sdcc-devel] What happened to the GNU/Linux on amd64 and i386  snapshots?


And then later when building the 32-bit Windows snapshot:

In file included from /home/sdcc-builder/build/sdcc-
build/orig/sdcc/src/common.h:41:0,
                 from /home/sdcc-builder/build/sdcc-
build/orig/sdcc/src/SDCCmain.c:33:
/home/sdcc-builder/build/sdcc-build/orig/sdcc/src/SDCCmain.c: In
function ‘main’:
/home/sdcc-builder/build/sdcc-build/orig/sdcc/src/SDCCmain.c:2893:21:
error: too few arguments to function ‘_pipe’
           wassert (!_pipe (p));
                     ^
/home/sdcc-builder/build/sdcc-build/orig/sdcc/src/SDCCglobl.h:384:33:
note: in definition of macro ‘wassertl’
 #define wassertl(a,s)   (void)((a) ? 0 : \
                                 ^
/home/sdcc-builder/build/sdcc-build/orig/sdcc/src/SDCCmain.c:2893:11:
note: in expansion of macro ‘wassert’
           wassert (!_pipe (p));
           ^~~~~~~
In file included from /home/sdcc-builder/build/sdcc-
build/orig/sdcc/src/SDCCmain.c:26:0:
/usr/share/mingw-w64/include/io.h:208:23: note: declared here
   _CRTIMP int __cdecl _pipe(int *_PtHandles,unsigned int _PipeSize,int
_TextMode);
                       ^~~~~
Makefile:103: recipe for target 'SDCCmain.o' failed
make[4]: *** [SDCCmain.o] Error 1

  Erik


_______________________________________________
sdcc-devel mailing list
sdc...@li...
https://lists.sourceforge.net/lists/listinfo/sdcc-devel

Re: [sdcc-devel] What happened to the GNU/Linux on amd64 and i386 snapshots?

[Erik P. <epe...@iv...>]

On Mon, 2025-11-24 at 09:13 +0100, Philipp Klaus Krause wrote:
> We had issues with the Windows ones for these architectures before,
> but 
> now the GNU/Linux ones are gone, too?
> 
> Philipp

The bigger problem was that a network connection went down; this is now
fixed. A few other problems remain. In the 32-bit Linux regression
tests are these errors:

cases/tinyaes/tinyaes_mode_CBC_keylen_128.c:586: error 9: FATAL
Compiler Internal Error in file '/home/sdcc-builder/build/sdcc-
build/orig/sdcc/src/SDCCicode.c' line number '1348' : IFFUNC_ISBUILTIN
(ftype) 
Contact Author with source code
Makefile:430: recipe for target
'gen/ucr2k/tinyaes/tinyaes_mode_CBC_keylen_128.rel' failed
make[6]: *** [gen/ucr2k/tinyaes/tinyaes_mode_CBC_keylen_128.rel] Error
1
results/ucr2k/tinyaes/tinyaes_mode_CBC_keylen_128.out:2:--- FAIL:
cannot compile/link cases/tinyaes/tinyaes_mode_CBC_keylen_128.c
cases/tinyaes/tinyaes_mode_CBC_keylen_192.c:586: error 9: FATAL
Compiler Internal Error in file '/home/sdcc-builder/build/sdcc-
build/orig/sdcc/src/SDCCicode.c' line number '1348' : IFFUNC_ISBUILTIN
(ftype) 
Contact Author with source code
Makefile:430: recipe for target
'gen/ucr2k/tinyaes/tinyaes_mode_CBC_keylen_192.rel' failed
make[6]: *** [gen/ucr2k/tinyaes/tinyaes_mode_CBC_keylen_192.rel] Error
1
results/ucr2k/tinyaes/tinyaes_mode_CBC_keylen_192.out:2:--- FAIL:
cannot compile/link cases/tinyaes/tinyaes_mode_CBC_keylen_192.c
cases/tinyaes/tinyaes_mode_CBC_keylen_256.c:586: error 9: FATAL
Compiler Internal Error in file '/home/sdcc-builder/build/sdcc-
build/orig/sdcc/src/SDCCicode.c' line number '1348' : IFFUNC_ISBUILTIN
(ftype) 
Contact Author with source code
Makefile:430: recipe for target
'gen/ucr2k/tinyaes/tinyaes_mode_CBC_keylen_256.rel' failed
make[6]: *** [gen/ucr2k/tinyaes/tinyaes_mode_CBC_keylen_256.rel] Error
1
results/ucr2k/tinyaes/tinyaes_mode_CBC_keylen_256.out:2:--- FAIL:
cannot compile/link cases/tinyaes/tinyaes_mode_CBC_keylen_256.c

...

cases/tinyaes/tinyaes_mode_CBC_keylen_128.c:586: error 9: FATAL
Compiler Internal Error in file '/home/sdcc-builder/build/sdcc-
build/orig/sdcc/src/SDCCicode.c' line number '1348' : IFFUNC_ISBUILTIN
(ftype) 
Contact Author with source code
Makefile:430: recipe for target
'gen/ucr5k/tinyaes/tinyaes_mode_CBC_keylen_128.rel' failed
make[6]: *** [gen/ucr5k/tinyaes/tinyaes_mode_CBC_keylen_128.rel] Error
1
results/ucr5k/tinyaes/tinyaes_mode_CBC_keylen_128.out:2:--- FAIL:
cannot compile/link cases/tinyaes/tinyaes_mode_CBC_keylen_128.c
cases/tinyaes/tinyaes_mode_CBC_keylen_192.c:586: error 9: FATAL
Compiler Internal Error in file '/home/sdcc-builder/build/sdcc-
build/orig/sdcc/src/SDCCicode.c' line number '1348' : IFFUNC_ISBUILTIN
(ftype) 
Contact Author with source code
Makefile:430: recipe for target
'gen/ucr5k/tinyaes/tinyaes_mode_CBC_keylen_192.rel' failed
make[6]: *** [gen/ucr5k/tinyaes/tinyaes_mode_CBC_keylen_192.rel] Error
1
results/ucr5k/tinyaes/tinyaes_mode_CBC_keylen_192.out:2:--- FAIL:
cannot compile/link cases/tinyaes/tinyaes_mode_CBC_keylen_192.c
cases/tinyaes/tinyaes_mode_CBC_keylen_256.c:586: error 9: FATAL
Compiler Internal Error in file '/home/sdcc-builder/build/sdcc-
build/orig/sdcc/src/SDCCicode.c' line number '1348' : IFFUNC_ISBUILTIN
(ftype) 
Contact Author with source code
Makefile:430: recipe for target
'gen/ucr5k/tinyaes/tinyaes_mode_CBC_keylen_256.rel' failed
make[6]: *** [gen/ucr5k/tinyaes/tinyaes_mode_CBC_keylen_256.rel] Error
1
results/ucr5k/tinyaes/tinyaes_mode_CBC_keylen_256.out:2:--- FAIL:
cannot compile/link cases/tinyaes/tinyaes_mode_CBC_keylen_256.c

And then later when building the 32-bit Windows snapshot:

In file included from /home/sdcc-builder/build/sdcc-
build/orig/sdcc/src/common.h:41:0,
                 from /home/sdcc-builder/build/sdcc-
build/orig/sdcc/src/SDCCmain.c:33:
/home/sdcc-builder/build/sdcc-build/orig/sdcc/src/SDCCmain.c: In
function ‘main’:
/home/sdcc-builder/build/sdcc-build/orig/sdcc/src/SDCCmain.c:2893:21:
error: too few arguments to function ‘_pipe’
           wassert (!_pipe (p));
                     ^
/home/sdcc-builder/build/sdcc-build/orig/sdcc/src/SDCCglobl.h:384:33:
note: in definition of macro ‘wassertl’
 #define wassertl(a,s)   (void)((a) ? 0 : \
                                 ^
/home/sdcc-builder/build/sdcc-build/orig/sdcc/src/SDCCmain.c:2893:11:
note: in expansion of macro ‘wassert’
           wassert (!_pipe (p));
           ^~~~~~~
In file included from /home/sdcc-builder/build/sdcc-
build/orig/sdcc/src/SDCCmain.c:26:0:
/usr/share/mingw-w64/include/io.h:208:23: note: declared here
   _CRTIMP int __cdecl _pipe(int *_PtHandles,unsigned int _PipeSize,int
_TextMode);
                       ^~~~~
Makefile:103: recipe for target 'SDCCmain.o' failed
make[4]: *** [SDCCmain.o] Error 1

  Erik

Re: [sdcc-devel] How to implement va_start?

[Philipp K. K. <pk...@sp...>]

Am 24.11.25 um 17:51 schrieb Philipp Klaus Krause:
> Am 22.11.25 um 18:15 schrieb Benedikt Freisen via sdcc-devel:
>> Options 0 and 2 look the most sensible to me, but I have no idea which 
>> one would be easier to implement.
> 
> I lika that 2 should work without changes in the backends; I'll try to 
> make 2 work; if not, I'll fall back to 0.
> 

Approach 0 is in the arraybounds branch: 
https://sourceforge.net/p/sdcc/code/15884/

While this is an ISO C23 va_start, this commit does not yet implement 
ISO C23 functions with variable arguments (i.e. va_start now works 
without a non-variable argument, but the parser does not yet accept 
declarations of functions that have only variable arguments). Also, 
regression tests are still missing (but I'll get to that later today or 
tomorrow).

Philipp

Re: [sdcc-devel] How to implement va_start?

[Philipp K. K. <pk...@sp...>]

Am 22.11.25 um 18:15 schrieb Benedikt Freisen via sdcc-devel:
> Options 0 and 2 look the most sensible to me, but I have no idea which 
> one would be easier to implement.

I lika that 2 should work without changes in the backends; I'll try to 
make 2 work; if not, I'll fall back to 0.

Philipp

Re: [sdcc-devel] No longer omitting the integer promotion on explicitly typecast arguments

[Steve S. <ste...@gm...>]

On Mon, Nov 24, 2025 at 2:22 PM Philipp Klaus Krause <pk...@sp...> wrote:
> (...) so I guess for now, we'd keep the omission for ms51, mos6502, mos65c02, ds390.

Sounds perfect to me as I also almost never use large and huge memory
models, only the small one.

It is much more efficient for me to simply put some variables explicitly in
idata or xdata and let SDCC do its magic for local vars and stack.

> have a good alternative, and will then no longer have a need to omit
> promotion on char.

I usually use uint8_t and int8_t instead of char, and I actually never
expected the promotion in the first place.
I guess I still have lots of things to know about C...

--
Steve Schnepp

Re: [sdcc-devel] No longer omitting the integer promotion on explicitly typecast arguments

[Philipp K. K. <pk...@sp...>]

Am 24.11.25 um 13:54 schrieb Maarten Brock:
> 
> I would not qualify the stack as large for the mcs51 large & huge
> memory models. Medium, large and huge do not place every variable in
> the <= 248 bytes data memory, but still use it for itemps. So stack
> space (= unallocated idata) remains very limited.
> 
> And when using --xstack the stack still is limited to 256 bytes pdata.
> There is no stack implementation in xdata.
> 
[…]
> 
> So my recommendation is to keep this behaviour for all targets with a
> stack space of 256 bytes or less.
Except pdk, where despite the the stack being small, there is no point 
in omitting the promotion (and AFAIR pdk never omitted it). I'm not 
sufficiently familiar with ds390 to make changes there, so I guess for 
now, we'd keep the omission for ms51, mos6502, mos65c02, ds390.

Benedikt raised an interesting point regarding this: _BitInt does not 
undergo integer promotion, so by passing a _BitInt(8), one can pass a 
single byte variable argument that only uses one byte of the stack 
(except for pdk) in a standard-conforming way.

So once most users use at least C23, we can revisit this, since users do 
have a good alternative, and will then no longer have a need to omit 
promotion on char.

Philipp

Re: [sdcc-devel] No longer omitting the integer promotion on explicitly typecast arguments

[Maarten B. <sou...@ds...>]

Philipp Klaus Krause schreef op 2025-11-23 16:02:
> Currently, SDCC omits integer promotion of explictly typecast
> arguments passed as variable arguments. This is done only when the
> selected standard dialect is an SDCC variant, and the target is not a
> pdk port (see section 3.5.15 of the manual).
> 
> The feature allows to save a byte of stack space (and some code size /
> speed if pushing an 8-bit value is simpler than pushing a 16-bit one)
> when passing a char, bool or _BitInt as variable argument.
> 
> I'd like to remove support for this langauge extension from the stm8
> port, f8 port, the z80-related ports, hc08 and s08.
> 
> Rationale:
> 
> * The main benefit of the feature is saving a little bit of stack
> space. But stm8, f8, the z80-related ports, hc08, s08, and mcs51 (for
> the large and huge memory model) have a large stack (with the
> exception of some stm8 devices, the whole RAM can be used as stack).

I would not qualify the stack as large for the mcs51 large & huge
memory models. Medium, large and huge do not place every variable in
the <= 248 bytes data memory, but still use it for itemps. So stack
space (= unallocated idata) remains very limited.

And when using --xstack the stack still is limited to 256 bytes pdata.
There is no stack implementation in xdata.

> * Omitting the integer promotion violates the C standard, and could
> thus result in surprising behavior for the user. After all that cast
> is not necessarily explicitly written with intent to omit the
> promotion, the cast might come e.g. from a macro expansion.
> * The omission makes code compiled with the SDCC dialect incompatible
> with code compiled without the dialect. This results in silent
> breakage when there are calls between such code that pass explicitly
> cast variable arguments (AFAIK even if that happens within the same
> file, and there is a #pragma std_sdccXX / #pragma std_cXX in between).
> * stm8, f8, the z80-related ports, hc08, s08 do have instructions to
> efficiently push a 16-bit value onto the stack, so there is not much
> benefit in code size and speed.
> * For the z80-related ports, we do not have instructions to
> efficiently put a single 8-bit value on the stack, we instead need to
> push a 16-bit register or value, then adjust the stack pointer, so
> there typically is no or even a negative benenefit in code size and
> speed.
> 
> Philipp

So my recommendation is to keep this behaviour for all targets with a
stack space of 256 bytes or less.

Maarten

Re: [sdcc-devel] How to implement va_start?

[Maarten B. <sou...@ds...>]

Philipp Klaus Krause schreef op 2025-11-21 09:47:
> We currently have the traditional implementation of va_start that uses
> the address of a last parameter before the variable arguments.
> 
> There are two problems with this:
> 
> a) In va_start, we take a pointer to an object (last parameter before
> variable arguments), do pointer arithmetic on it, and use the result
> to access outside that object. In general, that is undefined behavior
> (we are allowed to do it, since we are the implementation, and can
> define it do do whatever we want to). That UB triggers new warnings in
> the arraybounds branch.
> 
> b) Since ISO C23, only the first argument to va_start in mandatory,
> and functions with variable arguments don't need to have non-variable
> arguments. So in general, there is no last paramter before the
> variable arguments any more.
> 
> To implement va_start, we need a new way to get a pointer to the first
> variable argument. We have that knowledge in the compiler, I think
> that va_start can no longer be a library-only feature.

Would it not be possible to make the pointer point to the first variable
argument and pass an object of size zero as last parameter?

> My ideas so far:
> 
> 0) Have a builtin function __va_start that returns the address of the
> first variable argument. Downsides: all ports need to get support for
> builtin functions.
> 
> 1) Have an iCode VA_START that returns the address of the first
> variable argument. Downsides: special iCode for just a single specific
> feature, would also need support in AST, parserm lexer via special
> keyword, and in all ports.
> 
> 2) Have a predefined object char __va_start[] that we put into
> functions with variable arguments, where we somehow set the address so
> that the address would be the same as that of the first variable
> argument. Downsides: I don't know yet how hard it would be to
> implement this; this probably violates effective type rules as soon as
> the second variable parameter is accessed, so if we ever introduce
> warnings for violating effective type rules, we might get a situation
> similar to a) again. But IMO this is not a real iissue, since
> especially programmers targeting small systems have a habit of
> violating effective type rules anyway, so to keep users happy, we need
> to have the expected semantics and no warnings, even when effective
> type rules are violated.

How will that work with nested vaargs functions?

Greetings,
Maarten

[sdcc-devel] What happened to the GNU/Linux on amd64 and i386 snapshots?

[Philipp K. K. <pk...@sp...>]

We had issues with the Windows ones for these architectures before, but 
now the GNU/Linux ones are gone, too?

Philipp

[sdcc-devel] No longer omitting the integer promotion on explicitly typecast arguments

[Philipp K. K. <pk...@sp...>]

Currently, SDCC omits integer promotion of explictly typecast arguments 
passed as variable arguments. This is done only when the selected 
standard dialect is an SDCC variant, and the target is not a pdk port 
(see section 3.5.15 of the manual).

The feature allows to save a byte of stack space (and some code size / 
speed if pushing an 8-bit value is simpler than pushing a 16-bit one) 
when passing a char, bool or _BitInt as variable argument.

I'd like to remove support for this langauge extension from the stm8 
port, f8 port, the z80-related ports, hc08 and s08.

Rationale:

* The main benefit of the feature is saving a little bit of stack space. 
But stm8, f8, the z80-related ports, hc08, s08, and mcs51 (for the large 
and huge memory model) have a large stack (with the exception of some 
stm8 devices, the whole RAM can be used as stack).
* Omitting the integer promotion violates the C standard, and could thus 
result in surprising behavior for the user. After all that cast is not 
necessarily explicitly written with intent to omit the promotion, the 
cast might come e.g. from a macro expansion.
* The omission makes code compiled with the SDCC dialect incompatible 
with code compiled without the dialect. This results in silent breakage 
when there are calls between such code that pass explicitly cast 
variable arguments (AFAIK even if that happens within the same file, and 
there is a #pragma std_sdccXX / #pragma std_cXX in between).
* stm8, f8, the z80-related ports, hc08, s08 do have instructions to 
efficiently push a 16-bit value onto the stack, so there is not much 
benefit in code size and speed.
* For the z80-related ports, we do not have instructions to efficiently 
put a single 8-bit value on the stack, we instead need to push a 16-bit 
register or value, then adjust the stack pointer, so there typically is 
no or even a negative benenefit in code size and speed.

Philipp

Re: [sdcc-devel] Replacing the mechanism for declaring builtin functions

[Philipp K. K. <pk...@sp...>]

Am 22.11.25 um 17:39 schrieb Philipp Klaus Krause:
> If we want this, I'd introduce it in two steps: first for the port- 
> specific builtins (easier, and I need better type support there now), 
> then for all builtins.
The first step is now working in the arraybounds branch:
https://sourceforge.net/p/sdcc/code/15868/

Philipp

Re: [sdcc-devel] How to implement va_start?

[Benedikt F. <b.f...@gm...>]

Options 0 and 2 look the most sensible to me, but I have no idea which 
one would be easier to implement.

Benedikt

Am 21.11.25 um 09:47 schrieb Philipp Klaus Krause:
> We currently have the traditional implementation of va_start that uses 
> the address of a last parameter before the variable arguments.
>
> There are two problems with this:
>
> a) In va_start, we take a pointer to an object (last parameter before 
> variable arguments), do pointer arithmetic on it, and use the result 
> to access outside that object. In general, that is undefined behavior 
> (we are allowed to do it, since we are the implementation, and can 
> define it do do whatever we want to). That UB triggers new warnings in 
> the arraybounds branch.
>
> b) Since ISO C23, only the first argument to va_start in mandatory, 
> and functions with variable arguments don't need to have non-variable 
> arguments. So in general, there is no last paramter before the 
> variable arguments any more.
>
> To implement va_start, we need a new way to get a pointer to the first 
> variable argument. We have that knowledge in the compiler, I think 
> that va_start can no longer be a library-only feature.
>
> My ideas so far:
>
> 0) Have a builtin function __va_start that returns the address of the 
> first variable argument. Downsides: all ports need to get support for 
> builtin functions.
>
> 1) Have an iCode VA_START that returns the address of the first 
> variable argument. Downsides: special iCode for just a single specific 
> feature, would also need support in AST, parserm lexer via special 
> keyword, and in all ports.
>
> 2) Have a predefined object char __va_start[] that we put into 
> functions with variable arguments, where we somehow set the address so 
> that the address would be the same as that of the first variable 
> argument. Downsides: I don't know yet how hard it would be to 
> implement this; this probably violates effective type rules as soon as 
> the second variable parameter is accessed, so if we ever introduce 
> warnings for violating effective type rules, we might get a situation 
> similar to a) again. But IMO this is not a real iissue, since 
> especially programmers targeting small systems have a habit of 
> violating effective type rules anyway, so to keep users happy, we need 
> to have the expected semantics and no warnings, even when effective 
> type rules are violated.
>
> Philipp 

Re: [sdcc-devel] Replacing the mechanism for declaring builtin functions

[Benedikt F. <b.f...@gm...>]

You've got my full support for that.
At least on the surface, parsing the builtin functions from C code could 
simplify implementation and usage at the same time.

Benedikt

Am 22.11.25 um 17:39 schrieb Philipp Klaus Krause:
> Currently, we have a way of adding declarations for builtin functions. 
> Some of these are SDCC-wide, some are port specific. The latter 
> consist of e.g.g (z80 port example):
>
> static builtins _z80_builtins[] = {
>   {"__builtin_memcpy", "vg*", 3, {"vg*", "Cvg*", "Ui"}},
>   {"__builtin_strcpy", "cg*", 2, {"cg*", "Ccg*"}},
>   {"__builtin_strncpy", "cg*", 3, {"cg*", "Ccg*", "Ui"}},
>   {"__builtin_strchr", "cg*", 2, {"Ccg*", "i"}},
>   {"__builtin_memset", "vg*", 3, {"vg*", "i", "Ui"}},
>   {NULL, NULL, 0, {NULL}}
> };
>
> which is then used in the port struct. This is a way to code the type 
> for the declaration, which is then parsed in funcOfTypeVarg; for the 
> non-port-specific ones, this struct is built in initCSupport.
>
> All that parsing in funcOfTypeVarg, and having to use/learn this SDCC 
> format for the declarations looks ugly to me. Also, it is very 
> restricted in what types it supports (though I already extended it a 
> bit in the past).
>
> IMO, there is a better alternative: we pass two additional blocks of 
> code to yyparse before passing the user code from the preprocessor: an 
> SDCC-specific one (for the SDCC-wide builtins) and a port-specific one 
> (for the port-specific builtins). That way, we can use plain C code 
> for the declarations, thus it is a format we all know well, and we get 
> the full power of the C type system.
>
> If we want this, I'd introduce it in two steps: first for the 
> port-specific builtins (easier, and I need better type support there 
> now), then for all builtins.
>
> Philipp 

[sdcc-devel] Replacing the mechanism for declaring builtin functions

[Philipp K. K. <pk...@sp...>]

Currently, we have a way of adding declarations for builtin functions. 
Some of these are SDCC-wide, some are port specific. The latter consist 
of e.g.g (z80 port example):

static builtins _z80_builtins[] = {
   {"__builtin_memcpy", "vg*", 3, {"vg*", "Cvg*", "Ui"}},
   {"__builtin_strcpy", "cg*", 2, {"cg*", "Ccg*"}},
   {"__builtin_strncpy", "cg*", 3, {"cg*", "Ccg*", "Ui"}},
   {"__builtin_strchr", "cg*", 2, {"Ccg*", "i"}},
   {"__builtin_memset", "vg*", 3, {"vg*", "i", "Ui"}},
   {NULL, NULL, 0, {NULL}}
};

which is then used in the port struct. This is a way to code the type 
for the declaration, which is then parsed in funcOfTypeVarg; for the 
non-port-specific ones, this struct is built in initCSupport.

All that parsing in funcOfTypeVarg, and having to use/learn this SDCC 
format for the declarations looks ugly to me. Also, it is very 
restricted in what types it supports (though I already extended it a bit 
in the past).

IMO, there is a better alternative: we pass two additional blocks of 
code to yyparse before passing the user code from the preprocessor: an 
SDCC-specific one (for the SDCC-wide builtins) and a port-specific one 
(for the port-specific builtins). That way, we can use plain C code for 
the declarations, thus it is a format we all know well, and we get the 
full power of the C type system.

If we want this, I'd introduce it in two steps: first for the 
port-specific builtins (easier, and I need better type support there 
now), then for all builtins.

Philipp

Re: [sdcc-devel] How to implement va_start?

[Philipp K. K. <pk...@sp...>]

Am 21.11.25 um 18:31 schrieb "Janko Stamenović" via sdcc-devel:
> 
> To me, (0) seems to be the "most obvious" way and also the
> work regarding the "downside" seems to be similar to that
> in the other cases, but the overall "win" at the end seems
> to be the highest?

2) Should be possible without any changes in the backends. We already 
have logic to place the parameters at the correct stack locations 
(port-specific aspects are handled using valus from the port struct), so 
I think we could use that to basically place a virtual argument that 
happens to be at the stack location where the first variable argument 
would be.

Philipp

P.S.: Thinking about this a bit more, I now realize that as long as we 
keep our current va_arg macro, all three approaches 0), 1) and 2) that I 
  came up with so far would be affected by the effective type rule 
issue, that I previously mentioned as downside for only 2). A 
replacement for va_arg would have to be another builtin function or 
special icode (or, if we go with 0) or 1), we could maybe use the same 
as for va_start, and make its functionality depend on the 
arguments/operands).

Re: [sdcc-devel] How to implement va_start?

[Janko S. <jan...@ec...>]

To me, (0) seems to be the "most obvious" way and also the
work regarding the "downside" seems to be similar to that
in the other cases, but the overall "win" at the end seems
to be the highest?


> 0) Have a builtin function __va_start that returns the address of
the first variable argument. Downsides: all ports need to get support
for builtin functions.


--- Ursprüngliche Nachricht ---
Von: Philipp Klaus Krause <pk...@sp...>
Datum: 21.11.2025 09:47:44
An: Development chatter about sdcc <sdc...@li...>
Betreff: [sdcc-devel] How to implement va_start?

0) Have a builtin function __va_start that returns the address of the
first variable argument. Downsides: all ports need to get support for
builtin functions.

[sdcc-devel] How to implement va_start?

[Philipp K. K. <pk...@sp...>]

We currently have the traditional implementation of va_start that uses 
the address of a last parameter before the variable arguments.

There are two problems with this:

a) In va_start, we take a pointer to an object (last parameter before 
variable arguments), do pointer arithmetic on it, and use the result to 
access outside that object. In general, that is undefined behavior (we 
are allowed to do it, since we are the implementation, and can define it 
do do whatever we want to). That UB triggers new warnings in the 
arraybounds branch.

b) Since ISO C23, only the first argument to va_start in mandatory, and 
functions with variable arguments don't need to have non-variable 
arguments. So in general, there is no last paramter before the variable 
arguments any more.

To implement va_start, we need a new way to get a pointer to the first 
variable argument. We have that knowledge in the compiler, I think that 
va_start can no longer be a library-only feature.

My ideas so far:

0) Have a builtin function __va_start that returns the address of the 
first variable argument. Downsides: all ports need to get support for 
builtin functions.

1) Have an iCode VA_START that returns the address of the first variable 
argument. Downsides: special iCode for just a single specific feature, 
would also need support in AST, parserm lexer via special keyword, and 
in all ports.

2) Have a predefined object char __va_start[] that we put into functions 
with variable arguments, where we somehow set the address so that the 
address would be the same as that of the first variable argument. 
Downsides: I don't know yet how hard it would be to implement this; this 
probably violates effective type rules as soon as the second variable 
parameter is accessed, so if we ever introduce warnings for violating 
effective type rules, we might get a situation similar to a) again. But 
IMO this is not a real iissue, since especially programmers targeting 
small systems have a habit of violating effective type rules anyway, so 
to keep users happy, we need to have the expected semantics and no 
warnings, even when effective type rules are violated.

Philipp

[sdcc-devel] Prototype of unicode identifier handling in SDCC using libu8ident in undefined branch

[Philipp K. K. <pk...@sp...>]

A first version of new handling for unicode identifiers is implemented 
in the undefined branch today, and can be tested:

https://sourceforge.net/p/sdcc/code/15819/

If libu8ident is found at configure time, it will be linked statically 
(i.e. no added runtime dependency for SDCC). In C23/C2y mode, this is 
used for normalization and checking the validity of identifiers vs. UAX 
#31, and to emit an error for invalid ones. In modes up to C11, a 
warning is emitted for non-normalized identifiers and identifiers not 
valid according to UAX #31.
The check is still slightly incomplete - currently identifiers starting 
with $ or _ are not fully checked.

Regarding homoglyph attack prevention, only a very minimalistic approach 
is used: when scripts are combined in a way not allowed by UTS #39, we 
emit a warning. This check is done per-identifier; e.g. there is a 
warning if a single identifier uses both latin and cyrillic characters, 
but not if there is a latin and another cyrillic identifier.

Without libu8ident, we fall back to the minimum required by C11 (i.e. 
basically the same as current SDCC trunk), but also give a warning on 
any non-ASCII identifiers encountered.

Philipp

Re: [sdcc-devel] [RFC] Flexible linking strategy for Unicode support libraries

[Philipp K. K. <pk...@sp...>]

Am 29.10.25 um 04:28 schrieb 周 子益:
> This approach gives us the best of both worlds: reliability for casual 
> users and optimization power for advanced users. It also respects the 
> diverse deployment environments where SDCC is used.
> I'm interested in hearing thoughts on this flexible linking strategy, 
> particularly from package maintainers and those with experience in 
> cross-platform library distribution.

IMO a bit too much complexity for a feature that 90% of SDCC won't use 
anytime soon. Also, Unicode standards can make chanegs to the XID 
properties; while it is nice to get atuomatic updates in SDCC by using a 
newer librry, it somehow feels odd that the question of what is a valid 
identifier could depend on the versions of runtime libraries (as could 
happen with dynamic linking).

IMO, a simple solution could be
1) If unicode library is not available at build time, make SDCC emit a 
warning when it encounters non-ASCII identifiers, and fall back to 
C11/C17-style handling of Unicode indentifiers in C23/C2y mode.
2) If unicode library is available at build time, do the fancier stuff 
(normalization and check for the XID stuff in C23/C2y mode, warning in 
earlier modes on identifiers that would be a problem in C23 mode).

The rough idea could look like the attached patch (against an earlier 
revision of the undefined branch, won't apply cleanly to today's svn or 
trunk, and contains some unrelated bits, but should still give an idea 
of my thoughts on this topic).

Philipp

Re: [sdcc-devel] [RFC] Optional Unicode Support Module for SDCC

[Philipp K. K. <pk...@sp...>]

SDCC currently behaves according to the C17 standard wrt. Unicode in 
identifiers. This will not change for modes up to --std-c17. There might 
be additional warnings introduced, but not errors for these modes.

For --std-c23 and --std-c2y SDCC will have to implement what those 
standards require.

IMO it will be helpful to users if SDCC warns in --std-c17 and earlier 
about mode code that would be an error in --std-c23 mode.

Philipp

Re: [sdcc-devel] Using libunistring in SDCC?

[Philipp K. K. <pk...@sp...>]

Am 24.10.25 um 17:07 schrieb Ger Hobbelt:
> 1) […]
> 
> Ergo: push all those hassles to the outside, for all compilers (not just 
> SDCC).  At least offload into a dedicated, public, library if you can't 
> resist and have to (I have to, for my products, for very 
> different reasons).  (or better yet: look around and grab one you like 
> from someone else who enjoys this sort of Unicode + human factor thing.)

Yes. if we do something about homoglyphs, we'd rely on a library for it. 
And if we do something the user-visible effect would be a warning.

This isn't urgent, unlike the XID and normalization stuff, since there 
is nothing about homoglyphs in current C standards or standard drafts.
> 2) Unicode normal form C: NFC. […]
> 
> A tough call, deciding which way to go with this. Warning about any non- 
> NFC-formedness would require SDCC to include some sort of Unicode 
> normalization code anyway and that then makes me lean towards using the 
> UCI C library directly as that is the reference implementation for this.
C23 considiers identifiers too be equal if they are equal in 
normalization form C. So for proper C23 support we need to deal with 
normalization. My preference weould be to have normalization applied in 
C23 and C2y mode, and for earlier modes (up to C17) warn on 
non-normalized identifiers.

> 4) re the unicode C library to use: my minor gripe against GNU 
> libunistring is that its build system and support is rather Unix-centric 
> automake/autoconf based (a hassle on MSVC/Windows systems) and its license.
> Of course, using the grand old UCI C library would be an option AFAIAC 
> […]
> 
> It's not all that important what is picked in the end, though if you 
> wish to remain a C-but-no-C++ codebase for SDCC, I don't know of any 
> nice and easy alternatives, except perhaps utf8proc, which is used by 
> the Julia folks: https://github.com/JuliaStrings/utf8proc <https:// 
> github.com/JuliaStrings/utf8proc>
> All the others I've run into, including some wrappers for UCI itself, 
> are all C++ codebases.

There are multiple optionsm here; using a common library, such as 
libunistring or UCI would be one. Another one could be linking 
statically against libu8ident (a less common library, but by linking 
statically we would avoid a runtime-dependency, and it provides more or 
less the feature set we need without too much other stuff).

Philipp

[sdcc-devel] Some of suggestions to of c standard to the sdcc

[周 子益 <z12...@ou...>]

First , I agree with Fabrice Bellard's view: adding support for Unicode would lead to "endless problems". However, compilers must support new language standards to simplify development and address potential issues in previous standards. Therefore, an option for Unicode can be provided during the compiler installation.