Sign in
Search rabbit-semi
Subscribe to rabbit-semi
Sponsor
Ads
Discussion Groups
See Also
Discussion Groups | Rabbit-Semi | poniter to far
This is a group for folks designing and programming embedded systems using the Rabbit Semiconductor C-programmable microcontroller. Rabbit Semi is a spin-off from Z-World who makes a variety of embedded modules and tools. This group is not affiliated with either Rabbit or Z-World, but is a user forum for sharing ideas, asking questions, flaunting knowledge, and other typical user group stuff. The Rabbit is a powerful uC, supported by a full-featured C-compiler.
poniter to far - mfawzy79 - Jun 3 15:55:10 2009
Hi all,
what is happen if i passed near pointer to a function that should receive far pointer?, is it causing any problems with the stack?
Best Regards
M.Fawzy
------------------------------------
(You need to be a member of rabbit-semi -- send a blank email to rabbit-semi-subscribe@yahoogroups.com )
what is happen if i passed near pointer to a function that should receive far pointer?, is it causing any problems with the stack?
Best Regards
M.Fawzy
------------------------------------
(You need to be a member of rabbit-semi -- send a blank email to rabbit-semi-subscribe@yahoogroups.com )
Re: poniter to far - Tom Collins - Jun 5 18:38:51 2009
On Jun 3, 2009, at 5:01 AM, mfawzy79 wrote:
> what is happen if i passed near pointer to a function that should
> receive far pointer?, is it causing any problems with the stack?
Since the compiler knows that the function takes a far pointer, it
will automatically promote the near pointer to a far.
If it's an assembly function without a C prototype, then there will
be a problem. The compiler doesn't know what the assembly function
expects, so it can't set up the stack correctly.
Also note that the caller cleans up the stack after making the call,
so you don't have to worry about stack imbalance. The caller knows
how much it pushed onto the stack, so it knows how much to pop off.
-Tom
(You need to be a member of rabbit-semi -- send a blank email to rabbit-semi-subscribe@yahoogroups.com )
> what is happen if i passed near pointer to a function that should
> receive far pointer?, is it causing any problems with the stack?
Since the compiler knows that the function takes a far pointer, it
will automatically promote the near pointer to a far.
If it's an assembly function without a C prototype, then there will
be a problem. The compiler doesn't know what the assembly function
expects, so it can't set up the stack correctly.
Also note that the caller cleans up the stack after making the call,
so you don't have to worry about stack imbalance. The caller knows
how much it pushed onto the stack, so it knows how much to pop off.
-Tom
(You need to be a member of rabbit-semi -- send a blank email to rabbit-semi-subscribe@yahoogroups.com )
Re: poniter to far - Robert Richter - Jun 10 8:36:18 2009
--- In r...@yahoogroups.com, "mfawzy79" wrote:
>
> Hi all,
>
> what is happen if i passed near pointer to a function that should receive far pointer?, is it causing any problems with the stack?
>
> Best Regards
>
> M.Fawzy
>
The answer is not that simple, and yes, it can cause problems with the stack if you are stack juggling (uCOS-II). When a 16 bit near pointer is converted to a 32 bit far pointer, the high 16 bits are set to ones rather than converted to a physical address. When the pointer is dereferenced, if the 16 high bits are all ones, the Rabbit uses the logical address; otherwise, it uses the physical address. Under normal conditions, this isn't a problem. You mention stack, so I am asking, are you using uCOS-II or some other form of stack juggling multithreading? If so, pointers to the stack area cannot safely be converted and passed to another task, because the conversion doesn't actually convert to a physical address. In this case, use paddr_far to do the conversion so you do get a true conversion.
------------------------------------
(You need to be a member of rabbit-semi -- send a blank email to rabbit-semi-subscribe@yahoogroups.com )
>
> Hi all,
>
> what is happen if i passed near pointer to a function that should receive far pointer?, is it causing any problems with the stack?
>
> Best Regards
>
> M.Fawzy
>
The answer is not that simple, and yes, it can cause problems with the stack if you are stack juggling (uCOS-II). When a 16 bit near pointer is converted to a 32 bit far pointer, the high 16 bits are set to ones rather than converted to a physical address. When the pointer is dereferenced, if the 16 high bits are all ones, the Rabbit uses the logical address; otherwise, it uses the physical address. Under normal conditions, this isn't a problem. You mention stack, so I am asking, are you using uCOS-II or some other form of stack juggling multithreading? If so, pointers to the stack area cannot safely be converted and passed to another task, because the conversion doesn't actually convert to a physical address. In this case, use paddr_far to do the conversion so you do get a true conversion.
------------------------------------
(You need to be a member of rabbit-semi -- send a blank email to rabbit-semi-subscribe@yahoogroups.com )
Re: Re: poniter to far - Tom Collins - Jun 12 12:09:44 2009
On Jun 10, 2009, at 5:35 AM, Robert Richter wrote:
> --- In r...@yahoogroups.com, "mfawzy79"
> wrote:
> >
> > Hi all,
> >
> > what is happen if i passed near pointer to a function that should
> receive far pointer?, is it causing any problems with the stack?
> >
> > Best Regards
> >
> > M.Fawzy
> > The answer is not that simple, and yes, it can cause problems with
> the stack if you are stack juggling (uCOS-II). When a 16 bit near
> pointer is converted to a 32 bit far pointer, the high 16 bits are
> set to ones rather than converted to a physical address. When the
> pointer is dereferenced, if the 16 high bits are all ones, the
> Rabbit uses the logical address; otherwise, it uses the physical
> address. Under normal conditions, this isn't a problem. You mention
> stack, so I am asking, are you using uCOS-II or some other form of
> stack juggling multithreading? If so, pointers to the stack area
> cannot safely be converted and passed to another task, because the
> conversion doesn't actually convert to a physical address. In this
> case, use paddr_far to do the conversion so you do get a true
> conversion.
Note that the problem Robert describes isn't just limited to the near-
to-far upcast. When using uC/OS-II, if a pointer to one task's stack
will be referenced by another task, you need to use the function
Robert mentions to convert the logical address to a physical address.
One real-world example of this limitation cropping up is with sockets
and the TCP/IP stack. If you're using uC/OS-II and have multiple
tasks that call tcp_tick(), make sure that none of your sockets are
on the stack. Declare them as globals or static variables in your
functions.
-Tom
(You need to be a member of rabbit-semi -- send a blank email to rabbit-semi-subscribe@yahoogroups.com )
> --- In r...@yahoogroups.com, "mfawzy79"
> wrote:
> >
> > Hi all,
> >
> > what is happen if i passed near pointer to a function that should
> receive far pointer?, is it causing any problems with the stack?
> >
> > Best Regards
> >
> > M.Fawzy
> > The answer is not that simple, and yes, it can cause problems with
> the stack if you are stack juggling (uCOS-II). When a 16 bit near
> pointer is converted to a 32 bit far pointer, the high 16 bits are
> set to ones rather than converted to a physical address. When the
> pointer is dereferenced, if the 16 high bits are all ones, the
> Rabbit uses the logical address; otherwise, it uses the physical
> address. Under normal conditions, this isn't a problem. You mention
> stack, so I am asking, are you using uCOS-II or some other form of
> stack juggling multithreading? If so, pointers to the stack area
> cannot safely be converted and passed to another task, because the
> conversion doesn't actually convert to a physical address. In this
> case, use paddr_far to do the conversion so you do get a true
> conversion.
Note that the problem Robert describes isn't just limited to the near-
to-far upcast. When using uC/OS-II, if a pointer to one task's stack
will be referenced by another task, you need to use the function
Robert mentions to convert the logical address to a physical address.
One real-world example of this limitation cropping up is with sockets
and the TCP/IP stack. If you're using uC/OS-II and have multiple
tasks that call tcp_tick(), make sure that none of your sockets are
on the stack. Declare them as globals or static variables in your
functions.
-Tom
(You need to be a member of rabbit-semi -- send a blank email to rabbit-semi-subscribe@yahoogroups.com )
Re: poniter to far - mfawzy79 - Jun 14 7:19:46 2009
many thanx for you replies.
actually i'm using the ucos2 and i have more than task that are using different socket and all of my problems started with RST38 which does it mean "corruption into stack" so i was suspecting in passing the near pointer to the function that is receiving far pointer.
but your replies mean that if i'm passing the a near pointer to the function that is accepting far pointer in the same task, it won't be a problem.
Am I right?
Best Regards
MFawzy
--- In r...@yahoogroups.com, Tom Collins wrote:
>
> On Jun 10, 2009, at 5:35 AM, Robert Richter wrote:
> > --- In r...@yahoogroups.com, "mfawzy79"
> > wrote:
> > >
> > > Hi all,
> > >
> > > what is happen if i passed near pointer to a function that should
> > receive far pointer?, is it causing any problems with the stack?
> > >
> > > Best Regards
> > >
> > > M.Fawzy
> > >
> >
> > The answer is not that simple, and yes, it can cause problems with
> > the stack if you are stack juggling (uCOS-II). When a 16 bit near
> > pointer is converted to a 32 bit far pointer, the high 16 bits are
> > set to ones rather than converted to a physical address. When the
> > pointer is dereferenced, if the 16 high bits are all ones, the
> > Rabbit uses the logical address; otherwise, it uses the physical
> > address. Under normal conditions, this isn't a problem. You mention
> > stack, so I am asking, are you using uCOS-II or some other form of
> > stack juggling multithreading? If so, pointers to the stack area
> > cannot safely be converted and passed to another task, because the
> > conversion doesn't actually convert to a physical address. In this
> > case, use paddr_far to do the conversion so you do get a true
> > conversion.
>
> Note that the problem Robert describes isn't just limited to the near-
> to-far upcast. When using uC/OS-II, if a pointer to one task's stack
> will be referenced by another task, you need to use the function
> Robert mentions to convert the logical address to a physical address.
>
> One real-world example of this limitation cropping up is with sockets
> and the TCP/IP stack. If you're using uC/OS-II and have multiple
> tasks that call tcp_tick(), make sure that none of your sockets are
> on the stack. Declare them as globals or static variables in your
> functions.
>
> -Tom
>
------------------------------------
(You need to be a member of rabbit-semi -- send a blank email to rabbit-semi-subscribe@yahoogroups.com )
actually i'm using the ucos2 and i have more than task that are using different socket and all of my problems started with RST38 which does it mean "corruption into stack" so i was suspecting in passing the near pointer to the function that is receiving far pointer.
but your replies mean that if i'm passing the a near pointer to the function that is accepting far pointer in the same task, it won't be a problem.
Am I right?
Best Regards
MFawzy
--- In r...@yahoogroups.com, Tom Collins
>
> On Jun 10, 2009, at 5:35 AM, Robert Richter wrote:
> > --- In r...@yahoogroups.com, "mfawzy79"
> > wrote:
> > >
> > > Hi all,
> > >
> > > what is happen if i passed near pointer to a function that should
> > receive far pointer?, is it causing any problems with the stack?
> > >
> > > Best Regards
> > >
> > > M.Fawzy
> > >
> >
> > The answer is not that simple, and yes, it can cause problems with
> > the stack if you are stack juggling (uCOS-II). When a 16 bit near
> > pointer is converted to a 32 bit far pointer, the high 16 bits are
> > set to ones rather than converted to a physical address. When the
> > pointer is dereferenced, if the 16 high bits are all ones, the
> > Rabbit uses the logical address; otherwise, it uses the physical
> > address. Under normal conditions, this isn't a problem. You mention
> > stack, so I am asking, are you using uCOS-II or some other form of
> > stack juggling multithreading? If so, pointers to the stack area
> > cannot safely be converted and passed to another task, because the
> > conversion doesn't actually convert to a physical address. In this
> > case, use paddr_far to do the conversion so you do get a true
> > conversion.
>
> Note that the problem Robert describes isn't just limited to the near-
> to-far upcast. When using uC/OS-II, if a pointer to one task's stack
> will be referenced by another task, you need to use the function
> Robert mentions to convert the logical address to a physical address.
>
> One real-world example of this limitation cropping up is with sockets
> and the TCP/IP stack. If you're using uC/OS-II and have multiple
> tasks that call tcp_tick(), make sure that none of your sockets are
> on the stack. Declare them as globals or static variables in your
> functions.
>
> -Tom
>
------------------------------------
(You need to be a member of rabbit-semi -- send a blank email to rabbit-semi-subscribe@yahoogroups.com )
Re: poniter to far - Robert Richter - Jun 14 10:26:48 2009
--- In r...@yahoogroups.com, "mfawzy79" wrote:
>
> many thanx for you replies.
>
> actually i'm using the ucos2 and i have more than task that are using different socket and all of my problems started with RST38 which does it mean "corruption into stack" so i was suspecting in passing the near pointer to the function that is receiving far pointer.
The problem isn't near-to-far upcast, but near pointers to local variables or function parameters somehow making it to another thread. The near-to-far upcast is STILL a near pointer, unless you use paddr_far. One way for a near pointer to make it to another thread is to have TCP/IP calls in more than one thread and to put a socket on the stack. The TCP/IP library maintains a list of all active sockets, not knowing that some are in one thread, and some are in another. As Tom pointed out, make sure sockets are never on the stack.
> but your replies mean that if i'm passing the a near pointer to the function that is accepting far pointer in the same task, it won't be a problem.
Generally, but there may be other system libraries and circumstances other than TCP/IP where near pointers make it to another thread without you directly exchanging pointers. But things like string or memory copying will be OK.
>
> Am I right?
>
> Best Regards
> MFawzy
>
------------------------------------
______________________________
controlSUITE™ software. Comprehensive. Intuitive. Optimized.
Real-world software for real-time control. Details Here!
(You need to be a member of rabbit-semi -- send a blank email to rabbit-semi-subscribe@yahoogroups.com )
>
> many thanx for you replies.
>
> actually i'm using the ucos2 and i have more than task that are using different socket and all of my problems started with RST38 which does it mean "corruption into stack" so i was suspecting in passing the near pointer to the function that is receiving far pointer.
The problem isn't near-to-far upcast, but near pointers to local variables or function parameters somehow making it to another thread. The near-to-far upcast is STILL a near pointer, unless you use paddr_far. One way for a near pointer to make it to another thread is to have TCP/IP calls in more than one thread and to put a socket on the stack. The TCP/IP library maintains a list of all active sockets, not knowing that some are in one thread, and some are in another. As Tom pointed out, make sure sockets are never on the stack.
> but your replies mean that if i'm passing the a near pointer to the function that is accepting far pointer in the same task, it won't be a problem.
Generally, but there may be other system libraries and circumstances other than TCP/IP where near pointers make it to another thread without you directly exchanging pointers. But things like string or memory copying will be OK.
>
> Am I right?
>
> Best Regards
> MFawzy
>
------------------------------------
______________________________
controlSUITE™ software. Comprehensive. Intuitive. Optimized.
Real-world software for real-time control. Details Here!
(You need to be a member of rabbit-semi -- send a blank email to rabbit-semi-subscribe@yahoogroups.com )