| Author |
Message |
Everett M. Greene
Guest
|
 Posted:
Wed Oct 19, 2005 4:26 pm Post subject:
Re: Microchip Introduces First 16-bit Microcontroller Produc |
|
|
Ian Bell <ruffrecords@yahoo.com> writes:
| Quote: | R Adsett wrote:
ruffrecords@yahoo.com says...
Everett M. Greene wrote:
You're going to recompile all the libraries with every job?!?
[Maybe this is a good idea. Bye, bye linker.]
You find some calls to strcpy() that reference ROM for the
second argument and some that reference RAM. You're going
to have function overloading in C and produce two versions
of strcpy()?
All the more reason not to use library functions and a damn
good one for not using C at all.
I don't follow your logic here Ian. If you can have strings in ROM and
RAM and allow copy from either ROM or RAM how are you going to do it
without either a qualified pointer that distinguishes between the two
possible sources or a separate routine for each case (or the moral
equivalent thereof)regardless of the language?
I agree and therefore standard library functions will not suffice. Hence my
first assertion. As the specifics are micro specific I contend they are
best written in assembler; hence my second assertion.
|
Just to muddy the water a bit more, I'm currently doing some work
for a processor having two disjoint RAM spaces. I'm certainly
glad I don't have to work out the details of making the C compiler
for it generate the correct code. |
|
| Back to top |
|
 |
