On Sunday, in article
<43517dee$0$6773$9b4e6d93@newsread4.arcor-online.net>
usenet@andreas-s.net "Andreas Schwarz" wrote:
>Chris Hills schrieb:
>> In article <43515ad8$0$6777$9b4e6d93@newsread4.arcor-online.net>,
>> Andreas Schwarz <usenet@andreas-s.net> writes
>>>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.
>>
>> This is absolute rubbish. A simple function to put a character or two
>> out to a serial line will only be a few bytes long.
> >
>> As printf has to use this functionality to address the hardware, and you
>> may want to re-direct printf, it is often made available in source form
>> in the library. All you have to do is get the routine. Typically it is
>> only 4-5 lines of C.
>
>Appearantly we have a misunderstanding here. With printf I do not mean a
>put-everything-on-stdout-C89-printf. Most libraries have a printf
>variant that takes a function pointer argument for a putc function, or a
>seperate function to set the printf target. Obviously you have to write
>this one yourself.
Creating a simple putc or put_string is easy.
>The point I was trying to make is that it is useless to assemble a LCD
>output by hand (formatting numbers, concatenating strings, padding with
>spaces) when there is a function like printf that can do it all much
>easiert, but may take a bit more space.
Creating a custom printf is MUCH better than using a library function
many applications do not need
Floats
scientific of exponential notation
pointer printing
long modifiers
escape characters (form feed, line feed, bell)
Mnay only need single character or formatted strings with a byte or short
(signed/unsigned printing).
To create a custom printf is relatively easy and I have used a few, created
and expanded over time to have conditionally compilation for support required
(binary, octal, decimal, hex, pointer). Simple formatting for single
characters or strings as standard. Some of the conditional assembly for
16bit ranging from 400 bytes to 1000 bytes, depending on the target being
developed. Hence code reuse just like using a library, with known overhead.
--
Paul Carpenter | paul@pcserviceselectronics.co.uk
<http://www.pcserviceselectronics.co.uk/> PC Services
<http://www.gnuh8.org.uk/> GNU H8 & mailing list info
<http://www.badweb.org.uk/> For those web sites you hate
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
On Sun, 16 Oct 2005, Andreas Schwarz wrote:> Ian Bell schrieb: > > Andreas Schwarz wrote: > > > 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. > > > > > > So it *is* a compiler issue. > > Any hardware annoyance can be hidden by a layer of software. Still I think > it's fair to think of it as a fault of the architecture. >No you do not always need to add a LAYER of software. Most of the time it is just a case of generating code that looks horrible to YOU. On a PIC you can insert RAM page select instructions in front of all instructions if you wish *** OR *** you can analyse your code and only insert them where you NEED them. This may not be "nice" because it involves extra work for you. But if you do the job properly you end up with a VERY LOW page select overhead, much lower than if each instruction actually carried the extra bits required. The trick is to use a high level language or sophisticated assembler that will do this work for you. This is not adding a layer of software. Regards Sergio Masci http://www.xcprod.com/titan/XCSB - optimising PIC compiler FREE for personal non-commercial use .
Reply by ●October 15, 20052005-10-15
On Sat, 15 Oct 2005, Andreas Schwarz wrote:> 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. >This is simply wrong. A compiler can trace the use of a pointer throughout the code at compile time. What you need to do is add an attribute to the pointer that says "this pointer can only ever point to RAM" or "this pointer can only ever point to CODE". If you want you could call this attribute "const" and insist that all const pointers point to code and all non-const pointers point to RAM. The fundamental problem with your "transparency" assertion is that you are picking up on a particular language shortfall and translating it to the underlying architecture. Regards Sergio Masci http://www.xcprod.com/titan/XCSB - optimising PIC compiler FREE for personal non-commercial use .
Reply by ●October 15, 20052005-10-15
Ian Bell wrote:> Michael N. Moran wrote: >>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?Actually, I would say it's more of a language issue. -- 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
Andreas Schwarz wrote:> Ian Bell schrieb: > >> Michael N. Moran wrote: >>> 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.I'm not really suggesting a dynamic "RTTI like" solution, just a more complete static type model that recognizes different memory spaces. -- 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
Chris Hills wrote:> In article <uP74f.19146$Yl.14948@bignews4.bellsouth.net>, Michael N. > Moran <mike@mnmoran.org> writes > >> Ian Bell wrote: >>> 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. > > No they don't.No they don't what?> Compilers for Harvard architecture understand Harvard architecture > very well.I am referring to pure harvard architecture, (e.g. AVR) where ROM and RAM address spaces are accessed with different instructions. IOW pointers to to different address spaces are possible.> What do you mean by "most traditional compilers/languages"?For embedded use, C/C++.> For embedded use 99% of C programming uses extensions to C and most > compilers are specialised.By definition, "extensions" are not standard. -- 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
Mike Harrison wrote:> On Sat, 15 Oct 2005 09:59:35 -0400, "Michael N. Moran" <mike@mnmoran.org> wrote: >>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..?This is more than a "const" issue. For architecture such as the AVR, there are two entirely separate address spaces, each of which is accessed with different instructions. The C/C++ const qualifier only tells the compiler that a particular object may not be written (and thus may be placed in a read-only section of memory.) A function which accepts a pointer/reference to a const variable/object can also accept a pointer/reference to a non const variable/object without problem. The same semantic cannot be applied to pointers to two separate address spaces. (or something like that ;-) -- 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 16, 20052005-10-16
Microchip has a *new* architecture for the 16-bit chips like the dsPIC and PIC24, it is actually quite good. Leon
Reply by ●October 16, 20052005-10-16
Andreas Schwarz wrote:> Ian Bell schrieb: >> Andreas Schwarz wrote: >> >> >>>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. >> >> >> Not true. Library functions are immensely general purpose which largely >> accounts for their bloat and their inappropriateness in small 8 bit >> controller products. For simple printing of constant strings a user >> function is far better. > > Printf variants do a lot more than simple printing of constant strings. > Otherwise they wouldn't take a few Ks.Precisely my point - they are general purpose routines and do a whole bunch of things you don't need them too i.e. wasted space in a memory constrained product. Ian
Reply by ●October 16, 20052005-10-16
Andreas Schwarz wrote:> Ian Bell schrieb: >> Andreas Schwarz wrote: >>>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. >> >> >> So it *is* a compiler issue. > > Any hardware annoyance can be hidden by a layer of software. Still I > think it's fair to think of it as a fault of the architecture.Sounds to me like a case of the tail wagging the dog. Ian
