This part of the paper gives some additional information which will, hopefully, give a clearer understanding of how the concepts work. The text first discusses an application translator which will be made available for persons to view (or they can develop their own) in mid May 2005. It also illustrates two simple examples in more detail.
The translator

One objective of the approach is to be ethnic language independent, which is achieved by using a language table such as follows:
Table 10,'deflooping',5,'arith',7,'looping',10,'defineloop',8,'binarray'

This table can be in any Western based language, but should also be adaptable to languages such as Arabic and Hebrew.

The translator simply looks at the relative position of each language element in an application and gives an associated relative number (e.g. looping is 2, getarray is 6). As new language elements are added they are simply tagged on to the end of the table.

In developing a Java run system a table was developed corresponding to the Java byte codes, although the nature of the Genetix run system was such that it was not necessary to have a table element for each Java byte code. The same could be done for Forth, APL, Fortran, Cobol, Algol etc. While it may appear that there is a limit of 256 language elements this is easily overcome.

Each language element is associated with a language element string of numbers in the run system, as was indicated in Part 1. This will be outlined in more detail shortly.

Development language

The actual detail of the language will not be given at this time, just a summary being included. Considerable expansion of these language elements will take place. Brief descriptions of a couple of applications using the language will be given following the syntax, which is presented in alphabetic order.
addon attaches current variable to end of record
addtext adds additional text
arc drawing of arc
arcsin calculates arcsin
arctan calculates arctan
arith performs arithmetic operations
binarray creates array with initial values
bitmapp generates bitmap image
cases transfers to case specified
ceil calculates ceil
clear clears the screen and proceeds
cosine cosine of a into b
cotangent cotangent of a into b
createfile creates a new file on hard drive
defineloop establishes parameters for a named loop
deflooping operates on the named loop
exit returns to operating system
exp exponentiation
field gets fixed fields
getarray get value array
getlib create library group
include bring in library group
isfalse checks for false condition
keep stores variable in a list for later processing
library rings in library group
logn logn
looping increment starting value until it reaches end value
makefile creates a file structure
movetofixed moves field to fixed area
openfile opens existing file
prntscreen transfers text to the screen at designated location
putarray insert value in array
readfile brings in record
readnumber reads a number
readscreen accepts data at designated place on screen
readtxt reads text
readunit accepts a digit
record moves fields to variable locations
rectangle drawing of rectangle
reset back to text mode
screen places data on screen
setgraph sets graphics
sine sine calculation
sinewave temporary sinewave generation
skips transfer control
sqroot square root calculation
stopclear halts processing and clears the screen
storearray store value in array
storeit files current record
tangent calculates tangent
testeq test for equality
testge test for greater or equal
testgt test for greater than
testle test for less than or equal
testlt test for less than
testne test for inequality
testneg test for negative
testzero test for zero
textedit edit a text
textin bring in a text
textout transfer a text to file
transf transfers data to work area

Note that not all these language elements are included in the translator demonstration to be made available in May, just the ones shown in the table previously presented. Many additional language elements are also being developed and this external language will be considerably expanded as the needs of potential users are explored. In particular it is expected that specific vocabularies for specific industries will be established so that workers in those industries can understand what their application does without reference to programmers (see the work of the University of Waterloo Risk Research Institute, including the work of Dr. Siddall on the EM language).

Application statement line

The other function of the translator is to compress the statements to (wherever possible) single byte strings. Again this is accomplished by a relative reference number. One such statement might be as follows:
Screen ^d, h and sum is^ d h sum
Which places on the screen the edited values of variables d, h and their sum. The compression might be !3482. In this case ! has been used instead of the up and down arrow for 18, the relative position of language element screen, 3 would indicate the third literal, 4,8,2 the fourth, eighth and second variable it had found in translating the application. The literals are placed at the end of the compressed string. This would apparently limit the system to 256 variables but such is not the case, although a study has shown few applications have more than 256 unique variables.

A statement involving transfer of control might be:
Testzero Toyota #a #8
Which might compress as %429, where % has been used for the sun shaped 15 representing testzero, 4 indicates the fourth variable found in the translator, and 2 and 9 are the second and ninth transfer points found.

The translator indicates any errors in the statements of an application and only generates a compressed string that conforms to all rules.

This essentially completes the activity of the translator so it is now useful to examine a trivial item plus a couple of simple applications.

Each language element is associated in the run system with a small string of numeric codes which relate the internal functions that need to be called to carry out the function. These internal elements are themselves numeric codes which either call other internal elements or the virtual processor segments. The hierarchical structure of the internal elements leads to a very compact overall system.

Some of the current internal elements are:
apprun starts the application run
branch finds where to go next
clear clears the screen
cleara sets a to zero
clearb sets b arithmetic location to zero
clearr sets result area to zero
close closes the current file
convert converts decimal number to internal format
create used to create file
cursorx manipulates cursor on screen
def1 auxiliary function
def1a auxiliary function
def2 auxiliary used in define
definet used in defining loop
exits returns control to operating system
edit edits numeric data
getar gets arithmetic variable
getbinarr used for initialising binary array
getbinary gets the binary values for loop control
getconst finds required constant
getdigit single digit to binary
getloops arranges for the loop branches for a define loop
getnumber converts digits to internal representation
getputarray used in array operations
gettext finds requested text record
offsett gets variable offset
opens opens a record
varfind finds location of variable name
variable gets variable
varput stores variable
varputa stores arithmetic values


