As I said, I wanted to finish my other patch for SWAP, RRC and RLC.
I have completed my work with that patch, so I hope now, I can review the rules
and update the patches for the current snapshot.
Then merging it with the current snapshot will be up to Philipp.
But I think he's been pretty busy lately. So it may take some time to keep up.
Meanwhile you can use my rules as extra rules using the --peep-file command
line option (I do it all the time to do a fast test of my rules).
Of course you can also modify the peeph.def file yourself and also compile SDCC
yourself (provided you already valid toolchain installed to compile it and you
want to invest some time to make it compile).
En viernes, 19 de febrero de 2021 04:55:24 CET, Royce Pereira (T-star
Instrumentation) <royce.pere...@tstar.co.in> escribió:
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
_______________________________________________
Sdcc-user mailing list
Sdcc-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sdcc-user
