Some of my values declaration are showing been compiled as pointers

I spend sometime this morning further analyzing this issue and it seems that it's a problem on the debugger/ccstudio.
I followed the code step by step and it is doing the correct math.
Below is a better description of what is happening. 

On the 0.333ms timer loop I have the following declaration:

static long double period = TIMER2_PERIOD / 1000000.0; // TIMERx_PERIOD is in uSeconds

and it pass 'period' value to this function:

long double exPID(struct exPID_struct *me, struct analogue_struct *PV, long double period)

called in:

result = exPID(&pid1, &anal1, period) ;

when the debugger enters this function, its shown on the debug view as:

long double exPID(struct exPID_struct *, struct analogue_struct *, long double period *)() at exPID.c

saying that the long double period is a pointer; and in the variable views show period as:

period long double * 0x00010004 Register XAR6
*(period) long double 0.3045775894597357 0x010004@Data

meaning it is located in the register XAR6 and through the code execution I saw it changing both the value it's pointing to and the value itself, even thou I never directly change 'period'.

As I said, it seems that it's a debugger/ccstudio bug but I would like to hear from a TI personnel what's up with that?

It's a concerto MCU on the C28 core.
Compiler Version: v6.02
Runtime support: rts2800_fpu32.lib 
Floating point support: fpu32
Optimization level: 0
Debug options:  Full symbolic debug

The debugger/disassembler might not be able to tell the difference between the compiler's having invented a pointer for this purpose and the user having explicitly specified a pointer parameter in the first place.

Archaeologist,

Thanks for the info, I guess it does answer it, I thought there could be something on the compiler or linker properties to do with it.

I guess the main answer is answered as "that's the way it works and the debugger have to be re-worked/fixed by TI"

But just as discussion:

Even thou I understand the reason the compiler does it (save heap memory on too many parameters passing, speed up the function call), wouldn't that be potentially be creating a risky situation?

I mean, imagine I define a function(long double val, int i) and inside this function the math is actively changing val as part of the computational process. And this function is called in a code like:

long double myVal = 20.0;

for(int i=0;i<10;i++){
    function(myVal, i);
}

This code means that for each call, I still want value to be 20, the fact that the function changes the value inside as part of its algorithmic is irrelevant.
Any ideas? 

Ronaldo Pace said:

wouldn't that be potentially be creating a risky situation?

No, because the called function is responsible for making a copy if necessary.  This is all supposed to be transparent to the user.  Even though the TI compiler uses a pointer "under the hood", the pass-by-value semantics of the source code remain intact.

The lack of documentation for the fact that "long double" values are passed using a pointer is now being tracked as SDSCM00044398.

I do not know how the interface between debugger and the debugging information generated by the compiler is supposed to handle this detail, so I don't know if it's a bug or not.  Nonetheless, I've entered SDSCM00044401 to track that issue.

oh, got it.

The assembly pass it as a pointer but then "copies to a local variable" before carry on.
So actually there are 2 under-the-hood conversions happening there.

The real problem in the end is the lack of documentation and inability of the debugger to make the conversion before showing on the Debug/Variables/Expressions screen.

Thanks!

It could be the case that the debugger simply does not have enough information to tell the difference between a compiler-generated pointer parameter and a user-specified pointer parameter, in which case there isn't any simple solution other than to just become accustomed to that linkage convention.

The advantage of the callee instead of the caller making the local copy is that it doesn't have to make the copy under certain circumstances (when the compiler can be sure that the called function does not modify the local copy, and the variable is not aliased to another reachable object).  There is an old Bell Labs technical report (by Johnson & Ritchie as I recall) discussing various methods of implementing C function calls, which remains relevant and is worth reading.