I have noticed that a number of people have asked questions 
about 'which compiler' to go for.

First thing I will say is this. Do you really need a C-compiler? 
What's wrong with Assembly?

IMO all that a C-compiler does is to act as a 'vale' obtructing the 
programmers' view hence 'better' understanding of the
microcontroller 
they are developing code for (programming).

It also forces people to come out into a public forum such as this 
one, and discuss issues that they do not necessarily need to 'share' 
with everyone else.

I have had nothing but stress from my compiler. Not because it is not 
doing what it is supposed to (not always anyhow), but because it is 
taking too much of my time in terms of effort, which I have to put in 
to understand the semantics of it (the compiler and the people behind 
it).

My conclusion is, C-compilers are an absolute waste of time, money 
and effort. 

They are like becoming addicted to some form of drugs, where you have 
to keep going back for more fixes which ony fuels the vendors 
relentless effort to make you a permanent addict to their product.

The other important thing is, that all reference notes and 
application examples (provided by chip manufacturers) are in 
Assembly, so this effectively 'forces' programmers to be at the mercy 
of C-compiler vendors when it comes to looking for 'inspiration'.



Tam.

Tam,

> The other important thing is, that all reference
notes and 
> application examples (provided by chip manufacturers) are in 
> Assembly, so this effectively 'forces' programmers to be at the
mercy 
> of C-compiler vendors when it comes to looking for 'inspiration'.

Untrue.  TI and we provide examples in C and assembly code for their
peripherals and for each family of chip.  Many of their app notes are
written using examples in C and not assembly code (SLAA149, for
example).  Assembly code happens to be popular only because TI wish to
remain vendor neurtal and it is the lowst common denominator for
examples.

-- Paul.

Tam wrote:
> I have noticed that a number of people have asked
questions 
> about 'which compiler' to go for.
> 
> First thing I will say is this. Do you really need a C-compiler? 
> What's wrong with Assembly?

Most engineers are now taught C, or so it seems. Nothing is wrong with 
assembly, it's my solder of choice (to paraphrase Steve Ciarcia).

> IMO all that a C-compiler does is to act as a
'vale' obtructing the 
> programmers' view hence 'better' understanding of the
microcontroller 
> they are developing code for (programming).

This 'veil' is precisely why many people prefer C over assembly. They 
don't want to be concerned with machine architecture. Many applications 
don't require knowledge of the underlying hardware to make them 
feasible. I personally see compilers as a potential source of third 
party errors, that will complicate de-bugging, unless you have access to 
the compiler source, and can debug the compiler bugs.

> 
> It also forces people to come out into a public forum such as this 
> one, and discuss issues that they do not necessarily need to
'share' 
> with everyone else.

I don't understand this point. the forum is for all discussing MSP430 
issues. Compilers are obviously related subjects. You could equally say 
if everyone wrote in C they wouldn't have to come here and air their 
assembler dirty laundry.

> 
> I have had nothing but stress from my compiler. 

We've noticed ;@}

> Not because it is not 
> doing what it is supposed to (not always anyhow), but because it is 
> taking too much of my time in terms of effort, which I have to put in 
> to understand the semantics of it (the compiler and the people behind 
> it).

This is another reason I don't currently use one. The much vaunted 
'portability' issue doesn't exist. It certainly doesn't
exist between 
compilers from different vendors, and often doesn't exist between 
different platforms from the same vendor.

> My conclusion is, C-compilers are an absolute
waste of time, money 
> and effort. 

Not if they are your language of choice, or area of greatest skill. In 
this day and age many clients will require you to program in C. Often 
not for any valid reason other than someone else has told them it's best.

> They are like becoming addicted to some form of
drugs, where you have 
> to keep going back for more fixes which ony fuels the vendors 
> relentless effort to make you a permanent addict to their product.

And people claim I have a warped perspective of things???

> The other important thing is, that all reference
notes and 
> application examples (provided by chip manufacturers) are in 
> Assembly.

I have C and assembler versions of most MSP430 app notes, same goes for 
most parts.

> so this effectively 'forces' programmers
to be at the mercy 
> of C-compiler vendors when it comes to looking for 'inspiration'.

You are already in dire straits if you need to refer to app notes for 
inspiration. I thought they were a quick learning tool, to allow you to 
switch to a new architecture by rapidly checking out the syntax of the 
tools and (in assembler) the instruction set, and to quickly learn how 
to handle the peripherals. Not as a source of future project material.

