sdcc-devel — Development chatter about SDCC

Re: [sdcc-devel] SDCC 4.6.0 planning

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

Known blocking issues for 4.6.0:

* Fixing the cpp and binutils Msys2 issues (also merging current upstreams).
* Bug #3972 (make install issue).

Remaining wanted functionality that might still make it:

* f8(l) opcode map fix.
* _Optional updates for current TS draft.
* Various bug fixes.

In particular, the r4k port now works well for real hardware, __far now 
works for all Rabbits. The medium memory model for Rabbits on the other 
hand will have to be postponed beyond 4.6.0.

Due to the large number of changes since 4.5.0, I'd expect that we need 
more time from RC1 to release than usual.

Philipp

Re: [sdcc-devel] peephole optimizations

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

Hello,

Do you have a name I can address you by?

It is great that you now ran the full test-mcs51 memory model tests and
without failures. This gives a much higher confidence in your 
modifications.

I obviously find way too little time to invest into SDCC these days.
And as such I have not looked into what you modified. I take your word 
on
it.

It would be nice to know if all rules have been triggered at least once.
It would also be nice to know the statistics of the improvements 
(bytes).

Please upload your patches in the patch tracker. Even when it isn't 
applied
by the developers, it will still be visible for other users to pick up 
and
apply themselves.

Kind regards,
Maarten

kimstik wrote on 2026-03-25 12:24:
> I'm not an expert in SDCC's test infrastructure internals, so I limited
> myself initially to test-mcs51-small.
> Now ran the full test-mcs51 - passes on all memory models.
> Maarten, I really appreciate your activity on SDCC, and of course I'm 
> not
> in a position to point anyone where to look and what to look for.
> 
> It felt practical to run CI on my patches before starting the 
> conversation,
> and not to bother anyone with
> untested ones - plus get a working binary as an artifact.
> 
> These are prototypes, wanted to get feedback on the approach first.
> Happy to upload to SF once we agree on direction.
> Been following ticket #466 which seems to have stalled. Honestly a bit
> hesitant to create
> yet another one that might get lost - we're all busy people, after all.
> 
> Briefly what I have: 3 main engine features.
> 1. "tail" keyword - forces applying the match from the end of the match
> list. Naturally helps trigger cascade chains.
> 2. "retrack" keyword - re-run rtrack after replacement. Allows 
> restarting
> value tracking that had no chance to fire before.
> 3. operandOffset(%1 %2 N) - generalized offset match, checks if op1 == 
> op2
> + N. The beauty is that it covers constant symbols with offset 
> (symbolic
> comparison).
> 
> The last one handles sequences like:
>   mov  dptr,#(_serno + 0x0002)
>   mov  dptr,#(_serno + 0x0003)
> 
> All three reduce the number of rules needed and retrigger optimizations
> that otherwise had no chance to fire.
> Deisn made in a way to not affect perfomance, and i do not notice any
> performance degradation.
> They intended to efficiently provoke avlanche effekts and create longer
> chain of triggered rules.
> Do less to get more.
> 
> On Tue, 24 Mar 2026 at 17:31, Maarten Brock <sou...@ds...>
> wrote:
> 
>> Hello,
>> 
>> kimstik wrote on 2026-03-24 14:01:
>> > I'm a big fan of peephole optimizations.
>> > Recently I went through the MCS51 rule definitions and noticed many
>> > rules
>> > that would benefit from notUsed('c') guards. I tried to implement it.
>> > Seems to work. Then more ideas came - like notUsed('a' 'b' 'c').
>> > Implemented... basically I couldn't stop ;)
>> >
>> > So here's what I ended up with. On the engine side: notUsed('a' 'b'
>> > 'c'),
>> > a "tail" keyword that applies the rule at the last match (handy for
>> > cascade
>> > chains),
>> > "retrack" to re-run rtrack after replacement,
>> > operandOffset() for comparing symbolic addresses, --fixed-regbank to
>> > skip
>> > the redundant mov psw in bank-0 ISRs, and _Noreturn support in scan4op.
>> >
>> > I also wrote 29 new peephole rules. The biggest wins are consecutive
>> > zero-load batching via clr a (96 hits across 14 test projects),
>> > sequential DPTR collapse to inc dptr (51 hits, 7 projects), and a few
>> > others like redundant DPTR reload removal and mul-by-power-of-2
>> > strength
>> > reduction.
>> >
>> > No regressions on sdcc-test/support/regression test-mcs51-small.
>> > I also compiled 17 different real-world projects from the web - no
>> > visible
>> > issues on asm-diff.
>> 
>> How does the full test-mcs51 perform?
>> 
>> > I'd love for this to be useful in the main codebase. Feedback welcome.
>> >
>> > https://github.com/kimstik/sdcc-i51peep/tree/master/patches
>> 
>> The SDCC developers are not going to scatter-gather patches from all
>> sorts
>> of different places. Nor should SDCC users need to search the entire
>> internet
>> for all possibly useful patches. So, please upload your patches in the
>> patch-tracker at sourceforge.
>> 
>> Kind regards,
>> Maarten Brock

Re: [sdcc-devel] peephole optimizations

[kimstik <ki...@gm...>]

I'm not an expert in SDCC's test infrastructure internals, so I limited
myself initially to test-mcs51-small.
Now ran the full test-mcs51 - passes on all memory models.
Maarten, I really appreciate your activity on SDCC, and of course I'm not
in a position to point anyone where to look and what to look for.

It felt practical to run CI on my patches before starting the conversation,
and not to bother anyone with
untested ones - plus get a working binary as an artifact.

These are prototypes, wanted to get feedback on the approach first.
Happy to upload to SF once we agree on direction.
Been following ticket #466 which seems to have stalled. Honestly a bit
hesitant to create
yet another one that might get lost - we're all busy people, after all.

Briefly what I have: 3 main engine features.
1. "tail" keyword - forces applying the match from the end of the match
list. Naturally helps trigger cascade chains.
2. "retrack" keyword - re-run rtrack after replacement. Allows restarting
value tracking that had no chance to fire before.
3. operandOffset(%1 %2 N) - generalized offset match, checks if op1 == op2
+ N. The beauty is that it covers constant symbols with offset (symbolic
comparison).

The last one handles sequences like:
  mov  dptr,#(_serno + 0x0002)
  mov  dptr,#(_serno + 0x0003)

All three reduce the number of rules needed and retrigger optimizations
that otherwise had no chance to fire.
Deisn made in a way to not affect perfomance, and i do not notice any
performance degradation.
They intended to efficiently provoke avlanche effekts and create longer
chain of triggered rules.
Do less to get more.

On Tue, 24 Mar 2026 at 17:31, Maarten Brock <sou...@ds...>
wrote:

> Hello,
>
> kimstik wrote on 2026-03-24 14:01:
> > I'm a big fan of peephole optimizations.
> > Recently I went through the MCS51 rule definitions and noticed many
> > rules
> > that would benefit from notUsed('c') guards. I tried to implement it.
> > Seems to work. Then more ideas came - like notUsed('a' 'b' 'c').
> > Implemented... basically I couldn't stop ;)
> >
> > So here's what I ended up with. On the engine side: notUsed('a' 'b'
> > 'c'),
> > a "tail" keyword that applies the rule at the last match (handy for
> > cascade
> > chains),
> > "retrack" to re-run rtrack after replacement,
> > operandOffset() for comparing symbolic addresses, --fixed-regbank to
> > skip
> > the redundant mov psw in bank-0 ISRs, and _Noreturn support in scan4op.
> >
> > I also wrote 29 new peephole rules. The biggest wins are consecutive
> > zero-load batching via clr a (96 hits across 14 test projects),
> > sequential DPTR collapse to inc dptr (51 hits, 7 projects), and a few
> > others like redundant DPTR reload removal and mul-by-power-of-2
> > strength
> > reduction.
> >
> > No regressions on sdcc-test/support/regression test-mcs51-small.
> > I also compiled 17 different real-world projects from the web - no
> > visible
> > issues on asm-diff.
>
> How does the full test-mcs51 perform?
>
> > I'd love for this to be useful in the main codebase. Feedback welcome.
> >
> > https://github.com/kimstik/sdcc-i51peep/tree/master/patches
>
> The SDCC developers are not going to scatter-gather patches from all
> sorts
> of different places. Nor should SDCC users need to search the entire
> internet
> for all possibly useful patches. So, please upload your patches in the
> patch-tracker at sourceforge.
>
> Kind regards,
> Maarten Brock
>

