Keil Logo Arm Logo

#pragma REGISTERBANK(x) and AREGS/NOAREGS directivs

Next Thread | Thread List | Previous Thread Start a Thread | Settings

Details Message
Read-Only
Author
Amit Alon
Posted
23-Feb-2005 10:01 GMT
Toolset
C51
New! #pragma REGISTERBANK(x) and AREGS/NOAREGS directivs
Hello,
I would like to get more specific information regarding the use of #pragma REGISTERBANK(x) and AREGS/NOAREGS directivs.

Assuming the following code:

void UartIsr(void) INTERRUPT(4) USING(2)
{
   f1();
}

#pragma REGISTERBANK(2) // (mark #0)
void f1(void)
{
   …
   …
   f2();
   …
   …
}
#pragma REGISTERBANK(0) // (mark #1)
...
...
...
#pragma REGISTERBANK(2) // (mark #2)
void f2(void)
{
   …
   f3();
   …
   …
}
#pragma REGISTERBANK(0) // (mark #3)

...
...
...

#pragma REGISTERBANK(2) // (mark #4)
void f3(void)
{
   …
   …
   …
}
#pragma REGISTERBANK(0) // (mark #5)

...
...
...


1) I know that the line with the remrk (//mark #1) is vital for the proper execution of the code. I don't know whether the lines with remrks mark#1-5 are essential (or will the compiler know that they should inherit the registerbank from the calling function?). Please answer for each code mark separately.
please assume that all functions will be called ONLY from the showed code, and not from any other function that may call them using diffrent register bank.

2) Scenario 2: Please assume that each line that contains the pragma directive "REGISTERBANK(2)" will be replaced with "NOAREGS", and ecah line that contains the pragma directive "REGISTERBANK(0)" will be replaced with "AREGS", and re-answer question #1.

3) Scenario 3: Using the code above, please assume that function f3 CAN be called from another place that use registerbank 0 (the main application). in this case should the code of f3 be as folows:

#pragma NOAREGS // (mark #6)
void f3(void)
{
   …
   …
   …
}
#pragma AREGS // (mark #7)
? in such a case, which line with remarks should be left as they are and which shouldn't ?


Regards,
Amit Alon.
Read-Only
Author
Amit Alon
Posted
23-Feb-2005 10:10 GMT
Toolset
C51
New! RE: #pragma REGISTERBANK(x) and AREGS/NOAREGS directivs
4) What should I do in case that f3 is a library function like sizeof, or printf, for example ?
the problems are:
(A)it is called from diffrent loactions in the code using diffrent register banks.
and
(B) I don't know how to tell such a function to use a specific register bank or to be compiled using the NOAREGS pragma.
Read-Only
Author
Stefan Duncanson
Posted
23-Feb-2005 13:44 GMT
Toolset
C51
New! RE: #pragma REGISTERBANK(x) and AREGS/NOAREGS directivs
sizeof is not a library function, it is an operator.

Why are you trying to muck about with register banks like this?
Read-Only
Author
Amit Alon
Posted
23-Feb-2005 14:15 GMT
Toolset
C51
New! RE: #pragma REGISTERBANK(x) and AREGS/NOAREGS directivs
The interrupt uses diffrent register bank then the one that the main program uses.
I am not sure about if I correctly understood your question: Do you know any better way to do what I does ? I will be happy to learn from you !

p.s.
In addition to the sizeof and printf functions, there is also a use in casting, which after compilation creates code that call some of the compier's casting functions. I put these functions too under the same question (#4) that I asked before.
Read-Only
Author
erik malund
Posted
23-Feb-2005 15:02 GMT
Toolset
C51
New! RE: #pragma REGISTERBANK(x) and AREGS/NOAREGS directivs
library function like sizeof, or printf, ... it is called from diffrent loactions in the code using diffrent register banks. You can forget about the questions you ask until you get clear in your head the calling such functions (or other lenghty stuff) in an ISR will lead to disaster.

The "automatic" compiler functions (address finders, switch porocessor and such) are bank independent. They must be since you "do not know" they are used.

Erik

Next Thread | Thread List | Previous Thread Start a Thread | Settings

Keil logo

Arm logo
Important information

This site uses cookies to store information on your computer. By continuing to use our site, you consent to our cookies.