Searching \ for 'Question: C vs Asm' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/language/index.htm?key=asm
Search entire site for: 'Question: C vs Asm'.

Truncated match.
PICList Thread
'Question: C vs Asm'
2000\04\11@195039 by Sam WILLIAMS

flavicon
face
I am attempting to create a test environment that will answer the question regarding the viability of using C vs assembler for PIC programming. I know most of the arguments, but I was wondering if anyone had any references to hard data that had been accumulated using a large number of test programs. I know the request may sound stupid, but  company management currently believes that  C would give us a better opportunity for finding programmers. Code size could be the caveat. We are developing code for embedded aerospace control applications which means we have very tight constraints on component selection and use.

Any help would be greatly appreciated.

--- Sam Williams



>>> spam_OUTwfTakeThisOuTspamBLUSOFT.ORG.BR 04/11 7:35 PM >>>
Hi again...

Can the parallel port PC force a Interrupt (INTERRUPT REQUEST) when some
external event occur?

Thanks!

mIGUEL



**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.


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

2000\04\11@195702 by John Orhan

flavicon
face
Hi there,
I am wondering if 'c' gives as much versatility ( in terms of embedded
multi-tasking ) as assembler. Can 'c' not do things only sequentially? Also
there is the question of how compact the assembly code turns out for a 'c'
compiled application.

                               John

               {Original Message removed}

2000\04\11@202025 by Dipperstein, Michael

face picon face
> -----Original Message-----
> From: John Orhan [.....JOrhanKILLspamspam@spam@edm.com.au]
> Sent: Tuesday, April 11, 2000 4:58 PM
> To: PICLISTspamKILLspammitvma.mit.edu
> Subject: Re: Question: C vs Asm
>
>
> Hi there,
> I am wondering if 'c' gives as much versatility ( in terms of embedded
> multi-tasking ) as assembler. Can 'c' not do things only
> sequentially? Also
> there is the question of how compact the assembly code turns
> out for a 'c'
> compiled application.
>
>                                 John

In C you have just as much control over the order of execution of instructions
that you do when you code directly in assembly.  Multi-tasking in C is just as
easy to do as multi-tasking in assembly.

There are only two real drawbacks that I see to using C:
- Sometimes it is possible to save a few instructions using hand optimized
assembly vs. machine optimized C.
- Sometimes I have to contend with compiler errors (which the Hi-Tech people
have been quick to fix) in addition to my own errors.

The pluses are:
- I can write the code quicker.
- The compiler catches some of my errors for me.
- It's easier to debug by visual inspection.

I have no concrete data on any of these claims, so the management types looking
for raw data will have to look elsewhere.

-Mike

2000\04\11@202450 by Brian C. Delsey

picon face
When optimization is an issue, you can incorporate embedded assembler into your C program as needed.

bcd

{Original Message removed}

2000\04\12@035708 by Clyde Smith-Stubbs

flavicon
face
On Tue, Apr 11, 2000 at 06:34:14PM -0500, Sam WILLIAMS wrote:
> I am attempting to create a test environment that will answer the question regarding the viability of using C vs assembler for PIC programming.

I don't think you will find a nice, neat study that looked at a large body of
real-world code. I would suggest taking an existing assembler-coded
application and recoding it in C, and comparing the result in terms of code
size.

I'm biased, of course, but we (HI-TECH Software) frequently receive comments
from users of our PIC compiler that indicate no code-size penalty for using
C, and in some cases the C code is actually smaller. Certainly, you will find
it far easier to find programmers who can write applications in C for the PIC
and get good results than you will find assembler programmers who can code
effectively for the PIC.

To help your management, here are a few comments from our customers that directly
touch on code size:

"I've gotten some really good ROM- and RAM-saving techniques by
studying the compiler's output. And I've been coding PICs for 5+ years"

"I demonstrated that I could generate more complex and more readable code much faster, and the compiler is so tight that they could not significantly improve on the assembly code it generates.  Now, they [two colleagues] have both turned in their purchase requests for HT PIC C!"

"I made regular checks of the generated assembly code for size and tightness and have been impressed almost every time."

"I've been very pleased with your product ... The code is clean and efficient."

"The optimizations are great! It is impressive how much code can be packed in such a tiny processor as the PIC!"

{Quote hidden}

--
Clyde Smith-Stubbs               |            HI-TECH Software
Email: EraseMEclydespam_OUTspamTakeThisOuThtsoft.com          |          Phone            Fax
WWW:   http://www.htsoft.com/    | USA: (408) 490 2885  (408) 490 2885
PGP:   finger clydespamspam_OUThtsoft.com   | AUS: +61 7 3355 8333 +61 7 3355 8334
---------------------------------------------------------------------------
HI-TECH C: compiling the real world.

2000\04\12@075806 by Walter Banks

picon face
> From: Sam WILLIAMS wrote:
> I am attempting to test the viability of using C vs assembler for PIC
programming.

We (Byte Craft) have done quite a few internal studies of C vs Assembly.
For
compilers that we have released in the last 2 or 3 years for any non
trivial
application C won both in size and execution speed.

There are some clear advantages to using C
 Local memory allocation is a clear win. This is primarily an accounting
 problem that is easily done by compiler/linkers and is implemented using
 exact algorithms.

 Compilers can code around silicon bugs and anomalies in a transparent
 way. Most silicon companies document sequences that have potential
 problems in some applications. C compilers treat these sequences as
 part of the constraints of code generation.

 Compilers can generate code sequences that are extremely difficult
 to maintain in assembler. For example, on the PIC's using the lsb of the
 PC to implement an unconditional skip the generated code sequence is
 address dependent..

 Memory management tracking in Call and GOTO optimization.

Walter Banks

2000\04\12@101451 by Ken Webster

flavicon
face
Sam Williams wrote:
>I am attempting to create a test environment that will
>answer the question regarding the viability of using C vs
>assembler for PIC programming. I know most of the
>arguments, but I was wondering if anyone had any
>references to hard data that had been accumulated using a
>large number of test programs. I know the request may
>sound stupid, but company management currently believes
>that C would give us a better opportunity for finding
>programmers. Code size could be the caveat. We are
>developing code for embedded aerospace control
>applications which means we have very tight constraints
>on component selection and use.
>
>Any help would be greatly appreciated.

I don't know where you could find 'hard' data comparing assembly language to
C except from compiler vendors.  I doubt that such data would provide much
useful information anyway since so much depends on the nature of the tests
and applications.  If the 'hand-coded' assembly is produced by translating a
C program, for example, then approaches which are possible only in assembly
language would be overlooked.  Assembly language often suggests the use of
different algorithms than C.  If such algorithms are used then more
efficient and tightly controlled use of resources can often be achieved.

I have encountered applications where I was unable to come up with an
acceptable solution using a C compiler but was able to find a good solution
coding in assembly language.  The last time I attempted to use a C compiler
for a PIC was about 3 years ago when I was working on a very large project.
I thought that dropping $700 on the compiler would be a good investment
because of the time it would save ...  I ended up wasting a lot of time and
going back to assembly language in the end because the design required tight
use of resources and I could not find a way to fit the design into the
selected part using the C compiler.  Techniques that I could only implement
in assembly (and not just inline assembly) allowed the design to fit in the
selected part with room to spare.

Today's PIC C compilers are probably much better (I don't know because I
haven't touched one since that bad experience).  I personally found that
assembly language is actually a lot less time consuming to program in than C
if the task demands efficient use or tight control of processor time, stack
space, or memory.  Note that I do spend a great deal of time programming in
C++ for larger machines so I really do appreciate the benefits of working at
a higher level of abstraction when resources are plentiful.  I just found
that the PIC compilers I tried to use would not allow me to apply certain
techniques that I had grown accustomed to using in assembly language.

Some examples of PIC assembly-language techniques that I could not find a
suitable substitute for in the then 'state-of-the-art' C compilers were:

1). Dispatch tables ... jumping to a handler based on the contents of a
register:

  TRANSMIT      MOVLW           HIGH TXJMPTBL
                MOVWF           PCLATH
                MOVF            TX_STATE,W
                ADDLW           LOW TXJMPTBL
                BTFSC           ALUSTA,C
                INCF            PCLATH,F
                MOVWF           PCL

  TXJMPTBL      GOTO            TX_0
                GOTO            TX_1
                GOTO            TX_2
                etc ...

  TX_0    ... (handler for transmit state 0)
  TX_1    ... (handler for transmit state 1)
          etc ...

This is something I definitely expected the C compilers to at least come
close to supporting but was disappointed by ... in ANSI C the following
would work in a similar fashion (using more stack space but otherwise doing
the same thing):

function protocols and table declaration:

  void tx_1(void);
  void tx_2(void);
  void tx_3(void);
  etc...

  void (*tx_functions[]) (void) =
  {
     tx_1,
     tx_2,
     tx_3,
     etc...
  };

then, to do the dispatch:
  tx_functions[tx_state]();


But, unfortunately the compilers I had available back then would not do
this.  Do modern C compilers for the PIC allow arrays of pointers to
functions (or better yet labels that are not necessarily function entry
points)?  Is there a way to GOTO the computed address rather than CALL it?

It would also be cool if a C compiler could optimize code so that the
following would dispatch control through a table:

  switch(tx_state)
  {
  case 0 :
     (code for tx_0)
  case 1 :
     (code for tx_1)
  case 2 :
     etc...
  }

The compilers I worked with just produced code like:
  MOVF  tx_state,W
  BTFSC STATUS,Z
  GOTO  tx_0
  XORLW 1
  BTFSC STATUS,Z
  GOTO  tx_1
  XORLW 1 ^ 2
  BTFSC STATUS,Z
  GOTO  tx_2
  etc...
