An Approach to Describe the Tierra Instruction Set Using Microoperations: The First Result.

Full text

Page 1

An Approach to Describing the Tierra
Instruction Set using Microoperations: The First
Result
Shuichi Matsuzaki12
Hideaki Suzuki2
Minetada Osano1
1Graduate School of Computer Science and Engineering,
Aizu University
Aizu-Wakamatsu City, Fukushima 965-8580 Japan
d8022201@u-aizu.ac.jp
2ATR Human Information Science Labs
2-2-2 Hikaridai Seika-cho, Soraku-gun, Kyoto 619-0288 Japan
Abstract. In constructing an Artificial Life system with a high potential
for evolution, one of the elements that we should design most carefully is
the machine structure, that is, the architecture of the system controlling
the operations of a digital creature. This paper proposes an approach
to modify the machine structure of Tierra in order to obtain higher
evolvability. The structure of the Tierran digital creature that we propose
is stimulated by the self-reproducing model proposed by von Neumann,
which enables self-reproduction in a simple architecture. Verification of a
digital creature’s structure was carried out through computer simulation.
As a result, the capabilities of self-reproduction and parasitism were
demonstrated.
1Introduction
In the development of an Artificial Life (Alife) system, it is important that
the system be designed so that ‘emergence’ (the appearance of higher functions
among elements) may occur. It is therefore necessary for us to prepare a good
artificial environment during system construction, since the possibility of emer-
gence happening in the system usually depends on the quality of the environment
prepared by the designer. The actual biological system provides a good example
for deciding what is needed in an Alife system. Today, it is widely accepted that
an appropriate state of ancient earth permitted life to emerge and a variety of
complex life forms to evolve. If we could identify the conditions necessary for
this evolution [4], it would greatly assist in designing of a ‘good’ Alife system.
Artificial environments prepared for an Alife system in a computer usually have
a two-layered structure: the information space (hardware layer) and the reaction
rule set (software layer), which cannot be changed during evolution.
Alife is an approach that uses a policy of “minimum implementation” in the

Page 2

2Shuichi Matsuzaki
design. In order to have a system with high evolvability, we should prepare the
artificial environments so that the software layer may be changed/optimized by
evolution as much as possible. From this point of view, we propose optimiz-
ing the instruction set of ”Tierra”, which was designed by Tom Ray [1]. In the
original experiment of Tierra, [1,2], the instruction set, a set of machine codes
that specifies the operation was pre-programmed and thus could not able to
be modified. If we were able to equip creatures with different instruction sets,
the evolution of the instruction set in addition to the usual evolution of Tierra
might take place. The model we propose in this paper aims to achieve this kind
of evolution. As a result, the constructed architecture of the digital creature is
considerably modified from that of the original Tierran creature.
In Section 2, we discuss past research on Tierra and the self-reproducing
machine proposed by von Neumann, which formed the basis our self-reproducing
model. We show our model in Section 3 by describing the architecture of the
components. Experiments and results of a simulation are reported in Section 4.
Our concluding remarks and future work are discussed in Section 5.
2Previous Self-reproducing Models
Since Ray proposed Tierra in 1992, it has been recognized as the most typi-
cal and representative Alife model. The Tierra simulation experiment produced
stimulating results on the behaviors of virtual creatures. However, we believe
that Tierra has not yet reached a state of completion, at least from the view-
point of self-reproduction. Consequently, we propose another Alife model by
following the excellent suggestions proposed by von Neumann (Fig. 1). He de-
signed a self-reproducing machine comprised of a machine with the function of
a universal constructor and copier and a tape consisting of descriptions of both
the constructor and copier (conceptually, these objects consist of descriptions
that might be called a description in the following discussion). The constructor
manufactures another machine called a replicant, and the copier makes a copy of
the descriptions for the replicant. Both the constructor and copier use the data
of the description in each working process. Although von Neumann introduced
the tape as simply a storage device to keep the coded information for the entire
body of the machine during the self-reproduction process, we regard this self-
reproducing machine as a model enabling evolution of genotype-to-phenotype
association. We take this view because the constructer, whose codes themselves
are also written on the description tape, translates the genotypic information on
the tape into the phenotypic machines.
Here, we return to our discussion of Tierra. Figure 2 shows the machine struc-
ture of Tierra. In Tierra, the tape in von Neumann’s model can be regarded as a
core memory and the copier as a mixture of the functions of a program, a central
processing unit (CPU), and an operating system (OS). Although the role of the
constructor is achieved by the functions of the CPU and OS, these structures
are implicitly programmed in the system. Therefore, a creature in Tierra can
create its replicant’s CPU by simply executing one instruction (‘divide’), but

