sdcc-devel — Development chatter about SDCC

Re: [sdcc-devel] About optimization across multiple .c files in SDCC

[Oleg E. <ole...@t-...>]

On Wed, 2024-09-04 at 08:24 +0200, Philipp Klaus Krause wrote:
> Am 29.08.24 um 14:25 schrieb Oleg Endo:
> > 7) Automatic shortening of mcs51 lcall / ljmp to acall / ajmp.
> 
> I think This would be much harder. For this, the linker needs much more
> understanding of the code than for the other features requested so far.
> After all, optimizing a lcall / ljmp in the middle of some code into
> acall / ajmp changes code size, and thus requires changes in relative
> jumps over that place.
> 

Yes, of course linker relaxation can be a tricky thing to do.  If the linker
does the relaxation, it will require the linker to parse and understand the
whole program (to catch cases as you mention above).

The alternative is to compile the whole software effectively as a single
unit (LTO style) and let the compiler figure out whether ajmp/acall would be
in range or not.

Best regards,
Oleg Endo

Re: [sdcc-devel] About optimization across multiple .c files in SDCC

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

Am 29.08.24 um 14:25 schrieb Oleg Endo:
> 7) Automatic shortening of mcs51 lcall / ljmp to acall / ajmp.

I think This would be much harder. For this, the linker needs much more
understanding of the code than for the other features requested so far.
After all, optimizing a lcall / ljmp in the middle of some code into
acall / ajmp changes code size, and thus requires changes in relative
jumps over that place.

Philipp

Re: [sdcc-devel] About optimization across multiple .c files in SDCC

[Oleg E. <ole...@t-...>]

On Mon, 2024-07-15 at 14:22 +0900, Oleg Endo wrote:
> 
> On Sat, 2024-07-13 at 09:54 +0200, Maarten Brock wrote:
> > Oleg Endo schreef op 2024-07-09 04:00:
> > > On top of that, the linker doesn't even check for overlapping bank 
> > > sections,
> > > and doesn't provide any feedback on the utilization of each bank.  I've
> > > patched that in my local branch, which makes it a lot more practical.
> > 
> > Are you sure? The linker is supposed to check against overlapping bank 
> > sections.
> 
> Well, some years ago, when I needed that functionality, I wrote a patch for
> the linker that is included in the SDCC codebase to do exactly that.  Last
> time I checked (about 1 year ago) it still applied.
> 
> 

Let me quote from the SDCC manual:


-----
To create a function that can be called from another bank it requires the
keyword __banked. The caller must see this in the prototype of the callee
and the callee needs it for a proper return. Called functions within the
same bank as the caller do not need the __banked keyword nor do functions in
the common area. Beware: SDCC does not know or check if functions are in the
same bank. This is your responsibility!

-----
When linking your objects you need to tell the linker where to put your
segments. To do this you use the following command line option to SDCC: -Wl-
b BANK1=0x18000 (See 3.3.5). This sets the virtual start address
of this segment. It sets the banknumber to 0x01 and maps the bank to 0x8000
and up. The linker will not check for overflows, again this is your
responsibility.

-----

>From a user's perspective, this is poor man's tech and not very inviting, to
put it mildly.  Lots of room for improvement.

Perhaps yet another reason why folks choose other commercial compilers over
SDCC.


Best regards,
Oleg Endo

Re: [sdcc-devel] About optimization across multiple .c files in SDCC

[Oleg E. <ole...@t-...>]

On Tue, 2024-07-09 at 11:00 +0900, Oleg Endo wrote:
> 
> 6) Automatic "layout" of the flash space for banked vs. non-banked functions
> (and constant .rodata objects).
> 
> As of now, writing larger mcs51 banked software with SDCC is tedious.  Need
> to specify the code bank number manually for each translation unit.  Banks
> can't be mixed inside a translation unit, which makes the software source
> unnecessarily convoluted.
> 
> On top of that, the linker doesn't even check for overlapping bank sections,
> and doesn't provide any feedback on the utilization of each bank.  I've
> patched that in my local branch, which makes it a lot more practical.
> 