which burned up way more ROM space and processor cycles than our application
allowed (the table was rather large and the timing critical).



2). Jumping to a common function entry or cleanup point to save ROM space
and stack levels:

  DO_ONE_THING        BSF      PORTC,3
                      GOTO     DO_THING

  DO_SIMILAR_THING    BCF      PORTA,0

  DO_THING            ...
                  (common code)
                      RETURN



3). Tightly controlling timing by counting clock cycles and balancing all
branches of a loop so that its cycle timing is constant.


4). Avoiding the per-call bank switching ROM space overhead for calling
functions in other pages of ROM by placing hooks in the same bank as the
caller and making the hooks flip the bank select bits.  Do modern compilers
automatically do this upon request (a "save memory" versus "save time"
optimization)?  It seems like they should but the ones I used a few years
ago didn't.  They would always produce code like:
     BSF   PCLATH,n
     CALL  FUNC_IN_HIGH_BANK
     BCF   PCLATH,n
regardless of how many times a call to that function occurred.


There are several other examples I ran across by comparing the assembly
output from the C compiler with what I would have done if I had hand-coded
it.  My best C implementation required more memory space and stack space
than the PIC microcontroller had available.  My assembly language
implementation, however, fit with plenty of room to spare and packed in
several features I was considering leaving off when I was trying to get the
C implementation to fit.

I truly would be interested in a C compiler that could allow a good
programmer to produce object code that compares favorably with hand-coded
assembly language (done by a competent coder, of course, and not patterned
after an algorithm that was designed for implementation in C).  I am not
holding my breath.  Some things are best done at a low level of abstraction.
C is very useful for many PIC projects and definitely has its niche.  To
attempt to apply it to situations where resources must be tightly
controlled, however, is like attempting to trim a Bonsai tree with a
chainsaw.  It is just not the most appropriate tool for such jobs.

Ken

2000\04\12@102518 by Scott Dattalo

face
flavicon
face
On Wed, 12 Apr 2000, Walter Banks wrote:

>
>   Compilers can generate code sequences that are extremely difficult
>   to maintain in assembler. For example, on the PIC's using the lsb of the
>   PC to implement an unconditional skip the generated code sequence is
>   address dependent..

Walter,

Could you give us some examples where this may be useful? The only situation
that I can imagine is link-time optimization. For example, if you created a
library that supports a mix of features, then you could select which features
are enabled simply based on where the code is located.


start:
   btfsc  pcl,0
    goto  feature1

feature2:
    ...

If the address of start is even, then feature2 is implemented otherwise feature1
is implemented. This also saves having to pass a parameter to the library
function being implemented (in other words, you could achieve the same
functionality by testing a passed parameter).

Now if the code with which you are linking is 'exposed' (as opposed to buried in
some library), then the same effect could be achieved with macros and
conditional assembly too. So us asm only guys and gal, wouldn't benefit too
much.

Scott

2000\04\12@104527 by Wagner Lipnharski

flavicon
face
I wonder, and would like somebody to explain, how you can still get bugs
from a C compiler that is years old...  we are not talking about a huge
software platform.  Is this some kind of beta test software?   I never
get any compiling error from the assembler compilers I use for years,
not a single one, so I think it is a steady and fully debugged software.
I only feel confortable working with a screw driver that still to be a
screw driver doesn't matter what.

About C vs Asm, this is a life long discussion thread, the same as
discuss about "what is better to get drunk, beer or vodka?"
C   = Vodka
Asm = Beer

C is faster to write, or vodka to get drunk.
ASM you know exactly what you are doing, and few glasses of beer don't
knock you down so easily.

If you are a good software writer, or a experient drinker, you will
enjoy C as well ASM (beer or vodka) in the same fashion, your final
product will be good in anycase, instead of getting drunk the
experienced drinker would enjoy each sip.

C definetely use more code space than Assembler (for me at least).

Regarding debugging ASM or C, I personally can read (and understand) ASM
source code much faster than C (that requires much more attention to the
more detailed source lines).

In assembler you can optimize better the processor features, memory
space, etc, even that I heard about new C compilers that can do almost
the same.

As I already said before, the final touch:  We made money in assembler
development time, and our wifes spend it in C development time.

In doubt, my personal recomendation is; Learn ASM and C, you will enjoy
both and will find out when and how you should use one or another.

Wagner Lipnharski
Orlando, Florida
http://www.ustr.net


"Dipperstein, Michael" wrote:
>
> > {Original Message removed}

2000\04\12@120406 by Dipperstein, Michael

face picon face
{Quote hidden}

I do exactly this with Hi-Tech C.  Well okay, not exactly, the functions have a
single parameter as well.


{Quote hidden}

I see my compiler doing that a lot.  It really screws up source level debugging,
but I appriciate the memory it saves.

> 3). Tightly controlling timing by counting clock cycles and
> balancing all
> branches of a loop so that its cycle timing is constant.

I don't think there are even directives that tell a compiler to try this.

{Quote hidden}

That's on my fantasy list.  Maybe this will catch someone's attention.

-Mike

2000\04\12@121042 by Dipperstein, Michael

face picon face
I have yet to see a bug free compiler.  Compilers are complicated things.  New
optimizations get added, and sometimes incorrectly used.  In the case of the PIC
world, new MCU variations are added that cause a change in the compiler.

If you haven't found a bug, you haven't looked hard enough.  Look at Microsoft's
bug list for the latest revision of Microsoft C.  That's been around since the
1980's.

-Mike

> {Original Message removed}

2000\04\12@121240 by D Lloyd

flavicon
face
Hi,

When you say "embedded", are we talking about what seems typically described as
"embedded" these days (i.e. embedded PC - 4MB RAM, 20GB Hard disk), or more like
the environment that I am used to, which is (admittedly large in PIC terms) 4K
RAM, 128KB code space? Joking aside, we write our applications in a logical mix
of C/assembler and are probably subject to similar constraints as you
are.....and we enjoy maintainability at the expense of code size , as you might
expect. I had the belief that any decent embedded C programmer would be acutely
aware of how their C affected matters in terms of generated assembler (in which
case, your management would be correct as you get someone that could do both). I
don't think it defeats the object of C to look into the assembler listing to
optimise how you have written a routine; you are merely providing a level of
abstraction which may or may not be a good thing; usually good, though.
I cannot give you any real numbers, sorry.

Regards
Dan

Is it not written in 'Code Complete' about eductating your management? ; )






Sam WILLIAMS <@spam@sam.williamsKILLspamspamHS.UTC.COM>
12/04/2000 00:34


Please respond to pic microcontroller discussion list <KILLspamPICLISTKILLspamspamMITVMA.MIT.EDU>

To:   RemoveMEPICLISTTakeThisOuTspamMITVMA.MIT.EDU
cc:    (bcc: Dan Lloyd/GBPTD/ABB)
Subject:  Question: C vs Asm

Security Level:?         Internal



I am attempting to create a test environment that will answer the question
regarding the viability of using C vs assembler for PIC programming. I know most
of the arguments, but I was wondering if anyone had any references to hard data
that had been accumulated using a large number of test programs. I know the
request may sound stupid, but  company management currently believes that  C
would give us a better opportunity for finding programmers. Code size could be
the caveat. We are developing code for embedded aerospace control applications
which means we have very tight constraints on component selection and use.

Any help would be greatly appreciated.

--- Sam Williams



>>> spamBeGonewfspamBeGonespamBLUSOFT.ORG.BR 04/11 7:35 PM >>>
Hi again...

Can the parallel port PC force a Interrupt (INTERRUPT REQUEST) when some
external event occur?

Thanks!

mIGUEL



**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.


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

2000\04\12@130648 by Wagner Lipnharski

flavicon
face
I use ASEM and ASM51 for years, it is a free 8051 ASM compiler, no bugs
reported yet AFIK, even with macros and else. I don't need to look hard
trying to find a bug, probably more than 500 different programs I made
already can talk by themselves, some of this source files counting more
than 20 thousand text lines (they don't fit in the regular 640k DOS
memory, needing to split them in several include files).

Now you know two free compilers, bug free.  The same for Microsoft 8086
ASM.EXE compiler, using for many years (probably more than 14), never
hit a hole in the cheese.  Looks like "C" is different, leads to bugs.
This is whay I said, I use mostly assembler because I can actual "see"
what the machine will do, I don't expect someone's bugs be introduced at
"my" code.

Once at IBM I made a cross compiler for Z80 microprocessor, in REXX
language (VM under MVS), took me 2 to 3 months to finish and debug it,
macros and all, so source files done in VM/CMS could be compiled to Z80
binary executable code. It was neat, clean and bullet fast, of course,
running in a IBM 3090 mainframe processor... this is the neat thing
about Assembler compilers, you just have to take care of Variables,
Labels, Constants, Direct values and Instructions, nothing else, simple
and easy. By the other side, "C" compilers requires lots of "programming
inteligence", the C compiler needs to solve your source-code-line
"equations", and sometimes some is bypassed or wrongly concepted.

Someday we will have WP compilers (Whole Program). You just state less
than a dozen lines of input/output requirements and click few option
buttons, the compiler will create your whole program at once.  Something
similar is available (hardware) FPGAs, PLDs, GAL's and so on, you just
need to input the bolean formula and the programmer software does all
the rest for you.  I can imagine chasing bugs at WP compilers...

Wagner

"Dipperstein, Michael" wrote:
{Quote hidden}

> > {Original Message removed}

2000\04\12@135228 by William Chops Westfield

face picon face
   I use ASEM and ASM51 for years, it is a free 8051 ASM compiler,
   no bugs reported yet AFIK, even with macros and else.