Sergio Masci
Guest
|
| Posted:
Thu Oct 20, 2005 2:51 pm Post subject:
Re: Microchip Introduces First 16-bit Microcontroller Produc |
|
|
On Mon, 17 Oct 2005, David Brown wrote:
| Quote: | Sergio Masci wrote:
On Mon, 17 Oct 2005, David Brown wrote:
Sergio Masci wrote:
On Sun, 16 Oct 2005, Everett M. Greene wrote:
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...).
where a pointer points to is not the issue, what a pointer is
pointing to
is.
Consider a pointer to a "char". No mater where the pointer is
pointing
the compiler knows it is pointing to a "char". Regardless of how
you
manipulate the pointer the compiler will always derefernce it as a
char
pointer. You can play hide and seek and force a non char pointer
into it
but that is not the point. Here "char" is an attribute of the
pointer and
the attribute is tracked throughout the use of the pointer at
compile
time NOT runtime. Another attribute could easily be the address
space
(RAM, CODE, I/O etc). The actual runtime contents is not
important, the
compile time attribute is.
A char* pointer does not necessarily always point to a char. Like it
or not,
C code (both libraries and user-written code, and not just bad code
either) is
full of code that messes around with pointers and what they point to.
In
particular, char* and void* are used to point to any old bit of
memory. And
it is perfectly legal to add a "const" qualifier (though not to remove
one),
so it cannot be used to mean "in flash" without breaking from ANSI
standards.
C specifically requires one single memory space - any method of
supporting
different memory spaces requires either proprietary extensions (such
as IAR),
standard-breaking shortcuts (such as using "const" to mean "in flash",
as used
by ImageCraft - convenient and natural, but still not "C"), or ugly
macros
(avr-gcc). You can, however, get very close to perfect by compiling
the
entire program at once and having the compiler figure out what goes in
each
memory space - then your only problem is with code that is sometimes
called
with a ram pointer, and sometimes with a flash pointer.
Hi David,
I'm afraid you're missing the point. What you are talking about is the
run time value of a pointer. What I am talking about is the compile time
attributes of a pointer.
You can stuff an invalid value into a pointer at run time but at compile
time the compiler knows that pointer by its attributes. If you decalre a
pointer to char and then stuff a pointer to func in it the compiler will
(or should) complain. Yes you can coerce the compiler into doing your
bidding but then you also take responsibility for the correct use of the
pointer thereafter - you can't blame the compiler for generating invalid
code.
You can mess around with pointers to a great extent in C - and if the compiler
is following the ANSI standard, it must allow most of these coercions. Like
it or not, you cannot call a compiler "standard" if it is not possible to
(say) convert a "char*" to a "const char*", and you *are* free to blame the
compiler if it generates invalid code. In particular, it is not uncommon to
want functions that will handle a string or a block of memory through a
pointer, and the data pointed to may be either "const" or not. The only
standards-compliant general solution (on Harvard architectures) is for the
"const" data to go in ram. Note that I don't think that slavishly following
the standard is necessarily a good thing here. And if your compiler can
figure out, at least for the majority of cases, whether pointers and data
should be "flash" or "ram", then that is excellent.
Also, by talking explicitly about specific 'C' compiler implementations
we are getting side tracked from the issue which is that IT IS POSSIBLE
for a compiler to track the use of a pointer and if you give the pointer
a dedicated address space attribute, it is possible for *** A ***
compiler
to generate good efficient runtime code without the "decode at runtime"
overhead. Think back to the 8086 'C' compilers that allowed "near"
addressing modes for segmented pointers.
Exactly where in the ANSI C standards documents is the "near" pointer
qualifier described? It is a proprietary extension to C to help generate more
efficient code. It is non-standard. Again, this is not a bad thing here - I
am just saying that the C standard allows for certain types of pointer
manipulation (some of which are actually useful) that conflict with attempts
of separating memory spaces, and that any way of getting round this is
necessarily a compromise.
My XCSB compiler generates efficient executables for the PIC despite the
fact that it allows pointers to RAM and CODE sapce and this is because it
does track pointer use.
I think that is the best way to handle the problem, in general. But how do
you deal with a function such as:
void sendString(const char* p);
char buffer[16];
void test(void) {
sendString(buffer);
sendString("Testing);
}
|
Hi David,
This thread started out talking about how crap the PIC architecture is and
I have been trying to point out that it is not as crap as many people
would have "you" belive. Along the way the thread strayed into HLL (and
'C') space and now we seem to be fully entrenched in what is valid
standards complient 'C'.
Regardless of whether or not it is possible to trace the use of a RAM and
CODE space pointer in a standards complient 'C', the fact still remains
that with minor extensions IT IS POSSIBLE to do so.
I am really concerned that people with a limitted understanding of what it
is possible to do with a HLL base their critisisms of the PIC on what is
effectively a very old language developed for a mini computer with less
processing power than a modern PDA.
It is possible and practical for a modern HLL to do things that 'C'
cannot. We should be looking forward to what we can do with software not
holding ourselves back because the current software is limitted.
One of the reasons I chose to write a compiler other than a 'C' compiler
was to be able to freely take advantage of what can be done instead of
being tied to what others have been lead to expect.
| Quote: | But how do you deal with a function such as:
void sendString(const char* p);
char buffer[16];
void test(void) {
sendString(buffer);
sendString("Testing);
}
|
XCSB deals with this by allowing overloaded functions. I would effectively
have:
void sendString(const char* p);
void sendString(char* p);
In the future I will probably have a mechanism for automatically
generating different versions of a function to deal with both cases. Such
a mechanism is already in place to handle task safe functions
(multitasking is handled natively and not as a bolton library within
XCSB).
Regards
Sergio Masci
http://www.xcprod.com/titan/XCSB - optimising PIC compiler
FREE for personal non-commercial use
.. |
|
| Back to top |
|
|
Ian Bell
Guest
|
| Posted:
Thu Oct 20, 2005 4:15 pm Post subject:
Re: Microchip Introduces First 16-bit Microcontroller Produc |
|
|
Sergio Masci wrote:
bloody enormous SNIP
| Quote: | Hi David,
This thread started out talking about how crap the PIC architecture is and
I have been trying to point out that it is not as crap as many people
would have "you" belive.
|
Let's hope it is not as crap as your netiquette. Please trim quotes. Your
last post was 258 lines long.
Ian |
|
| Back to top |
|
|
Sergio Masci
Guest
|
| Posted:
Thu Oct 20, 2005 4:15 pm Post subject:
Re: Microchip Introduces First 16-bit Microcontroller Produc |
|
|
On Thu, 20 Oct 2005, Ian Bell wrote:
<snip>
I do not post just for your benefit.
Many people actually prefer to be able read through a single post without
having to jump around between posts to understand what is being refered
to.
When I do post something just for you I shall be sure to remove as much
useless clutter from it as possible.
Regards
Sergio Masci
http://www.xcprod.com/titan/XCSB - optimising PIC compiler
FREE for personal non-commercial use
.. |
|
| Back to top |
|
|
Tom Twist
Guest
|
| Posted:
Thu Oct 20, 2005 4:15 pm Post subject:
Re: Microchip Introduces First 16-bit Microcontroller Produc |
|
|
On Thu, 20 Oct 2005 13:13:22 +0100, Sergio Masci
<sergio@NOSPAM.xcprod.com> wrote:
| Quote: |
On Thu, 20 Oct 2005, Ian Bell wrote:
snip
Ian
I do not post just for your benefit.
Many people actually prefer to be able read through a single post without
having to jump around between posts to understand what is being refered
to.
When I do post something just for you I shall be sure to remove as much
useless clutter from it as possible.
|
Sergio
Why don't you put all previous posts on your web site, so that the
0.1% of people unable to follow a normal usenet thread can access them
there? Or they can use some search tools.
One doesn't have to delete a post after reading it.
The rest of us prefer to have all unnecessary stuff removed from a
followup.
Tom |
|
| Back to top |
|
|
Grant Edwards
Guest
|
| Posted:
Thu Oct 20, 2005 4:15 pm Post subject:
Re: Microchip Introduces First 16-bit Microcontroller Produc |
|
|
On 2005-10-20, Sergio Masci <sergio@NOSPAM.xcprod.com> wrote:
| Quote: |
On Thu, 20 Oct 2005, Ian Bell wrote:
snip
Ian
I do not post just for your benefit.
|
Most of us agree with Ian. Trim posts is good.
| Quote: | Many people actually prefer to be able read through a single
post without having to jump around between posts to understand
what is being refered to.
|
I'm sure sufficient context can be maintined without quoting
the entire thread.
| Quote: | When I do post something just for you I shall be sure to
remove as much useless clutter from it as possible.
|
Please do the same for me. :)
--
Grant Edwards grante Yow! This is PLEASANT!
at
visi.com |
|
| Back to top |
|
|
Ian Bell
Guest
|
| Posted:
Thu Oct 20, 2005 4:15 pm Post subject:
Re: Microchip Introduces First 16-bit Microcontroller Produc |
|
|
Sergio Masci wrote:
| Quote: | I do not post just for your benefit.
|
Well, I certainly don't feel like I gain any benefit from your posts, but
that is no excuse for bad manners.
Ian |
|
| Back to top |
|
|
A.P. Richelieu
Guest
|
| Posted:
Fri Oct 21, 2005 11:07 pm Post subject:
Re: Microchip Introduces First 16-bit Microcontroller Produc |
|
|
"Andreas Schwarz" <usenet@andreas-s.net> skrev i meddelandet
news:43515ad8$0$6777$9b4e6d93@newsread4.arcor-online.net...
| Quote: | Ian Bell schrieb:
Andreas Schwarz wrote:
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.
|
Currently implementing "optimized" printf for a 4kB ATmega48 controller.
Sure make a difference in price compared to the 8kB ATmega88...
--
Best Regards,
Ulf Samuelsson
This is intended to be my personal opinion which may,
or may bot be shared by my employer Atmel Nordic AB |
|
| Back to top |
|
|
A.P. Richelieu
Guest
|
| Posted:
Fri Oct 21, 2005 11:07 pm Post subject:
Re: Microchip Introduces First 16-bit Microcontroller Produc |
|
|
| Quote: |
I agree as well, the PIC is quote good when taking into account that
it is a mid 70's design, but the AVR is a 90's design, and when
working with it, it soon is obvious that in terms of developer
friendlyness it wins hands down.
The only thing that makes the PIC halfway usable are the vast number
of app notes and other support documents microchip provides.
The harvard architecture is actually not such a problem when using the
imagcraft C compiler. When declaring global variables "const", they
are put in flash and the LPM instruction are automatically used to
access these variables. I am not aware of an AVR compiler that
supports "generic" pointers, hence when using pointers the programmer
still needs to keep track of whether the data is in code or data
space.
|
IAR Embedded workbench can support generic pointers.
--
Best Regards,
Ulf Samuelsson
This is intended to be my personal opinion which may,
or may bot be shared by my employer Atmel Nordic AB |
|
| Back to top |
|
|
David Brown
Guest
|
| Posted:
Mon Oct 24, 2005 8:15 am Post subject:
Re: Microchip Introduces First 16-bit Microcontroller Produc |
|
|
Sergio Masci wrote:
<snip>
| Quote: |
Hi David,
This thread started out talking about how crap the PIC architecture is and
I have been trying to point out that it is not as crap as many people
would have "you" belive. Along the way the thread strayed into HLL (and
'C') space and now we seem to be fully entrenched in what is valid
standards complient 'C'.
|
The PIC (the old PIC16 at least - I don't know newer ones) architecture
*is* crap. What you have managed to do (and I highly commend for it) is
write a compiler that makes this crap run well. If you wrote a similar
compiler for a half-decent architecture like the avr, or a decent one
like the msp430, you'd get even better results.
| Quote: | Regardless of whether or not it is possible to trace the use of a RAM and
CODE space pointer in a standards complient 'C', the fact still remains
that with minor extensions IT IS POSSIBLE to do so.
|
I think we agree that extensions or changes to C for use in embedded
systems are a necessary thing, and can often be a good thing even when
strictly-speaking unnecessary. But if you have made extensions (like
adding "flash" or "near" keywords) or semantic changes (like changing
the meaning of "const"), it is no longer standard C. I stress that I
don't see that as a bad thing (within reason).
| Quote: | I am really concerned that people with a limitted understanding of what it
is possible to do with a HLL base their critisisms of the PIC on what is
effectively a very old language developed for a mini computer with less
processing power than a modern PDA.
It is possible and practical for a modern HLL to do things that 'C'
cannot. We should be looking forward to what we can do with software not
holding ourselves back because the current software is limitted.
|
I fully agree here - C is a terrible language for small embedded systems
(or big embedded systems, or non-embedded systems for that matter). It
should be possible to design an HLL that works far better in every way,
be it for a PIC or any other micro. However, pretty much any reasonable
HLL will work better on better architectures - the PIC will still be
poor in comparison to others.
| Quote: | One of the reasons I chose to write a compiler other than a 'C' compiler
was to be able to freely take advantage of what can be done instead of
being tied to what others have been lead to expect.
|
I'm slightly confused here - your compiler is *not* a C compiler? I
thought what you had written was a very smart C compiler. If what you
have is not a "C compiler" as such, but a "modified C" or a "C with some
bits of C++" compiler (guessing from your overloaded function), then
that's fair enough. It's likely to be a good solution - just as long as
you don't call it standard C.
mvh.,
David |
|
| Back to top |
|
|
Mark L Pappin
Guest
|
| Posted:
Mon Nov 28, 2005 5:15 pm Post subject:
Re: Microchip Introduces First 16-bit Microcontroller Produc |
|
|
"Michael N. Moran" <mike@mnmoran.org> writes:
| Quote: | Chris Hills wrote:
Michael N. Moran
E.g. oth language standards assume a single address space.
really?
OK. Please explain to me how one *without going outside of
the C/C++ language standard* declare an "unsigned char" for
the AVR that lives in the AVR ROM space and another that
lives in the AVR RAM space?
|
unsigned char lives_in_RAM = 'a';
const unsigned char lives_in_ROM = 'b';
works for all the HI-TECH C compilers I have installed at work, for
Harvard or von Neumann architectures. As several people have
mentioned (but not in detail), they allocate constant objects to
addresses in ROM that are outside the range of valid addresses in RAM,
so can be distinguished at runtime.
mlp
(Disclosure of Interest: employed by, but not speaking for, HI-TECH;
just pointing out a mechanism that can be and is used.) |
|
| Back to top |
|
|
Paul Burke
Guest
|
| Posted:
Mon Nov 28, 2005 5:15 pm Post subject:
Re: Microchip Introduces First 16-bit Microcontroller Produc |
|
|
Mark L Pappin wrote:
| Quote: | "Michael N. Moran" <mike@mnmoran.org> writes:
OK. Please explain to me how one *without going outside of
the C/C++ language standard* declare an "unsigned char" for
the AVR that lives in the AVR ROM space and another that
lives in the AVR RAM space?
unsigned char lives_in_RAM = 'a';
const unsigned char lives_in_ROM = 'b';
|
This really is one of the major problems of C. The construct above
doesn't work with, for example, the Raisonance 8051 compiler, where even
if you declare a const, it still assumes it's in the internal RAM unless
you precede it with "code".
This kind of thing makes porting code a bugger, even a debugger, and
it's time the industry got together to work out a standard. While you're
at it, define a portable way of allocating objects to specified locations.
Paul Burke |
|
| Back to top |
|
|
Hans-Bernhard Broeker
Guest
|
| Posted:
Mon Nov 28, 2005 5:15 pm Post subject:
Re: Microchip Introduces First 16-bit Microcontroller Produc |
|
|
Paul Burke <paul@scazon.com> wrote:
| Quote: | Mark L Pappin wrote:
unsigned char lives_in_RAM = 'a';
const unsigned char lives_in_ROM = 'b';
This really is one of the major problems of C.
|
No. If it's a problem, then it's one of the C compiler in question.
If you declare an object 'const', in C, a compiler for a target system
that has ROM space available has all the liberty needed to put it in
ROM. If the tools don't do so, that's not the fault of the language,
but a quality issue with the tools, or possibly a usage error (not
turning on the relevant compiler/linker option).
C doesn't provide a mechanism for portable programs to force the
translator to put objects to be in non-writable storage. But that's
not a problem, that's a designed-in feature of the language. Such
programs would be gratuitously unportable.
--
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain. |
|
| Back to top |
|
|
|
|
|
|
FAQ
Memberlist
Register
Profile
Log in to check your private messages
Log in