On Thu, 10 Jul 2003 04:20:48 -0700, Richard wrote:

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

An operating system is one of the better examples of where C
excels.  The reasons stand on entirely on their own and don't
need a justification, but it's also true that C's early design
took place in the milieu of operating system development for
computers with 16 bit words and relatively small, by today's
standards, external memory (8k to 16k, not uncommonly.)  This,
at least, hints at the idea that C would probably contain many
of the kinds of features an operating system developer for small
micros today might find convenient and appropriate.  (Especially
the MSP430 perhaps, because of its apparent similarities to the
PDP-11 which was part of the impetus behind the O/S development
surrounding C's design.)

In any case, the algorithms used in an operating system (various
types of queues and process coordination, message passing, and
memory management, as examples) are rather portable as they
aren't application specific nor chip specific.  Often, little
more assembly than the stack swapping and interrupt support is
required to port one.

I'm not sure I'd hold up an operating system as _the_ equivalent
example of portability for embedded applications, in general.
It's something like selecting out the highly portable parts of
an embedded application and then asking "How portable is this?"

But it's an example at one side of a multi-faceted universe.

Jon

I totally agree with you Tam,
mostly because I couldn't understand where a bug lay if I used high level
language, it's all hidden and subtle at best.
Probably because I just plain sucked at high level though.

Dennis
----- Original Message ----- 
From: "Tam" <embedded1@embe...>
To: <msp430@msp4...>
Sent: Thursday, July 10, 2003 10:09 PM
Subject: [msp430] Assembler Vs C-Compiler


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

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

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

Do you really think this is a very strong argument? If a programmer sees
that SPI is not working although bits x and y are set, he can say it
without breaking an NDA. If he sees that an addition between double and
int produces the wrong result, he can tell it the compiler vendor. If he
posts his program to a forum and say's "hey here's my code,
please fix
it", he's got the wrong job.

> > 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 don't think so. If the software is already written with portability in
mind, it's no problem. For example, I have a AVR project with the
files sequencer.c, midi.c, uart.c, main.c and keys.c. If I would want to
port it to MSP430, I would only have to change the uart access in uart.c
and the interrupt + I/O initialization in main.c, the remaining 90% of
the code don't have to be touched.

Andreas

--- In msp430@msp4..., "Tam" <embedded1@y...> wrote:
 > First thing I will say is this. Do you really need a C-compiler? 
> What's wrong with Assembly?

From my newgroup notes:

******** BEGIN 
Message 2 in thread 
From: Wouter van Ooijen (wf@wf@....)
Subject: Re: [PIC]: Re: PIC development STINKS! 
Newsgroups: comp.arch.embedded.piclist
View this article only 
Date: 2002-08-01 07:32:19 PST 
 

> I honestly don't know whty people in general
don't like assembly.

1. It does not eliminate unused (uncalled) code
2. It does not optimize (like: inline code that is called only once)
3. It does not warn when I exceed 8 (or 9, or 2, ...) stack levels
4. It does not (automatically) hack around the stack limit
5. It does not 'share' file registers used in different pieces of code
(pseudo-stack)
6. It is slower to write (general rule: lines/hour is the sam in each
langauge, HLL typically produces a few instrutions poer line fo HLL,
so
it codes faster, even considering an asm coder would have used
somewhat
fewer instructions)
7. It is more difficult to read
8. It is more difficult get target-independence (I know, even HLL
won't
be totally target-independent)
9. It does not transparently handle coding/banking (I know: not all
HLL's do that either)
10. It is more difficult to explain to 14-year old kids
....

Wouter van Ooijen

**************

--Andrew

"grahamgollings" <lmsbv@lmsb...> wrote:

> Just to inject something. The following is two
assembly code 
> fragments, both produce identical binary code. The first one is in 
> plain vanilla assembler (from a TI app note). The second is using the 
> features of a standard Forth assembler. Notice the labels have gone 
> and the code stucture is obvious ( with the if..else..then, begin.. 
> until constructs etc). 
> This makes assembler code easier to write and less prone to errors. 
> Someone mentioned a macro assembler and I wondered if that is 
> similar ?

I've once tried to use a macro assembler for AVR called AVRTerse, which
allowed to write things like

  count = 15
  {
    count--
  } !
instead of

    ldi count, 15
  loop:
    dec count
    brne loop

(both produce the same result), but I finally ended up with plain
assembler because I couldn't get used to the limitations of AVRTerse
compared to a compiler. _If_ there's an "IF" construct, I want to
use it
with constants, registers _and_ memory vars, not just with some things
which were easy to implement.

But maybe it's not that bad if you get used to it...


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

--- In msp430@msp4..., onestone <onestone@b...> 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.

Hmmm ... the Salvo RTOS currently compiles under all of these toolsets
listed below:

Archelon / Quadravox AQ430
various gcc compilers
HI-TECH 8051C
HI-TECH PICC
HI-TECH PICC-18
HI-TECH V8C
IAR MSP430
IAR PIC18 C
ImageCraft ICC11
ImageCraft ICC430
ImageCraft ICCAVR
Keil Cx51
Metrowerks CodeWarrior (x86)
Microchip MPLAB-C18
Rowley Associates CrossStudio430
TI Code Composer (for 'C24x)
TI Code Composer Studio (for 'C28x)

The only files that are common to all Salvo distributions that contain
compiler-specific preprocessor directives are some of the header files
(salvo.h and its "extensions").

The only files in each distribution that are particular to a specific
compiler are the header file (portXyz.h) and the file containing the
context-switcher (where applicable), either in assembly or C.

All four of our currently supported MSP430 compilers use exactly the
same instructions in the context-switcher Assembly file -- just the
assembly syntax differs (very slightly). We did IAR first, and the
rest followed very quickly -- most of the work had to do with creating
projects, libraries, etc. where things differ appreciably between
vendors.

And to add to all this, the Salvo-specific parts of a Salvo MSP430
application will "cross-compile" to any of the compilers without a
single source-code change. That's why we use only a single set of
common files for all of the tutorials in our distributions. E.g. there
is only one salvo\tut\tu1\main.c, and it is completely
compiler-independent. Compiler-specific issues (usually revolving
around how registers are defined, etc.) are handled in header files
using the preprocessor.

The Salvo RTOS was originally written in Assembly for the PIC17C756.
Wow, now there's a big market! :-) We then rewrote it entirely in C
for a much wider applicability. This would have been nearly impossible
in Assembly -- at least, it would have required many, many, many more
man-hours, and would have yielded few, if any, benefits.

So not only does C provide a means of real portability across
compilers from different vendors (e.g. MSP430), and across different
platforms from the same vendor (e.g. HI-TECH, IAR, ImageCraft), but it
even provides portability across different targets and compilers (e.g.
PIC to MSP430 to AVR). 

The latter requires heavy and judicious use of the
preprocessor. Of course, as one gets deeper and deeper into the
target's hardware subsystems, cross-compiler and cross-platform
portability requires more and more use of C's preprocessor in order to
pull this off. Even Salvo has to do that, in that most of our ports
include automatic clearing of the watchdog timer, which is
hardware-dependent in those targets that do not have native
watchdog-clearing instructions.

--Andrew Kalman  aek ... at ... pumpkininc ... dot ... com

On Thu, 10 Jul 2003 22:53:07 -0000, andrew wrote:

><snip>
>******** BEGIN 
>Message 2 in thread 
>From: Wouter van Ooijen (wf@wf@....)
>Subject: Re: [PIC]: Re: PIC development STINKS! 
>Newsgroups: comp.arch.embedded.piclist
>View this article only 
>Date: 2002-08-01 07:32:19 PST 

Okay, I gather this is a repost from someone else who can't
speak for themselves here.

><snip>
>1. It does not eliminate unused (uncalled) code

Should be a linker issue.  Separate compilation for C makes this
almost certainly dumped into the lap of the linker, not the
compiler, which only sees one file module at a time.

>2. It does not optimize (like: inline code that is
called only once)

I've used assembly optimizers which are a follow-on step to
using the assembler tool.  For example, in the MIPS R2000 case.
But a C compiler provides a well-specified and narrowed
programming model (specified and inescapable stack frame usage,
for example) and often has a higher level of semantic
information, so optimization is indeed easier and more likely.

But it's not a given that assemblers don't optimize or that they
cannot.  It's just that most folks using assembly would scream
to high heaven if it did.  In cases like the MIPS, people easily
accepted the code reorganization because the branch delay slot
filling problem is one often better left to automated tools and
well accepted as such by the customers.  And there have been
data flow analysis papers written which demonstrate methods for
optimizing and packing machine code, such as on DSPs like the
Analog Device's ADSP-21xx series, which could be applied to
assembly coding (and probably C compiler output, too.)

><3...9 snipped>
>10. It is more difficult to explain to 14-year old kids

Now there's a reason for C.  :)

Jon

>> ><3...9 snipped>
>10. It is more difficult to explain to 14-year old
kids

Now there's a reason for C.  :) <<

I must say, I'm really, really glad that I learned to program embedded 
processors in assembly language rather than C. 

I learned, at the age of around 14, to program the Z80 in assembly language. I 
found it very easy, maybe because I had a good teacher, but probably more 
likely because at  that age, it's easier to take in new concepts. I
struggled 
for years to get my head round how C could work on microcontrollers and as 
often as possible programmed in assembly. 

With that in my I think it's *better* to teach a fourteen year old to
program 
in assembly language. With an uncluttered mind s/he would be able to take on 
board assembly language with ease - assuming that s/he has the right sort of 
mind to do programming.  

Whether or not C is easier to explain to a fourteen year old is open to 
debate, but with the right kind of mind, it's not at all hard to understand

it [assembly language] at that age. A mind capable of C is equally as capable 
of *any* other language. The principles of programming remain the same 
however far up the levels you go; it's all just about having a logical bent

to life. 


 

--- In msp430@msp4..., Robert Wood <robert.wood@a...> wrote:
> >> ><3...9 snipped>
> >10. It is more difficult to explain to 14-year old kids
> 
> Now there's a reason for C.  :) <<
> 
> I must say, I'm really, really glad that I learned to program
embedded 
> processors in assembly language rather than C. 
> 
> I learned, at the age of around 14, to program the Z80 in assembly
language. 
[SNIP]

I, too, learned assembly on the Z80, and on the 68HC11. 

I think that assembly-language programming is an indispensable tool,
and by teaching that first (instead of C) newcomers to the embedded
world would probably have a much better foundation for writing code,
as they would more fully appreciate the link between what you write
and what the processor does with what you write ... :-)

But the top-down trend is that kids learn HMTL and Java first, and
only assembly when they're forced to. Bummer.

--Andrew

On Fri, 11 Jul 2003 01:24:59 +0100, you wrote:

>>> ><3...9 snipped>
>>10. It is more difficult to explain to 14-year old kids
>
>Now there's a reason for C.  :) <<
>
>I must say, I'm really, really glad that I learned to program embedded 
>processors in assembly language rather than C. 

I tend to agree with this sentiment, but as usual it is really
"to each their own."

>I learned, at the age of around 14, to program the
Z80 in assembly language. I 
>found it very easy, maybe because I had a good teacher, but probably more 
>likely because at  that age, it's easier to take in new concepts. I
struggled 
>for years to get my head round how C could work on microcontrollers and as 
>often as possible programmed in assembly. 

Hehe.  I was 21 when the Z80 made its debut.

>With that in my I think it's *better* to teach
a fourteen year old to program 
>in assembly language. With an uncluttered mind s/he would be able to take on

>board assembly language with ease - assuming that s/he has the right sort of

>mind to do programming.

I tend to agree with this, too.  It's easier (much, I believe)
to teach an assembly programmer about C than it is to teach a C
programmer about assembly.  More, I think that an embedded
programmer (at least, when embedded isn't including 100's of
millions of transistors) just about cannot ignore knowing about
assembly and is able to get around problems better, knowing it
well.

But I'm sure that this is a moot issue.

>Whether or not C is easier to explain to a fourteen
year old is open to 
>debate, but with the right kind of mind, it's not at all hard to
understand 
>it [assembly language] at that age.

I didn't get exposed to programming until I was 16.  And then,
it was first with Bell Labs' Cardiac, a *very* assembly-like
paper computer.  You did all the calculations by hand and moved
the PC position around by moving a little ladybug (I think.)

After that, it was on to a variety of other assembly languages
before my first exposure to BASIC.

>A mind capable of C is equally as capable 
>of *any* other language. The principles of programming remain the same 
>however far up the levels you go; it's all just about having a logical
bent 
>to life. 

As you go up the pyramid, to greater and greater abstraction,
you have to understand less and less about how the work gets
done.  You might, for example, use an infinite precision
calculator, for example, and never know or care about details
others have to worry about.  And if that's all you've ever been
exposed to, learning how to cope closer to the ground (so to
speak) can be tough -- new concepts are needed.

In smaller embedded systems, those details can be the make or
break factor for a product.  If price, size, weight, power
consumption, features, etc. are all pressing on various sides of
your product design, you simply may not be able to afford the
sheer weight all that abstraction requires under the hood.  And
for embedded work, assembly sometimes isn't an option --
sometimes, it's necessary.  For example, a year ago I
encountered a problem reading EEPROM in a PIC18.  The bug list
came out the next month documenting a certain order which
operations must take place and pointing out that the 'read' must
take place 'on the next cycle' of a control bit change event.
This simply isn't possible to guarantee with a C compiler.  And
I could list a few other important, general areas.  But I've
done it before so I won't bother again, here.

But none of this means that C isn't a very important language to
know.  It is and it's widely used.  So select a useful range of
tools, know those tools well, and then select what makes better
sense for the application you face.

Jon