Archived from groups: rec.games.corewar (More info?)
Here's an idea I had recently.
There are about 8000 different opcode/modifier/addrmode combinations
in redcode '94. A standard hill battle can involve at most 201 of
them, usually much less. The most commonly executed opcodes (MOV,
SPL, DAT, JMP) are all rather simple. (In particular, none of these
top 4 instructions use their B-instruction registers at all.)
If we knew which subset of opcodes will be used, we could make the
simulator loop much simpler. It would also be useful to include
separate, simplified execution paths, with fewer branches, for the
common, simple instructions.
So why not build a custom simulator for each battle? Of course, this
wouldn't be trivial, and would require either reliance on an external
compiler (high overhead) or direct assembly coding (non-portable).
But what about writing the simulator in an interpreted language, such
as Java bytecode? This wouldn't be as fast as real assembly code, but
it would be portable. And there are already JIT compilers that could
turn the generated bytecode into native code, possibly giving speeds
comparable to conventional simulators written in C.
Generating JVM bytecode directly could in itself give a speed boost
over conventional simulators written in Java, since the bytecode
produced by current Java compilers isn't very well optimized.
So, the question now is: is there actually any demand for a fast
Java-based MARS? If not, then there's no point in going much further
in this direction. It should be noted that much (though perhaps not
all, depending on implementation) of the speed gain is wasted if the
code needs to keep updating a graphical display all the time.
Or, for that matter, would someone actually want a MARS that needs to
call a C compiler before each battle?
--
Ilmari Karonen
To reply by e-mail, please replace ".invalid" with ".net" in address.
Here's an idea I had recently.
There are about 8000 different opcode/modifier/addrmode combinations
in redcode '94. A standard hill battle can involve at most 201 of
them, usually much less. The most commonly executed opcodes (MOV,
SPL, DAT, JMP) are all rather simple. (In particular, none of these
top 4 instructions use their B-instruction registers at all.)
If we knew which subset of opcodes will be used, we could make the
simulator loop much simpler. It would also be useful to include
separate, simplified execution paths, with fewer branches, for the
common, simple instructions.
So why not build a custom simulator for each battle? Of course, this
wouldn't be trivial, and would require either reliance on an external
compiler (high overhead) or direct assembly coding (non-portable).
But what about writing the simulator in an interpreted language, such
as Java bytecode? This wouldn't be as fast as real assembly code, but
it would be portable. And there are already JIT compilers that could
turn the generated bytecode into native code, possibly giving speeds
comparable to conventional simulators written in C.
Generating JVM bytecode directly could in itself give a speed boost
over conventional simulators written in Java, since the bytecode
produced by current Java compilers isn't very well optimized.
So, the question now is: is there actually any demand for a fast
Java-based MARS? If not, then there's no point in going much further
in this direction. It should be noted that much (though perhaps not
all, depending on implementation) of the speed gain is wasted if the
code needs to keep updating a graphical display all the time.
Or, for that matter, would someone actually want a MARS that needs to
call a C compiler before each battle?
--
Ilmari Karonen
To reply by e-mail, please replace ".invalid" with ".net" in address.
Facebook
Twitter
Instagram