🚀 go-pugleaf

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.