Skip to content

Latest commit

 

History

History
416 lines (335 loc) · 13.5 KB

File metadata and controls

416 lines (335 loc) · 13.5 KB

Specifications

General restrictions being followed.

Element Restrictions

Note: There are 71 usable bits for element instance members, and 32 bits for quarks.

Personal Restrictions

Currently, the event window look-ups are restricted to adjacent sites, sites 1 through 4 as a HW implementation feasibility measure.

Allocations Types

The desired requirements for allocation, size management, systems are the following:

  • Containing a space with a specified shape
  • Able to specify a max allocation
  • Separates between different allocation IDs and from unknown elements
  • Growth of allocated space tries to fill available space
  • Deal gracefully with inconsistencies in shape of available space
  • Kill allocation process if unfeasible

Demos:

Bubble Allocation

  • Creates a circle of a max radius if given infinite room
  • Allocates using a max radius from a center point
  • Locates the centroid of a space if constrained
  • Standard allocation on display in github repo.

Development Process

The chosen bubble allocation process went through multiple development stages. The selection process involved multiple development groups, with Group 4 being chosen. More details in past commits.

CANCELED Group 1

Crystalline growth, limited by inconsistencies in available area

CANCELED Group 2

Initial amorphous growth attempt, unstable

CANCELED Group 3

Pulsing growth attempt, ran into growth instability, fuse problem

Group 4

Based on group 2, with a logic pass-over to improve stability

Even Distribution of Nuclei of same ID

  • Use barriers between nuclei of same ID
  • every nucleus/stem have a unique ID separate from type
  • transparent barriers form between nuclei of the same type
  • allocations will join up together upon death/finalization
  • if two of same ID meet, they should merge
  • emitters transmit through transparent barriers?

Future Work

  • [ ] Currently, Cytoplasm based distance measuring means internal non-Cytoplasm elements will alter the overall shape of the allocated space
  • [ ] Nucleus auto-centering works with simple organizations, current issues:
    • Edges of world are preferable to auto-center, going to expect edges to exist for now

Elements

The following elements make up the bubble allocation process.

Nucleus

  • This element initiates site allocation, by creating Cytoplasm elements, and setting their dist data member.
  • Has an ID, that is bestowed on Cytoplasm children.
  • The ID is used to separate allocated sites by purpose.
  • Two nuclei of differing ID will not merge, and will stay distinct.
  • Two nuclei of the same ID will share allocated sites.
  • A nucleus will die if it is surrounded by Membrane elements.
  • Nuclei currently attempt to auto-center themselves within spaces, see Future Work for progress concerning this.
  • Parameters:
    maxDist
    This parameter determines how much space is allocated.

Cytoplasm

  • This element serves as the primary mechanism for size management.
  • Keeps track of a distance value, that decrements going outwards from the nucleus, that is used to determine distance.
  • The life-cycle of Cytoplasm is strongly connected to the Membrane life-cycle.

Membrane

  • This element represents the boundary of allocated space.
  • This element forms as Cytoplasm elements contact unknown elements, Cytoplasm of a differing ID, or the max allocation range.

Path Allocation

  • Creates straight path of a given max width and length if given infinite room
  • Goal is the allocation of a path of a minimum width
  • Allocations from an edge outwards using a max width and max length
  • Ideally, will bend to use up available space

Development Process

Below are proposed development directions that this allocation can be accomplished by.

WAITING Edge Idea

  • Build layer by layer by active edge
  • The edge being built changes from cycle to cycle based on open sites

Blow Bubbles Idea

  • Using multiple bubble allocations
  • The centers of each bubble allocation form the path
  • Could have a distance restriction from previous bubble
  • While trying to separate self from other bubbles
  • Retracts if previous bubble moves too far away
  • Use transparent barriers and exciters to track nuclei separation
  • Variables
    N
    number of bubbles
    W
    Width of path
  • Path length ~ W(N/4 + 1/2)
  • Bubble radius ~ W/2
  • Bubble separation ~ W/4

WAITING Grow Noodle From Base Idea

  • Have forward edge handle collision and bending?

IN-PROGRESS Bristled Chain Idea

  • A chain element goes out with a priority directions.
  • There are ‘bristles’ on either side that detect the distance to an obstacle
  • And it turns based on the distances measured on either side
  • If the minimum distance is ever met, than the chain element will die
    • Will marking its direction as bad in its parent chain
    • If chain under min chain length, then it will retract and try again, making different direction choices
    • In this way, the chain will crawl backwards when a link dies
    • Hopefully finding a more optimal path
  • Could optimize by increasing amount of info kept about bad paths
  • Variables
    • Priority Direction
    • Min bristle distance
    • Max bristle distance
    • Max chain length
    • Min chain length
    • Bad Direction [4]
Logic
  • Pointing Priority
    • if d < Max
      • Turn Away onto not bad non-priority direction
    • elif d < Min
      • Die and mark as bad
    • else
      • Keep Straight
  • Else
    • if d < Max
      • Go current direction
    • elif d < Min
      • Die and mark as bad
    • else
      • Return to priority direction
Implementation Plan
Implement simple single width path

Only detects adjacent sites to chain, will detect non-adjacent chains and obstacles

Implement bristles, only detect on obstacles

Modify detection to be half of width, using new bristle elements Base on bubble centering logic

Implement prior path bristles detection by current bristles

Detect bristles from previous chains so the path will maximize turning radius and reduce bristle overlap

Add in optimization’s such as keeping more bad path info

Add in logic and more data to allow for path assumptions to reduce dead-end path attempts

Future Work

Not yet implemented

Elements

Path Stem

Chain

Bristle

Organization Levels