One very simple answer is that C comes with a load of function libraries 
included, that solve a lot of mundane problems. This should in theory 
speed up development. However the counter argument is that these are 
generic and comparatively low level functions. Most assembler 
programmers have accumulated similar, typically more complex function 
libraries over the course of their careers. None of the C compilers have 
a CIRCLE(x,y,r) function, for example, for drawing circles on graphics 
panels, whereas it is one of many functions in my graphics LCD library, 
that exists both as a macro and a callable function.

Al

At 08:24 PM 7/10/2003 +0930, onestone wrote:
>...
>This is another reason I don't currently use one. The much vaunted
>'portability' issue doesn't exist. It certainly doesn't
exist between
>compilers from different vendors, and often doesn't exist between
>different platforms from the same vendor.
>...

Actually, there are a number of non-trivial programs for the AVR: Atmel 
EIT1 has ports for IAR and ImageCraft and Ethernut for GCC and ImageCraft, 
and that they have very few #ifdef for the different compilers. The much 
vaunted portability does exist. It's not 100%, but if you are careful, you 
can get very close.

Andrew can probably comment on Salvo portability amongst the different 
compiler vendors and chips.

Or even look at things like UCOS/II the RTOS. It is huge compared to Salvo, 
and is ported to a number of chips and a number of compilers. The 
compiler/chip specific portion is relatively small.

Or high level control algorithms. e.g. PID algorithm is going to be the 
same, regardless of the chips. C gets you there much faster.

Any case, this is the last I will speak on this. Obviously I have a vested 
interest in C usage on micros, but there are valid reasons to use C besides 
that I am making money on it. Even you think assembler is more suitable, it 
is fine w/ me though so no need to go down to a X vs. Y rathole (again)....


// richard <http://www.imagecraft.com> 
<http://www.dragonsgate.net/mailman/listinfo> 

Richard F. Man wrote:

> At 08:24 PM 7/10/2003 +0930, onestone wrote:
> 
>>...
>>This is another reason I don't currently use one. The much vaunted
>>'portability' issue doesn't exist. It certainly
doesn't exist between
>>compilers from different vendors, and often doesn't exist between
>>different platforms from the same vendor.
>>...
> 
> 
> Actually, there are a number of non-trivial programs for the AVR: Atmel 
> EIT1 has ports for IAR and ImageCraft and Ethernut for GCC and ImageCraft, 
> and that they have very few #ifdef for the different compilers. The much 
> vaunted portability does exist. It's not 100%, but if you are careful,
you 
> can get very close.

"if you are careful". meaning it is not portable, and there is a 
learning curve. Don't get me wrong, the gist of my reply to Tam was not 
anti-compiler, in fact I thought it was supportive of compilers where 
they suit people. Even I'm not anti-compiler, I just haven't found one

that fits my needs yet.

> 
> Andrew can probably comment on Salvo portability amongst the different 
> compiler vendors and chips.
> 
> Or even look at things like UCOS/II the RTOS. It is huge compared to Salvo,

> and is ported to a number of chips and a number of compilers. The 
> compiler/chip specific portion is relatively small.

These are OS's not compilers, again they are "relatively small".

> 
> Or high level control algorithms. e.g. PID algorithm is going to be the 
> same, regardless of the chips. C gets you there much faster.

Not when you have an assembler version in the library. It gets you there 
MUCH faster in terms of both development and execution speed.

> 
> Any case, this is the last I will speak on this. Obviously I have a vested 
> interest in C usage on micros, but there are valid reasons to use C besides

> that I am making money on it. Even you think assembler is more suitable, it

> is fine w/ me though so no need to go down to a X vs. Y rathole (again)....

I didn't do so, I thought it fairly clear that I was contradicting Tams 
blast against compilers. I stated my personal reasons for not using one, 
but gave him a few of the reasons many people do. As far as I'm 
concerned there is no issue. For some applications assembler is more 
suitable, for others C will always be good enough. My own area of work 
tends to be in the realms where maximum performance is required, that's 
all.

Al

Andreas Schwarz wrote:

> "Tam" <embedded1@embe...> wrote:
> 
> 
>>I have noticed that a number of people have asked questions 
>>about 'which compiler' to go for.
>>
>>First thing I will say is this. Do you really need a C-compiler? 
>>What's wrong with Assembly?
> 
> 
> C is portable, for example you won't have much trouble to port a
program
> or parts of a program from AVR to MSP430.
> C allows better structured programs than assembler.

Any programmer can write clean well structured code, just as any 
programmer can write garbage code. this has nothing to do with the 
language, only the skills of the programmer.

