| View previous topic :: View next topic |
| Author |
Message |
KOWA
Joined: 24 Mar 2019
Posts: 3
|
| auto memory allocation and overwrite disable |
 Posted: Sun Mar 24, 2019 8:02 am |
 |
|
Hi
I'm trying to disable the overwrite memory allocation of the compiler.
I mean if there is 2 different variables in 2 different functions
the compiler will give them 2 different addresses.
(and not will overwrite the same address).
I'm using CCS 5.078 with DSPIC33FJ64GS608.
Thanks for the help.
Last edited by KOWA on Sun Mar 24, 2019 8:05 am; edited 1 time in total |
|
 |
Ttelmah
Joined: 11 Mar 2010
Posts: 19258
|
|
| Posted: Sun Mar 24, 2019 8:05 am |
|
|
Just declare them as static.
A static variable is always given it's own RAM. |
|
|
KOWA
Joined: 24 Mar 2019
Posts: 3
|
|
| Posted: Sun Mar 24, 2019 8:10 am |
|
|
Hi Ttelmah,
thanks for the fast respond.
do you know if is threre another solution?
i still what to use variables that are local to each function |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19258
|
|
| Posted: Sun Mar 24, 2019 8:12 am |
|
|
A static variable declared locally is still local. Not global.
Don't confuse with global declaration (which also reserves memory
uniquely). |
|
|
KOWA
Joined: 24 Mar 2019
Posts: 3
|
|
| Posted: Sun Mar 24, 2019 8:18 am |
|
|
i tried to do like you said
void func ( static int8 var , static int16 var2){
///////
}
the code don't pass compilation |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19258
|
|
| Posted: Sun Mar 24, 2019 8:30 am |
|
|
Of course that won't....
Those are not variable declarations. Those are arguments. Things being passed to the function. These don't control memory allocation.
| Code: |
void func1 ( int8 var , int16 var2)
{
static int16 local; //this has unique RAM
}
void func ( int8 var , int16 var2)
{
static int16 local; //this too has unique RAM
}
|
Arguments don't control memory allocation, they tell the function
what it is going to receive. |
|
|
jeremiah
Joined: 20 Jul 2010
Posts: 1320
|
|
| Posted: Sun Mar 24, 2019 11:21 am |
|
|
I asked CCS about this and there is a compiler directive to do this, but it did not work the last time I checked (a few years ago now). I would ask that you email them a request for this to work. The more people that need it that ask, the more likely they are gonna fix it.
The option was #SEPARATE STDCALL
Take a look at it in the manual
it will use a combination of working registers and the stack to create local versions of the parameters. However it didn't work back when I tried it years ago. You might still need static for local variables as Ttelmah suggests because the documentation suggests this directive only affects the function parameters and may not change how local variables are handled.
So TLDR: Tryout #SEPARATE STDCALL and see if it works. If it does report back here so we know. If it doesn't, email support@ccsinfo.com with the bug. Hopefully they will fix it if it isn't working. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19258
|
|
| Posted: Sun Mar 24, 2019 12:00 pm |
|
|
If you read what he is asking it is simply to have separate RAM for
local variables. Static does that fine without needing anything else,
provided he uses it where he declares the variables. |
|
|
jeremiah
Joined: 20 Jul 2010
Posts: 1320
|
|
| Posted: Sun Mar 24, 2019 1:06 pm |
|
|
| Ttelmah wrote: | If you read what he is asking it is simply to have separate RAM for
local variables. Static does that fine without needing anything else,
provided he uses it where he declares the variables. |
His example later on addressed function parameters. Hence my earlier post.
In fact if you read the remainder of my previous post, I addressed local variables and even referenced your earlier response. |
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9134
Location: Greensville,Ontario
|
|
| Posted: Sun Mar 24, 2019 1:09 pm |
|
|
If he has enough RAM, could he just declare ALL variables as 'global' ? That should make the compiler not 'reuse' any RAM location for other purposes ??
Jay |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19258
|
|
| Posted: Sun Mar 24, 2019 1:25 pm |
|
|
He wants local names.
You are right that what he posted later shows him trying to affect
the arguments rather than variables. If this is what he is worried about
then your comments do apply. However 'why'?. On most proc\essors
variables handed 'to'functions would be done on the stack. On the PIC
since it doesn't have a variable stack it is instead done via a temporary
storage area, but reuse of this would only normally matter for some
form of debugging. Otherwise reuse is a vital way of not wasting memory
for what is after all temporary storage.... |
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9134
Location: Greensville,Ontario
|
|
| Posted: Sun Mar 24, 2019 1:29 pm |
|
|
| hmm I read it the other way...sigh... |
|
|
jeremiah
Joined: 20 Jul 2010
Posts: 1320
|
|
| Posted: Sun Mar 24, 2019 2:39 pm |
|
|
| Ttelmah wrote: | He wants local names.
However 'why'?.
|
I don't know the reason why or if the OP simply got confused (may very well just be that). There are actual reasons to do so (I had one when I asked) as there are certain things you cannot do when variables are mapped to specific locations instead of the more traditional stack based parameter and local variable construction.
I don't usually get too hung up on the why when people ask questions unless the question is too broad or I want to know how to present the potential solution(s). Knowing how I learn, it is extremely frustrating when I ask a question and instead of someone answering it, they try to solve my problem for me by changing the methodology (actually doesn't happen here, but other places it does). As such, if the question is directed enough and I have something to add or correct, I try to just answer it directly if possible, often added my suggestions or handling of the why potentially at the end as an option for the person. That way they get both what they asked for and also extra if they want it.
That's why I am not too worried that I only addressed the function parameter portion. You already covered local variables. I was just adding on extra based on how the OP rephrased the question in a later post.
| Ttelmah wrote: |
Otherwise reuse is a vital way of not wasting memory
for what is after all temporary storage.... |
Completely agree, and in our own benchmarks it was also faster than the more traditional way Microchip used in xc16. Additionally, for more safety minded projects, the variable allocation scheme is beautiful in that I can show that all of our variables are mapped and where. Makes certification tons easier for software based projects. That's why we use CCS for all of our projects. In the one case where I was asked to do something that required a different type of solution, I had to use a different compiler because it was impossible to do (with the constraints given) with the CCS compiler's normally superior calling convention and variable construction scheme. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19258
|
|
| Posted: Sun Mar 24, 2019 2:52 pm |
|
|
Yes.
I think I am right in that static will solve what he originally asked:
| Quote: |
I mean if there is 2 different variables in 2 different functions
the compiler will give them 2 different addresses.
(and not will overwrite the same address).
|
There is though an 'issue', that if you have a standard local variable declared (say) as
int16 v=1000;
This will be initialised to 1000 each time the function is called. With a
'static' declaration, this will only be initialised the first time the function
is called, so it becomes necessary for you to manually initialise any
variables yourself. |
|
|
jeremiah
Joined: 20 Jul 2010
Posts: 1320
|
|
| Posted: Sun Mar 24, 2019 3:08 pm |
|
|
The one thing that just a static variable won't fix though is if the OP wants two separate calls of the same function to have different copies of local variables in different locations (this was part of my original problem when I asked about STDCALL in addition to the parameters themselves). There aren't really any good solutions for that. I can give some ideas, but I didn't like where any of them led.
Again, I don't know for sure what the OP really wanted. They did say "different functions" but given the earlier terminology mixup, I don't know if they really mean different function calls or different actual functions. This is one of those cases where I would have liked a small compilable example with comments on what they wanted to do where so there was less guessing.
Maybe the OP can clarify.
Just extra stuff to consider. |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
