The second replicator doesn't need DAT for its pointers. Its pointers are used
in double usages with others. Instead of replicating 8 lines of code, it now
replicates 6 lines. This means smaller module and faster progress.
Like others, paper's goal is to terminate all of its adversary processes.
Although it is lacking of what other warriors have:
core-clear, it still can win just by mainly
overwriting the opponent code with its own code. One hindrance with this is
that simple plain of copying is not sufficient for paper to win alone. There
is a chance that its adversary becomes converted into another working paper
instead of getting clobbered. Thus, an ideal paper module should be able
to self-terminate as well as to replicate. Here is the importance of checksum.
It allows paper to check all the executing processes and direct their
continuation. Those who can identify themselves as original paper's processes
are allowed to continue replicating. Those who can't are forced to terminated.
One way to design checksum is by observing how distinct own processes
from opponent ones when running in a paper module. They are:
- Initial location.
- The opponent process may start at anywhere in the copied module.
- Number.
- There are more processes executing the module (own's + opponent's).
A checksum can be implemented effectively with only few additional codes.
The first warrior that demonstrates checksum is
note paper.
The concept is as follow:
;name Paper 3
cnt EQU dt - src
init SPL 1
MOV -1, 0
SPL 1 ; Create 6 on-line processes
src MOV #cnt, 0 ; Init number of lines to be copied
; This also serves as a source pointer
MOV
The new warrior requires an initial set-up that creates 6
online processes. Down at the bottom is
a neat single piece of code. It is intended for all alien processes.
The checksum is such as in order to replicate successfully, there have to be
exactly 6 processes running synchronously. Failing the requirement should
trigger the self-erase routine at the bottom.