Re: [sdcc-devel] peephole optimizations

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

Hello,

kimstik wrote on 2026-03-24 14:01:
> I'm a big fan of peephole optimizations.
> Recently I went through the MCS51 rule definitions and noticed many 
> rules
> that would benefit from notUsed('c') guards. I tried to implement it.
> Seems to work. Then more ideas came - like notUsed('a' 'b' 'c').
> Implemented... basically I couldn't stop ;)
> 
> So here's what I ended up with. On the engine side: notUsed('a' 'b' 
> 'c'),
> a "tail" keyword that applies the rule at the last match (handy for 
> cascade
> chains),
> "retrack" to re-run rtrack after replacement,
> operandOffset() for comparing symbolic addresses, --fixed-regbank to 
> skip
> the redundant mov psw in bank-0 ISRs, and _Noreturn support in scan4op.
> 
> I also wrote 29 new peephole rules. The biggest wins are consecutive
> zero-load batching via clr a (96 hits across 14 test projects),
> sequential DPTR collapse to inc dptr (51 hits, 7 projects), and a few
> others like redundant DPTR reload removal and mul-by-power-of-2 
> strength
> reduction.
> 
> No regressions on sdcc-test/support/regression test-mcs51-small.
> I also compiled 17 different real-world projects from the web - no 
> visible
> issues on asm-diff.

How does the full test-mcs51 perform?

> I'd love for this to be useful in the main codebase. Feedback welcome.
> 
> https://github.com/kimstik/sdcc-i51peep/tree/master/patches

The SDCC developers are not going to scatter-gather patches from all 
sorts
of different places. Nor should SDCC users need to search the entire 
internet
for all possibly useful patches. So, please upload your patches in the
patch-tracker at sourceforge.

Kind regards,
Maarten Brock

Re: [sdcc-devel] peephole optimizations

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

On Tue, 2026-03-24 at 14:01 +0100, kimstik wrote:
> I'm a big fan of peephole optimizations.
> Recently I went through the MCS51 rule definitions and noticed many rules
> that would benefit from notUsed('c') guards. I tried to implement it.
> Seems to work. Then more ideas came - like notUsed('a' 'b' 'c').
> Implemented... basically I couldn't stop ;)
> 
> So here's what I ended up with. On the engine side: notUsed('a' 'b' 'c'),
> a "tail" keyword that applies the rule at the last match (handy for cascade chains),
> "retrack" to re-run rtrack after replacement,
> operandOffset() for comparing symbolic addresses, --fixed-regbank to skip
> the redundant mov psw in bank-0 ISRs, and _Noreturn support in scan4op.
> 
> I also wrote 29 new peephole rules. The biggest wins are consecutive
> zero-load batching via clr a (96 hits across 14 test projects),
> sequential DPTR collapse to inc dptr (51 hits, 7 projects), and a few
> others like redundant DPTR reload removal and mul-by-power-of-2 strength
> reduction.
> 
> No regressions on sdcc-test/support/regression test-mcs51-small. 
> I also compiled 17 different real-world projects from the web - no visible issues on asm-diff.
> 
> I'd love for this to be useful in the main codebase. Feedback welcome.
> 
> https://github.com/kimstik/sdcc-i51peep/tree/master/patches
> 

I have created a ticket for this topic a while ago
https://sourceforge.net/p/sdcc/patches/466/?page=3

I've been sharing my version of the peephole patterns file there.
However, some of them might not work on the vanilla/trunk version.

Best regards,
Oleg Endo

[sdcc-devel] peephole optimizations

[kimstik <ki...@gm...>]

I'm a big fan of peephole optimizations.
Recently I went through the MCS51 rule definitions and noticed many rules
that would benefit from notUsed('c') guards. I tried to implement it.
Seems to work. Then more ideas came - like notUsed('a' 'b' 'c').
Implemented... basically I couldn't stop ;)

So here's what I ended up with. On the engine side: notUsed('a' 'b' 'c'),
a "tail" keyword that applies the rule at the last match (handy for cascade
chains),
"retrack" to re-run rtrack after replacement,
operandOffset() for comparing symbolic addresses, --fixed-regbank to skip
the redundant mov psw in bank-0 ISRs, and _Noreturn support in scan4op.

I also wrote 29 new peephole rules. The biggest wins are consecutive
zero-load batching via clr a (96 hits across 14 test projects),
sequential DPTR collapse to inc dptr (51 hits, 7 projects), and a few
others like redundant DPTR reload removal and mul-by-power-of-2 strength
reduction.

No regressions on sdcc-test/support/regression test-mcs51-small.
I also compiled 17 different real-world projects from the web - no visible
issues on asm-diff.

I'd love for this to be useful in the main codebase. Feedback welcome.

https://github.com/kimstik/sdcc-i51peep/tree/master/patches

Re: [sdcc-devel] Segment names across different ports

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

Am 21.03.26 um 22:45 schrieb Gabriele Gorla via sdcc-devel:
> I am working on integrating GBDK patches into SDCC. I noticed that
> the Z80 ports are the only one that add an underscore to all segment
> names. No other ports does that. The change is from z80/mappings.i
> as the name of the segment in z80/main.c are similar to all other
> ports.
> 
> Should we try to keep the naming consistent across ports?

I don't know why the difference is there. But I suspect that changing it
now would greatly inconvenience users that have the old names hardcoded
in hand-written assembler source files. I guess back when we changed hte
default calling convention could have been a good time to change these
names. If we change them, we definitely need to mention it in the
backwards-compatibility section of the manual, and bump .version.

Philipp

[sdcc-devel] Segment names across different ports

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

I am working on integrating GBDK patches into SDCC.
I noticed that the Z80 ports are the only one that add an underscore to all segment names. No other ports does that.
The change is from z80/mappings.i as the name of the segment in z80/main.c are similar to all other ports.

Should we try to keep the naming consistent across ports?

Re: [sdcc-devel] Missing snapshots

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

Am 21.03.26 um 07:16 schrieb Erik Petrich:
> The Mac snapshot is failing when attempting to build objdump:
>    CCLD     objdump
> Undefined symbols for architecture x86_64:
>    "_bfd_mach_o_get_base_address", referenced from:
>        _dump_load_command in od-macho.o
>    "_bfd_mach_o_read_symtab_strtab", referenced from:
>        _dump_load_command in od-macho.o
>    "_bfd_mach_o_read_symtab_symbols", referenced from:
>        _dump_load_command in od-macho.o
>    "_bfd_mach_o_section_attribute_name", referenced from:
>        _dump_load_command in od-macho.o
>    "_bfd_mach_o_section_get_entry_size", referenced from:
>        _dump_load_command in od-macho.o
>    "_bfd_mach_o_section_get_nbr_indirect", referenced from:
>        _dump_load_command in od-macho.o
>    "_bfd_mach_o_section_type_name", referenced from:
>        _dump_load_command in od-macho.o
> ld: symbol(s) not found for architecture x86_64
> clang: error: linker command failed with exit code 1 (use -v to see
> invocation)
> gmake[7]: *** [Makefile:956: objdump] Error 1
> 
> So something related to the updated binutils merge.
I see, but wonder why od-macho.o ends up in objdump on that machine. On 
my laptop CCLD objdfump apparently expands to

/bin/bash ./libtool  --tag=CC   --mode=link gcc -W -Wall 
-Wstrict-prototypes -Wmissing-prototypes -Wshadow -Wstack-usage=262144 
-Werror   -g -O2       -o objdump objdump.o dwarf.o prdbg.o demanguse.o 
rddbg.o debug.o stabs.o rdcoff.o bucomm.o version.o filemode.o elfcomm.o 
  ../opcodes/libopcodes.la ../libctf/libctf.la ../bfd/libbfd.la 
