[Sdcc-user] missing possible optimizations?

[Josh S. <jo...@4s...>]

Hello everyone,

I'm using SDCC with a Cygnal C8051F320 MCU.  I've got everything working
great - my code compiles and appears to be running flawlessly.  However, I
think SDCC is missing some fairly simple optimizations.  I'm trying to
figure out whether I am missing some options, or if SDCC has a few areas it
could improve...  As a disclaimer, while I do have some familiarity with
compiler design, I haven't looked into the source of SDCC yet, so I don't
know how hard it would be to do the things I'm going to mention.  Also, in
the past I have used only Motorola processors, so it might be that I am
missing some intricacies of the 8051.

I'm going to try to be very complete in this message, so I'll apologize now
for its length.  I haven't included my actual project, but I've attached a
very small test program that manages to illustrate a few opportunities for
optimization by the compiler.  Some of it may look pretty strange, because I
have included only the essential parts needed to make the code fragment
compile.  And in this form the code won't do anything useful, but it
compiles, which is all I was going for.  At the bottom of this message
you'll see my SDCC version and the compiler command to make this.

So, now to the meat of my message.  I will list code with line numbers, and
then my comments on improvements that I think SDCC should be able to find.
If I skip line numbers, it's because those were just comments.  If you
really want to see the comments, please look in the attached zip file.


<test.asm snip>
155:	mov	r2,a
158:	mov	a,#0x01
160:	add	a,r2

This could be optimized to:
	mov	r2,a
	inc	a
This could be corrected with a peep-file, but it seems like something that
the compiler should have done better in the first place.


<test.asm snip>
164:	mov	r3,a
165:	mov	dptr,#(_FC_Commands + 0x0100)
166:	movx	@dptr,a
168:	mov	r3,#0x00
171:	mov	a,r2
172:	add	a,#_FC_Commands
173:	mov	dpl,a
175:	mov	a,r3
176:	addc	a,#(_FC_Commands >> 8)
177:	mov	dph,a

The entire use of r3 here is unnecessary.  There's a few optimizations that
would remove it completely.  First, line 164 is a dead store due to 168.
Constant propagation from 168 to 175 lets you simplify 175 to "clr a".  At
this point, the definition at 168 is now also dead code.


<test.asm snip>
188:	mov	r2,#0x00
191:	mov	r3,_main_response_1_1
193:	mov	a,r3
195:	orl	a,r2
196:	mov	_P_Data,a

This part is a huge simplification of my macro WRITE_P_DATA.  With the given
values of On_Mask and Inv_Mask, almost the entire expression can be reduced.
I could do this by hand, but I would rather leave it, as I may need to
change either the On_Mask or Inv_Mask later.  When the masks are any other
values, the expression actually does a fair amount of work.  Yes, me being
lazy now means more work for the compiler, but that's what computers are
for, right?  So anyway, it looks like the compiler was (correctly) able to
reduce the macro down to:
	P_Data = 0x00 | response[0];
That it got that far is actually pretty impressive.  But, ORing with zero
changes nothing.  So this could be reduced further to:
	P_Data = response[0];
And in asm, this could be written with a single line:
	mov _P_Data,_main_response_1_1


<test.c snip>
18: int main()
19: {
20:	BYTE response[3];
21:	response[0] = CBExtractF(FC_Commands);
22:	WRITE_P_DATA(response[0]);
23:	return 0;
24: }

Because the 'response' is a local, non-volatile array, shouldn't the
compiler be able to eliminate its use?  It seems straightforward to make
this:
	int main()
	{
		WRITE_P_DATA(CBExtractF(FC_Commands));
		return 0;
	}


This whole thing feels to me like SDCC somehow got optimizations turned off
or limited, but the only command line options I see are to disable
optimizations, which tells me that they are on by default.  Or perhaps there
are some areas where it could be a little more aggressive, in which case an
option to make it more aggressive woul be nice.  I would much rather
sacrifice a little compile time to make the resulting code better.

Any input on all of this would be much appreciated...

Thanks,

Josh Stone


ps - give yourself a pat on the back if you made it this far... again, I
apologize for being so long-winded.



I am using the Windows snapshot from June 19, 2003.  "sdcc -v" says:
SDCC : mcs51/gbz80/z80/avr/ds390/pic14/pic16/TININative/xa51/ds400 2.3.5
(Jun 19 2003) (MINGW32)


Compile command is:
sdcc -mmcs51 --model-small --idata-loc 0x80 --iram-size 0x100 --xram-loc
0x0 --xram-size 0x400 --code-loc 0x0 --code-size 0x3E00 --out-fmt-ihx test.c

* Yes, I know that I am specifying many options that are defaults - I just
like to be thorough.  Besides, I use makefile's, so it's no skin off my
back...