Dear All, Two years I attended a Hitachi Embedded Seminar. They presented their embedded low power Flash microcontrollers there. The Presenter said: " If you look to the die you'll see that the cpu is only a small fraction and the flash part occupies much of it. Especially if the flash size is >32k." If this is real why don't they change the architecture to save some flash size? Any Comments? I am sure somebody has already worked on it.
reducing flash size in embedded processors?
Started by ●October 2, 2004
Reply by ●October 2, 20042004-10-02
Hi, the modern trend is to write single chip applications in C, much easier than assembler for micros like the Hitachi range. The consequence is that you need all that extra memory, both rom and ram, for allmost any practical program.
Reply by ●October 2, 20042004-10-02
On 2004-10-02, booth multiplier <boothmultipler@hotmail.com> wrote:> If you look to the die you'll see that the cpu is only a small > fraction and the flash part occupies much of it. Especially if > the flash size is >32k."> If this is real why don't they change the architecture to save > some flash size?How do you suggest they do so? -- Grant Edwards grante Yow! I brought my BOWLING at BALL -- and some DRUGS!! visi.com
Reply by ●October 2, 20042004-10-02
On 2004-10-02, CBarn24050 <cbarn24050@aol.com> wrote:> Hi, the modern trend is to write single chip applications in > C, much easier than assembler for micros like the Hitachi > range. The consequence is that you need all that extra memory, > both rom and ram, for allmost any practical program.You seem to be implying that writing a program in C requires significantly more memory than writing in assembly language. In my experince that simply isn't true. -- Grant Edwards grante Yow! Gibble, Gobble, we at ACCEPT YOU... visi.com
Reply by ●October 2, 20042004-10-02
> >You seem to be implying that writing a program in C requires >significantly more memory than writing in assembly language. > >In my experince that simply isn't true. >Hi, do you have first hand experience of that? Perhaps you could provide some real world examples.
Reply by ●October 2, 20042004-10-02
CBarn24050 wrote: (*** and neglected to preserve attributes ***)> >> You seem to be implying that writing a program in C requires >> significantly more memory than writing in assembly language. >> >> In my experince that simply isn't true. > > Hi, do you have first hand experience of that? Perhaps you could > provide some real world examples.Try it for yourself. Write some moderately complex function of 5 or 10 lines, compile it to an object module (gcc -gstabs+ -Wa,-ahldn -c source.c works for me) with various optimization settings, and examine the assembly code. Then see if you can significantly improve that code. In general a large portion of the bulk from simple C programs arises from the library and startup code. -- Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net) Available for consulting/temporary embedded and systems. <http://cbfalconer.home.att.net> USE worldnet address!
Reply by ●October 2, 20042004-10-02
CBFalconer wrote:> CBarn24050 wrote: (*** and neglected to preserve attributes ***) >> >>> You seem to be implying that writing a program in C requires >>> significantly more memory than writing in assembly language. >>> >>> In my experince that simply isn't true. >> >> Hi, do you have first hand experience of that? Perhaps you could >> provide some real world examples. > > Try it for yourself. Write some moderately complex function of 5 > or 10 lines, compile it to an object module (gcc -gstabs+ > -Wa,-ahldn -c source.c works for me) with various optimization > settings, and examine the assembly code. Then see if you can > significantly improve that code. > > In general a large portion of the bulk from simple C programs > arises from the library and startup code. >Tight loops blitting data to video hardware, assembler wins hands down every time. Ian -- Ian Bell
Reply by ●October 2, 20042004-10-02
> >Try it for yourself. Write some moderately complex function of 5 >or 10 lines, compile it to an object module (gcc -gstabs+ >-Wa,-ahldn -c source.c works for me) with various optimization >settings, and examine the assembly code. Then see if you can >significantly improve that code.Well if your saying that compiling by hand is not much better than letting a compiler do it then I would agree with you. That is not the same as saying C produces code of a similar size to assembler. Try taking a small job, write in C then write in assembler and see the difference.>In general a large portion of the bulk from simple C programs >arises from the library and startup code. >Librarys can be quite big but the startup code should be minimal, maybe 100 instructions.
Reply by ●October 2, 20042004-10-02
> >My experience is that C code is usually 20% to 70% larger, depending on >several factors. If you are familiar with the compiler's output, you >can reduce your program's size while coding in C. One simple technique >is recoding to eliminate library functions that are only called once or >twice. Know the tradeoff between using compile-time constants and >run-time parameters. Know the tradeoff between function-like macros (or >inline functions) and callable functions. Know the size and precision >requirements of the data; know which data must be signed. > >Thad >Hi Thad, maybe you could provide some real word example to prove your point.
Reply by ●October 2, 20042004-10-02
Ian Bell wrote:> CBFalconer wrote: >>CBarn24050 wrote: (*** and neglected to preserve attributes ***) >> >>>>You seem to be implying that writing a program in C requires >>>>significantly more memory than writing in assembly language. >>>> >>>>In my experince that simply isn't true. >>> >>>Hi, do you have first hand experience of that? Perhaps you could >>>provide some real world examples. >> >>Try it for yourself. Write some moderately complex function of 5 >>or 10 lines, compile it to an object module (gcc -gstabs+ >>-Wa,-ahldn -c source.c works for me) with various optimization >>settings, and examine the assembly code. Then see if you can >>significantly improve that code. >> >>In general a large portion of the bulk from simple C programs >>arises from the library and startup code. > > Tight loops blitting data to video hardware, assembler wins hands down every > time.I'm sure it's much faster, but the discussion is on memory space. While the assembler loop is probably tighter, too, it is usually a very small part of a complete program. My experience is that C code is usually 20% to 70% larger, depending on several factors. If you are familiar with the compiler's output, you can reduce your program's size while coding in C. One simple technique is recoding to eliminate library functions that are only called once or twice. Know the tradeoff between using compile-time constants and run-time parameters. Know the tradeoff between function-like macros (or inline functions) and callable functions. Know the size and precision requirements of the data; know which data must be signed. Thad