7) Automatic shortening of mcs51 lcall / ljmp to acall / ajmp.

Best regards,
Oleg Endo

Re: [sdcc-devel] Funding application

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

Am 22.08.24 um 11:01 schrieb 月明风清 via sdcc-devel:
> I want to know the work in detail. :)

Well, the application hasn't been written yet. So we still have the
freedom to put tasks into the application that SDCC developers think are
useful and that they want to work on.

Some rough guidelines: I intend to submit an application to the NLnet
NGI0 Commons Fund.

* NLnet is based in the EU, and they can fund anyone within the EU, and
also projects where the majority of the work is done in the EU. There
are some issues with funding developers in certain countries, AFAIK in
particular Russia, USA, Iran, North Korea. A potential issue is that
AFAIK, NGI0 funding for 2025 an onwards has not yet been officially
approved by the EU.

* The work should be relevant for modern embedded systems.
Retrocomputing stuff is AFAIK outside the scope of NGI0 funding. There
might be other, more culturally-oriented funding sources for
retrocomputing stuff, but I don't know much about that. There's the
"Awesome Foundation" which might fund something such work, but I'm in
Germany and they mostly fund work in the US and UK, and do not fund work
in Germany.

* If funding from NLnet received by a developer is taxable income, and
in case it is taxed, how, depends on your local tax laws, and their
interpretation. Unfortunately, for many countries, this is simply not
known yet.

Philipp

Re: [sdcc-devel] Funding application

[<445...@qq...>]

I want to know the work in detail. :)




月明风清
445...@qq...



 




------------------ Original ------------------
From:                                                                                                                        "Development chatter about sdcc"                                                                                    <pk...@sp...&gt;;
Date:&nbsp;Mon, Aug 5, 2024 06:04 PM
To:&nbsp;"Development chatter about sdcc"<sdc...@li...&gt;;

Subject:&nbsp;[sdcc-devel] Funding application



Dear SDCC developers,

I intend to attempt another application for funding for some paid work
on SDCC. Are any of you interested in participating?

Philipp


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

Re: [sdcc-devel] No 32-bit Snapshots since two weeks

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

Am 18.08.24 um 08:45 schrieb Philipp Klaus Krause:
> Am 18.08.24 um 06:35 schrieb Erik Petrich:
>>
>> /home/sdcc-builder/build/sdcc-build/orig/sdcc/src/f8/gen.c: In function
>> ‘genRightShift’:
>> /home/sdcc-builder/build/sdcc-build/orig/sdcc/src/f8/gen.c:5364:7:
>> error: a label can only be part of a statement and a declaration is not
>> a statement
>> […]
>>
>> Looks like some sort of portability issue with the f8 code that was
>> merged in on August 4.
>
> Thanks for having a look. That's my fault: labels before declarations
> are an ISO C23 feature, but SDCC is supposed to be written in ISO C17. I
> fixed it today.
>
> Philipp

In case someone was wondering why the snapshots aren't back yet: I found
and removed another use of a C23 feature in the f8 port today. That
should be the laat one, so I guess 32-bit snapshots will be back tomorrow.

Philipp

[sdcc-devel] Rough ideas for 4.5.0

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

My personal impression from the bug reports is that 4.4.0 is quite good,
except for Windows-specific issues. And AFAIK, about half our users do
use Windows.

My original plans for 4.5.0 (mcs51 codegen rewrite for new register
allocator) got delayed, so nothing of that will make it to trunk before
4.5.0.

