From the web-site we know after 2009, PIC18F series had extended the instructions of ADDFSR/PUSHL/ADDULNK, etc. New instructions seems good for C compiler/linker. However,
from http://ww1.microchip.com/downloads/en/DeviceDoc/C18_UG__51288e.pdf,
in section 3.2, we find for MPLAB C18, its C stack is still increasing the address when
PUSH data, and it uses FSR2 as the FRAME pointer, FSR1 as the STACK pointer. Sadly,
PUSHL instruction operates on FSR2, and decreasing, which means PUSHL cannot be used in C18
toolchain. It is really a pity that PUSHL can usually reduce the code size 3~8%.
By the way, for barebone systems like P18, "omit-frame pointer" optimization can still be easy to
implement debugging of local variables, and can save an FSR for user's code, also saves dual-2-byte pointer
operations of function prologue/epilogue. Those are a lots of codes. But "omit-frame-pointer" seems not
an option for MPLAB C18.
Seems MPLAB focus on the correctness of all parts include PIC16/14, etc. Calling convention modification
is just not an option.
Will SDCC's PIC18 port using PUSHL of the extend instructions?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The pic14 and pic16 ports are unmaintained.
I cannot rule out the possibility of a future new maintainer implementing support for those instructions. But at the moment, the future doesn't look good for the pic ports.
P.S.: Currently 116 out of 313 open sdcc bug reports are pic-specific. The pic ports also use gputils, which are currently unmaintained, too.
Last edit: Philipp Klaus Krause 2021-05-07
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
From the web-site we know after 2009, PIC18F series had extended the instructions of ADDFSR/PUSHL/ADDULNK, etc. New instructions seems good for C compiler/linker. However,
from http://ww1.microchip.com/downloads/en/DeviceDoc/C18_UG__51288e.pdf,
in section 3.2, we find for MPLAB C18, its C stack is still increasing the address when
PUSH data, and it uses FSR2 as the FRAME pointer, FSR1 as the STACK pointer. Sadly,
PUSHL instruction operates on FSR2, and decreasing, which means PUSHL cannot be used in C18
toolchain. It is really a pity that PUSHL can usually reduce the code size 3~8%.
By the way, for barebone systems like P18, "omit-frame pointer" optimization can still be easy to
implement debugging of local variables, and can save an FSR for user's code, also saves dual-2-byte pointer
operations of function prologue/epilogue. Those are a lots of codes. But "omit-frame-pointer" seems not
an option for MPLAB C18.
Seems MPLAB focus on the correctness of all parts include PIC16/14, etc. Calling convention modification
is just not an option.
Will SDCC's PIC18 port using PUSHL of the extend instructions?
The pic14 and pic16 ports are unmaintained.
I cannot rule out the possibility of a future new maintainer implementing support for those instructions. But at the moment, the future doesn't look good for the pic ports.
P.S.: Currently 116 out of 313 open sdcc bug reports are pic-specific. The pic ports also use gputils, which are currently unmaintained, too.
Last edit: Philipp Klaus Krause 2021-05-07