Ian Bell schrieb:> 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.Nobody uses printf for simple printing of constant strings. If you need only some of the functions like number formatting printf can already be useful, and looking for a cheaper function while the program fits in your target controller is wasted time.
Microchip Introduces First 16-bit Microcontroller Product Line - the PIC24
Started by ●October 11, 2005
Reply by ●October 16, 20052005-10-16
Reply by ●October 16, 20052005-10-16
Sergio Masci schrieb:> 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.As I said, in theory you can hide any architecture issue from the programmer with software. But if none of the compilers does this (because it would require a lot of effort or would create too much overhead), this knowledge is of little value for me.
Reply by ●October 16, 20052005-10-16
Sergio Masci wrote:> Sorry I don't get it. In what way is the ARM anything like the 6502?Apart from the fact that Acorn claimed to have started development of their own CPU due to 32-bit processors at the time lacking the latency they were used to from the 6502, the only thing that's a callback to the 6502 is the strict three letter mnemonics. It's most obvious in ORR, which obviously comes from ORA. But the architectures are otherwise too different to have much in common. -- M.I.K.e
Reply by ●October 16, 20052005-10-16
On Sun, 16 Oct 2005 02:24:21 +0100 (BST), paul$@pcserviceselectronics.co.uk (Paul Carpenter) wrote:>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).If the library sources are available, it should be easy to disable the floats etc. However, if the library sources are not available, but if the library object files have been divided intelligently, e.g. the actual printf function in printf.obj and the floating point printing routines in print_float.obj, it should be possible to create dummy_float.c containing e.g. void print_float (double d.....) { return ; } Put the dummy_float.obj on the linker command line _before_ the library files. When the linker detects the printf reference in he application program, it extracts the printf.obj from the library. Since that printf module contains a reference to print_float, the linker already knows where it is, since it has been provided by the dummy_float.obj and does not need to retrieve the print_float.obj from the library. Paul
Reply by ●October 16, 20052005-10-16
In article <43517dee$0$6773$9b4e6d93@newsread4.arcor-online.net>, Andreas Schwarz <usenet@andreas-s.net> writes>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. > >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.point taken -- \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/ /\/\/ chris@phaedsys.org www.phaedsys.org \/\/\ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Reply by ●October 16, 20052005-10-16
In article <43517eee$0$21263$9b4e6d93@newsread2.arcor-online.net>, Andreas Schwarz <usenet@andreas-s.net> writes>Chris Hills schrieb: >> In article <4350e6c3$0$21246$9b4e6d93@newsread2.arcor-online.net>, >> Andreas Schwarz <usenet@andreas-s.net> writes >> >>>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. >> >> >> printf should NOT be used for debugging at all. >> some parts only have 2-4 K of program memory. > >Some parts have only 512B of memory - so what? Of course there are >exceptions. > >> Only ametures debug with printf on 78 bit micros. > >And what do professionals use?ICE or JTAG -- \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/ /\/\/ chris@phaedsys.org www.phaedsys.org \/\/\ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Reply by ●October 16, 20052005-10-16
In article <2Pi4f.31903$Lp.31780@bignews5.bellsouth.net>, Michael N. Moran <mike@mnmoran.org> writes>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?only understand a single contiguous address space> >> 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.There are quite a few Harvard architecture MCU about. They all have compilers that handle it with no problems.> >> What do you mean by "most traditional compilers/languages"? > >For embedded use, C/C++.what do you mean by "traditional compilers/languages" There are many Harvard compilers about. C and C++ They are separate languages have know knowledge of HW architectures.> >> For embedded use 99% of C programming uses extensions to C and most >> compilers are specialised. > >By definition, "extensions" are not standard.There are no compilers you would use for embedded work that don't have extensions to ISO C. Actually there are no Standard C compilers anyway. -- \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/ /\/\/ chris@phaedsys.org www.phaedsys.org \/\/\ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Reply by ●October 16, 20052005-10-16
On 16 Oct 2005 11:33:17 GMT, in comp.arch.embedded Michael Koenig <mikenospam@email.deMUNGED> wrote:>Sergio Masci wrote: >> Sorry I don't get it. In what way is the ARM anything like the 6502? > >Apart from the fact that Acorn claimed to have started development of their >own CPU due to 32-bit processors at the time lacking the latency they were >used to from the 6502, the only thing that's a callback to the 6502 is the >strict three letter mnemonics. It's most obvious in ORR, which obviously comes >from ORA. >But the architectures are otherwise too different to have much in common.from little acorns.... Wiki is good on ARM http://en.wikipedia.org/wiki/ARM_architecture martin
Reply by ●October 16, 20052005-10-16
Sergio Masci <sergio@NOSPAM.xcprod.com> writes:> 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.Particulary not in the face of separate compilation. Even if the entire source is available, it still may not be able to determine where a pointer points (a number is a number is a number...).> 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.And if we want to get even a little more picky about it, the AVR has a third address space (I/O) which (somewhat) overlaps the RAM address space and includes the register set.> 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.
Reply by ●October 16, 20052005-10-16
paul$@pcserviceselectronics.co.uk (Paul Carpenter) wrote:>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.Some compilers can help with this. For example HI-TECH says about a feature of their upcoming "Pro" compiler series: "Automatic Generation of printf Code: The code associated with the C library function printf() has been removed from the library files. After a preliminary scan of the user's C source code, an appropriate printf routine is "written" by the compiler that will suit the function's usage, based on the placeholders used in the format string in calls to printf()." -- Dan Henry