\this application places a simple message on the screen\
screen ^hello world out there^ ^are you happy?^

While the 'Hello World' application is trivial, ubiquitous and stupid it seems to be the Holy Grail for new systems, so is included.

Note that we have a 'magic' string as does Java, all applications being started with batip01. The 01 represents the version number.

All applications have as their last line the statement zend.

The statement exit may appear anywhere in the application.

Comments are begun and ended with \.

Apart from the two literals the compressed version would be !01”@ where ! is used for the language element screen, “ is used as a statement terminator and @ is used for the statement exit. The 0 and 1 would be in their binary bit form.

CELC temperature conversion

arith fahr = 68
screen ^Fahrenheit Celcius^
#2 arith celcius = fahr - 32
arith celcius = celcius / 9 * 5
screen fahr ^ ^ celcius
arith fahr = fahr + 18
looping 68 18 248 #1 #2
#1 exit

In this case fahr would be variable 0, celcius variable 1, #2 would be transfer point 0 and #1 transfer point 1. Constants 32,9,5,18,68,248 are converted to their binary or floating point format as appropriate, preceded by a symbol indicating which type is being used.

The above example would compress to about 32 bytes plus the literals and constants, for presentation to the run system.

Binary constants use whatever bits are necessary, floating point constants require a minimum of 4 bytes, three of which are for the length, sign and exponent. This length is extended to 32 bytes for the single length format, allowing for a number 10 to +/- 128.

The actual compressed byte code cannot be printed on my printer or on my screen, To give a verbal definition of the byte stream would only be confusing.

FACT calculation of factorials

#5 arith up = 1
arith start = 1
screen ^enter number less than 30^
readnumber number
arith number1 = number
testneg number #1 #a
#a testzero number #1 #2
#1 exit
#2 arith number = number + 1
screen ^entered factorial for ^ number1
#4 arith start = start * up
arith up = up + 1
arith number1 = number1 - 1
testzero number1 #3 #4
#3 screen start
skips #5

This application asks the user to enter a number n and then gives as a result factorial n n! It illustrates, in particular, the accuracy of arithmetic multiplications.

Variables 0,1,2,3 are up, start, number, number1
Transfer points 0,1,2,3,4,5 are #5,#1,#a,#2,#4,#3

This application would generate 65 bytes plus literals and constants.


This experimental application will not be reviewed at this time. It generates a JPEG image.

An example of a language element is zcalc which is associated with the arith statement. Edited to remove superfluous items it would be:
zcalc: zichvind,0,128,addcode1,1,zddcode1,c7,2,addcode1,1,zgetar

zcalc is one of the longer language elements and each of the addcode1, zddcode1, etc. is in fact a number. This number gives exact information to the run system as to what is required to perform an arithmetic operation. Most of the activity refers directly to run system modules but zgetar, zstoreno, zactcalc refer to other internal elements in the hierarchical linkage, while endline is a control word.

The number of modules in the run system is quite small and can be defined for use, thus far, with a number from 0-65535. The basic categories for the number system are:

;33280 msgs
;33792 keys
;34304 functions
;34816 adding
;35328 subing
;35840 multing
;36352 diving
;36864 addctl
;37376 subctl
;38400 zdd ops
;38912 zero2
;39424 zdi ops
;39936 zid ops
;40448 zii ops
;40960 zichmove
;41472 offquery
;41984 matchis
;42496 matching

Within the message module 5 items as used at present are:
;msgs 33280
appnmsg = 33280
invalidmsg = 33281
msglinemsg = 33282
codesmsg = 33283
while one of the movement modules has 12 items, the first 5 being:
;39936 ; zid in run system
zidtestno = 39941
zidst1 = 39968
zidst2 = 39969
zidst3 = 39970
zidst4 = 39971

Another module has as its first seven:
;40448 zii in run system
ziist1 = 40480
ziist2 = 40481
ziist4 = 40483
ziist5 = 40484
ziist12 = 40491
ziicode1 = 40501
ziic6ind = 40523

In this example the zii base of 40448 takes the run system to the module that moves data from one location defined indirectly to another indirectly defined location. The difference between the base and the element code used indicates the variable to be used in this operation. For instance 40481 refers to the 33rd variable in a variable name table (st2) while 40501 refers to the 53rd variable name (code1).

Benefits and use of the revised system

The obvious question to ask is ‘why is this revision to the usual architectural concept of value’. There are many advantages which will now be illustrated.

The "vision" is that a single program will be used for all application activity. This does not imply that the maximum code will be used in every case (e.g. it would be useless to have graphics on a smart card) but that module patterns are available for platforms of interest (which have already been debugged for other platforms), and which in any case are so small that debugging is a trivial affair.

Functionality can be added or removed as necessary, enabling a much greater opportunity for customisation. This is particularly important when the same software is used on many platforms as, for instance, software to transfer from a host system to a smart card, where only a few of the available modules are needed on the smart card.

It was proven in an earlier version, that GENETIX could do anything that Java could do, in a much more compact form, without the complex baggage associated with all Java run systems. This is now even more so with the numeric system.

The situation for Java is actually a lot worse than indicated because the run system based on the numeric technology does not have to cater to such things as Exceptions, various methods ancillary to those of the application, and multi threading, which tend to bloat Java applications.

By having the same software on all platforms it means that any platform can be a host or receptor. This is important, particularly in the area of telecommunications, where an alternate system can take over in the event of failure of another system, in some ways reflects the situation that exists with Internet.