Assuming that you consider an assembler a compiler.


   some of this source files counting more than 20 thousand text
   lines (they don't fit in the regular 640k DOS memory, needing to
   split them in several include files).

Hey!  That sounds like a bug to me!  Why should a source file have to fit
in memory?


   The same for Microsoft 8086 ASM.EXE compiler, using for many years
   (probably more than 14), never hit a hole in the cheese.

I vaguely remember bugs that I had to work around in MASM 1 or MASM 2, back
when I was trying to write a large 8086 assembler program.  But that was
so long ago I don't remember what they were.

Just because you haven't found bugs, doesn't mean that bugs aren't there.
"conservative" code is a good idea as it will help you avoid bugs...

BillW

2000\04\12@141651 by Wagner Lipnharski

flavicon
face
Well, did you ever found a bug in a pocket calculator? in a InfraRed
remote control? The fact that you never found it, doesn't mean there is
some hiden. I would love to do the same question about MS Windows in
general... :)

It was not ASEM or ASM51 physical limitation to work into the 640k DOS
Memory, it was the easy and small DOS TEXT editor I ever used (old
"internal use only" IBM TE.EXE 1986/87), this limitation was planned,
not a bug. Anyway, just messy guys like me would go and write a source
code with more than 20k lines for a 8051.

Yes, conservative code is the best recomendation.
Wagner.

William Chops Westfield wrote:
{Quote hidden}

2000\04\12@143736 by Walter Banks

picon face
> From: Wagner Lipnharski <TakeThisOuTwagnerEraseMEspamspam_OUTUSTR.NET>
>
> I wonder, and would like somebody to explain, how you can still get bugs
> from a C compiler that is years old...  I never get any compiling error
> from the assembler compilers I use for years,

Complexity. Assemblers are straight translators. You can write an
assembler without understanding the instruction set. Assemblers
have a single production for each possible source statement.
A test suite for an assembler is a single program about
5 or 6 pages long.

C is a language with syntax and potentially ambiguous diverse meanings. C
lets you encapsulate abstract ideas independent of the target environment.

A C program can be easily moved to a different target platform where
assembly
contains both a description of the application idea and method that is
used to implement it.on a specific target,

A C compiler takes thousands of programs in a test suite.

..

2000\04\12@154239 by Clyde Smith-Stubbs

flavicon
face
On Wed, Apr 12, 2000 at 10:50:32AM -0700, William Chops Westfield wrote:
> Just because you haven't found bugs, doesn't mean that bugs aren't there.

When I was a student, I was told that "all non-trivial programs have
bugs". The corollary is that "any bug-free program is trivial".

The intervening years have not turned up any counter-examples, though
I have seen many bugs in trivial programs too :-)

--
Clyde Smith-Stubbs               |            HI-TECH Software
Email: RemoveMEclydespamTakeThisOuThtsoft.com          |          Phone            Fax
WWW:   http://www.htsoft.com/    | USA: (408) 490 2885  (408) 490 2885
PGP:   finger clydeEraseMEspam.....htsoft.com   | AUS: +61 7 3355 8333 +61 7 3355 8334
---------------------------------------------------------------------------
HI-TECH C: compiling the real world.

2000\04\12@162022 by Walter Banks

picon face
----------
> From: Scott Dattalo <EraseMEscottspamDATTALO.COM>
> To: RemoveMEPICLISTEraseMEspamEraseMEMITVMA.MIT.EDU
> Subject: Re: Question: C vs Asm
> Date: Wednesday, April 12, 2000 10:24 AM
>
> On Wed, 12 Apr 2000, Walter Banks wrote:
>
> >
> >   Compilers can generate code sequences that are extremely difficult
> >   to maintain in assembler. For example, on the PIC's using the lsb of
>>    the PC to implement an unconditional skip the generated code
>>    sequence is address dependent..
>
> Walter,
>
> Could you give us some examples where this may be useful?

One example on the MPC compilers is the skip transformation
when you have a skip instruction that is missing its
compliment in the instruction set. A Skip followed by
an unconditional skip transforms the pair into the
compliment function of the first skip.

Microchip PIC's do not have an unconditional skip so
we created one by skipping on the lsb of the PC.  The
alternative is to use a goto but that may require ROM
memory management. The unconditional skip is always
a single word instruction and leaves memory management
alone.

The following code fragment illustrates the point.

0025 3328    TSTFSZ 28               if (i)
0026 9002    BTFSS  PCL,0
0027 C02A    GOTO   002Ah
0028                                  {
0028 0000    NOP                        NOP();
0029 0000    NOP                        NOP();
                                     }

002A 3328    TSTFSZ 28               if (i)
002B 9802    BTFSC  PCL,0
002C C02F    GOTO   002Fh
002D                                  {
002D 0000    NOP                        NOP();
002E 0000    NOP                        NOP();
                                     }
002F 0002    RETURN                }

Walter Banks

2000\04\12@163725 by l.allen

picon face
This is probably a dumb ass question.

But how do you single step a programme with an ICE
while trying to follow your C source code?
I can with assembler, I cant see how this could be done
with C if there is not always a direct correlation line for
line, instruction by instruction.


_____________________________

Lance Allen
Technical Officer
Uni of Auckland
Psych Dept
New Zealand

http://www.psych.auckland.ac.nz

_____________________________

2000\04\12@170205 by Morgan Olsson

picon face
Hej Wagner Lipnharski. Tack fšr ditt meddelande 14:13 000412 -0400 enligt nedan:
>Well, did you ever found a bug in a pocket calculator?

Yes - Scary.

It was a programmable pocket calculator i had in school, SHARP PC-512 or something.  I got teh wrig answer to an equation.  Friends tried to help, and we got different answers to the same equation.  We split it up and fond it did wrong in some combination of numbers in a simple division, like 27/3 dit not become nine or something like that.  Strangely  one of my class friends had exactly the same SHARP model number, and it did calculate exactly.  The manufacturer did not want to change the model number, but one thing they did to make a differense was: the corrected version had another color of the back plate.

Never trust a machine, program, or human too, for that sake...

/Morgan

2000\04\12@172441 by Jerry Merrill

flavicon
face
<sorry for the double-post....wasn't paying attention!>
At 03:34 PM 4/12/00 , you wrote:
>This is probably a dumb ass question.
>
No...not at all.

>But how do you single step a programme with an ICE
>while trying to follow your C source code?
>I can with assembler, I cant see how this could be done
>with C if there is not always a direct correlation line for
>line, instruction by instruction.
>

The C compiler vendor encodes line number <-> address references in its
symbol file. The ICE vendor parses this data so it knows which addresses
(opcodes) were generated for any particular C source line.  When the user
'Single Steps' a C source line, the ICE can 'microstep' until it hits an
address that belongs to a different source line.  Once it hits an address
associated with a new source line, the displays are updated.


{Quote hidden}

Jerry Merrill

RemoveMEjerrymspam_OUTspamKILLspamtech-tools.com
http://www.tech-tools.com
FAX: (972) 494-5814
VOICE:(972) 272-9392
TechTools
PO Box 462101
Garland,  TX  75046-2101

2000\04\12@172853 by Scott Dattalo

face
flavicon
face
On Wed, 12 Apr 2000, Walter Banks wrote:

{Quote hidden}

Yeah butt,

    movf  28,f   ; i is at address 28
    skpnz
     goto l1

or
    movf  28,f
    skpz
     goto l2



Handles each of these situations too.

At the risk of giving Clyde a competitive advantage, could you give another
example? The only other conditional branching instructions that skip on only one
polarity are the incfsz and decfsz. I could see how you could use this trick to
implement an infsnz [the mnemonic as given in the 18cxxx instruction set] that
does not affect the z-bit.

   incfsz  i,f
    btfss  pcl,0
     goto  l1

but the same thing can be implemented with:

   incf    i,f
   skpnz
    goto   l1

(but the z-bit IS affected).


Scott

2000\04\12@180043 by M. Adam Davis

flavicon
face
It executes all the code pertaining to the line in question.  So single-stepping
the line
  PORTB=0x0f;
actually executes the code:
  MOVLW .16
  MOVWF PORTB

and whatever else was that line was compiled into, like bank switching.

This is fine for debugging your C code.  If you have an insiduous compiler bug,
it won't help you, you'll have to find where the problem is occuring, single
step the ASM code, and send in a bug report to the company that makes the
compiler.

And this is a very good question.

-Adam

Lance Allen wrote:
{Quote hidden}

2000\04\12@180837 by Dmitry Kiryashov

flavicon
face
Hi guys.

> Yeah butt,
>
>      movf  28,f   ; i is at address 28
>      skpnz
>       goto l1
>
> or
>      movf  28,f
>      skpz
>       goto l2
>

In common case it can be handled like following:

       test_some_condition
       goto    $+2
       goto    label

Any command can be used like decfsz,incfsz,tstf,skpc,skpnz,etc...

I also can't understand the reasons to introduce this
sophisticated trick with pcl related skip into programming.

WBR Dmitry.

2000\04\12@181452 by paulb

flavicon
face
Dmitry Kiryashov wrote:

> In common case it can be handled like following:

>         test_some_condition
>         goto    $+2
>         goto    label

> I also can't understand the reasons to introduce this
> sophisticated trick with pcl related skip into programming.

 He was indicating that they wished to avoid potential problems on
chips where GOTO is dependent on PCLATH.
--
 Cheers,
       Paul B.

2000\04\12@182118 by paulb

flavicon
face
Wagner Lipnharski wrote:

> Someday we will have WP compilers (Whole Program). You just state less
> than a dozen lines of input/output requirements and click few option
> buttons, the compiler will create your whole program at once.

 Having a daughter doing Computer Engineering has its rewards.  They
