We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
We have a library called 834keil.lib. This library seems to like being linked under the small memory model. There is an associated header file containing two globals with the data attribute. Removing the data attribute yields an error. We are compiling under the small memory model now and giving our globals an xdata attribute as a work-around.
I guess the question is- Why do we have to use the small memory model to compile the project when we use this library?
Removing the data attribute yields an error Why do we have to use the small memory model to compile the project In the small memory model, the default memory location for globals is in the "data" space. Under the large memory model, the default is in xdata. If you compile with the large model, and there is an explicit memory type qualifer on these variables, they'll go in that space. The "data" attribute places them in the internal RAM; removing it moves the variables to external RAM. If you switch to the small model, then the variables will be in internal RAM without an explicit qualifer. (One case you didn't mention would be if you compile under small, and explicitly declare these globals "xdata". The hypothesis would be that the code will break in that case.) So, the question comes down to some details about these particular variables and their usage. Why do they have to be in internal RAM for the program to work? Does someone else use an explicit data* to point to them? Are the globals shared with some other code that will be dismayed if they move? More obscure possibilities spring to mind: Is speed a factor? Can you actually access xdata at the points in the code where these variables are used? Exactly what sort of failure do you get?
I guess the question is- Why do we have to use the small memory model to compile the project when we use this library? The first answer I have is...Because the library was generated for the SMALL memory model. The second answer I have is...You don't. If you want to use the functions in the library from a LARGE model program, you will need to change the prototypes for the functions in the library. In the .H file for the library, make the following change for all prototypes for functions in the library: Change...
int function (int a, int b, int c);
int function (int a, int b, int c) small;
"In the small memory model, the default memory location for globals is in the 'data' space" To be more precise, the Memory Model defines the default memory space for everything - locals, globals, parameters, etc... If you mix memory models, the different parts of your code will be making different assumptions about the locations of all these things - that way lies disaster!! It's like the two old ladies shouting across the street - they could never reach an agreement, because they were arguing from different premises! ;-)