Back | Home | Next

Physiology

ANNA  K5

@

Home
Glossary
Objectives
Formalism
Morphology
Physiology
Connectors
Serialization
Traits
Methods
Claims
Relations
Dictionary
Core UML
Ring1 Apps
Tiger Server
Features
History
ToDo
Authors
API
Images
ToDo
DNA Declarations
Physiology RO
Real Time RO
ANNA as an Eco System RO
HMM Generator
ERP

 

Prototypes

1.                  Call frame is a typed object of the Morphic Model.

2.                  Type has public or implementation relations.

3.                  An outsider sees the public fields of a prototype and perceives a prototype’s implementation as amorphous data.

4.                  Object pointer falls at the level of the header.

Header

Public/Protected

7

ArgD

 

6

ArgC

 

5

ArgB

 

4

ArgA

 

3

ArgC

 

2

ArgB

 

1

ArgA

 

 

Implementation

-1

VarA

 

-2

VarB

 

-3

VarC

 

-4

VarD

 

-5

VarA

 

-6

VarB

 

-7

VarC

 

 

Prototype B

Header

Public/Protected

3

ArgC

 

2

ArgB

 

1

ArgA

 

 

Implementation

-1

VarA

 

-2

VarB

 

-3

VarC

 

-4

VarD

 

 

Prototype A


Access to an object’s implementation is acquired through negative offsets.

Call frames

6.                  Call frame is a typed object of the Morphic Model.

7.                  The type of a call frame is a Prototype.

8.                  Prototypes are Type Masters.

9.                  Prototypes inherit from other prototypes.

10.              Fork clones the current call frame as the first object of a new thread.

ScopeA

{

            ScopeB

            {

            }

            do something

            CALL ScopeB(args)

            do something

            FORK ScopeB(args), stack, size

            do something

}

 


 

Network

{

                int NetworkID;

                void NetworkSharedMemory[nw_size];

                Machine

                {

                                int MachineID;

                                void MachineSharedMemory[m_size];

                                Process

                                {

                                                int ProcessID;

                                                void ProcessMemory[p_size];

                                                Thread

                                                {

                                                                int ThreadID;

                                                                void Stack[stack_size];

                                                                FunctionA

                                                                {

                                                                                int Arg1;

                                                                                FunctionAA

                                                                                {

                                                                                                int Arg2;

                                                                                }

                                                                                FunctionAB

                                                                                {

                                                                                }

                                                                }

                                                                FunctionB

                                                                {

                                                                                int Arg1;

                                                                                FunctionBA

                                                                                {

                                                                                }

                                                                }

                                                                Start

                                                                {

                                                                                int Var1;

                                                                                CALL FunctionB

                                                                }

                                                                CALL Start()

                                                }

                                                ThreadB

                                                {

                                                }

                                }

                }

}


Instances of methods

An instance consists of public data, type info, private data.

A function call pushes parameters first. This is the init public data. The method completes the instance by calling a constructer finalizor. Generalizing, an object instance is constructed by finalizing a public initialization.

There would be changes to the TypeInfo layout.

Sacks, frames, morphism within a running system

 

 

 

 

 

 

Visible region

 

 

Ex

 

 

Local p-1

 

 

 

ESPn-1

 

Local p

 

 

 

 

PUSH

Arg n

Rel n

 

METHOD  Instance

 

 

 

 

 

 

UPtr

 

 

...

 

 

 

PUSH

Arg 2

Rel 2

 

 

PUSH

Arg 1

Rel 1

 

 

CALL

Return Addr

Children

AMORPHOUS  header

 

EBPn

ENTER lsz,nn

Next Frame=EBPn-1

Next

 

 

Parent EBP

Parent (thread)

Hidden region

 

 

 

 

 

 

 

Obj

 

 

Local Special

Prev=Parent->Children

 

 

 

Object=MethodType

 

 

 

Index=Parent.Count++

 

 

 

Count=0

 

 

 

Vector=0

 

 

 

VMT of method

 

 

 

Proxy STREE

 

 

 

 

 

 

 

 

MPtr

 

 

Local 1

Rel n+1

 

 

 

Local 2

Rel n+2

 

 

 

...

 

 

 

 

Local m

Rel n+m

 

ESPn

 

alloca space

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Interlocking threads, methods and arguments

Objects referenced by the current thread cannot be relocated without stack analysis.

1.      Object interlock should change to use the Suspend/Resume scheme. Need an int to count the overlocks. Might use InterlockData for this purpose. Must then rethink the interlocking scheme of NODE and LINE.

2.      Object Semaphore renamed to Handle. This frees the TypeInfo::Children field to be used in recursive memory management. Dictionary would then drop its MemoryBlock[0] field.

Th:       CALL S ();

S:         var Ta a1,a2;

            var Tb b1,b2;

            var Tc c1,c2;

CALL A (a1,b1); Ia1++; Ib1++;

A:        CALL B (b1,c1); Ib1++; Ic1++;

B:        CALL A (a2,b2); Ia2++; Ib2++;

CALL B (b2,c2); Ib2++; Ic2++;

 

a1

b1