../libiberty/libiberty.a   ../libsframe/libsframe.la

Which doesn't look like any host-specific files go into it. Could you 
provide the output of "make clean; make V=1" in support/sdbinutils of a 
revision where the failure happens?

For now, in https://sourceforge.net/p/sdcc/code/16381/, I've disabled 
the build of objdump, and hope that will do, but wonder if the build 
will instead just fail for some other binary in support/sdbinutils/binutils.

Philipp

Re: [sdcc-devel] regression tests for pic14 and pic14e

[daniel k <pro...@gm...>]

Hi,
Thanks for your comments.
xc8 has this newer assembler pic-as - also it is different compared to
assembler from gputils or Mplab.
But hlink is a linker for xc8. Its main usage is via command line
arguments. Still can be used.

Sebastian, what do you think about my proposal from one of the previous
messages ? about using linker scripts with valid reset vector and interrupt
template (c_interrupt and STARTUP)
also I have added patch to help run regression tests
https://sourceforge.net/p/sdcc/patches/494/

so far I was able to build and test sdcc 3.2.0 release using docker (I can
provide container image for tests) - and in this release I was able to run
tests without any issues

if you want you can test on your own simple test code
https://github.com/dk2233/PicThrowDK/tree/main/16f913/sdcc_simple
also tested on add.c one of regression tests (sdcc/src/regression/add.c) -
same conclusion



A comparative analysis between SDCC 3.2.0 and SDCC 4.5.19 (using the same
gpasm version) identifies a breaking change in how relocatable sections are
handled. The modern backend generates assembly that triggers Error[118]
(Overwriting previous address contents) at 0x0000 during the assembly phase
(gpasm -c), even when hardware vectors are explicitly defined.

1. Impact of PAGESEL on the Assembler’s PC
The primary differentiator is the introduction of PAGESEL directives in the
4.5.19 output.

Mechanism: In relocatable mode, PAGESEL requires the assembler to calculate
page-bits for symbols.

Observation: Testing shows that the presence of PAGESEL within a
relocatable code section forces gpasm to attempt an early address
resolution. In the absence of an external memory map, gpasm defaults the
base of these sections to 0x0000.

Verification: Manually commenting out PAGESEL directives in the 4.5.19
assembly allows the file to assemble successfully without changing any
other section attributes or hardware vector definitions. You can try on
your side with
https://github.com/dk2233/PicThrowDK/tree/main/16f913/sdcc_simple


2. Section Overlap Logic
The modern backend has moved toward a more granular section model
(Section-per-Function).

In 3.2.0, the code was largely monolithic within a single relocatable block.

In 4.5.19, multiple relocatable code sections are generated.

Without a mechanism to stack these sections, gpasm treats each as an
independent request for the first available address (defaulting to 0x0000).
This causes a collision not only with the fixed STARTUP and INTERRUPT
vectors but also between the functions themselves.

3. Absolute vs. Relocatable Conflict
The error persists as long as the hardware vectors are defined as absolute
(e.g., code 0x0000).

If the absolute requirement is removed from the ASM (changing the vectors
to pure relocatable code sections), the gpasm -c phase completes without
Error[118].

This indicates that the assembler's internal Program Counter (PC)
management cannot reconcile fixed-address hardware vectors with relocatable
sections containing page-resolution logic (PAGESEL) in a single pass.

Technical Conclusion:
The PIC14 assembly output has reached a level of complexity where gpasm can
no longer resolve the local symbol table and paging logic alongside
fixed-address vectors. The conflict is inherent to the assembler's default
behavior when handling multiple relocatable sections and page-aware
instructions.

Regards,
Daniel Kucharski

pt., 20 mar 2026 o 19:20 Sebastien Lorquet <seb...@lo...>
napisał(a):