Page 3

An Approach to Describe Tierra Instruction Set using Microoperations3
Fig. 1. John von Neumann’s Self-reproducing Machine’s structure
Fig. 2. Machine structure of Tierra

Page 4

4Shuichi Matsuzaki
almost all of the procedures necessary for the construction are executed by the
operating system. In the simulation, the programs embedded in the operating
system cannot be changed by any operation. This implies the impossibility of
optimizing the instruction set in the current Tierra structure.
Noteworthy features of the Tierra structure are as follows.
- The instruction code plays mostly the same role as the copier, but there is
no explicit constructor (it is programmed in the OS).
- In the simulation of Tierra, only the instruction code evolves, and the other
functions are embedded in the operating system.
3 Proposed Model
3.1Architecture
The architecture of individuals in this model is shown in Fig. 3. Since the entire
model itself was designed based on Tierra, of course the individual of our model
and that of Tierra still have a lot of common machineries. Nevertheless, the
architecture is more strongly influenced by von Neumann’s machine architecture
rather than by Tierra.
Fig. 3. Machine structure of Tierra redesigned
The structure is divided into two parts: ‘Machine’ and ‘Description’. In the
machine, there is a control memory and a set of registers (Table. 1). The control
memory is the only device that is recognized as a driving device from the operat-
ing system, and all operations are propelled by the interpretation and execution
of ‘microcodes’ in the control memory. As in the canonical technique of micro-
programming [7], the microcodes are expressed as register-transfer operations
(Table 2). In the process of self-replication, the codes are initially written in the
core memory as a part of the description tape (i.e., the codes are copied from a
mother individual to a daughter individual), and then they are copied (loaded)

Page 5

An Approach to Describe Tierra Instruction Set using Microoperations5
into the control memory. This process of loading the microcodes into the control
memory is coded in the ‘constructor’.
The code of the ‘copier’, which is also written in the core memory, is almost
the same as the original Tierran program. The code of the copier is represented
by a sequence of approximately eighty instructions of the original Tierra.
During the self-reproduction process of original Tierra, a creature, after allo-
cating memory space for the daughter, executes ‘divide’ instruction to create the
daughter CPU. In our model, the divide is eliminated, and instead a sequence
of instructions in the constructor (Table 3) is added to the copier and executed.
This additional routine, which is a sequence eighteen instructions, includes the
function of the ‘load’ instruction and accomplishes the job of making machine
architecture for the daughter CPU.
The description of the ancestor creature by the proposed model consists of
18 instruction words for the constructor, 86 instruction words for the copier, and
1,477 microcodes, which occupy 1581 data words in the core..
The following points give an outline of this model’s features.
- The model is Tierra-based, but the structure of individuals is largely influ-
enced by von Neumann’s self-replicating machine structure.
- The individuals have two components: ‘machine’ and ‘description’. The ma-
chine replicates (make copies) of both the individual’s machine and descrip-
tion by interpreting microcodes.
- The entire code, that is, microcodes, constructor and copier, is explicitly
coded on the core memory. Therefore, all code elements are changeable by
mutation.
3.2The Model vs. Tierra
In the previous subsection, we explained the architecture of our model. Here, we
discuss the advantages of our model by comparing it with Tierra.
Each individual of Tierra has the instructions of Tierran language, that is,
a virtual machine language (e.g. pushax, jmp, mal). The instructions are in-
terpreted by the operating system and executed from the top during the self-
replication. We should note that the instructions aren’t a variable function, in
other words, they are pre-programmed in the operating system. Therefore, the
mapping from the code (in the core memory) to the instruction set (programed
in OS) and the program that codes the Tierran instruction are never modified.
With respect to the former problem, McMullin et al. detected new instructions
with mutated genotype-phenotype mappings by using a variable lookup table
that is explicitly coded in the core memory [9]. In our model, we aim to make
not only the genotype-phenotype mapping but also the program itself mutable.
As we discussed, the instructions of this model are interpreted by micro opera-
tions in the control memory 2. The important point here is that the microcode
and the machine constructor are both coded in the core memory as a part of the
genotype.
We expect the following changes to individuals by mutation in this model.