sdcc-devel — Development chatter about SDCC

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

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

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

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

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

[Michael H. <mha...@gm...>]

Will the talks be recorded and uploaded somewhere for later viewing? That would be awesome!
-- 
Michael A Hawkins
Woodbury, CT 06798 USA
Mobile: 203-550-5502




On Thu, 2025-04-10 at 09:58 +0200, Benedikt Freisen via sdcc-devel wrote:
> 
> 
> We will see what we can do.
> However, the presentations will mostly be aimed at people who have never
> heard of SDCC before, which might be a bit boring to you.
> Furthermore, when native or fluent German speakers give presentations to
> a natively or fluently German speaking audience at a German university,
> it is rather common to compromise on English slides presented in German,
> to combine local practicality with the international audience's ability
> to read up on it.
> If we can host the presentations in a hybrid format at all, we will then
> have to figure out the most practical approach.
> 
> Benedikt
> 
> Am 10.04.25 um 07:25 schrieb Gabriele Gorla via sdcc-devel:
> > I'll be interested in joining virtual as well if there is a bridge.
> > thanks,
> > GG
> > 
> > On Wednesday, April 9, 2025 at 01:17:36 PM PDT, Philipp Klaus Krause <pk...@sp...> wrote:
> > 
> > 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.
> > > 
> > > Maarten
> > 
> > Sorry for the late reply, Maarten.
> > 
> > I don't have experience with hosting mixed meetings. The university that
> > hosts us will provide some suitable hardware, and I'll try to make this
> > work, but can't promise anything.
> > 
> > 
> > Philipp
> 
> 
> _______________________________________________
> sdcc-devel mailing list
> sdc...@li...
> https://lists.sourceforge.net/lists/listinfo/sdcc-devel

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 09:58 schrieb Benedikt Freisen via sdcc-devel:
> However, the presentations will mostly be aimed at people who have never
> heard of SDCC before, which might be a bit boring to you.

Indeed most of my first talk probably is not very interesting to SDCC
developers (but can be interesting to non-expert users), but the end
(last slide) is about current challenges SDCC does face, so that part,
and a possible discussion of it, is likely relevant for SDCC developers.
On the other hand, my second talk should be interesting to anyone
interested in the current or future z80-related ports.

> Furthermore, when native or fluent German speakers give presentations to
> a natively or fluently German speaking audience at a German university,
> it is rather common to compromise on English slides presented in German,
> to combine local practicality with the international audience's ability
> to read up on it.

Well, I'm used to presenting in English, so there shouldn't be a
language barrier for my two talks apart from my acccent (though in my
experience with hybrid meetings that I attended, an accent tends to add
to the difficulties inherent in hybrid meetings - I often did have
difficulties understanding remote participants with an accent, when I
was able to understand remote participants without such an accent and
in-person participants with an accent).

> If we can host the presentations in a hybrid format at all, we will then
> have to figure out the most practical approach.

Do we have anyone at the meeting in-person, woh has experience in
setting up hybrid meetings?

Philipp

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

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

We will see what we can do.
However, the presentations will mostly be aimed at people who have never
heard of SDCC before, which might be a bit boring to you.
Furthermore, when native or fluent German speakers give presentations to
a natively or fluently German speaking audience at a German university,
it is rather common to compromise on English slides presented in German,
to combine local practicality with the international audience's ability
to read up on it.
If we can host the presentations in a hybrid format at all, we will then
have to figure out the most practical approach.

Benedikt

Am 10.04.25 um 07:25 schrieb Gabriele Gorla via sdcc-devel:
> I'll be interested in joining virtual as well if there is a bridge.
> thanks,
> GG
>
> On Wednesday, April 9, 2025 at 01:17:36 PM PDT, Philipp Klaus Krause <pk...@sp...> wrote:
>
> 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.
>>
>> Maarten
>
> Sorry for the late reply, Maarten.
>
> I don't have experience with hosting mixed meetings. The university that
> hosts us will provide some suitable hardware, and I'll try to make this
> work, but can't promise anything.
>
>
> Philipp

Re: [sdcc-devel] regression suite test bug-1805702.c

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

The URL redirection on sourceforge.net leads me to
https://sourceforge.net/p/sdcc/bugs/1376/ where SVN revision
https://sourceforge.net/p/sdcc/code/4956/ is referenced.
My impression is that the internal function referenced in the regression
test has been chosen arbitrarily, because the bug itself is about
function declarations (with or without extern) overwriting previous
declarations, which apparently affected both, user defined and
predefined functions.
Disabling the test for an individual target looks like the easiest solution.

