v2_lab technical notes::
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 To: m , Artem Baguinski Cc: artm@v2.nl, remco@v2.nl Subject: Re: ap0201/2 more stuff: HW-comments I'll add some comments to this, from a Hardware point of view, when i think it's relevant. Of course this pertains only to the HW-devices version (AP01 (?)) StK At 06:37 PM 27-2-02 +0000, m wrote: >ok will go thru bit by bit:> > > > numbers (opcodes) will be different, although i can rearrange them later > > to comply. anyway it'll start from 0. i like nop to be 0. > >is ok though with cell wall idea would arther use 0 as wall (doesn't >matter tho) > > > > > > 1) read -determined by register values = channel (mapfile > also),to/from where > > > to/from where > > > 2) write -= (depends on channel capabilities) > > > > we wanted to call them differently. i suggested mutate for one and say > > for the other. although say/listen is better pair i guess. > > > >let's go for say/listen The DTMF-chip generates an interrupt when valid data is received... so the 'listen' function can work in two ways: a) When an interrupt occured (some DTMF was heard) it is automatically written to the location in WP, and the 'listen' function will only listen to 'the wind'. b) on interrupt, 'heard' data is buffered (ugh) and the 'listen' function wil first try to read from this buffer & resort to 'the wind' when buf == empty i like option a) more, 'cos doing any serious buffering in a handfull of RAM is not fun... > > if channels are all one-way (and those potentially two-ways represented > > as two channels) we don't really need two instructions for this, do we? > > it'll be communicate then or "com" with one arg - channel number, and > > direction of the channel determines if it's say or listen. > > >sounds good to me suggestion a) above would make the 'heard' DTMF-data NOT a channel as such, it would be a sort of 'independent proces'... That would leave 'wind' (in) and 'say' (out) as channels, right? > > > 3) jmpf /jmp -to matching template /register offset /search (back)/fwd > > > > for now i made jmp
, but it is equal to set r0
(r0 > > is instruction pointer). should i change it to something interesting? > > > >we should go just with jmpf/jmpb search-jump to matching next template > > > > 4) jmz -if register zero > > todo > > > > > 5) copy -to register offset / register amount [if use own memory as > channel > > > then just use read/write] +1 > > what's that? > > > >just like you say further down we include own memory as channel so can >copy segments around > > > 6) join - pull two adjacent cells together > > what's that? > > > >this would be for virtual multi-cellular version > > > > 7) inc - register > > done > > > > > 8) dec - register > > done > > > > > 9/10) templates -nop1 -nop0 > > xxx > > > > > 11) rotate - shift registers round 1234-2341 > > todo. > > > > > 12) push - register onto stack > > > 13) pop - off stack > > do we need stack? why for? > >why not - creates bit more interest and allows more flexible swap of >register values the PIC has a 8-level HW stack, independant of RAM(!!) i think the VM will/should use it, but the instruction-set running ON the VM should maybe NOT have any knowledge of stack, just to keep things simple. :-) > > > > > 14) set - set register to number > > done > > > > > 15) nop > > done :) > > > > > 16) spawn - new cell in next suitable space > > what's that? > >again multi-cellular version > > > > > > 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 > > > > we can have up to 16 registers (arg0 is 4 bits, I use it to encode > > register number or channel number, so 16 registers, 16 channels). first > > three registers are special - instruction pointer, write pointer, read > > pointer. "rotate" let us use value from other registers. > > > >ok > > > does "copy" copy from channel to/from register? > > > >could do -- let's ditch copy tho and have memory as channel > > > > so far: > > > 4 bit instruction set > > > 16 bit registers (65536 2^16) > > > size of cellspace -- ? > > > > max 65536, coz ip is a register and can't address more. > >ok 'main mem' will be 32K, NOT 64K!!! > > > > it can be smaller, then memory is cyclic. in my test i created 20 bytes > > long memory. > > > >in multi-cell version is variable by cell wall templates > > > > Q is if enough use of registers in instruction set? > > > > more then enough. > > > > > also only really reading 8 bits into it (but then incs possible??) > > > > why? > >hmm maybe totally wrong here but reasoning was that if we can just read an >8 bit value into a register chances are it'll rarely go much further than >255 > > > > > probability of saying something is 1/16. it's not much. or is it > > enough? it should say something every 16 instructions in average... > > > >enough > > > is it's own memory also a channel? or even two channels - one for > > reading one for writing. then it's possible to copy chunks of data from > > place to place in memory ... > > > >that would be nice > >i've nearly finished rather ropey network modules.. would be good to have >a vm up and running soon to test all these ideas and see what really can >happen over long time periods. v excited > >see you soon] >mar > > > -- > > Artem Baguinski (http://www.artm.org/) > > V2_Lab - International Lab For the Unstable Media > (http://www.v2.nl/V2_Lab/) > > Eendrachtsstraat 10 - 3012 XL Rotterdam > > uuuh... OkDan! StK From stock@v2.nl Wed Mar 6 11:35:11 2002 Date: Thu, 28 Feb 2002 19:22:36 +0100 From: Stock To: m@1010.co.uk, remco@v2.nl Subject: Fwd: Re: ap0201/2 more stuff: HW-comments >X-From_: artm@nerve.v2.nl Thu Feb 28 19:12:51 2002 >Date: Thu, 28 Feb 2002 19:12:26 +0100 >To: Stock >Subject: Re: ap0201/2 more stuff: HW-comments >User-Agent: Mutt/1.3.27i >X-URL: http://nerve.v2.nl/ >From: Artem Baguinski > >Stock(stock@v2.nl)@2002.02.28 16:35:32 +0000: > > The DTMF-chip generates an interrupt when valid data is received... > > so the 'listen' function can work in two ways: > > > > a) When an interrupt occured (some DTMF was heard) it is automatically > > written to the location in WP, > > and the 'listen' function will only listen to 'the wind'. > > > > b) on interrupt, 'heard' data is buffered (ugh) and the 'listen' function > > wil first try to read > > from this buffer & resort to 'the wind' when buf == empty > > > > i like option a) more, 'cos doing any serious buffering in a handfull of > > RAM is not fun... > > > >virtual machine knows nothing about interupts [now]. > >option c: > >when VM doesn't listen, it doesn't care if somebody's speaking >[interrupt is masked, or ignored]. when VM listens - it waits till >somebody will say something. > >this will make it even more simple: no buffering, no interrupts on the >VM level. > > > >> if channels are all one-way (and those potentially two-ways represented > > >> as two channels) we don't really need two instructions for this, do we? > > >> it'll be communicate then or "com" with one arg - channel number, and > > >> direction of the channel determines if it's say or listen. > > >> > > >sounds good to me > > > > suggestion a) above would make the 'heard' DTMF-data NOT a channel as such, > > it would be a sort of 'independent proces'... > > That would leave 'wind' (in) and 'say' (out) as channels, right? > >suggestion c) would make DTMF data a channel again. > > > >> > 12) push - register onto stack > > >> > 13) pop - off stack > > >> do we need stack? why for? > > > > > >why not - creates bit more interest and allows more flexible swap of > > >register values > > > > the PIC has a 8-level HW stack, independant of RAM(!!) > > i think the VM will/should use it, but the instruction-set running ON > > the VM should maybe NOT have any knowledge of stack, > > just to keep things simple. :-) > >let's avoid mixing "real" and "virtual". PIC stack has nothing to do >with VM stack. VM exists as a program+data in PIC's memory. if there is >VM stack, it is somewhere in this memory. > > > >> > so far: > > >> > 4 bit instruction set > > >> > 16 bit registers (65536 2^16) > > >> > size of cellspace -- ? > > >> > > >> max 65536, coz ip is a register and can't address more. > > > > > >ok > > > > 'main mem' will be 32K, NOT 64K!!! > >it doesn't matter - VM is very safe (i'll write report tomorrow, coz i >have to go to school now). if address exceeds actual memory size it is >divided by modulo memsz :) so if main memory is 100 bytes and there's >"jmp 201" command it'll jump to "1" (201 % 100 = 1) > >so i was talking about max memory size. > >cellspace is a new concept, as Martin explained later [to me only???] > >ok, i'm running away. > >i implemented channels and copy command (copies 2 bytes between channel >and register). only VM's own memory channels are implemented so far. > >cheerz > >-- >Artem Baguinski (http://www.artm.org/) >V2_Lab - International Lab For the Unstable Media (http://www.v2.nl/V2_Lab/) >Eendrachtsstraat 10 - 3012 XL Rotterdam feb 25 2002+:: 1) event model is about reducing amount of data -could even use neural network model here (own research notes) 2) data sequences // linked list of cells data sequence expansion -- start from smallest sequence (example LZW compression) sequence AB ABC tree structure ABC sequence is code of AB + C becomes new code for ABC data -> tree/net structure [but Q is each cell would need to store its own tree structure/mapping] 3) 3 layer system --> a) 8 bit data -> mirror B b) mirror B -> mirror C = event pointers to mirror B /or/ resequence/net of B 4) what if instruction set and architecture of VM not borrowed from current models - no IP/registers etc - translation of no step through -- pure fragment (non)functional (no step through but an expansive search and openness) event and no event reflect probable use of an architecture sequential -- parallel against itself / of whether we are using something (a machine) against what it is used FOR and if is a problem use FROM no use FROM - no logic built from a logic gate undecidable switch -- standing system of notation [of reverse question] of encoded performance system of no logic from the very begining base level/our hardware