Subject:
|
Re: Some goals, ideas, etc. for a new bytecode interpreter (long)
|
Newsgroups:
|
lugnet.robotics.rcx
|
Date:
|
Sat, 8 May 1999 23:44:52 GMT
|
Viewed:
|
1786 times
|
| |
|
|
Mark Tarrabain <markt@lynx.bc.ca> wrote:
> I would hope that the new system would look and feel *EXACTLY* like
> the RIS firmware in terms of end-user observable behavior when no new
> features are being exploited (the internal behaviour is likely to be
> different, of course).
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.
> Each thread of execution with a program should have its own virtual
> register set. All arithmetic manipulations and data movement happen
> through these registers (that is, to move data from one variable to
> another, it must first be loaded into a register and then the contents
> of that register moved to the memory location required). Doing this
> drastically simplifies the instruction set to the point where it becomes
> feasible to develop a robust bytecode set in only 256 instructions
> (implementing much more than 256 instructions is not particularly viable
> on a machine that only has 32K of RAM).
This is reasonable unless you find that you can considerably reduce program
size 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.
> It must be possible to create and dispose of stack frames at runtime
> in a LIFO manner to permit recursive functions to exist.
It is certainly possible; I suggested a way to do this earlier.
> Space for global variables, stack, and virtual registers will be
> allocated and initialized by the interpreter when the program is run,
> and deallocated upon program termination. Since only one program can
> run at any one time, it would be wasteful to consume RAM with other
> programs' runtime requirements while they are not actually running. I
> realize that this mechanism completely fails to support the concept of
> pre-initialized global variables, but in light of the limited RAM
> available on the RCX, I believe that this is a reasonable trade-off.
The only way to properly support initialized globals is to maintain a data
area for them. Then, whenever you start a program and allocate its global
data area, you copy the initialized globals to the start of that area and
go on from there. Note that only initialized (i.e. initially non-zero)
globals take space. The remaining globals can be explicitly set to zero by
the interpreter.
I would suspect that if the cost to implementing them is small from the
point of view of the interpreter, you will find that maintaining a data
area for initialized globals is worth the cost. Having the program
initialize the data will be more costly, since you have to do the
initialization from the byte code.
Presumably, the compiler will know what is an initialized global and what
is not, and will be able to get the addressing right so that initialized
globals are located together at the start of the global data area, and so
that the initial values for these variables are stored somewhere so they
can be downloaded to the RCX.
Speaking of all this, if you end up using an opcode to allocate the global
data area, this opcode can be followed by inline data to initialize the
starting section of the data area. This sort of merges the idea of
initializing at run time with the idea of maintaining a separate data area
to store the data to initialize with, and compacts the code needed to do
the initialization.
Regarding debugging support, I've accumulated a different set of ideas
about how to get this working.
The normal way to implement a breakpoint is to replace an opcode with a
trap opcode. In the case of the RCX, the trap opcode might be a single
byte; reaching the opcode suspends execution of all tasks. You seem to
have latched onto this idea.
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.
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.
Clearly, there need to be ways to query and manipulate variable frames from
the PC; these methods depend highly on the machine model and are not really
worth discussing at this point, except to say that such methods should
exist.
Assuming support for execution of a subset of opcodes received over the IR
link, changing the I/O state of the RCX is a simply matter of executing the
proper opcodes. If done correctly, reading back the I/O state is a matter
of implementing the functionality currently supported by the get value
opcode. The point of all this is that manipulation of the I/O state is
essentially free (i.e. independent of other debugging support) in the
current scheme of things, and should likewise be free in any new firmware.
I imagine all new debugging functions to be implemented with a single
IR-only opcode, to keep the impact on the opcode space small.
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.
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.
-Kekoa
|
|
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
|
|
|
|