are teaching such things.  Go see http://www.haskell.org/

 (I find it a bit incomprehensible but ... I'm an Assembler junkie.)
--
 Cheers,
       Paul B.

2000\04\12@183334 by Scott Dattalo

face
flavicon
face
On Thu, 13 Apr 2000, Paul B. Webster VK2BZC wrote:

> Dmitry Kiryashov wrote:
>
> > In common case it can be handled like following:
>
> >         test_some_condition
> >         goto    $+2
> >         goto    label
>
> > I also can't understand the reasons to introduce this
> > sophisticated trick with pcl related skip into programming.
>
>   He was indicating that they wished to avoid potential problems on
> chips where GOTO is dependent on PCLATH.

Perhaps. However, his example had a goto too. Besides, if Dmitry can't think of
reason for it then there probably isn't one!

Scott

2000\04\12@183548 by William Chops Westfield

face picon face
> Someday we will have WP compilers (Whole Program). You just state less
> than a dozen lines of input/output requirements and click few option
> buttons, the compiler will create your whole program at once.

Hah.  Hah Hah!  I suppose this might be possible for those "problems" that
you can specify the Input and output requirements within a dozen lines.
Everyone knows that programming is easier with a full set of well specified
product requirements, but how often do you actually get that?  Not often.
Most software is is compromise in understanding vs implementation, and
of course it tends to evolve...

BillW

2000\04\12@183751 by Dmitry Kiryashov

flavicon
face
Hi Walter.

> Complexity. Assemblers are straight translators. You can write an
> assembler without understanding the instruction set. Assemblers
> have a single production for each possible source statement.
> A test suite for an assembler is a single program about
> 5 or 6 pages long.
You can't write in asm without clearly understanding what you are doing.
Learning assembler takes much more time than C in term of getting working
program.

> C is a language with syntax and potentially ambiguous diverse meanings. C
> lets you encapsulate abstract ideas independent of the target environment.
that's true and correct. one will pay extra program memory for that win.

> A C program can be easily moved to a different target platform where
> assembly
> contains both a description of the application idea and method that is
> used to implement it.on a specific target,
that's also true. that guy will get unpredictable code size and execution
time for black box of C compiled module.

> A C compiler takes thousands of programs in a test suite.
C is good for large projects with portability for different uC platform.
(100K lines of code and more)
Asm is excellent for fast responded short sized procedures.
(less that 100K lines of sources)

In terms of small embedded word there are not so many situations here
when using of C will get real advantage over asm.

Just my two cent.

WBR Dmitry.

2000\04\12@185446 by l.allen

picon face
Thanks to all who responed

I am thinking of obtaining a C compiler so this was a
issue for us.
My tech who does most of the actual PIC coding ( I tend
to concentrate on the algorithms, tricky interactive bugs
and hardware) is very good at C and recently generated
tables for DDS with a PIC in Borland C and ported the
output into our asm code.
It seems to me that small or tight applications will best
be served by asm but we are moving into areas like DDS
(developed 3 projects so far), DSP, Graphic control and
we are thinking of TCP/IP, where it would appear C is
better suited.
Trouble is I will have to remember how to use C, I was
horribly put off when everything seemed to go to C++ and
programmes ballooned in size.




_____________________________

Lance Allen
Technical Officer
Uni of Auckland
Psych Dept
New Zealand

http://www.psych.auckland.ac.nz

_____________________________

2000\04\12@185659 by Dmitry Kiryashov

flavicon
face
Scott Dattalo wrote:
>
> On Thu, 13 Apr 2000, Paul B. Webster VK2BZC wrote:
>
> > Dmitry Kiryashov wrote:
> >
> > > In common case it can be handled like following:
> >
> > >         test_some_condition
> > >         goto    $+2
> > >         goto    label
> >
> > > I also can't understand the reasons to introduce this
> > > sophisticated trick with pcl related skip into programming.
> >
> >   He was indicating that they wished to avoid potential problems on
> > chips where GOTO is dependent on PCLATH.
>
> Perhaps. However, his example had a goto too. Besides, if Dmitry can't think of
> reason for it then there probably isn't one!

Yep. It is possible but I don't know the way finally omit all gotos in code
written for PIC ;)

WBR Dmitry.

2000\04\12@190704 by William Chops Westfield

face picon face
> There are some clear advantages to using C
>   Local memory allocation is a clear win. This is primarily an accounting
>   problem that is easily done by compiler/linkers and is implemented using
>   exact algorithms.

