sdcc-devel — Development chatter about SDCC

Re: [sdcc-devel] Calling conventions for Z80 and SM83

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

Am 03.10.25 um 08:52 schrieb Sam Wilson:
> Let's take a function like `void f(char arg1, char arg2)`. If I'm 
> reading it right, the Z80 port will put arg1 in register A and arg2 in 
> register L, but the SM83 port will use registers A and E.
> 
> Let's take a function like `void f(long int arg1)`. If I'm reading it 
> right, the Z80 port will put arg1 in registers H, L, D, E, but the SM83 
> port will use registers D, E, B, C.
> 
> Does anyone know why this difference is there? I'm also interested in 
> what would hypothetically happen for ports to other similar targets, 
> like the Intel 8080.

It was decided experimentally: https://arxiv.org/abs/2112.01397 (note 
that those experiments were done for 8/16/32 bit parameters of basic 
type only, so the calling convention for parameters and return values of 
other sizes (_BitInt, long long, struct, union) was just decided ad-hoc, 
not based on real data).

I do have an opinion on what caused this, though: On the Z80 we can use 
hl more efficiently than other register pairs - we have the add hl, rr, 
adc hl, rr, ld r, (hl) etc; also ld hl (nn) is cheaper than ld rr, (nn). 
So having the parameter in hl allows us to get it there efficiently 
(e.g. if it is an addition result or a global variable), and use it 
efficiently (e.g. is the parameter is soon used as address pointer or 
addition operand).
And if we need to access the stack or global variables while that 
parameter is in hl, we can do so well using ix or iy (or ld rr, (nn)). 
But for sm83, there is no ix, iy or ld rr(nn). To generate okayish code 
for those, sm83 typically needs an available hl, so using hl for 
parameters tends to cause more problems than it solves.

Philipp

[sdcc-devel] Calling conventions for Z80 and SM83

[Sam W. <sam...@gm...>]

Hello everyone,

I'm looking at sdccman.pdf and in particular in which registers the first
function parameters get put, if they're short enough and few enough that
the stack is not involved. I'm looking at the flowcharts in 4.3.3.1 and
4.3.5.1.

Let's take a function like `void f(char arg1, char arg2)`. If I'm reading
it right, the Z80 port will put arg1 in register A and arg2 in register L,
but the SM83 port will use registers A and E.

Let's take a function like `void f(long int arg1)`. If I'm reading it
right, the Z80 port will put arg1 in registers H, L, D, E, but the SM83
port will use registers D, E, B, C.

Does anyone know why this difference is there? I'm also interested in what
would hypothetically happen for ports to other similar targets, like the
Intel 8080.

[sdcc-devel] atomic merge today

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

Dear SDCC developers,

while I did a merge from the atomic branch to trunk today, this did not 
actually give us any improved support for atomics. I just felt that what 
currently was in the atomic branch would be useful in trunk:

* Improved front-end only support for C11 atomics results in better 
error messages - instead of just getting an error message about lack of 
atomics support whenever the _Atomic keyword is used, we now also get 
additional error messages, when trying to use _Atomic in a way that 
wouldn't work even if SDCC had proper support for atomics.

* Refactoring of parameter passing iCode generation fixes a few corner 
cases for weird ways to pass parameters on the stack (as the pdk ports 
do, and for __smallc also the z80-relkated ports). This will also be 
sueful when I implement improved __dynamicc for the z80-related ports 
(another weird way to pass parameters).

The atomic branch will stay around for work towards actually improved 
atomics support.

Philipp

Re: [sdcc-devel] [Sdcc-user] realloc(p, 0)

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

Am 01.09.25 um 18:27 schrieb Maarten Brock:
> But according to this link you posted earlier, every other system except 
> BSD does
> the same as SDCC currently does:
> 
> https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2464.pdf

Mostly, though it misses some details:

* glibc is kind of worst, since there, malloc(0) allocates memory, but
realloc(ptr, 0) doesn't, so it looks inconsistent to me.
* musl libc does not free on realloc(ptr, 0).
* The BSDs by now also have diverged a bit. FreeBSD does free on 
realloc(ptr, 0), but OpenBSD and NetBSD don't.
* macOS behaves like what I want SDCC to change to.

Philipp

Re: [sdcc-devel] [Sdcc-user] realloc(p, 0)

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

Philipp Klaus Krause schreef op 2025-09-01 17:47:
> Am 01.09.25 um 17:35 schrieb Maarten Brock:
>> Philipp Klaus Krause schreef op 2025-09-01 17:19:
>>> C99TC2 (also C99TC3 and C11): "[…] If memory for the new object 
>>> cannot
>>> be allocated, the old object is not deallocated and its value is
>>> unchanged."
>> 
>> ISO/IEC 9899:TC3:
>> 
>> J.3 Implementation-defined behavior
>> A conforming implementation is required to document its choice of 
>> behavior in each of
>> the areas listed in this subclause. The following are implementation- 
>> defined:
>> [...]
>> J3.12 Library functions
>> [...]
>> — Whether the calloc, malloc, and realloc functions return a null 
>> pointer or a
>> pointer to an allocated object when the size requested is zero 
>> (7.20.3).
>> 
>> To me this says that as long as we document the current implementation
>> it is all right.
> 
> This gives us the right to return null (as we currently do), or an
> allocated object (as I want to do in the future).
> 
> But IMO this does not give us the right to free the old object if we
> return a null pointer. Thus I think our current implementation is
> non-compliant.
> 
> Philipp

But according to this link you posted earlier, every other system except 
BSD does
the same as SDCC currently does:

https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2464.pdf

Btw. I don't have a strong opinion which direction to choose.

Maarten

Re: [sdcc-devel] [Sdcc-user] realloc(p, 0)

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

Am 01.09.25 um 17:35 schrieb Maarten Brock:
> Philipp Klaus Krause schreef op 2025-09-01 17:19:
>> C99TC2 (also C99TC3 and C11): "[…] If memory for the new object cannot
>> be allocated, the old object is not deallocated and its value is
>> unchanged."
> 
> ISO/IEC 9899:TC3:
> 
> J.3 Implementation-defined behavior
> A conforming implementation is required to document its choice of 
> behavior in each of
> the areas listed in this subclause. The following are implementation- 
> defined:
> [...]
> J3.12 Library functions
> [...]
> — Whether the calloc, malloc, and realloc functions return a null 
> pointer or a
> pointer to an allocated object when the size requested is zero (7.20.3).
> 
> To me this says that as long as we document the current implementation
> it is all right.

This gives us the right to return null (as we currently do), or an 
allocated object (as I want to do in the future).

But IMO this does not give us the right to free the old object if we 
return a null pointer. Thus I think our current implementation is 
non-compliant.

Philipp

Re: [sdcc-devel] realloc(p, 0)

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

Philipp Klaus Krause schreef op 2025-09-01 17:19:
> void *realloc(void *ptr, size-t size);
> 
> C90: "[…] If the space cannot be allocated, the object pointed to by
> ptr is unchanged. If size is zero and ptr is not a null pointer, the
> object it points to is freed."
> 
> C99TC2 (also C99TC3 and C11): "[…] If memory for the new object cannot
> be allocated, the old object is not deallocated and its value is
> unchanged."

ISO/IEC 9899:TC3:

J.3 Implementation-defined behavior
A conforming implementation is required to document its choice of 
behavior in each of
the areas listed in this subclause. The following are 
implementation-defined:
[...]
J3.12 Library functions
[...]
— Whether the calloc, malloc, and realloc functions return a null 
pointer or a
pointer to an allocated object when the size requested is zero (7.20.3).

To me this says that as long as we document the current implementation
it is all right.