So my idea was to try to look into those Windows issues a bit, and see
if I can fix some of them (despite not being a Windows user), and fix
that code size/speed regression
(https://sourceforge.net/p/sdcc/feature-requests/937/) I introduced when
fixing a bug recently, so 4.5.0 would be for Windows users what 4.4.0
was for the non-windows users. Once those fixes are in, we could look
into a release schedule for 4.5.0, possibly aiming for a release in the
first few days of 2025.

Philipp

Re: [sdcc-devel] No 32-bit Snapshots since two weeks

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

Am 18.08.24 um 06:35 schrieb Erik Petrich:
>
> /home/sdcc-builder/build/sdcc-build/orig/sdcc/src/f8/gen.c: In function
> ‘genRightShift’:
> /home/sdcc-builder/build/sdcc-build/orig/sdcc/src/f8/gen.c:5364:7:
> error: a label can only be part of a statement and a declaration is not
> a statement
> […]
>
> Looks like some sort of portability issue with the f8 code that was
> merged in on August 4.

Thanks for having a look. That's my fault: labels before declarations
are an ISO C23 feature, but SDCC is supposed to be written in ISO C17. I
fixed it today.

Philipp

Re: [sdcc-devel] No 32-bit Snapshots since two weeks

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

On Sat, 2024-08-17 at 18:38 +0200, Philipp Klaus Krause wrote:
> Accordingto the snapshots page, we haven't had 32-bit GNU/Linux or
> Windows Snapshots for two weeks.
> 
> Anyone know more about the issue?
> 
> Philipp

/home/sdcc-builder/build/sdcc-build/orig/sdcc/src/f8/gen.c: In function
‘genRightShift’:
/home/sdcc-builder/build/sdcc-build/orig/sdcc/src/f8/gen.c:5364:7:
error: a label can only be part of a statement and a declaration is not
a statement
       bool xl_dead = regDead (XL_IDX, ic) && (premoved_count ? false :
(right->aop->regs[XL_IDX] < 0));
       ^
/home/sdcc-builder/build/sdcc-build/orig/sdcc/src/f8/gen.c:5365:7:
error: expected expression before ‘_Bool’
       bool xh_dead = regDead (XH_IDX, ic) && (right->aop->regs[XH_IDX]
< 0 || premoved_count);
       ^
/home/sdcc-builder/build/sdcc-build/orig/sdcc/src/f8/gen.c:5375:45:
error: ‘xh_dead’ undeclared (first use in this function)
       genMove (shiftop, left->aop, xl_dead, xh_dead, y_dead, false);
                                             ^~~~~~~
/home/sdcc-builder/build/sdcc-build/orig/sdcc/src/f8/gen.c:5375:45:
note: each undeclared identifier is reported only once for each
function it appears in
<builtin>: recipe for target 'gen.o' failed
make[5]: *** [gen.o] Error 1
make[5]: Target 'all' not remade because of errors.
Makefile:57: recipe for target 'f8/port.a' failed
make[4]: *** [f8/port.a] Error 2
make[4]: Target 'all' not remade because of errors.
Makefile:153: recipe for target 'sdcc-cc' failed
make[3]: *** [sdcc-cc] Error 2
make[3]: Target 'sdcc' not remade because of errors.
components/sdcc.mk:41: recipe for target 'sdcc-build' failed
make[2]: *** [sdcc-build] Error 2

Looks like some sort of portability issue with the f8 code that was
merged in on August 4.

  Erik

Re: [sdcc-devel] LTO I have done in recent 4 months

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

Am 16.08.24 um 12:12 schrieb Oleg Endo:
>
> On Fri, 2024-08-16 at 17:10 +0800, 月明风清 via sdcc-devel wrote:
>>
>> Acording to my work requirement, a small 8-bit mcu with 9bit RAM
>> addr 13bit ROM addr，without banking. I use SDCC and  gputils for
>> it. I have tried a lot of. Recently, I did 2 LTO pass in gputils's
>> linker: 1) remove unused global variable (initialized or
>> uninitialized). 2) Reuse temporary ram variable accross different
>> functions. In this pass , I  construct the call-graph with main、
>> intterrupt0、interrupt1 as the root. when two functions are in one
>> call-graph, they can share compiler allocated global ram
>> variables. Great, it works.
>>
>>
>
> Wow, congratulations.  I wish we had this working for other backends
> of SDCC.

Regarding the other backend, assuming we use the asxxxx linker:

* I hadn't thought about the RAM reuse yet. Obviously this only matters
to the ports that actually put local variables into RAM, as opposed to
on the stack. But for thisports it could be quite useful.
* The linker already can handle dependenices at the module level. And
for libraries it can handle multiple modules per file. So we'd only have
to get the linker to accept multiple modules per .rel file, and SDCC to
split the .rel files into multiple modules. Still will be some work,
including testing.

