I'd thought about including some kind of "inline" command back when jman and I were polishing the first cut of the ZScript language, but ultimately rejected it for several reasons:
1) Complexity of safe integration: ZScript makes heavy use of registers and the stack to keep itself in a working, consistent state, in way that is not obvious to the typically ZScript programmer. For instance, the following code
Code:
ffc script foo
{
void run() {
int a = 1;
int b = 2;
inline { ADDV D4, 1 }
Trace(b);
}
}
would print 1. As an addition example, almost any kind of stack manipulation in inline ZASM would derail ZScript.
2) Such a feature isn't useful enough to be worth the implementation cost.
ZASM has two good advantages over ZScript: it is simpler for small scripts, and more efficient for all scripts.
As you've pointed out, there are one-line ZASM scripts that take 3-4 lines in ZScript. However, this advantage exists only for the shortest of scripts: branching, loops, or complicated expressions all become extremely nasty in pure assembly.
Script speed in a different story: I'd estimate that, on average, ZScript scripts are about 3 times slower than equivalent ASM scripts, as the ZScript compiler currently attempts no optimizations. Is this a problem? Possibly. Since ZC runs at 60 FPS, game logic code has about a 17 milliseconds allowance before it will start lagging the game. On my machine (2002 craptop) default ZC game logic takes about 3 milliseconds, leaving potentially 14 milliseconds to the ZASM interpreter, though of course your performance will vary. As long as script execution time stays under this cutoff point, it doesn't matter much whether the script is faster or slower - the user won't see a difference.
If it turns out that normal scripting starts lagging ZC, optimization measures will be taken, and I'd certainly give an inline assembly command a second look.