Redcoders Frenzy - The ongoing corewar tournament
Organiser: Chip Wendell
Time to free yourselves from the confines of tiny coresizes, and
explore the open spaces of a truly huge core!
Core size = 1,000,000
Max cycles = 10,000,000
Read limit = 1,000,000
Write limit = 50,000
Max processes = 10
Max length = 1000
Min distance = 10,000
P-space size = 100,000
Number of rounds = 100
P-space is allowed, but PIN is not (no handshaking). The battles are
fought Round Robin with no self fights. Two entries are allowed per
author. Three points for a win, one point for a tie.
Please note the write limit. You'll need to use either CoreWin 2.2
or Joonas' R/W limit patch for pmars.
- There is no read limit, so scanners can see all of core. But they'll
have to send out proxies to attack anything they find. Here's where
p-space can come in handy: sharing information and instructions with
your far-flung processes.
- With only 1/20th of the core reachable by any process, and only 10
processes, imp spirals are impossible, because the head can't wrap
around to the tail. It also means that no set of static processes can
bomb all of core. Mobility will be needed.
- There's plenty of room and plenty of time, so don't feel rushed.
There's no danger of being hit by a qscan in the first 20 cycles!
Perhaps this is the time to dust off some of the more complex
strategies (cooperating processes, self-repair programs) that never
seem to succeed on the standard hills.
There have been a few questions about the RF23 round, so I've put
together a brief FAQ.
Q: Why isn't my warrior working the same under CoreWin and pmars?
A: As I noted in a previous post, CoreWin has a bug in the way it reads
settings from a .cfg file. Each time you start CoreWin, you need to
type numbers into the write limit and p-space size boxes in order for
those parameters to be set properly. If in doubt, run MOV 0,50001; it
should behave as a normal imp.
Q: How do read/write limits work?
A: This is a long one, but here goes:
Every address in Redcode is either a read address or a write address.
Basically, a write address is any address at which the core contents
are (or could be) changed, and everything else is a read address. For
instance, in a MOV $X,$Y instruction, X is a read address but Y is a
write address. All compares, jumps, and SPL use read addresses, because
nothing is changed in core. The address that's decremented by a DJN is
a write address. Each of the indirect addressing modes involves two
addresses, which may be classified differently: in a SUB >X,}Y
instruction, both of the intermediate addresses (X and Y) are write
addresses, because they're being incremented; the final addresses
(X+[X.B] and Y+[Y.A]) are read and write addresses, respectively.
Under R/W limits, each write address is calculated modulo the write
limit (WL), so that the address is "folded" into the range -WL/2+1 to
+WL/2. Similarly, each read address is folded modulo the read limit.
Under RF23 rules, the read limit is the same as the coresize, and since
all addresses are calculated modulo the coresize anyway, the extra
folding has no effect; any address in core can be "read". But the write
limit is 50000, so every write address will be folded into the range
-24999 to +25000, relative to the current instruction. This is true
even for indirect addressing; MOV bomb,@ptr will bomb the same section
of core no matter how far away ptr is.
Note that p-space addresses are not subject to R/W limits. STP
#42,#90000 will store a value in p-space location 90000 under RF23
rules. (P-space addresses are folded modulo the p-space size, but
that's a different story.)
In a very close result, Roy van Rijn squeaks out a narrow victory
over Christian Schmidt and German Labarga, on the strength of his
clever non-PIN handshake. Nenad Tomasev finishes a very strong fourth.
||Roy van Rijn||182.5||100.0|
||Roy van Rijn||153.5||84.1|
|8||32.5||38.6||28.9||don't know if..
||John K. Lewis||106.4||58.3|
|11||5.9||67.0||27.1||castle of mirrors