> C programs are easier to read and understand than
assembler programs
> (when I write pseudocode to implement an algorithm, it already looks
> very much like C).

This is like saying Chinese is easier to read than English. It is if 
you're chinese. C is easy to read if you are a frequent user. Assembler 
is easy to read if you are a frequent user. If I'd never learned C it 
would look like some cryptic jumble. Have a look at the entries in the 
annual Obfuscated C competition, and tell me you can read them straight off.

> C reduces development time, because you don't
have to reinvent the wheel
> for a simple loop, function call, etc.

Not true, it is just as easy to use macros etc in assembler to achieve 
the same thing.

> C is industry standard for microcontroller
programming.

Absolute bullshit. Many compilers aren't even 100% ANSI compatible. Can 
you point me to the standard number?

>>IMO all that a C-compiler does is to act as a
'vale' obtructing the 
>>programmers' view hence 'better' understanding of the
microcontroller 
>>they are developing code for (programming).
>>
>>It also forces people to come out into a public forum such as this 
>>one, and discuss issues that they do not necessarily need to
'share' 
>>with everyone else.
> 
> 
> What is this supposed to mean?
> 
> 
>>I have had nothing but stress from my compiler. Not because it is not 
>>doing what it is supposed to (not always anyhow), but because it is 
>>taking too much of my time in terms of effort, which I have to put in 
>>to understand the semantics of it (the compiler and the people behind 
>>it).
> 
> 
> Maybe you did use the wrong compiler?
> 
> 
>>My conclusion is, C-compilers are an absolute waste of time, money 
>>and effort. 
>>
>>They are like becoming addicted to some form of drugs, where you have 
>>to keep going back for more fixes which ony fuels the vendors 
>>relentless effort to make you a permanent addict to their product.
> 
> 
> C is portable, not only between different processor architectures, but
> also between different compilers. I don't know how it is looking with
> other compilers, but it's trivial to "port" an IAR C program
to MSPGCC,
> the only difference is the Interrupt API and the (inline) assembler.
> 
> 
>>The other important thing is, that all reference notes and 
>>application examples (provided by chip manufacturers) are in 
>>Assembly, so this effectively 'forces' programmers to be at
the mercy 
>>of C-compiler vendors when it comes to looking for
'inspiration'.
> 
> 
> That's wrong. Did you never look at the TI website? It has loads of C
> examples. And btw, what do you mean by "inspiration"? If you know
the C
> language, the processor architecture, and your project, you don't need
> any "inspiration".
> 
> Sorry, but your arguments sound like you do not really know what you are
> talking about.
> 
> Andreas, user of AVR-GCC and MSPGCC

Tam has a history with the compiler vendors, but that doesn't stop him 
from being as welcome to voice his opinion as anyone else. I've voiced 
my reasons for not using compilers, but I'm very pro-compiler (for other 
people). I just get ticked off with some of the inanities spouted as 
absolute truths regarding C and assembler. A few years ago C was 
considered eveil, Pascal or Modula-2 or Smalltalk, or whatever was the 
preferred language. The reasons given were exactly those now given in 
favoiur of C.

The best tool for a job is usually what you know, what you're best at, 
what best suits an application, and often what you have readily to hand.

Al

User of anything that turns me on.

> Sorry, but your arguments sound like you do not really know what 
you are
> talking about.
> 
> Andreas, user of AVR-GCC and MSPGCC
> 
> 
> -- 
> AVR-Tutorial, er 350 Links
> Forum f AVRGCC und MSPGCC
> -> http://www.mikrocontroller.net



I have already shown (See my Poll) that we do not have to know what 
the hell we are talking about to participate here. This is not an 
Elitist group.


"There are no stupid questions"


Therefore, I welcome you in joining me in not knowing what the hell 
you know are talking about either.


Tam.

"Tam" <embedded1@embe...> wrote:

> I have noticed that a number of people have asked
questions 
> about 'which compiler' to go for.
> 
> First thing I will say is this. Do you really need a C-compiler? 
> What's wrong with Assembly?

C is portable, for example you won't have much trouble to port a program
or parts of a program from AVR to MSP430.
C allows better structured programs than assembler.
C programs are easier to read and understand than assembler programs
(when I write pseudocode to implement an algorithm, it already looks
very much like C).
C reduces development time, because you don't have to reinvent the wheel
for a simple loop, function call, etc.
C is industry standard for microcontroller programming.

