>
>------
>BUG #1
>------
>
>void NW_SEND_STRING (byte *the_string) {
>    while ((the_char = *the_string) != 0) {
>        NW_SEND_CHAR(the_char);
>        the_string++;
>    }
>}
>
>This routine, when executed, consistently caused a stack overflow. I

>
>The code assembled as follows:
>
>0056                              void NW_SEND_STRING (byte *the_string) {
>0071 1283    BCF    03,5
>0072 00D6    MOVWF  56
>0073 0804    MOVF   04,W
>0074 00D7    MOVWF  57
>0075 287D    GOTO   007Dh             while ((the_char = *the_string) != 0) {
>0076 307F    MOVLW  7Fh
>0077 1283    BCF    03,5
>0078 0557    ANDWF  57,W
>0079 008A    MOVWF  0A
>007A 3001    MOVLW  01h
>007B 0756    ADDWF  56,W
>007C 0082    MOVWF  02
>007D 2076    CALL   0076h
>007E 1283    BCF    03,5
>007F 00D5    MOVWF  55
>0080 1903    BTFSC  03,2     <------------notice here
>0081 288A    GOTO   008Ah
>0082                                      NW_SEND_CHAR(the_char);
>0082 1283    BCF    03,5
>0083 0855    MOVF   55,W
>0084 2058    CALL   0058h
>0085 1283    BCF    03,5                  the_string++;
>0086 0AD6    INCF   56
>0087 1903    BTFSC  03,2
>0088 0AD7    INCF   57
>0089 2875    GOTO   0075h             }
>008A 0008    RETURN               }
>
>
>I flowcharted this code, and determined that the line I have highlighted

>
>006A                              void NW_SEND_STRING (byte *the_string) {
>0070 1283    BCF    03,5
>0071 00EA    MOVWF  6A
>0072 0804    MOVF   04,W
>0073 00EB    MOVWF  6B
>                                      do {
>0074 287C    GOTO   007Ch                 Char_Sent = *the_string;
>0075 307F    MOVLW  7Fh
>0076 1283    BCF    03,5
>0077 056B    ANDWF  6B,W         <-----the high byte
>0078 008A    MOVWF  0A
>0079 3001    MOVLW  01h          <-----observe here (adding one to...)
>007A 076A    ADDWF  6A,W         <-----observe here (...the low byte )
>007B 0082    MOVWF  02
>007C 2075    CALL   0075h
>007D 1283    BCF    03,5
>007E 00E8    MOVWF  68
>007F 08E8    MOVF   68                    if (Char_Sent != 0)

>                                                NW_SEND_CHAR(Char_Sent);
>0080 1903    BTFSC  03,2
>0081 2885    GOTO   0085h
>0082 1283    BCF    03,5
>0083 0868    MOVF   68,W
>0084 2057    CALL   0057h
>0085 1283    BCF    03,5                 the_string++;
>0086 0AEA    INCF   6A
>0087 1903    BTFSC  03,2
>0088 0AEB    INCF   6B
>                                      }
>0089 08E8    MOVF   68                while (Char_Sent != 0);
>008A 1D03    BTFSS  03,2
>008B 2874    GOTO   0074h
>008C 0008    RETURN               }
>
>Any comments welcome.
>
>Cheers,
>        Geoff.
>
>Geoff Cox                                 Manager - Discrete Products
>Eurotherm Controls Inc                           Phone (703) 471-4870
>11485 Sunset Hills Rd.                             Fax (703) 787-3447
>Reston, VA 22090               EMAIL Geoff.CoxKILLspamControls.Eurotherm.Com
>                                            HOME EMAIL .....PNJSKILLspam.....Nicom.Com
>
>[Do not] put too much confidence in experimental results until they have
>been confirmed by theory.---Sir Arthur Eddington
>

>
> At 02:24 PM 12/02/1997 -0500, you wrote:
> >I have been developing for the 16C65A for a few days now, and seem to
> already have uncovered 2 bugs with the MPLABC compiler (details below).
> >
> >I am using "V1.10 Released". Is this already known to be fairly buggy, and
> should I be using something else?
>
> I finally gave up on MPLABC after chasing those kinds of bugs and falling
> further and further behind on my project.  I switched over to MPC directly
> from Bytecraft and my bad code generation problems went away except for one.
> I duplicated the problem in a small test program and emailed it to
> Bytecraft. Walter Banks at Bytecraft emailed me a Rev C later that day that
> solved that problem.  Apparently that was the first bug found that actually
> prevented further work.
>
> So,  yes,  I am a satisfied customer but I did have to work around compiler
> inconsistancies.  For example:
>
> pHexChar = &NetMsg.Parameters.PARAMDATA[bufindex];
>
> generates invalid code - First it makes the correct indexed pointer and then
> promptly writes over it with the wrong value.
>
> The work-around is:
>
> pHexChar = &NetMsg.Parameters.PARAMDATA[0]+bufindex;
> and generates one extra instruction.
>
> Note that the manual states that the above C statement that failed is not
> supported so to give credit where credit is due, I was breaking the rules.
> <sigh>