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
<[email protected]> 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
[email protected]https://lists.sourceforge.net/lists/listinfo/sdcc-user
_______________________________________________
Sdcc-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/sdcc-user
_______________________________________________
Sdcc-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/sdcc-user
