RE: [Sdcc-user] ATMEL 8051 - SDCC Vs KEIL (and general optimizati on notes)

[Stephen O. <sob...@fr...>]

I don't know much about writing compilers; the most depth I've ever gone
into was making an ugly patch for my SDCC, to make it support the paste
operator between / and * operate correctly).  I'm just throwing in my $0.02.


It seems to me that SDCC misses a number of potential optimizations, like
this one suggested by Frieder Ferlemann (which was sent to SDCC-Devel):

---
Convert multiplication by 3:

   0069 75 F0 03            208 	mov	b,#0x03
   006C EA                  209 	mov	a,r2
   006D A4                  210 	mul	ab

to:

   0066 EA                  207 	mov	a,r2
   0067 2A                  208 	add	a,r2
   0068 2A                  209 	add	a,r2
---

About an hour after that mail was sent to the list, it was discovered that
this optimization is flawed, because sometimes
the compiler relies on 'b' being 0x03 after the move.

---

Another one, also by Frieder, is:

---

        mov     r%1,a
        mov     dpl,r%1
%2:
        ret

to

        mov     dpl,a
%2:
        ret

---

This is safe because of the 'ret', but a similar peephole cannot currently
be done in the middle of a function
because the compiler might use r<whatever> later on.


These flaws all occur because, while certain register moves are unnecessary
for a particular operation (like
a -> rX -> dpl ==> a -> dpl), the register moves that are unnecessary at the
time may be relied on by later code.
The suggestion/question I pose is, would it be feasible to mark a register
as 'trashable' when the next access to it will be
a move into it?

Example:

(I *think* this is valid assembly.  Remember, I use SDCC so I can program in
C!)

	...
	mov a, #0x02		; forget the inefficieny, this is a
SIMPLIFIED EXAMPLE
	mov r1, a			; r1=trashable -- the next
instruction using it writes to it
	mov dpl, r1
	mov r1, #0x01
	...

*BUT* pitfall alert...

	...
	mov a, #0x02		; a is NOT trashable! while the next
operation DOES write to it, it uses it as an input!
	mov r1, a			; once again, r1=trashable
	mov dpl, r1
	anl a, #0xF0		
	...

Questions? Comments? Offers of money? 
I know it's possible -- is it feasible?

	
-- 
Stevie-O

Real programmers use COPY CON PROGRAM.EXE


> -----Original Message-----
> From: Royce & Sharal Pereira [mailto:be...@et...]
> Sent: Tuesday, January 07, 2003 2:41 AM
> To: SDCC
> Subject: Fw: [Sdcc-user] ATMEL 8051 - SDCC Vs KEIL
> 
> 
> Hi,
> ----- Original Message -----
> From: "Renaldo Noma" <ren...@fa...>
> 
>  When I compile with SDCC, the BIN file  have a size about 
> 7.9KB, but with
> Keil I got 5.3KB. I think this is a
> > very big difference. And with Keil I can add more features to my
> > system because there still enough room for the code.
> 
> There is plenty of scope for SDCC to generate really compact code..
> Like how about deciding automatically to use 'caller saves' or 'callee
> saves' for any function depending on the no. of registers 
> used by the caller
> v/s callee?
> Also to remove some redundant code like:
> 
>  mov r2,a
> ; genPlus
>  mov a,ar2
> 
> Some code is long winded(These are just clips from one of my 
> applications):
> Example 1:
>             unsigned char st_no;
>             st_no= P3_2<<3;
> gives:-
>  clr a
>  mov c,_P3_2
>  rlc a
>  swap a
>  rr a
>  anl a,#0xf8
>  mov _st_no,a
> 
> When it could be:-
> 
> clr a
> setb acc.3
> mov   _st_no,a
> ------------------------------
> Example 2:
>         bit flg_st_ch; unsigned char dat_no;
>         dat_no=flg_st_ch?34:63;
> gives:-
>  jnb  _flg_st_ch,00151$
> 00178$:
>  mov r2,#0x22
>  sjmp 00152$
> 00151$:
>  mov r2,#0x3F
> 00152$:
>  mov _dat_no,r2
> 
> When it could be:-
> 
>  jnb  _flg_st_ch,00151$
> 00178$:
>  mov _dat_no,#0x22
>  sjmp 00152$
> 00151$:
>  mov _dat_no,#0x3F
> 00152$:
> (SDCC puts intermediate values in registers even when they 
> will not be used
> later..probably there could be a way to decide when not to..)
> --------------------------------
> Example 3:
>         bit flg_st_ch; unsigned char dat_no;
>         flg_st_ch= (dat_no>17)?1:0;
> gives:-
> 
>  clr c
>  mov a,#0x11
>  subb a,_dat_no
>  jnc  00153$
> 00179$:
>  mov r2,#0x01
>  sjmp 00154$
> 00153$:
>  mov r2,#0x00
> 00154$:
>  mov a,r2
>  add a,#0xff
>  mov _flg_st_ch,c
> 
> When it could be:
> 
> clr c
>  mov a,#0x11
>  subb a,_dat_no
>  mov _flg_st_ch,c
> ------------------------------------------------
> I dont know how difficult or feasible the above refinements 
> are. I dont mean
> to be unappreciative ;-) the developers are already working 
> hard to make
> sdcc a great package..on the other hand, I do want to see 
> sdcc compete with
> other so-called 'professional' packages. Price need not be 
> the only criteria
> to choose SDCC!
> 
> Thanks,
> 
> --Royce.
> 
> 
> 
> -------------------------------------------------------
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
> http://www.vasoftware.com
> _______________________________________________
> Sdcc-user mailing list
> Sdc...@li...
> https://lists.sourceforge.net/lists/listinfo/sdcc-user
>