Subject:
|
Re: Some goals, ideas, etc. for a new bytecode interpreter (long)
|
Newsgroups:
|
lugnet.robotics.rcx
|
Date:
|
Sun, 9 May 1999 06:49:17 GMT
|
Viewed:
|
1592 times
|
| |
|
|
Kekoa Proudfoot wrote:
> 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 mention not
> maintaining byte code compatilibity later, so again, maybe look and feel
> does not include opcodes.
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 actual instructions executed to accomplish
a task.
> [256 opcodes] is reasonable unless you find that you can considerably reduce
> programsize with minimal increases to the interpreter code by allowing opcodes
> to make use of more complex addessing modes. You may or may not find the
> existing source/argument idea useful in this regard.
Maybe... but this would mean that *every* operand to an instruction
would be 3 bytes - 1 byte source and 2 bytes for the argument. Perhaps
this would be acceptable for the 'mov' instruction, but for any other
instructions which have destinations such as add, I believe that the
destination should always simply be a register because it can save 2
bytes for each such instruction (which can add up really quick).
> An interesting way to implement a breakpoint on the RCX, and the preferred
> way in my opinion assuming that the interpreter is designed similarly to
> the current interpreter regarding the 0x08 sequence bit, is to use the 0x08
> sequence bit to implement a breakpoints. Opcodes stored in programs do not
> normally have the 0x08 bit set; setting the bit causes execution to be
> suspended when an opcode with that bit set is decoded. The nice thing
> about using the 0x08 bit is it simplifies coding the debugger
> substantially. You don't need to replace and restore opcodes.
That's a really cool idea! I wish I'd thought of it. :)
> In order to reliably notify the PC that a breakpoint has occurred, the PC
> should probably poll the RCX to see if it has reached a breakpoint. The
> primary reason for this is that the tower stops receiving if the PC has not
> anything for a few seconds. It is possible to write code on the PC to keep
> the tower alive, but things are complicated this way, because then
> notifications from the RCX have to made reliable.
Okay. I guess the PC would constantly query the RCX to see if a
breakpoint was reached, and if one was, the RCX would respond with where
the breakpoint is (otherwise, it would respond with some sort of
negative acknowledgement).
> I imagine all new debugging functions to be implemented with a single
> IR-only opcode, to keep the impact on the opcode space small.
Hrm, but wouldn't the lengths of all the debugging opcodes be the same
in that case?
> Regarding a debugging file format, you proposed including a table of legal
> breakpoints. Did you mean to imply that there every instruction was a
> valid breakpoint? This should certainly be the case. Such a table maps
> really tags instructions with file/line, and it should be named
> accordingly, preferably with the existing name used in existing object code
> file formats, which I do not know but I'm sure somebody else does.
Although technically every instruction could be a legitimate breakpoint,
in practice, the only breakpoints in a program would be at the first
instruction for a given source line (since a single line of source code
may map to more than a single instruction).
> I would suggest incorporating debugging information into the object code
> file format, so everything is in one place. You might even find that an
> existing object code file format defines everything you need already.
I can see this being useful, but the debugging information should
definitely *NOT* exist on the RCX itself (it will take up too much
space). The software to download a program into the RCX would have to
be written so that it ignores all the debugging information (except for
possibly setting some flag in the RCX which tells it that the program is
okay to debug). This should not be too difficult. The idea I had of a
separate debugging file is loosely based upon the ever-diminishing idea
I had that bytecode-level compatibility be maintained.
> > Mark
|
|
Message has 1 Reply:
Message is in Reply To:
9 Messages in This Thread:
 
  
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
This Message and its Replies on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
