Advanced Artificial Intelligence Lecture 19: ProgrammingBased GP: Machine Code StackBased

1
Advanced Artificial IntelligenceLecture 19
Programming-Based GP Machine Code Stack-Based

• Bob McKay
• School of Computer Science and Engineering
• College of Engineering
• Seoul National University

2
Outline

• GP based on programming languages
• Machine-code GP
• Stack-based GP

3
GGPS2

• Compiled Genetic Programming System
• Nordin Banzhaf dont actually give this system
  a name, but their earlier system was called CGPS

4
Turing-Complete Systems

• Many of the expression languages we will look at
  are not Turing complete
• But there are also a number of Turing-complete
  systems, often based on traditional programming
  paradigms
• We look at two
• Machine Code GP
• Stack-Based GP

5
Machine-Code Stack GP

• Share a number of properties
• Turing complete
• Able to represent function calls, recursion,
  iteration
• Linear representation
• Restricted genetic operations to preserve
  syntactic validity
• Slightly restricted languages to make this simple
• Restricted execution to preserve semantic
  validity
• Restricted memory reference
• Restricted execution time

6
Machine-Code GP

• Primary aim is to increase evolution speed
  through fast evaluation
• Programs can be evaluated at machine-code
  execution speed
• No requirement for an interpreter or compiler
• Described version target at SUN SPARC cpu
• Later for intel architecture - Discipulus
• Secondary aim to improve memory footprint
• Evolutionary system doesnt need an interpreter
• Can fit into smaller systems - eg embedded

7
SPARC Register Architecture

• 8 In-registers
• Used to hold input parameters in called function
• Copied from out-registers at start of execution
  (save)
• Copied back to in-registers at end (restore)
• Previous values of In-registers are held in local
  stack
• When this stack overflows, it is backed up to
  memory
• 8 Out-registers
• Used to hold call parameters from calling
  function
• Restored (by copying from In-registers) on call
  to restore op at end of function execution
• Can also be backed up to a stack (less important)

8
SPARC Register Architecture

• 8 Local registers
• Used to hold local variables for a function
• Also pushed and popped (stacked) when function is
  entered and exited
• 8 Global registers
• Used to hold global values
• Never pushed or popped
• Conventionally many registers are reserved for
  function call, specific global values

9
SPARC Register Architecture

• Registers available for evolved programs
• Global0
• In0 - in5
• Out0 - out5
• Local0 - local7

10
CGPS2 Instructions

• Some instructions omitted to permit arbitrary
  crossover mutation (general call, branch)
• CGPS2 allows

• XOR - exclusive or
• AND - logical and
• OR - logical or
• CL1 - CL7
• Jumps to address in local1 - local7

• ADD - addition
• SUB - subtraction
• MUL - multiplication
• SLL - shift left
• SRL - shift right

11
CGPS2 Evolutionary Operators

• Crossover
• Allowed only at 32-bit word boundaries
• Barred from changing header and footer of
  function
• If ADFs are used, then crossover is between
  corresponding ADFs

12
CGPS2 Evolutionary Operators

• Mutation
• If instruction has a constant part, mutate
• If instruction has no constant part, mutate type,
  source and destination registers
• Call and jump instructions may be mutated to
  other instructions

13
CGPS2 Memory organisation

• Memory for each individual divided up into
  fixed-size chunks, one for each possible ADF
• Chunk consists of an initial part, not subject to
  evolution
• saving and restoring call parameters, providing
  pointers to other ADFs
• Also includes a global variable, and code testing
  how often this function is called
• When a pre-defined bound is reached, execution is
  aborted

14
CGPS2 External Functions

• These constraints mean that CGPS2 can also call
  external functions
• Like ADFs, the calls to them can evolve
• Unlike ADFs, they are not themselves evolved

15
Push 3.0

• Stack-based language (like forth)
• Not only the representation language
• Also the programming language in which GP system
  is written
• The GP system can evolve itself

16
Push 3.0 Stacks

• Language built around stacks
• Data stacks, one for each type
• Integer, Float, Boolean
• Code stack
• For manipulating code
• Code is just a data type
• Can be
• Literal
• Instruction
• list
• Exec stack
• For executing code
• Same types as Code stack
• Code is not just a data type
• Name stack
• For names of literals

17
Push 3.0 Execution

• Before a Push 3.0 program is executed, it is
  loaded into the EXEC stack
• The execution cycle then loops
• If the first item on the stack is an instruction,
  execute it
• If it is a literal, pop it and push onto
  appropriate type
• (its a list)
• Pop it and push all the elements it contains back
  on the stack in reverse order (so first element
  is on top)

18
Push 3.0 Examples

• (2 3 integer. 4.1 5.2 float. true false
  boolean.or)
• Leads to
• Bool stack (true)
• Code stack ((2 3 integer. 4.1 5.2 float. true
  false boolean.or))
• Float stack (9.3)
• Int stack (6)

19
Push 3.0 Examples

• (5 1.23 INTEGER. (4) INTEGER.- 5.67 FLOAT.)
• Leads to
• Code stack ((5 1.23 INTEGER. (4) INTEGER.- 5.67
  FLOAT.))
• Float stack (6.9741)
• Int stack (1)
• INTEGER. acts as a NOOP because the
  corresponding stack entry isnt available
  (fail-safe behaviour)

20
More Push 3.0 Instructions

• Dup instruction duplicates the top of stack
• Define assigns a name (from NAME stack)
• Code.Quote instruction pushes its argument onto
  the Code stack

21
More Push 3.0 Examples

• (Integer.Dup Integer.)
• Doubles the first element on the integer stack
• (Double Code.Quote (Integer.Dup Integer.)
  Code.Define)
• Pushes the name Double onto the Name stack
• Pushes code to double a number onto the Code
  stack
• Pops Code and Name stacks, and defines Double
  to mean the sequence of code for doubling

22
Yet More Push 3.0 Instructions

• Exec.Y pops the top item (X) of the EXEC stack,
  pushes (X Exec.Y), then pushes X itself
• This allows the definition of most recursive
  control structures

23
Yet More Push 3.0 Examples

• (Exec.Y (ltBool with side effectsgt Exec.If ()
  Exec.pop))
• This leaves (ltBool with side effectsgt Exec.If ()
  Exec.pop) on top of the execution stack, and
  itself as the next item
• If the execution of ltBool with side effectsgt
  yields true, then Exec.If passes control to () -
  a NO-OP
• Execution passes to the next copy
• If it yields false, then executing Exec.pop
  removes the final copy from the EXEC stack
• Execution passes to the next instruction

24
Control Structures

• Note that the loop just given can be given a
  Code.Define, so new control structures can be
  defined
• Interpreter must provide a mechanism to limit the
  number of push evaluations
• (since infinite loops will almost certainly
  evolve)

25
Summary CGPS2

• Carefully restricted machine code language
• Mainly to ensure that semantically meaningless
  code cant be generated
• Restricted operators to ensure syntactic
  correctness is preserved
• Protected function headers to ensure function
  calling semantics are preserved and call limits
  are observed (avoid infinite loops)
• Fast evaluation as direct machine code, Turing
  complete

26
Summary Push3

• Very general-purpose evolutionary language
• Little restriction required on operators
• Almost any expression is meaningful
• Code can be evolved
• Including the code for the evolutionary engine
  itself
• Requires an interpreter
• Interpreter enforces Eval limits

27
?????