• State Not Answered
  • Locked Locked
  • Replies 11 replies
  • Subscribers 21 subscribers
  • Views 2335 views
  • Users 0 members are here
2025 survey

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.

Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Mixed Memory Models

Andrew Neil

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

If I select SMALL in the Target options, and specify LARGE in the C51 'Misc Controls' box where required, everything Compiles OK, but I get Linker warnings for each of the 'Large' Modules:
L14: INCOMPATIBLE MEMORY MODEL

If I specify 'large' in each function declaration where required, it all Compiles and Links OK!

Thus it is possible to create a mixed-model Project, but extremely cumbersome to have to specify the model on every function!
Why doesn't it work when the model is specified at the module level?

(yes, I know you wouldn't want to design a Project like this from scratch, but this is "inherited" stuff...)

Parents
  • 0 in reply to Andrew Neil

    > 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 ?

Reply
  • 0 in reply to Andrew Neil

    > 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 ?

Children
No data