Subject:
|
Re: Some goals, ideas, etc. for a new bytecode interpreter (long)
|
Newsgroups:
|
lugnet.robotics.rcx
|
Date:
|
Mon, 10 May 1999 17:25:50 GMT
|
Viewed:
|
1367 times
|
| |
|
|
Mark Tarrabain <markt@lynx.bc.ca> wrote:
> > 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?
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.
> 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).
Some people might want to step through the disasm, no? Especially if they
do not yet trust the compiler.
> 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).
Nobody said the debugging information should be stored on the RCX.
Clearly, some records in the file contain actual object code, and other
records contain other data.
-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
|
|
|
|