The following are the requirements for organization:

  • Relative addressing levels
    • Absolute addressing is not possible
  • Perform some kind of life-cycle management
  • Current Levels include:
    1. Organ Layer
    2. Lobe Layer
    3. Leaf Layer

Hierarchical Loop Organization

This forms the general organization of an organ. A hierarchical loop, where a central loop has a controlled distribution of contents. This distribution is then propagated through adjoining loops, indirectly.

Benefits

Higher throughput than a melange, more directed. Encapsulation of functionality. Protect information better?

Organization Summary

Organ

  • Bubble allocation
  • Variables
    • Max Radius
    • Organ ID
      • determine leave/stem IDs

Lobes (generic)

  • Path allocation
  • Variables
    • base width
    • max length

Leaves

  • Path allocation
  • Variables
    • Base width
    • max length
  • Stem ID
    • Determines filters

Notes

Organ

  • Hierarchical loop top-level
  • Primary address level
  • Has an allocation bubble
  • Basic I/O ports
  • Central kernel/node
    • Connects to lobes and I/O
  • Lobes have width, determines leaf height
    • Coil out into available space
    • Fit as many as possible with given width

Leaves

  • Grow within lobe wall
  • Circulated through system and embed where there is open space
  • simple loop
  • has base width
  • stem forms center
  • Filters grow from stars
    • perform data processing

Growth and Life-cycle

Leaf and Lobe Growth

  • Could be similar
  • Has base width
  • Pushes into growth medium
  • Stem path is important part of lobe growth
    • leaves can cross lobe boundaries
  • both could embed and grow?

Organ Life-cycle

  1. Organ stem exists
  2. Performs bubble allocation
  3. stem -> kernel
  4. Grows I/O lines
  5. Kernel inserts lobe stems
  6. Kernel inserts leave stems
  7. Open for business
  8. Homeostasis

Lobe Life-cycle

  1. Lobe stem exists
  2. embed self in kernel wall
  3. perform noodle allocation
  4. Homeostasis

Leaf Life-cycle

  1. Leaf stem exists
  2. Embeds self in lobe wall
  3. Performs noodle allocation
  4. Grows filters
  5. Homeostasis

Homeostasis

Allocation

  • Die if allocation issues found
  • Stem cells in permanent allocation, constant circulation
    • Promotes regrowth of failed leaves and lobes
  • If leave type missing or in short supply, cull population and replace
    • Determine percentage of each
    • Dynamically handle % based on input
      • starving leaves w/constant stem circulation?
  • Dynamic regulation of stems in kernel

Circulation

  • Kernel has a circular flow
  • I/O have straight flow

Gating

Gates change addressing levels? Could leaf data only be valid within organs? Needing a special conversion to be viable on the organ addressing level?

  • Organ ID based
    • Organ Gate
      • White-list data
    • Kernel Gate
      • White list data
  • Leaf ID Based
    • Leaf Gate
      • White-list data
  • Dynamic
    • Lobe Gate
      • Dynamically white-list based on contained leaf IDs

IDs

Organ IDs

  • Input data
  • Output data
  • Leaf ID distribution
  • Allocation size
  • Lobe width and length

Leaf ID

  • Input data
  • Filters -> Output Data
  • Width and Length

Development

Block out hierarchy

Implement Path Allocation

Melange Organ

Organs contain a mixture of operator elements. Much simpler structure than Hierarchical loop organization. Operator elements organize themselves into stratification, move around depending upon if they have available input elements.

Routing would be to an organ ID first than an operator.

Benefits

Simple

Inner Organization

Should only move when seeing data? Try to organize based on certain ideas?

????

Unsorted Notes

A collection of miscellaneous unorganized notes.

Robust Calculation Basics

  • Need multiple observes of input
  • Able to recover and not spoil whole calculation process by a single bad calculation
  • Single missing data element should not be an issue

Decay Cleanup

  • Like human
    • T-cells
    • Macro-phages
  • Like Ecosystem
    • Rot and decay
    • Multiple levels of decay, chewing and then breakdown

Ulam Implementation

  • Each processor is a pointer to the law if physics
  • Law of physics will need to be distributed in some fashion, maybe N processors per program memory
  • Law of physics are compiled code and each processors element is decided by what line (program counter) the element has

Organ Creation Regeneration

Organs regenerate insides If organ dies, takes too much damage to regenerate , it’s not rebuilt and organism will die

  • Shoot ?Egg? Into system, spawns organs which lead to organism
  • Entered from edge of tile
  • could fail, in that case shoot another egg in

Have some way of telling if tile organism has died or failed to gestate? Maybe a poison to clean up tile of partially developed organisms Or so simply power cycle tile

Calculation Hierarchy

Organ

  • Think standard library
  • queue, stack, sort, I/O interface

Organism

  • Appliance (Toaster, Soda Machine)
  • control system

Hide and Heal

  • when to know to heal??
  • error produce hormone, that at certain density leads to death?

Inter-Organ Communication

  • Could use medium distance field to guide a growing tendril
  • Goal would be to connect to a specific organ
  • Once connected, could be used for high throughput routing of info to that organ
  • if cut, could regrow

Communication Levels

Think about spatial travel

  • Train for long range
  • trucks mid range
  • walk short range (walking and diffusion)

Data storage

  • Could have special data storage elements
  • think barrels that you can load up on trains or trucks

What makes a destination unique? Why travel ?

  • Certain spatial locations are required for I/O and devices in general
  • need to make it to edges for I/O
  • what about processing ?

Road Signs

  • Perhaps major pathways exist and forks have road-signs saying what is which direction, and distance
  • Road-signs update periodically when they see still-alive signals?
  • Road signs communicate with one another about what they say

Databases

How to add/remove data within reason if stuff can go wrong?