Al,
It's a requirement of an ANSI implementation to document all
implementation defined behaviour. However, the C standard gives
implementations many degrees of freedom, not least in the types tey
support. Our compiler conforms to C90, FWIW.
Regards,
-- Paul.
Good Compiler for the MSP430
Started by ●February 13, 2004
Reply by ●March 6, 20042004-03-06
Reply by ●March 6, 20042004-03-06
Rolf,
> > Actually, there is. It is called the Freestanding Subset and is
> > enshrined in the C90 standard.
>
> The C90 is ancient, i mean C99 or newer because many
> compilers like the gcc have features of the next ANSI/ISO-C standards.
I see no benefit in C99 from a user's perspective. So many compilers
are C90 that C99 is irrelevant at the current time. Because C99 extends
the language in a bizarre way, user's wont quickly migrate to C99 if
they're at all worried about code portability because odds are that C99
isn't supported on the set of compilers they use. Hell, we still use VC
6 with all its problems because it works well for us (lots of tools and
very few bugs) and that's way behind any ISO C++ standard. Trolltech
are even more conservative because so many C++ compilers are broken they
need to use only a "working" common subset.
As I say, C99 is irrelevant at this time.
-- Paul.
> > Actually, there is. It is called the Freestanding Subset and is
> > enshrined in the C90 standard.
>
> The C90 is ancient, i mean C99 or newer because many
> compilers like the gcc have features of the next ANSI/ISO-C standards.
I see no benefit in C99 from a user's perspective. So many compilers
are C90 that C99 is irrelevant at the current time. Because C99 extends
the language in a bizarre way, user's wont quickly migrate to C99 if
they're at all worried about code portability because odds are that C99
isn't supported on the set of compilers they use. Hell, we still use VC
6 with all its problems because it works well for us (lots of tools and
very few bugs) and that's way behind any ISO C++ standard. Trolltech
are even more conservative because so many C++ compilers are broken they
need to use only a "working" common subset.
As I say, C99 is irrelevant at this time.
-- Paul.
Reply by ●March 7, 20042004-03-07
Yes some time ago when the TI kickstart was 2K (it is now 4k) the IAR
compiler was glued to TI developed FET drivers -there was mixed code
ownership between TI and IAR that formed the suite.
These days the the kickstart and the full IAR compiler have the same
solidness/weakness -as all the whole suite is coded by IAR
developers. As I remember, the kickstart still needs a seperately
downloaded floating point library though.
It's maybe worth noting that there is a 12K Baseline IAR product -
albeit more expensive than some other unlimited code size compilers.
I would definitely try out at least 3 different vendor's MSP430
compilers and support desks before buying. The last thing I want to
do (in my day job) is sell IAR compilers into situations where they
are not fit for purpose.
Jason
..IAR sales and Nixie clock builder
compiler was glued to TI developed FET drivers -there was mixed code
ownership between TI and IAR that formed the suite.
These days the the kickstart and the full IAR compiler have the same
solidness/weakness -as all the whole suite is coded by IAR
developers. As I remember, the kickstart still needs a seperately
downloaded floating point library though.
It's maybe worth noting that there is a 12K Baseline IAR product -
albeit more expensive than some other unlimited code size compilers.
I would definitely try out at least 3 different vendor's MSP430
compilers and support desks before buying. The last thing I want to
do (in my day job) is sell IAR compilers into situations where they
are not fit for purpose.
Jason
..IAR sales and Nixie clock builder
Reply by ●March 7, 20042004-03-07
>> It's maybe worth noting that there is a
12K Baseline IAR product - albeit more expensive than some other unlimited code
size compilers. <<
And also worth noting that it's 12k of *source* code, not 12k of object code!
I was caught out by this when I bought the 8k version back in the days when
there was only the IAR compiler that actually existed! Or has that rather
bizarre catch been changed now?!
And also worth noting that it's 12k of *source* code, not 12k of object code!
I was caught out by this when I bought the 8k version back in the days when
there was only the IAR compiler that actually existed! Or has that rather
bizarre catch been changed now?!
Reply by ●March 7, 20042004-03-07
I'm pretty sure it's 12K of linked code. However, there is a slight
annoyance that the Compiler listing output is disabled -this is to prevent hand
linking of a collection of compiled files totalling more than 12K.
The Strange non 2^N code size limit is quite recent -about 6 months ago is rose from 8K.
Jason
The Strange non 2^N code size limit is quite recent -about 6 months ago is rose from 8K.
Jason
Reply by ●March 7, 20042004-03-07
Paul Curtis wrote:
> Al,
>
> It's a requirement of an ANSI implementation to document all
> implementation defined behaviour. However, the C standard gives
> implementations many degrees of freedom, not least in the types tey
> support. Our compiler conforms to C90, FWIW.
>
Paul, it is this non-standard implementations of a standard that is one
of the drawbacks I see to compilers. There is a standard yes, but it
doesn't guarantee the sort of cross platform compatibility that is
touted as a C requirement. Not an argument I want to get into. I prefer
ASM anyway, but when is a standard non-standard.
As far as I am aware, from what I've read, tried and sampled here I
couldn't take code directly writtten for any of the 4 most popular
compilers here and run it unchanged on any of the other compilers. To me
that defines 'standard'
Al
> Al,
>
> It's a requirement of an ANSI implementation to document all
> implementation defined behaviour. However, the C standard gives
> implementations many degrees of freedom, not least in the types tey
> support. Our compiler conforms to C90, FWIW.
>
Paul, it is this non-standard implementations of a standard that is one
of the drawbacks I see to compilers. There is a standard yes, but it
doesn't guarantee the sort of cross platform compatibility that is
touted as a C requirement. Not an argument I want to get into. I prefer
ASM anyway, but when is a standard non-standard.
As far as I am aware, from what I've read, tried and sampled here I
couldn't take code directly writtten for any of the 4 most popular
compilers here and run it unchanged on any of the other compilers. To me
that defines 'standard'
Al
Reply by ●March 7, 20042004-03-07
At 11:32 PM 3/7/2004 +1030, you wrote:
>Paul, it is this non-standard implementations of a standard that is one
>of the drawbacks I see to compilers. There is a standard yes, but it
>doesn't guarantee the sort of cross platform compatibility that is
>touted as a C requirement. Not an argument I want to get into. I prefer
>ASM anyway, but when is a standard non-standard.
>
>As far as I am aware, from what I've read, tried and sampled here I
>couldn't take code directly writtten for any of the 4 most popular
>compilers here and run it unchanged on any of the other compilers. To me
>that defines 'standard'
Hi Al, we went thru this before, I think. First of all, lets clear the bias
- I am a C compiler vendor, I love to have everyone move to C. You are a
very experienced programmer, probably can whip out a non-trivial asm
program than most people can write the equivalent in C.
With that out of the way, yes - you can write trivial C programs that are
difficult to port, even if you don't use any of the extensions but just
hitting on the "implementation defined" areas. On the flip side, you can
also write large C programs that are trivially portable. I will again dig
up this quote from one of our customers. Sorry it is a bit longish.
However, note that he ported a non-trivial program written for x86 to AVR,
just like that:
***
Next, I wanted to know if 128K as enough program memory so I figured I
might as well jump in at the deep end and see if I could get our x86
(Turbo-C) product source to at least compile. I was thinking no way it
would run, but at least I would get an idea of how big the code was likely
to be.
First thing I did was run the Application builder again and tell it I
needed a serial port with an interrrupt handler, some I/O ports and a
system tick. I cut and pasted between the file it produced and my source files.
Next I went through and nixed all the MK_FP() macro calls and the other
stuff that contains segment/offset stuff. After an hour or so, I was ready
to hit the compile key for the first time. Now we have 27,000+ lines of
code here and some of it is pretty funky stuff: A DOS emulation with a
complete file system on a SmartMedia memory card and some pretty complex
data structures. (The modem script interpreter uses arrays of pointers to
structures containing function pointers, ints and strings, for example.)
I had made a few mistakes here and there (so he fixed them - C.W.) but on
my second attempt, I got no errors! The code size was about 50K. Slightly
less than that used by the Am188. Just for fun, I didn't really have time
to do any more with it but I clicked the IDE button to load the program
into FLASH anyway and started the terminal. I got a screenful of mostly
junk but some of it it was recognizable.
Since my printf() is rather non-standard, I unlinked it and let the linker
find the one supplied with the compiler. I loaded it again. I could not
believe my eyes. It just worked! I started testing more and more features
and every thing worked exactly as it is supposed to!
****
// richard (This email is for mailing lists. To reach me directly, please
use richard@rich...)
>Paul, it is this non-standard implementations of a standard that is one
>of the drawbacks I see to compilers. There is a standard yes, but it
>doesn't guarantee the sort of cross platform compatibility that is
>touted as a C requirement. Not an argument I want to get into. I prefer
>ASM anyway, but when is a standard non-standard.
>
>As far as I am aware, from what I've read, tried and sampled here I
>couldn't take code directly writtten for any of the 4 most popular
>compilers here and run it unchanged on any of the other compilers. To me
>that defines 'standard'
Hi Al, we went thru this before, I think. First of all, lets clear the bias
- I am a C compiler vendor, I love to have everyone move to C. You are a
very experienced programmer, probably can whip out a non-trivial asm
program than most people can write the equivalent in C.
With that out of the way, yes - you can write trivial C programs that are
difficult to port, even if you don't use any of the extensions but just
hitting on the "implementation defined" areas. On the flip side, you can
also write large C programs that are trivially portable. I will again dig
up this quote from one of our customers. Sorry it is a bit longish.
However, note that he ported a non-trivial program written for x86 to AVR,
just like that:
***
Next, I wanted to know if 128K as enough program memory so I figured I
might as well jump in at the deep end and see if I could get our x86
(Turbo-C) product source to at least compile. I was thinking no way it
would run, but at least I would get an idea of how big the code was likely
to be.
First thing I did was run the Application builder again and tell it I
needed a serial port with an interrrupt handler, some I/O ports and a
system tick. I cut and pasted between the file it produced and my source files.
Next I went through and nixed all the MK_FP() macro calls and the other
stuff that contains segment/offset stuff. After an hour or so, I was ready
to hit the compile key for the first time. Now we have 27,000+ lines of
code here and some of it is pretty funky stuff: A DOS emulation with a
complete file system on a SmartMedia memory card and some pretty complex
data structures. (The modem script interpreter uses arrays of pointers to
structures containing function pointers, ints and strings, for example.)
I had made a few mistakes here and there (so he fixed them - C.W.) but on
my second attempt, I got no errors! The code size was about 50K. Slightly
less than that used by the Am188. Just for fun, I didn't really have time
to do any more with it but I clicked the IDE button to load the program
into FLASH anyway and started the terminal. I got a screenful of mostly
junk but some of it it was recognizable.
Since my printf() is rather non-standard, I unlinked it and let the linker
find the one supplied with the compiler. I loaded it again. I could not
believe my eyes. It just worked! I started testing more and more features
and every thing worked exactly as it is supposed to!
****
// richard (This email is for mailing lists. To reach me directly, please
use richard@rich...)
Reply by ●March 8, 20042004-03-08
Hi Richard, I know you well, and the service you provide. Prior to my
accident my company used ICCAVR (selected prior to my joining ;@}). When
I took over, the code was junk, and the licences all over the place, one
late night (for you) phone call sorted out both licencing and a couple
of minor code issues. I was able to completely debug the code and get
the entire system up and running within two days, without a single
glance at the manuals. Thus I have a lot of respect both for your
product and your support. You may also remember that in the early days
of the MSP I was a loud voice tyring to convince you to adopt it. All
that to one side, and without getting into religious arguments. My
comments were actually not anti-C or anticompiler, it was more a little
anti Rolfs attitude. I felt that his expectations were based on wish
fulfillment rather than the practicalities of the existing 'standards',
particularly as he was quoting standards that do not directly apply to
embedded systems
Cheers
Al
accident my company used ICCAVR (selected prior to my joining ;@}). When
I took over, the code was junk, and the licences all over the place, one
late night (for you) phone call sorted out both licencing and a couple
of minor code issues. I was able to completely debug the code and get
the entire system up and running within two days, without a single
glance at the manuals. Thus I have a lot of respect both for your
product and your support. You may also remember that in the early days
of the MSP I was a loud voice tyring to convince you to adopt it. All
that to one side, and without getting into religious arguments. My
comments were actually not anti-C or anticompiler, it was more a little
anti Rolfs attitude. I felt that his expectations were based on wish
fulfillment rather than the practicalities of the existing 'standards',
particularly as he was quoting standards that do not directly apply to
embedded systems
Cheers
Al
Reply by ●March 8, 20042004-03-08
At 02:28 PM 3/8/2004 +1030, onestone wrote:
>Hi Richard, I know you well, and the service you provide. Prior to my
>accident my company used ICCAVR (selected prior to my joining ;@}). When
>I took over, the code was junk, and the licences all over the place, one
That is a great image! :-) Junky code and broken licenses! :-)
>late night (for you) phone call sorted out both licencing and a couple
>of minor code issues. I was able to completely debug the code and get
>the entire system up and running within two days, without a single
>glance at the manuals. Thus I have a lot of respect both for your
>product and your support. You may also remember that in the early days
Thank you!
>of the MSP I was a loud voice tyring to convince you to adopt it. All
>that to one side, and without getting into religious arguments. My
Yea, I bet you would not have imagined that 2-3 years later, there are more
compilers than can fit in a hand! :-)
>comments were actually not anti-C or anticompiler, it was more a little
>anti Rolfs attitude. I felt that his expectations were based on wish
>fulfillment rather than the practicalities of the existing 'standards',
>particularly as he was quoting standards that do not directly apply to
>embedded systems
I guess you were too subtle for me :-) Sorry. Any case, cheers!
[ Lets see, half a dozen :-)s and multiple !s. Yup, I am done with this
msg! :-) ]
// richard (This email is for mailing lists. To reach me directly, please
use richard@rich...)
>Hi Richard, I know you well, and the service you provide. Prior to my
>accident my company used ICCAVR (selected prior to my joining ;@}). When
>I took over, the code was junk, and the licences all over the place, one
That is a great image! :-) Junky code and broken licenses! :-)
>late night (for you) phone call sorted out both licencing and a couple
>of minor code issues. I was able to completely debug the code and get
>the entire system up and running within two days, without a single
>glance at the manuals. Thus I have a lot of respect both for your
>product and your support. You may also remember that in the early days
Thank you!
>of the MSP I was a loud voice tyring to convince you to adopt it. All
>that to one side, and without getting into religious arguments. My
Yea, I bet you would not have imagined that 2-3 years later, there are more
compilers than can fit in a hand! :-)
>comments were actually not anti-C or anticompiler, it was more a little
>anti Rolfs attitude. I felt that his expectations were based on wish
>fulfillment rather than the practicalities of the existing 'standards',
>particularly as he was quoting standards that do not directly apply to
>embedded systems
I guess you were too subtle for me :-) Sorry. Any case, cheers!
[ Lets see, half a dozen :-)s and multiple !s. Yup, I am done with this
msg! :-) ]
// richard (This email is for mailing lists. To reach me directly, please
use richard@rich...)
Reply by ●March 8, 20042004-03-08
Richard F. Man wrote:
> At 02:28 PM 3/8/2004 +1030, onestone wrote:
>
>>Hi Richard, I know you well, and the service you provide. Prior to my
>>accident my company used ICCAVR (selected prior to my joining ;@}). When
>>I took over, the code was junk, and the licences all over the place, one
>
>
> That is a great image! :-) Junky code and broken licenses! :-)
Junky code has nothing to do with the compilers. The 'engineer' at the
time was barely qualified as a bench tech. he'll never be an engineer or
a programmer as long as there's a hole in his bum. The real licence was
installed on 'his' computer, and he sabotaged the whole thing when he
left. We were lucky I didn't trust him, and had stayed late one evening
to make sure I had the latest copies of code and hardware. It could have
been a disaster, except for your help, Instead it was deployed within 10
days, after thorough testing. A replacement licence for the main
desktop, plus codes to allow me to run from my laptop as well, then a
couple of quick problems solved. Considering I'd never used your
compilers before, or used any compiler on an AVR, nor had I used an
ATMEGA, it was an exceptional outcome.
It still didn't ween me off asm though.
;@}
Al
> At 02:28 PM 3/8/2004 +1030, onestone wrote:
>
>>Hi Richard, I know you well, and the service you provide. Prior to my
>>accident my company used ICCAVR (selected prior to my joining ;@}). When
>>I took over, the code was junk, and the licences all over the place, one
>
>
> That is a great image! :-) Junky code and broken licenses! :-)
Junky code has nothing to do with the compilers. The 'engineer' at the
time was barely qualified as a bench tech. he'll never be an engineer or
a programmer as long as there's a hole in his bum. The real licence was
installed on 'his' computer, and he sabotaged the whole thing when he
left. We were lucky I didn't trust him, and had stayed late one evening
to make sure I had the latest copies of code and hardware. It could have
been a disaster, except for your help, Instead it was deployed within 10
days, after thorough testing. A replacement licence for the main
desktop, plus codes to allow me to run from my laptop as well, then a
couple of quick problems solved. Considering I'd never used your
compilers before, or used any compiler on an AVR, nor had I used an
ATMEGA, it was an exceptional outcome.
It still didn't ween me off asm though.
;@}
Al
