1) power calculations for all components
(sleep mode to reduce power?)
[877 -> 20ua @3v 32khz
<0.6ma @4mhz 2.5-5v
2) playhead concept (1 or 2) turing? loops through buffer
multiple cells=multiple playheads (each circular for cell wall/barrier)
display= current timesliced head ///
death as repetition (judged) or simple replacement in memory.
cell identity dissolved.
3) opcodes research:
tag/template method for all addressing (/cell wall below)
templates use complementary patterns to match
4) identity though use of differently designed encoding disks (+ poss.
communication identities) + different sampling speeds for disk
5) simplest instruction set at expense of speed
sample opcodes ideas:
copy
spawn
repeat
jump
read
barrier
split
write
merge
+logical operators
+ data
4 bit instruction (16)
(see below redcode/corewar opcodes)
registers?
read and write now as simple access to channels (implicit r/w)
OK so we decide on following and need to source:
1) solar cells (maybe two small diagonally mounted either side of encoding
disk in center / --- \ disk central \=solar cells
/ | \
---------
different encoding disks specify identity of device
2) visible output (low power?? -lcd) - acoustic comms. source small low power
transducers/recivers
3) playhead is display-head + program head/counter moving through eeprom memory
buffer in loop. (avoid too many writes to eeprom data)
clarify q for devices: are they multicellular (multi-head) or uni-cell?
for devices: instruction pointer/read pointer/write pointer
5) agree that best first step would be to abstract
situation/vm (environment data/ tx/rx etc) and implement in C to best
determine opcodes/general functionality -- also useful for both projects and
could be coded quickly.
abstract out data in/out -- virtual machine -- opcodes -- tr/rx
modules such as (for both devices/virtual):
1) what I/O is available -- initialisation of data/instruction space
there. initialise mirror data/code space.
[devices: fill buffer . move head to first cell/instruction in buffer. q to
constantly poll receiver?]
2) access to I/O -- network (encoding scheme for rx/tx) / (sound, terminal, video in etc, local network)
disks [how far to go - registers, other info]) -- search, read , write to
mirror. abstract these functions as far as possible
are opcodes totally responsible for writing code to mirror space???
3) who is out there?
4) vm - opcodes/virtual cpu
5) management of mirrored environment space/data
(still struggle with cell wall idea:- read/write across cell wall :- all
elation to data via cell wall)
both/virtual machine:
1) Q separation code from data. coded, permeable cell wall within data
2) avoid endless loop:- each cell timesliced
break/reset for inactivity on tx front
ie. if head reads 0,0-> then polls environment at intervals till situation
changes.
if can spawn new cells then have to implement some sort of timeslicing and
will need multiple pointers for play/data heads
[death of cell as lack of new information-transmission]
sort of appendix:
basic corewars opcodes:
mov (operates on addresses/>)
add
sub
jmp
jmz (jmp if 0)
djz (dec jmp if 0)
cmp (if unequal skip)
dat (no executable data value)
spl (execution splits)
relative addressing -- direct, indirect, immediate
opcodes encoded to decimal integers
psoup (based on tierra):
spawn
register-register moves
register-mmory moves
add subtract
inc dec
register immediate moves
unconditional jump
conditional jump
pushes and pops
calls and returns
search backwards and forwards
noops
labels
(no genetic operators such as crossover or mutation = bitflip [note these
are implemented from above])
tierra -- pretty much the same also details of network version:
network instructions:
getipp: reads data structure (of map of known ip addresses) into cell memory
tpings: sends tping to ip address in register
tpingr: processes resulting data
divide: if zero or non-zero in register sends daughter to ip in register
surf: cell is ejected from current node to ip address ...
ifsig: checks signal type in register -ie. can see if tpings has returned
ttime: time placed in register
these only used as indications of how certain problems approached/solved by
tierra (main lesson is that IP addresses and other network info is not coded
within cells but rather accessed (randomly or via a pointer) from external
data structure used by all cells. network and I/O subsystems as seperate
from VM.
more tierra stuff:
1) instructions:
nop_0 (no operation 0; used in templates)
nop_1 (no operation 1; used in templates)
or1 (flip the low bit of cx)
sh1 (shift left cx)
zero (zero cx)
if_cz (if cx=0 do next instruction)
sub_ab (subtract bx from ax, result into cx)
sub_ac (subtract cx from ax, result into ax)
inc_a (increment ax)
inc_b (increment bx)
dec_c (decrement cx)
inc_c (increment cx)
push_ax (push ax onto the stack)
push_bx (push bx onto the stack)
push_cx (push cx onto the stack)
push_dx (push dx onto the stack)
pop_ax (pop top of stack into ax)
pop_bx (pop top of stack into bx)
pop_cx (pop top of stack into cx)
pop_dx (pop top of stack into dx)
jmp (move ip to template)
jumpb (move ip backward to template)
call (call a procedure)
ret (return from procedure)
mov_cd (move cx to dx)
mov_ab (move ax to bx)
mov_iab (move instruction pointed to by bx to address in ax)
adr (address of nearest template into ax)
adrb (search backwards for template)
adrf (search forwards for template)
mal (allocate memory for daughter cell)
divide (cell division)
[ thus tierra is purely 5/6 bit instruction set without operands -- could
reduce own instruction set to 4 bits]
2) The CPU data stucture is:
struct cpu {
short ax; //Address register
short bx; //Address register
short cx; //Numerical register
short dx; //Numerical register
char fl; //Flag (set when errors occur)
char sp; //Stack pointer
short st[10]; //Stack
short ip; //Instruction pointer
}
3) The soup is simply a block of computer memory between 16 and 256
kilobytes in size, within which the creatures live. It is cellular, in the
sense that a creature cannot simply write instructions anywhere, but has
only write priviledges in its own block, and that of its daugher cell, if it
has one.
4) The slicer doles out to each creature in turn a short time-slice, during
which it executes a small number of instructions. This time-slicing enables
an imperfect implementation of parallelism in the simulator. In MacTierra,
the slicer is implemented as a circular list of creatures which is rotated
at every time-slice. Offspring creatures are only inserted into the slicer
queue when they become independent from their parent (when the parent
executes the divide instruction).
5) each cell = block of memory with own/shared copy of program & own
processor. allocated block of memory -- can examine and excute code outside
this.
6) fetch-decode-execute-increment IP cycle (for each virtual cpu -- see data
structure)
feb20/2002
1) multiple cells in memory -- keep idea a) cell IP (instruction pointer)
b) WP c) RP (additional pointers: CP channel pointer// MP net mapfile
pointer)
2) is data brought into soup(?) totally by each cell & if can/not overwrite
other cells - again data channels idea
3) x channels for available read/writes==
a) soundcard rw
b) local net r
c) internet rw --- via mapfile of addresses [do we include this as a
channel YES] UDP
d) hard drive r [raw access? start tree/search]
e) V4Linux card r
f) console w [just use X -- simple library to work with for this and
V4L = libbgrab]
[g) keybd r [not too exciting]]
self-display as channel byproduct
SKIP[4) possibly direct memory approach to channels [problems root access?] -
could implement to some extent]
5) layers:
a) init -- -establish I/O channels access [what is
there/initialisation]
-peers mapfile -IP addresses to be polled // begins
mapfile expansion thru other nodes[d]
-data/cell space
b) I/O rw access -channels access abstracted
c) VM/interpreter -(array of cells)/ pointers / cell wall???
--handling cell identity.
d) management of cell instances/buffers/messages
--and polling [issues/accepts mapfile requests +checks
mapfile entries on diff port to network channel?]
6) what cell /cell space is and how defined -- relation between two.
-pointers/heads
-jump outside boundary
-cell wall as point of division/splitting (of code)// [in tierra
cells as semi-permeable in that cannot write into another cell's
interior but can read and execute another cell's code]
-are channel buffers external to cell space [YES]
-how we identify cell [WALL CODE]
IGNORE[7) possibility of event based interpretation of data for cells [raw data
converted to event data = recognition of change events and clusters of
repetition] -- could be difficult to implement]
8) channel buffers -- simply over-writing circular channel buffers read from
start pointer
9) flatten data space -- data/=/cell/=/template matching. is this feasible?
how we could implement flexible cell notion (does this go against a cell
wall idea? could parse entire environment/soup/memory space and deal with
cells as encounter templates)--
vm moves through generic cell space -- identifies and runs denoted cells and
updates structures for new cells.
[reflexive -- ideas from vm contribute to instruction set and architecture
as totality ie. as much as possible of vm/data structures to manage vm
should be in cell memory space itself]
10) for communication between nodes do we simply treat comms as another r/w
channel [or could we send larger data structures which could be seen as
transitory/network cells. also if go further into network as environment
becomes quite interesting as we can include environmental data such as hops
thru nodes //other ideas// perhaps could go for more mobile cell structure
-- mobile cells in mirrored data space -- shift mirror. cell
structure=mirrored data space]NO
stick to simple structure without too many impositions and see what happens
[towards unified / flattened structure for ap02 -- is possible all data
written to memory/soup space -- no stack/registers etc (but pointers are
registers - pointer to pointers to -- but still pointer memory ??) -- could
specify pointers with templates eg. [datwp (instruction)] [00001110](next
byte read as data) -- searches thru cell space for pointer when gets
instruction related to pointer -- can also change data bytes
(if pointer location was simply datwp say in memory then could not change
easily)]
] -- keep instruction pointer?
11) possible instructions/identifiers [how we address pointers and chunk
size of read/write needs be addressed before can go further]
a) read -- addresses rpointer and cpointer. read from cpointer channel into
rpointer address
b) write -- wpointer and cpointer. write to cpointer channel from rpointer
address
c) barrier -- write cell wall identifier [identity/size/ipointer
boundary] = split to two cells
d) jmp -- changes ipointer [or jmp to template dat match]
e) jmz -- jump if [what?] zero
f) copy cell -- to where? rpointer?
g) bitwise ops on next data
h) inc/dec/set pointers
i) identifiers: datw, datr, datc, datm
4 bit instruction (ignore most significant 4 bits in byte)
8 bit data
other ideas:
cell barrier identity is cell identity/identifier = repetition of a
sequence.
how could implement a cell merge thru templates
feb21/2002
devices work = ap0201
virtual work = ap0202
1) if we wish run ap0202 always in background don't really want display
in X -- would be good if served data at port x from ap0202 so can
connect to see current display via. thus two apps (ap0202 + display)
2) like to go further with event-based ideas (size/decision of pattern event
-- change/trigger in/of state)
.translation raw data to events via frame-size/chunking
.translation display channels to event-based display = mapping
(re-chunking/framing. diagrammatic forms) modular (structure) event // vm //
translator // foldback (of translation parameters onto to-be-translated
data)
receive event
pattern event (?) - framesize + fuzziness
event=time-based
so stored event data = issue of time-span (frequency) -- mapping of
occurrence to data
(FFT as interpretation(?) of time-based events)
also neural event models (barrier)
[for more real time performance system possible to map event structure onto
trigger playhead idea in buffers (triggers straight output of buffer x
data)--
means using both event[data] buffers and data buffers [2 buffers per write
channel]
micro events - granular
macro events -- // zoom of an FFT
3) +instruction - join to pull cells together via templates // contraction.
cell split/wall/join
4) possibly two passes to VM thru cell/memory space:
a) identifies and tracks previous cell identity. assign slices to newly
located cells
b) do instruction/cpu slice each cell
5) opcodes research --- 1) read -determined by register values = channel (mapfile also),to/from where
to/from where
2) write -= (depends on channel capabilities)
3) jmpf /jmp -to matching template /register offset /search (back)/fwd
4) jmz -if register zero
5) copy -to register offset / register amount [if use own memory as channel
then just use read/write] +1
6) join - pull two adjacent cells together
7) inc - register
8) dec - register
9/10) templates -nop1 -nop0
11) rotate - shift registers round 1234-2341
12) push - register onto stack
13) pop - off stack
14) set - set register to number
15) nop
16) spawn - new cell in next suitable space
pointers=registers (except IP tho could use as register)
when instruction refers to register looks at nops to determine which else
uses default
some jmp possibles could be achieved by use of IP as register
so far:
4 bit instruction set
16 bit registers (65536 2^16)
size of cellspace -- ?
Q is if enough use of registers in instruction set?
also only really reading 8 bits into it (but then incs possible??)
vm structure to include:
1) lifecycle
2) IP
3) registers & stack + associated pointers
4) start and end [not to write into another cell]
5) time since last write [overwrite cell if not write for x long]
6) slice number?
other instructions/ideas:
1) + [bitshift left register]
[mv address/?offset into register]
[search template --> offset/address to register]
[add / sub 2 registers]
[barrier=split]
From stock@v2.nl Wed Mar 6 11:34:49 2002
Date: Thu, 28 Feb 2002 16:35:32 +0100
From: Stock