Is there a way to make the C51 compiler use xdata memory-specific pointers as the default instead of generic pointers?
C source code that could otherwise be portable to other platforms has to have xdata keywords sprinkled all over the place. Thereby making the source code no longer portable.
Assume the following example code:
// Forward reference typedef struct request_block req_t; // A hypothetical request block struct request_block { int cmd; int parm1; int parm2; int result; req_t* next; }; void add_request(req_t* new_request);
The above code is very portable, but results in generic pointers which is too costly in terms of code space. I really need to use memory-specific pointers.
To be sure I can do the following with macros to solve the portability issue, but I still need to sprinkle my macros everywhere. In fact this is the solution I am currently using, but it is a pain.
#ifdef __C51__ # define XDATA xdata #else # define XDATA #endif // Forward reference typedef struct request_block req_t; // A hypothetical request block struct request_block { int cmd; int parm1; int parm2; int result; req_t XDATA* next; }; void add_request(req_t XDATA* new_request);
If I could specify a compiler pragma or even better a compiler option switch that told the C51 compiler to use "xdata" as the default for all naked pointer declarations then I could use my original example without any xdata keywords or macros sprinkled all over the place. BTW, my example only shows one pointer type being declared. Imagine this issue duplicated to dozens of other pointer types and I think you will see why I consider this macro solution a real pain.
I realize I would be giving up access to any Keil provided function that uses generic pointers, but that is not an issue for me since I am implementing all the supporting functions myself.
Even more awesome would be a "generic" keyword along with the compiler option to pick the default pointer type for naked pointer declarations and use the "generic" keyword when needed to explicitly choose generic pointer types.
Unfortunately I don't get to pick the hardware. The chips we use are for very cost sensitive products. Since the chip vendors get to use an 8051 core for free (or basically for free) it keeps their costs down which in turn makes us keep picking them: bottom-line dont-cha-know.
But in less cost sensitive products there is more freedom for more capable MCUs and I would like to share as much code as possible.
Since the chip vendors get to use an 8051 core for free (or basically for free) good point, several "specific function chips with mcu) has appeared using the '51 core