Philipp

Re: [sdcc-devel] LTO I have done in recent 4 months

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

Am 16.08.24 um 11:10 schrieb 月明风清 via sdcc-devel:
>
> Acording to my work requirement, a small 8-bit mcu with 9bit RAM addr
> 13bit ROM addr，without banking.
> I use SDCC and  gputils for it. I have tried a lot of.
> Recently, I did 2 LTO pass in gputils's linker:
> 1) remove unused global variable (initialized or uninitialized).
> 2) Reuse temporary ram variable accross different functions.
> In this pass , I  construct the call-graph with main、intterrupt0、
> interrupt1 as the root. when two functions are in one call-graph, they
> can share compiler allocated global ram variables.
> Great, it works.

Sounds useful, though the SDCC pic ports are unmaintained. Did you
submit your work to upstream gputils, e.g. via
https://sourceforge.net/p/gputils/patches/?

Philipp

[sdcc-devel] No 32-bit Snapshots since two weeks

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

Accordingto the snapshots page, we haven't had 32-bit GNU/Linux or
Windows Snapshots for two weeks.

Anyone know more about the issue?

Philipp

Re: [sdcc-devel] LTO I have done in recent 4 months

[Oleg E. <ole...@t-...>]

On Fri, 2024-08-16 at 17:10 +0800, 月明风清 via sdcc-devel wrote:
> 
> Acording to my work requirement, a small 8-bit mcu with 9bit RAM addr 13bit ROM addr，without banking.
> I use SDCC and  gputils for it. I have tried a lot of. 
> Recently, I did 2 LTO pass in gputils's linker:
> 1) remove unused global variable (initialized or uninitialized).
> 2) Reuse temporary ram variable accross different functions. 
> In this pass , I  construct the call-graph with main、intterrupt0、interrupt1 as the root. when two functions are in one call-graph, they can share compiler allocated global ram variables.
> Great, it works.
> 
> 

Wow, congratulations.  I wish we had this working for other backends of
SDCC.

Best regards,
Oleg Endo

[sdcc-devel] LTO I have done in recent 4 months

[<445...@qq...>]

Acording to my work requirement, a small 8-bit mcu with 9bit RAM addr 13bit ROM addr，without banking.
I use SDCC and  gputils for it. I have tried a lot of. 
Recently, I did 2 LTO pass in gputils's linker:
1) remove unused global variable (initialized or uninitialized).
2) Reuse temporary ram variable accross different functions. 
In this pass , I  construct the call-graph with main、intterrupt0、interrupt1 as the root. when two functions are in one call-graph, they can share compiler allocated global ram variables.
Great, it works.


月明风清
445...@qq...



 

[sdcc-devel] Packaging SDCC for Msys2 MINGW-packages

[Joel H. <jo...@ai...>]

Hi Folks,

I'm working on packaging SDCC 4.4.0 for Msys2/MINGW, and I'm having an 
issue with the build.

The current issue I have is in regard to sdcc trying to execute 
sdcpp.exe during the build. I don't understand how this is meant to 
work, because bin/sdcpp is a shell script. However, sdcc when executing 
the preprocessor via sdcc_system(), tries to execute sdcpp.exe via 
system(), which wouldn't work even if the file name was correct.

There must be a solution to this issue, because sdcc has Windows 
releases already, so can someone help me understand what I'm doing wrong 
here?

Kind Regards
Joel Holdsworth

[sdcc-devel] Funding application

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

Dear SDCC developers,

I intend to attempt another application for funding for some paid work
on SDCC. Are any of you interested in participating?

Philipp

Re: [sdcc-devel] Putting the f8 port into trunk

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

Why not? I mean, it's not like someone will have too much expectations ;-)

Therefore, if it doesn't impede any other arch, I don't see any reason not
to.

Cheers,

-- 
Steve

On Fri, Aug 2, 2024, 15:32 Philipp Klaus Krause <pk...@sp...> wrote:

> The f8 is still a work in progress; the instruction set won't change
> much, but the opcode map will. No hardware implementation exists. There
> is Verilog code that can be used to have an f8 on two FPGA boards
> (tested, can run simple programs, such as Drhystone and Whetstone).
> Currently, the f8 port lives in the f8 branch (apart from uCsim in trunk
> having f8 support).
> Would it be ok to put the f8 port into trunk soon?
>
> Philipp
>
>
> _______________________________________________
> sdcc-devel mailing list
> sdc...@li...
> https://lists.sourceforge.net/lists/listinfo/sdcc-devel
>
-- 
Steve SCHNEPP

[sdcc-devel] Putting the f8 port into trunk

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

The f8 is still a work in progress; the instruction set won't change
much, but the opcode map will. No hardware implementation exists. There
is Verilog code that can be used to have an f8 on two FPGA boards
(tested, can run simple programs, such as Drhystone and Whetstone).
Currently, the f8 port lives in the f8 branch (apart from uCsim in trunk
having f8 support).
Would it be ok to put the f8 port into trunk soon?

Philipp

Re: [sdcc-devel] [sdcc:code] New commit [r14923] by maartenbrock

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

Philipp Klaus Krause schreef op 2024-07-17 08:26:
> Am 17.07.24 um 01:57 schrieb Small Device C Compiler (SDCC) SVN 
> repository:
>> * device/lib/z80/__itoa.s,
>> * device/lib/z80/__ltoa.s,
>> * device/lib/z80/__mulsint2slong.s,
>> * device/lib/z80/__strreverse.s,
>> * device/lib/z80/__uitobcd.s,
>> * device/lib/z80/abs.s,
>> * device/lib/z80/atomic_flag_test_and_set.s,
>> * device/lib/z80/crt0.s,
>> * device/lib/z80/divmixed.s,
>> * device/lib/z80/divsigned.s,
>> * device/lib/z80/divunsigned.s,
>> * device/lib/z80/memcpy.s,
>> * device/lib/z80/memmove.s,
>> * device/lib/z80/modmixed.s,
>> * device/lib/z80/modsigned.s,
>> * device/lib/z80/modunsigned.s,
>> * device/lib/z80/mul.s,
>> * device/lib/z80/mulchar.s,
>> * device/lib/z80/setjmp.s,
>> * device/lib/z80/strcpy.s,
>> * device/lib/z80/strlen.s: added .module <name> & .optsdcc -mz80 
>> sdcccall(1)
>> […]
>> * src/z80/main.c (_z80_genAssemblerStart): new, added to emit 
>> .optsdcc,
>> includes calling convention
>> * src/z80/mappings.i: added .optsdcc
> 
> This means that we now get an "Internal Version Error" when trying to
> link object files compiled with --sdcccall 1 to those compiled with
> --sdcccall 0

Correct.

> (or objects from asm source files without the explicit .optsdcc).

Not correct. When there is no .optsdcc line the check is not performed.

> IMO, this is problematic, since it breaks compatibility. In particular,
> we previously supported such use-cases:
> 
> test.c:
> void f(void) __sdcccall(0);
> 
> void main(void)
> {
> }
> 
> test1.c:
> void f(void)
> {
> }
> 
> Compiling test.c with -sdcccall 1 (i.e. the default), while compiling
> test1.c with --sdcccall 0.

That is just plain stupid. I see no reason why SDCC should support that.
But for those who really want this, there is already the option
--no-optsdcc-in-asm which suppresses the .optsdcc line.

> AFAIK, the main use case if libraries partially written in assembler to
> the __sdcccalll(0) convention. By just adding __sdcccall(0) to
> declarations in headers, these libraries were used in programs that
> otherwise use the new default calling convention.
> 
> Philipp

Maarten

Re: [sdcc-devel] [sdcc:code] New commit [r14923] by maartenbrock

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