Interesting.  I would have listed "global register allocation" as a clear
advantage of asm (though perhaps not relevant so much on PICs.)  You can
save a lot of time in speed critical code by having all your important data
in regsiters rather than ram (in a register-rich architecture, anyway) and
RESTRICTING the usage of those registers from general purpose functions.
(I don't really see why a C compiler couldn't do this, if it allowed
global variables to be defined "register" and took that "suggestion"
seriously, but I don't know of any compilers that actually DO that.)

BillW

2000\04\12@194514 by Erik Reikes

flavicon
face
In the PIC projects I write I use C almost exclusively.  The reason for
this for me is ease of code reuse, ease of readability, and its just plain
old easier to write in.  I never have to worry about code page bits, ram
bank bits, local variables, etc. etc.  Also, I have ported a number of
complicated functions written for other platforms quite easily to the PIC.

The detriments are slightly larger code size which I mitigate by being
careful about how and what C statements I use and when.

Now for the PIC, a C compiler really just ends up being a really excellent
Macro Assembler, but the benefits are huge.  I wouldn't recommend to anyone
starting out to start writing programs exclusively in ASM.  Its very
important to know the PIC ASM commands, but that is primarily just for
verification when something doesn't work right, and when occasionally you
must write something very time intensive.

My estimates for the medium sized project that I am working on currently
that C is costing me about 25% of my code space.  A lot of this is due to
sheer laziness because we have a ton of extra space currently.  The gain in
time spent implementing and debugging, however, is well over 90%.  As in I
believe it would take 10x as long to develop and debug this program in
straight assembler.

YMMV





Erik Reikes
Senior Software Engineer
Xsilogy, Inc.

RemoveMEereikesKILLspamspamxsilogy.com
ph : (858) 535-5113
fax : (858) 535-5163
cell : (858) 663-1206

2000\04\12@200816 by Quitt, Walter

flavicon
face
Wait till you fill (max) your part up (out)!
Trying to minimize implemented and working code is not simple.
One project is at 14K lines of ASM code (14 KLOCs) in a 16K part.
I even moved some constant overlay tables and LCD screens to serial EEPROM.

YES, for programming in the SMALL or simple stuff, C is GREAT.
But real-time, speed critical stuff is real hard to do well in C.
Sorry, that's MHO after years of doing real-time code and now
for the last 2+ years almost full time on PICs.

BTW: Using the BANKSEL and PAGESEL directives allows you to
write (basically) totally relocatable (modular/reusable) code
pieces in MPASM.  So you can have C drivers calling the ASM
fast/tight ASM routines.  There's something to be gained there,
I think.  Therefore, almost no worries about those pesky banks.

Also, from a maintenance standpoint poorly written or documented C
can be just as hard (or easy) to work with as similar ASM.
Been there and certainly done that!

BTW: I do both C and ASM.
"It is left as an exercise for the reader to determine which I like more!"

Hint: I don't even know, I just like to see the moving machines and
blinking lights......

Walt...
{Original Message removed}

2000\04\12@203307 by Brandon, Tom

flavicon
picon face
How can you compare C and Assembly? All you can do is compare a certain C
compiler (and\or programmer) with a certain Assembly compiler (and\or
programmer). It all depends on situation. The compiler(\programmer) and
project would have more influence than the language in most cases. If you're
doing DSP and you use a good C compiler with highly optimised assembly DSP
routines then it could easily be faster than your code cause someone spent a
lot of time writing good asm routines and they knew the architecture and the
problem better than you.

In general you CAN optimise assembly more than C in all cases but are you
better at optimising assembly than the people who wrote the C compiler?

Tom.

{Original Message removed}

2000\04\12@214107 by l.allen

picon face
Tom Wrote
> How can you compare C and Assembly? All you can do is compare a certain C
> compiler (and\or programmer) with a certain Assembly compiler (and\or
> programmer). It all depends on situation. The compiler(\programmer) and
> project would have more influence than the language in most cases.

Umm

>From what I know..

An "assembly" compiler does bugger all to the code,
other than fill in the macros and equates, take out the
comments, error trap etc.

The code generated is pretty much what the programmer
wrote line for line.  So yes the programmer has a VERY
big influence on how good the code is but not the
compiler.

Where as a C compiler is a more "removed" from the PIC
instruction set and therefore presents a variable from one
compiler to the next, this is on top of the idiot behind the
keyboard.

Just to show no bias.. the idiot behind the keyboard
(TIBTK) is a common factor in C and ASM.
_____________________________

Lance Allen
Technical Officer
Uni of Auckland
Psych Dept
New Zealand

http://www.psych.auckland.ac.nz

_____________________________

2000\04\12@223945 by Andrew Warren

face
flavicon
face
Walter Banks <PICLISTSTOPspamspamspam_OUTMITVMA.MIT.EDU> wrote:

> Compilers can generate code sequences that are extremely difficult
> to maintain in assembler.

... and then inexplicably chose to prove his point with one of the
most esoteric examples imaginable.

Here's an excerpt from a message I sent to the list 3 years ago; I
think it'll make Walter's point a little clearer:

   ----------------------------------------------------------------

   One of the nicest things about high-level compilers is that they
   can safely generate brittle code that no sane assembly-language
   programmer would DARE write.  [For those of you unfamiliar with
   the term, "brittle" refers to code that works NOW, but will stop
   working if seemingly-minor or irrelevant changes are made to it].

   For instance, let's say that you're doing the following:

       BUFFER  EQU     020H    ;A BUFFER STARTING AT REGISTER 20.

       ....

           MOVLW   BUFFER  ;POINT THE FSR TO THE START OF THE
           MOVWF   FSR     ;BUFFER.

           MOVLW   " "     ;STORE A "SPACE" CHARACTER IN THE BUFFER.
           MOVWF   INDF    ;

   A clever programmer might notice that the ASCII value of a
   "space" is 0x20, and save a word in the above code by removing
   the 'MOVLW " "'.

   That shortened code will work just fine... UNTIL you change the
   location of the buffer.  The instant you do that, it'll start
   putting the wrong character in the buffer, seemingly for no
   reason. After all, changing the location of the buffer SHOULDN'T
   change anything that's written into it, right?

   A high-level-language compiler, on the other hand, CAN safely
   remove that second "MOVLW"; if you later change the "BUFFER"
   location, the compiler will just put the MOVLW back in when you
   recompile.

   This was a simplistic example, of course... Really good
   compilers can do much more complex register-tracking and find
   LOTS of optimizations that would be too dangerous for an
   assembly-language programer to use.

   ----------------------------------------------------------------

And just in case there's someone who hasn't seen it yet, here's what
I wrote about C vs. Assembly when someone posed the question on my
web page 5 years ago:

   -----------------------------------------------------------------

   What are the relative merits of C versus Assembly-Language for
   microcontroller programming?

       Wow... Big topic. Here are the first few thoughts that come
       to mind (in no particular order):

       1. Good programmers can write good code in any language, and
       mediocre programmers will write crappy code in ALL
       languages. Writing in a high-level language makes it easy to
       avoid some "stupid" mistakes, but so does experience.

       2. The nature of microcontroller programming is such that,
       often, very little code is reusable between applications.
       There are so many differences between one
       microcontroller-based project and another that similar
       algorithms must often be coded in wildly different ways,
       which is why the traditional reasons for writing in a
       high-level language (portability across platforms and
       reusability from one project to the next) are generally NOT
       reasons to use a high-level language to program small
       microcontrollers. There ARE reasons -- about 25% of the
       microcontroller code I write is written in C, for example --
       but they have little to do with reuse.

       3. Some problems are better expressed in C than assembly,
       and vice-versa. You've got to pick the right tool for the
       job.

       4. Without a good understanding of the underlying assembly
       language, you won't be able to write optimal C.

       5a. An excellent C compiler can generate better code than an
       excellent assembly-language programmer, because the compiler
       can safely generate incomprehensible, non-maintainable,
       "brittle" code that the programmer wouldn't dare write.

       5b. An excellent assembly-language programmer can write
       better code than an excellent C compiler, because the
       programmer can see a much larger picture of the problem than
       the compiler can.

       6. C is easier to debug. Compiler code-generation errors are
       rare, so debugging a C program involves mostly finding and
       fixing bugs in the program's design, rather than in its
       implementation. Since C offers a higher level of abstraction
       than assembly, you don't get bogged down in "can't see the
       forest for the trees"-type debugging.

       7. Writing in C is faster than writing in assembly. I'm
       about the fastest assembly-language programmer I know, but I
       can write good C code even faster.

       8. Because they're so easy to write and debug, programs
       written in C often suffer from massive "feature-creep".

       9. With intelligent use of a really good macro assembler,
       you can have your cake and eat it, too. With an assembler
       that supports macros, multi-module code, long symbol-names,
       etc., you can write "C-like" (or BASIC-like, or... well, ok,
       not Lisp-like) macros that make assembly-language
       programming almost as easy as high-level programming.

       10. If you spend your whole life honing your
       assembly-language skills, you won't be nearly as employable
       as any of the hundreds of thousands of C programmers out
       there. While C PROGRAMS aren't always portable from one
       processor to another, C PROGRAMMERS are.

   ----------------------------------------------------------------

-Andy


=== Andrew Warren - spamBeGonefastfwdSTOPspamspamEraseMEix.netcom.com
=== Fast Forward Engineering - San Diego, California
=== http://www.geocities.com/SiliconValley/2499

2000\04\12@224202 by David VanHorn

flavicon
face
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


To clarify

>An "assembly" compiler does bugger all to the code,
>other than fill in the macros and equates, take out the
>comments, error trap etc.

There is no "assembly" compiler. It's an assembler.
It makes machine code out of assembler statements and directives.
RETLW 8  is exactly one word of assembler, and never anything else.
A compiler takes high level instructions, like "let A=25 Let B=9.72 Let
C=A*sqrt(B)"
and makes machine code.  You can find out how, but the whole point is that
you not look at what it's doing. Theoretically, you don't care. A small
change in some part of the code could theoretically result in many changes
all through the generated machine code.

>The code generated is pretty much what the programmer
>wrote line for line.  So yes the programmer has a VERY
>big influence on how good the code is but not the
>compiler.

It damn well better be EXACTLY what I wrote, line for line!
If not, it's broken.

>Where as a C compiler is a more "removed" from the PIC
>instruction set and therefore presents a variable from one
>compiler to the next, this is on top of the idiot behind the
>keyboard.

Here I agree. C is to some extent portable, and it encourages you
to ignore the machine's internal architechture and limitations/abilities.

The problem can crop up when C does something that is maybe locally
optimized, but
globally awkward. Maybe allocating registers for infrequent tasks and using
ram for
high speed tasks.


-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 6.5.2 for non-commercial use <http://www.pgp.com>

iQA/AwUBOPVJOYFlGDz1l6VWEQLoNQCgyXiOaMFimuHtP7oZRvxHWT/n7goAn259
J2YUBNxLPvhJSgAvF++coBAg
=ksHx
-----END PGP SIGNATURE-----

2000\04\12@235621 by paulb

flavicon
face
Scott Dattalo wrote:

> >   He was indicating that they wished to avoid potential problems on
> > chips where GOTO is dependent on PCLATH.
> Perhaps. However, his example had a goto too. Besides, if Dmitry can't
> think of reason for it then there probably isn't one!

 I was being rather subtle there.  :)

 Where a GOTO is used, some PICs may require PCLATH to be set first.
Point is, I can't recall to which, if any, chips this applies and
that's why I was being tongue-in-cheek about it.

Nevertheless, if you plan performing a GOTO to a FAR location as a
consequence of a conditional skip, but have to reverse the sense of the
skip and it isn't available, you need a "counter-skip" to follow.  You
can't use a GOTO for this, because if PCLATH is pre-set for the other
GOTO, your local skip will jump FAR instead.
--
 Cheers,
       Paul B.

2000\04\13@004517 by Wagner Lipnharski

flavicon
face
I have just a question to "C" compilers producers:

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?

Our colleague in Brazil, Miguel Wisintainer, got a problem with the
DS1621 for several weeks, the unit just stopped to respond for some
unknown reason, he lost half of the hair of his head, the other half got
white, he almost lost his sanity, I suspect he was praying and crying
for hours every day, (he was recommended to visit "candomblŽ and black
magic that can sometimes fix those problems), then (this week) for a
lapse of good luck he found out that the new version of the CCS had
*THIS BUG* fixed (I2CSTART).

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

Now the only thing that is missing, is to find out that Microchip is
releasing PIC chips that "possibly" carry bugs in the core... than my
friends, you all are doomed...

... you know that wire with the oxidized lead that solder doesn't stick
at any cost? and you can't wipe it clean? and can't sold it either? so
you apply a big amount of solder and that "ball" stick all around, it is
physically there, but you are not sure that it made a good electric
connection?  yup! the same feeling.

... you know that cable that you needed to pull and you applied more
pulling force than what you suspect the internal wires would stand, then
you are without any doubt suspecting that some wires could be broken...
and you need to use the cable to a demonstration of your important
device to a very important customer?  cant test it before, and don't
have another cable... yup! the same feeling.

... you know that your car's tire with that big patch, that needed to be
repaired twice already, and you need to travel 400 miles, in a raining
night? yup! the same feeling.

... you know that your car's battery that is stalling once in a while,
requiring a jumper from a "nice" friend here and there to start your
car, and that now is 11pm, you are the last one to leave the company, it
is raining, cold and you are approaching your car at the parking lot, it
looks deadly quiet there during the last 15 hours, and you have that
inner voice saying; "battery loves me, battery loves me not...", yup!
the same feeling.

2000\04\13@004534 by Mark Willis

flavicon
face
Andrew Warren wrote:
> <snipped>
>     A clever programmer might notice that the ASCII value of a
>     "space" is 0x20, and save a word in the above code by removing
>     the 'MOVLW " "'.
>
>     That shortened code will work just fine... UNTIL you change the
>     location of the buffer.  The instant you do that, it'll start
>     putting the wrong character in the buffer, seemingly for no
>     reason. After all, changing the location of the buffer SHOULDN'T
>     change anything that's written into it, right?

Solution for THAT, and an all-around GOOD programming practice:  Just
Comment out the 'movlw " "', and add something like,

 if !(Buffer == 020H)
 error "headspace error: uncomment the movlw line!"
 endif

(Same thing as an Assert(Buffer==020h).)  Assumptions like that &
strcpyn() instead of strcpy() & a few other "gotchas" WILL bite..

 Mark

2000\04\13@043218 by Alan B Pearce

face picon face
Has anyone tried to modify the Small C compiler that appeared in Dr Dobbs
Journal a few years back, so it will produce PIC assembler source? This compiler
was (may still be) available on CD from Dr Dobbs in the last couple of years.

