Sanity check: 8k enough flash for small project

"Mike" schreef in bericht news: snipped-for-privacy@example.com...

For a glorified timer in 8K you can even write in kindergarten C.

--
Thanks, Frank.
(remove 'x' and 'invalid' when replying by email)

There are two simple things you can do

• Collect/define all the messages (fonts?) and determine that storage.

• Get some of their examples, that are similar to what you intend, ad see how big they are.

• Check number types, if you plan on using a lot of floating point, and many menu trees, then 8K could get tight.

-jg

Should be plenty of room, let us know if it isn't.

As long as you don't start linking in full blown printf and floating point libraries it sounds like plenty.

Hi Mike,

Did you ever look at the assembly code or memory map of this project ?

If you did, this question would be obvious .....

Thanks for the responses. I think it will be plenty too...just wanted to bounce it off others. Since the LCD is alphanumeric, I won't be blowing memory on fonts and such.

To answer the above comment, I don't plan on writing/designing the code before I get the development board and compiler. I am not at all concerned with RAM. I figure 8k of flash probably gives me 7000 instructions or so (1k used for initialized data and such). Maybe average each line of C-code as 4 instructions. This should give me roughly 1700 lines of C to work with. Plenty for logic...doing fixed point integer arithmetic could get messy.

I'll second that. I did a medium complexity Z8 Encore project this year and found that attempts to use libraries would result in little remaining space for my code. For example, I wound up coding a specialized version of scanf() rather than including the string library. I also spent some time optimizing a message parser to keep things tight. Nothing too heroic but certainly not the first cut, either.

--
========================================================================
          Michael Kesti            |  "And like, one and one don't make

8K should be way more than you need, even if you write in loose C code.

Richard [in PE12]

3 bytes is also common

Wim

"Wim Ton" wrote in news:qJg9d.10208$BI5.7635 @fe2.news.blueyonder.co.uk:

Such measures also depend quite a bit on how you count lines and how the application is written. I once wrote a ~10K-15K line C application that worked out to slightly less than one byte per line of code. That was a bit of an anomoly though.

--
Walter Mallory   walter.mallory@mbda-us.com
Reach, Connect, Celebrate, Grow, Serve

Those are unrealistic ratios. The following code, with gcc on the x86, generates 76 bytes with -O3 optimization, 153 bytes without optimization. There are 4 lines generating code, 5 if you include initialization, 8 if you also insist on one statement per line. Most instructions are 2 bytes.

#include

int strncmp(const char *s1, const char *s2, size_t n) { unsigned const char *c1 = s1, *c2 = s2;

while (*c1 && (*c1 == *c2) && n) { c1++; c2++; n--; } if (n) return (*c1 > *c2) - (*c1 < *c2); else return n; } /* strncmp untested */

--
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
   Available for consulting/temporary embedded and systems.

With the Metrowerks 68K compiler, the example generated 78 bytes of code without optimization and 70 bytes with the highest level of optimization. As on the x86, most of the instructions generated were two bytes long (the minimum on the 68K). I wonder what the

2:1 difference says about optimization and the x86 instruction set?

Incidentally, rewriting the example the way I would normally write it----without mixing boolean and character expressions:

#include int strncmp(const char *s1, const char *s2, size_t n) { unsigned const char *c1 = s1, *c2 = s2; while ((*c1 != 0) && (*c1 == *c2) && (n > 0)) { c1++; c2++; n--; } if (n > 0) { if (*c1 > *c2) rval = 1; // did I get the sense right?? if (*c1 < *c2) rval = -1; } else rval = 0;

return rval; } /* strncmp untested */

results in a code length of 56 bytes optimized and 60 bytes unoptimized.

I guess that means that there really is a penalty for mixing up your boolean expressions with character and arithmetic comparisons! ;-)

Incidentally, the Codewarrior compiler didn't have to use any stack space for the temporary rval. The code used only the A0, A1, D0, D1, and D2 registers---which apparently can be used without a save and restore. The result is returned in D0.

Here's the assembly listing----not a lot of apparent fat in this code.

int xstrncmp( const char *s1, const char *s2, size_t n){

00000000: 222F 000C move.l 12(a7),d1 unsigned const char *c1 = s1, *c2 = s2; int rval; 00000004: 226F 0004 movea.l 4(a7),a1 00000008: 206F 0008 movea.l 8(a7),a0 while ((*c1 != 0) && (*c1 == *c2) && (n > 0)){ 0000000C: 6006 bra.s *+8 ; 0x00000014 *c1++; 0000000E: 5289 addq.l #1,a1 *c2++; 00000010: 5288 addq.l #1,a0 n--; 00000012: 5381 subq.l #1,d1 } 00000014: 1011 move.b (a1),d0 00000016: 6708 beq.s *+10 ; 0x00000020 00000018: B010 cmp.b (a0),d0 0000001A: 6604 bne.s *+6 ; 0x00000020 0000001C: 4A81 tst.l d1 0000001E: 66EE bne.s *-16 ; 0x0000000e if(n > 0){ 00000020: 4A81 tst.l d1 00000022: 6710 beq.s *+18 ; 0x00000034 if(*c1 > *c2) 00000024: 1210 move.b (a0),d1 00000026: B001 cmp.b d1,d0 00000028: 6302 bls.s *+4 ; 0x0000002c rval = 1; 0000002A: 7401 moveq #1,d2 if(*c1 < *c2) 0000002C: B001 cmp.b d1,d0 0000002E: 6406 bcc.s *+8 ; 0x00000036 rval = -1; 00000030: 74FF moveq #-1,d2 } else 00000032: 6002 bra.s *+4 ; 0x00000036 rval = 0; 00000034: 7400 moveq #0,d2 return rval; 00000036: 3002 move.w d2,d0 00000038: 4E75 rts }

Mark Borgerson

I think you got the return condition wrong. The exit portion should be:

if (n = 0) rval = 0; else if (*c1 > *c2) rval = 1; else if (*c1 < *c2) rval = -1; else rval = 0;

to handle strings that are of unequal length and less than n long. I think this code will be slower on machines doing look ahead because of extra pipeline flushing. The actual loop should generate the same code either way.

--
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
   Available for consulting/temporary embedded and systems.

At this point, I'll take your word for that.

Pipelines and special branch prediction hardware make it really difficult to optimize code for many of the newer processors. That's one of the reasons it is more difficult now for even an assembly- language expert to beat out the C compilers. You are essentially matching your skills against those of the processor expert who wrote the code generator for the compiler. I might enter the contest with the 68K systems and (going back a bit) the 6809 or 6800, but I would never make that bet with the MSP 430 or the ARM 7 series.

As my test showed, the programmer's C style can make a significant difference in the code generates. Perhaps the best results are to be had if the programmer writes C like he was writing assembly for the PDP-11 (been there, done that!)

Mark Borgerson

Fixed point is fine. It is the same as int. Beware of floats. Use fixed point instead.