[Openec] checksum of first 64k of updateme.bin not calculated correctly

[Paul Fox]

i wrote:
 > frieder wrote:
 >  > The memory model currently used (--model-large) for SDCC
 >  > is typically generating about 33% larger code than the
 >  > (--model-small) or about 18% larger code than the
 >  > stack-auto memory model.
 >  > (ratios from regression test results)
 > 
 > we should certainly look at using small, then.  when i built a
 > comparable set of 1.75 source on both keil and sdcc "large", keil was
 > about 2/3's the size.  many of our accesses are to xdata, as you
 > noticed, so we might not get the full gain of small, but if it could
 > keep us on sdcc we'd all be happier.

well, i switched to --model-small, and then added xdata keywords to
global and static declarations until i no longer got "Could not get NN
consecutive bytes in internal RAM for area DSEG" messages.

doing this took us from 39K to 36K of code, clearly much less than a
33% savings.  presumably this is because our xdata needs are so big
that we don't get a big savings.  does that seem right?

switching to 3.0, as you predicted, gave minimal savings -- under 100
bytes.

we can eliminate some code (e.g., we probably don't need all of
monitor(), for instance, and the 1150 byte "updateme" image will go
away when we switch to the 3731).  we also know that we can use bit
variables for many of our booleans, and some data is probably
redundant -- porting our code to the new framework has exposed some of
that.  but i'm not optimistic about fitting in 32K -- at least not
with comfortable breathing room.  :-/

(i also spent time converting the code to keil.  using large model it's
28K, and small model is around 26K.)

paul

 > 
 >  > 
 >  > 
 >  > > Is sdcc 3 any better at generating smaller code?
 >  > 
 >  > If so then likely in the (low) single digit percent range.
 >  > BTW SDCC 3.0.0 has been released today.
 > 
 > great!  i'll try it.
 > 
 >  > 
 >  > 
 >  > The ec-1.75 source often uses code which clears/sets/
 >  > toggles bits within an external __xdata array.
 >  > SDCC does not recognize this yet.
 >  > Taking for example the last lines of the code generated
 >  > for updateme.c
 >  > 
 >  >                            1150 ;       updateme.c:423: xbi[SPICFG] &= 
 >  > ~(SPICFG_WEN | SPICFG_CS_LOW);
 >  >    0404 90 FE AD           1151         mov     dptr,#(_xbi + 0x000d)
 >  >    0407 E0                 1152         movx    a, at dptr
 >  >    0408 FA                 1153         mov     r2,a
 >  >    0409 53 02 E7           1154         anl     ar2,#0xE7
 >  >    040C 90 FE AD           1155         mov     dptr,#(_xbi + 0x000d)
 >  >    040F EA                 1156         mov     a,r2
 >  >    0410 F0                 1157         movx    @dptr,a
 >  > 
 >  > These type of accesses could be reduced to:
 >  > 
 >  >                            1150 ;       updateme.c:423: xbi[SPICFG] &= 
 >  > ~(SPICFG_WEN | SPICFG_CS_LOW);
 >  >    0404 90 FE AD           1151         mov     dptr,#(_xbi + 0x000d)
 >  >    0407 E0                 1152         movx    a, at dptr
 >  >    0409 xx E7              1154         anl     a,#0xE7
 >  >    040F xx                 1156         mov     r2,a
 >  >    0410 F0                 1157         movx    @dptr,a
 >  > 
 >  > with relatively little effort by using a peephole file.
 > 
 > yes, we were talking about that sort of construct just a day or two
 > ago.  fixing that would help a lot.
 > 
 > regarding optimization -- from the sdcc docs, it looks like most (all?)
 > optimizations are on by default, and the options exist to disable them,
 > correct?  so there's nothing we should be adding to the makefile to
 > make sure we're getting all available benefit?
 > 
 > paul
 > =---------------------
 >  paul fox, pgf at laptop.org
 > _______________________________________________
 > Openec mailing list
 > Openec at lists.laptop.org
 > http://lists.laptop.org/listinfo/openec

=---------------------
 paul fox, pgf at laptop.org