Subject:
|
Re: Maximum Subroutine numbers?
|
Newsgroups:
|
lugnet.robotics.rcx.robolab
|
Date:
|
Sun, 28 Dec 2003 19:25:59 GMT
|
Reply-To:
|
BrainChild@Skyler(avoidspam).com
|
Viewed:
|
10063 times
|
| |
|
|
While I was dwelling on the fundamental interconnectedness of all
things on Sun, 28 Dec 2003 16:52:00 GMT, "Dick Swan"
<dickswan@sbcglobal.net> wrote:
<snip>
> FIrmware does not support nesting of subroutine call. There is no firmware
> error detection. Firmware appears to keep only a single return address
> (rather than a stack) for subroutine returns. A nested subroutine call
> sequence will "wipe out" the original return address.
>
> I suspect that events and subroutines don't mix well and may very well have
> software bugs. They both interrupt the sequential instruction address
> sequence. I wouldn't be surprized that a subroutine 'return' instruction may
> cancel any existing event 'monitoring' sequence. [I have not tested this].
It doesn't happen most of the time, so the conflict would have to have
more dependencies, but I suspect this description is what is going on.
I have since concluded that even without subroutine calls events in
Robolab are unreliable.
|
|
Message is in Reply To:
 | | Re: Maximum Subroutine numbers?
|
| I don't use Robolab, but I can offer some insight into how the RCX firwmare operates with subroutines (and events) that may partially explain your problems. RCX firmware supports 8 (eight) subroutines per slot. Internally they are numbers 0 to 7. (...) (21 years ago, 28-Dec-03, to lugnet.robotics.rcx.robolab)
|
5 Messages in This Thread:
  
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