> Hi,
>
> 20 years ago MPLAB8 already had linker scripts and IIRC gputils used the
> same kind. We are still using it at work because conversion of MCC18
> projects to MPLABX+XC8 sucks, we had to do it for a specific project
> because we ported existing software on a newer pic18 that was not supported
> by MPLAB8. When that constraint is not relevant, it is much more efficient
> to continue using MPLAB8 in a vm. We use a silex DS600 to passthrough an
> ICD3 out of the VM via ethernet.
>
> These linker scripts are very flexible, we have many legacy projects at
> work that use this to locate code. Linker scripts are very convenient and
> are a greatly missed in sdcc in general. A code_loc value et al is not
> always sufficient to define code regions, specifically when firmware has to
> be updated, etc.
>
> XC8 is a nightmare and does not support linker scripts anymore, however,
> you can still define code regions and indicate their address in the command
> line. It's very cumbersome, but at least you can specify a file that
> contains this options, and then it works as a primitive linker script like
> command file. In addition to that, the toolchain has hardcoded magic names,
> for example if your project does not contain a routine named "main", it
> complains.You can just add an empty main() somewhere and that will be ok,
> even if that routine is not used at all.  It is also hard to control what
> happens between the reset vector and the main routine in the pure C
> language only case.
>
> Sebastien
>
>
> On 3/20/26 13:52, daniel k wrote:
>
> Hi,
> What is the version of sdcc that was fully testable with pic14? I would
> like to check how it was done previously but the idea was always the same -
> in case of relocatable objects - all of the code sections got address
> 0x0000 and only linker is capable of putting them into specific locations
> (automatically or by intention).
>
>
> I’ve analyzed the modern XC8 toolchain, and as I mentioned, they also
> avoid hardcoding addresses in the assembly. Instead, they use the linker to
> inject these locations.
>
> /media/dan/Workbench/XC8_v3.10/pic/bin/hlink
> @/tmp/xcXlmegJA/hlink_driver_tmp_15.cmd [ -W-3
> --edf=/media/dan/Workbench/XC8_v3.10/pic/dat/20250813170317_en.msgs -cn
> -h+dist/default/production/simple_test.X.production.sym
> --cmf=dist/default/production/simple_test.X.production.cmf -z -Q16F913
> -o/tmp/xcXlmegJA/driver_tmp_3.o --defsym=__MPLAB_BUILD=1
> --fixupoverflow=error
> -Mdist/default/production/simple_test.X.production.map
> --md=/tmp/xcXlmegJA/driver_tmp_0.dat -E1 -ver=XC8^Compiler#PRO##V3.10
> -ACODE=00h-07FFhx2 -ASTRCODE=00h-0FFFh -ASTRING=00h-0FFhx16
> -ACONST=00h-0FFhx16 -AENTRY=00h-0FFhx16 -ACOMMON=070h-07Fh
> -ABANK0=020h-06Fh -ABANK1=0A0h-0EFh -ABANK2=0120h-016Fh
> -ARAM=020h-06Fh,0A0h-0EFh,0120h-016Fh
> -AABS1=020h-07Fh,0A0h-0EFh,0120h-016Fh -ASFR0=00h-01Fh -ASFR1=080h-09Fh
> -ASFR2=0100h-011Fh -ASFR3=0180h-01EFh -ACONFIG=02007h-02007h -DCONFIG=2
> -AIDLOC=02000h-02003h -DIDLOC=2 -AEEDATA=00h-0FFh/02100h
> -peeprom_data=EEDATA -DEEDATA=2 -DCODE=2 -DSTRCODE=2 -DSTRING=2 -DCONST=2
> -DENTRY=2 *-preset_vec=00h,intentry=04h,*sivt,init,end_init
> -ppowerup=CODE -pcinit=CODE -pfunctab=ENTRY -k
> dist/default/production/startup.o
> dist/default/production/simple_test.X.production.o ]
>
> In the XC8 log I provided: -preset_vec=00h,intentry=04h,...'''
>
> XC8 is capable of "pinning" sections to addresses via command-line flags. *However,
> gplink (from gputils) is not capable of this.* I have verified the gplink
> source and documentation—it does not support an inline --section-start or
> equivalent flag for relocatable objects. Also I see that in the case of
> small projects - it will integrate all files into one big asm (*.s) file.
>
> Actually I think I will spend some time and check very old sdcc releases -
> I am also interested in what kind of approach was used.
> If you really want an approach without linker - then we will need to
> create one big asm file that will have c_interrupt
> and t__sdcc_gsinit_startup integrated directly into the main file of the
> project. Currently there is a libsdcc.lib that provides required
> functionality. Very likely older gputils was better in handling a mix of
> relocatable and absolute code.
>
> Such an approach may work quite well - until of course the project does
> not consist of more files - than a proper linker is a must. For more
> advanced users - it should not be an issue to write its own linker script
> that should switch into relocatable mode.
>
> Regards
> Daniel Kucharski
>
> czw., 19 mar 2026 o 15:24 Philipp Klaus Krause <pk...@sp...> napisał(a):
>
>> Am 15.03.26 um 21:54 schrieb daniel k:
>> > Hi Philipp, Gabriele,
>> >
>> > Thank you for the insights. I understand the preference for avoiding
>> > complex linker setups, but I’d like to highlight why the PIC14 port is
>> a
>> > "special case" compared to Z80 or 6502, and why Patch #494 and proper
>> > linker support are technically required for stable code.
>>
>> I wonder how this worked 20 years ago, when the pic14 port and gputils
>> were still maintained.
>>
>> Philipp
>>
>>
>>
>> _______________________________________________
>> sdcc-devel mailing list
>> sdc...@li...
>> https://lists.sourceforge.net/lists/listinfo/sdcc-devel
>>
>
>
> _______________________________________________
> sdcc-devel mailing lis...@li...://lists.sourceforge.net/lists/listinfo/sdcc-devel
>
> _______________________________________________
> sdcc-devel mailing list
> sdc...@li...
> https://lists.sourceforge.net/lists/listinfo/sdcc-devel
>

Re: [sdcc-devel] Missing snapshots

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

Am 21.03.26 um 07:21 schrieb Atirut Wattanamongkol:
>     The 64-bit Linux and Windows snapshots were missing because the
>     associated virtual machine had shutdown. Not entirely sure why, but
>     possibly ran out of memory on the underlying host. I have restarted
>     the virtual machine.
> 
> 
> Sorry for butting in; does SourceForge not offer CI/CD like GitHub or 
> GitLab? Really curious on this one.

AFAIR, I've read some notes (in the repo or wiki) stating that SDCC once 
used such infrastructure from SourceForge, but SourceForge made some 
change to it that made it unsuitable for SDCC resulting in SDCC 
developers building the current compile farm. That was before my time 
with SDCC, so I don't know the details.
By now, we make quite heavy use of our compile farm, in particular fore 
regression testing. Last time I had a quick look at github 
infrastructure, it looked like we'd hit the compute time limits there. 
Also our farm now has some relativly exotic host platforms not or not 
easily available on github (e.g. the big-endian ppc64), that tend to be 
quite valuable for us, ot for direct support of those host platforms, 
but because sometimes bugs that are sporadic or hard to reproduce on 
common host platform are easy to reproduce on an exotic one.

Philipp

Re: [sdcc-devel] Missing snapshots

[Atirut W. <ati...@gm...>]

>
> The 64-bit Linux and Windows snapshots were missing because the
> associated virtual machine had shutdown. Not entirely sure why, but
> possibly ran out of memory on the underlying host. I have restarted
> the virtual machine.


Sorry for butting in; does SourceForge not offer CI/CD like GitHub or
GitLab? Really curious on this one.

Re: [sdcc-devel] Missing snapshots

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

On Thu, 2026-03-19 at 12:41 +0100, Philipp Klaus Krause wrote:
> We are curently missing:
> 
> * GNU/Linux on amd64
> * Windows on x86
> * macOS onamd64
> 
> Does anyone know why?
> 
> Philipp

The 64-bit Linux and Windows snapshots were missing because the
associated virtual machine had shutdown. Not entirely sure why, but
possibly ran out of memory on the underlying host. I have restarted
the virtual machine.

The Mac snapshot is failing when attempting to build objdump:
  CCLD     objdump
Undefined symbols for architecture x86_64:
  "_bfd_mach_o_get_base_address", referenced from:
      _dump_load_command in od-macho.o
  "_bfd_mach_o_read_symtab_strtab", referenced from:
      _dump_load_command in od-macho.o
  "_bfd_mach_o_read_symtab_symbols", referenced from:
      _dump_load_command in od-macho.o
  "_bfd_mach_o_section_attribute_name", referenced from:
      _dump_load_command in od-macho.o
  "_bfd_mach_o_section_get_entry_size", referenced from:
      _dump_load_command in od-macho.o
  "_bfd_mach_o_section_get_nbr_indirect", referenced from:
      _dump_load_command in od-macho.o
  "_bfd_mach_o_section_type_name", referenced from:
      _dump_load_command in od-macho.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see
invocation)
gmake[7]: *** [Makefile:956: objdump] Error 1

So something related to the updated binutils merge.

  Erik

Re: [sdcc-devel] regression tests for pic14 and pic14e

[Sebastien L. <seb...@lo...>]

Hi,

20 years ago MPLAB8 already had linker scripts and IIRC gputils used the 
same kind. We are still using it at work because conversion of MCC18 
projects to MPLABX+XC8 sucks, we had to do it for a specific project 
because we ported existing software on a newer pic18 that was not 
supported by MPLAB8. When that constraint is not relevant, it is much 
more efficient to continue using MPLAB8 in a vm. We use a silex DS600 to 
passthrough an ICD3 out of the VM via ethernet.

These linker scripts are very flexible, we have many legacy projects at 
work that use this to locate code. Linker scripts are very convenient 
and are a greatly missed in sdcc in general. A code_loc value et al is 
not always sufficient to define code regions, specifically when firmware 
has to be updated, etc.

XC8 is a nightmare and does not support linker scripts anymore, however, 
you can still define code regions and indicate their address in the 
command line. It's very cumbersome, but at least you can specify a file 
that contains this options, and then it works as a primitive linker 
script like command file. In addition to that, the toolchain has 
hardcoded magic names, for example if your project does not contain a 
routine named "main", it complains.You can just add an empty main() 
somewhere and that will be ok, even if that routine is not used at all.  
It is also hard to control what happens between the reset vector and the 
main routine in the pure C language only case.

Sebastien


On 3/20/26 13:52, daniel k wrote:
> Hi,
> What is the version of sdcc that was fully testable with pic14? I 
> would like to check how it was done previously but the idea was always 
> the same - in case of relocatable objects - all of the code sections 
> got address 0x0000 and only linker is capable of putting them into 
> specific locations (automatically or by intention).
>
>
> I’ve analyzed the modern XC8 toolchain, and as I mentioned, they also 
> avoid hardcoding addresses in the assembly. Instead, they use the 
> linker to inject these locations.
>
>
> /media/dan/Workbench/XC8_v3.10/pic/bin/hlink 
> @/tmp/xcXlmegJA/hlink_driver_tmp_15.cmd [ -W-3 
> --edf=/media/dan/Workbench/XC8_v3.10/pic/dat/20250813170317_en.msgs 
> -cn -h+dist/default/production/simple_test.X.production.sym 
> --cmf=dist/default/production/simple_test.X.production.cmf -z -Q16F913 
> -o/tmp/xcXlmegJA/driver_tmp_3.o --defsym=__MPLAB_BUILD=1 
> --fixupoverflow=error 
> -Mdist/default/production/simple_test.X.production.map 
> --md=/tmp/xcXlmegJA/driver_tmp_0.dat -E1 -ver=XC8^Compiler#PRO##V3.10 
> -ACODE=00h-07FFhx2 -ASTRCODE=00h-0FFFh -ASTRING=00h-0FFhx16 
> -ACONST=00h-0FFhx16 -AENTRY=00h-0FFhx16 -ACOMMON=070h-07Fh 
> -ABANK0=020h-06Fh -ABANK1=0A0h-0EFh -ABANK2=0120h-016Fh 
> -ARAM=020h-06Fh,0A0h-0EFh,0120h-016Fh 
> -AABS1=020h-07Fh,0A0h-0EFh,0120h-016Fh -ASFR0=00h-01Fh 
> -ASFR1=080h-09Fh -ASFR2=0100h-011Fh -ASFR3=0180h-01EFh 
> -ACONFIG=02007h-02007h -DCONFIG=2 -AIDLOC=02000h-02003h -DIDLOC=2 
> -AEEDATA=00h-0FFh/02100h -peeprom_data=EEDATA -DEEDATA=2 -DCODE=2 
> -DSTRCODE=2 -DSTRING=2 -DCONST=2 -DENTRY=2 
> *_-preset_vec=00h,intentry=04h_,*sivt,init,end_init -ppowerup=CODE 
> -pcinit=CODE -pfunctab=ENTRY -k dist/default/production/startup.o 
> dist/default/production/simple_test.X.production.o ]
>
> In the XC8 log I provided: |-preset_vec=00h,intentry=04h,...|'''
>
> XC8 is capable of "pinning" sections to addresses via command-line 
> flags. *However, |gplink| (from gputils) is not capable of this.* I 
> have verified the |gplink| source and documentation—it does not 
> support an inline |--section-start| or equivalent flag for relocatable 
> objects. Also I see that in the case of small projects - it will 
> integrate all files into one big asm (*.s) file.
>
> Actually I think I will spend some time and check very old sdcc 
> releases - I am also interested in what kind of approach was used.
> If you really want an approach without linker - then we will need to 
> create one big asm file that will have c_interrupt 
> and t__sdcc_gsinit_startup integrated directly into the main file of 
> the project. Currently there is a libsdcc.lib that provides required 
> functionality. Very likely older gputils was better in handling a mix 
> of relocatable and absolute code.
>
> Such an approach may work quite well - until of course the project 
> does not consist of more files - than a proper linker is a must. For 
> more advanced users - it should not be an issue to write its own 
> linker script  that should switch into relocatable mode.
>
> Regards
> Daniel Kucharski
>
> czw., 19 mar 2026 o 15:24 Philipp Klaus Krause <pk...@sp...> napisał(a):
>
>     Am 15.03.26 um 21:54 schrieb daniel k:
>     > Hi Philipp, Gabriele,
>     >
>     > Thank you for the insights. I understand the preference for
>     avoiding
>     > complex linker setups, but I’d like to highlight why the PIC14
>     port is a
>     > "special case" compared to Z80 or 6502, and why Patch #494 and
>     proper
>     > linker support are technically required for stable code.
>
>     I wonder how this worked 20 years ago, when the pic14 port and
>     gputils
>     were still maintained.
>
>     Philipp
>
>
>
>     _______________________________________________
>     sdcc-devel mailing list
>     sdc...@li...
>     https://lists.sourceforge.net/lists/listinfo/sdcc-devel
>
>
>
> _______________________________________________
> sdcc-devel mailing list
> sdc...@li...
> https://lists.sourceforge.net/lists/listinfo/sdcc-devel

