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 ---------------------------------------------------------------------- --