A

B

Ta

Tb

Tc

c1

a2

b2

c2

S

Ara

Arb

Brb

Brc

2a

2b

2c

Th

CA1

CB1

CA2

CB2

CS

a1

a2

b1

b2

c1

c2

 

 

 

 

 

 

 

 

3.    Object Handle is free for assignment as a file handle, thread handle, or memory block. Object assumes that the handle is a memory block. An object flag says that the handle points to another object.

4.      Object has the basic stream capabilities of Access(direction, position, buffer, length). Position is bit-granular.

 

Thread::Start()

{

            char space[0x1000];

            Ta a1,a2;

            Tb b1,b2;

            Tc c1,c2;

            FunctionA(&a1,&b1);

}

FunctionA(Ta*a, Tb*b)

{

            NODE lock_a(EBP,a);

            NODE lock_b(EBP,b);

            printf("FunctionA(%x:%s,%x:%s)",a,lock_a->GetName(),b,lock_b->GetName());

            FunctionA(a,b);

}

 

 

 

 

 

 

 

Visible region

 

 

Ex

 

 

Local p-1

 

 

 

ESPn-1

 

Local p

 

 

 

 

PUSH

Arg n

Rel n

 

METHOD  Instance (CF)

 

 

 

 

 

 

 

UPtr

 

 

...

 

 

 

PUSH

Arg 2 *

Rel 2

 

 

PUSH

Arg 1 *

Rel 1

 

 

 

 

T.Next=0

Call Frame CF

 

 

 

T.Prev=0

 

 

 

T.Children=0

 

CALL

Return Addr

T.Parent= MethodType

EBPn

ENTER lsz,nn

Object 0

T.Object=CF

Hidden region

 

 

 

 

 

 

 

 

 

 

 

Obj

 

 

Object 1

#.Parent scope

 

 

Object N-3

#.Thread  TID

 

 

Object N-2

#.Process  PID

 

 

Object N-1

#.Machine IP

 

 

Object N

#.Network  Port

 

 

 

 

 

OBJECT.

Interlock

I.Children

 

 

I.Parent=PrevCF

 

 

I.Next

 

 

I.Prev

 

 

I.Object=CF

 

 

AMORPHOUS

VMT of method

 

 

Local 1

Rel n+1

 

 

 

 

 

MPtr

 

 

MPtr

 

 

Local 2 *

Rel n+2

 

 

 

...

 

 

 

 

Local m-1

Rel n+m-1

 

 

 

Local m

Rel n+m

 

ESPn

 

interlock1

Interlock CF→Arg1

 

 

 

 

 

interlock2

Interlock CF→Arg2

 

 

 

 

interlock3

Interlock CF→Local2

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

  1. Upon any function entry the thread exclusively locks the call frame object.
  2. lock_a and lock_b are implementation relations of TYPE_FunctionA.
  3. lock_a and lock_b are NODE sub-structures of the CALL Frame.

Problems

  1. Creating selectors is destructive unless we begin to say that selectors can be taken in the Interlock scope, or any other scope.
  2. Relations must create objects, because their result is design oriented.
  3. Interlock must have a flag to distinguish between lock and share.
  4. Auto-constructed selection paths must be OBJECTS and live on a heap. The heap must be at least as persistent as the targeted objects.
  5. Killing a thread corrupts the interlock chains. Corrupting the interlock for system objects outside the scope of the thread is a catastrophic event.
  6. An interlock tree structure should be tested for integrity before traversal.
  7. A corrupt interlock node affects the neighbours as well, so the parent interlock must be deemed corrupted. This problem affects any scope, not just the interlock.
  8. Deleting, moving, and relaying are disposition rights. The entire solid needs to be exclusively locked for such operations.
  9. A thread would have already locked its Call frames.
  10. Thread->CorrelatePointer(argument) would always match an existing call frame as pre-selector.
  11. A function argument lock is a selector owned by this scope, nesting into the call-frame that defined the argument, and instance of the corresponding function argument.

