pMARS patch set
M Joonas Pihlaja
Hello,
I've some patches for pMARS to fix some bugs and add some
optional features including read/write limit support. They are
available at:
http://www.cs.helsinki.fi/u/jpihlaja/cw/pmars-0.9.2-patches_20040721.tar.gz
The patches are described below. Most patches are independent of
each other, excepting the 02bimmediate.patch and the
07rwlimit.patch that must be applied in that order. If you're
applying all of them, it's best to apply them in the order below,
using a fuzz factor of three or four.
I've not got access to a windows compiler at the moment so can't
make an EXE of these I'm afraid. I'll be adding r/w support to
the server at SAL after my holiday.
Many thanks to Chip Wendell and John Metcalf for noticing these
bugs.
Best Regards,
Joonas Pihlaja
- 01bigbufs.patch:
Increases some internal limits so pMARS won't crash as easily by
accident.
- 02bimmediate.patch:
Fixes a bug when evaluating immediate mode B-operands where the
B-register wasn't reloaded after evaluating the A-operand. This
caused code where the A-operand was <0 or >0, and thus changed
the B-field of the instruction, to be executed wrong.
- 03longmin-alpha.patch:
Fixes a bug in eval.c that caused pMARS to crash on Alpha
processors when dividing LONG_MIN by +1
- 04optA.patch:
Adds an command line switch -A that can be used to assemble only
the input warriors and not run any fights. Emits '94 Draft
compliant load files.
- 05outside_org.patch:
Fixes a bug in sim.c that caused pmars to try to access memory
outside core when given an ORG or END statement with an argument
that was too large.
- 06rc5.patch:
Adds another random number generator with a larger seed space to
make cracking -F numbers harder. If the parameter to the -F
switch contains non-digits then it seeds the new generator, and
otherwise the old generator is used, to maintain compatibility.
- 07rwlimit.patch:
Adds read/write limit support. The implementation follows Chip
Wendell's CoreWin R/W model where the base offset cell in
predecrement and postincrement indirect modes is computed within
the write limit. New switches -R <readlimit> and -W <writelimit>
can be used to set the limits, which must be divisors of
CORESIZE. Also, the predefined symbols READLIMIT and WRITELIMIT
are available for warriors to use during assembly.
Note: compiling in R/W limit support slows down the simulator by
170% even if both the R/W limits are equal to CORESIZE!
Note 2: Consider this one to be in a beta-test phase, as I'm not
100% sure I've got the details exactly right. Just wanted to get
it out the door before dropping off line for a bit.
Ilmari Karonen
>
> I've some patches for pMARS to fix some bugs and add some
> optional features including read/write limit support. They are
> available at:
>
> http://www.cs.helsinki.fi/u/jpihlaja/cw/pmars-0.9.2-patches_20040721.tar.gz
I'm still the official maintainer of the pMARS sourceforge project
(but not the project admin, so I can't transfer the job to someone
else without Anton's help). I'm unfortunately not around much until
mid August or so, so I can't get a new version out before that. But
these patches certainly do seem useful.
Some quick comments below:
> - 02bimmediate.patch:
> Fixes a bug when evaluating immediate mode B-operands where the
> B-register wasn't reloaded after evaluating the A-operand. This
> caused code where the A-operand was <0 or >0, and thus changed
> the B-field of the instruction, to be executed wrong.
If this was in fact a violation of the '94 draft spec, how come nobody
noticed it before? Come to think of it, might there be some warriors
around that depend on this bug?
> - 04optA.patch:
> Adds an command line switch -A that can be used to assemble only
> the input warriors and not run any fights. Emits '94 Draft
> compliant load files.
How is that different from -r 0 (except, I suppose, for the value of
ROUNDS)?
--
Ilmari Karonen
If replying by e-mail, please replace ".invalid" with ".net" in address.
Sascha Zapf
> ,
> Adds read/write limit support. The implementation follows Chip
> Wendell's CoreWin R/W model where the base offset cell in
> predecrement and postincrement indirect modes is computed within
> the write limit. New switches -R <readlimit> and -W <writelimit>
> can be used to set the limits, which must be divisors of
> CORESIZE. Also, the predefined symbols READLIMIT and WRITELIMIT
> are available for warriors to use during assembly.
>
> Note: compiling in R/W limit support slows down the simulator by
> 170% even if both the R/W limits are equal to CORESIZE!
>
> Note 2: Consider this one to be in a beta-test phase, as I'm not
> 100% sure I've got the details exactly right. Just wanted to get
> it out the door before dropping off line for a bit.
I think one thing is missing. If you let fight one Warrior alone, and he
survives without selfdestruction he should win. But pmars output is 0 0,
For example exmars, means exhaust puts out 1 0
Sascha
--
Parlez vous Redcode?
M Joonas Pihlaja
On Sat, 24 Jul 2004, Ilmari Karonen wrote:
> > - 02bimmediate.patch:
> > Fixes a bug when evaluating immediate mode B-operands where the
> > B-register wasn't reloaded after evaluating the A-operand.
[snip]
> If this was in fact a violation of the '94 draft spec, how come
> nobody noticed it before? Come to think of it, might there be
> some warriors around that depend on this bug?
Two reasons. Firstly, it's very difficult to actually come
across this bug as the instruction needs to modify the b-field's
value in the a-field (i.e. either < or > as the a-mode), and
secondly, because sim.c currently goes out of its way to *not*
re-load the b-register when the b-field is immediate, making it
look more official. Or that's my theory anyway. :)
Nevertheless, if you look at the draft it clearly says that the
b-operand's registers are explicitly loaded after the a-operand
is completely evaluated. For post-increment indirect this is
made explicit in lines 606-609 which say:
[...The]
0606 B-number of the instruction pointed to by the A/B-number of the current
0607 instruction is incremented after the A/B-instruction is stored, but
0608 before the B-operand is evaluated (for post-increment A-mode), or
0609 the operation is executed (for post-increment indirect B-mode).
Moreover, the example simulator loads the b-register after
computing the read and write pointers of the b-operand (line 989
of the draft.)
> > - 04optA.patch:
> > Adds an command line switch -A that can be used to assemble only
> > the input warriors and not run any fights. Emits '94 Draft
> > compliant load files.
>
> How is that different from -r 0 (except, I suppose, for the value of
> ROUNDS)?
It emits proper load files without the 'Program "<name>" by
"<author>" banner. Also, if a hill server uses -r 0 to assemble
files to check for a Good Compile of Your Warrior and check for
compliance to hill rules, but then re-assembles with a different
ROUNDS when actually fighting, then the difference in ROUNDS can
be used by unscrupulous players to sneak in code that doesn't
comply to the hill rules. AFAIK, this has caused at least one
KOTH server to stop accepting submissions, in the past.
Joonas
M Joonas Pihlaja
On Sat, 24 Jul 2004, Sascha Zapf wrote:
> I think one thing is missing. If you let fight one Warrior alone, and he
> survives without selfdestruction he should win. But pmars output is 0 0,
> For example exmars, means exhaust puts out 1 0
hm.. The default score formula is (W^2-1)/2 where W = #warriors,
S=#survivors for warriors that don't die furing a battle, with 0
points given for any warrior that dies. So 0 is actually the
correct score since always W^2 - 1 = 0 for a single warrior.
You should be able to get around this by setting the score
formula to something like 'S==1', but I just tried that and S is
always equal to one for single warrior battles. :-(
Joonas