Path: utzoo!utgpu!watserv1!watmath!att!dptg!ulysses!andante!princeton!udel!wuarchive!usc!ucsd!ucbvax!cck.coventry.ac.uk!esx038 From: esx038@cck.coventry.ac.uk ("W. J. G. Overington") Newsgroups: comp.sys.transputer Subject: (none) Message-ID: <20743.9007160835@cck.cov.ac.uk> Date: 16 Jul 90 10:35:45 GMT Sender: usenet@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 128 ALCOR NEWS Issue Number 1 July 1987 Alcor is a new special purpose computer language invented by W. J. G. Overington, in order to provide a software environment for running parallel processing software systems on a network of transputers, with the provided facility that any of the nodes in the network can dynamically specify a software procedure on any other node and, either immediately or later on, initiate the execution of that procedure on the other node. The reason for the inventing of the alcor language is to resolve a circumstance that could occur in a parallel processing system using transputers. It appears to the present author that it is, in a system written directly in the occam language, in principle straightforward for, say, processor number 4 to say to processor number 13 the computer talk equivalent of "You know that when you were set up, you were told that if and whenever you receive an & character, you should execute a certain procedure; well, here is an & character so please execute the procedure". On the other hand, it appears to the present author that it is, in a system written directly in the occam language, not possible for processor number 4 to say to processor number 13 the computer talk equivalent of "Excuse me please, when you have finished what you are doing at the moment, or when you reach a convenient point to break off what you are doing at the moment for a while, could you please execute a task for me. The task is called deneb and this is what I would like you to do, if and whenever you receive the word deneb. You should .". In order to overcome what seems to the present author to be a potential problem for the future development of transputer based systems, he has devised the alcor language. Alcor is a language based upon the forth language, though with a few differences. Firstly, alcor is designed specifically with parallel processing in mind. The only inter-processor messages being by means of sequences of printable text characters, together with the return character used to indicate the end of a message. Secondly, alcor has several data stacks, one for each type of data element used. Thus there is an integer stack, a real stack, a boolean stack and a character stack. There is thought of adding a complex number stack soon. Forth cognoscenti may like to know that whereas forth has DUP as its duplication of the top item on the stack command, alcor has Idup, Rdup, Bdup, Hdup and so on as the commands for the duplication of the top item on the various data stacks respectively. Thirdly, alcor permits forward referencing of as yet undefined words in definitions. This is because alcor is stored in a partly interpretative style. This allows recursive procedures and also facilitates exporting definitions from one node to another node. Fourthly, alcor is, at the moment, without different dialects and it is hoped to keep this advantage so that any alcor program will always be useable on any alcor implementation. The current state of development of alcor is that a simulation, written in pascal, of a 15 node system is up and running on a vax computer. Each node is regarded as being implemented by two transputers, so as to provide a hardware partition between the Sheet 1 of 2, issue 1. transputer handling the alcor system at the node and the transputer handling inter-processor message passing. This design feature is so that the transputer handling the alcor system is never interrupted, and thus delayed in its work, by the need to deal with inter-processor messages travelling via that node. Each alcor system transputer is seen as being in a cul de sac off a binary tree network of message handling transputers. No attempt has yet been made to implement an alcor system on an actual array of transputers, but it is hoped to proceed to this stage in the future, when much of the simulation software can be used to provide the alcor system for each node. Each node is simulated as performing the following pair of operations over and over again ad infinitum. 1. Is there a line of input text waiting to be processed? If so, obey every word on this line of text. 2. Is there a user defined word called auto defined at this node? If so, obey the user defined word auto. Here are a few samples of alcor software to give a flavour of the alcor system. define cube Idup Idup I* I* ; This defines the word cube at the current node. 3 cube This executes the word cube, as defined, at the current node, leaving the number 27 on the integer stack. 13 sendto print" define cube Idup Idup I* I* ;" cr This defines the word cube on node 13. 13 sendto print" cube" cr This causes the previously defined word called cube on node 13 to be executed on node 13, using whatever data in on the top of the integer stack of node 13. A special feature of alcor is what are known as 'five dollar words'. A five dollar word is a word which is sought to be obeyed which has five dollar signs at its tail. For example e$$$$$ might be sought to be obeyed, even though it will not have been defined previously. The alcor system detects the five dollar word and substitutes a five character representation of the top number on the integer stack for the five dollar signs. The alcor system then checks to see if the new word has been defined. If it has not been defined, the five tail characters are replaced each with a zero character. For example, please consider the sequence, define e00000 1 I+ ; define e00045 2 I+ ; 67 e$$$$$ 45 e$$$$$ The 67 e$$$$$ produces the word e00067, which, since e00067 is not defined is replaced by e00000, so the word e00000 is obeyed. The 45 e$$$$$ produces the word e00045, which, since e00045 is defined, is allowed to stand, so the word e00045 is obeyed. Alcor news is written by W. J. G. Overington, Robotics Group, Department of Electrical, Electronic and Systems Engineering, Coventry Polytechnic, Priory Street, Coventry CV1 5FB, England. Sheet 2 of 2, issue 1.