20,741
edits
Improving Nasal: Difference between revisions
Jump to navigation
Jump to search
m
→Better debugging/development support
| Line 10: | Line 10: | ||
If you are aware of any major Nasal issues that are not yet covered here, please feel free to add them here, however it is also a good idea to use the FlightGear bug tracker in such cases: http://flightgear-bugs.googlecode.com/ | If you are aware of any major Nasal issues that are not yet covered here, please feel free to add them here, however it is also a good idea to use the FlightGear bug tracker in such cases: http://flightgear-bugs.googlecode.com/ | ||
= Consider Opcode reordering = | |||
Referring to switch/case constructs like these (also to be found in Andy's code): | |||
<syntaxhighlight lang="c"> | |||
334 switch(BYTECODE(code)[i]) { | |||
335 case OP_PUSHCONST: case OP_MEMBER: case OP_LOCAL: | |||
336 case OP_JIFTRUE: case OP_JIFNOT: case OP_JIFNOTPOP: | |||
337 case OP_JIFEND: case OP_JMP: case OP_JMPLOOP: | |||
338 case OP_FCALL: case OP_MCALL: | |||
339 naVec_append(bytecode, naNum(BYTECODE(code)[++i])); | |||
</syntaxhighlight> | |||
Such logic can be expressed more easily by simply wrapping these OP codes in between BEGIN_IMMEDIATE_MODE and END_IMMEDIATE_MODE enums, because we then only need to do this: | |||
<syntaxhighlight lang="c"> | |||
#define IS_IMMEDIATE_MODE(bytecode) bytecode > BEGIN_IMMEDIATE_MODE && BYTECODE(code)[i] < END_IMMEDIATE_MODE | |||
if ( IS_IMMEDIATE_MODE(BYTECODE(code)[i]) ) | |||
naVec_append(bytecode, naNum(BYTECODE(code)[++i])); | |||
#undef IS_IMMEDIATE_MODE | |||
</syntaxhighlight> | |||
Which basically means that we only need to worry about a single place when it comes to extending opcodes, which also translate into less assembly instructions that are actually run (2 CMP vs. ~12 per insn). Also, the bytecode interpreter routine itself could be simplified that way, too. In addition, it would make sense to augment the list of opcode enums by adding an OP_VERSION field that is incremented once opcodes are added/removed: | |||
<syntaxhighlight lang="c"> | |||
enum { | |||
OP_VERSION = 0x01, | |||
BEGIN_OPS=0xFF, // reserve space for 255 opcode changes (should be plenty) | |||
OP_NOT, OP_MUL, OP_PLUS, OP_MINUS, OP_DIV, OP_NEG, OP_CAT, OP_LT, OP_LTE, | |||
OP_GT, OP_GTE, OP_EQ, OP_NEQ, OP_EACH, OP_JMP, OP_JMPLOOP, OP_JIFNOTPOP, | |||
BEGIN_IMMEDIATE_MODE, | |||
OP_JIFEND, OP_FCALL, OP_MCALL, OP_RETURN, OP_PUSHCONST, OP_PUSHONE, | |||
END_IMMEDIATE_MODE, //FIXME: incomplete - just intended as an example! | |||
OP_PUSHZERO, OP_PUSHNIL, OP_POP, OP_DUP, OP_XCHG, OP_INSERT, OP_EXTRACT, | |||
OP_MEMBER, OP_SETMEMBER, OP_LOCAL, OP_SETLOCAL, OP_NEWVEC, OP_VAPPEND, | |||
OP_NEWHASH, OP_HAPPEND, OP_MARK, OP_UNMARK, OP_BREAK, OP_SETSYM, OP_DUP2, | |||
OP_INDEX, OP_BREAK2, OP_PUSHEND, OP_JIFTRUE, OP_JIFNOT, OP_FCALLH, | |||
OP_MCALLH, OP_XCHG2, OP_UNPACK, OP_SLICE, OP_SLICE2, | |||
NUM_OPCODES | |||
}; | |||
</syntaxhighlight> | |||
At which point it would make sense to add a library function that returns a hash with build-time constants, like these: | |||
* OP_VERSION | |||
* MAX_STACK_DEPTH 512 | |||
* MAX_RECURSION 128 | |||
* MAX_MARK_DEPTH 128 | |||
* OBJ_CACHE_SZ 1 | |||
= Better debugging/development support = | = Better debugging/development support = | ||
| Line 16: | Line 65: | ||
* Being able to dump the global namespace (see [http://flightgear.org/forums/viewtopic.php?f=30&t=19049&p=182930&#p182930 this topic] for a possible solution) or at least dump things prettily (an unreleased version of the file discussed in [[Nasal Meta-Programming]] has good support for nice formatting). | * Being able to dump the global namespace (see [http://flightgear.org/forums/viewtopic.php?f=30&t=19049&p=182930&#p182930 this topic] for a possible solution) or at least dump things prettily (an unreleased version of the file discussed in [[Nasal Meta-Programming]] has good support for nice formatting). | ||
* Register a callback for handling errors using call() | * Register a callback for handling errors using call() | ||
* work on abstracting the GC interface (Hooray) {{Progressbar|50}} | * work on abstracting the GC interface (Hooray) {{Progressbar|50}} | ||