[Openec] checksum of first 64k of updateme.bin not calculated correctly
Paul Fox
pgf at laptop.org
Mon Nov 1 09:01:37 EDT 2010
frieder wrote:
> Hi Richard,
>
> Am 01.11.2010 10:04, schrieb Richard A. Smith:
> > On 11/01/2010 03:56 AM, Frieder Ferlemann wrote:
> >
> >> Do you see problems/shortcomings (or near term problems)
> >> with the current code?
> >> (In terms of data, xdata, code memory or functionality?)
> >
> > The existing info out on IRC is a bit premature. I was waiting until
> > after 1.75 bringup to write up the announcement and the general state of
> > affairs.
>
> Fine.
yes, it's definitely rough, still. :-)
>
> > Resource wise the KB3930 has plenty of resources, but its only a
> > stepping stone. There are certainly some challenges ahead for moving to
> > the IO3730. It only has 32k of ROM and does not have in-ram code
> > execution ability.
> >
> > Right now it looks like we will have to switch back to Keil because sdcc
> > generate code is so much larger.
>
> How much space is left in data memory and in code memory?
> (Can you give numbers for Keil versus SDCC?)
>
> 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.
>
>
> > 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
More information about the Openec
mailing list