Hello all,

Sorry if this is a repeat post - not sure if the other posting was
successful (I think it failed).

'5509A with all code, data stacks etc in on-chip memory. Most of the
app is written in C with some smallish assembler.

The code snippet below shows a call to a function taking a 16 bit
value and returning a Uint32. Return value is being wiped out before
being assigned to the (Local) variable.  The "MOV T0, AC0" seems to be
simply wrong.

;----------------------------------------------------------------------
; 3489 | clstSize = FAT_cluster_size(retVal);                        
          
;----------------------------------------------------------------------
        MOV *SP(#1), T0 ; |3489| 
        CALL #_FAT_cluster_size ; |3489| 
                                        ; call occurs
[#_FAT_cluster_size] ; |3489| 
        MOV T0, AC0
        MOV AC0, dbl(*SP(#22)) ; |3489| 

Any ideas why?  Is there some compiler option that could do this?  Is
this fixed in more recent compiler?

Thanks,
Ian

Ian-

> Sorry if this is a repeat post - not sure if the other posting was
> successful (I think it failed).
>
> '5509A with all code, data stacks etc in on-chip memory. Most of the
> app is written in C with some smallish assembler.
>
> The code snippet below shows a call to a function taking a 16 bit
> value and returning a Uint32. Return value is being wiped out before
> being assigned to the (Local) variable.  The "MOV T0, AC0" seems to be
> simply wrong.
>
> ;----------------------------------------------------------------------
> ; 3489 | clstSize = FAT_cluster_size(retVal);
>
> ;----------------------------------------------------------------------
>         MOV *SP(#1), T0 ; |3489|
>         CALL #_FAT_cluster_size ; |3489|
>                                         ; call occurs
> [#_FAT_cluster_size] ; |3489|
>         MOV T0, AC0
>         MOV AC0, dbl(*SP(#22)) ; |3489|
>
> Any ideas why?  Is there some compiler option that could do this?  Is
> this fixed in more recent compiler?

Where's the corresponding C code?  Maybe the return variable isn't used or is otherwise
optimized out.

After tens of thousands of users and 10+ years, the chances of a bug in CCS when calling
functions are microscopic, as
you might guess.

-Jeff

Ian-

> Thanks for your reply.  The C-code was in the commented line above (I
> gave a snippet from the LST file.)

No, I mean the actual C code.  You only showed "commented C code" copied and printed
by the assembler.  People on the group need to see *your* code to give useful
suggestions.  I was trying to see what happens after the function call, for example
if the return value wasn't used.

> I found the problem - the function FAT_cluster_size had no prototype
> so compiler was assuming return value of int rather than the correct
> value of Uint32.  Making a prototype accessible to the file fixed the
> problem.

Somehow I'm not surprised it's not a CCS bug :-)

> Digging into the build options showed that an "implicit declaration"
> warning can be turned on (and now is for this project) (should be the
> default IMO).
> 
> I am still struggling to see how the "MOV T0, AC0" statement could be
> correct though?  It means that the effective return for the
> FAT_cluster_size function is the retVal parameter that was passed in.

Not sure, but the CCS C6x and C5x compilers are fairly smart.  The name of the game
in DSP is speed, so the TI code generation tools have a long history of finding ways
to shave cycles here and there.  Many times a code generation and debug weirdnesses
turn out to be side-effects of some type of optimization.

> Still problem fixed.

Ok, good work.

-Jeff

PS. Please post to the group, not to me.

Hello all,
>
>Sorry if this is a repeat post - not sure if the other posting was
>successful (I think it failed).
>
>'5509A with all code, data stacks etc in on-chip memory. Most of the
>app is written in C with some smallish assembler.
>
>The code snippet below shows a call to a function taking a 16 bit
>value and returning a Uint32. Return value is being wiped out before
>being assigned to the (Local) variable.  The "MOV T0, AC0" seems to be
>simply wrong.
>
>;----------------------------------------------------------------------
>; 3489 | clstSize = FAT_cluster_size(retVal);                        
>          
>;----------------------------------------------------------------------
>        MOV *SP(#1), T0 ; |3489| 
>        CALL #_FAT_cluster_size ; |3489| 
>                                        ; call occurs
>[#_FAT_cluster_size] ; |3489| 
>        MOV T0, AC0
>        MOV AC0, dbl(*SP(#22)) ; |3489| 
>
>Any ideas why?  Is there some compiler option that could do this?  Is
>this fixed in more recent compiler?
>

I had the same problem. My function was in another file and I didn't define it external. I
don't know why linker didn't give any error or warning. I could even run it with debugger.

external Uint32 _FAT_cluster_size(Uint16);

> Subject: Re: CCS3.1.0 return value from function trashed before being assigned
> Posted by: "joeblogss84" j...@yahoo.com.au joeblogss84
> Date: Mon Jul 2, 2007 8:09 am ((PDT))
>
> I found the problem - the function FAT_cluster_size had no prototype
> so compiler was assuming return value of int rather than the correct
> value of Uint32.  Making a prototype accessible to the file fixed the
> problem.

I have seen this subject arises every now and then, it seem to be in the
top ten in the chart :)

I think that if the default action of the compiler had been to issue a
regular warning instead of a remark (by default, remarks are not printed,
they could be turned on by -pdr option) when there is no function declaration,
the stream of posts on the current subject would have been much more shallow...

Yes, by default, in C a function with no declaration is assumed to return an 
int; but somehow it contradicts to more general rule to declare every object
before its use. If a variable is used before being declared - this makes
the compiler to issue an error :)

Cheers,

Andrew