J.C. Wren wrote:

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

A 6502 is a microprocessor, most don't have bit manipulation 
instructions. These are generally the realm of microcontrollers. C was 
developed for microprocessor based machines, ie data processors. It 
would be interesting to develop a C-like language that was optimised for 
microcontroller/real world interfacing applications, I'm sure that a lot 
of the speed and code size disparities that exist between C and 
assembler code is related to this. However I doubt that this would be 
practical, given the wide disparities between different microcontroller 
families, even in the area of bit manipulation instructions. For example 
the MSP430 offers a multi-bit operation, whereas the PIC offers  only 
single bit.

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

Aye! there's the rub.

Al

--- In msp430@msp4..., "Paul Curtis" <plc@r...> wrote:
> 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.  


And the FET examples???



A challenge would be to find that code on the TI web site.


Can't be bothered, because I never claimed what you are saying.


> We put our copyright notices on our own code, just
like every other
> compiler vendor simply to assert the origin of the source code.  


I didn't claim that you put those notices for any other reason.


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


I never claimed you did.


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

The following 'partial' file says you are wrong on this occasion! it 
is not an example, but a 'run-time' item. I don't know how
different 
that is?!



// Rowley C Compiler, runtime support.
//
// Copyright (c) 2001, 2002 Rowley Associates Limited.
//
// This file may be distributed under the terms of the License 
Agreement
// provided with this software.
//
// THIS FILE IS PROVIDED AS IS WITH NO WARRANTY OF ANY KIND, 
INCLUDING THE
// WARRANTY OF DESIGN, MERCHANTABILITY AND FITNESS FOR A PARTICULAR 
PURPOSE.

#ifndef 



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


I didn't accuse you of anything.

I'm not even going to bother 'getting back' you need to grow up 
some....


But I will say this paul. It is on record here at this forum that I 
am 'for' members representing vendors to sign off their messages with 
their company details and you are clearly refusing to do this. So why 
are you bothering me about making a reference to the 'fact' that you 
represent RAL?

I think we (you and I) may need to go off-line again.


Tam..

Tam wrote:


>>The examples for the SoftBaugh & Olimex
boards is code that's 
> 
> written by
> 
>>RAL, not TI.  
> 
> 
> 
> And the FET examples???

I will upload a copy if you like, the last kickstart download included C 
and assembler examples for every MSP430F sub family. In fact there are 
more examples in C than there are in assembler. 4 vs1 for the 149, 2:1 
for the 1121 etc.

Al

>From: onestone <onestone@ones...>
>Reply-To: msp430@msp4...
>To: msp430@msp4...
>Subject: Re: [msp430] Assembler Vs C-Compiler
>Date: Thu, 10 Jul 2003 23:52:13 +0930
>
>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?
>

Four batallions of 80-ish devices (matelots) ruled by a chief petty officer
(it was a naval system) programmed in ADA (Hard hats on men, time for
anther language war :D ).  As it was for the navy they could only march
approximately in step :-)
[big snip]

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

Ian (still at work but waiting for a decent sized block of data to fly 
through space)

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

Ian Okey wrote:

> 
> 
>>From: onestone <onestone@ones...>
>>Reply-To: msp430@msp4...
>>To: msp430@msp4...
>>Subject: Re: [msp430] Assembler Vs C-Compiler
>>Date: Thu, 10 Jul 2003 23:52:13 +0930
>>
>>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?
>>
> 
> 
> Four batallions of 80-ish devices (matelots) ruled by a chief petty officer
> (it was a naval system) programmed in ADA (Hard hats on men, time for
> anther language war :D ).  As it was for the navy they could only march
> approximately in step :-)

But they swayed in time I bet.


> Ian (still at work but waiting for a decent sized
block of data to fly 
> through space)

Al (working between teasing Tam. Waiting for a decent deep frozen vodka 
to find its way into my hand)

Tamer,

> > The examples for the SoftBaugh & Olimex
boards is code that's
> > written by RAL, not TI.
> 
> And the FET examples???

The FET example *projects* are TI's.  We have an agreement with TI to
allow us to modify and redistribute them as we please.  Some FET
examples were modified and used as template files for the FET New
Project wizard.

> >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.  
> 
> I never claimed you did.

The FET examples are TI examples, as I stated.

