 | | Re: Some goals, ideas, etc. for a new bytecode interpreter (long)
|
| (...) What do you mean by end-user? Does keeping the end-user look and feel mean keeping the existing opcodes intact? You seemed to have mentioned this as a goal before but maintaining just the "look and feel" might no longer mean that. Also, you (...) (26 years ago, 8-May-99, to lugnet.robotics.rcx)
| | | | | Re: Some goals, ideas, etc. for a new bytecode interpreter (long)
|
| (...) In light of some of your points raised earlier and consideration since I first brought it up, I can see that bytecode level compatibility is not strictly required. By Look & Feel, I refer only to the observable behaviour of the RCX, not the (...) (26 years ago, 9-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. (...) (26 years ago, 10-May-99, to lugnet.robotics.rcx)
| | | | | 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 (...) (26 years ago, 10-May-99, to lugnet.robotics.rcx)
| |
