Well ... strings are only one part of the problem. Any constant tables/arrays, such as:
o state tables o lookup-tables o v-tables
are problematic to most traditional compilers/languages that only understand a single contiguous address space.
Well ... strings are only one part of the problem. Any constant tables/arrays, such as:
o state tables o lookup-tables o v-tables
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
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
Surely a compiler ought to be able to figure out if data is constant or not, and allocate it appropriately..?
This has been partly done on the new Embedded extensions TR.
-- \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
Mike Harrison schrieb:
and allocate it
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.
LOL, that 2-3K makes a huge difference in products with 16K ROM or less and there are very many of those.
Ian
But surely that is a *compiler* issue not a fault of the underlying architecture?
Ian
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.
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.
used with the upper
In recent parts, there
SRAM), depending on
and skip instructions.
would be better.
jitter...
league on this - you can
really want to.
assembly..?)
within the same product!)
advocates would have
..and you could add
But yes, it is better than the '70s 12 bitOpcode PIC cores. (and so it should be). Less of a difference to the newer 16 bitOpCode PICs, and behind the PIC24's.
A key indicator of a good uC, is when you would use it for a NEW design, and the new 32 bit ones, are certainly putting pressure on the larger 8 bit devices.
-jg
In article , Andreas Schwarz writes
printf should NOT be used for debugging at all. some parts only have 2-4 K of program memory.
Only ametures debug with printf on 78 bit micros.
-- \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
In article , Andreas Schwarz writes
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.
Or you could do it yourself but if writing a SIMPLE function like this "takes time, is error prone" should you be programming embedded systems at all?
It will make you code 2-3K smaller and does NOT hurt maintainability at all. IT gains you a lot as it makes the test outputting smaller and faster so it distorts the memory map less than printf and changes the time by a lot less.
-- \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
No they don't. Compilers for Harvard architecture understand Harvard architecture very well.
What do you mean by "most traditional compilers/languages"? For embedded use 99% of C programming uses extensions to C and most compilers are specialised.
-- \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
Chris Hills schrieb:
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.
Chris Hills schrieb:
Some parts have only 512B of memory - so what? Of course there are exceptions.
And what do professionals use?
Printf variants do a lot more than simple printing of constant strings. Otherwise they wouldn't take a few Ks.
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.
So it *is* a compiler issue.
Ian
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.
Ian
Creating a simple putc or put_string is easy.
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 PC Services
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.