Solutions:

  1. A call frame wants to de-reference a pointer.
  2. The caller expects a selector, so it allocates local space for one.
  3. Caller can only commence locking once its call frame has been fully bound.
  4. Every call frame is also a relation endpoint for the thread to the called function.
  5. The call frame is also a selector of the thread to the endpoint function.
  6. Caller checks the pointer against the thread limits.
  7. Caller is the last connector of the multi-relation added.
  8. The pointer offset relative to the stack current position is ptr-this.
  9. Calls thread->FindRelationByOffset(offset) to match an earlier stack call frame that defined the object whose pointer is to be de-referenced.
  10. The above returns the endpoint of the thread multi-relation, and updates the offset to be relative to the endpoint type.
  11. Thread is a coherent system, and not a union. The solid path is therefore unique.
  12. If no selector can be found because the source pointer lies outside the STACK, then it must be PROCESS or SYSTEM memory.
  13. A similar search for a selector is done for the process that owns the thread, then for the system that owns the process, etc. If no selection chain can be established, then the pointer is outside the SCOPE of the system and into amorphic data SPACE.
  14. A container protects data accesses by restricting the creation of selectors.
  15. FindRelationByOffset may have better chances of reaching its goal by first recursing, if the parent scope is flatly narrower than the initial one.
  16. The operating system, however is not coherent everywhere. The OS may have tools that view and monitor processes, which are overlapping.
  17. A system's selection path to an external entity is only valid through designed references.
  18. Function=endpoint->GetTypeMaster().
  19. RELATION*argument=Function->FindRelationByOffset(offset);
  20. A future selector between Endpoint and Argument might conflict with other such selectors of the Argument.
  21. selector.INIT(owner=this, parent=endpoint,type=argument,handle=ptr,flShare)
  22. Construction may fail if another thread has an exclusive selection path to the same argument. The rejection must happen at the lowest level of SetTypeMaster.
  23. OBJECT::INIT sets the share flags before binding the instance to its TYPE.
  24. Selector is a local variable mapped by the function type master.
  25. To prevent expensive multiple searches for selectors, pointers to selectors can be passed as function arguments and must not themselves be locked.
  26. Objects of a level higher than this but in the same scope ancestry are always mapped and directly selectable available.
  27. Finding external collateral references is expedited by cabling.

Reversible code

The following is a function body enabled for backtracking.

void BacktrackingProcedure (arg1,arg2, arg3, arg4)

{

 

JBK

@@bk0

Pseudo instruction testing the direction

@@fd0

ENTER

 

Space allocation

@@bk4

DOUNDO

something1

 

 

JBK

@@exit

 

 

PUSH

arg1

 

 

PUSH

arg2

 

 

PUSH

@@fd1

 

@@bk3

JMP

Function1

 

@@fd1

JBK

@@bk4

 

@@bk2

DOUNDO

something2

 

 

JBK

@@bk3

 

 

PUSH

arg3

 

 

PUSH

arg4

 

 

PUSH

@@fd2

 

@@bk1

JMP

Function2

 

@@fd2

JBK

@@bk2

 

@@bk0

DOUNDO

something3

 

 

JBK

@@bk1

 

 

RET

 

Persistent return to caller

@@exit

LEAVE

 

Relinquishing space

 

RET

 

Return to caller

}

If backtracking code is handled with classes, one class per function, then no return types are going to be possible. The return of a constructor is the object.

STED and CLED set and clear the execution direction.


Old and questionable issues

1.  Code(C) and Data(D) is in some state(S) at a given time t.

2.  State C:D is everchanging as the system rus.

2.1. Code has either ran or will run.

2.2. Data has either been used or will be used.

3.  We are at point (C,D,t) in the system and want to do one of the following:

    3.1. Add a relation R to type T between T.r[i] and T.r[i+1]

    3.2. Remove a relation T.r[i] from the type

    3.3. Resize a replation T.r[i]

    3.4. Reorder a relation T.r[i] before T.r[j]

    3.5. Move a relation T.r[i] in starting offset

    3.6. Hide a visible relation T.r[i]

    3.7. Show a hidden relation T.r[i]

4.  Resizing a relation can only be done by

    4.1. Changing the Supplier of that relation

    4.2. Changing the containment rule of the relation between BY_VAL and BY_REF.

    4.3. Changing the cardinality of the relation.

5.  There can be more than one morphism pending on an instance of a type.

6.  Morphism can only be resolved one type instance at a time.

7.  An instance of a morphing type cannot be de-refferenced until the system has been re-pointed.

8.  New instances of a morphing type are created under the new type.

10. Morphism needs to be published through-out the system to everybody that refferences morphing data.

11. We need a way to garantee that the r[m+1] fields of morphing data are not used by the system. The Memory Manager needs to cooperate and protect data instances of morphing types against access. The Protection Fault would block all memory accesses until the data instance is released.

12. Data instances cannot hold any flag information about morphism.

13. A contains B an instance a of A has an embedded b of type B. a belongs to the instance chain of A. B has a list of client relations through which it finds b included in a.

14. When growth morphism occurs, memory is allocated with a 10% or so of internal fragmentation to support faster morphism. When the threshold is passed re-allocation takes place. If it underpassed de-fragmentation is invoked.

15. All types have a template.

16. A new has BY_VAL relation of a type copies the template by the cardinality count into the gap. A new has BY_REF relation of a type sets the pointer to the supplier's template. This way instance data is initialized after morphism occured.

17. The type master holds a decreasing counter of unresolved morphisms. Newed instances insert in the instances list before the currently morphing instance. Instances deleted from the tail, after the morphing instance, decrease the count.

18. Two morphisms pending on the same type yield a conflict that needs to be resolved or arbitrated.


Hit Counter Created on 05/27/2009 06:31:54 AM, modified on 05/27/2009 06:31:54 AM

Home
Processes
The Enterprise Evaluator
Scope Reduction Mechanism
Programming Languages

Home | Feedback | Contents | Search

Send mail to webmaster@ProximaCentauri.ro with questions or comments about this web site.
All principles and artwork exposed on this site or by our software products is our intellectual property. 
Copyright © 2006 Proxima Centauri Romania SRL. Last modified: 05/27/09