This particular compiler used a subset of the K & R C definition to generate the
appropriate assembler source code which then had to be assembled. My memories of
looking at the code was it would be easy to change it to any processor.

The original version produced Z80 source, but I am aware that modified versions
existed that produced 8086 and at least one of the Motorola processor families
source code.

2000\04\13@044639 by Alan B Pearce

face picon face
>Well, did you ever found a bug in a pocket calculator?

All HP35 calculators had a rounding error in them when they were produced. This
was a problem known by HP when they produced the machines, and occurred because
the ROM chips available to them at the time were not large enough capacity to
put sufficient code in the calculator to get around this. As larger chips became
available, HP offered an upgrade to correct the problem.

2000\04\13@045711 by Alan B Pearce

face picon face
> Someday we will have WP compilers (Whole Program). You just state less
> than a dozen lines of input/output requirements and click few option
> buttons, the compiler will create your whole program at once.

Have a look at the Burroughs (now Unisys) Link programming system. It has been
doing exactly this for years as I understand it. The problem is the output is
Cobol.

2000\04\13@053730 by Michael Rigby-Jones

flavicon
face
part 0 3616 bytes
<P><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">Generaly speaking, porting an existing C compiler to the PIC architecture is a non trivial task.&nbsp; All the processors you mention below have a stack that is accessable for passing and returning parameters to functions, the normal C method of doing things.&nbsp; The PIC has no such stack, all parameters must be passed either through W for a single char argument or return, or through registers i.e. temporary variables.</FONT></P>

<P><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">Modifying the C compiler to use this method would probably take almost as much effort as starting from scratch.&nbsp; This is almost certainly why the GNU C compilers (BCC etc) haven't been ported for the PIC, but have been ported for other micros.</FONT></P>

<P><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">Porting it to something like an 8051 OTOH would be far easier, it may already have been done in fact.</FONT>
</P>

<P><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">Regards</FONT>
</P>

<P><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">Mike Rigby-Jones</FONT>
</P>
<BR>
<UL>
<P><FONT SIZE=1 FACE="Arial">{Original Message removed}

2000\04\13@072120 by Andrew Kunz

flavicon
face
Also, the Mathias ICE allows you to step INSIDE each line of code by making the
"code" window active prior t the step operation.

Andy









"M. Adam Davis" <KILLspamadavisspamBeGonespamUBASICS.COM> on 04/12/2000 04:42:23 PM

Please respond to pic microcontroller discussion list <EraseMEPICLISTspamEraseMEMITVMA.MIT.EDU>








To:      @spam@PICLIST@spam@spamspam_OUTMITVMA.MIT.EDU

cc:      (bcc: Andrew Kunz/TDI_NOTES)



Subject: Re: Question: C vs Asm








It executes all the code pertaining to the line in question.  So single-stepping
the line
  PORTB=0x0f;
actually executes the code:
  MOVLW .16
  MOVWF PORTB

and whatever else was that line was compiled into, like bank switching.

This is fine for debugging your C code.  If you have an insiduous compiler bug,
it won't help you, you'll have to find where the problem is occuring, single
step the ASM code, and send in a bug report to the company that makes the
compiler.

And this is a very good question.

-Adam

Lance Allen wrote:
{Quote hidden}

2000\04\13@072715 by Andrew Kunz

flavicon
face
I use C because time-to-market (and NRE costs) are so much lower with C than
with assembly.  My customers LIKE being able to

a) comprehend the logic in the code - it isn't "black magic" any more
b) adjust simple parameters (sensitivity, etc.  I'm doing this in asm code more
now too, though)
c) not pay so much for a functional prototype (test feasibility)

