gnupic: SDCC pic port status
Subject:
SDCC pic port status
From:
Scott Dattalo ####@####.####
Date:
26 Dec 2000 20:38:46 -0000
Message-Id: <Pine.LNX.4.21.0012261412240.11932-100000@tempest2.blackhat.net>
I've moved back to California and have resumed development. The last few weeks,
as you can imagine, have been slow. I still don't have an ISP(*) so am unable to
commit my changes to CVS, but here's what's working so far: for loops, while
loops, addition between bit/char/ints, pointers, case statements, and arrays. I
still have all of the operators to work out. However, I've concentrated on
addition with the idea that other operators should be similar.
The efficiency is still relatively good. However, since SDCC was originally
targetted to an 8051, there are few 8051-isms that have crept into its
design. Some of these are proving to be a real challenge to implement
efficiently on a pic (but if you're satisfied with inefficient 8051-like code,
then it's just fine). For example, the whole concept of indirect addressing with
INDF/FSR is totally different than the @r0 or @r1 addressing. As a consequence,
this generates horrible code:
for(i=0; i<5; i++)
some_array[i]=0;
(this should take no more than 6 pic instructions [don't forget that i should
equal 5 after the loop executes]. The version I've got working is about 10
instructions and loops 4 times. Yuck.)
There are now about 7 files part of the regression test. This is proving to be
invaluable in catching errors. Often times a "fix" in one area breaks something
in another area.
Hopefully I'll have an ISP real soon so that the changes can be submitted. In a
month, SDCC should be generating usable PIC code. However, there still is a
substantial amount work still left. Some of the major issues are banking and
linking. The latter may involve modifying gpasm and gpsim too.
Scott
(*)
PS. Anyone have any good recommendations for an ISP in the SF bay area?
