| Author |
Message |
Paul Carpenter
Guest
|
 Posted:
Mon Oct 17, 2005 7:19 pm Post subject:
Re: Microchip Introduces First 16-bit Microcontroller Produc |
|
|
On Monday, in article
<yUL4f.9980$6l.512@bignews3.bellsouth.net> mike@mnmoran.org
"Michael N. Moran" wrote:
| Quote: | Chris Hills wrote:
In article <hpy4f.14832$MG.11071@bignews2.bellsouth.net>, Michael N.
Moran <mike@mnmoran.org> writes
.....
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 would like to know WHICH compiler you use for H8 series that is ISO C
fully compliant and does not rely on an extension to define interupt
routines. This has been by #pragma and more recently by function attribute
for GCC, I ought to know about that.
I know of no standard definition for ISO C or whatever standard that
has been used across compilers to define hardware/software interupt
functions and vector tables.
| 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.
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.
|
It is almost impossible to make an embedded application *fully*
portable the bits that directly relate to the hardware, memory
map constraints, interupts and processor are target dependent.
Some parts may only be portable to systems with the same OS.
Algorithms and quite a few functions may well be portable.
| 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?
|
GCC for H8 is not standards compliant for interupts at least, as
I am not aware of any standard for defining them in C.
......
| 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.
|
Where in C99 does it specify how to define functions as interupt
routines, and if you can find it name a compiler that uses it.
--
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 |
|
| Back to top |
|
 |
