On Thu, 13 Apr 2000, Wagner Lipnharski wrote:

> Dale Botkin wrote:
> >
> > On Thu, 13 Apr 2000, Wagner Lipnharski wrote:
> >
> > > Your PIC C Compiler program source file is written in C language also,
> > > correct?  What if, this compiler of the compiler has bugs and generates
> > > some holes in the PIC C Compiler?  According to some piclisters here, it
> > > is a fact that *every* C compiler has bugs, alive and identified, or
> > > hidden and avid to use its fangs over your PIC, so, how can you live in
> > > such tension of being possibly assaulted by a terrible ghost of despair
> > > at 2am needing to have the code working for a 9am product presentation?
> >
> > Probably because I know if I do it in assembly, the presentation will be
> > at 9 AM -- three months from now.
>
> Exactly. This is the most common point for all "C" people. It will took
> light years to produce the same code in assembler... Of course, probably
> will take longer or even never be done, "if you don't know how to do
> it"...  I know both and as I already said before, assembler takes
> probably 10 to 15% more time than C, but I feel much more flexibility
> and control.  I feel firmly positioned because I know them both.

As do I.  But I can write code in C, especially things like math
functions, a lot faster than I can in assembler.  I don't have to keep
track of every single RAM location, every scratchpad variable, etc.  For
me, it's a matter of time efficiency.  Yes, I *could* write it in
assembler, but it's a LOT faster in C for me -- and I learned C, what,
three weeks ago??

> [snip]
>
> > > So, what can we learn about it?  If you have a problem with your program
> > > written in "C", just don't despair, first *don't look at your code for
> > > problems*, but go to the nearest tech support of your compiler and ask
> > > if, by any chance, there is any possible *known* bug that can generate
> > > such misbehavior at your software... if not, and don't forget it can be
> > > a new bug at the compiler, then scan your source code for possible
> > > errors, if you are good in assembler, then scan the generated code for
> > > possible understanding of what is happening, at least, there is always
> > > the black magic and voodoo in south america that are now updated to also
> > > fix compilers and I2C routines...
> >
> > Naah.  First look at your own code, because it's more likely to be at
> > fault. If YOUR code looks good, then look at the output of the compiler
> > for problems.  If you don't see anything, then ask the compiler folk if
> > there are known bugs.
>
> But then again, I don't understand, if you don't know assembler, or
> would take forever to write a code in ASM, how can you feel conformable
> to debug the C compiler ASM output?

If you don't know assembler, then you're in trouble either way.  Don't get
me wrong, I have been an assembler bigot for years.  I never used C or
BASIC or Forth or anything but assembler for the 8x48/51, Z80, 8088, 8085,
etc.  Never even considered it.  But since deciding to try C on the PIC,
I've been converted.  I still use an occasional in line assembly routine
when I need precise control of the timing, because it's a lot easier and
faster to do it that way, but for general code banging, I'll be working
mostly in C from now on.

Dale
---
The most exciting phrase to hear in science, the one that heralds new
discoveries, is not "Eureka!" (I found it!) but "That's funny ..."
                -- Isaac Asimov