Subject:
|
Some goals, ideas, etc. for a new bytecode interpreter (long)
|
Newsgroups:
|
lugnet.robotics.rcx
|
Date:
|
Sat, 8 May 1999 18:39:53 GMT
|
Viewed:
|
1317 times
|
| |
|
|
Forgive me while I think out load here. I'd like some feedback on
some goals and ideas I've thought of for a new bytecode interpreter.
Any critiques, comments, opinions, recommendations, or additions are
welcome:
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).
The system should still support the storage of a number of programs
at the same time, like the normal RIS firmware does (only one can
actually be used at any given time, though).
I was originally thinking of a replacement firmware that would be
bytecode-level compatible with the standard RIS one. In light of the
new features provided by the interpreter, however, bytecode-level
compatibility is probably not an issue.
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).
It must be possible to create and dispose of stack frames at runtime
in a LIFO manner to permit recursive functions to exist.
There should be no limit to the number of global variables allowed
in a program other than available RAM on the RCX.
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.
All "addresses" within a bytecode sequence are actually offsets from
one of the following: the start of the program code, the start of global
data space, or the start of the current stack fram. Which address
actually being referred to by any given instruction depends on the exact
instruction.
A debugging IR protocol should exist. It should be possible to
notify the RCX at any time that a breakpoint has been set. When the
bytecode interpreter arrives at a breakpoint, the RCX communicates to
the PC which breakpoint has been reached, and the program is suspended
until resumed by another IR instruction, or terminated. Further, the PC
should be able to set the states of the motors and read the sensors (of
couse), and should also be able to obtain or set the current value of
any global or local variable. This debugging protocol should be ignored
by the RCX if the currently running program is specified as being
non-debuggable. This ensures that in robot competitions, the debugging
protocol could not possibly be used to suspend the processes of other
RCX's or peek into their behaviours. All a competition entrant would
need to do is compile their program with a debug flag turned off before
downloading it into the RCX. The only issue of debugging that should be
allowed at all times is that the RCX is able to be queried about whether
or not the current program is debuggable (the default should probably be
no).
The way I would imagine the breakpoint mechanism to function is as
follows:
There would exist a mechanism by which the desktop PC could directly
change the bytecode of the program currently running (via a new IR
instruction). When a breakpoint is to be inserted, the PC instructs the
RCX to change the opcode at some specified location to what happens to
be the RCX breakpoint instruction. The RCX should comply and respond by
informing the PC of the instruction that was originally there (so the
debugger can know what instruction to really execute at that spot).
When the RCX encounters a breakpoint instruction, it transmits a message
to the PC which indicates that it has stopped, along with the position
of the breakpoint (so the PC knows which breakpoint was reached). To
resume from a breakpoint, the PC would transmit a resume instruction
along with a single byte parameter which specified the instruction that
was overwritten by the breakpoint instruction (so the RCX can execute
it). The RCX would then execute the instruction transmitted (picking up
any of the instruction's operands from the original bytecode stream).
To remove a breakpoint, the PC could tell RCX to set the opcode back to
the value that the PC recieved originally. It should be the
responsibility of the debugging environment on the desktop PC to ensure
that this mechanism be performed cleanly. I realize that the potential
here is quite high for errors to creep in while developing the debugger,
but like many things, I see this is a tradeoff. This mechanism does not
take up any RAM overhead on the RCX (which is a fundamental concern,
given its limited size) beyond, perhaps, a single instruction to be
executed before the program begins which indicates that the program is
to accept debugging instructions. Furthermore, and again in light of
the RCX's limited size, I believe it is more forgiveable to place a much
greater burden on the desktop PC's side of things that the software
function correctly because, quite frankly, these computers have the
memory and horsepower to spare.
The following is an idea that I came up with for a debugging
information file format. I believe it has the merits of being robust,
source-language independent, easy to generate, and not excessively
large. This file would remain on the desktop computer and would be
generated by a compiler for debuggable programs, and would be used by
debugging software which could be part of an IDE or may be a separate
application. I have never explored the inner workings of a debugger
before, so it's probable that there are quite a few things wrong with my
ideas, but here's what I've got so far:
Count of source files in project
List of source files in project
Count of legal breakpoints in program
<For each legal breakpoint>
Position of possible breakpoint
Source file (an index into the list at the beginning)
Line number
Count of global variables
<For each variable>
Name of variable
Position of variable in global address space (as an offset)
Count of functions
<For each function>
Name of function
Position of function
Size of function
Number of local variables in function
<For each local variable>
Name of variable
Position of variable in local stack frame
If you've actually read everything I've written up to this point, I
thank you. :)
> > Mark
|
|
Message has 3 Replies:
 | | Some clarification
|
| (...) I was not suggesting creating a potential for an L&F lawsuit from Lego by duplicating their Mindstorms product for Windows or some other PC platform, I was suggesting imitating the look & feel of their firmware on the RCX itself. (Not that I (...) (25 years ago, 8-May-99, to lugnet.robotics.rcx)
|
9 Messages in This Thread:
 
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