> C17: "If size is zero and memory for the new object is not allocated,
> it is implementation-defined whether the old object is deallocated. If
> the old object is not deallocated, its value shall be unchanged."
> 
> C23 (same in current C2Y draft): "[…] if the size is zero, the
> behavior is undefined. If memory for the new object is not allocated,
> the old object is not deallocated and its value is unchanged."
> 
> Currently, our malloc and realloc cannot allocate an object of size
> zero, they return NULL on such a request, and realloc does free. To me
> that looks compliant with C90, C17 and C23, but not C99.
> 
> I would like to change that to allowing allocation of zero-sized
> objects instead. Then, malloc(0) and realloc(ptr, 0) would return a
> non-null pointer. This would be compliant with C99, C17 and C23, but
> not C90.

IMHO the current implementation is compliant with all.

> From my side, this change is not motivated by a preference for the new
> semantics, but by it being the simplest to implement, thus reducing
> code size for malloc and realloc a bit.
> 
> Philipp

Maarten

Re: [sdcc-devel] realloc(p, 0)

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

Hi Philipp,

Philipp Klaus Krause schreef op 2025-08-28 16:06:
> Dear SDCC users,
> 
> do any of you use realloc(p, 0) for non-null p?
> 
> Historically, C implementations diverged substantially here, and what
> ANSI C89 / ISO C90 mandates¹ is different from what ISO C99 mandates²
> (I don't to go to explaining POSIX here). In current C23 it is
> undefined behavior.

Can you elaborate on the differences?

> I'd like to change the behavior of SDCC realloc from the C90 to the
> C99 one. Would that be a problem for you?

Please expand on what you want to change from and to. And also why.

AFAICT the current implementation is allowed in all cases.

> 
> Philipp
> 
> ¹ In ISO C90, realloc(p, 0) for non-null p is equivalent to free(p)
> and returning null.
> ² In C90 it will either not free, and return null or return a non-null
> pointer like it would for non-zero size.

Is this a typo? Should that be C99?

Greets,
Maarten

Re: [sdcc-devel] realloc(p, 0)

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

On Mon, Sep 1, 2025 at 5:21 PM Philipp Klaus Krause <pk...@sp...> wrote:
> I would like to change that to allowing allocation of zero-sized objects
> instead. Then, malloc(0) and realloc(ptr, 0) would return a non-null
> pointer. This would be compliant with C99, C17 and C23, but not C90.

That behaviour would be my preference also, as it makes actually using
it easier.

Cheers,
--
Steve Schnepp

Re: [sdcc-devel] realloc(p, 0)

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

void *realloc(void *ptr, size-t size);

C90: "[…] If the space cannot be allocated, the object pointed to by ptr 
is unchanged. If size is zero and ptr is not a null pointer, the object 
it points to is freed."

C99TC2 (also C99TC3 and C11): "[…] If memory for the new object cannot 
be allocated, the old object is not deallocated and its value is unchanged."

C17: "If size is zero and memory for the new object is not allocated, it 
is implementation-defined whether the old object is deallocated. If the 
old object is not deallocated, its value shall be unchanged."

C23 (same in current C2Y draft): "[…] if the size is zero, the behavior 
is undefined. If memory for the new object is not allocated, the old 
object is not deallocated and its value is unchanged."

Currently, our malloc and realloc cannot allocate an object of size 
zero, they return NULL on such a request, and realloc does free. To me 
that looks compliant with C90, C17 and C23, but not C99.

I would like to change that to allowing allocation of zero-sized objects 
instead. Then, malloc(0) and realloc(ptr, 0) would return a non-null 
pointer. This would be compliant with C99, C17 and C23, but not C90.

 From my side, this change is not motivated by a preference for the new 
semantics, but by it being the simplest to implement, thus reducing code 
size for malloc and realloc a bit.

Philipp

[sdcc-devel] realloc(p, 0)

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

Dear SDCC users,

do any of you use realloc(p, 0) for non-null p?

Historically, C implementations diverged substantially here, and what 
ANSI C89 / ISO C90 mandates¹ is different from what ISO C99 mandates² (I 
don't to go to explaining POSIX here). In current C23 it is undefined 
behavior.

I'd like to change the behavior of SDCC realloc from the C90 to the C99 
one. Would that be a problem for you?

Philipp

¹ In ISO C90, realloc(p, 0) for non-null p is equivalent to free(p) and 
returning null.
² In C90 it will either not free, and return null or return a non-null 
pointer like it would for non-zero size.

P.S.: If you want to know more background, see
https://www.open-std.org/jtc1/sc22/wg14/www/docs/summary.htm#dr_400
https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3621.txt
https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2464.pdf
https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2438.htm

[sdcc-devel] Merging the f8l branch to trunk

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

In the f8l branch, I've been working on an f8l port. The f8l is a  light 
version of the f8, its instruction set is a subset of the f8 one. This 
results in about 15% bigger, slower code, butz also in an f8l core only 
needing about half the area of a comparable f8 core.

Currently, the f8l port is purely compiler/library. It uses the f8 
assembler and simulator. Passign the regression tests thus doesn't mean 
that the generated code is necessarily correct, since it might still 
contain some f8l instruction not supported by the f8 (though I found 
none with grep).

I'd like to merge the f8l branch to trunk in a few days, but leave the 
f8 and f8l ports as experimental until we have the final opcode map (for 
both) and f8l assembler or simulator support (for f8l).

The benefits would be getting nightly f8l regressiont esting, and some 
f8 codegen improvements.

Philipp

[sdcc-devel] Bug category vs labels

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

Currently, our bug tracker has both categories and labels. Labels are 
rarely used, but IMO the categories are not very helpful. In fact, I 
rarely use one other than "other":

A bug in the z80-specific part of the peephole optimizer: "peephole 
optimizer" or "z80"? Both fit, neither fits perfectly. But assigning 
both a "z80" and a "peephole optimizer" label describes it well.

I thus suggest to remove the categories, and replace them by use of 
labels. IMO, it would make sense to instead have categories for how 
serious the bug is, such as "broken code generated" and "compilation 
fails", which could then replace the rarely-used priority.

Philipp

[sdcc-devel] FrOSCon presentation on SDCC: 2025-08-17 11:15

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

Dear SDCC users and developers,

there will be a prsentation on both recent progress and near-future 
plans for SDCC at FrOSCon this year:

https://programm.froscon.org/2025/events/3307.html

Philipp

Re: [sdcc-devel] mos6502, mos65c02, pic14 port disabled by default (and for snapshots)

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

Snapshots are back since Monday, and since today, they also contain the 
pic14, mos6502 and mos65c02 ports again.

Philipp

[sdcc-devel] mos6502, mos65c02, pic14 port disabled by default (and for snapshots)

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

Dear SDCC users and developers,

there currently is a bug affecting the mos6502, mos65c02 and pic14 
ports. To get back nightly regression testing at least for the other 
ports, I today disabled the mos6502, mos65c02, pic14 ports by default 
(i.e. they are only built if explicitly enabled at configure time), and 
in the snapshots.
Once bugs #3851, #3853 are fixed we can bring these ports back into the 
default configuration and snapshots.

Philipp

Re: [sdcc-devel] optimizing conditional expressions

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

Am 10.04.25 um 07:27 schrieb Gabriele Gorla via sdcc-devel:
> 16-bit addtions and subtractions are expensive on 8-bit CPUs.
> there is a lot of code that compares to <= or >= to a var+/-1
> 
> i.e. for(i=1; i<=row-1; ++i)
> 
> this is the icode for  i<=row-1
> 
> ;     [---] ic:6:     iTemp3 [k8 lr8:9 so:0]{ ia0 a2p0 re0 rm0 nos0 ru0 dp0}{int fixed}[a x ] = (int fixed)iTemp0 [k2 lr3:31 so:0]{ ia0 a2p0 re1 rm0 nos0 ru0 dp0}{char fixed}{ sir@ _legal_row_10000_18}[_legal_row_10000_18]
> ;     [---] ic:7:     iTemp4 [k9 lr9:11 so:0]{ ia0 a2p0 re0 rm0 nos0 ru0 dp0}{int fixed}[a x ] = iTemp3 [k8 lr8:9 so:0]{ ia0 a2p0 re0 rm0 nos0 ;     [a-x] ic:8:     iTemp5 [k10 lr10:11 so:0]{ ia0 a2p0 re0 rm0 nos0 ru0 dp0}{int fixed}{ sir@ _legal_sloc1_1_0}[_legal_sloc1_1_0] = (int fixed)iTemp17 [k26 lr5:31 so:0]{ ia0 a2p0 re0 rm0 nos0 ru0 dp0}{char fixed}{ sir@ _legal_sloc0_1_0}[_legal_sloc0_1_0]
> ;     [---] ic:9:     iTemp6 [k11 lr11:12 so:0]{ ia0 a2p0 re0 rm0 nos0 ru0 dp0}{_Bool fixed} = iTemp5 [k10 lr10:11 so:0]{ ia0 a2p0 re0 rm0 nos0 ru0 dp0}{int fixed}{ sir@ _legal_sloc1_1_0}[_legal_sloc1_1_0] > iTemp4 [k9 lr9:11 so:0]{ ia0 a2p0 re0 rm0 nos0 ru0 dp0}{int fixed}[a x ]
> 
> Ideally the optimizer would convert it to:
> i<row
> is it possible?

I think the C standard would allow that. However, compilers exploiting 
undefined behaviour for optimization is highly controversial in the C 
community, so some users might not like this (assuming row is an int, 
row-1 has UB for row==INT_MIN, and we'd have to rely on that since the 
semantics of i<INT_MIN is different from i<=INT_MAX). We'd probably want 
a command-line switch to disable such optimizations.

Philipp

[sdcc-devel] 10 days of no snapshots: mos6502 (vs. pic14)

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

Dear SDCC developers,

we last had snapshots 10 days ago (except for powerpc64-linux-gnu, see 
below). Since the results on the snapshots page are an important part of 
our protection against regressions, this is unfortunate.

It looks like the problem is ports exporting symbols without a 
port-specific prefix. In this case, there apparently is an 
incompatibility between the pic14 port and the mos6502 port (which is 
why we still have powerpc64-linux-gnu snapshots - these are built 
without the pic14 port). I.e. both are exporting the same symbol, when 
neither one should do so.

I've opened tickets:
https://sourceforge.net/p/sdcc/bugs/3851/
https://sourceforge.net/p/sdcc/bugs/3853/

and tried to do a bit of fixing on the pic14 side a few days ago already 
- since then sdcc builds, but we still get a segfault when trying to 
build the mos6502 library.

While the issue should be fixed on both sides, the pic14 port is 
unmaintained. So the fastest way to get the snapshots back should be 
fixing the problem on the mos6502 side.

Philipp

Re: [sdcc-devel] compile behavior of function pointers

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

Am 21.04.25 um 03:17 schrieb Gabriele Gorla via sdcc-devel:
> The following code cannot be compiled if the function neg is in the
> same file. I believe this to be the correct behavior on platforms
> that default to non-reentrant. Adding only the function prototype
> and using a different file for the function body makes it compile. 
> Marking everything __reentrant makes both one file compilation and
> multiple files work as expected.
> 
> I don't understand why the prototype when used alone matches the
> typedef while the function definition does not. Is this a bug?
> Should I file it?
> 
> 
> typedef float (*float_test_func)(float);
> 
> // the following alone is ok float neg(float);
> 
> // the following produces a compilation error // funcptr.c:15: error
> 78: incompatible types // from type 'float function ( float xdata)
> fixed' // to type 'float function ( float fixed) xdata' float neg
> (float a) { return -a; }
> 
> float_test_func f=neg;
> 
> void main(void) { }
Actually, I see the compilation error for mos6502, but not other ports 
that default to nonreentrant (mcs51, pdk15).
And the error message doesn't look particularly informative either 
(thoug we should get the more helpful "Functions called via pointers 
must be 'reentrant' to take this many (bytes for) arguments" at the call 
site anyway).

Philipp

[sdcc-devel] compile behavior of function pointers

[Gabriele G. <go...@ya...>]

The following code cannot be compiled if the function neg is in the same file. I believe this to be the correct behavior on platforms that default to non-reentrant.
Adding only the function prototype and using a different file for the function body makes it compile.
Marking everything __reentrant makes both one file compilation and multiple files work as expected.

I don't understand why the prototype when used alone matches the typedef while the function definition does not.
Is this a bug? Should I file it?


typedef float (*float_test_func)(float);

// the following alone is ok
float neg(float);

// the following produces a compilation error
// funcptr.c:15: error 78: incompatible types
// from type 'float function ( float xdata) fixed'
// to type 'float function ( float fixed) xdata'
float neg (float a)
{
  return -a;
}

float_test_func f=neg;

void main(void)
{
}

[sdcc-devel] SDCC developer meeting 2 -- transcripts

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

Good evening!

Following up on last Friday's developer meeting, I am pleased to 
announce that, in addition to our slides*, the full transcripts of our 
presentations* and subsequent discussions are now also available online, 
and can be studied by all those that would have been interested in 
partaking in the developer meeting, but could not attend in person.

Both, slide sets and transcripts, are in our SVN repository:

https://sourceforge.net/p/sdcc/code/HEAD/tree/trunk/sdcc-extra/developer%20meeting/2/

Best regards

Benedikt

*) I.e. those by SDCC developers. The one by a treedec developer is not 
included.

Re: [sdcc-devel] SDCC developer meeting 2 summary

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

Any references to "3.6.0" should have been "4.6.0" in my previous email.

Philipp

[sdcc-devel] SDCC developer meeting 2 summary

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

Dear SDCC developers and users,

I'll try to give a rough summary of my understanding of the results of
the SDCC developer meeting 2. Slides for three of the talks can be found
at
https://sourceforge.net/p/sdcc/code/HEAD/tree/trunk/sdcc-extra/developer%20meeting/2/,
and we'll likely have transscripts of talks and questions / answers for
them.

We recognize the need for better support for current µC in SDCC and our
rough plans for SDCC 3.6.0 are:

* Improve reliability by fixing bugs and adopting more tests from GCC
* Merge current upstream asxxxx into sdas (most of the other tasks
depend on this)
* Look into link-time elimination of unused functions and objects
* Further improve ISO C standard compliance
* Improve DWARF output
* Improve eZ80 and Rabbit support
* Introduce basic PDK16 support
* Introduce f8l support
* Improve S08 support
* Look into possible improvements in obtaining tree decompositions
(which SDCC uses in optimizations)

Some other tasks will most likely be postponed until after the 3.6.0
release:

* Introduce TLCS-870(/C,/C1) family support (hard to get chips, eval
boards, and documentation)
* Improve MCS-51 support (we recognize that this is our most important
target architecture, but there is substantial work required, and for
3.6.0 we'll be busy with a lot of other stuff)
* Atomics

Philipp

Re: [sdcc-devel] SDCC developer meeting 2: Bamberg, 2025-04-12 to 2025-04-13

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

Philipp Klaus Krause schreef op 2025-04-11 12:32:
> Am 15.03.25 um 12:30 schrieb Maarten Brock:
>> Hello Philipp,
>> 
>> Unfortunately I won't be able to come to the meeting in person.
>> But would you consider to also host the meeting online? E.g. through 
>> Jitsi?
>> I can probably provide a dedicated Jitsi server.
> 
> How can I connect to that server?
> 
> Philipp

Connect to https://jitsi.vanmierlo.com/SDCC-Developer-Meeting-2025

Maarten

Re: [sdcc-devel] SDCC developer meeting 2: Bamberg, 2025-04-11 to 2025-04-12 (date corrected)

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

Am 10.04.25 um 13:57 schrieb Michael Hawkins:
> Will the talks be recorded and uploaded somewhere for later viewing? That would be awesome!

We'll try, but can't promise anything.