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.
Hi,all
I have succeeded in runing ucos (v2.52) in the keil simulator environment, and still confused about the reentrant functions though I searched it here. reentrant stack is also called simulator stack,right? My OS is xp sp2. Keil is C51.EXE V8.06 My project is complied in large mode.
And the quetions are:
1, Does every reentrant function have Its own reentrant stack? Are there the same number of ?C_XBP as the reentrant functions.
2, For all the reentrant functions, Arguments and local variable are stored in the simulator stack,right? If all the functions in my project are reentrant. is there no hardware stack wanted? if not what is it for?
3,How can I know each or the total simulator stack size ?Can I get it from the map file? or other ways.
Thanks
The different reentrant functions doesn't have their own pre-allocated stack areas. When a reentrant function is called, it will crow the software stack from it's current position. When it returns, it will release this space, so a completely different reentrant function may use the same space.
If two reentrant functions are called at the same time - or one reentrant function is recursively called, the sw stack will contain the data for all these calls - in the orther that they where called. They will always have to end in the reverse order, so when they return, the stack will shrink correspondingly.
Per Westermark The different reentrant functions doesn't have their own pre-allocated stack areas. When a reentrant function is called, it will crow the software stack from it's current position. When it returns, it will release this space, so a completely different reentrant function may use the same space.
Hi,thanks very much!
I think I made a mistake. The reentrant stack belongs to the call-chain, not to a single function. right?
And, In my project with ucos(v2.52) as the os in large mode. For the concept of mutiple tasks, There will never be a chance for "return". Then all the reentrant functions including the reentrant task should share the same simulator stack (0x7ffff~~)? That's why It only save the hardware stack and the ?C_XBP when context switch ocurred. When It's one task's turn again, It restore the ?C_XBP from the user stack, Then every things go well.
If There's some things wrong pls let me know. Thanks all you kind-heart guys!
When running with a preemptive OS, the different tasks need individual stacks, since one task can be preempted in the middle of a call chain.
When running without a OS, individual calls to reentrant functions will just add stack frames on the stack - each popped when the function returns.
Which is why the architecture of the '51 does not in any way lend itself to the use of an OS. If you believe (for a '51 project is must be 'belief' not 'fact') you need an OS, switch to a processor capable of running an OS without jumping through hoops. Today, you can get an ARM for much less than "an arm and a leg" - sorry, could not help that one - less than $5 so, if you have a legitimate NEED for an OS switch to the ARM.
In the olden days, when the king of diamonds were still just a jack, the price differential between a '51 and something else was so dramatic that jumping through hoops to 'make do' with a '51 might have been justified, but today, use the wonderful '51 for what it is wonderful at which is NOT running an OS.
Erik
The software stack for reentrant functions works just like you would expect a "normal" stack for "normal" C to work. That is, there's a stack pointer, and values get pushed and popped on the stack as the call chain goes up and down. It's only called a "software stack" or "simulated stack" because the 8051 doesn't have much in the way of pointer registers, and Keil wants a clear distinction between this stack and the "hardware" stack that uses the SP register. The stack pointer is a variable, not a register, which means there's more code to manipulate that pointer than is usual with other architectures.
Different memory models change the names slightly.
As was mentioned, every task will need its own stack (as is usual with a preemptive OS). The task-switching code for your OS will need to be aware of the software stack implementation, and will have to store ?C_XBP in the task control block and change it out on task switches as it does with all the other registers. Since the stack implementation is unique to Keil, your uCOS code may or may not already have support for this. (Someone may have done the Keil-specific port already; if not, you get to learn about the internals of the uCOS kernal.)
Thanks all you guys!
I think it's very clearly about this point. you all gave me a great help. thanks.
About the OS and C51,I start a new topic about this, http://www.keil.com/forum/docs/thread10068.asp#msg47684. It's "Why It is not recommended porting a OS to C51?", if you have some idea and It's convenient for you,pls, Do me a favor to let me know, I'll greatly appreciate it.