Thank you Vincente, Will re-installing SDCC from the latest snapshot include the updated rules?
Best Regards, - Royce Pereira, T-Star Instrumentation, 102, Creative Industries, Sunder Nagar Road # 2, Kalina, Santacruz-East, Mumbai- 400098, INDIA Cell: +91 9820061636 *GSTIN*: 27AAFFT2843M1ZS P *Let's care for our Environment. * *Please don't print this e-mail unless you really need to.* On Fri, 19 Feb 2021 at 02:04, Vicente Sendra via Sdcc-user < sdcc-user@lists.sourceforge.net> wrote: > When tested with the rules uploaded here: > https://sourceforge.net/p/sdcc/patches/362/ > > The code is fully optimized as expected: > _test_bits: > ; ../src/test2.c: 26: PD_ODR |= 1<<1 ; > ; skipping iCode since result will be rematerialized > ; skipping iCode since result will be rematerialized > ; genPointerGet > ; genOr > ; genPointerSet > bset __PD_ODR_+0, #1 > ; peephole replaced 'or' by 'bset' (compiler symbol). > ; ../src/test2.c: 28: PD1 = 1 ; > ; skipping iCode since result will be rematerialized > ; skipping iCode since result will be rematerialized > ; genPointerSet > bset __PD_ODR_+0, #1 > > When I finish my work in progress for SWAP, RRC and RLC operations for > STM8 (it's taking longer than expected), I'll update/fix the patches for > the rules against the current version of SDCC. > > I hope Philipp will merge them all then. > > > En jueves, 18 de febrero de 2021 17:32:27 CET, Georg Icking-Konert < > ge...@cream-tea.de> escribió: > > > Hello Royce, > > I also found it inconvenient that SDCC provides no STM8 headers. Therefore > I developed them and made them available as OSS under > https://github.com/gicking/STM8_headers. There you also find examples how > to use them. Hope this helps!? > > Regards, Georg > > PS: I also asked the SDCC developer team whether these headers could be > included into the SDCC distribution. So far no response (hint, hint...) > > > Am 18.02.21 um 16:32 schrieb Royce Pereira (T-star Instrumentation): > > As there is no header file for STM8, I was trying to create my own using 2 > different approaches. > They each produce different -though correct- outputs. > > Code Sample 1: > > typedef struct > { > unsigned char PIN0:1 ; > unsigned char PIN1:1 ; > unsigned char PIN2:1 ; > unsigned char PIN3:1 ; > unsigned char PIN4:1 ; > unsigned char PIN5:1 ; > unsigned char PIN6:1 ; > unsigned char PIN7:1 ; > } _BITS_ ; > > typedef union > { > _BITS_ sbits ; > unsigned char _sfrByte_ ; > } _SFR_ ; > //-------------------------------- > volatile _SFR_ __at (0x500F) _PD_ODR_ ; > //--------------------------------- > #define PD_ODR _PD_ODR_._sfrByte_ > #define PD1 _PD_ODR_.sbits.PIN1 > > //--------------------------------- > void main(void) > { > PD_ODR |= 1<<1 ; > PD1 = 1 ; > } > //--------------------------------- > > This produces (main.asm): > .globl _main > .globl __PD_ODR_ > ;-------------------------------------------------------- > ; ram data > ;-------------------------------------------------------- > .area DATA > __PD_ODR_ = 0x500f > > ...... some instructions ...... > > _main: > ; main.c: 26: PD_ODR |= 1<<1 ; > ld a, __PD_ODR_+0 > or a, #0x02 > ld __PD_ODR_+0, a > ; main.c: 28: PD1 = 1 ; > bset __PD_ODR_+0, #1 > ; main.c: 29: } > ret > > ======================================== > Code sample 2: > > #define _SFR_(mem_addr) (*(volatile unsigned char *)(0x5000 + > (mem_addr))) > /* PORT D */ > > #define PD_ODR _SFR_(0x0F) > > void main(void) > { > PD_ODR |= 1 << 1 ; > } > //------------------------------------------- > Produces: > > _main: > ; main.c: 9: PD_ODR |= 1 << 1 ; > bset 20495, #1 > ; main.c: 10: } > ret > > This does seem more efficient. > > Its curious why the "PD_ODR |= 1<<1" produced the "ld a ...." in the 1st > example, > while just the 'bset ...' in the second, when both cases were absolute > addresses. > > The 1st sample did produce "bset" for "PD1=1",(which is essentially > "PD_ODR = 1 <<1" ). > > Best Regards, > > - Royce Pereira, > > T-Star Instrumentation, > 102, Creative Industries, > Sunder Nagar Road # 2, > Kalina, Santacruz-East, > Mumbai- 400098, > INDIA > > Cell: +91 9820061636 > > *GSTIN*: 27AAFFT2843M1ZS > > P *Let's care for our Environment. * > > *Please don't print this e-mail unless you really need to.* > > > _______________________________________________Sdcc-user mailing > listSdcc-user@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/sdcc-user > > _______________________________________________ > Sdcc-user mailing list > Sdcc-user@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/sdcc-user > _______________________________________________ > Sdcc-user mailing list > Sdcc-user@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/sdcc-user >
_______________________________________________ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
