How to fix the local variables

http://www.keil.com/support/man/docs/c51/c51_le_absvarloc.htm

I don't want to use _at_ keyword.
My question is that when enter the RSA.c file it can use all the internal ram, as other file would'n run at this time. So how can I set the Keil to make the RSA.c file can use all the IRAM ?

"I don't want to use _at_ keyword."

So why didn't you say that in the first place?
The more information you provide in your question, the more likely you are to get relevant and useful replies!

Your original post gave no indication that you had even considered the _at_ keyword, so that was the obvious answer based on the information provided.

"My question is that when enter the RSA.c file it can use all the internal ram, as other file would'n run at this time."

The Ovelraying should take care of this.

"So how can I set the Keil to make the RSA.c file can use all the IRAM ?"

That is, in fact, a completely different quesion to your original post!

Note that no file can use all the IRAM, since some will be required for the stack...

Yes, thanks your answer.
I am sorry that I didn't decribe my question very clearly.

Thanks again.

Now, I describe my question again. There are some code segments as follows:

/* main.c */
void main ()
{

        //Serial interrupt is open

        while (1)
        {
                schedule_task();
                Enter_Idle_Mode();
        }
}
/* main.c file is end */

/* app.c */
void cmd_process ()
{
        int local2;// the local vars are so many also.

        // ...
}

void serial_ISR () interrupt 4
{
        // 1. Receive Five Bytes APDU command
        cmd_process();// 2. command process
}

/* app.c file is end */

/* task.c */
void schedule ()
{
        int local;// the local vars are many.
        //...
}
/* task.c is end */

You will find that when schedule() is running, it will be interrupted by serial interrupt, but I don't want to use reentrant keyword for schedule function, as the reentrant stack isn't efficient.

So if I define the function schedule in the above code, the Keil will do overlay analysis and maybe the local variables of the schedule() function and app.c file are using the same ram space, and to resolve this question, I give some methods and maybe there will be a better way.

1. Store the local var of schedule() when entering serial_ISR(), and there is a new qustion that how can I know the local var's address of schedule() function?

2. Can we fix a block of ram to allocate the local variables of schedule(), and also when the task.c and app.c build, the app.c can reuse the ram that
allocated by schedule()?

Can you give some suggestion about the two ways above, or a new idea to give?
thanks very much.

I write the task.c in assemble code to resolve this problem, and now the local variable is just a address tag, like this:

Local_Var1 DATA 20H
...

so the keil will not do the overlay analyse.
Thanks all.

Keil will do overlay analysis and maybe the local variables of the schedule() function and app.c file are using the same ram space

No, they won't.

how can I know the local var's address of schedule() function?

You can't, but that's OK, since you don't need to known them.

the app.c can reuse the ram that allocated by schedule()?

If that's possible, the overlay analysis will find out all by itself. That's what it's there for.

You really ought to stop fighting the tools all the way. You're making your life miserable without any good need.

The OVERLAY linker directive allows you to edit the call tree to suit yourself. Of course, you'd better understand exactly what you're doing when using it!

I don't understand the reference to declaring schedule() reentrant. From the code shown, it's only called in one context anyway. ("schedule" hints that you're doing task switching, but I didn't see anything directly pointing out that there are preemptive tasks here. So, there's only two contexts/call trees: from main(), and from the ISR.)

You mention a few other functions and C files. I assume these are all routines called by schedule(). They will all overlay each other; none of them will overlay with the ISR tree. schedule() cannot share its local variables with a function that schedule() calls; that's two different levels of the same call tree. (If you really don't need schedule's locals after you call some sub-task, then you can move the work done in schedule to another subroutine, which will overlay the other tasks.)

If you're really sure the ISR cannot occur at the same time as other routines -- because, for instance, you mask the interrupts to prevent it -- then you might use the OVERLAY directive to overlay the ISR and main task memory. Note that the compiler will trust you, though, and if you slip on the mutual exclusion, you'll get weird bugs as your memory gets corrupted.