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.
I used to use the macro approach. The code was portable between C51 and x86 (where there was a similarish issue with near, far and huge pointers).
Code was ultimately ported to ARM with no issues.
typedef should work well too.
>>x86 (where there was a similarish issue with near, far and huge pointers).
Come from that place as well. Using 8051 boat anchors for increasingly complicated tasks is a battle I'm not interested in fighting when so many better solutions are available in the current marketplace. Pick a target that's inherently portable rather than one that has to be beaten at every turn. At some point the friction and inertia of working with the part has a diminishing return.
Using 8051 boat anchors for increasingly complicated tasks
I am, mainly an ARM user, however, since the above generalizes "boat anchor", I will rephrase the above since I still, occasionally, find cases where the '51 is the right choice.
for complicated tasks the 8051 is a boat anchor, but for may simpler tasks it may be the right choice.
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