Just a couple of comments and a question regarding the current "C-Compiler"
debate.

>But - the sentence - 'fix it by tomorrow' - is what worries me!  Haven't
>you ever fixed one bug in your s/w - only to find it causes another?  Take
>another day and test it for interactions guys.
>
>> Remember, C is not new and these compilers are a few years old. There
>> really is no excuse.
>>
>
>Windows is a few years old, and is, of course, bug free.  Windows is
>written by an organisation with programmers numbered in  the 1000's  CCS
>has 1, so the codebase size comparison is reasonable.

Mike, I'm not sure if you're being facetious by this comment.

I've always thought that the best code was written by one or two people and
not the thousands (what does that say about Windows...).  A small team is
more aware of interactions (and is therefore able to avoid them).

Such things as UNIX, Motif, and VisiCalc are examples of ground breaking
software that was written by a small team or one person.

This, of course, is no excuse for not thoroughly testing software in a
logical/structured manner.  It also means that if there are few authors
involved in the development of a piece of software are locked into what I
call "the life and death relationship of software support" (ie you're
supporting it until you die).


Is anybody looking at Java for the PIC (or other microcontrollers)?  The
more I look at compilers for (embedded) microcontrollers, the more it seems
like the "C" way of handling data is not that appropriate (ie pointers are
not that valuable/appropriate, take up too much space, and don't really have
built-in processor hardware that would make them more efficient).  Java's
methods of handling data seem to be more appropriate and will result in more
efficient assembly/object code.


Lastly, how do the various compilers handle negative numbers?  This question
originally comes from a comment Andy Warren made a number of months ago
regarding how the PIC doesn't really handle negative numbers.

Well, I spent a few hours a couple of nights ago playing with the Basic
Stamp 1 and I see what he means.  A two's complement "negative" number isn't
necessarily a negative number (especially in the Stamp).

For example, say you were going to add -5 (which is defined as an 8 bit
byte) by 7 (which is defined as a 16 bit word) and put the result in a 16
bit word; what would your answer be?

The Stamp converts all parameters to sixteen bit values before executing an
arithmetic opertor.

So, -5 is actually 0x0FB (or $FB in PBASIC Speak), which is treated as
0x000FB when the add operator code is called.

The result is 0x0102 ($102) and not 2 as logic would dictate.

Now, in my trusty Microsoft "C" Compiler on my PC, this can be done
(defining the variables as "char" and "int) and the answer "2" will be
produced.  But as I look at the code, a "CBW" (Convert Byte Word)
instruction, which converts a byte (half register) into a signed word
(sixteen bits or full register), is executed before the addition takes place.

What do the PIC C Compilers do and is this where people have been saying you
have to look at the actual output code to make sure issues like this are
avoided?

myke

"Aliens are really just the same as us, only their molecules are different"
- Will Robinson