> > None of the examples refer to "use at
your own risk".
> 
> The following 'partial' file says you are wrong on this occasion!
it 
> is not an example, but a 'run-time' item. I don't know how
different 
> that is?!

It's not an example, as you point out, it is *the* *one* source file we
ship that makes up part of the RTL.  As such, it ships with the
compiler, is our code, contains our copyright, and that's that.  It's
included so that users with specific needs can use it as a template, but
if they go away from the standard startup code, it's at their own risk.

> But I will say this paul. It is on record here at
this forum that I 
> am 'for' members representing vendors to sign off their messages
with 
> their company details and you are clearly refusing to do this. So why 
> are you bothering me about making a reference to the 'fact' that
you 
> represent RAL?

AFAIK, group policy has not been set, so being personally 'for'
something doesn't compel me to do anything.  As I said before, I don't
like seeing sigs advertise products on each and every post, and as such
I don't put advertising material on mine either.

-- Paul.

onestone wrote

It would be interesting to develop a C-like language that was optimised for 
microcontroller/real world interfacing applications, I'm sure that a lot of

the speed and code size disparities that exist between C and assembler code 
is related to this.

[Ian dons Hard hat agaiin and says]
I remember that language.  It was called PL/M in various flavours from 8080 
through 8051 to 80386. (in chronological rather than numerical order)

Ian

_________________________________________________________________
Stay in touch with absent friends - get MSN Messenger 
http://www.msn.co.uk/messenger

Ian Okey wrote:

> 
> 
> onestone wrote
> 
> It would be interesting to develop a C-like language that was optimised for

> microcontroller/real world interfacing applications, I'm sure that a
lot of 
> the speed and code size disparities that exist between C and assembler code

> is related to this.
> 
> [Ian dons Hard hat agaiin and says]
> I remember that language.  It was called PL/M in various flavours from 8080

> through 8051 to 80386. (in chronological rather than numerical order)
> 
> Ian

I'd almost forgotten PL/M, it's been so long since I used it. 
8080/8085/8088/8048 and 8051. Except I'd suggest PL/M was probably not 
as high a level language as C.

Al

The only thing I'll add on this subject is that it doesn't make
sense to me
to knock C because it _can_ be written in such a way that it is not clear!
So can assembly, and I'd guess any other language.

I think it would be far more appropriate to contrast the readability,
comprehensibility, and so maintainability (by another programmer, or the
same programmer years later) of the same program, written well, in C and
assemby.

--Bruce



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

On Thu, 10 Jul 2003 10:09:27 -0000, Tam wrote:

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

Nothing is *wrong*, per se, 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).

That's not *all* a C compiler does.

When I first learned to use computers in 1972, I started out
with assembly.  I programmed assembly on the IBM 1130, assembly
on the PDP-8, assembly on the PDP-11, assembly on the HP-21xx,
assembly on the 8080 and 8085.

But when I first encountered C, in 1978 while learning the Unix
v6 kernel, it was like a dream language to me.  By that time,
I'd programmed in FORTRAN II and IV, COBOL-68, several BASICs,
PASCAL, and ALGOL-68.  But with C, working on operating systems
was suddenly a real snap.  (Yes, I'd tried writing operating
system code in such things as FORTRAN and BASIC, if you can
believe it.)

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

C does add a few things you need to be familiar with -- some
additional details which are peculiar to the compiler
implementation.  To the degree that libraries are standard, you
have to be aware of those facts, and to the degree that there
are peculiar details in those libraries which differ from
compiler to compiler, you have to be aware of those facts, too.
There will be syntax variations -- if nothing else, in the
#pragma's.

In embedded work, since linkers aren't part of the C standard,
you will have peculiar details of the linker to deal with.  Many
of those will be in common with assembly use, probably, but some
of the details may be C-implementation details which you'll also
have to absorb to use properly.

To be honest, in using C in embedded work, I've never been
entirely able to free myself from assembly work.  So in my
experience, I've always had a higher level of learning to do
when I include C in the development package.  I not only have to
be aware of everything which I must know in order to correctly
use the tools to develop in assembly, but I have to add in the
additional constraints, gotchas, and details that a specific C
compiler imposes on the project design.

So yes, I think C in embedded use increases the breadth of
knowledge required to get the job done and this fact alone
probably argues that you'll be asking the C compiler vendors
some questions.

