Subject:
|
RE: pbForth & ROLL
|
Newsgroups:
|
lugnet.robotics.rcx.pbforth
|
Date:
|
Sat, 6 Sep 2003 15:37:41 GMT
|
Reply-To:
|
<[rhempel@bmts.]StopSpammers[com]>
|
Viewed:
|
3599 times
|
| |
|
|
> While testing my console the other day I kept getting pbForth to hang (or so it
> appeared). It turns out I was passing ROLL a number that caused it to do bad
> things. I'm wondering whether it should error out with "aborted stack
> underflow" or something like that rather than make you have to reboot the brick
> (as it were). What's the standard behavior of other forth systems?
John,
As always, it depends. ROLL can sometimes be recovered gracefully, but
not always. If you ROLL more than the stack depth, you'll shift some
RAM that you probably don't want to shift - like the pbForth image
itself.
In that case, there's not much point in recovering gracefully unless
you catch a ROLL before it happens. This will slow the system down.
The funny thing about embedded systems devlopment is that it's so
easy to clobber the target. Adding more "armour" to the system slows it
down. I guess that's why LEGO's bytecode interpreter is the way it is.
I do have a test suite that I pass through to pbForth in console mode.
It's a pretty big file,, but it tests pbForth completely, and as a
by=product, does a decent test of the console :-)
Let me know, and I'll email you a copy....
Ralph
|
|
Message is in Reply To:
 | | pbForth & ROLL
|
| (...) While testing my console the other day I kept getting pbForth to hang (or so it appeared). It turns out I was passing ROLL a number that caused it to do bad things. I'm wondering whether it should error out with "aborted stack underflow" or (...) (21 years ago, 6-Sep-03, to lugnet.robotics.rcx.pbforth)
|
14 Messages in This Thread:
  
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