Re: [sdcc-devel] regression tests for pic14 and pic14e

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

Am 20.03.26 um 13:52 schrieb daniel k:
> Hi,
> What is the version of sdcc that was fully testable with pic14? I 
> would like to check how it was done previously but the idea was always 
> the same - in case of relocatable objects - all of the code sections 
> got address 0x0000 and only linker is capable of putting them into 
> specific locations (automatically or by intention).
> [...]

I don't think that anybody here can tell you for sure, but something 
like SDCC 3.0.0 (2010) or SDCC 3.5.0 (2015) could be a good starting 
point if you want to investigate that.

Greetings,
Benedikt

Re: [sdcc-devel] regression tests for pic14 and pic14e

[daniel k <pro...@gm...>]

Hi,
What is the version of sdcc that was fully testable with pic14? I would
like to check how it was done previously but the idea was always the same -
in case of relocatable objects - all of the code sections got address
0x0000 and only linker is capable of putting them into specific locations
(automatically or by intention).


I’ve analyzed the modern XC8 toolchain, and as I mentioned, they also avoid
hardcoding addresses in the assembly. Instead, they use the linker to
inject these locations.

/media/dan/Workbench/XC8_v3.10/pic/bin/hlink
@/tmp/xcXlmegJA/hlink_driver_tmp_15.cmd [ -W-3
--edf=/media/dan/Workbench/XC8_v3.10/pic/dat/20250813170317_en.msgs -cn
-h+dist/default/production/simple_test.X.production.sym
--cmf=dist/default/production/simple_test.X.production.cmf -z -Q16F913
-o/tmp/xcXlmegJA/driver_tmp_3.o --defsym=__MPLAB_BUILD=1
--fixupoverflow=error
-Mdist/default/production/simple_test.X.production.map
--md=/tmp/xcXlmegJA/driver_tmp_0.dat -E1 -ver=XC8^Compiler#PRO##V3.10
-ACODE=00h-07FFhx2 -ASTRCODE=00h-0FFFh -ASTRING=00h-0FFhx16
-ACONST=00h-0FFhx16 -AENTRY=00h-0FFhx16 -ACOMMON=070h-07Fh
-ABANK0=020h-06Fh -ABANK1=0A0h-0EFh -ABANK2=0120h-016Fh
-ARAM=020h-06Fh,0A0h-0EFh,0120h-016Fh
-AABS1=020h-07Fh,0A0h-0EFh,0120h-016Fh -ASFR0=00h-01Fh -ASFR1=080h-09Fh
-ASFR2=0100h-011Fh -ASFR3=0180h-01EFh -ACONFIG=02007h-02007h -DCONFIG=2
-AIDLOC=02000h-02003h -DIDLOC=2 -AEEDATA=00h-0FFh/02100h
-peeprom_data=EEDATA -DEEDATA=2 -DCODE=2 -DSTRCODE=2 -DSTRING=2 -DCONST=2
-DENTRY=2 *-preset_vec=00h,intentry=04h,*sivt,init,end_init -ppowerup=CODE
-pcinit=CODE -pfunctab=ENTRY -k dist/default/production/startup.o
dist/default/production/simple_test.X.production.o ]

