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: <20900.9007160836@cck.cov.ac.uk> Date: 16 Jul 90 10:36:28 GMT Sender: usenet@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 656 ALCOR NEWS Issue Number 3 July 1988 Alcor is now moving from the, "let's try it out to see if it will do what I want it to do" stage into becoming a properly documented, state of the art computer language. I am therefore redesigning the internal structuring of the pascal program which is the current implementation of the alcor language, extending the documentation, seeking to get alcor implemented on some actual transputer hardware and starting to write a book about the alcor language and its applications. The writing of the book will take quite some time as I am hoping to produce a definitive work. However, I am hoping that it will become published, (under such circumstances that I do not have to assign my copyright to any person or organization and that my work is not editorially altered), in the not too distant future. In this issue of Alcor News there are items on a number of new features that I am adding to the language. These are as follows. Special category user specified words in alcor. Alcor dictionary searching facilities. Object code within alcor. Exporting definitions between nodes. The $read command and an application example. The case statement in alcor. Of these features some are implemented in my 15 node simulation, written in pascal that runs on a vax, some are partly implemented and some are not even started to be implemented yet. Special category user specified words in alcor, the $read command and the case statement are all implemented; the alcor dictionary searching facilities are partly implemented and I am thinking about how to expand their scope somewhat; the object code and the export facilities are only just being started to be implemented at the time of writing this issue of Alcor News. Also, I have included a section about the internal method of handling user defined words, which is yet only partly implemented. Special category user specified words in alcor. ------- -------- ---- --------- ----- -- ------ The alcor language is certainly suitable for performing general purpose calculations, though at a lower speed than could be obtained by using a specially written pascal program which had been specially compiled. Alcor has its advantages in the regions of convenient dynamic program generation onto other nodes in a transputer system. Recognizing that there is this slower running speed overhead, which could be, in some applications, of concern, the alcor language has a special facility to improve both speed of running and, potentially, programming convenience in certain cases. For example, please consider a situation where one wishes some particular node of the transputer system to, say, interface a camera which is viewing a plan view of a conveyor belt in a robotic work cell. One possible approach to this situation would be to write a few low level special words which interfaced the camera to the alcor system, which words would effectively be standard alcor words as far as the local version of alcor were concerned. The user could then define one or more user defined words which used these words Sheet 1 of 10, issue 3 of Alcor News, by W. J. G. Overington. in order to pick up the data from the camera and put it into memory storage defined within the alcor system. It is, however, a better prospect, where a particular computation intensive process will need to be repeated often, to build in a special local word which does all of the necessary computation. Alcor provides clearly marked places for doing this in the pascal source code in which it is written. These words are called special1, special2, special3 and special4. Here is the listing of the procedure special1 from the pascal source code in which alcor is written. procedure special1; begin (* ------------------------------------------------------- *) (* *) (* | *) (* | If you wish to define special1 as your own locally *) (* | defined word, then please put the pascal software *) (* | in here. Interfacing of the word special1 to the *) (* | alcor system is already programmed into the alcor *) (* | system and you need not concern yourself with this *) (* | aspect unless you wish to investigate it for your *) (* | own interest. *) (* | If you do not wish to use special1, you do not need *) (* | to do anything with this section at all. *) (* | *) writeln('The alcor word special1 merely performs the built-in '); writeln('default operation, namely the printing of this message. '); writeln('If you wish to have a built-in special1 word, you will '); writeln('need to obtain a copy of the source program alcor.p and '); writeln('change the software in the special1 procedure definition'); writeln('to produce a file called local.p which will need to be '); writeln('compiled to produce your own local alcor program. Please'); writeln('know that you do not need to alter the way in which the '); writeln('alcor system recognizes the word special1. '); (* | *) (* v *) (* ------------------------------------------------------- *) end; The procedures special2, special3 and special4 are identical to the procedure special1 except for the characters 1 being replaced by characters 2, 3 and 4 respectively. I am aware that I have made a great point about alcor always being standard yet that I have also included the facility of special1, special2, special3 and special4. This means that any alcor program listing using one or more of the words special1, special2, special3 or special4 will of necessity be non-standard alcor software. However, the only exception to the general principle that alcor software is standard will be in software where special1, special2, special3 or special4 are used. Any such usage will be easily detectable. A potential user of the software will then need to decide whether to implement the special local version of alcor required in order to handle the non-standard software. I hope that I have struck a fair balance between having a standard system and providing flexibility for specialist usage. I feel that an advantage of this approach is that alcor software will be standard unless it is very non-standard. I wish to avoid particularly having a variety of slightly different alcor systems Sheet 2 of 10, issue 3 of Alcor News, by W. J. G. Overington. which leads to most alcor software having to be slightly modified before it will run properly on some other alcor system. This sort of apparently trivial translation exercise can, in fact, take a great deal of time. I feel that it is well worth making the effort for total standardization right from the start. A practice that anyone distributing non-standard alcor software to other people should include a note giving either the pascal source code for the special words used or details of how it could be obtained would be helpful. Alcor dictionary searching facilities. ----- ---------- --------- ----------- An interesting feature of the alcor language, and one in which it differs from the forth language upon which it is based, is the fact that in alcor the places in internal memory where the information about the meaning of user defined words and the like are stored are not accessible to the user. The design philosophy for this is that it avoids any operation of a user program being dependent upon any node-specific memory addresses. There are, however, situations where one wishes to perform some of the operations that forth allows as a consequence of it having the facility to find out where definitions are stored, but which would not cause a node-specific problem such as mentioned above. An example of this is involved in desiring to obey whatever word is on the top of the word stack, which involves finding out whether a definition for some given user defined word exists at the node. The word Wliteral in an alcor statement will cause the word which immediately follows Wliteral to be placed on the alcorword stack. The word obey causes whatever word is on the top of the alcorword stack to be obeyed. Object code within alcor. ------ ---- ------ ------ An important feature of alcor is its standard format and the fact that variant versions do not exist. This feature is considered at all times when the extension of the alcor language is desired. Many implementations of forth permit the inclusion of words which are defined in the machine code of the particular processor being used. This has advantages and disadvantages. Access to machine code instructions is gained at the cost of reducing software portability. Now, as it happens, the present author, as personal research, has been developing a portable object code for a number of years. This is called 1456 object code and is designed as a proposed international system standard for telesoftware, which is the author's invention that produces a remote access interactive computer system by means of the unidirectional cyclic broadcasting of software. The usual method of broadcasting is by placing software on teletext pages. When one considers the possibility of broadcasting software from a direct broadcast satellite to whole continents, the potential for education is enormous. Telesoftware does not use any return information link whatsoever to the central broadcasting computer. The original concept of 1456 object code, back in the late 1970s, was because there would be legal difficulties in broadcasting authorities agreeing to a broadcasting standard which involved a proprietary microprocessor. For that reason 6800, Z80, 68000 and Z8000 are Sheet 3 of 10, issue 3 of Alcor News, by W. J. G. Overington. all unsuitable for use in a broadcasting standard, regardless of their scientific suitability for the purpose. The concept of 1456 object code today is that, although the idea to have 1456 object code arose out of a legal problem, given that a special, manufacturer independent, system is necessary, then it is best to make 1456 as scientifically elegant as is possible. The way that 1456 object code is envisaged as being used is that all user telesoftware equipment has a piece of software, specific to that type of proprietary equipment, running in it; that piece of software being called COMET. There will thus need to be as many versions of COMET in existence as there are types of user equipment in use. In practice, this will probably mean the existence of about five to eight different version of COMET. The COMET program converts a program written in 1456 object code into a compiled program in the machine code of the processor on which the COMET program is running. Thus a telesoftware service would carry only one version of any given program, written in 1456 object code, but this would be automatically converted in equipment of various end users to be a program in, say, 6800, Z80, 68000 or Z8000 machine code. It has occurred to the author that it would be useful for 1456 object code to be the method of putting machine code sections into an alcor program. An initial advantage is that it would mean that all alcor program listings would be portable between alcor systems running on different hardware. For example, I have it in mind to continue to run alcor in simulation on a vax computer, to implement a version to run on an IBM Personal Computer, or a compatible machine, and also to run alcor on a network of transputers. On the vax, the 1456 code will be interpreted in a simulation, on the PC the 1456 code will be compiled to give an 8086 machine code program, on the transputer network, the 1456 code could be interpreted in a simulation or, with more initial programming work, compiled into a transputer machine code program. Here is a short example of how a 1456 object code program would be used in an alcor system. Please know that the example piece of 1456 object code presented is only intended as a teaching example as it does not include any mechanism for extracting the answer back into the alcor language system. The example is to take as immediate data the integer 2 and add to it the immediate data of the integer 3 and then halt. The halt command will be interpreted as a return back into the main alcor language system. In 1456 object code, parameters are placed before the operation code and parameters are always expressed in octal notation. A load immediate command is expressed by w and an add immediate command is expressed by p. Thus load immediate 2 is expressed by 2w and add immediate 3 is expressed by 3p. The halt is expressed as H. An entry point to the program, label 1, expressed by 1: needs to be added, in this case at the beginning of the software and a "compile and execute" command to the COMET system, expressed as a = character, needs to be added at the end of the 1456 object code program. Thus the example program is expressed by 1:2w3pH= and this is entered in alcor by a definition such as define x entercode" 1:2w3pH=" ; Upon executing the user defined word x, the 1456 object code is obeyed. Now, in order that long 1456 object code routines may be entered, there also exists the alcor word morecode" whereby extra Sheet 4 of 10, issue 3 of Alcor News, by W. J. G. Overington. 1456 object code may be entered but without creating any runtime entry point into the 1456 object code. For example, the simple demonstration program above could be entered in two sections such as define y entercode" 1:2w" ; define z morecode" 3pH=" ; Obeying y would produce exactly the same effect as obeying the word x above. Obeying z would produce no effect, as morecode" has no runtime effect. Another equivalent effect could be produced by define e entercode" 1:2w" ; define f morecode" 3p" ; define g morecode" H=" ; Here, obeying the user defined word e would produce the same effect as obeying x or y above. Obeying f or g would produce no effect at all. In the compilation of 1456 object code, the 1456 object code is two pass assembled to produce the local code machine code task. In situations where the 1456 object code is interpreted, it is also initially two pass assembled in order to satisfy address commands within a current module and also any links to other modules that have been entered (1456 object code entering any subroutines before the main program, so that link loading can be easily performed). A consequence of the existence of the facility of the word morecode" is that the two pass assembly must not commence until all of the 1456 code has been entered, using one use of the word entercode" and as many uses of the word morecode" as desired. A convenient arrangement is that the 1456 object code is two pass assembled upon the first attempt at executing it. Accordingly, there is a flag, stored in the alcor entry for the particular use of the word entercode" to indicate whether that code has yet been two pass assembled. The flag is stored in the entry for the particular use of the word entercode" rather than as a global flag in order to allow the user to define more than one user defined alcor word containing a machine code section on any given processor in the network. Care must be taken in designing a machine code module so as to avoid any infinite loops. The 1456 object code system effectively floats in a physical memory map by having addresses stored in a linking table. The alcor language provides a way of loading data in and taking data out of the 1456 environment by means of the words to1456 and from1456 which put data in and take data out of the 1456 environment address which is specified by the top two locations of the integer stack. The top location of the integer stack in such a circumstance is an index value (which will often be 0) and the top but one location a pointer to the 1456 environment link address list. The link address list is very important in 1456 object code. Consider that we wish to extend the 1456 object code example above so that we can extract the number 5 which it computes into the alcor system. Having performed the immediate addition, using the 3p instruction, we must store the result, which will be in the 1456A register, in memory. We define a unit of memory at, say, label 7, by using 7:/ where / reserves a unit of memory for data storage. 7:4/ would have initialized the data location with the number 4 octal. Sheet 5 of 10, issue 3 of Alcor News, by W. J. G. Overington. The actual storing operation is 7S where 7 is the label number, in octal. The sequence to perform the addition in the 1456 environment and put the result on the integer stack of the alcor language consists of a definition involving both 1456 code and alcor commands. define u entercode" 1:2w3p7SH7:/=" 7 0 from1456 ; Please note that this definition could be split in various ways, for example define a entercode" 1:2w3p" c ; define b morecode" 7SH7:/=" ; define c 7 0 from1456 ; Exporting definitions between nodes. --------- ----------- ------- ------ Another feature that I am designing into alcor is the ability to export a definition from one node to another. The desire to do this is the reason why the originally entered alcor definitions are retained in storage, notwithstanding that the meanings of the definitions are compiled. In a typical case, a word exported from one node to another will not be compiled with the same internal code numbers at the other node. Thus, the exporting of the definition of a word must be in the original alcor text format. I am seeking to implement the word export in alcor so that all words called by the named definition are also exported, and so on recursively. This will take some care as, it will be remembered, alcor definitions may call themselves and each other. I have it in mind that the word named for export will be placed in a list, initially as the only member of the list. The definition of the named word will be searched and any user defined word found, as long as it is not the named word itself, will be added to the list. The next word, if any, on the list will then have its definition searched and any user defined word found will be added to the list unless it is already on the list. One by one, all the words in the list will be analysed and eventually the list will cease to grow in size. A copy of the alcor text of each word in the list will then be transmitted to the new node. Thus all the definitions needed to permit the named word to be executed on the new node will automatically be sent to the new node. The $read command and an application example. --- ----- ------- --- -- ----------- -------- A useful command which I have built into my current simulation of a 15 node system running alcor, which is written in pascal and runs on a vax under unix, is the alcor word $read which, when executed causes all subsequent input to the alcor system to be taken from a file called alcortext rather than from the keyboard. This input text is treated exactly as if it had been entered at the keyboard, except for the word quit. In the keyboard mode, quit causes the user to leave the alcor system, whereas in the alcortext mode quit causes the user to go back to the keyboard mode. In my development work with alcor I have various unix directories each containing a file called alcortext. I can choose which directory I am in when I start alcor running and thus, by merely typing $read, I can load the contents of the alcortext file in that directory into the alcor system. It is possible to run a complete alcor program from an alcortext file, but I have Sheet 6 of 10, issue 3 of Alcor News, by W. J. G. Overington. tended to use the alcortext facility to load up a collection of definitions onto various nodes so that I can then try various experiments interactively from the keyboard using the definitions thus entered. Here, however, is a load and go program from an alcortext file. 3 sendto print" define start v 0 150 continue ;" cr 3 sendto print" define v 8 sendto message cr ;" cr 3 sendto print" define message print' setup' ;" cr 3 sendto print" define continue a 8 sendto b cr ;" cr 3 sendto print" define b Iprint print' pp' ;" cr 3 sendto print" define a I+ 100 I- Idup ;" cr 8 sendto print" define setup 150 90 I! ;" cr 8 sendto print" define pp q 3 sendto Iprint u cr ;" cr 8 sendto print" define u print' continue' ;" cr 8 sendto print" define q 80 I! qq 90 I@ ;" cr 8 sendto print" define qq qqhi qqlo ;" cr 8 sendto print" define qqhi if hi then golo endif ;" cr 8 sendto print" define hi 80 I@ 900 I> ;" cr 8 sendto print" define golo 50 90 I! ;" cr 8 sendto print" define qqlo if lo then gohi endif ;" cr 8 sendto print" define lo 80 I@ 500 I< ;" cr 8 sendto print" define gohi 150 90 I! ;" cr 3 sendto print" start" cr quit The purpose of this demonstration is to construct a simple representation of an algand called qq on processor 8 and to have it interrogated from processor 3. The user types $read and then watches the effect. The case statement in alcor. --- ---- --------- -- ------ The case statement in alcor is of the form define z caseof I1 is X1 : I2 is X2 otherwise X3 endcase ; For example, define p caseof 4 is u : 7 is v otherwise w endcase ; define q caseof 8 is u : 9 is v : 10 is x otherwise w endcase ; where I1, I2 are either integers or words which leave an integer on the integer stack. It is interesting to compare and contrast the operation of alcor case and if constructs. The alcor case statement starts with define name caseof I1 is X1 and finishes with endcase ; In between are as many occurrences as desired of the format : Ii is Xi followed, optionally, by one occurrence of otherwise Xj The alcor if statement starts with define name if C1 then X1 where C1 is a user defined word which leaves a boolean value on the boolean stack, and finishes with endif ; Sheet 7 of 10, issue 3 of Alcor News, by W. J. G. Overington. In between are as many occurrences as desired of the format elseif Ci then Xi followed, optionally, by one occurrence of else Xj It can be observed that the word structure is thus in one to one correspondence, namely caseof if is then endcase endif : elseif otherwise else Indeed the correspondence goes further, in that in executing these structures, the alcor system, upon executing certain words seeks to look forward for the next occurrence of one of a given set of words and then continues execution at the next word after the found word. The alcor word caseof does nothing. The alcor word if does nothing. The alcor word is compares the top two items on the integer stack to form a boolean result, which it places on the boolean stack. In comparing the two integers, the top item on the stack is lost, but all other items on the integer stack are unaffected. The word is then takes the top item on the boolean stack and if it is true continues processing, otherwise it searches forward for the next occurrence of any of the alcor words : otherwise endcase and continues processing at the next alcor word after that. The alcor word then takes the top item on the boolean stack and if it is true continues processing, otherwise it searches forward for the next occurrence of any of the alcor words elseif else endif and continues processing at the next alcor word after that. In execution terms, the different actions of the alcor words is and then are the only significant differences between the case and if statements in alcor. The alcor word endcase does not do anything when executed, but is included in the case statement to act as a marker for forward searches by the alcor words is : otherwise. The alcor word endif does not do anything when executed, but is included in the if statement to act as a marker for forward searches by the alcor words then elseif else. The alcor word : searches for endcase immediately. Please note that if the word : is encountered in a properly written case statement, the desired case has already been encountered and the corresponding desired action has already been taken. The alcor word : is also used as a marker in searches by the alcor word is. The alcor word elseif searches for endif immediately. Please note that if the alcor word elseif is encountered in a properly written if statement, the desired condition has already been encountered and the corresponding desired action has already been taken. The alcor word elseif is also used as a marker in searches by the alcor word then. The alcor word otherwise searches for the word endcase when it is executed. It is also a marker in searches by the alcor word is. The alcor word else searches for the word endif when it is executed. It is also a marker in searches by the alcor word then. Sheet 8 of 10, issue 3 of Alcor News, by W. J. G. Overington. This can be summarised in a table. Alcor Searches Searches Searched Searched word unconditionally conditionally unconditionally conditionally for next of for next of for by for by ----- --------------- ------------- --------------- ------------- caseof - - - - if - - - - is - : - - otherwise endcase then - elseif - - else endif endcase - - : is otherwise endif - - elseif then else : endcase - - is elseif endif - - then otherwise endcase - - is else endif - - then I have also taken the opportunity to build into alcor the word null as a word which does nothing at all. This is to enable statements such as define e caseof 3 is g1 : 4 is g2 otherwise null endcase ; to be written in an alcor program, for clarity of a program listing, so that it is clear that the general case has not been forgotten to be programmed. The internal method of handling user defined words. --- -------- ------ -- -------- ---- ------- ------ The internal working of the alcor system when obeying a previously entered definition, or a definition called by a definition, and so on, is that each alcor instruction is known to the system by four software objects, namely a ten character array of characters called the softwarename, an integer called the softwareparameter, an integer called softwareprecompiled and an integer called softwarelocator. The system could, in fact, run quite happily on just softwarename and softwareparameter, but use of softwareprecompiled and softwarelocator provide an important increase in speed. Softwarename contains the name of an alcor word to be obeyed. This word may be a user-defined word, an alcor built-in word or a number. In the event of it being a user-defined word, the word is obeyed, which, in practice, means that the return stack is pushed and operation continues from elsewhere in the system. An alcor built-in word is simply obeyed, producing the effects specified for that particular word. These effects cover arithmetic, logic and conditional constructs, as well as returning from definitions. A number is simply placed on the appropriate data stack; the integer stack if there is no decimal point in the word and the real stack if there is a decimal point in the word. Softwareparameter is not used by all words, but is used by some words to good effect. For example, a print" command, to print a string of text, has the string of text stored in the array bitsoftext and softwareparameter stores Sheet 9 of 10, issue 3 of Alcor News, by W. J. G. Overington. the index of the start of the string in the array bitsoftext. Softwareprecompiled stores an integer which specifies the value of the internal codenumber of the word in softwarename. At initialization, all softwareprecompiled cells are set at zero, and are only altered at the first time that the word in softwarename is attempted to be obeyed. This means that the first time of passing any particular softwarename entry, the word in softwarename must be searched for in the list of user defined words and possibly also in the list of standard words. Once the word is found, the codenumber found is inserted in the softwareprecompiled cell, so that the next time that that word is reached (if indeed it is reached) a quick check to see if the value in the softwareprecompiled cell is non-zero will save all of the list searching. The reason that the searching is performed at the first attempt at running rather than at entry is so that words may be entered that reference words not previously entered and may also reference themselves in order to produce recursive effects. Softwarelocator is used principally in alcor conditional constructs. For example, in an alcor if statement, the alcor word then may need to search to find the alcor word after the next occurrence of any one of the three alcor words elseif, else, endif. The first time that the word is obeyed, the search needs to be sequentially forwards, checking each word encountered. Once, however, this search has been done on the first occasion, the position in the softwarename array to where the program control should jump is stored in softwarelocator, thereby saving time on future occasions. Softwarelocator is also used in using object code sections. In this case, once the entry point to the compiled software is entered in softwareparameter, the starting point of the uncompiled software in cometinputbuffer is stored in softwarelocator. The purpose of this is so that the original uncompiled software may be located and copied out should the user-defined alcor word containing it need to be exported to another node in the system. It cannot be assumed that a number in softwarelocator is automatically a jump in the control of the system, for, in the first place the number may not be indicative of a jump at all, and secondly, even if it is a jump destination, that jump may not be unconditional. Reference should always be first made to the value in the softwareprecompiled cell and, if that is zero, to the name in softwarename. There are a few additional special cases to consider. An integer value is precompiled using a number that means Integervalue, and softwareparameter contains the index to an array of integers called integervalues where the integer value is stored. The word Integervalue does not actually appear in softwarename as the text format of the integer is retained in softwarename in case export of the definition is required. A real value is precompiled using a number that means Realvalue, and softwareparameter contains the index to an array of reals called realvalues where the real value is stored. 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 10 of 10, issue 3 of Alcor News, by W. J. G. Overington.