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.
C51 v6.03+; uVision v2.07+ I want to build a Project with some files using the SMALL model, but most using LARGE. If I select LARGE in the Target options, and specify SMALL in the C51 'Misc Controls' where required, or use a #pragma in the file itself, I get a fatal Compiler error:
RESPECIFIED OR CONFLICTING CONTROL
L14: INCOMPATIBLE MEMORY MODEL
The problem is this: If you have a file (compiled in SMALL memory model) and another file (compiled in LARGE memory model) and both files call the printf library routine...which printf routine is included from the library? The LARGE model printf or the SMALL model printf? The answer is that this is an error condition. The memory model applies to the WHOLE program. It specifies not only the default variables space for YOUR functions but also the default variable space for the LIBRARY routines. When you create a program, you may specify the memory model on a function-by-function basis. For example:
int my_func (int a, int b, int c) large
So if I don't use any (Keil) Library functions, or if I'm careful to make sure they're all the same model, I should be OK? Is it possible to specify explicitly which Library the Linker should use? If I had:
#pragma LARGE : int my_func (int a, int b, int c) small
Could you also explain what the differences between the models available are, or do they ONLY change the default memory type? For example, what causes the stack efficiency in the large model to be worse than small?( P88 , C51 Compiler)
That's talking about the reentrant stack; not the 8032 CPU stack. The "reentrant stack" is a simulated stack created by Keil to support reentrant functions, due to the limitations of the 8032 CPU stack. The reentrant stack is used for parameters and locals; the 8032 CPU stack is still used for the return address (p97) Keil simulates the small reentrant stack in idata, the compact reentrant stack in pdata and the large reentrant stack in xdata - see p96. The large/compact reentrant stacks are less efficient because they're in xdata/pdata.
> Keil simulates the small reentrant stack in idata, > the compact reentrant stack in pdata and the > large reentrant stack in xdata - see p96. > The large/compact reentrant stacks are less efficient > because they're in xdata/pdata. You conclude that reentrant stack in idata more preferrable ? So, could you explain me which sense to simulate reentrant stack in idata ? Instead of simulated reentrant stack in idata can be used efficient native hardware stack (via SP and PUSH/POP instructions). Which sense in simulation ?
So if I don't use any (Keil) Library functions, or if I'm careful to make sure they're all the same model, I should be OK? Yep, but I haven't tested this. Is it possible to specify explicitly which Library the Linker should use? If I had: #pragma LARGE : int my_func (int a, int b, int c) small would that call 'large' model libraries? Yep. Jon
Could you also explain what the differences between the models available are, or do they ONLY change the default memory type? The memory model only affects the DEFAULT place where variables, function arguments, and local vars are stored. For example, what causes the stack efficiency in the large model to be worse than small?( P88 , C51 Compiler) This reference is to the reentrant stack. It is more efficient in SMALL model because the reentrant stack is stored in IDATA rather than XDATA. Jon