free-pdk / pdk-includes

Device Include files for Padauk MCUs
GNU General Public License v2.0
10 stars 8 forks source link

Add a check and prompt to rename _sdcc_external_startup to __sdcc_external_startup with newer SDCC versions #14

Open basilhussain opened 1 year ago

basilhussain commented 1 year ago

As you may be aware, as of current SDCC development version 4.2.10, and for the forthcoming release version 4.3.0, the _sdcc_external_startup function has been renamed to __sdcc_external_startup (note the additional underscore at the beginning). See SDCC feature request #859.

This creates potential compatibility problems for Free-PDK header users who:

In both cases, the user will encounter transparent (i.e. without warning or error) failure or misbehaviour due to omission of system clock initialisation and calibration that is typically done inside the startup function by the Free-PDK header macros.

While there are potentially plans to solve the former issue SDCC-side (see feature request #868), I have devised a way of helping the latter case, and also situations where existing codebases are updated to the latest Free-PDK includes.

Because it is (one way or another) obligatory to call the PDK_SET_SYSCLOCK() macro within the startup function, it can be used as a convenient point to make a check on the name of the startup function when necessary.

This modification adds a check against the SDCC version in use, and if it's a version equal to or newer than the revision the change to __sdcc_external_startup was made, it uses inline assembler macros to then check whether a label (i.e. function) is defined with the old name. When one is, an error message is emitted prompting the user to update their code to the new name:

**** ERROR: You are using an SDCC version newer than 4.2.9 ****
**** Please rename _sdcc_external_startup to __sdcc_external_startup ****
main.asm:227: Error: <e> .error/.assume programmed error

Where the user is already using the new name, the check is entirely transparent.

Note that the check does not change the code emitted by the macro. The check takes place entirely at compile-time.

basilhussain commented 1 year ago

By the way, if you're wondering why not also add the opposite check, for use of __sdcc_external_startup with SDCC older than 4.2.10, unfortunately it would not be practicable.

The .ifdef, .msg, and .error assembler directives were not ported across from upstream ASxxxx until SDCC revision 13177 (post 4.2.0 release, pre 4.2.1), so the same technique would only work for a narrow range of dev versions.

serisman commented 1 year ago

Looks like a 'fix' for SDCC feature request #868 has been implemented with commit r13850.

I suppose that makes this PR less necessary.

basilhussain commented 1 year ago

Yes, indeed. Thanks to @spth for adding it unexpectedly quickly.

However, the SDCC change only emits a warning and lets compilation proceed, whereas my suggested change actually causes compilation (or, technically, the assembly stage) to fail altogether and the message makes explicitly clear what the situation is and what needs to be changed, so I think it still has some merit even in light of the SDCC feature.