318 lines
17 KiB
Plaintext
318 lines
17 KiB
Plaintext
Newsgroups: comp.theory.self-org-sys
|
||
From: aa954@Freenet.carleton.ca (T. Dunlop)
|
||
Subject: E.D.O.E a Unified View of Computing
|
||
Message-ID: <1993Mar6.072411.3794@freenet.carleton.ca>
|
||
Organization: National Capital Freenet, Ottawa, Canada
|
||
Date: Sat, 6 Mar 1993 07:24:11 GMT
|
||
Lines: 316
|
||
|
||
E.D.O.E a Unified View of Computing
|
||
-----------------------------------
|
||
{ Event-Driven, Data-Oriented, Object-Enviornment }
|
||
|
||
There are only two ways to look at the world:
|
||
1 - Serially, algorothmic, one step at a time, Sychronously.
|
||
2 - Parallel, multiprocessing, many things happening, Asychronously.
|
||
|
||
Most things in the world are neither all sychronouse or all asychronouse,
|
||
but a combination of both. So, why are computers thought of in terms of
|
||
algorithmic processing? Process: even the words we use to talk about
|
||
computers imply single steps one after another, all following along in
|
||
sychronouse fashion. This gets in the way of a simple understandable
|
||
description of problems, the algorithmic rut (we seem to be in) forces
|
||
upon programming convoluted solutions to what should be simple problems
|
||
elegently described.
|
||
|
||
Real time programming is made very difficult because of the algorithmic
|
||
rut! Even object oriented programming (which seems to be an attempt to get
|
||
out of the rut) suffers because algorithms are being used to describe an
|
||
event system. It would be much easier to do it the other way around and
|
||
use an events approach to describe algorithms. Put another way algorithms
|
||
are naturally a subset of events but events can not be made a subset of
|
||
algorithms! There lies the problem and the reason there is a need for a
|
||
Unified View of Computing.
|
||
|
||
The seperation of the two views lies at the bottom of the problem and
|
||
at the heart of all computing. To fix the problem and Unify the View of
|
||
Computing means rethinking from the ground up. Starting at the Processor.
|
||
E.D.O.E as a Unified View of Computing can sit just above any single
|
||
processor or multiprocessor design and all will appear to the user,
|
||
programmer, and programs as having no difference, as being no different
|
||
except for speed of execution.
|
||
|
||
The flip side of any computer is the Interrupt system, an Event System.
|
||
This is what must be merged with the algorithmic instruction pointer to
|
||
build a Unified View of Computing. Whether we build such hardware in the
|
||
future is not an issue, though the CM-5 may be very close. For the
|
||
programming enviornment built upon the hardware can easily merge the two
|
||
concepts into a single programming model!
|
||
|
||
The difficulity in doing so is small but means rethinking much of what
|
||
computing is today. The heart of the problem is in how Instruction Pointers
|
||
are handled and viewed in todays approachs to computing. If we rebuild from
|
||
the instruction pointer upward again we can unify the view of programming
|
||
into a single simple model.
|
||
|
||
The instruction pointer needs to be under the programmers control. This
|
||
requires that there be methods to create, terminate, suspend, and restart
|
||
the instruction pointer(s) as required by the description of the problem
|
||
being solved, described as a program on the system. The four methods can be
|
||
done as three, this solves the need to know what type of object is being
|
||
addressed, used, by a method, and allows their use in sychronous as well
|
||
as asychronous solutions to problems. I refere to the fact that objects can
|
||
be either active of passive, the same holds true for messages.
|
||
|
||
1 - Start processing at location.
|
||
2 - Terminate instruction pointer, free for reassignment.
|
||
3 - Suspend execution for restart at location, but do not reassign.
|
||
|
||
Are the three methods required to handle instruction pointers. With the use
|
||
of Enviornment Variables and nesting counts the three methods can easily
|
||
determine what is required and free the programmer from having to be overly
|
||
specific in requesting that a new instruction pointer be used or in assigning
|
||
the use of an existing instruction pointer. This is accomplished with a message
|
||
object placed in the object enviornment, a high level view of the instruction
|
||
pointer.
|
||
|
||
With a Message Object in the object enviornment the two views of computing
|
||
are merged and yet retain their seperate identity. The object enviornment
|
||
is the Event System and the Methods are the algorithmic sub-elements within.
|
||
And the programmer is freed to choose whatever approach is most approprate
|
||
for the description of a problem.
|
||
|
||
---
|
||
The current object approach folds the methods upward where the
|
||
message addressing hierarchy needs to be. It is a result of using algorithmic
|
||
approachs to deal with events and needs to be unfolded, placing the methods
|
||
and their associated alogrithms below that of objects. Algorithms are the
|
||
building blocks from which methods are constructed, algrothims are not a
|
||
part of the descriptive hierarchy of, type, group, class, categorie, ...
|
||
When I write a letter I use a hierarchy to address it, from specific to
|
||
general. Or a phone call uses a hierarchy of codes to reach the correct
|
||
destination, from general to specific.
|
||
|
||
This in turn causes a minor problem associated with subroutines,
|
||
function calls and macro expansion. The solution is to use a boundary to
|
||
enclose groups of objects and their associated methods into functional
|
||
elements such as devices, programs, event handlers, GUIs, ...
|
||
These boundaries can then be viewed as larger self-contained black-boxes.
|
||
The algorithmic elements contined within are for the most part not useful
|
||
beyond these larger boundary.
|
||
|
||
To have the E.D.O.E approach work this folding has to be undone. Methods
|
||
can not be thought of as belonging to super-classes, but must be thought of
|
||
as building blocks, a resources to be used within the system. To this end
|
||
methods are the store house boundary for IP algorithms.
|
||
|
||
Events can also be used to describe algorithmic solutions to problems so
|
||
where is the dividing line at what point do instruction pointer algorithms
|
||
end and event algorithms begin? That point is at the subroutine call in BASIC
|
||
or the function call in 'C' below this event-messages are not efficient. It is
|
||
more practical to use the instruction pointers assembler instructions, they
|
||
consume fewer cycles than processing a message requires.
|
||
----
|
||
Objects as Black-Box Elements is what the event system is, a message
|
||
enviornment filled with active, passive and quiesient objects. The instruction
|
||
pointer rides along as part of the message, yes all messages are active in
|
||
this respect. The instruction pointer at the destination is used to run the
|
||
initial method, what happens after that depends upon the type of object and
|
||
the type of message, active or passive. Sending a passive message to a passive
|
||
object doesn't make a great deal of sense but there are uses for it, such as
|
||
setting up the context within which an instance is be used before activating
|
||
the method to be applied to that instance of an object.
|
||
----
|
||
Methods as Black-Box Elements are the store house of the algorithmic
|
||
instructor pointer elements, the pseudo-assembler language of E.D.O.E.
|
||
With the inclusion of target assemblers as part of the E.D.O.E system any
|
||
program could be quickly assembled and pre-bound into the enviornment.
|
||
|
||
What to do with methods that are not associated with, do not belong to, an
|
||
object is a problem. Placing them in a method hierarchy, a seperate class
|
||
structure from that of the objects, is a resonable solution.
|
||
|
||
Which eliminates another headache in computer programming, understanding,
|
||
and use. Also allows each user to put together a custom enviornment to
|
||
meet their individual needs, requirements, and equipment. The user would
|
||
be free to pick and choose among programs, methods, and pieces written by
|
||
themselves. Late or early binding of the objects would not matter, except
|
||
for the peniality in speed encured in looking for objects not pre-bound.
|
||
|
||
I see this as a virtual-memory system which banishes the problems of
|
||
fetching, accessing and binding with objects on disk to a seperate
|
||
peripherial domain rather than being a part of the E.D.O.E enviornment.
|
||
----
|
||
I am in a partial void here. I can read books, magazines, watch
|
||
T.V. programs, but have no-one to disscuss my ideas with. Hopefully the
|
||
UseNet will be a resonablely safe place to meet, talk with, others that
|
||
have a knowledge equal to or that exceeds my own. It is difficult to
|
||
know if I am going in the right direction, how the world will accept
|
||
my ideas, theories, designs. I think E.D.O.E is the first step in
|
||
building a Thinking Reasoning Machine, that is where this need for a
|
||
unified view comes from, the reverse designing of ACI concepts.
|
||
|
||
There is just too much, too many pieces. I am not good at making
|
||
assumptions about my audience. And this is a first posting, make that
|
||
the first posting to any UseNet News Group. I am trying to guess some
|
||
of the questions and answer them, dum idea I suspose? I am trying not
|
||
to loose everybody with new concepts, or new definitions applied to
|
||
old words...etc...
|
||
|
||
Sincerely T. Dunlop aa954@freenet.carleton.ca
|
||
March, 01st, 1993 Ottawa, Ontario, Canada
|
||
Copyright T. Dunlop 1993
|
||
|
||
E.D.O.E objects
|
||
---------------
|
||
|
||
Environment Variables, UnBounded Global Variables - can be used to share
|
||
information with other objects or to set up the context (environment) with
|
||
in which an instance is to function. All Environment Variables are owned
|
||
by some object they are the simplest way to pass information among objects.
|
||
They can be used to wake up a quiescent object.
|
||
|
||
Report Objects - are the high level structure of interrupts. They send events
|
||
into the envvironment, (report upon what goes on with out). A disk is
|
||
inserted in a drive, the printer wants more attention, the user has
|
||
pressed a mouse button, or their are key strokes,...etc...
|
||
|
||
Control Objects - complement the report objects by sending commands out of
|
||
the environment to the external hardware. read the track, turn on the
|
||
motor, place the printer in underline mode,...etc...
|
||
|
||
IP Objects, Instruction Pointer - is a machine specific implementation and is
|
||
at the heart of building a Unified Environment!
|
||
The IP object is just one part of a collection of pieces that together
|
||
allow the events and algorithmic aspects of the E.D.O.E environment to
|
||
co-exist.
|
||
Note: If the Instruction Pointers are not handled properly here and in the
|
||
Message Objects the whole environment will suffer.
|
||
|
||
There are three methods that apply to the Instruction Pointers
|
||
|
||
1 - Start at location, or ReStart a quiescent IP.
|
||
2 - Terminate IP, free it for reassignment.
|
||
3 - Suspend processing but do not reassign, set up a restart location.
|
||
|
||
On a single processor system the need to Time Slice the CPU's action is
|
||
required. This is done with a hardware clock and a queue of active
|
||
instruction pointers. The discontinued IPs are kept in a list for
|
||
reassignment, and IP in a suspended atate are marked with a flag.
|
||
Leaving the quiescent IPs in the queue means testing every IP, but
|
||
taking them out means the bother of placing them back in each time the
|
||
object they are assigned to is activated. Which is better depends upon
|
||
the application: If you have a large number of IP and only a few are
|
||
quiescent then testing each wastes CPU cycles. But if you have a few IPs
|
||
and most are quiescent then the overhead of removing them and placing them
|
||
into the queue list can be large. And somewhere in between either will
|
||
work equally well.
|
||
I think the removal of quiescent IPs from the queue in the long run is
|
||
a better, prefered, choice. It has the advantage of speed with a large
|
||
number of IPs and the extra processor cycles freeded between events that
|
||
may happen infrequently should off set the load and removal time. Yes, their
|
||
are of course exceptions to this reasoning somewhere I expect.
|
||
|
||
Note: The quiescent IPs are usually assigned to report objects associated
|
||
with incomming interrupts as a means to speed interrupt processing,
|
||
responce. But for some object types are equally valuable with in
|
||
the environment.
|
||
|
||
Message Objects - are the high level representation (program objects) of the
|
||
the Instruction Pointers!
|
||
The problem is, Where do events stop and algorithms begin?
|
||
Events are so flexiable as to allow algorithms to be defined as a subset
|
||
of events! Using events to describe an algorithm is possible but not always
|
||
very efficient because of the overhead of message processing. I think you
|
||
would agree that placing a message between each assembler instruction to
|
||
pass the IP along is just not very efficient. What about test and branch
|
||
or a subroutine jump and return? How about a function call in 'C' or a GoSub
|
||
in 'BASIC'? You see the problem. The function call is about right for one
|
||
to end and the other to take over. That acts as a resonable guide.
|
||
What about synchronous and asynchronous operation? The same ability to
|
||
use events to describe algorithms allows a simple solution to synchronize
|
||
events, If the programmer has control of the Messages IP Type! For method A
|
||
to synchronize with method B, method A can pass its IP to method B which will
|
||
return it when method B has completed. Sort of a game of Tag Your It.
|
||
Asynchronous operation comes in several forms depending upon the type of
|
||
object being activated, a passive object needs an IP to become active. An
|
||
active object can be quiescent, requiring waking up first.
|
||
With careful design of the IP object and the three methods associated with
|
||
them some of the problems, a need to know just what type of object is being
|
||
activacted can be eliminated. And at the same time allow the programmer to
|
||
choose whether the object is to be used synchronously or asynchronously.
|
||
This involves environment flags and a nesting count that the three methods
|
||
can question.
|
||
|
||
To me the problem here is not how to activate an object but ensuring that
|
||
it will do what the programmer wants with the instance its asked to operate
|
||
with, upon. This is where the Environment Variables are most helpful,
|
||
allowing the context to be preset before the object:instance is activated.
|
||
Note: The activating object may not be responsible for setting the
|
||
Environment Variables, they coould be set by other objects or
|
||
even the user selecting options in a GUI interface.
|
||
|
||
I suspose their are plenty of other pieces I could deacribe, but to me
|
||
these are the important parts. The pieces that show how Events and
|
||
Algorithms can live happily together in a Single Unified Environment!
|
||
Allowing the user to choose the most natural approach to describe the
|
||
solution to a given problem!
|
||
|
||
A single simple Unified View of Computing!
|
||
That is what E.D.O.E is designed to be !!!
|
||
{ Event-Driven, Data-Oriented, Object-Environment } = E.D.O.E !
|
||
|
||
Sincerely T. Dunlop, aa954@Freenet.carleton.ca
|
||
Ottawa, Ontario, Canada.
|
||
February 15th 1993.
|
||
|
||
The Law of Complexity
|
||
---------------------
|
||
1 - All systems are driven. No driving force, no change.
|
||
- It's just a matter of finding the 'Force' => lambda factor.
|
||
|
||
2 - Self-Organisation allows the driving force to be more easily
|
||
resisted, thus the system remains unchanged longer.
|
||
- '2 is stronger than 1 and 3 is better than 2'.
|
||
|
||
2a - Some systems can only Passively resist the driving force.
|
||
|
||
2b - Others can Actively resist, use the force, convert it into
|
||
something else, change the force or redirect it,
|
||
or emit the force outward again.
|
||
|
||
3 - The lambda point => When the driving force (lambda factor)
|
||
is equal to the boundary to chaos.
|
||
|
||
3a - Increasing the force drives the system into chaos.
|
||
- The order (organisation) will collaspe, break down.
|
||
- (?) is entrophy a form of excess force ?
|
||
|
||
3b - Decreasing the force the system becomes cyclic.
|
||
- When the force is below that needed to drive the system into
|
||
chaos the system will store the force and cycle as the value
|
||
exceeds the lambda point, at the edge of chaos.
|
||
|
||
3c - Remove the driving force and the system will solidify or stagnate.
|
||
- the system will cease to change.
|
||
- action driven by the lambda force factor will terminate.
|
||
- and (?) entrophy takes over.
|
||
|
||
4 - Entrophy can be viewed as the removal, bleeding off, of any stored
|
||
lambda force in the system.
|
||
|
||
5 - Large systems can be viewed as a whole with the lambda force being
|
||
applied from without, externally, or as a collection of smaller
|
||
subsystems interacting where the lambda force is being moved around
|
||
within the larger whole and affecting each of the parts seperatly.
|
||
----------------------------------------------------------------------
|
||
T. Dunlop aa954@Freenet.carleton.ca February 10, 1993.
|
||
|
||
I suspose you could call it a new 3rd law of thermodynamics or
|
||
a new 2nd law, but 'The Law of Complexity' seems to ring true.
|
||
Where are you Stuart Kauffman, Chris Langton, John Holland, Doyne Farmer,
|
||
Murray Gell-Mann, and George Cowan? I hope you get a chance to read this.
|
||
|
||
Sincerely T. Dunlop,
|
||
Ottawa, Ontario, Canada
|
||
----------------------------------------------------------------------
|
||
--
|
||
|