WO2007037710A2 - Dispositif de calcul informatique pour gestion d'ensembles - Google Patents
Dispositif de calcul informatique pour gestion d'ensembles Download PDFInfo
- Publication number
- WO2007037710A2 WO2007037710A2 PCT/NZ2006/000255 NZ2006000255W WO2007037710A2 WO 2007037710 A2 WO2007037710 A2 WO 2007037710A2 NZ 2006000255 W NZ2006000255 W NZ 2006000255W WO 2007037710 A2 WO2007037710 A2 WO 2007037710A2
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- cursor
- child
- identification
- proxy
- handle
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Ceased
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45504—Abstract machines for programme code execution, e.g. Java virtual machine [JVM], interpreters, emulators
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
- G06F9/5061—Partitioning or combining of resources
- G06F9/5072—Grid computing
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/40—Transformation of program code
- G06F8/41—Compilation
Definitions
- This invention relates to Computer Science and has applications in Information and Communication Technology (ICT).
- ICT Information and Communication Technology
- the invention is particularly suited for systems that require storage and retrieval of set structures founded on Set Theory. Sets can be applied in diverse applications such as XML, filing systems, databases and mathematical constructs evaluated with computational systems.
- Set Theory was developed by Gregory Cantor almost 300 years ago. It forms a foundation of mathematics and is a useful mechanism for modelling information systems. There are many versions of Set Theory, each with varying axioms that create subtly different universes with different properties.
- the present invention uses a unique set of axioms that are optimised for the manipulation of sets from a computational perspective. The invention allows for the storage of sets as well as managing instructions to manipulate their contents.
- the invention provides a computational device including a data manipulation and/or storage structure representing a plurality of sets of data storage locations, each set having a parent set identifier and containing a linked list of one or more child storage locations wherein each parent set identifier references a child storage locations in the set, and wherein each child storage location can reference its parent storage location.
- each parent set identifier references a plurality of markers that each reference a single child storage location.
- an interface is provided that can manipulate data storage locations by means of a marker.
- Each parent set identifier may be capable of attaching primitive data structures or files.
- the data manipulation may trigger events.
- the invention provides a data structure representing a plurality of sets of data storage locations, each set having a parent set identifier and containing a linked list of one or more child storage locations wherein each, parent set identifier references a child storage locations in the set, and wherein each child storage location can reference its parent storage location.
- each parent set identifier references a plurality of markers that each reference a single child storage location.
- the invention can be used in conjunction with other circuits to produce useful computational processes for the manipulation of sets.
- the invention can be used for constructing compilers for an Interoperable Information Infrastructure model (Ill-model), storage mechanisms, educational and experimental mathematical systems. These systems can be used to deliver products and generate revenue.
- Ill-model Interoperable Information Infrastructure model
- storage mechanisms storage mechanisms
- educational and experimental mathematical systems These systems can be used to deliver products and generate revenue.
- the unique mathematics of the invention is derived from Set Theory to provide total protection against attack when used with a computationally complete environment that utilises the invention as its memory store. If the software is required to communicate with other software, it can perform this communication across a single set. The software is then required to take additional steps to prevent this communication from posing any risk. This mechanism is known as a Reference Membrane. Introspective scope of execution prevents software from accessing other software for which it does not contain a reference - a property exhibited from the hardware itself.
- the invention has only one instruction to obtain a new reference (known as Get-Child and is described further below), which retrieves a specified Child set from within a Parent set. There is absolutely no instruction to retrieve the reference to a Parent set even though these sets may exist privately and in plurality in the. invention.
- Get-Child a new reference
- the set structure according to a preferred embodiment of the invention is referred to herein as the Manabars-Set. It provides a foundation mathematical structure that can be used as a generic container to hold any kind of information. Furthermore, the Manabars-Set is super- symmetric, meaning that there is no logical limit to the amount of data that it can hold, or the number of relationships that may exist between any sets. The mechanics of the Manabars-Set provides an efficient way of structuring information to help reduce complexity and increase productivity for developers and users of software.
- the invention is an abstract design of a circuit that can be implemented in a number of ways in software, CMOS, FPGA or other exotic computational environments such as SpintronicsTM, Quantum Computing or biological computers.
- the invention communicates with other external components via a series of buses known as the Kl-lnterface.
- Each Kl-lnterface bus allows the sets contained within the invention to be manipulated by an external circuit utilising the bus.
- the bus operates by sending a continuous stream of instructions to the invention.
- Each instruction on the bus may have numerous parameters and returns.
- the invention starts up with a single set known as the Powerset.
- the Kl-lnterface By using the Kl-lnterface repeatedly, an image can be pre-installed.
- the invention can be modified at several points to allow for the fast loading of pre-existing images instead of using the Kl-lnterface.
- FIG. 1 A first figure.
- FIG. 1 shows the preferred embodiment of the invention also known as the Kernel-Image.
- the Kernel-Image (2800) is accessed by the Kl-lnterface (2810).
- the Kl- lnterface has 6 high priority channels (2870a-f) and 6 low priority channels (2875a-f). It also has a Backplane-Bus (2900) to allow instructions to flow between Isolated-Memory-Segments (2910a-c).
- FIG. 2 shows the Manabars-Set is composed of four basic structures.
- the Parent-Identification holds the set data
- the Cursor-Identification marks the Cursor position
- the Child-Identification locates the associated Parent for that Child and the Proxy-Identification is a structure to manage dynamic manipulation of the link lists.
- FIG. 3 shows the Parent-Identification links to the Cursor-Identification and the Child- Identification only. It contains four fields being the Leftmost-Cursor-Handle, the Rightmost- Cursor-Handle, the Leftmost-Child-Handle and the Rightmost-Child-Handle. It also contains the content associated with this Parent. In the preferred embodiment, this content contains primitives such as a 64-bit integer or a 64-bit floating-point number.
- FIG. 4 shows the Child-Identification is a linked list structure of Children sets that maintains ordering.
- FIG. 5 shows the Proxy-Identification links to the Cursor-Identification and the Child- Identification. It is useful for tracking connectivity through such instructions as the deletion of a Child from a Parent that could lead to Cursor-Identifications sharing a single Child.
- FIG. 6 shows the Cursor-Identification that contains the Left-Cursor-Handle and the Right- Cursor Handle that make it form part of a linked list of Cursor-Identifications inside a single Parent.
- the Parent-Handle-Port is able to locate the Parent-Identification of the Child to which it points. It is also able to locate the appropriate Proxy-Identification so that it can locate other Cursor-Identifications or Child-Identifications.
- FIG. 7 shows the Cursor-Identification that contains the Left-Cursor-Handle and the Right- Cursor Handle that make it form part of a linked list of Cursor-Identifications inside a single Parent.
- the Parent-Handle-Port is able to locate the Parent-Identification of the Child to which it points. It is also able to locate the appropriate Proxy-Identification so that it can locate other Cursor-Identifications or Child-Identifications.
- FIG. 7 shows the Cursor-Identification that contains the
- FIG. 7 shows the Cursor-Identification-Content (4000) that is used to manage the CUI-Monitor- Event (4010). It also shows the Proxy-Identification-Content (4020) that holds the Proxy-Size (4030).
- FIG. 8 shows the Child-ldentification-Content (4200) that holds the CHI-Monitor-Event (4210) and the Left-Index (4220).
- FIG. 9 shows the Parent-Identification-Content (4400) that holds the primitives that are attached to the set as well as additional indexing information.
- FIG. 10 shows an arbitrary Manabars-Set (4800) in a manner that highlights how the handles reference elements of the set.
- FIG. 11 shows a single Manabars-Set (5000) that can have 3 Monitor-Events (5100) attached at the PI-Monitor ⁇ Event (5015), CHI-Monitor-Event (5025) and CUI-Monitor-Event (5035).
- Monitor-Events 5100 attached at the PI-Monitor ⁇ Event (5015), CHI-Monitor-Event (5025) and CUI-Monitor-Event (5035).
- FIG.13 shows a UPT-Monitor-Generator (5400) that is used to capture the state of a single Kl- lnterface method call.
- FIG. 13 shows the MG-Capture-lnstance (5600) that is used to assist the UPT-Monitor- Generator.
- FIG. 14 shows the MG-Capture-lnstance (5600) that is used to assist the UPT-Monitor- Generator.
- FIG. 14 shows a physical deployment of the Kernel-Image that includes the Kl-lnterface to enable access to the Kl-Memory via Cursor-Identifications.
- FIG. 15 shows the structure of a Monitor, used to trigger events.
- the components in the invention that are constituted directly from the host platform are known as real entities and are represented with rectangles with unbroken lines.
- Real entities can be either simulated in software or constructed directly in hardware as this represents all design behaviour directly attributable to the implementation platform. All rounded rectangles represent Manabars-Sets that operate as virtual entities.
- a single Cursor-Identification reference can be represented with an arrow that identifies the Child to which the Cursor points.
- a single Parent-Identification reference can be represented with multiple arrows that identify all Cursor-Identifications within the Manabars-Set.
- the dark arrow represents the Cursor-Identification that was used to identify this Parent- Identification, while white arrows represent other Cursor-Identifications present for the shared Parent-Identification.
- Manabars-Sets are used as Fields that hold Values. In some instances, this Value data may not be present and is equivalent to Null in C. Value data is symbolised with a dashed line, which distinguishes it from the context or Set superstructure.
- Child # 1 (202) Child # 2 (203) Child # 2 (202)
- any item may be left out if it is deemed not to be relevant to the element being represented.
- the only requirements are that the scope is preserved, but. any number of sets may be ignored. If A contains B and B contains C, then visually Parent A may contain Child C 1 but Parent C cannot contain Child A - not unless C contains something that contains A. In this case, the object explicitly repeats its scope and it is likely to be represented by the Repeated Scope method below.
- Manabars-Sets where the scope has repeated. These are important for understanding security constraints, as the Manabars-Set only allows for introspective access.
- a Manabars-Set that re-introduces a distant Parent as a Child converts all the Manabars-Sets between the scopes of the 2 identical repeats into a single security access zone.
- Label names are joined by dashes so that the object name can be clearly identified in a sentence such as Governance-Layer-Interface. Not all labels are objects, some are phrases that start with a Capital letter, contain no full stop and preserve the capitalisation of names. For example - Partner Node - does not use a dash as this is a phrase starting with a capital ⁇ Partner), and a capital for a name [Node). When using a name in another name, only the acronym should be used for the referenced name, for example, Governance-Layer-Interface- Instance becomes GLI-lnstance. Names retain their capitalisation through minor word changes imposed by language such as plurals in Child and Children. TYPE IDENTIFICATION
- the Type information is highlighted at the bottom right of the Manabars-Set.
- Communication occurring across an interface is declared with a box with a dashed line where the name ends is 'Interface'.
- the polarity of the interface is indicated with a (+) and (-) depending on the symmetry required.
- a reversed polarity means that components implement opposite calls on the interface.
- An exemplary embodiment of the invention is when it operates as a memory store of sets founded on Set Theory and is likely to be housed within a more complex machine.
- the invention provides a dynamic container for a special variety of sets which are referred to herein as Manabars-Sets.
- the Manabars-Set is a mechanical structure to represent a variant of Set Theory in a computational form that is flexible enough to achieve computational completeness but yet preserve scope as inherited from Set Theory.
- the Manabars-Set structure is optimised for implementation through the use of array structures, which are readily available on computing platforms with sequential addressable memory.
- the Manabars-Set is representative only of the idealistic set structure alone and does not include the mathematical operators such as Union and Intersection. These operators are required to be derived at another level through the use of a program and are outside the scope of the Manabars-Set.
- the Manabars-Set deviates from traditional Set Theory as originally outlined by Gregory Cantor.
- the Manabars-Set can contain any number of Children sets and any Child can be repeated any number of times. Furthermore, Children are arranged sequentially from one pole to the other and are referred from Left to Right.”
- Manabars-Set In order to enable efficient computability of the Manabars-Set, individual Children are identified through the use of an element having the ability to act as a marker or pointer, which we refer to in this document as a Cursor.
- a single Cursor will point to a single Child that belongs to a single Parent.
- a preferred embodiment of the Manabars-Set enables a system that has access to Cursor references and is not able to alter the Parents or Children directly. However, a single Parent may have any number of Cursors.
- the invention utilises the Kl-lnterface (2810 of FIG. 1 ) to allow alteration to the structure using the Cursor references alone.
- This interface will allow for the manipulation of the Manabars-Set through method calls such as shifting a Cursor to the Leftmost position (see Appendix A).
- a preferred embodiment of the invention would implement these method calls and alter the array structures that represent the Manabars-Set directly.
- the Manabars-Set (3000 of FIG. 2) is the fundamental and only data type used by the invention (2800 of FIG. 1) to store and represent all information.
- a unique handle identifies each Manabars-Set. Although a Manabars-Set can be thought of abstractly as a unique entity, it is actually related to other Manabars-Sets in the invention in complex ways.
- the structure of the Manabars-Set is made up of 4 individual structures which each have their own values and links. These structures are the Cursor-Identification (3030 of FIG. 2 and 3800 of FIG. 6), the Parent- Identification (3040 of FIG. 2 and 3200 of FIG. 3), the Child-Identification (3020 Of FIG. 2 and 3400 of FIG. 4) and the Proxy-Identification (3010 of FIG.
- the Cursor-Identification (3030 of FIG. 2 and 3800 of FIG. 6) structure is the only frame of reference that Emulator-Components can use to modify the invention (2800 of FIG. 1) through the Kl-lnterface (2810 of FIG. 1).
- the remaining structures of the Parent-Identification (3040 of FIG. 2 and 3200 of FIG. 3), the Proxy-Identification (3010 of FIG. 2 and 3600 of FIG. 5) and the Child-Identification (3020 of FIG. 2 and 3400 of FIG. 4) are hidden from direct access and so are perceived as a simpler entity.
- FIG. 10 shows 2 exemplary Manabars-Sets (4800 & 4920) that have been referenced with a Cursor-Identification (3030 of FIG. 2 and 3800 of FIG.
- the Cursor-Identification handle renders a simplistic view of a Manabars-Set Parent (4800 of FIG. 10) that contains any number of other Manabars-Sets that form its Children (4810 - 4860 of FIG. 10) in a chain. Only one of these Children, the Selected-Child (4840 of FIG. 10) must hold the unique position in the Manabars-Set that is pointed to by the Cursor (4890 of FIG. 10). If there are no Children, then the Cursor (4860 of FIG. 10) points to an identifier called No- Child (4930 of FIG. 10) that represents an empty set.
- Figure 6 shows all the fields that make up the structure of the Cursor-Identification and how they link to the other structures. These include the following:
- the Cursor-Proxy-Handle (3810 of FIG. 6 field references the Proxy-Identification (3870 of FIG. 6 and 3010 of FIG. 2) to which this Cursor-Identification belongs.
- PARENT-HANDLE-PORT
- the Parent-Handle-Port (3820 of FIG. 6) field points to the Parent-Identification (3860 of FIG. 6 and 3040 of FIG. 2) to which this Cursor-Identification belongs. This is a mechanism for any Cursor-Identification to find the Parent-Identification that it may share with many other Cursor- Identifications. In the example in FlG. 10, it points to the Parent (4800 of FIG. 10).
- the actual Cursor-Identification is determined by a linked list of Cursor-Identifications built by chaining from the Left-Cursor- Handle (3830 of FIG. 6) to the Right-Cursor-Handle (3840 of FIG. 6). This is used to locate the Left-Cursor (4840 of FIG. 10) and Right-Cursor (4900 FIG. 10).
- the chains are terminated at either end of the chain with a unique identifier called Cursor-Terminator (4950 and 4970 of FIG. 10), which differentiates it from a genuine reference to another Cursor-Identification.
- the Cursor-Identification-Content (3890 of FIG. 6 and 4000 of FIG. 7) contains a single field - the CUI-Monitor-Event (4010 of FIG. 7).
- the CUI-Monitor-Event (4010 of FIG. 7 and 5035 of FIG. 11) field provides a handle to a Monitor-Event (5100 of FIG. 11) that contains Monitors (5110a - 511On of FIG. 11). These Monitors are required to be triggered with activity relating to the Cursor-Identification (3030 of FIG. 2) during the implementation of Kl-lnterface instructions.
- the Parent-Identification (3040 of FIG. 2 and 3200 of FIG. 3) structure is a hidden frame of reference and is used internally by the Kernel-Image (2800 of FIG. 1) as a superstructure to hold references to Cursor-Identification (3030 of FIG. 2 and 3260 of FIG. 3) and Child- Identification (3020 of FlG. 2 and 3250 of FIG. 3) structures.
- the Parent-Identification acts as a common Parent for all Cursor-Identifications (3260 of FIG. 3 and 3030 of FIG. 2) that it holds, so it contains the shared information that represents a single Manabars-Set.
- the Cursor- Identification has a reference to the Parent-Identification called the Parent-Handle-Port (3270 of FIG. 3 and 3820 of FIG. 6).
- Figure 3 shows all the fields that make up the structure of the Parent-Identification and how they link to the other structures. These include the following:
- the Leftmost-Cursor-Handle (3210 of FIG. 3) and Rightmost-Cursor-Handle (3220 of FIG. 3) locates the Leftmost-Cursor-Identification (4870 of FIG. 10) and Rightmost-Cursor-Identification (4910 of FIG. 10) for this Parent-Identification (3200 of FIG. 3 and 3040 of FIG. 2).
- a Manabars-Set (3000 of FIG. 2) contains no Children
- there is only 1 Cursor for the Parent-Identification so the Leftmost-Cursor-Handle and the Rightmost-Cursor- Handle both use the same Cursor-Identification (4890 of FIG. 10) - even though this Cursor- Identification itself has a Child-Handle that points to No-Child instead of a genuine Child- Identification (3020 of FIG. 2).
- the Leftmost-Child-Handle (3230 of FIG. 3) and Rightmost-Child-Handle (3240 of FIG. 3) contains the Leftmost-Child-Identification (4810 of FIG. 10) and Rightmost-Child-ldentification (4860 of FIG. 10) of a Manabars-Set (3000 of FIG. 2).
- both the Leftmost-Child-Handle and Rightmost-Child-Handle fields point to the No-Child identifier (4930 of FIG. 10) that differentiates them from their normal context where the handle would otherwise point to a genuine Child- Identification (3250 of FIG. 3 and 3020 of FIG. 2).
- the Parent-Identification-Content (3225 of FIG. 3 and 4400 of FIG. 9) contains 15 fields listed below:
- the Number-Of-Children (4410 of FIG. 9) contains the number of unique Child-Identifications (3020 in FIG. 2) for this Parent-Identification (3040 of FIG. 2).
- the Child-Identifications are chained together as other Manabars-Sets in a linked list.
- the Number-Of-Children is the total number of Children (4810 - 4860 of FIG. 10) in the arbitrary Manabars-Set (4800 of FIG. 10).
- the Index-Integrity (4430 of FIG. 9) is a boolean field holding True or False. A value of True indicates the Left-Index (4220 of FIG. 8) is correct. If the value is False, then the index should be recalculated before the result for the Get-Index is called.
- Reset-Index (4500 of FlG. 9) is a boolean field holding True or False.
- a value of False indicates that no change has occurred in the Parent-Identification (3040 of FIG. 2) since the last Kl-Get- Index method call.
- the Kernel-Image (2800 of FIG. 1) holds a reference to the last Child- Identification (3020 in FIG. 2) that had its Left-Index (4220 of FIG. 8) updated.
- a value of True indicates that the KI-Get-lndex call has to start again from the Leftmost-Child-ldentification held in the Leftmost-Child-Handle (3230 of FIG. 3).
- Number-Of-Cursors (4420 of FIG. 9) contains the number of unique Cursor-Identifications (3030 of FIG. 2) for the shared Parent-Identification (3040 of FIG. 2).
- Each Child may have any number of Cursors, each represented by a unique Cursor-Identification.
- Each Cursor- Identification may be separated by any number of Children.
- Pi-Monitor-Event (4490 of FIG. 9 and 5015 of FlG. 11) provides a handle to a Monitor-Event (5100 of FIG. 11) that contains Monitors (5110a - 511On of FIG. 11). These Monitors are required to be triggered with activity relating to the Parent-Identification (3040 of FIG. 2) during the implementation of Kl-lnterface instructions.
- the Whole (4440 of FIG. 9) contains a 64 Bit numerical value that does not have a decimal point.
- the Float (4450 of FIG. 9) contains a 64 Bit numerical value that includes a floating decimal point.
- the Fast-ABS-Handle (4460 of FIG. 9) contains a unique key that is used to locate a Bit- Sequence in the Fast-ABS.
- the Slow-ABS-Handle (4470 of FIG. 9) contains a unique key that is used to locate a Bit- Sequence in the Slow-ABS.
- the Type (4480 of FIG. 9) contains a Whole number that identifies the Type of the Manabars- Set.
- the Number-Of-lnserts (4510 of FIG. 9) contains a Whole number that identifies how many times this Parent-Identification is inserted as a Child inside another Manabars-Set (3000 of FIG. 2).
- the Whole-Hashkey (4520 of FIG. 9) contains a Whole number that is used as a unique identifier based on the Whole values of all the Children of the Manabars-Set (3000 of FIG. 2). Any one of many algorithms may be used for determining the Whole-Hashkey.
- the Float-Hashkey (4520 of FIG. 9) contains a Whole number that is used as a unique identifier based on the Float values of all the Children of the Manabars-Set (3000 of FIG. 2). Any one of many algorithms may be used for determining the Float-Hashkey.
- FAST-ABS-HASHKEY FAST-ABS-HASHKEY
- the Fast-ABS-Hashkey (4520 of FIG. 9) contains a Whole number that is used as a unique identifier based on the Fast-ABS-Handles of all the Children of the Manabars-Set (3000 of FIG. 2). Any one of many algorithms may be used for determining the Fast-ABS-Hashkey.
- the Slow-ABS-Hashkey (4520 of FIG. 9) contains a Whole number that is used as a unique identifier based on the Slow-ABS-Handles of all the Children of the Manabars-Set (3000 of FIG. 2). Any one of many algorithms may be used for determining the Slow-ABS-Hashkey.
- the Child-Identification (3020 Of FIG. 2 and 3400 of FIG. 4) structure forms a linked list of Manabars-Sets (3000 of FIG. 2) that are all Children of a common Parent-Identification (3450 of FIG. 4 and 3040 of FIG. 2).
- the linked list is terminated on either end when the Left-Child- Handle (3410 of FIG. 4) and the Right-Child-Handle (3420 of FIG. 4) equals the No-Child identifier.
- the Left-Child-Handle (3410 of FIG. 4) and Right-Child-Handle (3420 of FIG. 4) provides references to the adjacent Child-Identifications (3400 of FIG. 4 and 3020 of FIG. 2) that are the Left-Child-ldentification (4830 of FIG. 10) and Right-Child-ldentification (4850 of FIG. 10) that create a linked list of Children Manabars-Sets (3000 of FIG. 2) for this Parent-Identification (3450 of FIG. 4 and 3040 of FIG. 2).
- the Child-Proxy-Handle (3430 of FIG. 4) provides a handle to a Proxy-Identification (3480 of FIG. 4 and 3010 of FIG. 2) that contains all the Cursor-Identifications (3490 of FIG. 4 and 3030 of FIG. 2) that are currently pointing to the Child-Identification (3400 of FIG. 4). If there are no Cursor-Identifications currently pointing to the Child-Identification then the Child-Proxy-Handle will point to a No-Proxy identifier that differentiates it from a genuine reference to another Proxy- Identification. PARENT-HANDLE-STARBOARD
- the Parent-Handle-Starboard (3440 of FIG. 4) provides a handle to the Cursor-Identification (3490 of FIG. 4 and 3030 of FIG. 2) to which this Child-Identification (3400 of FIG. 4) refers.
- Child-Identification-Content (3445 of FIG. 4 and 4200 of FIG. 8) contains 2 fields listed videow:
- the CHI-Monitor-Event (4210 of FIG. 8 and 5025 of FIG. 11) provides a handle to a Monitor- Event (5100 of FIG. 11) that contains Monitors (5110a - 5110n of FIG. 11). These Monitors are required to be triggered with activity relating to the Child-Identification (3020 of FIG. 2) during the implementation of Kl-lnterface instructions.
- the Left-Index (4220 of FIG. 8) field holds the last known index that the Cursor occupies from the Leftmost Manabars-Set (3000 of FIG. 2).
- the Right-Index is the last known index that the Cursor occupies from the Rightmost Manabars-Set and is calculated through subtracting the Left-Index from the Number-of-Children (4410 of FlG. 9). The integrity of these indexes should be checked with the Index-Integrity field (4430 of FIG. 9). If False, the indexes should be recalculated before use with the Get-Index method.
- the Proxy-Identification (3010 of FIG. 2 and 3600 of FIG. 5) structure forms a linked list of Cursor-Identifications (3650 of FIG. 5 and 3030 of FIG. 2) that are currently pointing to a Child- Identification (3670 of FIG. 5 and 3020 of FIG. 2).
- the Main and the Sublevel Proxy-Identifications (3600 of FIG. 5) are distinguished through the Proxy-Handle (3620 of FIG. 5).
- a Main Proxy-Identification holds an identifier of No-Proxy in the Proxy-Handle. If the Proxy-Handle holds a reference to another Proxy-Identification then it is considered to be a Sublevel Proxy-Identification.
- the Main Proxy- Identification fields are kept up to date after each Kl-lnterface method call, while the Sublevel Proxy-Identification fields are not always reliable with the exception of the Proxy-Handle (3620 of FIG. 5).
- a background process may synchronise the Main and Sublevel-Proxy-ldentifications on a regular basis.
- the Proxy-Child-Handie (3610 of FIG. 5) field holds the handle to the Child-Identification (3670 of FIG. 5 and 3020 of FIG. 2) that is pointed to by all of the Cursor-Identifications (3650 of FIG. 5) inside the Proxy and represents the Selected-Child (4840 of FIG. 10). If the Manabars-Set is empty, the Proxy-Child-Handle should hold the state of No-Child, differentiating it from an actual handle to a genuine Child-Identification.
- the Proxy-Handle (3620 of FIG. 5) field is utilised when there is more than one Proxy currently referencing the same Child-Identification (3670 of FIG. 5 and 3020 of FIG. 2). This would happen in the event of Delete-Child Kl-lnterface method call, or an Insert-Child Kl-lnterface method call in the situation of a number of Cursor-Identifications (3650 of FIG. 5 and 3030 of FIG. 2) shifting over to reference another Child-Identification (3670 of FIG. 5) at the same time.
- the Main Proxy-Identification (3600 of FIG. 5) currently pointing to the new Child-Identification has its Proxy-Handle (3620 of FIG. 5) updated to reference the Proxy- Identification that is being moved, thereby becoming a Sublevel Proxy-Identification, and the Proxy-Identification that is being moved will become the Main Proxy-Identification referenced by the new Child-Identification.
- the Proxy-Leftmost-Cursor-Handle (3630 of FIG. 5) and Proxy-Rightmost-Cursor-Handle (3640 of FIG. 5) locates the first and last Cursor-Identifications (3660 of FIG. 5 and 3030 of FIG. 2) that are inside the Proxy. All Cursors in between the first and last Cursors can be found using the Left-Cursor-Handle (3830 of FIG. 6) and Right-Cursor-Handle (3840 of FIG. 6) of the Cursor-Identification. Any Sublevel Proxy-Identifications (3600 of FIG.
- the Proxy-Identification-Content (3615 of FIG. 5) contains a single field - the Proxy-Size.
- the Proxy-Size (4030 of FIG. 7) holds the amount of Cursor-Identifications (3660 of FIG. 5 and 3030 of FIG. 2) currently referencing the same Proxy-Identification (3600 of FIG. 5). Any Sublevel Proxy-Identifications are considered to be part of the Main Proxy-Identification, which means that the Proxy-Size of the Main Proxy-Identification includes all the sizes of any Sublevel Proxy-Identifications. If a Cursor-Identification (3660 of FIG. 5) is shifted into, or out of the Main Proxy-Identification or any of its Sublevel Proxy-Identifications then only the size of the Main Proxy-Identification is updated.
- the invention in the embodiment described is implemented in a module known as the Kernel- lmage(2800 of FIG. 1), hence the term "Kernel-Image” is also used in this document to refer generally to the invention.
- the invention may act as a central repository for information by other devices. Every Manabars-Set (3000 of FIG. 2) is stored within the invention. The outermost Manabars-Set is known as the Powerset. Manabars-Sets can only be accessed through the Kl- lnterface (2810 of FIG. 1), so other Emulator-Components can't access the KI-Memory (2610 of FIG. 14) directly. All handles to manipulate Manabars-Sets are of the type Cursor-Identification (3030 of FIG.
- the KI-Memory (2610 of FIG. 14) is used to store every Manabars-Set (3000 of FIG. 2) within the Kernel-Image (2800 of FIG. 1). It is likely that the implementers of the invention may use arrays to represent every field in the Parent-Identification (3040 of FIG. 2), the Cursor- Identification (3030 of FIG. 2), the Child-Identification (3020 of FIG. 2) and the Proxy- Identification (3010 of FIG. 2).
- the KI-Memory is the primary memory system in the Emulator. KI-INTERFACE
- the Kl-lnterface (2810 of FIG. 1) is the only conduit through which Emulator-Components can access the KI-Memory (2610 of FIG. 14).
- the Kl-lnterface should allow any number of methods to be called in parallel, provided that they do not utilise any identical Cursor-Identification (3030 of FIG. 2 and 3800 of FIG. 6) handles and they don't share a common Parent.
- a separate Channel (2870a - 287Of and 2875a - 2875f of FIG. 1) is required.
- There are two types of Channels (1) High-Priority-Channels (2870a - 287Of of FIG.
- FIG. 1 shows the Kl-lnterface configuration that is optimised for silicon, having 6 High-Priority-Channels and 6 Low-Priority-Channels.
- Each Channel acts as a parallel interface to the KI-Memory (2610 of FIG. 14) that conforms to the Kl- lnterface and each will be blocked by the Request-Blocker (2890a - 289Of & 2895a - 2895f of FIG. 1) if it is already busy with a request. If multiple requests are made, the Request-Blocker should queue these.
- Each Channel may have its own Implementation-Logic (2880a - 288Of and 2885a - 2885f of FIG. 1), so that requests may be processed in parallel.
- the minimal implementation is a single Implementation-Logic unit (2627 of FIG. 14) that services High- Priority-Channel requests before Low-Priority-Channel requests.
- the KI-Memory (2610 of FIG. 14) may not allow absolute parallel access for all the Implementation-Logic (2627 of FIG. 14) components.
- these Request-Blockers (2626a of FIG. 14) for the High-Priority-Channels (2625a of FIG. 14) should each rotate in their own round robins. Since a Channel may constantly be utilised, failure to service all Channels in a statistically equivalent manner could lead to the disruption of the devices the invention supports. Specifically, in the optimised configuration of FIG. 1 this could be avoided through the following rotation sequence: 2890a - 2890b - 2890c - 289Od - 289Oe - 289Of - 2890a. However, any statistically equivalent distribution is acceptable.
- the Implementation-Logic translates methods directly into implementation specific low-level memory requests by using Implementation-Level-Access (2680 of FIG. 14).
- the Implementation-Logic therefore has direct access to arrays to build the set structures, which are efficient and readily available on the von Neumann architecture.
- the Arrays and Counters are beyond the scope of the patent because the behavioural specification of the Manabars-Set (3000 of FIG. 2) is already defined and the implementation may vary.
- FIG. 14 shows the invention (2600 of FIG. 14) acting as a centralised memory model.
- Emulator-Components do not have direct access to the Kl-Memory (2610 of FIG. 14), but manipulate data with handles and methods via the Kl-lnterface (2685 of FIG. 14 and 2810 of FIG. 1).
- the Kl-lnterface seamlessly passes method calls to the Implementation-Logic (2880a - 288Of & 2885a - 2885f of FlG. 1).
- the Implementation-Logic is likely to be a series of methods calls within a single Kl-lnterface object.
- there is little need to repeat the Implementation-Logic as memory is shared between processes and repeating code does not speed up execution because more threads have to compete for a fixed computational resource in a conventional von Neumann hardware deployment.
- the Implementation-Logic is required to check for any attached to Manabars-Sets (3000 of FIG. 2) that are affected directly and indirectly by any Kl-lnterface (2620 of FIG. 14) method calls.
- a compulsory parameter for each method call identifies the stack that will contain the UPT- Monitor-Generator (5400 of FIG. 12). This stack is to contain instructions that provide a computationally complete platform and is provided by devices that utilise this invention. If this parameter is set to the value No-Stack then all Monitors attached to the Manabars-Set are ignored. See the Monitors section for a complete explanation of how Monitors are triggered. Also refer to Appendix A for a full list of Kl-lnterface methods and the Monitors that may be triggered through each Kl-lnterface method call.
- the Defragmenter (2640 of FIG. 14) is an implementation specific component and so is beyond the scope of this patent.
- the implementers may choose to maintain a list of every available Cursor-Identification (3030 of FlG. 2), Child-Identification (3020 of FIG. 2) and Parent- Identification (3040 of FIG. 2) so that the entire defragmentation process is irrelevant.
- the implementers may choose to confine all the utilised memory structures within tracked zones of indexes. Defragmentation would then be used to shrink these zones when elements inside them were deleted.
- the Defragmenter may receive events from the Kl-Memory (2610 of FIG. 14) that may assist in the defragmentation process. ..
- the Defragmenter has Implementation-Level-Access (2680 of FIG. 14), so it modifies the Kl- Memory structures directly.
- the Asynchronous-Garbage-Collector (2630 of FIG. 14) is an implementation specific component. It is responsible for freeing up unused memory that occurs during a Delete-Child Kl-lnterface method call or Insert-Child Kl-lnterface method call with an Action-Polarity set to Type-Neutral. These Kl-lnterface calls are guaranteed to free up memory associated with Child-Identifications, however, the memory associated with the Cursor-Identification and its shared Parent-Identification can only be deleted if there are exactly zero references utilising it.
- This Emulator-Component is tightly related to the Defragmenter and it is expected that they may work together to manage the Kl-Memory (2610 of FIG. 13).
- Monitors provide a mechanism whereby software executing in the Kernel-Image (2800 of FIG. 1) can be made aware of changes to other Children.
- Kernel-Image (2800 of FIG. 1)
- CUI-Monitors These Monitors are concerned with any changes to the Cursor-Identification (3030 of FIG. 2 and 3800 of FIG. 6) such as the Cursor shifting to a different Child. These Monitors are stored in the CUI-Monitor-Event (4010 of FIG. 7 and 5035 of FIG. 11) of the Cursor-Identification-Content (3890 of FIG. 6 and 4000 of FIG. 7).
- Pi-Monitors These Monitors are concerned with any changes to the Parent-Identification (3040 of FIG. 2 and 3600 of FIG. 5) such as a Child being inserted or deleted, or the Whole (4440 of FIG. 9) or Float (4450 of FIG. 9) being altered. These Monitors are stored in the Pl-Monitor- Event (4490 of FIG. 9 and 5015 of FIG. 11) of the Parent-Identification-Content (3225 of FIG. 3 and 4400 of FIG. 9).
- CHI-Monitors These Monitors are concerned with any changes to the Child-Identification (3020 of FIG. 2 and 3400 of FlG. 4) such as a Child being inserted to the Left or Right of the Child being monitored. These Monitors are stored in the CHI-Monitor-Event (4210 of FIG. 8 and 5025 of FIG. 11) of the-Child-ldentification-Content (3445 of FIG. 4 and 4200 of FIG. 8).
- Monitors (5110a - 511On of FIG. 11 and FIG. 15) are added to a Monitor-Event (5100 of FIG. 11) through the Kl- Add-Monitor method (refer Appendix A).
- the parameters for this method call are the Monitor that is to be added and the Cursor-Identification (3030 of FIG. 2 and 3800 of FIG. 6) used to locate the Monitor-Event,
- Each Monitor has a unique Type (4480 of FIG. 9) that is used to identify whether the Monitor belongs in a Pi-Monitor-Event (4490 of FIG. 9 and 5015 of FIG. 11), CUI-Monitor-Event (4010 of FIG.
- a Monitor-Event (5100 of FIG. 11) is a Child with no specific Type, which is essentially a list of Monitors (5110a - 511On of FIG. 11 and FIG. 15) that identify specific events that require triggering. Events are triggered from within the Implementation-Logic (2880a - 288Of and 2885a - 2885f of FIG. 1) that processes instructions for the Kl-lnterface (2810 of FIG. 1). A single instruction processed by the Implementation-Logic may trigger a number of Monitors. See appendix A for all Monitors triggered through each Kl-lnterface method call.
- the CUI-Monitor-Event (4010 of FIG. 7 and 5035 of FIG. 1 1), Pi-Monitor-Event (4490 of FIG. 9 and 5015 of FIG. 11) and CHI-Monitor-Event (4210 of FIG. 8 and 5025 of FIG. 11) must be searched to locate the Monitors (5110a - 5110n of FIG. 11 and FIG. 15) that are to be triggered. This may take an unknown amount of time and therefore cannot be processed through the Implementation-Logic. Therefore during the processing of each instruction, the Implementation-Logic creates (see below for further explanation) an UPT-Monitor-Generator (5400 of FIG. 12), which holds all the relevant parameters for each event that has occurred that may trigger a Monitor.
- Monitor-Events that may hold Monitors that require triggering are also included in the UPT-Monitor-Generator. These Monitor-Events are:
- This Monitor-Event is inserted into the Cursor-Monitor-Field (5500 of FIG. 12).
- This Monitor-Event is inserted into the Parent-Monitor-Field (5450 of FIG. 12).
- This Monitor-Event is inserted into the Current-Child-Monitor-Field (5460 of FIG. 12).
- the CHI-Monitor-Event (4210 of FIG.
- a computationally complete environment is required to process instructions from a stack, all comprised of Manabars-Sets.
- the UPT-Monitor-Generator (5400 of FIG. 12) is then inserted into the Leftmost position of the Stack provided as a compulsory call parameter for every Kl-lnterface method - providing that the Stack itself is non-null. Monitor behaviour should be ignored for the Kl-lnterface call, if the Stack is null.
- the UPT-Monitor- Generator is subsequently executed repeatedly inside the appropriate Stack until all the relevant Monitors have been processed. However the full details of how the UPT-Monitor-Generator is executed and how the Monitor is subsequently processed is beyond the scope of this document.
- the Kl-Add-Monitor method call returns a key that is used to locate the specific Monitor (5110a -511On of FIG. 11) within the Monitor-Event (5100 of FIG. 11). This key is subsequently used to remove the Monitor from the Monitor-Event through the Kl-Remove-Monitor method call. All Monitors are transient and therefore all Monitor-Events are removed from the Manabars-Set on Shutdown of the invention.
- Deviated Behaviour Create new Monitor-Event and update the CHI-Monitor-Event, Pi-Monitor-Event or CUI-Monitor-Event (depending on the Type of the Monitor) to reference the newly created Monitor-Event.
- Next-Proxy (Able to be No-Proxy) The main Proxy-Identification (3010 of FIG. 2 and 3870 of FIG. 6) found through the Child-Proxy-Handle (3430 of FIG. 4) of the Next-Child.
- Left-Child (Able to be No-Child) The Child to the Left of the Child to be deleted (Current-Child) found through the Left-Child-Handle (3410 of FIG. 4) of the Current-Child.
- Right-Child (Able to be No-Child) The Child to the Right of the Child to be deleted (Current-Child) found through the Right-Child-Handle (3420 of FIG. 4) of the Current-Child.
- Parent-Identification Found through the Parent-Handle-Port (3820 of FIG. 6) of the Cursor-Identification (input 1).
- Step 1 The Left-Child-Handle (3410 of FIG. 4) of the Right-Child and the Right-Child-Handle (3420 of FIG. 4) of Left-Child are updated to reference each other. Check for the following monitors: CHI-Monitor-Child-Deletes-Left for the Right-Child, CHI-Monitor-Child-DeletesrRight forthe Left-Child.
- Step 2 Update the Proxy-Handle (3620 of FIG. 5) of the Next-Proxy to reference the Current-Proxy.
- the Action-Polarity (input (2)) update the Proxy-Leftmost-Cursor-Handle (3630 of FIG. 5) or the Proxy- Rightmost-Cursor-Handle (3640 of FIG. 5) of the Current Proxy to equal the Proxy-Leftmost-Cursor-Handle or the Proxy-Rightmost-Cursor-Handle of the Next-Proxy.
- Add the Proxy-Size 4030 of FIG. 7) found in the Proxy- Identification-Content (3615 of FIG. 5 and 4020 of FIG. 7) of the Next-Proxy to the Proxy-Size of the Current-Proxy.
- Step 3 Update the Proxy-Child-Handle (3610 of FIG. 5) of the Current-Proxy to reference the Next-Child. Update the Child-Proxy-Handle (3430 of FIG. 4) of the Next-Child to reference the Current-Proxy. Update the Child-Proxy- Handle of the Current-Child to reference No-Proxy.
- Step 4 If the Index-Integrity (4430 of FIG. 9) found in the Parent-Identification-Content (3225 of FIG. 3 and 4400 of FIG. 9) of the Parent-Identification is currently set to True then set it to False, and check for the Pl-Monitor-Bad- Index for the Parent-Identification. Calculate and update the new values for the Whole-Hashkey (4520 of FIG. 9), Float-Hashkey (4530 of FIG. 9), Fast-ABS-Hashkey (4540 of FIG. 9) and Slow-ABS-Hashkey (4550 of FIG. 9) of the Parent-identification-Content.
- Step 5 The Asynchron ⁇ us-Garbage-Collector (2630 of FIG. 13) is informed of the released Child-Identification (3020 of FIG. 2 and 3400 of FIG. 4) and the Number-Of-Children (4410 of FIG. 9) found in the Parent-ldentification-
- Deviated Behaviour Step 1 - Child on Left Boundary The Left-Child-Handle (3410 of FIG. 4) of the Right-Child is updated to reference No-Child.
- the Leftmost-Child-Handle (3460 of FIG. 4 and 3230 of FIG. 3) of the Parent-Identification is updated to reference the Right-Child.
- Step 1 - Child on Right Boundary: The Right-Child-Handle (3420 of FIG. 4) of the Left-Child is updated to reference No-Child. The Rightmost-Child-Handle (3470 of FIG. 4 and 3240 of FIG. 3) of the Parent-Identification is
- Deviated Behaviour Step 1 The method returns the Cursor-Identification (3030 of FIG. 2 and 3800 of FIG. 6) equal to input (1) because there are no more Cursor-Identifications in the direction specified. Check for the CUI-Monitor-Cursor- Retrieved.
- Deviated Behaviour Step 1 Locate the Leftmost-Child-Handle (3230 of FIG. 3) of the Parent-Identification and set its Left-Index (4220 of FIG. 8) found in the Child-Identification-Content (3445 of FIG. 4 and 4200 of FIG. 8) of the Child-Identification to 1.
- Step 2 Find the next Child through the Right-Child-Handle (3420 of FIG. 4) of the last Child; increase the number of the Left-Index (4220 of FIG. 8) and set the next Child's Left-Index. Repeat Step 2 until all Children have been updated.
- Inputs (1) A Cursor-Identification (3030 of FIG. 2 and 3800 of FIG. 6) that locates the shared Parent-Identification (3040 of FIG. 2 and 3200 of FIG. 3) for which the number of Children is requested
- Step 1 Check for and trigger the Pi-Monitor-Number-Children-Queried. Return the Number-Of-Children (4410 of S FIG. 9) found within the Parent-Identification-Content (3225 of FIG. 3 and 4400 of FIG. 9) of the Parent- Identification.
- Inputs (1) A Cursor-Identification (3030 of FIG. 2 and 3800 of FIG. 6) that locates the shared Parent-Identification (3040 of FIG. 2 and 3200 of FIG. 3) for which the number of Cursor-Identifications is requested.
- Step i Locate and return the Parent-Handle-Port (3270 of FIG. 3 and 3820 of FIG. 6) of input (1).
- Action-Trilarity is Neutral or Left then the Left-Child is found through the Left-Child-Handle (3410 of FIG. 4) of the Current-Child. Otherwise if the Action-Trilarity is Right then the Left-Child is the same as the Child identified by the Cursor.
- Right-Child (Able to be No-Child) The Child that will be to the right of the Child to be inserted (New-Child) if the Action-Trilarity is neutral or right then the Right-Child is found through the Right-Child-Handle (3420 of FIG. 4) of the Current-Child. Otherwise if the Action-Trilarity is Left then the Right-Child is the same as the Child identified by the Cursor.
- Parent-Identification Found through the Parent-Handle-Port (3820 of FIG. 6) of the Cursor-Identification (input 1).
- Old-Left-Cursor (Able to be Cursor-Terminator) Found through the Left-Cursor-Handle (3830 of FIG. 6) of the Cursor-Identification (input (1)).
- Old-Right-Cursor (Able to be Cursor-Terminator) Found through the Right-Cursor-Handle (3840 of FIG. 6) of the Cursor-Identification (input (1)).
- Step 1 Create a new Child-Identification (3020 of FIG. 2 and 3400 of FIG. 4) and set the Parent-Handle-Starboard (3440 of FIG. 4) to reference the Cursor-Identification (3030 of FIG. 2 and 3800 of FlG. 6) of input (2).
- the CHI- Monitor-Event (4210 of FIG. 8), found in the Child-Identification-Content (3445 of FIG. 4 and 4200 of FIG. 8) of the New-Child, will be set to No-Monitor-Event.
- Step 2 The Left-Index (4220 of FlG. 8) found in the Child-ldentification-Content (3445 of FIG. 4 and 4200 of FIG. 8) of the New-Child will be set to 0. If the Index-Integrity (4430 of FIG. 9) found in the Parent-Identification-Content (3225 of FIG. 3 and 4400 of FIG. 9) of the Parent-Identification is true then set it to false and check for the Pl- Monitor-Bad-Index for the Parent-Identification.
- Step 3 Update the Right-Child-Handle (3420 of FIG. 4) of the New-Child to reference the Right-Child, and the Left- Child-Handle (3410 of FIG. 4) of the New-Child to reference the Left-Child. Update the Left-Child-Handle of the Right-Child and the Right-Child-Handle of the Left-Child to reference the New-Child. Increase the Number-Of- Children (4410 of FIG. 9) found in the Parent-Identification-Content (3225 of FIG. 3 and 4400 of FIG. 9) of the Parent-Identification.
- Step 4 Update the Left-Cursor-Handle (3830 of FIG. 6) of the Old-Right-Cursor and the Right-Cursor-Handle (3840 of FIG. 6) of the Old-Left-Cursor to reference each other.
- Step 5a If the Action-Trilarity (input (3)) is Left: Locate the New-Right-Cursor found through the Proxy-Leftmost- Cursor-Handle (3630 of FIG. 5) of the Current-Proxy. Locate the New-Left-Cursor through the Left-Cursor-Handle (3830 of FIG. 6) of the New-Right-Cursor.
- Step 5b If the Action-Trilarity (input (3)) is Right: Locate the New-Left-Cursor found through the Proxy-Rightmost- Cursor-Handle (3640 of FIG. 5) of the Current-Proxy. Locate the New-Right-Cursor through the Right-Cursor- Handle (3840 of FIG. 6) of the New-Left-Cursor.
- Step 5 Update the Right-Cursor-Handle and the Left-Cursor-Handle of the Cursor-Identification (input (1)) to reference the New-Left-Cursor and the New-Right-Cursor. Update the Right-Cursor-Handle (3840 of FIG. 6) of the New-Left-Cursor and the Left-Cursor-Handle (3830 of FIG. 6) of the New-Right-Cursor to reference the Cursor- Identification (input (1)).
- Step 6 Create a new Proxy-Identification (3010 of FIG. 2 and 3600 of FIG. 5) and update the Cursor-Proxy-Handle 4- -4 (3810 of FIG. 6) of the Cursor-Identification (input (1)) and the Child-Proxy-Handle (3430 of FIG. 4) of the New- Child to reference the new Proxy-Identification.
- Step 7 Calculate and update the new values for the Whole-Hashkey (4520 of FIG. 9), Float-Hashkey (4530 of FIG. 9), Fast-ABS-Hashkey (4540 of FIG. 9) and Slow-ABS-Hashkey (4550 of FIG. 9) of the Parent-Identification- Content.
- Proxy-Handle (of the New-Child), Proxy-Child-Handle (of the new Proxy-Identification), Proxy-Handle (of the new Proxy-Identification), Proxy-Leftrnost-Cursor-Handle and the Proxy-Rightmost-Cursor-Handle (of the new Proxy- Identification), Proxy-Size (of the new Proxy-Identification).
- Monitors PI-Monitor-Bad-lndex for the Parent-Identification
- CHI-Monitor-Child-lnserts-Left for the Right-Child
- CHI- Monitor-Child-lnserts-Right for the Left-Child
- Pi-Monitor-Inserts-Child for the Parent-Identification
- CHI-Monitor- Cursor-ldentification-Shifted-Qff-Child for the Current-Child
- Deviated Behaviour Steps 1 - 3 Are the same as in the Generic Behaviour. Step 4: If the Cursor is moving from the boundary:
- Step 4a If the Action-Trilarity (input (3)) is Left: Update the Left-Cursor-Handle (3830 of FIG. 6) of the Old-Right- Cursor to reference No-Child. Update the Leftmost-Cursor-Handle (3210 of FIG. 3) to reference the Old-Right- Cursor and check for Pi-Monitor-Cursor-Leftmost for the Parent-Identification.
- Step 4b If the Action-Trilarity (input (3)) is Right: Update the Right-Cursor-Handle (3840 of FIG. 6) of the Old-Left- O Cursor to reference Cursor-Terminator. Update the Rightmost-Cursor-Handle (3220 of FIG. 3) to reference the Old-Left-Cursor and check for Pi-Monitor-Cursor-Rightmost for the Parent-Identification.
- Step 5 If the Cursor is moving to the boundary:
- Step 5a If the Action-Trilarity (input (3)) is Left: Locate the New-Right-Cursor found through the Proxy-Leftmost- Cursor-Handle (3630 of FIG. 5) of the Current-Proxy. Update the Left-Cursor-Handle (3830 of FIG. 6) of the New- Right-Cursor and the Right-Cursor-Handle (3840 of FIG. 6) of the Cursor-Identification (input (1)) to reference each other. Update the Left-Cursor-Handle of the Cursor-Identification (input (1)) to reference Cursor-Terminator. Update the Leftmost-Cursor-Handle (3220 of FIG. 3) of the Parent-Identification to reference the Cursor- Identification (input (1)) and check for Pi-Monitor-Cursor-Leftmost for the Parent-Identification.
- Step 5b If the Action-Trilarity (input (3)) is Right: Locate the New-Left-Cursor found through the Proxy-Rightmost- Cursor-Handle (3640 of FIG. 5) of the Current-Proxy. Update the Right-Cursor-Handle (3840 of FIG. 6) of the New-Left-Cursor and the Left-Cursor-Handle (3830 of FIG. 6) of the Cursor-Identification (input (1)) to reference each other. Update the Right-Cursor-Handle of the Cursor-Identification (input (1)) to reference Cursor-Terminator. Update the Rightmost-Cursor-Handle (3220 of FIG. 3) of the Parent-Identification to reference the Cursor- ldentification (input (1)) and check for Pi-Monitor-Cursor-Rightmost for the Parent-Identification.
- Deviated Behaviour Step 1 Is the same as in the Generic Behaviour.
- Step 2 Copy the Left-Index (4220 of FIG. 8) found in the Child-ldentification-Content (3445 of FIG. 4 and 4200 of FIG. 8) of the Child identified by the Cursor to the Left-Index of the New-Child.
- Step 3 Is the same as in the Generic Behaviour. Steps 4 + 5: Do not happen.
- Step 6 Update the Child-Proxy-Handle (3430 of FIG. 4) of the New-Child to reference the Current-Proxy and the Child-Proxy-Handle of the Current-Child to reference No-Child. Update the Proxy-Child-Handle (3610 of FIG. 5) of the Current-Proxy to reference the New-Child. Check for the CHI-Monitor-Cursor-ldentification-Shifted-Off-Child and CHI-Monitor-No-Cursor-Identification for the Current-Child. Check for the Pl-Monitor-Deletes-Child for the Parent-Identification.
- Step 7 Is the same as in the Generic Behaviour.
- CHI-Monitor-Child-Inserts-Left for the Right-Child
- CHI-Monitor-Child-lnserts-Right for the Left-Child
- Pl-Monitor- Inserts-Child and Pl-Monitor-Deletes-Child for the Parent-Identification
- CHI-Monitor-Cursor-ldentification-Shifted- Off-Child for the Current-Child
- CHI-Monitor-No-Cursor-Identification for the Current-Child.
- Step 4 Update the following fields for the new Proxy-Identification (3600 of FIG. 5): Proxy-Child-Handle (3610 of FIG. 5) to reference No-Child, Proxy-Handle (3620 of FIG. 5) to reference No-Proxy, Proxy-Leftmost-Cursor-Handle (3630 of FIG. 5) and Proxy-Rightmost-Cursor-Handle (3640 of FIG. 5) to reference new Cursor-Identification (3800 of FIG. 6), Proxy-Size (4030 of FIG. 7) found in the Proxy-Identification-Content (3615 of FIG. 5 and 4020 of FIG. 7) to equal 1.
- Step 5 Do everything exactly the same as insert (including allowing for all cases) using the newly created Cursor- Identification (3800 of FIG. 6) as the Source-Child to be inserted into input (1).
- Action-Trilarity (input (2)) is Neutral, then the newly created Manabars-Set (3000 of FIG. 2) replaces the Manabars-Set pointed to by the Cursor of the destination location from parameter (1).
- New Number-Of-Children, Number-Of-Cursors, Index-Integrity, Pi-Monitor-Event, Leftmost- Cursor-Handle, Rightmost-Cursor-Handle, Leftmost-Child-Handle, Rightmost-Child-Handle, Whole, Float, Fast-ABS- Handle, Slow-ABS-Handle, and Type.
- Cursor-Identification (New): Cursor-Proxy-Handle, Parent-Handle-Port, Left-Cursor-Handle, Right-Cursor-Handle, CUI- Monitor-Event, and Child-Handle.
- Proxy-Identification (New): Proxy-Child-Handle, Proxy-Handle, Proxy-Leftmost-Cursor-Handle, Proxy-Rig htmost- Cursor-Handle, and Proxy-Size.
- Cursor-Identification (3030 of FIG. 2 and 3800 of FIG. 6) that identifies the Parent-Identification (3040 of FIG. 2 and 3200 of FIG. 3) to undergo the Float (4450 of FIG. 9) replacement.
- Cursor-Identification (3030 of FIG. 2 and 3800 of FIG. 6) that identifies the Parent-Identification (3040 of FIG. 2 and 3200 of FIG. 3) to undergo the Slow-ABS-Handle (4470 of FIG. 9) replacement.
- Slow-ABS-Handle •
- Step 1 Locate and set the Slow-ABS-Handle (4470 of FIG. 9), found within the Parent-Identification-Content (3040 of FIG. 2 and 3200 of FIG. 3) of the Parent-Identification, to equal input (2). Check for the PI-Monitor-Slow-ABS-Changed
- Cursor-Identification (3030 of FIG. 2 and 3800 of FIG. 6) that identifies the Parent-Identification (3040 of FIG. 2 and 3200 of FIG. 3) to undergo the Whole (4440 of FIG. 9) replacement.
- Step 1 Locate and set the Whole (4440 of FIG. 9), found within the Parent-Identification-Content (3040 of FIG. 2 and 3200 of FIG. 3) of the Parent-Identification, to equal input (2). Check for the Pl-Monitor-Whole-Changed for the Parent- Identification.
- Cursor-Handle (3630 of FIG. 5) of the Current-Proxy. Locate the New-Left-Cursor through the Left-Cursor-Handle (3830 of FIG. 6) of the New-Right-Cursor.
- Step 2b If the Action-Trilarity (input (3)) is Right: Locate the New-Left-Cursor found through the Proxy-Rightmost- Cursor-Handle (3640 of FIG. 5) of the Current-Proxy. Locate the New-Right-Cursor through the Right-Cursor- Handle (3840 of FIG. 6) of the New-Left-Cursor.
- Step 2 Update the Right-Cursor-Handle (3840 of FIG. 6) and the Left-Cursor-Handle (3830 of FIG. 6) of the Cursor-Identification (input (1)) to reference the New-Left-Cursor and the New-Right-Cursor. Update the Right- Cursor-Handle (3840 of FIG. 6) of the New-Left-Cursor and the Left-Cursor-Handle (3830 of FIG. 6) of the New- Right-Cursor to reference the Cursor-Identification (input (1)).
- Step 3a If there is no Next-Proxy create a new Proxy-Identification (3010 of FIG. 2 and 3600 of FIG. 5) as the Next-Proxy. Update the Proxy-Child-Handle (3610 of FIG. 5) of the Next-Proxy to reference the Next-Child. Update the Proxy-Handle (3620 of FIG. 5) to point to No-Proxy and the Proxy-Size (4030 of FIG. 7), found in the Proxy-Identification-Content (3615 of FIG. 5 and 4020 of FIG. 7) of the Next-Proxy, to equal 0. If the Action- Polarity (input (2)) is Left then update the Proxy-Leftmost-Cursor-Handle (3630 of FIG.
- Step 3 Update the Cursor-Proxy-Handle (3810 of FIG. 6) of the Cursor-Identification (input (1)) to reference the Next-Proxy. Update the Proxy-Leftmost-Cursor-Handle (3630 of FIG. 5) (if the Action-Polarity (input (2)) is Right) or the Proxy-Rightmost-Cursor-Handle (3640 of FIG. 5) (if the Action-Polarity (input (2)) is Left) of the Next-Proxy to reference the Cursor-Identification (input (1)).
- Step 3b If the Proxy-Leftmost-Cursor-Handle (3630 of FIG. 5) of the Current-Proxy references the Cursor- Identification (input (1)) and the Action-Polarity is Right then update the Proxy-Leftmost-Cursor-Handle of the Current-Proxy to reference the Old-Right-Cursor.
- Step 3c If the Proxy-Rightmost-Cursor-Handle (3640 of FIG. 5) of the Current-Proxy references the Cursor- Identification (input (1)) and the Action-Polarity is Left then update the Proxy-Rightmost-Cursor-Handle of the Current-Proxy to reference the Old-Left-Cursor.
- APPENDIX A the Cursor-Identification (input (1))), Proxy-Leftmost-Cursor-Handle (if the Action-Polarity (input (2)) is Right) or the Proxy-Rightmost-Cursor-Handle (if the Action-Polarity (input (2)) is Left) (of the Next-Proxy), Proxy-Size (of the Next-Proxy), Proxy-Size (of the Current-Proxy), Proxy-Leftmost-Cursor-Handle or Proxy-Rightmost-Cursor-Handle (of the Current-Proxy).
- CHI-Monitor-Cursor-ldentification-Shifted-Off-Child for the Current-Child
- CHI-Monitor-Cursor-ldentification- Shifted-Onto-Child for the Next-Child
- CUI-Monitor-Cursor-At-Boundary for input (1)
- CUl-Monitor-Cursor-At- Leftmost or CUl-Monitor-Cursor-At-Rightmost for input (1)
- Pl-Monitor-Cursor-Leftmost or Pl-Monitor-Cursor- Rightmost for the Parent-Identification.
- New-Child The Child-Identification (3020 of FIG. 2 and 3400 of FIG. 4) that the Cursor-Identification will be shifted to. Found through the Leftmost-Child-Handle (3230 of FlG. 3) or the Rightmost-Child-Handle (3240 of FlG. 3) of the Parent-Identification depending on the Action-Polarity (input (2)).
- New-Proxy (Able to be No-Proxy) The Proxy-Identification that the New-Child references. Found through the Child-Proxy-Handle (3430 of FIG. 4) of the New-Child.
- Old-Left-Cursor (Able to be Cursor-Terminator) Found through the Left-Cursor-Handle (3830 of FlG. 6) of the Cursor-Identification (input (1)).
- Old-Right-Cursor (Able to be Cursor-Terminator) Found through the Right-Cursor-Handle (3840 of FlG. 6) of the Cursor-Identification (input (1)).
- Leftmost-Child Found through the Leftmost-Child-Handle (3230 of FlG. 3) of the Parent-Identification. ;
- Step 1 Locate the Left-Cursor-Handle (3830 of FIG. 6) of the Old-Right-Cursor and the Right-Cursor-Handle (3840 of FIG. 6) of the Old-Left-Cursor and update them to reference each other.
- Step 2a Update the Left-Cursor-Handle (3830 of FiG. 6) of the Leftmost-Cursor-Handle (3210 of FIG. 3) of the Parent-Identification and the Right-Cursor-Handle (3840 of FIG. 6) of the Cursor-Identification (input (1)) to reference each other. Update the Left-Cursor-Handle of the Cursor-Identification (input (1)) to reference Cursor- Terminator. Update Leftmost-Cursor-Handle of the Parent-Identification to reference Cursor-Identification (input (1)). Check for the Pi-Monitor-Cursor-Leftmost for the Parent-Identification.
- Step 2b Update the Right-Cursor-Handie (3840 of FIG. 6) of the Rightmost-Cursor-Handle (3220 of FIG. 3) of the Parent-Identification and the Left-Cursor-Handle (3830 of FIG. 6) of the Cursor-Identification (input (1)) to reference each other. Update the Right-Cursor-Handle of the Cursor-Identification (input (1)) to reference Cursor-Terminator. Update Rightmost-Cursor-Handle of the Parent-Identification to reference Cursor-Identification (input (1)). Check for the Pl-Monitor-Cursor-Rightmost for the Parent-Identification.
- Step 3a If there is no New-Proxy create a new Proxy-Identification (3010 of FIG. 2 and 3600 of FIG. 5) as the New-Proxy. Update the Proxy-Child-Handle (3610 of FIG. 5) of the New-Proxy to reference the New-Child. Update the Proxy-Handle (3620 of FIG. 5) to point to No-Proxy and the Proxy-Size (4030 of FIG. 7), found in the Proxy-Identification-Content (3615 of FIG. 5 and 4020 of FIG. T) of the New-Proxy, to equal 0. If the Action-Polarity (input (2)) is Left then update the Proxy-Rightmost-Cursor-Handle (3640 of FIG.
- Step 3 Increase the Proxy-Size (4030 of FIG. 7), found within the Proxy-Identification-Content (3615 of FIG. 5 and 4020 of FIG. 7) of the New-Proxy, by 1 and decrease the Proxy-Size, found within the Proxy-Identification-Content of the Current-Proxy, by 1.
- the Cursor is the boundary Cursor in the direction of the Action-Polarity (input (1)
- Steps 3 + 4 Are the same as in Generic Behaviour.
- the parameters of the Monitor reflect the changes made to the Manabars-Set involved.
- the parameters include such things as:
- a Parent which is a spawned Cursor of the original Cursor-Identification. Some parameters include a Parent before and a Parent after. Both of these Parents are spawned Cursor- Identifications which reflect the state of the original Cursor-Identification before and after the event occurred.
- a Child which is the Cursor-Identification of the Child involved in the Kl-lnterface call.
- This Child may be the Child that the original Cursor-Identification is pointing to or the Child to the Right or the Left of the Child that the original Cursor-Identification is pointing to.
- the Child may also be the Child that was inserted or deleted from the Parent.
- a Cursor-Identification which is the original Cursor-Identification.
- the original Cursor-Identification is the Cursor-Identification that was involved in the Kl-lnterface method call that triggered the Monitor.
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Mathematical Physics (AREA)
- Multi Processors (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
- Storage Device Security (AREA)
Abstract
La présente invention concerne un système ou une structure de stockage de données représentant un certain nombre d'ensembles de localisations de stockage de données. Chaque ensemble possède un identificateur d'ensemble parent et contient une liste associée de localisations de stockage enfant. Lorsqu'elle est utilisée comme stockage en mémoire avec un environnement complet de calcul informatique cette invention fournit une protection contre des attaques d'utilisateurs non autorisés.
Applications Claiming Priority (4)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US72289605P | 2005-09-30 | 2005-09-30 | |
| NZ54276105 | 2005-09-30 | ||
| US60/722,896 | 2005-09-30 | ||
| NZ542761 | 2005-09-30 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| WO2007037710A2 true WO2007037710A2 (fr) | 2007-04-05 |
| WO2007037710A3 WO2007037710A3 (fr) | 2007-05-31 |
Family
ID=37900034
Family Applications (2)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| PCT/NZ2006/000255 Ceased WO2007037710A2 (fr) | 2005-09-30 | 2006-10-02 | Dispositif de calcul informatique pour gestion d'ensembles |
| PCT/NZ2006/000254 Ceased WO2007037709A1 (fr) | 2005-09-30 | 2006-10-02 | Plate-forme d'abreges permettant de faciliter l'interoperabilite d'informations |
Family Applications After (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| PCT/NZ2006/000254 Ceased WO2007037709A1 (fr) | 2005-09-30 | 2006-10-02 | Plate-forme d'abreges permettant de faciliter l'interoperabilite d'informations |
Country Status (1)
| Country | Link |
|---|---|
| WO (2) | WO2007037710A2 (fr) |
Family Cites Families (11)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5592667A (en) * | 1991-05-29 | 1997-01-07 | Triada, Ltd. | Method of storing compressed data for accelerated interrogation |
| US5479656A (en) * | 1992-05-13 | 1995-12-26 | Rawlings, Iii; Joseph H. | Method and system for maximizing data files stored in a random access memory of a computer file system and optimization therefor |
| CA2225932A1 (fr) * | 1997-05-09 | 1998-11-09 | Kim Lawson Rochat | Gestion de la memoire dans un systeme de programmation a recuperation partielle des miettes |
| US5924098A (en) * | 1997-06-30 | 1999-07-13 | Sun Microsystems, Inc. | Method and apparatus for managing a linked-list data structure |
| WO2000057350A1 (fr) * | 1999-03-19 | 2000-09-28 | Raf Technology, Inc. | Fonctions de synthese destinees a un stockage, une presentation et une analyse efficaces de donnees |
| US7130891B2 (en) * | 2002-02-04 | 2006-10-31 | Datasynapse, Inc. | Score-based scheduling of service requests in a grid services computing platform |
| US7065549B2 (en) * | 2002-03-29 | 2006-06-20 | Illinois Institute Of Technology | Communication and process migration protocols for distributed heterogeneous computing |
| US7043522B2 (en) * | 2002-05-30 | 2006-05-09 | Microsoft Corporation | Unbounded computing space |
| US7774191B2 (en) * | 2003-04-09 | 2010-08-10 | Gary Charles Berkowitz | Virtual supercomputer |
| US20050125537A1 (en) * | 2003-11-26 | 2005-06-09 | Martins Fernando C.M. | Method, apparatus and system for resource sharing in grid computing networks |
| US7526515B2 (en) * | 2004-01-21 | 2009-04-28 | International Business Machines Corporation | Method and system for a grid-enabled virtual machine with movable objects |
-
2006
- 2006-10-02 WO PCT/NZ2006/000255 patent/WO2007037710A2/fr not_active Ceased
- 2006-10-02 WO PCT/NZ2006/000254 patent/WO2007037709A1/fr not_active Ceased
Also Published As
| Publication number | Publication date |
|---|---|
| WO2007037709A1 (fr) | 2007-04-05 |
| WO2007037710A3 (fr) | 2007-05-31 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US20230376332A1 (en) | Parallel Processing Of Data | |
| DeLoach | Analysis and Design using MaSE and agentTool | |
| US9395954B2 (en) | Project planning and debugging from functional decomposition | |
| KR20170037636A (ko) | 데이터 계통 요약 | |
| EP2191362A1 (fr) | Gestion de flux de données dans des calculs à base de graphes | |
| Lins | The Modula-2 Software Component Library: Volume 3 | |
| JP6500896B2 (ja) | 属性列挙システム、属性列挙方法および属性列挙プログラム | |
| Santiago-Duran et al. | A gearbox model for processing large volumes of data by using pipeline systems encapsulated into virtual containers | |
| Friedman et al. | Fisheye consistency: Keeping data in synch in a georeplicated world | |
| Bernardi et al. | Model design using hierarchical web-based libraries | |
| WO2007037710A2 (fr) | Dispositif de calcul informatique pour gestion d'ensembles | |
| Allmaier et al. | Parallel shared-memory state-space exploration in stochastic modeling | |
| US20070198547A1 (en) | Computational device for the management of sets | |
| Freire et al. | Preserving the mental map in interactive graph interfaces | |
| Wirtz | Modularization and process replication in a visual parallel programming language | |
| Kesaraju et al. | Integrated simulation combining process-driven and event-driven models | |
| Dorier et al. | Extending the Mochi Methodology to Enable Dynamic HPC Data Services | |
| Beckett et al. | A strict occam design tool | |
| Just et al. | VjControl: an advanced configuration management tool for VR Juggler applications | |
| Rodríguez et al. | Verification of the MQTT IoT protocol using property-specific CTL sweep-line algorithms | |
| Enokido et al. | The energy-efficient object replication scheme by omitting meaningless write methods in virtual machine environments | |
| Zhou et al. | Asynchronous and composable distributed co-simulation engine design for cloud-based industrial CAE software | |
| Andler et al. | DeeDS NG: Architecture, design, and sample application scenario | |
| Bailey et al. | SPEEDES: A brief overview | |
| Del Fabbro | Developing a distributed image processing and management framework |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| DPE1 | Request for preliminary examination filed after expiration of 19th month from priority date (pct application filed from 20040101) | ||
| NENP | Non-entry into the national phase |
Ref country code: DE |
|
| 121 | Ep: the epo has been informed by wipo that ep was designated in this application |
Ref document number: 06812830 Country of ref document: EP Kind code of ref document: A2 |
|
| 122 | Ep: pct application non-entry in european phase |
Ref document number: 06812830 Country of ref document: EP Kind code of ref document: A2 |