CBFalconer <cbfalconer@yahoo.com> writes:
> Is it?  Let's just take the 15 year old C90 standard.  Can it build
> an object of 32767 byte size?

Is that required by the standard?

I've got plenty of useful C programs that never need to deal with
more than 4KB of data.

> Can it do long arithmetic (32 bit minimum).
> Can it do int arithmetic (16 bit minimum).

Yes to both.

> PIC assembly is so simple that anyone should be able to pick it up
> in a few days.  This doesn't mean they will be facile in it.

Agreed on both points.

Eric

"Casey" <cclremovethispart@cox.net> wrote in message
news:j28Rd.85382$B95.43017@lakeread02...
> Bob Stephens said
> > On Thu, 17 Feb 2005 07:30:30 -0800, Richard Henry wrote:
> >
> > >> At any rate, I consider the ability to handle assembly language
> > >> essential in exactly 98.375% of embedded applications. :-)
> >
> > I used to feel that way, but these days I'd say that at least 98.375% of
my
> > embedded work is handled entirely in C - with occaisional inline
assembler
> > hacks.
>
> Same here.   Things change with time.
>

So to be safe, 2% of the members of your coding staff should be familiar
with assembler.

With multiple developers, you actually can do okay if some members only
know C.

Rufus

On 17 Feb 2005 21:35:48 GMT, Hans-Bernhard Broeker wrote:

> Bob Stephens <stephensyomamadigital@earthlink.net> wrote:
> 
>>>> At any rate, I consider the ability to handle assembly language
>>>> essential in exactly 98.375% of embedded applications. :-)
> 
>> I used to feel that way, but these days I'd say that at least 98.375% of my
>> embedded work is handled entirely in C - with occaisional inline assembler
>> hacks.
> 
> You didn't get all the fine-print of the quoted statement.  Note that
> it says "ability to handle" assembly language, there, not "actually
> write the entire thing in it".  How would you get your occasional
> inline assembly hacks done, without the ability to handle assembly
> language?

agreed.

Bob Stephens <stephensyomamadigital@earthlink.net> wrote:

> >> At any rate, I consider the ability to handle assembly language
> >> essential in exactly 98.375% of embedded applications. :-)

> I used to feel that way, but these days I'd say that at least 98.375% of my
> embedded work is handled entirely in C - with occaisional inline assembler
> hacks.

You didn't get all the fine-print of the quoted statement.  Note that
it says "ability to handle" assembly language, there, not "actually
write the entire thing in it".  How would you get your occasional
inline assembly hacks done, without the ability to handle assembly
language?

-- 
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.

Bob Stephens said
> On Thu, 17 Feb 2005 07:30:30 -0800, Richard Henry wrote:
> 
> >> At any rate, I consider the ability to handle assembly language
> >> essential in exactly 98.375% of embedded applications. :-)
> 
> I used to feel that way, but these days I'd say that at least 98.375% of my
> embedded work is handled entirely in C - with occaisional inline assembler
> hacks.

Same here.   Things change with time.


Casey

On Thu, 17 Feb 2005 07:30:30 -0800, Richard Henry wrote:

>> At any rate, I consider the ability to handle assembly language
>> essential in exactly 98.375% of embedded applications. :-)

I used to feel that way, but these days I'd say that at least 98.375% of my
embedded work is handled entirely in C - with occaisional inline assembler
hacks.


Bob

Well, I read AN734 and rewrite it in C.
Thank you guys.

> At any rate, I consider the ability to handle assembly language
> essential in exactly 98.375% of embedded applications. :-)

Even if I agree with you I should confess that I belong to those
firmware developers that deal with quoted 1.625% applications.

My previous project has been developed entirely in C and we even did
not consider assembler.  Knowing that our HEX code use 96% of
PIC18F8720 ROM (125830 bytes) and that source code is about 450KB
[O.K. with comments :-)] it is obvious why we decided to use C instead
of assembler.

Again, I agree that it is nice if firmware developer know assembler. 
But...

"CBFalconer" <cbfalconer@yahoo.com> wrote in message
news:42145972.AC8AA721@yahoo.com...
>
> At any rate, I consider the ability to handle assembly language
> essential in exactly 98.375% of embedded applications. :-)

As long as you stay away from C++ horrors, C is a convenient shorthand way
to write assembler.  I have found that I can then tweak with #ASM where
needed if the C output is messy.

I guess it depends whether your primary software speed issue is "How fast
will it run?" or "When will you be done?"

"Tauno Voipio" <tauno.voipio@iki.fi.NOSPAM.invalid> wrote in message
news:8oPQd.687$Mf.467@read3.inet.fi...
> Tesvit wrote:
> >>Check out application note AN734 "Using the PICmicro SSP for Slave I2C
> >>Communication" at www.microchip.com. Good description of the SSP and C
> >>source code example.
> >
> >
> > Hi Bob,
> > Thank you for URL.  I checked it:
> > http://ww1.microchip.com/downloads/en/AppNotes/00734a.pdf but there is
> > just assembler source.  I need "C" one...
> >
> > Regards,
> > tesvit.
>
> So what?
>
> Just rewrite it in C, if you prefer. You cannot avoid at least
> reading assembler code if you will to get anywhere in the small
> controller world. It pays to get the assembler listings of the
> compiler output and have a look at surprises in code generation.
> A seemingly innocent C construction can expand to a machine
> code monster, and you'll notice where to improve.

Agreed.  I wrote my own EEPROM write routine after I saw the assembler
listing of how CCS PICC was doing it.

On the other hand, I converted an 68HC705 assembly program to ByteCraft C
some years ago as the first step in adding some features.  I was surprised
to see that the resulting object code was smaller than the original
assembler.  I studied the assembler listing from the C code to find out how
they did the improvements.