Ian Bell schrieb:> Andreas Schwarz wrote: > > >>>>I disagree. The only thing I don't like about the AVR is the Harvard >>>>architecture, because it makes handling of constants and variables a bit >>>>cumbersome when you program in C >>> >>> >>>Interesting. Do you mean cumbersome in C itself or in the underlying >>>machine code created by the compiler? >> >>The problem is that you need different instructions to read from RAM and >>ROM, so you often end up with two functions that do the same thing, one >>for RAM arguments (printf), and one for ROM arguments (printf_P). > > > Right so the *real* problem is handling large constant strings. > > IMHO the last thing you should be using on an 8 bit micro is library > functions like printf.Printf was only an example, the same applies to strcmp, puts, and many more, not to mention your own functions that operate on constant arrays. And besides, I don't think there's anything wrong with using printf on 8 bit controllers. It makes serial debugging, LCD usage and things like that much more comfortable, and the additional 2-3 kB scarcely matter.
Microchip Introduces First 16-bit Microcontroller Product Line - the PIC24
Started by ●October 11, 2005
Reply by ●October 15, 20052005-10-15
Reply by ●October 15, 20052005-10-15
Ian Bell wrote:> Andreas Schwarz wrote: >>The problem is that you need different instructions to read from RAM and >>ROM, so you often end up with two functions that do the same thing, one >>for RAM arguments (printf), and one for ROM arguments (printf_P). > > Right so the *real* problem is handling large constant strings.Well ... strings are only one part of the problem. Any constant tables/arrays, such as: o state tables o lookup-tables o <shield-up> v-tables <shield-down> are problematic to most traditional compilers/languages that only understand a single contiguous address space. -- Michael N. Moran (h) 770 516 7918 5009 Old Field Ct. (c) 678 521 5460 Kennesaw, GA, USA 30144 http://mnmoran.org "So often times it happens, that we live our lives in chains and we never even know we have the key." The Eagles, "Already Gone" The Beatles were wrong: 1 & 1 & 1 is 1
Reply by ●October 15, 20052005-10-15
larwe wrote:>>>I disagree. The only thing I don't like about the AVR is the Harvard >>>architecture, because it makes handling of constants and variables a bit >>>cumbersome when you program in C >> >>Interesting. Do you mean cumbersome in C itself or in the underlying machine >>code created by the compiler? > > > It's almost invisible in C. Look at the documentation for avr-libc. > There are ROM versions of the string functions, but little else is > magic. >It's that *almost* part that bothers me ;-) I wish that the C/C++ standards bodies would use the AVR and other "pure" Harvard architecture machines as an example and standardize a set of memory space qualifiers as a part of the type system to address this issue. That ... along with other systems programming support features such as alignment (for caches, and pages). But that's another thread ... -- Michael N. Moran (h) 770 516 7918 5009 Old Field Ct. (c) 678 521 5460 Kennesaw, GA, USA 30144 http://mnmoran.org "So often times it happens, that we live our lives in chains and we never even know we have the key." The Eagles, "Already Gone" The Beatles were wrong: 1 & 1 & 1 is 1
Reply by ●October 15, 20052005-10-15
On Sat, 15 Oct 2005 09:59:35 -0400, "Michael N. Moran" <mike@mnmoran.org> wrote:>larwe wrote: >>>>I disagree. The only thing I don't like about the AVR is the Harvard >>>>architecture, because it makes handling of constants and variables a bit >>>>cumbersome when you program in C >>> >>>Interesting. Do you mean cumbersome in C itself or in the underlying machine >>>code created by the compiler? >> >> >> It's almost invisible in C. Look at the documentation for avr-libc. >> There are ROM versions of the string functions, but little else is >> magic. >> > >It's that *almost* part that bothers me ;-) > >I wish that the C/C++ standards bodies would use the AVR >and other "pure" Harvard architecture machines as an example >and standardize a set of memory space qualifiers as a part >of the type system to address this issue. > >That ... along with other systems programming support >features such as alignment (for caches, and pages). >But that's another thread ...Surely a compiler ought to be able to figure out if data is constant or not, and allocate it appropriately..?
Reply by ●October 15, 20052005-10-15
In article <AW74f.19148$Yl.12737@bignews4.bellsouth.net>, Michael N. Moran <mike@mnmoran.org> writes>larwe wrote: >>>>I disagree. The only thing I don't like about the AVR is the Harvard >>>>architecture, because it makes handling of constants and variables a bit >>>>cumbersome when you program in C >>> >>>Interesting. Do you mean cumbersome in C itself or in the underlying machine >>>code created by the compiler? >> >> >> It's almost invisible in C. Look at the documentation for avr-libc. >> There are ROM versions of the string functions, but little else is >> magic. >> > >It's that *almost* part that bothers me ;-) > >I wish that the C/C++ standards bodies would use the AVR >and other "pure" Harvard architecture machines as an example >and standardize a set of memory space qualifiers as a part >of the type system to address this issue.This has been partly done on the new Embedded extensions TR. -- \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/ /\/\/ chris@phaedsys.org www.phaedsys.org \/\/\ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Reply by ●October 15, 20052005-10-15
Mike Harrison schrieb:> On Sat, 15 Oct 2005 09:59:35 -0400, "Michael N. Moran" <mike@mnmoran.org> wrote: > > >>larwe wrote: >> >>>>>I disagree. The only thing I don't like about the AVR is the Harvard >>>>>architecture, because it makes handling of constants and variables a bit >>>>>cumbersome when you program in C >>>> >>>>Interesting. Do you mean cumbersome in C itself or in the underlying machine >>>>code created by the compiler? >>> >>> >>>It's almost invisible in C. Look at the documentation for avr-libc. >>>There are ROM versions of the string functions, but little else is >>>magic. >>> >> >>It's that *almost* part that bothers me ;-) >> >>I wish that the C/C++ standards bodies would use the AVR >>and other "pure" Harvard architecture machines as an example >>and standardize a set of memory space qualifiers as a part >>of the type system to address this issue. >> >>That ... along with other systems programming support >>features such as alignment (for caches, and pages). >>But that's another thread ... > > > Surely a compiler ought to be able to figure out if data is constant or not, and allocate it > appropriately..?The problem is not allocation, but access to variables: void function (int *something) { return (*something == 1); } function(ROM_address); function(RAM_address); To make this work, the compiler would have to generate code that can tell a ROM address from a RAM address at runtime.
Reply by ●October 15, 20052005-10-15
Andreas Schwarz wrote:> > Printf was only an example, the same applies to strcmp, puts, and many > more, not to mention your own functions that operate on constant arrays. > And besides, I don't think there's anything wrong with using printf on 8 > bit controllers. It makes serial debugging, LCD usage and things like > that much more comfortable, and the additional 2-3 kB scarcely matter.LOL, that 2-3K makes a huge difference in products with 16K ROM or less and there are very many of those. Ian
Reply by ●October 15, 20052005-10-15
Michael N. Moran wrote:> Ian Bell wrote: >> Andreas Schwarz wrote: >>>The problem is that you need different instructions to read from RAM and >>>ROM, so you often end up with two functions that do the same thing, one >>>for RAM arguments (printf), and one for ROM arguments (printf_P). >> >> Right so the *real* problem is handling large constant strings. > > Well ... strings are only one part of the problem. > Any constant tables/arrays, such as: > > o state tables > o lookup-tables > o <shield-up> v-tables <shield-down> > > are problematic to most traditional compilers/languages that > only understand a single contiguous address space. > >But surely that is a *compiler* issue not a fault of the underlying architecture? Ian
Reply by ●October 15, 20052005-10-15
Ian Bell schrieb:> Andreas Schwarz wrote: > > > >>Printf was only an example, the same applies to strcmp, puts, and many >>more, not to mention your own functions that operate on constant arrays. >>And besides, I don't think there's anything wrong with using printf on 8 >>bit controllers. It makes serial debugging, LCD usage and things like >>that much more comfortable, and the additional 2-3 kB scarcely matter. > > > LOL, that 2-3K makes a huge difference in products with 16K ROM or less and > there are very many of those.Optimization (writing a specialized function instead of using one from the library is nothing but optimization) is done when necessary, and no sooner. If your program with printf & Co. is 14k large and you target a 16k microcontroller, replacing standard functions with specialized code will gain you absolutely nothing, but takes time, is error-prone, makes your code larger and hurts maintainability.
Reply by ●October 15, 20052005-10-15
Ian Bell schrieb:> Michael N. Moran wrote: > > >>Ian Bell wrote: >> >>>Andreas Schwarz wrote: >>> >>>>The problem is that you need different instructions to read from RAM and >>>>ROM, so you often end up with two functions that do the same thing, one >>>>for RAM arguments (printf), and one for ROM arguments (printf_P). >>> >>>Right so the *real* problem is handling large constant strings. >> >>Well ... strings are only one part of the problem. >>Any constant tables/arrays, such as: >> >>o state tables >>o lookup-tables >>o <shield-up> v-tables <shield-down> >> >>are problematic to most traditional compilers/languages that >>only understand a single contiguous address space. >> >> > > > But surely that is a *compiler* issue not a fault of the underlying > architecture?No. To achive true transparency, the compiler would have to generate code that can tell a ROM address from a RAM address at runtime. Otherwise functions that take pointer arguments would not be possible.
