 | | Forward of pbFORTH debug sessions
|
|
John Cooper and I have exchanged numerous emails on the progression of pbFORTH and he has agreed to share them with the group. I guess we should have always discussed on the group, but once I just hit Reply instead of ReplyToAll and that was the end (...) (25 years ago, 11-May-99, to lugnet.robotics.rcx.pbforth)
|
| |
| | Re: Some goals, ideas, etc. for a new bytecode interpreter (long)
|
|
(...) Single-stepping through instructions would be a mode offered by the interpreter, and wouldn't require any breakpoints to be set. I suppose what the debugging information could contain is, instead of a list of valid breakpoints, a list of (...) (25 years ago, 10-May-99, to lugnet.robotics.rcx)
|
| |
| | Re: Some goals, ideas, etc. for a new bytecode interpreter (long)
|
|
(...) You have 4 7-segment characters which could display a 4 character text string (albeit with some of the characters being different case and some confusion between characters). (...) Adding limited functions to check the memory usage without (...) (25 years ago, 10-May-99, to lugnet.robotics.rcx)
|
| |
| | Re: Some goals, ideas, etc. for a new bytecode interpreter (long)
|
|
(...) Sure, but that's what zero padding is for. Since the opcode is IR-only, you don't care too much about length. The only length restriction comes from the second digit of the opcode, assuming you're using the ROM to receive incoming IR data. (...) (25 years ago, 10-May-99, to lugnet.robotics.rcx)
|
| |
| | Re: Some goals, ideas, etc. for a new bytecode interpreter (long)
|
|
(...) I was not intending to limit its functionality to that performed by the RCX with the standard firmware loaded. I did say "when no new features are being exploited". The idea of flashing an identifier associated with the current program may not (...) (25 years ago, 10-May-99, to lugnet.robotics.rcx)
|
