| Author |
Message |
Michael N. Moran
Guest
|
 Posted:
Mon Oct 17, 2005 12:15 am Post subject:
Re: Microchip Introduces First 16-bit Microcontroller Produc |
|
|
Sergio Masci wrote:
| Quote: | On Sun, 16 Oct 2005, Everett M. Greene wrote:
With regard to seperate compilation: don't make me laugh!
Yes it may have been necessary 20 years ago to compile a 10,000 line C
program as seperate 1,000 line modules because each module took 5 minutes
to compile (on a state of the art PDP/11). But today a 1,000,000 line
program takes less than 2 minutes to compile AND given that most programs
for a tiny MCU are much smaller than this, seperate compilation is not
necessary and in many cases it is actually counter productive from an
optimisation standpoint.
|
Surely you're not suggesting that it is a good practice to
have a single "compilation unit" as a general rule. And it
would be even worse to *require* such a technique.
Code is not modularized based on compilation time.
That's not even my close to my first consideration.
--
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 |
|
| Back to top |
|
 |
Andreas Schwarz
Guest
|
| Posted:
Mon Oct 17, 2005 12:15 am Post subject:
Re: Microchip Introduces First 16-bit Microcontroller Produc |
|
|
Sergio Masci schrieb:
| Quote: | Yes tools that do the job (and do it very well) do exist. You just
obviously don't know about them.
|
We were talking about AVRs and RAM/ROM. Still looking for a compiler
that can "do the job". |
|
| Back to top |
|
|
Mochuelo
Guest
|
| Posted:
Mon Oct 17, 2005 12:15 am Post subject:
Re: Microchip Introduces First 16-bit Microcontroller Produc |
|
|
On Sun, 16 Oct 2005 19:41:46 +0100, Sergio Masci
<sergio@NOSPAM.xcprod.com> wrote:
| Quote: | To claim that the underlying PIC architecture is a problem is nonsense.
It's crap compilers and assemblers that are the problem.
|
Wow.
Well, looking at your signature, I feel a little bit better, because
now I understand how come someone can write paragraphs like the one
above. |
|
| Back to top |
|
|
Ian Bell
Guest
|
| Posted:
Mon Oct 17, 2005 12:15 am Post subject:
Re: Microchip Introduces First 16-bit Microcontroller Produc |
|
|
Andreas Schwarz wrote:
| Quote: | Ian Bell schrieb:
Andreas Schwarz wrote:
Nobody uses printf for simple printing of constant strings.
There's a serious danger of going round in circles here because that's
just what the OP was doing with printf.
Where?
|
Pass.
Ian |
|
| Back to top |
|
|
Jim Granville
Guest
|
| Posted:
Mon Oct 17, 2005 12:15 am Post subject:
Re: Microchip Introduces First 16-bit Microcontroller Produc |
|
|
Andreas Schwarz wrote:
| Quote: | Ian Bell schrieb:
Andreas Schwarz wrote:
Mike Harrison schrieb:
AVR and PIC have probably about the same number of architectural
annoyances
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). See
http://wwwjobb4.iar.se/Support/?note=86174. If a compiler would want to
handle that transparently it would have to generate code to distinguish
between RAM and ROM at runtime.
This problem doesn't exist in Von Neumann machines like MSP430.
|
Some uC's use harvard designs, but 'flatten' the memory map in
hardware to make things simpler for novice C users - others have FLASH
that can
map into DATA space.
The AVR sort-of does HW-Overlay that with IO and RAM, and they COULD
have done it with CODE - but there are a couple of problems in doing that :
** if you look at the execution times, the LPM instruction is SLOWER
than the LD opcodes. (Flash is slower than RAM)
** It makes most sense on the smallest cores, (where the small library
savings might make a difference) but on the bigger cores, you cannot
reach ALL the code, so that adds complications to something that
was intended to simplify....
The AVR also has a natural opcode reach limit at 64K, so above that
you need to introduce the Page-handling for LPM and CALLs.
On their biggest parts, they do handle RET with an extra cycle/byte
Also, last time I looked, the MSP430 had poor/none external RAM handling ?
Better uC also map their EEPROM, into data space, so that allows users
to have simpler mixing of CONST and VAR strings.
Of course, it's a little more work to get the CONST String info into
the EEPROM, but I have seen this done to save valuable code space,
and simplify the libraries...
Of course, in the new ARM uC, their 32 bit indexes mean you can
map everything into one space. Code size is larger, but life is
simpler....
-jg |
|
| Back to top |
|
|
Chris Hills
Guest
|
| Posted:
Mon Oct 17, 2005 3:14 am Post subject:
Re: Microchip Introduces First 16-bit Microcontroller Produc |
|
|
In article <hpy4f.14832$MG.11071@bignews2.bellsouth.net>, Michael N.
Moran <mike@mnmoran.org> writes
| Quote: | Chris Hills wrote:
In article <2Pi4f.31903$Lp.31780@bignews5.bellsouth.net>, Michael N.
Moran <mike@mnmoran.org> writes
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.
C++ is a (rough) superset of C.
Both languages make assumptions about their execution
environment (abstract machine.)
|
In what way?
| Quote: | 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.
Just because embedded compilers *have* extensions, doesn't mean
that you are required to use those extensions.
|
It is almost impossible to write sensible programs on many MCU unless
you do use them.
| Quote: | If you do use those
extensions, it's a good idea to isolate their usage.
|
Again this is often not possible.
| Quote: | Unless of
course you're not interested in portability.
|
Very few are. There are good reasons for this.
| Quote: | Actually there are no Standard C compilers anyway.
Interesting.
|
Can you name any?
| Quote: | There *are*, however, standard language
specifications for C and C++.
|
However the are very open and undefined in some areas.
| Quote: | What I have suggested is that these languages be extended
to account for multiple separate address spaces.
|
It has been done.
| Quote: | The result would be that it becomes possible to write
portable code, given conforming compilers.
|
However there are no C99 conforming compilers.
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ chris@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ |
|
| Back to top |
|
|
Sergio Masci
Guest
|
| Posted:
Mon Oct 17, 2005 6:27 am Post subject:
Re: Microchip Introduces First 16-bit Microcontroller Produc |
|
|
On Sun, 16 Oct 2005, Chris Hills wrote:
| Quote: | In article <Pine.LNX.4.61.0510161924340.9763@yoda.srts.co.uk>, Sergio
Masci <sergio@NOSPAM.xcprod.com> writes
To claim that the underlying PIC architecture is a problem is nonsense.
It's crap compilers and assemblers that are the problem.
So why are there so many crap compilers for PIC?
|
Because the market tolerates them.
Regards
Sergio Masci
http://www.xcprod.com/titan/XCSB - optimising PIC compiler
FREE for personal non-commercial use
.. |
|
| Back to top |
|
|
Sergio Masci
Guest
|
| Posted:
Mon Oct 17, 2005 6:37 am Post subject:
Re: Microchip Introduces First 16-bit Microcontroller Produc |
|
|
On Sun, 16 Oct 2005, Michael N. Moran wrote:
| Quote: | Sergio Masci wrote:
On Sun, 16 Oct 2005, Everett M. Greene wrote:
With regard to seperate compilation: don't make me laugh!
Yes it may have been necessary 20 years ago to compile a 10,000 line C
program as seperate 1,000 line modules because each module took 5 minutes
to compile (on a state of the art PDP/11). But today a 1,000,000 line
program takes less than 2 minutes to compile AND given that most programs
for a tiny MCU are much smaller than this, seperate compilation is not
necessary and in many cases it is actually counter productive from an
optimisation standpoint.
Surely you're not suggesting that it is a good practice to
have a single "compilation unit" as a general rule. And it
would be even worse to *require* such a technique.
|
Yes and no. I am stating that it is good to have the compiler compile all
the source in one go but I am not suggesting that all the source is
presented in one file.
| Quote: |
Code is not modularized based on compilation time.
That's not even my close to my first consideration.
|
I'm not surprised given the speed of modern PCs.
Regards
Sergio Masci
http://www.xcprod.com/titan/XCSB - optimising PIC compiler
FREE for personal non-commercial use
.. |
|
| Back to top |
|
|
Sergio Masci
Guest
|
| Posted:
Mon Oct 17, 2005 6:49 am Post subject:
Re: Microchip Introduces First 16-bit Microcontroller Produc |
|
|
On Sun, 16 Oct 2005, Andreas Schwarz wrote:
| Quote: | Sergio Masci schrieb:
Yes tools that do the job (and do it very well) do exist. You just
obviously don't know about them.
We were talking about AVRs and RAM/ROM. Still looking for a compiler that can
"do the job".
|
Sorry I thought we were talking about RAM / CODE on the PICs.
Anyway it is still trivial to write an assembler that emits a machine code
instruction based on the address space of the operand. There really is no
need to have different nmeonics for instructions that handle different
address spaces.
I could probably add this functionallity to the XCASM meta assembler in
less than a day.
Regards
Sergio Masci
http://www.xcprod.com/titan/XCSB - optimising PIC compiler
FREE for personal non-commercial use
.. |
|
| Back to top |
|
|
David Brown
Guest
|
| Posted:
Mon Oct 17, 2005 8:15 am Post subject:
Re: Microchip Introduces First 16-bit Microcontroller Produc |
|
|
Michael N. Moran wrote:
| Quote: | Sergio Masci wrote:
On Sun, 16 Oct 2005, Everett M. Greene wrote:
With regard to seperate compilation: don't make me laugh!
Yes it may have been necessary 20 years ago to compile a 10,000 line C
program as seperate 1,000 line modules because each module took 5
minutes to compile (on a state of the art PDP/11). But today a
1,000,000 line program takes less than 2 minutes to compile AND given
that most programs for a tiny MCU are much smaller than this, seperate
compilation is not necessary and in many cases it is actually counter
productive from an optimisation standpoint.
Surely you're not suggesting that it is a good practice to
have a single "compilation unit" as a general rule. And it
would be even worse to *require* such a technique.
Code is not modularized based on compilation time.
That's not even my close to my first consideration.
|
I think he is suggesting that all the modules are compiled at once, not
that you only have one module. I fully agree with him in this case -
separate compilation made sense long ago, and still makes sense on large
systems, but the traditional compile-assemble-link cycle is absurd for
small microcontrollers. Compiling all the modules at once gives much
greater opportunities for optimisation - even gcc (a traditional tool if
ever there was one) now has options for program-at-once compilation, and
can then do cross-module optimisations. |
|
| Back to top |
|
|
David Brown
Guest
|
| Posted:
Mon Oct 17, 2005 8:15 am Post subject:
Re: Microchip Introduces First 16-bit Microcontroller Produc |
|
|
Sergio Masci wrote:
| Quote: | 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. |
|
| Back to top |
|
|
Michael N. Moran
Guest
|
| Posted:
Mon Oct 17, 2005 4:02 pm Post subject:
Re: Microchip Introduces First 16-bit Microcontroller Produc |
|
|
David Brown wrote:
| Quote: | I think he is suggesting that all the modules are compiled at once, not
that you only have one module. I fully agree with him in this case -
separate compilation made sense long ago, and still makes sense on large
systems, but the traditional compile-assemble-link cycle is absurd for
small microcontrollers. Compiling all the modules at once gives much
greater opportunities for optimisation - even gcc (a traditional tool if
ever there was one) now has options for program-at-once compilation, and
can then do cross-module optimisations.
|
Which is reasonable for small programs, however,
I would not think it would scale well to larger systems.
--
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 |
|
| Back to top |
|
|
Michael N. Moran
Guest
|
| Posted:
Mon Oct 17, 2005 4:15 pm Post subject:
Re: Microchip Introduces First 16-bit Microcontroller Produc |
|
|
Chris Hills wrote:
| Quote: | In article <hpy4f.14832$MG.11071@bignews2.bellsouth.net>, Michael N.
Moran <mike@mnmoran.org> writes
Both languages make assumptions about their execution environment
(abstract machine.)
In what way?
|
E.g. oth language standards assume a single address space.
| Quote: | There are no compilers you would use for embedded work that don't
have extensions to ISO C.
Just because embedded compilers *have* extensions, doesn't mean
that you are required to use those extensions.
It is almost impossible to write sensible programs on many MCU unless
you do use them.
|
While this may be true for certain MCU's, it's certainly not
true for all of them. For example the H8 series.
| Quote: | If you do use those extensions, it's a good idea to isolate their
usage.
Again this is often not possible.
|
Certainly, this can be the case for *some* MCUs, and
*any* time the feature set stretches the available resources,
all bets are off.
| Quote: | Unless of course you're not interested in portability.
Very few are. There are good reasons for this.
Certainly there are exceptions to every rule, and resource |
constrained systems are frequently full of exceptions, but
aside from that, surely portability is a consideration.
| Quote: | Actually there are no Standard C compilers anyway.
Interesting.
Can you name any?
|
Certainly GCC is attempting to be standards conforming.
Are there exceptions/non-conformances? Sure. What is
your point?
| Quote: | There *are*, however, standard language specifications for C and
C++.
However the are very open and undefined in some areas.
|
Yes, there are usages that are specified as undefined.
We usually avoid those constructs.
| Quote: | What I have suggested is that these languages be extended to
account for multiple separate address spaces.
It has been done.
|
I refer to the language standards, not to implementation
specific extensions.
| Quote: | The result would be that it becomes possible to write portable
code, given conforming compilers.
However there are no C99 conforming compilers.
|
Again, 100% tested conformance? Sure there are bugs and
implementation limitations, but certainly there are compilers
that are moving towards conformance with standards. Probably
not for all targets. Clearly, MCUs with architectures that do
not fit cleanly into the C/C++ language assumptions are supported
by fewer if any vendors.
--
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 |
|
| Back to top |
|
|
Chris Hills
Guest
|
| Posted:
Mon Oct 17, 2005 4:15 pm Post subject:
Re: Microchip Introduces First 16-bit Microcontroller Produc |
|
|
In article <yUL4f.9980$6l.512@bignews3.bellsouth.net>, Michael N. Moran
<mike@mnmoran.org> writes
| Quote: | Chris Hills wrote:
In article <hpy4f.14832$MG.11071@bignews2.bellsouth.net>, Michael N.
Moran <mike@mnmoran.org> writes
Both languages make assumptions about their execution environment
(abstract machine.)
In what way?
E.g. oth language standards assume a single address space.
|
really?
| Quote: |
There are no compilers you would use for embedded work that don't
have extensions to ISO C.
Just because embedded compilers *have* extensions, doesn't mean
that you are required to use those extensions.
It is almost impossible to write sensible programs on many MCU unless
you do use them.
While this may be true for certain MCU's, it's certainly not
true for all of them. For example the H8 series.
|
I think you will find it is true for most there are exceptions which are
in the minority.
| Quote: |
If you do use those extensions, it's a good idea to isolate their
usage.
Again this is often not possible.
Certainly, this can be the case for *some* MCUs, and
|
MOST MCU's
| Quote: | *any* time the feature set stretches the available resources,
all bets are off.
|
???
| Quote: | Unless of course you're not interested in portability.
Very few are. There are good reasons for this.
Certainly there are exceptions to every rule,
|
And you appear to be it.
| Quote: | and resource
constrained systems are frequently full of exceptions, but
aside from that, surely portability is a consideration.
|
As this is comp.arch.embedded most here will be constrained systems.
| Quote: | Actually there are no Standard C compilers anyway.
Interesting.
Can you name any?
Certainly GCC is attempting to be standards conforming.
Are there exceptions/non-conformances? Sure. What is
your point?
|
That there are no "Standard C" compilers. GCC has it's own standard.
| Quote: | There *are*, however, standard language specifications for C and
C++.
However the are very open and undefined in some areas.
Yes, there are usages that are specified as undefined.
We usually avoid those constructs.
|
Unspecified and undefined..... there are hundreds of them.
If you are avoiding all those + the language extensions your programs
must be very inefficient.
| Quote: |
What I have suggested is that these languages be extended to
account for multiple separate address spaces.
It has been done.
I refer to the language standards, not to implementation
specific extensions.
|
So was I.... The embedded extensions TR.
| Quote: | The result would be that it becomes possible to write portable
code, given conforming compilers.
However there are no C99 conforming compilers.
Again, 100% tested conformance? Sure there are bugs and
implementation limitations, but certainly there are compilers
that are moving towards conformance with standards.
|
"moving towards"? Yes and they have a LONG (or even Long long :-) way to
go. AFAIK there are only 3 or 4 which even come close to C99.
| Quote: | Probably
not for all targets.
|
Not for most at the moment.
| Quote: | Clearly, MCUs with architectures that do
not fit cleanly into the C/C++ language assumptions are supported
by fewer if any vendors.
|
No they are well supported it is just that the C standard has moved well
away from it target constituency.
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ chris@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ |
|
| Back to top |
|
|
Everett M. Greene
Guest
|
| Posted:
Mon Oct 17, 2005 6:48 pm Post subject:
Re: Microchip Introduces First 16-bit Microcontroller Produc |
|
|
Sergio Masci <sergio@NOSPAM.xcprod.com> writes:
| Quote: | On Sun, 16 Oct 2005, Everett M. Greene wrote:
Sergio Masci <sergio@NOSPAM.xcprod.com> writes:
[snip]
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.
|
The point is not the type of object to which a pointer is
pointing, it's where the pointer physically points.
| Quote: | With regard to seperate compilation: don't make me laugh!
Yes it may have been necessary 20 years ago to compile a 10,000 line C
program as seperate 1,000 line modules because each module took 5 minutes
to compile (on a state of the art PDP/11). But today a 1,000,000 line
program takes less than 2 minutes to compile AND given that most programs
for a tiny MCU are much smaller than this, seperate compilation is not
necessary and in many cases it is actually counter productive from an
optimisation standpoint.
|
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()? |
|
| Back to top |
|
|
|
|
|
|
FAQ
Memberlist
Register
Profile
Log in to check your private messages
Log in