Benedikt

Am 10.04.25 um 07:51 schrieb Gabriele Gorla via sdcc-devel:
> Hello,
> I am implementing some of the fp code in assembly on the 6502 and now the test for  bug-1805702 fails to compile.
> the relevant part of the test is:
>
> float __fsmul (float, float) __nonbanked;
>
> float __fsmul (float a1, float a2) __nonbanked {
>    /* just for testing... */
>    return (a1 + a2);
> }
>
> void
> test(void)
> {
> #if !defined(__SDCC_pdk14) // Not enough RAM
>    foo = 10;
>
>    ASSERT(foo == 10);
> #endif
> }
>
> for resaons that I don't understand the test is redefining __fsmul to prove it can compile as the test itself is not doing anything at all.
> I looked in the svn log for clarification without success.
> Could someone explain what is the purpose of the test?
> Is it ok to disable when using assembly for __fsmul?
>
> thanks,
> GG

[sdcc-devel] regression suite test bug-1805702.c

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

Hello,
I am implementing some of the fp code in assembly on the 6502 and now the test for  bug-1805702 fails to compile.
the relevant part of the test is:

float __fsmul (float, float) __nonbanked;

float __fsmul (float a1, float a2) __nonbanked {
  /* just for testing... */
  return (a1 + a2);
}

void
test(void)
{
#if !defined(__SDCC_pdk14) // Not enough RAM
  foo = 10;

  ASSERT(foo == 10);
#endif
}

for resaons that I don't understand the test is redefining __fsmul to prove it can compile as the test itself is not doing anything at all.
I looked in the svn log for clarification without success.
Could someone explain what is the purpose of the test?
Is it ok to disable when using assembly for __fsmul? 

thanks,
GG

[sdcc-devel] optimizing conditional expressions

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

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?

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

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

I'll be interested in joining virtual as well if there is a bridge.
thanks,
GG





On Wednesday, April 9, 2025 at 01:17:36 PM PDT, Philipp Klaus Krause <pk...@sp...> wrote: 





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

Sorry for the late reply, Maarten.

I don't have experience with hosting mixed meetings. The university that
hosts us will provide some suitable hardware, and I'll try to make this
work, but can't promise anything.


Philipp



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

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

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

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

Sorry for the late reply, Maarten.

I don't have experience with hosting mixed meetings. The university that
hosts us will provide some suitable hardware, and I'll try to make this
work, but can't promise anything.

Philipp

[sdcc-devel] SDCC dev. meeting date: 2025-04-11 to 2025-04-12

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

Dear SDCC developers and users,

as Bendikt just noticed, the date was wrong in the subject of my
previous mail about the SDCC developer meeting 2. Sorry for this
mistake, I hope it didn't inconvenience anyone.

There will be four short talks on the first day of the meeting, with
plenty of time for discussion.

Philipp

P.S.: We do have a poster for the meeting at
https://sourceforge.net/p/sdcc/code/HEAD/tree/trunk/sdcc-extra/developer%20meeting/2/Poster.pdf

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

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

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.

Maarten

Philipp Klaus Krause schreef op 2025-03-13 14:04:
> Dear SDCC developers,
> 
> the location for the meeting has changed from room WE5/02.020 to
> WE5/04.004. I've updated the poster draft at
> https://sourceforge.net/p/sdcc/code/HEAD/tree/trunk/sdcc-extra/developer%20meeting/2/Poster.pdf
> accordingly.
> 
> Would any of you like to give a talk at the meeting (so far we have 3
> short talks)?
> 
> Philipp

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

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

Dear SDCC developers,

the location for the meeting has changed from room WE5/02.020 to
WE5/04.004. I've updated the poster draft at
https://sourceforge.net/p/sdcc/code/HEAD/tree/trunk/sdcc-extra/developer%20meeting/2/Poster.pdf
accordingly.

Would any of you like to give a talk at the meeting (so far we have 3
short talks)?

Philipp

Re: [sdcc-devel] Adding TMS9900 back end

[Michael H. <mha...@gm...>]

Yes, and that is certainly something I keep in mind. :-)

It's just that my charitable spirit is curtailed by a world defined by scarcity of time.

-- 
Michael A Hawkins
Stamford, CT 06902 USA
Mobile: 203-550-5502



On Sun, 2025-02-16 at 23:03 +0100, Steve Schnepp wrote:
> 8080/8085 support might benefit more folks than just your next project ;-)
> 
> _______________________________________________
> sdcc-devel mailing list
> sdc...@li...
> https://lists.sourceforge.net/lists/listinfo/sdcc-devel