When products have to go in assembly, I often use teh C compiler to generate
code which I merge into the existing product or to find bugs in my own assembly
(yep, 7+ years of PICs and still making mistakes :-(

Andy










Dmitry Kiryashov <spamBeGonezewsspamKILLspamAHA.RU> on 04/12/2000 06:32:20 PM

Please respond to pic microcontroller discussion list <.....PICLISTspam_OUTspamMITVMA.MIT.EDU>








To:      TakeThisOuTPICLIST.....spamTakeThisOuTMITVMA.MIT.EDU

cc:      (bcc: Andrew Kunz/TDI_NOTES)



Subject: Re: Question: C vs Asm








Hi Walter.

> Complexity. Assemblers are straight translators. You can write an
> assembler without understanding the instruction set. Assemblers
> have a single production for each possible source statement.
> A test suite for an assembler is a single program about
> 5 or 6 pages long.
You can't write in asm without clearly understanding what you are doing.
Learning assembler takes much more time than C in term of getting working
program.

> C is a language with syntax and potentially ambiguous diverse meanings. C
> lets you encapsulate abstract ideas independent of the target environment.
that's true and correct. one will pay extra program memory for that win.

> A C program can be easily moved to a different target platform where
> assembly
> contains both a description of the application idea and method that is
> used to implement it.on a specific target,
that's also true. that guy will get unpredictable code size and execution
time for black box of C compiled module.

> A C compiler takes thousands of programs in a test suite.
C is good for large projects with portability for different uC platform.
(100K lines of code and more)
Asm is excellent for fast responded short sized procedures.
(less that 100K lines of sources)

In terms of small embedded word there are not so many situations here
when using of C will get real advantage over asm.

Just my two cent.

WBR Dmitry.

2000\04\13@085927 by Scott Dattalo

face
flavicon
face
On Thu, 13 Apr 2000, Alan B Pearce wrote:

> Has anyone tried to modify the Small C compiler that appeared in Dr Dobbs
> Journal a few years back, so it will produce PIC assembler source? This compiler
> was (may still be) available on CD from Dr Dobbs in the last couple of years.

Yeah there was a pic translation called pic_cc, by John Favata. It generated
pure crap. It is absolutely pathetic. One problem is that the Small C compiler
assumes a ram based stack. Another problem is that there is no optimization.
(John, if you're out there, I don't mean any kind of personal attack... I'm
stating the facts I've observed).

The consequence is that instead of being 25 or 50% larger, it generated code
that was 400 to 1000% larger. I'm not exagerating!

BTW, I'm almost embarassed to admit it, but I hacked pic_cc to compile under
Linux. You can get it here:

http://www.dattalo.com/gnupic/pic_cc.tar.gz

You can get the window's version on the gnupic webpage: http://www.gnupic.org/

If you wish to check it out feel free to do so. However, I can't offer any
technical assistance.

BTW, AnyC is gcc based project that is attempting to produce a pic c
compiler. The source code (or at least a link to it) is also available on the
gnupic webpage. It's a work in progress - a euphemism for a hobby. But it's
taking a better approach at generating a Pic C compiler.

Scott


>
> This particular compiler used a subset of the K & R C definition to generate the
> appropriate assembler source code which then had to be assembled. My memories of
> looking at the code was it would be easy to change it to any processor.
>
> The original version produced Z80 source, but I am aware that modified versions
> existed that produced 8086 and at least one of the Motorola processor families
> source code.
>

2000\04\13@101325 by Walter Banks

picon face
----------
> From: Brandon, Tom <TakeThisOuTTomKILLspamspamspamPSY.UNSW.EDU.AU>
>
> In general you CAN optimise assembly more than C in all cases but are you
> better at optimising assembly than the people who wrote the C compiler?

Actually a C compiler is a data base of the optimizations of the compilers
authors and all of the people who called in and said, "You can do the
following
sequence in less code". This data base of programming tricks are then used
where appropriate.

Walter Banks

2000\04\13@101334 by Walter Banks

picon face
{Quote hidden}

But, but   :)

Your sequence will work on the 12 and 14 bit cores.
On the 17Cxx (the only processor with a TSTFSZ) the
movf is replaced with movpf. This instruction will only
test the first 16 locations of RAM limiting its usefulness

Walter Banks

2000\04\13@101337 by Walter Banks

picon face
----------
> From: William Chops Westfield <RemoveMEbillwspamspamBeGoneCISCO.COM>
> You can save a lot of time in speed critical code by having all
> your important data in regsiters rather than ram .
> ...a C compiler couldt do this, if it allowed global variables to
> be defined "register" and took that "suggestion"
> ...  but I don't know of any compilers that actually DO that.

Named address space in Byte Craft's MPC allows developers to
do exactly that.

Walter Banks

2000\04\13@104504 by Dale Botkin

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

> Our colleague in Brazil, Miguel Wisintainer, got a problem with the
> DS1621 for several weeks, the unit just stopped to respond for some
> unknown reason, he lost half of the hair of his head, the other half got
> white, he almost lost his sanity, I suspect he was praying and crying
> for hours every day, (he was recommended to visit "candomblé and black
> magic that can sometimes fix those problems), then (this week) for a
> lapse of good luck he found out that the new version of the CCS had
> *THIS BUG* fixed (I2CSTART).

But was that a compiler bug, or a bug in a routine supplied with the
compiler?  

I always go through the ASM code generated by the compiler.  One of the
reasons I use C is to become better at assembly, by looking at how the C
compiler does things.  The compiler was written by people who are much
better at assembly than I am.  Anyway, if I don't know exactly what needs
to be done to interface to a particular device, I know I'd better learn it
if I'm going to have any chance at debugging problems.  Always remember
that the compiler is a *tool* for generating code, not a method of
extracting code from the heavens.

{Quote hidden}

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.

As for the litany of unreliable devices...  well, yeah, if you break
something, it's broken, that's how things work.  Try not to break things,
and if you know they're broken, either fix them or replace them.

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

2000\04\13@111556 by Andrew Warren

face
flavicon
face
Mark Willis <spamBeGonePICLIST@spam@spamspam_OUTMITVMA.MIT.EDU> wrote:

> > A clever programmer might notice that the ASCII value of a
> > "space" is 0x20, and save a word in the above code by removing
> > the 'MOVLW " "'.
> >
> > That shortened code will work just fine... UNTIL you change the
> > location of the buffer.
>
> Solution for THAT, and an all-around GOOD programming practice:  Just
> Comment out the 'movlw " "', and add something like,
>
>   if !(Buffer == 020H)
>   error "headspace error: uncomment the movlw line!"
>   endif

Mark:

As you know, I'm a big proponent of that sort of defensive
programming; I think I recommended doing the same sort of thing a few
weeks ago, in a thread on page-crossing lookup tables.

My point, though, was that C compilers do that sort of thing
AUTOMATICALLY.

-Andy


=== Andrew Warren - TakeThisOuTfastfwdspamspamix.netcom.com
=== Fast Forward Engineering - San Diego, California
=== http://www.geocities.com/SiliconValley/2499

2000\04\13@111559 by Wagner Lipnharski

flavicon
face
> In general you CAN optimise assembly more than C in all cases but are you
> better at optimising assembly than the people who wrote the C compiler?

The fact to be working in a C Compiler producer company, writing
compilers, doesn't mean a person knows more than everybody else in the
world that is NOT working at that company. I am not saying either that
they know less, but for sure there is NOT a selection exam to choose the
best of the world software writers to be part of such software company.

During my professional life I turned to be a specialist in a half dozen
things, and I can say that there is this false presumption that only
specialists can produce something useful. They just know more about
something because they got more contact with the subject, but it doesn't
mean they are more intelligent about it. They can collect much more
information about the subject, but it doesn't mean they will use all of
it, or even remember that they have it.

So, the answer to the above question is *YES*, and probably lots of
other people too.

2000\04\13@112804 by Wagner Lipnharski

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

[snip]

{Quote hidden}

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?

The closer I can imagine, is trying (for me) to debug a program looking
only at the .HEX file binary display...

Wagner

2000\04\13@114221 by Dale Botkin

flavicon
face
On Thu, 13 Apr 2000, Wagner Lipnharski wrote:

{Quote hidden}

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

{Quote hidden}

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

2000\04\13@115706 by John Mitchell

flavicon
face
On Thu, 13 Apr 2000, Andrew Warren wrote:

> Mark Willis <PICLISTEraseMEspamMITVMA.MIT.EDU> wrote:
>
> > [...] and an all-around GOOD programming practice:  Just
> > Comment out the 'movlw " "', and add something like,
> >
> >   if !(Buffer == 020H)
> >   error "headspace error: uncomment the movlw line!"
> >   endif


In C, and maybe assembly, a better phrase is the following:

       if (020H != Buffer)
       error "headspace error: uncomment the movlw line!"
       endif

That is, the constant is on the *left* hand side of a comparison.  If you
slip, and write:

       if (020H = Buffer)

you'll get the the appropriate error from your compiler.  Compilers are
tools -- use the wisely to catch the ugliest problems for you.

I've spent way too many hours tracing down why "if (i=0)" never works...


- j

2000\04\13@120124 by Andrew Warren

face
flavicon
face
Andrew Kunz <RemoveMEPICLISTEraseMEspamspam_OUTMITVMA.MIT.EDU> wrote:

> the Mathias ICE allows you to step INSIDE each line of [C] code by
> making the "code" window active prior to the step operation.

   ... as does MPLAB.

   -Andy


=== Andrew Warren - @spam@fastfwdRemoveMEspamEraseMEix.netcom.com
=== Fast Forward Engineering - San Diego, California
=== http://www.geocities.com/SiliconValley/2499

2000\04\13@120334 by Andrew Kunz

flavicon
face
Wagner,

I agree with you - it's essential to know both.  I used to agree with you about
using asm instead of C for "flexibility and control," but a few projects in
mixed modes made me see the value of C.  I now have equal flexibility and
control in either one.

I've been working with these (and other) processors for quite a few years, and
find myself using C to produce quick bug-free code in a shorter time than in
assembly, quite consistently.  Doesn't matter which processor.  WRT PICs, if I
have a library routine in asm, I frequenty drop it into C (this is VERY easy to
do with the HiTech tools).  If I have to write it anew, I use C and frequently
debug the algorithm on my PC using PC tools, then use the same code (sometimes
with minor revisions, often with none) in a PIC.

The C compiler is a tool, just like the assembler.  You ahve to use the right
tool for the job.

Granted, there are some things that are difficult if not impossible to do in C.
One recent example is to perform a add/mult/div sequence on 16-bit values, while
measuring the pulse on a pin at 6uS intervals, using a 4 MHz resonator.
Impossible with straight C, but easy in asm.

The algorithm for the add/mult/div portion was coded in C.  I then interleaved
my pulse measurement into the assembly source code (-S option for HiTech).
Then I had to transfer the code from the HiTech assembler to work on CVASM (to
maintain compatibility with the customer).

Took a little time, but it worked first shot.  It was faster than going it from
assembly the whole way.

It was a matter of using the right tool at the right time in the application.

So, yes, knowing both is essential, but ruling out one or the other is foolish.

Andy










Wagner Lipnharski <EraseMEwagnerspam@spam@USTR.NET> on 04/13/2000 11:23:13 AM

Please respond to pic microcontroller discussion list <@spam@PICLISTspam_OUTspam.....MITVMA.MIT.EDU>








To:      spamBeGonePICLISTEraseMEspamMITVMA.MIT.EDU

cc:      (bcc: Andrew Kunz/TDI_NOTES)



Subject: Re: Question: C vs Asm








Dale Botkin wrote:
{Quote hidden}

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.

[snip]

{Quote hidden}

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?

The closer I can imagine, is trying (for me) to debug a program looking
only at the .HEX file binary display...

Wagner

2000\04\13@121205 by Andrew Warren

face
flavicon
face
Wagner Lipnharski <PICLISTspamBeGonespamMITVMA.MIT.EDU> wrote:

> > In general you CAN optimise assembly more than C in all cases but
> > are you better at optimising assembly than the people who wrote the
> > C compiler?
>
> The fact to be working in a C Compiler producer company, writing
> compilers, doesn't mean a person knows more than everybody else in the
> world that is NOT working at that company.

   True, Wagner... But compiler manufacturers DO answer the phone
   when it rings, and sometimes the person on the other end of the
   line says something like, "Hi, [Walter/Clyde], this is
   [Andy/Scott/whomever].  Y'know, you can save an instruction in
   your 16-bit subtractions by...."

   When that happens, the next version of the C compiler generally
   includes those optimizations.  In other words, specific compiler
   optimizations are often developed by a whole TEAM of people,
   most of whom don't even work for the compiler manufacturers.

   -Andy


=== Andrew Warren - RemoveMEfastfwd@spam@spamspamBeGoneix.netcom.com
=== Fast Forward Engineering - San Diego, California
=== http://www.geocities.com/SiliconValley/2499

2000\04\13@123504 by Wagner Lipnharski

flavicon
face
Andrew Warren wrote:
[snip]
>     True, Wagner... But compiler manufacturers DO answer the phone
>     when it rings, and sometimes the person on the other end of the
>     line says something like, "Hi, [Walter/Clyde], this is
>     [Andy/Scott/whomever].  Y'know, you can save an instruction in
>     your 16-bit subtractions by...."
>
>     When that happens, the next version of the C compiler generally
>     includes those optimizations.  In other words, specific compiler
>     optimizations are often developed by a whole TEAM of people,
>     most of whom don't even work for the compiler manufacturers.

Most true, and it is very nice to have this kind of "personal" support.
But this only happens because there is a mutual interest. Try to get the
same attention from Microsoft when your Visual Basic doesn't work the
way you want, and you got stuck...

In some sense you will end up with a low cost product that was debugged
(part of) in the field (by the customers), a practical way to do a field
test and gatter data for implementations. For my particular type of
products and customers, I can't afford this kind of business practice.
My customers are not that compreensible, when they buy a screwdriver
they want one with the handler in place and the blade already done.
There are customers and business.  :)

Wagner

2000\04\13@125946 by Andrew Kunz

flavicon
face
All the more reason to run GNU on Linux.

Now if only there were GNUPIC C...

Andy









Wagner Lipnharski <.....wagner@spam@spamEraseMEUSTR.NET> on 04/13/2000 12:30:55 PM

Please respond to pic microcontroller discussion list <.....PICLISTRemoveMEspamMITVMA.MIT.EDU>








To:      .....PICLISTSTOPspamspam@spam@MITVMA.MIT.EDU

cc:      (bcc: Andrew Kunz/TDI_NOTES)



Subject: Re: Question: C vs Asm








Andrew Warren wrote:
[snip]
{Quote hidden}

Most true, and it is very nice to have this kind of "personal" support.
But this only happens because there is a mutual interest. Try to get the
same attention from Microsoft when your Visual Basic doesn't work the
way you want, and you got stuck...

In some sense you will end up with a low cost product that was debugged
(part of) in the field (by the customers), a practical way to do a field
test and gatter data for implementations. For my particular type of
products and customers, I can't afford this kind of business practice.
My customers are not that compreensible, when they buy a screwdriver
they want one with the handler in place and the blade already done.
There are customers and business.  :)

Wagner

2000\04\13@131226 by jamesnewton

face picon face
Funny, I don't remember seeing anything on any C compiler manufacturers web
site, program output, manuals or other docs to encourage people to report
optimizations.... I may have missed it. Please correct me if I have.

But there have been a lot of code challenges on the PICList and a lot of
code is available on the FAQ and other sites. I ask for people to release
code all the time. Mr. Davis has offered to reward people who release code
that he sees as useful to the community (IDE-PIC interface and thank you Mr.
Davis)

