Having read all the replies to date I'm just curious. Why are you 
looking for a fight? I know Tuesdays are traditionally boring socially, 
but this smacks of desperation for entertainment.

;@]

Al

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?
> 
> 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.
> 
> 
> 
> 
> 
> 
> 
> 
> .
> 
>  
> 
> ">http://docs.yahoo.com/info/terms/ 
> 
> 
> 

Say WHAT?  Are you sure you've tried C and not Visual Basic?

On Thursday 10 July 2003 09:43 am, Robert Wood wrote:
[snip]
>  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.
[snip]

Tamer,

> 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.

The examples for the SoftBaugh & Olimex boards is code that's written
by
RAL, not TI.  A challenge would be to find that code on the TI web site.

We put our copyright notices on our own code, just like every other
compiler vendor simply to assert the origin of the source code.  The TI
examples are reproduced verbatim save for the interrupt declaration
adaptations; the authorship is clearly stated as TI's in all examples,
we have not altered this.  We have not attached copyright notices to
TI's examples, only our own.

None of the examples refer to "use at your own risk".

I find it particularly inappropriate for you accuse us of plagiarism or
of performing acts that we have not.

I simply pointed out that not all vendors and not all app notes are
written with assembly code in mind, and for TI it seems that C is their
preferred language for complex examples (TCP/IP, Replicator, whatever).
However, you seen to have twisted my response into another snide comment
about the company I work for.

-- Paul.

Once again we seem to be venturing into the realms of religious warfare.
We are talking about TOOLs, not life and death.

There are advantages to using assembler - closeness to the hardware, ability 
to
fine tune your code, absolute control over the operation of the code.

There are advantages to using C - Speed of code development, portability, 
ease
of maintenance (particularly by someone other than the original author).

I have written both.  I have written a military system running on 250 
parallel
processors in assembler.  Some of the files, even when split down to the 
smallest
viable units ran to 150kbytes.  Maintenance was a nightmare but it 
(eventually)
worked to specification.

I have written a few satellite radio modulators in assembler.  These are 
obviously
smaller but while relatively easy to write, the maintenance of this code, 
and the
modification to support new transmission formats is not easy.

I have also written a satellite data terminal in C.  some of the time 
critical stuff
is in ASM but the vast majority is in C.  The serial comms protocol is 
written in C
and the same code runs on two different processors using compilers from 
different
vendors.  On one platform unsigned char is 8 bits, on the other it is 24.

Implementing the functions in asm would have taken three times as long.  The
time saved in this alone has paid for one of the compiler toolsets.

At the end of the day everyone has their own preferences and prejudices.  
These are
as I have already said just tools.  Why some appear ready to go to war over 
their
relative merits baffles me.

Asm vs. C is an argument over whether to use a socket set or an adjustable 
spanner
to tighten a bolt.

Ian

_________________________________________________________________
Express yourself with cool emoticons - download MSN Messenger today! 
http://www.msn.co.uk/messenger

>> Say WHAT?  Are you sure you've tried C
and not Visual Basic?

On Thursday 10 July 2003 09:43 am, Robert Wood wrote:
[snip]
>  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.
[snip] <<

Sorry, which part do you not understand? The hard to read C or the proper bit 
manipulation?

If it's the hard to read C bit, just read some of my  ex boss's code.
If it's 
the lack of bit manipulation, then there's the fact that you can't
have a  
"bit" variable; you can't rotate and access the bit that's
fallen off the top 
end or bottom end of the byte; you can't just set a bit without having to
OR 
a byte, or clear without having to AND the byte. 

I've never tried Visual basic, btw. What's the point when you have
Delphi?! 
:-)

> > 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?


Mmmm. 
I t  m e a n s,  t h a t  t h o s e  w h o  h a v e  t e c h n i c a 
l  p r o b l e m s  w i t h  t h e i r  c o d e   r e s o r t  t o  h 
a v i n g   t o  d i s c l o s e  t h e i r  (p a r t s  o f) c o d 
e  (hence what they are developing or working on - usually through 
register/function  names, labels etc.)

I don't see any vendor saying, oh look everyone, the hundred 
complains we received about a bug is as a result of the 'following' 
code.... 

D i s c l o s e  t h e i r  c o d e   as  in ,  "hey look-at-my-code, 
why isn't it doing what it should be?"

This is not always desirable. It would be interesting to know how 
many firms/people actually have NDA's with their vendors.

I will put up a Poll to find out.....


> 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.
> 

Yes I accept the portability factor. But IMO it is usually easier to 
start from scratch than to try to port 'code'. 

I will put up another Poll, to find out just how often people feel 
the need to port code.

> > 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".


This is a subjective issue, so I will not argue with your views. But 
will point out that my opinions are just that, opinions. If you wish 
to enlighten me, then please be my guest....

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