Am 17.07.24 um 01:57 schrieb Small Device C Compiler (SDCC) SVN repository:
> * device/lib/z80/__itoa.s,
> * device/lib/z80/__ltoa.s,
> * device/lib/z80/__mulsint2slong.s,
> * device/lib/z80/__strreverse.s,
> * device/lib/z80/__uitobcd.s,
> * device/lib/z80/abs.s,
> * device/lib/z80/atomic_flag_test_and_set.s,
> * device/lib/z80/crt0.s,
> * device/lib/z80/divmixed.s,
> * device/lib/z80/divsigned.s,
> * device/lib/z80/divunsigned.s,
> * device/lib/z80/memcpy.s,
> * device/lib/z80/memmove.s,
> * device/lib/z80/modmixed.s,
> * device/lib/z80/modsigned.s,
> * device/lib/z80/modunsigned.s,
> * device/lib/z80/mul.s,
> * device/lib/z80/mulchar.s,
> * device/lib/z80/setjmp.s,
> * device/lib/z80/strcpy.s,
> * device/lib/z80/strlen.s: added .module <name> & .optsdcc -mz80 sdcccall(1)
> […]
> * src/z80/main.c (_z80_genAssemblerStart): new, added to emit .optsdcc,
> includes calling convention
> * src/z80/mappings.i: added .optsdcc

This means that we now get an "Internal Version Error" when trying to
link object files compiled with --sdcccall 1 to those compiled with
--sdcccall 0 (or objects from asm source files without the explicit
.optsdcc).

IMO, this is problematic, since it breaks compatibility. In particular,
we previously supported such use-cases:

test.c:
void f(void) __sdcccall(0);

void main(void)
{
}

test1.c:
void f(void)
{
}

Compiling test.c with -sdcccall 1 (i.e. the default), while compiling
test1.c with --sdcccall 0.
AFAIK, the main use case if libraries partially written in assembler to
the __sdcccalll(0) convention. By just adding __sdcccall(0) to
declarations in headers, these libraries were used in programs that
otherwise use the new default calling convention.

Philipp

Re: [sdcc-devel] About optimization across multiple .c files in SDCC

[Oleg E. <ole...@t-...>]

On Sat, 2024-07-13 at 09:54 +0200, Maarten Brock wrote:
> Oleg Endo schreef op 2024-07-09 04:00:
> > On top of that, the linker doesn't even check for overlapping bank 
> > sections,
> > and doesn't provide any feedback on the utilization of each bank.  I've
> > patched that in my local branch, which makes it a lot more practical.
> 
> Are you sure? The linker is supposed to check against overlapping bank 
> sections.

Well, some years ago, when I needed that functionality, I wrote a patch for
the linker that is included in the SDCC codebase to do exactly that.  Last
time I checked (about 1 year ago) it still applied.

There are several other issues regarding the banked code support which ought
to work but are not.  I guess nobody has been really using SDCC to make
larger mcs51 applications.


> And the utilization can be checked in the map file, I believe.
> 

Yes, that's what I'm doing.


Best regards,
Oleg Endo

Re: [sdcc-devel] About optimization across multiple .c files in SDCC

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

Oleg Endo schreef op 2024-07-09 04:00:
> On top of that, the linker doesn't even check for overlapping bank 
> sections,
> and doesn't provide any feedback on the utilization of each bank.  I've
> patched that in my local branch, which makes it a lot more practical.

Are you sure? The linker is supposed to check against overlapping bank 
sections.
And the utilization can be checked in the map file, I believe.

Kind regards,
Maarten Brock

Re: [sdcc-devel] Register allocation in MCS51

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

Using standard syntax is always better, indeed.

-- 
Steve SCHNEPP

Re: [sdcc-devel] Register allocation in MCS51

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

Am 09.07.24 um 16:07 schrieb Steve Schnepp:
> What does "flexible calling convention in the compiler" mean ?
> Not saying practical, but would it be doable to have a fully flexible
> calling convention ?
>
> something akin to
>
> __reg(a) char my_add( __reg(a) char first, __reg(r0) char second) {
>     return first + second;
> }

AFAIR, there was a similar discussion when we worked on calling
conventions for z80. Since the calling convention does not make a
difference inthe abstract machine, it would probably be a good idea to
use C23 attributes instead of inventing new syntax.
But for that we'd need to improve our support of C23 attributes in the
frontend first.

Philipp