In the XC8 log I provided: -preset_vec=00h,intentry=04h,...'''

XC8 is capable of "pinning" sections to addresses via command-line
flags. *However,
gplink (from gputils) is not capable of this.* I have verified the gplink
source and documentation—it does not support an inline --section-start or
equivalent flag for relocatable objects. Also I see that in the case of
small projects - it will integrate all files into one big asm (*.s) file.

Actually I think I will spend some time and check very old sdcc releases -
I am also interested in what kind of approach was used.
If you really want an approach without linker - then we will need to create
one big asm file that will have c_interrupt and t__sdcc_gsinit_startup
integrated directly into the main file of the project. Currently there is a
libsdcc.lib that provides required functionality. Very likely older gputils
was better in handling a mix of relocatable and absolute code.

Such an approach may work quite well - until of course the project does not
consist of more files - than a proper linker is a must. For more advanced
users - it should not be an issue to write its own linker script  that
should switch into relocatable mode.

Regards
Daniel Kucharski

czw., 19 mar 2026 o 15:24 Philipp Klaus Krause <pk...@sp...> napisał(a):

> Am 15.03.26 um 21:54 schrieb daniel k:
> > Hi Philipp, Gabriele,
> >
> > Thank you for the insights. I understand the preference for avoiding
> > complex linker setups, but I’d like to highlight why the PIC14 port is a
> > "special case" compared to Z80 or 6502, and why Patch #494 and proper
> > linker support are technically required for stable code.
>
> I wonder how this worked 20 years ago, when the pic14 port and gputils
> were still maintained.
>
> Philipp
>
>
>
> _______________________________________________
> sdcc-devel mailing list
> sdc...@li...
> https://lists.sourceforge.net/lists/listinfo/sdcc-devel
>

Re: [sdcc-devel] regression tests for pic14 and pic14e

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

Am 15.03.26 um 21:54 schrieb daniel k:
> Hi Philipp, Gabriele,
> 
> Thank you for the insights. I understand the preference for avoiding 
> complex linker setups, but I’d like to highlight why the PIC14 port is a 
> "special case" compared to Z80 or 6502, and why Patch #494 and proper 
> linker support are technically required for stable code.

I wonder how this worked 20 years ago, when the pic14 port and gputils 
were still maintained.

Philipp

Re: [sdcc-devel] regression tests for pic14 and pic14e

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

Am 15.03.26 um 22:02 schrieb mhawkins.consultant:
> How does the sdcc support bank switching/layout for the Z80? with linker 
> script definitions of something else?
> 
> /Mike H

For data, we have user-defined named address spaces (i.e. the compiler 
inserts calls to the user-defined bank-switching function before data 
access). For functions, there is __banked. I am not familiar with the 
details on the linker side, though.

Philipp

[sdcc-devel] Missing snapshots

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

We are curently missing:

* GNU/Linux on amd64
* Windows on x86
* macOS onamd64

Does anyone know why?

Philipp

Re: [sdcc-devel] regression tests for pic14 and pic14e

[mhawkins.consultant <mha...@gm...>]

How does the sdcc support bank switching/layout for the Z80? with linker script definitions of something else?/Mike HSent from my Galaxy
-------- Original message --------From: daniel k <pro...@gm...> Date: 3/15/26  4:54 PM  (GMT-05:00) To: Development chatter about sdcc <sdc...@li...> Subject: Re: [sdcc-devel] regression tests for pic14 and pic14e Hi Philipp, Gabriele,Thank you for the insights. I understand the preference for avoiding complex linker setups, but I’d like to highlight why the PIC14 port is a "special case" compared to Z80 or 6502, and why Patch #494 and proper linker support are technically required for stable code.1. Hardware-Fixed "Instruction Slots" vs. Tables Unlike the STM8, 6502, or Z80 (IM 2), where an interrupt vector is a pointer in a table, the PIC14 hardware expects actual executable instructions at 0x0004. There are exactly 4 words between Reset (0x0000) and the Interrupt vector.If the compiler or linker doesn't strictly manage these "small holes," they overlap (causing the Error[118] many users report).Gabriele’s approach of per-file segment descriptions works for linear memory, but on PIC, the linker must act as a physical gap manager.2. Relocation is more than an Offset - On a Z80, relocation primarily involves adjusting 16-bit addresses within a flat 64KB space ( I am not an expert here so correct me if I am wrong)On a PIC14, relocating a function from Page 0 to Page 1 requires the compiler to fundamentally alter how it handles PCLATH and where it inserts PAGESEL directives—because the code itself must manage banking at the instruction level. Users have to pay attention to function location. 3. Why "Linker-less" fails on PIC
If we don't use linker scripts, gputils doesn't know where the physical memory "gaps" are. It assumes a flat space, which doesn't exist on PIC. For the regression tests to pass reliably across different MCUs, we need a way to tell the toolchain: "Place the Reset code here, the ISR here, and don't let the main code spill into the config bits at the end of the flash."My ultimate proposal to fix the current fragility is to move the Reset vector and ISR addresses directly into the linker script. * This removes the hardcoded CODE 0x0000 from the .asm file, which is what currently triggers the assembler conflicts.The rest of the functions can then be handled by gplink dynamically.If a user needs a custom layout, they can provide their own script, but the default behavior would finally be robust and "invisible" to the user.Without this, the regression tests will continue to be "flaky" because we are fighting the toolchain's lack of knowledge about the PIC's fragmented memory map.I will propose a meeting on some chat - I can show you and explain the issues. I can share my screen, show the generated code, and explain the technical hurdles behind the current approach in real-time. I believe this could significantly speed up the process of making the PIC14 port as robust as the others.I have spent some time trying to prepare valid tests to explain the problems. Regards,
Danielsob., 14 mar 2026 o 19:13 daniel k <pro...@gm...> napisał(a):Hi,I agree that the linker and linker scripts can be confusing, but understanding them is essential when you need to locate functions or data in specific sections (e.g., bootloaders, boot managers, HSM, reset vectors, or configuration data containers). Linker scripts are even more critical when dealing with memory paging; ensuring specific functionality is placed in Page 0 is vital. While one could technically create one massive file and use the org command for everything, it is far more efficient to encapsulate functionality into separate files for better reusability.Actually, linker scripts are relatively simple to grasp (at least compared to the Tasking environment!). If you want to check some specific PIC16F examples, I have some here: https://github.com/dk2233/PicThrowDK/tree/main/16f913/ds18b20_led_relocatableRegarding what Philipp wrote:If we define crt0 as the "startup routines, initialization code, and standard library support," then this logic currently resides in libsdcc.lib.If no interrupt is defined in the MCU, we have the main startup: the function __sdcc_gsinit_startup (cinit) is defined in idata.c. (I believe this code should eventually be rewritten in assembler to be smaller and faster). Consequently, every SDCC build adds a small reset vector to handle the jump at system start, especially since address 0x0004 must be reserved for the interrupt vector.I have attached a patch that, when applied, allows all regression tests to pass. (I am also considering moving them into the support/regression folder as suggested). I have also included proper linker scripts in the tests folder. Unfortunately, we need a specific linker script for each microcontroller—similar to the lkr folder in gputils—because the default ones provided by gputils do not set up a valid reset vector.Regards,
Daniel Ksob., 14 mar 2026 o 13:51 Philipp Klaus Krause <pk...@sp...> napisał(a):Am 14.03.26 um 10:39 schrieb daniel k:> How about linker scripts for other micros? Maybe by default they have a> section related to reset vector or isr address?Some ports use a custom crt0 (e.g. z80),though there is a default oneincluded in the library useful as an example for the user writing their own.Some ports emit the interrupt table in the same file as main() (e.g.stm8, r4k).I guess we have a "section" _IIVT for the interrupt vector table forr4k. For stm8 it is part of HOME. But I don't know much about the linkereither. I just hope that stuff doesn't break when I work on thecompiler, and usually don't know what to do when users request changesto it.Philipp_______________________________________________sdcc-devel mailing lis...@li...://lists.sourceforge.net/lists/listinfo/sdcc-develsob., 14 mar 2026 o 17:27 Gabriele Gorla via sdcc-devel <sdc...@li...> napisał(a):I don't fully understand the linker behavior as well.
The segment ordering and placement rules are very confusing.
If you compile multiple source files the order in which they are placed in the link line will affect the segment ordering.
I spent weeks chasing bugs in the compiled code due to this.

In the mos 6502 port I solved the issue by placing a full segment description at the beginning of every file.
In this way regardless of the order in the link line you get the same segment ordering. 


thanks,
GG


On Saturday, March 14, 2026 at 05:51:23 AM PDT, Philipp Klaus Krause <pk...@sp...> wrote: 





Am 14.03.26 um 10:39 schrieb daniel k:
> How about linker scripts for other micros? Maybe by default they have a 
> section related to reset vector or isr address?
Some ports use a custom crt0 (e.g. z80),though there is a default one 
included in the library useful as an example for the user writing their own.

Some ports emit the interrupt table in the same file as main() (e.g. 
stm8, r4k).

I guess we have a "section" _IIVT for the interrupt vector table for 
r4k. For stm8 it is part of HOME. But I don't know much about the linker 
either. I just hope that stuff doesn't break when I work on the 
compiler, and usually don't know what to do when users request changes 
to it.

Philipp



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


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

Re: [sdcc-devel] regression tests for pic14 and pic14e

[daniel k <pro...@gm...>]

Hi Philipp, Gabriele,

Thank you for the insights. I understand the preference for avoiding
complex linker setups, but I’d like to highlight why the PIC14 port is a
"special case" compared to Z80 or 6502, and why Patch #494 and proper
linker support are technically required for stable code.

*1. Hardware-Fixed "Instruction Slots" vs. Tables* Unlike the STM8, 6502,
or Z80 (IM 2), where an interrupt vector is a pointer in a table, the PIC14
hardware expects actual executable instructions at 0x0004. There are
exactly 4 words between Reset (0x0000) and the Interrupt vector.

   -

   If the compiler or linker doesn't strictly manage these "small holes,"
   they overlap (causing the *Error[118]* many users report).
   -

   *Gabriele’s approach of per-file segment descriptions works for linear
   memory, but on PIC, the linker must act as a physical gap manager.*

*2. Relocation is more than an Offset - *On a Z80, relocation primarily
involves adjusting 16-bit addresses within a flat 64KB space ( I am not an
expert here so correct me if I am wrong)

On a PIC14, relocating a function from Page 0 to Page 1 requires the
compiler to fundamentally alter how it handles PCLATH and where it inserts
PAGESEL directives—because the code itself must manage banking at the
instruction level. Users have to pay attention to function location.

*3. Why "Linker-less" fails on PIC* If we don't use linker scripts, gputils
doesn't know where the physical memory "gaps" are. It assumes a flat space,
which doesn't exist on PIC. For the regression tests to pass reliably
across different MCUs, we need a way to tell the toolchain: "Place the
Reset code here, the ISR here, and don't let the main code spill into the
config bits at the end of the flash."

My ultimate proposal to fix the current fragility is to *move the Reset
vector and ISR addresses directly into the linker script.* * This removes
the hardcoded CODE 0x0000 from the .asm file, which is what currently
triggers the assembler conflicts.

   -

   The rest of the functions can then be handled by gplink dynamically.
   -

   If a user needs a custom layout, they can provide their own script, but
   the default behavior would finally be robust and "invisible" to the user.

Without this, the regression tests will continue to be "flaky" because we
are fighting the toolchain's lack of knowledge about the PIC's fragmented
memory map.

I will propose a meeting on some chat - I can show you and explain the
issues. I can share my screen, show the generated code, and explain the
technical hurdles behind the current approach in real-time. I believe this
could significantly speed up the process of making the PIC14 port as robust
as the others.

I have spent some time trying to prepare valid tests to explain the
problems.


Regards, Daniel

sob., 14 mar 2026 o 19:13 daniel k <pro...@gm...> napisał(a):

> Hi,
>
> I agree that the linker and linker scripts can be confusing, but
> understanding them is essential when you need to locate functions or data
> in specific sections (e.g., bootloaders, boot managers, HSM, reset vectors,
> or configuration data containers). Linker scripts are even more critical
> when dealing with memory paging; ensuring specific functionality is placed
> in Page 0 is vital. While one could technically create one massive file and
> use the org command for everything, it is far more efficient to
> encapsulate functionality into separate files for better reusability.
>
> Actually, linker scripts are relatively simple to grasp (at least compared
> to the Tasking environment!). If you want to check some specific PIC16F
> examples, I have some here:
> https://github.com/dk2233/PicThrowDK/tree/main/16f913/ds18b20_led_relocatable
>
> Regarding what Philipp wrote:
>
> If we define *crt0* as the "startup routines, initialization code, and
> standard library support," then this logic currently resides in
> libsdcc.lib.
>
> If no interrupt is defined in the MCU, we have the main startup: the
> function __sdcc_gsinit_startup (cinit) is defined in idata.c. (I believe
> this code should eventually be rewritten in assembler to be smaller and
> faster). Consequently, every SDCC build adds a small reset vector to handle
> the jump at system start, especially since address 0x0004 must be
> reserved for the interrupt vector.
>
> I have attached a patch that, when applied, allows all regression tests to
> pass. (I am also considering moving them into the support/regression
> folder as suggested). I have also included proper linker scripts in the
> tests folder. Unfortunately, we need a specific linker script for each
> microcontroller—similar to the lkr folder in gputils—because the default
> ones provided by gputils do not set up a valid reset vector.
>
> Regards, Daniel K
>
>
>
> sob., 14 mar 2026 o 13:51 Philipp Klaus Krause <pk...@sp...> napisał(a):
>
>> Am 14.03.26 um 10:39 schrieb daniel k:
>> > How about linker scripts for other micros? Maybe by default they have a
>> > section related to reset vector or isr address?
>> Some ports use a custom crt0 (e.g. z80),though there is a default one
>> included in the library useful as an example for the user writing their
>> own.
>>
>> Some ports emit the interrupt table in the same file as main() (e.g.
>> stm8, r4k).
>>
>> I guess we have a "section" _IIVT for the interrupt vector table for
>> r4k. For stm8 it is part of HOME. But I don't know much about the linker
>> either. I just hope that stuff doesn't break when I work on the
>> compiler, and usually don't know what to do when users request changes
>> to it.
>>
>> Philipp
>>
>>
>>
>> _______________________________________________
>> sdcc-devel mailing list
>> sdc...@li...
>> https://lists.sourceforge.net/lists/listinfo/sdcc-devel
>
>
> sob., 14 mar 2026 o 17:27 Gabriele Gorla via sdcc-devel <
> sdc...@li...> napisał(a):
>
>> I don't fully understand the linker behavior as well.
>> The segment ordering and placement rules are very confusing.
>> If you compile multiple source files the order in which they are placed
>> in the link line will affect the segment ordering.
>> I spent weeks chasing bugs in the compiled code due to this.
>>
>> In the mos 6502 port I solved the issue by placing a full segment
>> description at the beginning of every file.
>> In this way regardless of the order in the link line you get the same
>> segment ordering.
>>
>>
>> thanks,
>> GG
>>
>>
>> On Saturday, March 14, 2026 at 05:51:23 AM PDT, Philipp Klaus Krause <
>> pk...@sp...> wrote:
>>
>>
>>
>>
>>
>> Am 14.03.26 um 10:39 schrieb daniel k:
>> > How about linker scripts for other micros? Maybe by default they have a
>> > section related to reset vector or isr address?
>> Some ports use a custom crt0 (e.g. z80),though there is a default one
>> included in the library useful as an example for the user writing their
>> own.
>>
>> Some ports emit the interrupt table in the same file as main() (e.g.
>> stm8, r4k).
>>
>> I guess we have a "section" _IIVT for the interrupt vector table for
>> r4k. For stm8 it is part of HOME. But I don't know much about the linker
>> either. I just hope that stuff doesn't break when I work on the
>> compiler, and usually don't know what to do when users request changes
>> to it.
>>
>> Philipp
>>
>>
>>
>> _______________________________________________
>> sdcc-devel mailing list
>> sdc...@li...
>> https://lists.sourceforge.net/lists/listinfo/sdcc-devel
>>
>>
>> _______________________________________________
>> sdcc-devel mailing list
>> sdc...@li...
>> https://lists.sourceforge.net/lists/listinfo/sdcc-devel
>>
>

Re: [sdcc-devel] regression tests for pic14 and pic14e

[daniel k <pro...@gm...>]

Hi,

I agree that the linker and linker scripts can be confusing, but
understanding them is essential when you need to locate functions or data
in specific sections (e.g., bootloaders, boot managers, HSM, reset vectors,
or configuration data containers). Linker scripts are even more critical
when dealing with memory paging; ensuring specific functionality is placed
in Page 0 is vital. While one could technically create one massive file and
use the org command for everything, it is far more efficient to encapsulate
functionality into separate files for better reusability.

Actually, linker scripts are relatively simple to grasp (at least compared
to the Tasking environment!). If you want to check some specific PIC16F
examples, I have some here:
https://github.com/dk2233/PicThrowDK/tree/main/16f913/ds18b20_led_relocatable

Regarding what Philipp wrote:

If we define *crt0* as the "startup routines, initialization code, and
standard library support," then this logic currently resides in libsdcc.lib.

If no interrupt is defined in the MCU, we have the main startup: the
function __sdcc_gsinit_startup (cinit) is defined in idata.c. (I believe
this code should eventually be rewritten in assembler to be smaller and
faster). Consequently, every SDCC build adds a small reset vector to handle
the jump at system start, especially since address 0x0004 must be reserved
for the interrupt vector.

I have attached a patch that, when applied, allows all regression tests to
pass. (I am also considering moving them into the support/regression folder
as suggested). I have also included proper linker scripts in the tests
folder. Unfortunately, we need a specific linker script for each
microcontroller—similar to the lkr folder in gputils—because the default
ones provided by gputils do not set up a valid reset vector.

Regards, Daniel K



sob., 14 mar 2026 o 13:51 Philipp Klaus Krause <pk...@sp...> napisał(a):

> Am 14.03.26 um 10:39 schrieb daniel k:
> > How about linker scripts for other micros? Maybe by default they have a
> > section related to reset vector or isr address?
> Some ports use a custom crt0 (e.g. z80),though there is a default one
> included in the library useful as an example for the user writing their
> own.
>
> Some ports emit the interrupt table in the same file as main() (e.g.
> stm8, r4k).
>
> I guess we have a "section" _IIVT for the interrupt vector table for
> r4k. For stm8 it is part of HOME. But I don't know much about the linker
> either. I just hope that stuff doesn't break when I work on the
> compiler, and usually don't know what to do when users request changes
> to it.
>
> Philipp
>
>
>
> _______________________________________________
> sdcc-devel mailing list
> sdc...@li...
> https://lists.sourceforge.net/lists/listinfo/sdcc-devel


sob., 14 mar 2026 o 17:27 Gabriele Gorla via sdcc-devel <
sdc...@li...> napisał(a):

> I don't fully understand the linker behavior as well.
> The segment ordering and placement rules are very confusing.
> If you compile multiple source files the order in which they are placed in
> the link line will affect the segment ordering.
> I spent weeks chasing bugs in the compiled code due to this.
>
> In the mos 6502 port I solved the issue by placing a full segment
> description at the beginning of every file.
> In this way regardless of the order in the link line you get the same
> segment ordering.
>
>
> thanks,
> GG
>
>
> On Saturday, March 14, 2026 at 05:51:23 AM PDT, Philipp Klaus Krause <
> pk...@sp...> wrote:
>
>
>
>
>
> Am 14.03.26 um 10:39 schrieb daniel k:
> > How about linker scripts for other micros? Maybe by default they have a
> > section related to reset vector or isr address?
> Some ports use a custom crt0 (e.g. z80),though there is a default one
> included in the library useful as an example for the user writing their
> own.
>
> Some ports emit the interrupt table in the same file as main() (e.g.
> stm8, r4k).
>
> I guess we have a "section" _IIVT for the interrupt vector table for
> r4k. For stm8 it is part of HOME. But I don't know much about the linker
> either. I just hope that stuff doesn't break when I work on the
> compiler, and usually don't know what to do when users request changes
> to it.
>
> Philipp
>
>
>
> _______________________________________________
> sdcc-devel mailing list
> sdc...@li...
> https://lists.sourceforge.net/lists/listinfo/sdcc-devel
>
>
> _______________________________________________
> sdcc-devel mailing list
> sdc...@li...
> https://lists.sourceforge.net/lists/listinfo/sdcc-devel
>

Re: [sdcc-devel] regression tests for pic14 and pic14e

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

I don't fully understand the linker behavior as well.
The segment ordering and placement rules are very confusing.
If you compile multiple source files the order in which they are placed in the link line will affect the segment ordering.
I spent weeks chasing bugs in the compiled code due to this.

In the mos 6502 port I solved the issue by placing a full segment description at the beginning of every file.
In this way regardless of the order in the link line you get the same segment ordering. 


thanks,
GG


On Saturday, March 14, 2026 at 05:51:23 AM PDT, Philipp Klaus Krause <pk...@sp...> wrote: 





Am 14.03.26 um 10:39 schrieb daniel k:
> How about linker scripts for other micros? Maybe by default they have a 
> section related to reset vector or isr address?
Some ports use a custom crt0 (e.g. z80),though there is a default one 
included in the library useful as an example for the user writing their own.

Some ports emit the interrupt table in the same file as main() (e.g. 
stm8, r4k).

I guess we have a "section" _IIVT for the interrupt vector table for 
r4k. For stm8 it is part of HOME. But I don't know much about the linker 
either. I just hope that stuff doesn't break when I work on the 
compiler, and usually don't know what to do when users request changes 
to it.

Philipp



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

Re: [sdcc-devel] regression tests for pic14 and pic14e

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

Am 14.03.26 um 10:39 schrieb daniel k:
> How about linker scripts for other micros? Maybe by default they have a 
> section related to reset vector or isr address?
Some ports use a custom crt0 (e.g. z80),though there is a default one 
included in the library useful as an example for the user writing their own.

Some ports emit the interrupt table in the same file as main() (e.g. 
stm8, r4k).

I guess we have a "section" _IIVT for the interrupt vector table for 
r4k. For stm8 it is part of HOME. But I don't know much about the linker 
either. I just hope that stuff doesn't break when I work on the 
compiler, and usually don't know what to do when users request changes 
to it.

Philipp

Re: [sdcc-devel] regression tests for pic14 and pic14e

[daniel k <pro...@gm...>]

I guess it is related to gpasm.

One simple test - I can always do in e.g. - create a file in asm and add to
its code section absolute address .
run gpasm -c file.asm (it should build an object in relocated mode) - but
it is throwing an error.

One might wonder if there is a way to "trick" gpasm into mixing absolute
addresses with relocatable code without a linker script. Unfortunately, in
the gputils ecosystem, this is a fundamental limitation for several reasons:

Phase Separation: gpasm resolves absolute sections (code 0x0000) during
assembly. At this stage, it has no knowledge of where the linker (gplink)
will later decide to place relocatable objects from libraries (like
libsdcc).

Linker Blindness: The default linker scripts for many PIC14 devices define
page0 starting at 0x0000 without any PROTECTED range. Since the linker
doesn't "read" the absolute addresses defined in the ASM files, it assumes
the entire page is available and starts packing relocatable library
functions right at the beginning of the memory map.

Section Priority: When gplink encounters a conflict between a relocatable
section and an absolute one, it simply throws a "section overlap" error
because it lacks the logic to dynamically "shift" relocatable code around
an arbitrary absolute block defined in source code.

Conclusion:
Mixing these two worlds reliably is only possible through the Linker
Command File (.lkr).
That is how I understand this issue.
I can try to check some older gpasm release.

How about linker scripts for other micros? Maybe by default they have a
section related to reset vector or isr address?

Regards
Daniel K


sob., 14 mar 2026 o 09:35 Philipp Klaus Krause <pk...@sp...> napisał(a):

> Am 14.03.26 um 01:47 schrieb daniel k:
> > Hi again,
> > I have created a patch in sourceforge project with my changes .
> > https://sourceforge.net/p/sdcc/patches/494/ <https://sourceforge.net/p/
> > sdcc/patches/494/>
> >
> > I have just realized that I never really used sdcc in only-sdcc mode. I
> > always use sdcc to compile to asm + my own asm files + my own linker
> > script. So it seems that in the current approach it is the best (but not
> > easiest) approach. It gives maximum control with function locations
> > https://github.com/dk2233/PicThrowDK <https://github.com/dk2233/
> > PicThrowDK> . And it should be emphasizes in sdcc manual that without
> > your own linker script - it will always creates issues (or sometimes
> > just purely coincidence - it will properly locate sdcc_start and c_init
> > in expected location ;-))
>
> I have no idea about pic ports. But this looks like an a odd issue. For
> other ports we typically do okayish without hte user having to do such
> things manuall (except maybe z80 - target systems vary widely, so a
> custom crt0 is typically needed, and the use of --code-loc). Was this
> always a problem? Did it work with older SDCC/gputils?
>
> Philipp
>
>
>
> _______________________________________________
> sdcc-devel mailing list
> sdc...@li...
> https://lists.sourceforge.net/lists/listinfo/sdcc-devel
>