I've not had the problems you've apparently experienced, in
dealing with compiler vendors.  But with what I saw written here
by you and assuming that every frustration you talked about was
unavoidable (an assumption I'll make just for argument's sake),
I'd probably be wondering why I was using C, too.

But C is often worth the effort, too.  It allows your client or
employer to more easily find programmers who can reasonably work
on much of the code -- and that detail tends to allow them to
hire more cheaply and/or more readily.  (Whether or not you want
that is another thing, of course.)  And it's easier to modify an
algebraic expression in C than to hack away at it in assembly,
for the most part.  Many algorithms are broadly portable, such
as sorting routines, tree walking, syntax lexing and parsing,
and so on.  But of course nothing is perfect and this is more
than doubly true for embedded work in small micros, you a LOT of
what you write in C will be rather specific to the application
and some will be specific to the compiler.  So to the degree
this happens, it tends to undermine the portability arguments.

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

Well, that's a fact of life if you are designing and developing
the application from scratch.  Not the "nothing but stress" part
of it, one hopes.  But the fact that you'll have to have a
broader understanding of various issues.  However, once you have
dealt with all these details, the application *can* be passed on
to other programmers who do *not* have to know as much as you
did, to jump in and modify the C portions at some later time.
So, if that's of value to your employer, it may be worth the up
front efforts.  As might the value of developing those kinds of
algorithms which are largely portable and may represent a useful
containment of knowledge -- particularly, if you also document
your understandings and efforts along the way.

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

I can't go there.  I can imagine that you can make that
judgement for your circumstances, which you know a lot better
than I do.  But as a conclusion applied to others?  No.

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

Well, if all one does is narrow their viewpoint using blinders
(blinkers to the British) and refuse to learn anything but C in
their programming life, then yes.  C isn't a be-all, saws-all.
And anyone stuck in that rut, when the applications and their
clients could well use assembly or some other language instead,
gives away a lot of power to the compiler vendors who may hold
their only source of relief.

But when your knowledge is broad enough that you can well use
any of the various C compilers which may be offered without
getting hung up on any one detail about them, are able to use
assembly well, and can also use other language options (C is the
more likely, but who knows?)... then you take back a lot of
control for yourself.

I know that if I have to switch away from Quadravox to
Imagecraft, for example, that there will be new things to pick
up and that I'll have to hack away at the various modules to
regain my starting position.  But I also *know* that I'm capable
of doing that in short order, too.  So the actual cost of
switching, should I need to, is finite and acceptable.  This
means that I have some small amount of power returned and that
if the compiler vendors want my purchases to continue in later
years, that they will have to work for me.

Some companies won't care and I'll discover this fact.  And I'll
then probably switch to some other compiler at the earliest
reasonable opportunity.  Oh, well.

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

The examples the chip makers will provide are there, usually, to
illustrate some feature of their chip.  And getting caught up in
the details of how that may look in specific C compilers may
involve them in certain, non-standard details for which the
compiler vendors may have felt some need to specialize their
syntax.  Plus, the chip makers have a good deal of market
pressure to provide an assembler toolset for their chips, but
often very little pressure to provide their own C compiler
(Microchip may be an exception, here.)  So they control the
assembler syntax, usually, and therefore only need to worry
about a single syntax.  But it's also VERY appropriate, when
dealing with hardware details of the chip to express those
details in assembly, not C.  It's very precise and unambiguous.

But, in the main, I'm not dependent on C compiler vendors for my
inspiration.  At least, I don't think so.  I have no problems at
all switching between mental states dealing with assembly, or C,
or even combinatorial or sequential logic in VHDL.  It's all
quite fluid for me.  There are times, as you suggest, that some
detail isn't clear to me about their compiler.  Most of those
questions can easily be resolved to my satisfaction by simply
looking at the assembly output.  There are times where that's
not enough -- for example, where I'd like to know some detail
about code segment naming conventions -- and those I simply pass
on to the compiler vendor.  And if they don't respond, I have
always been able to ferret it out for myself.

But yes, sometimes a C compiler vendor gets too big for their
britches and they start talking "proprietary" like they really
believed they were Zeus's gift to humanity or something.  It's
at that point I start looking for someone else to work with.  I
think the real issues are about relationship and if a compiler
vendor starts making it a one-sided deal, I start packing my
bags.  But I'm pretty easy to get along with, when we are all
pulling in the same directions.

Jon