Do compiler manufacturers benefit from PICList members? (probably) Do they
credit them? (doubtful) Do we benefit from improvements in the compiled
code? (if we use their product...) Can we benefit as much from members code
without the (hard) work of selecting the best code for the situation that
the compiler manufacturers must perform in the compiler? Could open source
work? Could an on-line code generator built from a public domain C (or
other) compiler do an acceptable job of selecting from an optimized
functions library directly updated by list members? How would that affect
compiler manufacturers?

Do compiler manufacturers "hoard" the optimizations that they are directly
made aware of? I do remember at least one case of code being volunteered
onto the PICList by a compiler vendor (a 16x16 bit Multiply routine from
Clyde Smith-Stubbs of HI-TECH software). Would it be better for the
community to report an optimization directly to the list? Would that anger
or illegally damage the compiler manufacturer? What if their name and
original code were left out of it? Is there a motive for the user of the
compiler to "go public" with an idea rather than feed it back to the
manufacturer? Do the manufacturers reward "private optimizers"?

Please understand that I'm not complaining or trying to start a war. I just
think these questions should be asked and I'm interested in hearing the
answers.

Also, I don't see this as off topic, but if you do, please let me know
directly. Please do not complain to the list.

---
James Newton (PICList Admin #3)
jamesnewtonEraseMEspam@spam@piclist.com 1-619-652-0593
PIC/PICList FAQ: http://www.piclist.com or .org

{Original Message removed}

2000\04\13@132307 by Scott Dattalo

face
flavicon
face
On Thu, 13 Apr 2000, Andrew Kunz wrote:

> All the more reason to run GNU on Linux.
>
> Now if only there were GNUPIC C...

Well, there is - sort of.

Daniel Webb is working on a C-compiler for pics. I have no idea how useful it is
at the moment. I've done nothing other than view the webpage.

http://www.crosswinds.net/~anyc/


(he's using Windows instead of Linux for his development environment).


Scott

2000\04\13@133753 by Wagner Lipnharski

flavicon
face
James Newton wrote:
[snip long text of questions about if compiler manufacturers benefit
from field tests and customer or this list suggestions]

Of course they do, even if they don't say that. If not, why then FORD,
CHEVY and all other car manufacturers make thousands of beta tests,
distribute hundreds of free cars for people able to report back all the
problems and suggestions?  Not only cars, free refrigerators, ovens, all
kind of domestic appliances go to the same tests year after year.

I don't do it open wide with my customers, but of course I read their
lips and the small wispers in between their words, trying to understand
what they want at the follow-on device, so sooner or later they will
find out the device of their dreams...  I don't have a crystal ball, not
anyone else, and I can't just wake up at morning knowing all of what my
customers want.

Of course they use lots of ideas, suggestions and complains from this
list. This list is a strong supply of information to them, including all
the embedded BS dragged all along.  You can be quite sure that at least
a couple of them are reading all of this thread in details.

Recognize names and authors of tricky solutions? what for? so they would
need to pay the guy for it? nah. It is purelly business.  You learn
tricky things here and there, basically you don't reward everyone who
teach you things "for free".

When working at IBM in a Teleprocessing and Network Support Team, every
single problem or complain was taken to a meeting, it was an unvaluable
source of information to improve the service, new trainning, new tools,
new procedures.  Some customer could realize that, others don't, but
basically you can grow and make more money based on customers problems.
Just business, when the smart one learn from any situation.

Wagner.

2000\04\13@143732 by William Chops Westfield

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

Editors, operating systems, assemblers, and the PIC chips themselves all
have bugs.  It's our job to make working code in spite of it all.  This is
part of what programming is an art...

I remember once when I had typed in a (8080) forth system from a magazine,
assembled it with homemade cross-assembler, and tried to run it on a
homemade simulator.  THAT was frustrating!

BillW

2000\04\14@094730 by Marc

flavicon
face
> In C, and maybe assembly, a better phrase is the following:
>
>         if (020H != Buffer)
>         error "headspace error: uncomment the movlw line!"
>         endif

What about

        if (' ' != Buffer)
          movlw ' '
        endif

2000\04\14@153909 by William Chops Westfield

face picon face
        if (' ' != Buffer)
          movlw ' '
        endif

By the time you clutter up your source file with crap like this, it's even
less readable than normal assembler.  I have big problems with obscure
optimizations done for their own sake (in HW as well as SW) - if you do this
sort of thing, you'd better REALLY need that extra word, AND you'd better
comment the hell out of it.

A compiler can do the equivilent as a matter of course, but it's a bit
questionable whether the CPU cycles spent keeping track of every register
containing a constant is worth the occasional ability to make such an
optimization - there are benefits to having a compile be QUICK, too.
(obviously, the benefit is greater on something like a PIC with 8 bit
registers and very limitted instruction space, and you probably won't
be having hour-long compiles anyway...)

BillW

2000\04\14@160601 by Dan Michaels

flavicon
face
BillW wrote:

>         if (' ' != Buffer)
>           movlw ' '
>         endif
>
>By the time you clutter up your source file with crap like this, it's even
>less readable than normal assembler.  I have big problems with obscure
>optimizations done for their own sake (in HW as well as SW) - if you do this
>sort of thing, you'd better REALLY need that extra word, AND you'd better
>comment the hell out of it.
>
......
>BillW
>

BillW scores a homerun.

2000\04\14@182614 by Clyde Smith-Stubbs

flavicon
face
On Fri, Apr 14, 2000 at 12:38:02PM -0700, William Chops Westfield wrote:
> questionable whether the CPU cycles spent keeping track of every register
> containing a constant is worth the occasional ability to make such an
> optimization - there are benefits to having a compile be QUICK, too.

Keeping track of things like that is easy, and not time consuming.
At most the overhead will be linear wrt. program size, whereas the
things that kill compile time are those things that are exponential
on program size (there are quite a few problems in code generation
that are NP-complete). They mostly relate to tree operations and
register allocation, though register allocation on a PIC is a no-brainer.

Cheers, Clyde

--
Clyde Smith-Stubbs               |            HI-TECH Software
Email: RemoveMEclydespamspamBeGonehtsoft.com          |          Phone            Fax
WWW:   http://www.htsoft.com/    | USA: (408) 490 2885  (408) 490 2885
PGP:   finger spamBeGoneclydeKILLspamspam@spam@htsoft.com   | AUS: +61 7 3355 8333 +61 7 3355 8334
---------------------------------------------------------------------------
HI-TECH C: compiling the real world.

2000\04\19@032126 by Paul Anderson

flavicon
face
On Thu, 13 Apr 2000, Wagner Lipnharski wrote:

> Try to get the
> same attention from Microsoft when your Visual Basic doesn't work the
> way you want, and you got stuck...
>
Well, there's three words in that sentence that are your main problems:
Microsoft and Visual Basic.  Microsoft software having been sub-standard
software for years(MS compilers having had that reputation much longer
than the rest of their software), and Visual Basic being a toy language.




---
Paul Anderson - Self-employed Megalomaniac
paulspam_OUTspam@spam@geeky1.ebtech.net
http://zephyr.sellad.on.ca/~paul
"Malrekomendegi!"

2000\04\19@032139 by Paul Anderson

flavicon
face
On Thu, 13 Apr 2000, Wagner Lipnharski wrote:

>
> 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...
>
You have to realize that 99.999999% of the time, the problem is the
programmer's fault, not the compiler.  0.0000005% of the time, it's a
compiler bug.  The other 0.0000005%, someone is out to get you.  If you
run across a compiler bug, either you are (a) using a buggy development
version, (b) just about to be struck by lightning, or (c) SEVERELY pushing
the compiler's limits and capabilities.  It's extremely rare that you will
find a compiler bug interfering with the function of your code, and if it
ISN'T rare, switch compilers.


---
Paul Anderson - Self-employed Megalomaniac
spamBeGonepaul@spam@spamgeeky1.ebtech.net
http://zephyr.sellad.on.ca/~paul
"There *is* light at the end of the tunnel.
>From here, it looks like the Moon."
       -- Edward Jones, Head of the Lunaris Project

2000\04\19@110510 by M. Adam Davis

flavicon
face
Its nice, however, that one using a 'toy language' can command a 50k salary -
with no degree.

-Adam

Paul Anderson wrote:
>... Visual Basic being a toy language.
> ---
> Paul Anderson - Self-employed Megalomaniac
> RemoveMEpaulEraseMEspamKILLspamgeeky1.ebtech.net
> http://zephyr.sellad.on.ca/~paul
> "Malrekomendegi!"

What, pray tell, are you strongly un-recommending?
(I like search engines.  Only one page showed up under "Malrekomendegi!")

2000\04\19@155158 by Paul Anderson

flavicon
face
On Wed, 19 Apr 2000, M. Adam Davis wrote:

> Its nice, however, that one using a 'toy language' can command a 50k salary -
> with no degree.
>
Sure, but that makes no comment as to it's real-world usefulness.  No
serious application is well served by Visual Basic.  VB programmers tend
to treat it like a hammer, and every problem starts to look like a nail.
They can rarely tolerate the concept that some languages are better for
some applications than others.

>
> What, pray tell, are you strongly un-recommending?
> (I like search engines.  Only one page showed up under "Malrekomendegi!")
>
I ran across the esperanto website a while back, and thought the word
sounded funny, so in my .sig it went.


---
Paul Anderson - Self-employed Megalomaniac
spamBeGonepaulspam_OUTspamRemoveMEgeeky1.ebtech.net
http://zephyr.sellad.on.ca/~paul
"What are you doing?!  You run like a demented duck."

More... (looser matching)
- Last day of these posts
- In 2000 , 2001 only
- Today
- New search...