Sergio Masci
Guest
|
| Posted:
Mon Oct 17, 2005 9:41 pm Post subject:
Re: Microchip Introduces First 16-bit Microcontroller Produc |
|
|
On Mon, 17 Oct 2005, David Brown wrote:
| Quote: | 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.
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.
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.
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 10:59 pm Post subject:
Re: Microchip Introduces First 16-bit Microcontroller Produc |
|
|
Jim Granville wrote:
| Quote: | Mike Harrison wrote:
On Fri, 14 Oct 2005 22:37:20 +0200, Andreas Schwarz
usenet@andreas-s.net> 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 - but compared to the evils of
the PIC architecture (banking!) this is nothing.
|
It's been a while since I've programmed Pic16 chips, but I'd choose an
AVR over the PIC's any day, especially if programming in assembler. I
prefer msp430 chips (in assembly or C) as a small micro, however - the
16-bit orthogonal single-memory-space architecture is easy to work with.
I agree with a fair number of the points below, so I'm not doing a
blow-for-blow argument. But some I definitely disagree with.
| Quote: | A few things I don't like about AVRs (mostly from an assembly point of
view)...
Highly nonorthogonal - you have to remember which instructions can
only be used with the upper
registers, and then there are a few that only work on a handful of
|
The AVR is, by small cpu standards, highly orthogonal. There are, as
you say, a few instructions that only work with some registers, but most
of those are fixed in the megas. The difference between upper and lower
registers is very annoying, but hardly difficult to remember - only
upper registers can use immediate addressing modes. More annoying are
the limited pointer registers - if the upper four pairs were all
pointers and all supported the same modes, it would be a far better chip.
| Quote: | registers. In recent parts, there
are THREE diffferent types of IO register access (high register, any
register, SRAM), depending on
the register.
|
All the registers are memory-mapped in the same address space as SRAM.
There are some registers that have shorter addressing modes - consider
them as short-cuts instead of standard memory access, rather than as a
separate IO space. When working in C, it makes no difference - the
compiler will correctly figure out if it can use the short-cut opcodes
in virtually every case.
| Quote: | Inconsistent branching methods - a mix of limited-range conditional
branches and skip instructions.
|
All cpus I've worked with have different branch ranges.
| Quote: | Maybe if they'd made STATUS a register so you could skip on carry etc.
it would be better.
|
Making STATUS a register would have been nice. More useful would be if
the stack pointer was a register pair.
| Quote: | No immediate XOR instruction.
|
It would be rarely used - you can't fit everything into an instruction set.
| Quote: | Inconsistent interrupt latency. Set up a timer interrupt and watch
that jitter...
|
Compared to other micros I've used, it's not bad.
| Quote: | No quick way to toggle an IO bit (except on some very recent parts)
|
I can't think of any reason I've ever had to toggle an IO bit. I always
know if I've turned a bit on or if I've turned it off, so I know how to
change it.
| Quote: | Power consumption sucks bigtime at 5V
Watchdog timer wake from SLEEP does a reset instead of continuing
Poor IO drive current.
Most parts can't wake up from sleep on a short pulse. History of poor
availability and obsoleting parts. Microchip are in another league on
this - you can
still buy the first mainstream PIC parts (in their original die rev)
if you really want to.
Devtools not great (how long did it take Atmel's assembler to get
conditional assembly..?)
|
Who uses Atmel's own assembler? The majority of those programming AVRs
in assembler use IAR's assembler (which is free - and downloadable from
Atmel's website) or the gnu assembler (which is obviously free in all
senses of the word). I don't think even Atmel ever recommended their
own assembler.
If you want to start complaining about AVR Studio, however, there is
plenty of scope (although it's good value for money!).
Early tools for AVR were very limited unless you wanted to spend a great
deal of money on IAR tools. But then, early tools for the PIC were no
better. I remember reading the errata and limitations list for
Microchip's PIC compiler (before they gave up on it entirely) - it was a
real laugh.
| Quote: | No standard in-circuit emulator platform across the range.
|
You don't use the same emulator for modern PICs as for older PICs
either, although admittedly Atmel seems to change faster than most
microcontroller suppliers.
| Quote: | The AVR has some great features, and I use both PICs and AVRs
(sometimes within the same product!)
depending on requirements, but it is a long way from being as perfect
as some advocates would have
you believe..!
|
Agreed.
| Quote: |
..and you could add
* No Direct memory opcodes (thus register bottleneck and pointer thrashing)
|
It's a RISC processor - everything goes through the registers. It would
be a lot better with four pointers, rather and two and a half, however.
| Quote: | * Limited SFR map
* No Boolean variables/opcodes [well, SOME new devices have a kludge on
this.. ]
* No interrupt priority
|
Very few small microcontrollers have proper interrupt priority.
| Quote: | * No register banking, so interrupt switch is clumsy/slow.
* Poor family portability
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
|
|
|
| Back to top |
|
|
Paul Carpenter
Guest
|
| Posted:
Mon Oct 17, 2005 11:05 pm Post subject:
Re: Microchip Introduces First 16-bit Microcontroller Produc |
|
|
On Monday, in article <slrndl8449.bij.usenet@jwt.xargs.com>
usenet@xargs-spam.com "John Temples" wrote:
| Quote: | On 2005-10-17, Paul Carpenter <paul$@pcserviceselectronics.co.uk> wrote:
I would like to know WHICH compiler you use for H8 series that is ISO C
fully compliant and does not rely on an extension to define interupt
routines.
Extensions do not make a compiler non-ISO-compliant, as long as those
extensions do not alter the behavior of a conforming program.
|
I do hate it when people remove TOO much context as the previous poster
said that NO extensions were needed at all. A conforming program that
uses NO extensions will NOT work on all the targets *I* have seen. By this
I mean ALL types of programmes, not just tasks added to an OS on an embedded
system.
=== Previous context ======
| 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 would like to know WHICH compiler you use for H8 series that is ISO C
fully compliant and does not rely on an extension to define interupt
routines. This has been by #pragma and more recently by function attribute
for GCC, I ought to know about that.
=== End previous context =====
--
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 |
|
| Back to top |
|
|
David Brown
Guest
|
| Posted:
Mon Oct 17, 2005 11:18 pm Post subject:
Re: Microchip Introduces First 16-bit Microcontroller Produc |
|
|
Sergio Masci wrote:
| Quote: | 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.
| Quote: | 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.
| Quote: | 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);
}
|
|
| Back to top |
|
|
Mike Harrison
Guest
|
| Posted:
Mon Oct 17, 2005 11:25 pm Post subject:
Re: Microchip Introduces First 16-bit Microcontroller Produc |
|
|
| Quote: | Inconsistent interrupt latency. Set up a timer interrupt and watch
that jitter...
Compared to other micros I've used, it's not bad.
|
But for cases where any jitter on a timer interrupt is uncceptable, 'better' is not good enough.
No jitter on a PIC.
| Quote: | You don't use the same emulator for modern PICs as for older PICs
either, although admittedly Atmel seems to change faster than most
microcontroller suppliers.
|
MPLAB-ICE2000 covers almost all the range, right back to the 16C54, the only exceptions being some
of the biggest parts and the dspic range. Adding a new processor is reasonably inexpensive
(especially with the developer discounts on devtools). |
|
| Back to top |
|
|
Ian Bell
Guest
|
| Posted:
Tue Oct 18, 2005 12:15 am Post subject:
Re: Microchip Introduces First 16-bit Microcontroller Produc |
|
|
Mike Harrison wrote:
| Quote: |
But for cases where any jitter on a timer interrupt is uncceptable,
'better' is not good enough. No jitter on a PIC.
|
I do not understand this. All micros I am familiar with sample the interrupt
at some point in an instruction cycle. If an interrupt is present the
current instruction completes and then it vectors to the ISR. No matter
what the processor, the jitter in the interrupt latency must therefore be
at least one instruction cycle time. That's not no jitter.
Ian |
|
| Back to top |
|
|
Ian Bell
Guest
|
| Posted:
Tue Oct 18, 2005 12:15 am Post subject:
Re: Microchip Introduces First 16-bit Microcontroller Produc |
|
|
Everett M. Greene wrote:
| Quote: | Sergio Masci <sergio@NOSPAM.xcprod.com> writes:
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.
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()?
|
All the more reason not to use library functions and a damn good one for not
using C at all.
Ian |
|
| Back to top |
|
|
Jim Granville
Guest
|
| Posted:
Tue Oct 18, 2005 12:15 am Post subject:
Re: Microchip Introduces First 16-bit Microcontroller Produc |
|
|
Ian Bell wrote:
| Quote: | Mike Harrison wrote:
But for cases where any jitter on a timer interrupt is uncceptable,
'better' is not good enough. No jitter on a PIC.
I do not understand this. All micros I am familiar with sample the interrupt
at some point in an instruction cycle. If an interrupt is present the
current instruction completes and then it vectors to the ISR. No matter
what the processor, the jitter in the interrupt latency must therefore be
at least one instruction cycle time. That's not no jitter.
|
There are two types of jitter, one is sampling external pins, and that
must quantize to at least the pin sample cycle time.
The other is response time, and consider a Timer interrupt, running
from the CPU clock. There is no jitter in the FLAG setting, but
the CPU may have different response times to vector.
My understanding is the PIC has a fixed vector response time ?
The 80C51 also can do this, if you interrupt from IDLE - ie you can
get zero jitter interrupts.
Most uC simply complete the current opcode, then vector.
-jg |
|
| Back to top |
|
|
Jim Granville
Guest
|
| Posted:
Tue Oct 18, 2005 12:15 am Post subject:
Re: Microchip Introduces First 16-bit Microcontroller Produc |
|
|
David Brown wrote:
<snip>
| Quote: | A few things I don't like about AVRs (mostly from an assembly point
of view)...
Highly nonorthogonal - you have to remember which instructions can
only be used with the upper
registers, and then there are a few that only work on a handful of
The AVR is, by small cpu standards, highly orthogonal. There are, as
you say, a few instructions that only work with some registers, but most
of those are fixed in the megas.
|
Can you clarify that ? Which Megas fix the immediate opcode issue ?
My AVR data shows a 4 bit opcode field,dddd, for the register in all
immediate opcodes, which is why this has a 16, and not 32
register reach.
-jg |
|
| Back to top |
|
|
John Temples
Guest
|
| Posted:
Tue Oct 18, 2005 12:15 am Post subject:
Re: Microchip Introduces First 16-bit Microcontroller Produc |
|
|
On 2005-10-17, David Brown <david@westcontrol.removethisbit.com> wrote:
| Quote: | 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.
|
How is having "const" data in flash not standards-compliant, if I can
access it, and RAM data, through a pointer-to-const?
| 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);
}
|
That code will work fine with the PIC C compiler I use, which stores
string literals in flash.
--
John W. Temples, III |
|
| Back to top |
|
|
John Temples
Guest
|
| Posted:
Tue Oct 18, 2005 12:15 am Post subject:
Re: Microchip Introduces First 16-bit Microcontroller Produc |
|
|
On 2005-10-17, Paul Carpenter <paul$@pcserviceselectronics.co.uk> wrote:
| Quote: | I would like to know WHICH compiler you use for H8 series that is ISO C
fully compliant and does not rely on an extension to define interupt
routines.
|
Extensions do not make a compiler non-ISO-compliant, as long as those
extensions do not alter the behavior of a conforming program.
--
John W. Temples, III |
|
| Back to top |
|
|
Chris Hills
Guest
|
| Posted:
Tue Oct 18, 2005 2:30 am Post subject:
Re: Microchip Introduces First 16-bit Microcontroller Produc |
|
|
In article <4353eb06$1@news.wineasy.se>, David Brown <david@westcontrol.
removethisbit.com> writes
| Quote: | 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"
|
Which standard are you referring to?
K&R
ANSI 89
ISO 90
ISO 90 + A1
ISO 99
| Quote: | Exactly where in the ANSI C standards documents
Well the ANSI document only applies in the USA |
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ chris@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ |
|
| Back to top |
|
|
Michael N. Moran
Guest
|
| Posted:
Tue Oct 18, 2005 5:55 am Post subject:
Re: Microchip Introduces First 16-bit Microcontroller Produc |
|
|
Paul Carpenter wrote:
| Quote: | On Monday, in article
yUL4f.9980$6l.512@bignews3.bellsouth.net> mike@mnmoran.org
"Michael N. Moran" wrote:
I would like to know WHICH compiler you use for H8 series that is ISO C
fully compliant and does not rely on an extension to define interupt
routines. This has been by #pragma and more recently by function attribute
for GCC, I ought to know about that.
|
Err... assembly language, possibly calling a C function?
| Quote: | I know of no standard definition for ISO C or whatever standard that
has been used across compilers to define hardware/software interupt
functions and vector tables.
|
I *never* said, nor implied that any C standard specified
interrupt handling. I simply lament the fact that the C/C++
language standards have not (yet) dealt with the issue of multiple
address spaces.
| Quote: | 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.
It is almost impossible to make an embedded application *fully*
portable the bits that directly relate to the hardware, memory
map constraints, interupts and processor are target dependent.
|
Sure. However, there are other parts that can be made
portable. The more the merrier.
| Quote: | Some parts may only be portable to systems with the same OS.
|
Sure. There are many possible levels/layers of
portability/reusability.
| Quote: | Algorithms and quite a few functions may well be portable.
|
Yep, unless they must be optimized for a particular
architecture due to resource constraints.
| Quote: | Certainly GCC is attempting to be standards conforming.
Are there exceptions/non-conformances? Sure. What is
your point?
GCC for H8 is not standards compliant for interupts at least, as
I am not aware of any standard for defining them in C.
|
Yep. Again, there are means other than C/C++ for
implementing interrupt services, and ISRs can use
proprietary extensions in a separate module isolating
their impact on the rest of the code.
--
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:
Tue Oct 18, 2005 6:26 am Post subject:
Re: Microchip Introduces First 16-bit Microcontroller Produc |
|
|
Chris Hills wrote:
| Quote: | In article <yUL4f.9980$6l.512@bignews3.bellsouth.net>, 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?
| Quote: | 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.
|
Yep.
| Quote: | Certainly, this can be the case for *some* MCUs, and
MOST MCU's
|
Certainly at the low end of the spectrum.
| 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.
|
Ouch. That sounds ... personal. As much as I might like
to think so, however, I'm probably not *that* unique ;-)
| 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.
|
Granted, given the original subject of this thread, that
this is often the case in embedded systems with varying
degrees. *Especially* when combined with the cost pressures
of high volume applications (e.g. consumer products).
However, embedded systems programming is much broader than that.
The system that I will soon begin work on has 128M of RAM, and
it ain't a PC :-)
| Quote: | 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.
|
GCC has extensions ... yes, but they have been emphasizing
standards conformance in recent years.
| Quote: | 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.
|
Of course, there is a time and place for each facet
of efficiency, as it's needed. Identify and isolate those
instances. Right?
| Quote: | I refer to the language standards, not to implementation specific
extensions.
So was I.... The embedded extensions TR.
|
From the ISO website:
ISO/IEC TR 18037:2004 deals with the following topics: extensions to
support fixed-point arithmetic, named address spaces, and basic I/O
hardware addressing.
Nice, though I haven't read this. The "named address spaces"
seems like what I am asking for.
| Quote: | 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.
|
And?
| Quote: | Probably not for all targets.
Not for most at the moment.
|
Yep.
| 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.
|
Without reading it, it seems like TR 18037 is fighting
that trend. I worry that the C/C++ languages are moving
from their systems programming roots as well.
--
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 |
|
|
|
|
|
|
FAQ
Memberlist
Register
Profile
Log in to check your private messages
Log in