Subject:
|
Re: Some goals, ideas, etc. for a new bytecode interpreter (long)
|
Newsgroups:
|
lugnet.robotics.rcx
|
Date:
|
Mon, 10 May 1999 18:04:12 GMT
|
Viewed:
|
1480 times
|
| |
|
|
Kekoa Proudfoot wrote:
> Mark Tarrabain <markt@lynx.bc.ca> wrote:
> > 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.
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 file/line number,and function ID for each instruction
in the program (The latter piece of information being able to be used by a
high level language debugger to locate a set of valid identifiers within the
current scope). That would mean that the debugging information size would be
8 times the number of instructions contained in the program: 2 bytes for the
file [an index into an array of files for the program]), 2 bytes for function
ID (an index into an array of functions), and 4 bytes for the line number (I
realize that in practice for such small programs, only 2 bytes may be
necessary for line numbers, but since the source file will exist on a desktop
PC, it could conceivably be much longer than 64K [eg. lots of whitespace, or
perhaps very long comment sequences].)
> > Mark
|
|
Message is in Reply To:
9 Messages in This Thread:
 
  
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
