Subject:
Re: SDCC
From:
Scott Dattalo ####@####.####
Date:
14 Nov 2001 03:19:42 -0000
Message-Id: <Pine.LNX.4.33.0111131851070.27761-100000@ruckus.brouhaha.com>
On Wed, 14 Nov 2001, matt wrote:
> On Tue, 13 Nov 2001 22:26, Ralf Forsberg wrote:
> > I've been writing a few tests for sdcc, and then bothering Scott
> > about those that don't work. As I did that I got curious about
> > how the generated code compared to other compilers.
> >
> > I tried my "alfa.c" on the pic compilers I could find, and then
> > measured execution time using gpsim. All compilers are demo versions
> > downloaded from the web. It may be that the regular versions are better,
> > but that seems strange.
> >
> > It may not say much, alfa.c perhaps is not the most 'average' program.
> >
> > accumulated cycles:
> > sdcc picc picc -O -Zg9 CCSC sdcc uchar mpc
> > init 2 0x145 0x143 ? 9
> > t1 0xc7 0x24a 0x214 0x76 0x5e ?
> > t2 0x708 0xbae 0x96b 0x46c 0x36c 0x9b3
> > t3 0x26303 0x3d381 0x2e3cd 0x1f7f6 0x14585 0x3fbbe
> >
>
> Ok, here's my thoughts. I would be VERY VERY VERY surprised if sdcc could
> beat all those compilers this well with Scott still developing it.
Matt,
There's no reason for suprise, I've seen the code SDCC's produced.
> here's my thoughts. Check all the hex. files to see if they work.. not if
> they simply execute to the end.
The code is accurate too, but you're implication is partially correct.
The PIC port of SDCC is by no means complete. The parts that are complete
are fairly well optimized. Look here to get an idea what SDCC is capable
of:
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/sdcc/sdcc/src/regression/
These are regression tests I've created to verify SDCC's correctness. I
haven't run these tests against any of the other compilers. I know that
SDCC passes on all of them, however.
>
> Specifically Ralf could supply results of the execution to prove that indeed
> singed math was used (big over head here) and that all compilers were
> actually doing 16 bit math (bigger overheads obviously)... and even look to
> see if in-line functions were ever employed.
> This is not an error, but might explain how a compiler is winning - ie. it's
> not really optimising the maths, just killing little bits of code around the
> place..
Again, within the scope of this specific test, SDCC is the fastest
executing. Although I wouldn't be surprised if MPC or Hi-Tech can be
supplied with the proper command line options to improve their execution
and even beat SDCC. C2C (not tested) and CCSC, otoh, probably don't have a
chance.
----
I still have *, /, and % to complete before the basic operation of the PIC
port is done. At this point, SDCC will be capable of compiling single .c
files to produce an excutable. This is somewhat like C2C's limitation, but
will probably be useful for many applications. I expect these to be done
within 4 weeks. After that I'll start performing more rigorous tests that
involve pointers, structures, etc. A solid beta should be ready around
February or March '01.
Also going on unnoticed is Craig's linker development. I suspect that
Craig will have something ready about the time I need it - not to put
words in his mouth though. I'll be porting a portion of SDCC to the
linker. The linker will be an optimizing one. In fact, properly
constructed assembly will be optimizable too! By properly constructed, I
don't mean inefficiently written :). Instead, I mean using some new gpasm
pragmas that will be added. So things like register overlaying, function
inlining, peep hole optimizing, tail optimizing, etc. will be introduced
to the linker.
Scott