> IMO all that a C-compiler does is to act as a
'vale' obtructing the 
> programmers' view hence 'better' understanding of the
microcontroller 
> they are developing code for (programming).
> 
> It also forces people to come out into a public forum such as this 
> one, and discuss issues that they do not necessarily need to
'share' 
> with everyone else.

What is this supposed to mean?

> I have had nothing but stress from my compiler.
Not because it is not 
> doing what it is supposed to (not always anyhow), but because it is 
> taking too much of my time in terms of effort, which I have to put in 
> to understand the semantics of it (the compiler and the people behind 
> it).

Maybe you did use the wrong compiler?

> My conclusion is, C-compilers are an absolute
waste of time, money 
> and effort. 
> 
> They are like becoming addicted to some form of drugs, where you have 
> to keep going back for more fixes which ony fuels the vendors 
> relentless effort to make you a permanent addict to their product.

C is portable, not only between different processor architectures, but
also between different compilers. I don't know how it is looking with
other compilers, but it's trivial to "port" an IAR C program to
MSPGCC,
the only difference is the Interrupt API and the (inline) assembler.

> The other important thing is, that all reference
notes and 
> application examples (provided by chip manufacturers) are in 
> Assembly, so this effectively 'forces' programmers to be at the
mercy 
> of C-compiler vendors when it comes to looking for 'inspiration'.

That's wrong. Did you never look at the TI website? It has loads of C
examples. And btw, what do you mean by "inspiration"? If you know the
C
language, the processor architecture, and your project, you don't need
any "inspiration".

Sorry, but your arguments sound like you do not really know what you are
talking about.

Andreas, user of AVR-GCC and MSPGCC


-- 
AVR-Tutorial, er 350 Links
Forum f AVRGCC und MSPGCC
-> http://www.mikrocontroller.net

I love this  list, me! It's lively, people post regularly, on the
whole have a 
good SOH and they aren't afraid to be controversial. When I read Tam's
e-mail 
I was waiting for holy coding war to break out! ;-) I have certain sympathies 
for what he's saying. 

To my mind the worst thing about C is the arcane and anachronistic syntax of 
the language. I  can understand why it was invented like it was in the days 
where it was imperative to have smallest size source code, but that's an 
irrelevance now. 

It's easy to write C code that is even more difficult to follow than
assembly 
language. C also has some serious deficiencies: for example the lack of 
proper bit manipulation, which  is unforgivable to a language that is really 
quite low level.

It *is* portable to *some* degree; obviously the access to the hardware is 
always going to be different and there will always be problems with certain 
compilers having quirks that are individual to that compiler. I did  a port 
from a PIC to an MSP430 once. It would have been quicker to start from 
scratch as the author of the code had used so many  weird PIC compiler 
functions. IMHO, if you write in C you should write in ANSI standard so that 
if you do have to port, it's as easy as possible. 

Also, I still don't believe, even though many compiler vendors claim 
otherwise, that C is *anything like* as efficient as assembly language. It 
never ceases to amaze me how big C programs get and conversely how small they 
are when I write them in assembly. 

--- In msp430@msp4..., "Paul Curtis" <plc@r...> wrote:
> Tam,
> 
> > The other important thing is, that all reference notes and 
> > application examples (provided by chip manufacturers) are in 
> > Assembly, so this effectively 'forces' programmers to be at
the 
mercy 
> > of C-compiler vendors when it comes to
looking for 'inspiration'.
> 
> Untrue.  TI and we provide examples in C and assembly code for their
> peripherals and for each family of chip.  Many of their app notes 
are
> written using examples in C and not assembly code
(SLAA149, for
> example).  Assembly code happens to be popular only because TI wish 
to
> remain vendor neurtal and it is the lowst common
denominator for
> examples.
> 
> -- Paul.


I can see why you reacted in this way, to my 'thoughts'. I am not 
publishing a thesis here. It is simply my opinion. Stupid or 
otherwise.
Thanks for 'jumping out' in this way, to point this out anyway, you 
looked good in doing so, I'm sure it is what is expected.

So I used the word 'all', above, and this makes my statement untrue. 
I accept that much. I guess I was generalising here, since the 
word 'manufaturers' is plural and the whole sentence was in general. 
So I stand corrected, but will stick to saying 'most' application 
notes.

I wouldn't get too excited about your (RAL's) generosity in this
"TI 
and we" c-examples issue though Paul, since what you provide with 
your toolset is 'identical examples' to TI, with the added 'use
at 
your own risk' and lots of 'copyright notices', but I will not
delve 
in that direction too far.


Thanks for your response.

Tam.