See...



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

Ian Okey wrote:
> Once again we seem to be venturing into the realms
of religious warfare.
> We are talking about TOOLs, not life and death.

Life is a wrench.

> There are advantages to using assembler -
closeness to the hardware, ability 
> to
> fine tune your code, absolute control over the operation of the code.
> 
> There are advantages to using C - Speed of code development, portability, 
> ease
> of maintenance (particularly by someone other than the original author).
> 
> I have written both.  I have written a military system running on 250 
> parallel
> processors in assembler. 

Yes, but did they all march in step?

> Some of the files, even when split down to the 
> smallest
> viable units ran to 150kbytes.  Maintenance was a nightmare but it 
> (eventually)
> worked to specification.
> 
> I have written a few satellite radio modulators in assembler.  These are 
> obviously
> smaller but while relatively easy to write, the maintenance of this code, 
> and the
> modification to support new transmission formats is not easy.
> 
> I have also written a satellite data terminal in C.  some of the time 
> critical stuff
> is in ASM but the vast majority is in C.  The serial comms protocol is 
> written in C
> and the same code runs on two different processors using compilers from 
> different
> vendors.  On one platform unsigned char is 8 bits, on the other it is 24.
> 
> Implementing the functions in asm would have taken three times as long. 
The
> time saved in this alone has paid for one of the compiler toolsets.
> 
> At the end of the day everyone has their own preferences and prejudices.  
> These are
> as I have already said just tools.  Why some appear ready to go to war over

> their
> relative merits baffles me.
> 
> Asm vs. C is an argument over whether to use a socket set or an adjustable 
> spanner
> to tighten a bolt.

I vote for the sledgehammer

Al (obviously bored tonight)

	It was the second part, about bit operators.

	So... A 6502 does not have set and clear bit operations.  That's purely an

architecture specific thing.  It does have a bit test instructure, but it's

more a non-destructive AND, rather than a proper bit test.  Does that make a 
6502 worse than assembler?

	As for the argument of unreadability, that's not in the least bit valid. 
ALL 
langauges can be write-only, when written by a poor programmer.  Just because 
you can see each instructure doesn't make it any easier or more complex to 
decode than any other language.  And if you *really* want to see the 
instructions being used, then produce an assembler listing.

	I've been programming for over 20 years, and I used to think everything 
should be done in assembly.  I have hundreds of thousands of lines of 
assembly code in various projects.  I still do bare metal coding, but only 
when absolutely necessary.  I much prefer my C compilers and Forth machines.  
I prefer to write routines that I can use on the PC, the AVR, and the MSP430, 
rather than re-writing them 3 or more times.

	I now have a library that can read FAT12/FAT16/FAT32 file systems.  Shortly, 
it will be able to write.  Based on the device driver, it can handle MMC, CF, 
IDE, or virtual disks (disks as files).  I've written it all in C under 
Linux, and taken it to the MSP430 and AVR to test as needed.  It's a
helluva 
lot faster development cycle than the compiler/erase/burn/test cycle on the 
actual platforms.

	In my mind, except for absolutely as needed work, writing in assembly is 
obsolete.  Well, except for perhaps entertainment.

	--John

On Thursday 10 July 2003 10:06 am, Robert Wood wrote:
>  >> Say WHAT?  Are you sure you've tried C and not Visual Basic?
>
>  On Thursday 10 July 2003 09:43 am, Robert Wood wrote:
>  [snip]
>
>  >  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.
>
>  [snip] <<
>
>  Sorry, which part do you not understand? The hard to read C or the proper
> bit manipulation?
>
>  If it's the hard to read C bit, just read some of my  ex boss's
code. If
> it's the lack of bit manipulation, then there's the fact that you
can't
> have a "bit" variable; you can't rotate and access the bit
that's fallen
> off the top end or bottom end of the byte; you can't just set a bit
without
> having to OR a byte, or clear without having to AND the byte.
>
>  I've never tried Visual basic, btw. What's the point when you
have
> Delphi?!
>
>  :-)
>
> 
>
>
>
>
>
>
>  .
>
>
>
>  

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

[rubbish]

It seems that my first impression was right: you don't want a
discussion, you want a flamewar.

>>  So... A 6502 does not have set and clear bit operations. 
That's purely an  
architecture specific thing.  It does have a bit test instructure, but it's

more a non-destructive AND, rather than a proper bit test.  Does that make a  
6502 worse than assembler? <<

Sorry, I really don't see what that has to do with C bit operators.
I'm 
talking about C, not processors.

>> As for the argument of unreadability,
that's not in the least bit valid.  
<<

We'll have to agree to disagree then. I've seen loads of very
difficult to 
read C. Maybe you've been lucky to work with better C programmers than I 
have.