Software modifying instructions in 1456 object code.

William Overington

In developing a new 1456 applet landscape a situation arose that, although a solution was produced that worked, it was a solution that I considered inelegant. I began to think as to how an elegant solution could be produced. The result is that I am adding six new instructions to the 1456 object code specification each of which is a two character instruction that starts with a U character. I am also adding an additional instruction, %c, that places a one character string formed from the contents of ac1456 into bs1456 and adding two new action codes to the eutodraw system to enable more compact programming in certain situations. In addition I am adding three new & commands to the system. These are concerned with the topic of software modification.

Following the success of the Print1456 1456 applet landscape I decided to produce a 1456 applet landscape where 13? and 23? are used to produce a toolbar along the lower edge of the screen that consists of a lot of squares, each fairly small yet of reasonable size, so that a simulation of a keyboard could be produced. The 13? and 23? are used much as 11? and 21? respectively are used in the Print1456 1456 applet landscape. As the applet is 700 pixels wide I decided to make the toolbar as being 700 pixels wide consisting of 4 rows each of 28 squares, each 25 pixels by 25 pixels. I thought in terms of a checkerboard effect and, after experimenting with cyan and yellow alternating squares, I settled on light grey and yellow alternating squares, with the intention that these would have red lettering on them. I called this structure a softboard toolbar.

In view of the fact that these square keys would need to carry lettering for normally wide characters like M and W and also for normally narrow characters such as i and l, I decided to make available to users of this particular 1456 applet landscape the monospaced font in 12 and 18 point as well as those sans serif fonts made available to users of the Print1456 1456 applet landscape. These are made available using 3120? and 3180? software interrupts.

The 1456 applet landscape was programmed such that, when the softboard toolbar were active, a mouse click on the screen would produce one of 113 different entry points to the 1456 object code, namely 70: for a click on the white background, and 100: for the top left key on the softboard toolbar, 101: for the key to its right and so on, 127: being for the top key at the right hand side of the softboard toolbar, 128: being the entry point for the key second down at the left hand side of the softboard toolbar, and so on. Clicking the key at the bottom of the right hand side of the softboard toolbar would produce 211: as the entry point.

The matter then arose of drawing the keys on the keyboard and making the keys carry out the desired function. A scenario of a text displaying program is introduced. A user can click on the keys of the softboard toolbar, choosing which key upon which to click by looking at the red monospaced lettering on the key, and then that letter will appear on the screen in a large, variable spaced sans serif font in blue. For key 102 this software could be as follows, supposing that, say, key 102 is used for the e acute character. The hexadecimal code for an e acute character is 00e9.

102:'u00e9'w250CH

For key 104 this software could be as follows, supposing that, say, key 104 is used for the h character.

104:^h'w250CH

Thus, for each key required to be active, the key could be programmed to load the desired character into the ac1456 register and to call a subroutine to process the character.

The prospect existed of adding 112 such entry point routines manually, most of either of these two forms, with a few to act as a newline character and so on.

The subroutine at 250: would then add the character onto the end of a string and draw the string on the screen. Redrawing the whole string each time would avoid any problems of the variable width of characters in the sans serif font.

The initial labelling of the keys would be carried out by the HTML file containing STRING01 through to STRING04 each having 28 characters in them and having the start up routine draw the characters on the keys of the softboard toolbar.

Indeed, perhaps an interrupt service routine would be provided so that the 1456 programmer could label the keys easily, though provided as a separate interrupt service routine so that the softboard toolbar could be added without any lettering if that were the result that were desired.

These 28 characters in STRING01 through to STRING04 could be either ordinary keyboard characters or unicode characters entered using a 'u sequence or any permutation of them whatsoever.

However, after experimenting with the system I realized that each character desired would need to be added twice, once in one of the STRING01 to STRING04 strings and once in a corresponding subroutine. It would become tedious to add all of the subroutines and the opportunities for error would be great.

I began to think as to what would be necessary for the 1456 software to be able to look at each of the characters in the STRING01 through to STRING04 strings in turn and to produce the routines automatically.

I sought a general solution that could be applied both to this scenario and to other scenarios in the future.

The internal workings of the 1456 engine, which is written in Java, need not concern the 1456 programmer. Certainly, people who are programmers in 1456 object code may choose to become interested in such matters and acquire knowledge in them, but such knowledge is not necessary in order to program in 1456 object code. However, a look at some points relevant to the history of how the software modifying instructions in 1456 object code are designed may hopefully be of interest.

In my own implementation of the 1456 engine, which has been produced during development of the 1456 object code system, all of the 1456 software is stored in the 1456 engine, including the label numbers and the : characters. The software is stored in an array of characters that is defined as follows.

    int totalcharavailablefor1456software = 10001;
    char[] software1456char = 
             new char[totalcharavailablefor1456software];

Labels are then compiled so that the index number of the cell in the software1456char array immediately after the : character is stored in the array named label defined as follows.

    int[] label = new int[300];

Loading of software also uses two integers, which both start out with values of 0.

    int nextcodeloadplace=0;
    int nextcodeassembleplace=0;

Adding a first piece of 1456 software, say, 23 characters of 1456 software, means that they are stored in software1456char[0] through to software1456char[22]. The value of nextcodeloadplace is increased to become 23. The code is then scanned for labels starting from software1456char[nextcodeassembleplace] and proceeding to software1456char[nextcodeloadplace - 1]. Any labels found are compiled into the label array. The value of nextcodeassembleplace is increased to become 23.

Adding a second piece of software repeats the above process except that the software is stored in software1456char[23] and subsequent locations in the software1456char array. Compilation of label addresses is carried out on just the newly added software.

Software is loaded into the 1456 engine from the 1456 applet landscape using the methods loadSoftwareFromAppletParameters and loadSoftwareFromString which are encoded as follows.

    public void loadSoftwareFromAppletParameters
                 (String stringofsoftwarefromparameters)
      {
        software1456=stringofsoftwarefromparameters;
        loadSoftware();
      }

    public void loadSoftwareFromString(String stringofsoftware)
      {
        software1456=stringofsoftware;
        loadSoftware();
      }

The method loadSoftware has the format as follows.

    private void loadSoftware()

Many 1456 programs begin at label 1. For such a program, in my implementation of the 1456 engine the character 1 would be stored in software1456char[0], the character : would be stored in software1456char[1]. The number 2 would be stored in label[1] so that in the event of the system attempting to run 1456 software starting at label 1, the 1456 engine will look in label[1], find the value 2 and start processing 1456 object code from the character stored in software1456char[2].

A person producing a 1456 engine from this specification may perhaps choose not to store label numbers and : characters in order to save storage space. However, it needs to be remembered that the 1456 object code system needs to be able to test whether a routine exists for each particular label. If the 1456 software is being stored in an array of characters one way that this requirement could be satisfied would be by starting storage of the 1456 software at location 1 of the array rather than at location 0 of the array, so that no entry in a list of labels would then have the value 0.

My thinking was that the storing of the label numbers feature could be useful if a listing were produced, but the system has not, in fact, been developed along those lines.

Returning to the matter of what would be necessary for the 1456 software to be able to look at each of the characters in the STRING01 through to STRING04 strings in turn and to produce the routines automatically.

My first thoughts were towards the possibility that a command would access the label array and return the value of the index number of the place in the software1456char array where the software starting with the label number present in the ai1456 register were located. I decided against this approach as it would involve the 1456 programmer in involvement with the inner workings of the 1456 engine software and would thus impose upon the writer of a 1456 engine restrictions as to how he or she chose to implement the 1456 object code specification.

I gradually refined this approach ending up so as to add ten commands to the 1456 object code specification, together with two extensions to the eutodraw system, such that action code 33 will draw the contents of the ac1456 register on the screen and action code 34 will draw the contents of the as1456 register on the screen. Six of the commands are directly dealing with software modifying and start with a letter U and are followed by a second character. The seventh command is something that I felt was needed when doing some experimental work with the softboard toolbar, namely a command to place a copy of the character that is in the ac1456 register as a string into the bs1456 register as a one character string. The command %c is used for this purpose. The one character string could then be loaded into as1456 or concatenated onto as1456 as desired. Please compare and contrast %c which is used for one character converted to a string and placed into bs1456 register and %C which is used for a string of zero to many characters which is placed into the as1456 register.

The three remaining new commands each begin with an & character and each loads an integer into the ai1456 register.

The U( command adds a label into the system. The number of the label to be added must be contained in the ai1456 register before the command is obeyed. Only labels in the range 1 to 299 may be added. Adding a label that already exists replaces the previous information in the label table. It is entirely up to the designer of the 1456 engine as to whether the label number digit character or characters and the : character are stored in the 1456 engine. Indeed, in my own implementation of the 1456 engine, which has been gradually developed as design of the 1456 object code proceeds, label number digit characters and : characters are included when the software has arrived in a string from the 1456 applet landscape or from the use of the U% command introduced later in this section, but they are not included when the label has been added using a U( command.

The U= command may be used to check whether a label exists. The number of the label to be checked must be contained in the ai1456 register before the U= command is obeyed. If the label number given is within the range 1 to 299 and the label exists then linkflag1456 is set to true, otherwise linkflag1456 is set to false. For completeness the U) command is provided to delete a label. A use for the U) command is not immediately apparent to me but I have added it for completeness. The number of the label to be deleted must be contained in the ai1456 register before the U) command is obeyed. Only labels in the range 1 to 299 may be deleted. Deletion of a nonexistent label is harmless.

A U> command stores in the bi1456 th character after the ai1456 label of the 1456 software a copy of the character in ac1456. The label used should be the label immediately before the place in the software that it is intended to modify, as some implementations of a 1456 engine may store the characters of the label definition in the software and some may not. Here mention is made of a matter that a 1456 programmer and a 1456 applet landscape designer who use a 1456 engine prepared by someone else need not concern themselves about, but is included for writers of 1456 engines. When a character is added into a place not already being used for software, then the fact of the software being present should update such internal data of the 1456 engine as is necessary to regard that place as being occupied by software so that, for example, a later added label does not get added in a place that could cause a clash of interests to occur. This may mean that several character positions in an array of characters meant to contain software are left empty. Care might be needed to set them as space characters if they were not initialized when the 1456 engine was instantiated.

Returning to matters for 1456 programmers. A U< command places in the bc1456 register a copy of the character that is in the bi1456 th character after the ai1456 label of the 1456 software. The label used should be the label immediately before the place in the software that it is intended to modify, as some implementations of a 1456 engine may store the characters of the label definition in the software and some may not.

A U% character loads the string that is in as1456 just as if it were at the end of the input stream from the HTML file. This can be useful. Consider please that, for example, one is adding routines for most keys on a softboard toolbar automatically at the start up of a 1456 program using a looping routine that generates routines from the character codes of the keys that are to be displayed on the softboard toolbar. These character codes being obtained from STRING01 through to STRING04. One may then use a [ defined string, a %w command and a U% command to add a software routine to make one softboard toolbar key, such as the one in the bottom right hand corner, act as a newline key. This facility also allows for the possibility that the designer of a 1456 applet landscape might like to include a text box that allows a user to enter some 1456 software in a text box while the applet is running and then have that software be obeyed.

Please note that at no time does the 1456 programmer become involved with the actual locations of software in the software1456char array of my implementation of the 1456 engine, nor in the actual locations of software in any implementation of the 1456 engine that some other person may make. Please note in particular that the character stored into the software may be any 16 bit unicode character. This is somewhat different to the entry of software from the HTML page. Software being loaded into the 1456 engine is not preprocessed by the 1456 engine to resolve any 'u sequences in the software. Although such preprocessing might at first glance appear to have benefits, the specification is that 'u sequences in software from the HTML page are not preprocessed out but are obeyed character by character in the 1456 engine. I specify that such preprocessing should not be done so that a user of a 1456 engine that complies with this specification knows with certainty that such preprocessing has not taken place. Anyone wishing to investigate such a conversion possibility would need to bear in mind that a 'u sequence in software might need to be replaced with one character if it were in a [ string, and by two characters, the first a ^ character, if it were not in a string and that it would need to be remembered from one STRINGnn item to the next as to whether a [ string was being carried over from the one STRINGnn item to the next. However, software originated within a 1456 applet landscape could contain strings of characters expressed in the Java software of the 1456 applet landscape by a \uhhhh sequence if the designer of the 1456 applet landscape so chooses. The restriction is to allow the 1456 programmer to be able to use the software modifying instructions of the 1456 specification with certainty.

So how could the softboard toolbar be programmed? The characters in STRING01 to STRING04 are dealt with sequentially. Each is a 16 bit unicode character. These characters are each associated with a key routine number and thus a key square on the softboard toolbar. The character is drawn in red on the key on the softboard toolbar. The routine could be constructed by using the following software, where the key number is in the ai1456 register to start and the character just obtained from the STRINGnn is in character location 99.

U(^^'w0U>99'<'w1U>^''w2U>^w'w3U>^2'w4U>
^5'w5U>^0'w6U>^C'w7U>^H'w8U>

This code has the effect off adding a software routine into the 1456 engine, a software routine that can then be obeyed when desired. Suppose for example that mc1456[99] contains the character e and that the ai1456 register contains the number 103. The software above would produce routine 103 to be as follows.

^e'w250CH

I have chosen a letter e as the example here so that it, being a 7 bit ascii printing character, will show properly on a web page with a minimum font supporting the browser. However, any 16 bit unicode character could have been used.

An alternative method to produce the same effect would be as follows as the label is added just before the rest of the software is added.

U(^^'w0U>99'<'w1U>['w250CH]%wU%

The three new & commands are as follows. The &U command loads into ai1456 the label number of the last label that was the target of a call or jump command that actually took place. Any C or J command will alter the value that &U would provide. Only those !C and !J commands that actually produce a call or a jump will alter the value that &U would provide. For the avoidance of doubt the R and !R commands do not affect the value provided by this function. The &V command loads into ai1456 the previous label number that would have been provided by the &U command before the last call or jump took place. If the last jump was in a loop in the software, it is possible that &U and &V will return the same value. The purpose of &U is to ease programming of question and answer programs and the like so that an additional question may be easily added at a new label in the software. For example, questions might be at labels 221, 222, 223 and so on with the final message that the test is over at label 224. A question could involve displaying one string that asks a question and displaying five possible answers, only one of which is correct. The software being designed to move to the next question once the correct answer is selected and inviting the student to please try again if an incorrect answer is selected. Suppose that one wishes to add an extra question. A good start can be made by copying the question and answer choice strings that start at label 223, renumbering the copy as starting at label 224 and changing the original label 224 to become label 225. After that the text strings can be changed to produce the new question. However, suppose that the software needs the label number of that question to be stored somewhere. The label number would need to be found and edited if it is included as a number. Yet if &U is used to obtain it, then the &U in this new question will produce the correct value without any editing needing to have been done. If a subroutine is called by the software to handle such housekeeping activity, then &V can be used.

A very useful application of &V is where a number of routines have been added by software modification using U( and related instructions. Suppose, for example, that a softboard toolbar is being used and 112 routines have been generated automatically and each calls a routine at label 250. The routine at label 250 may use &V to find out which routine called it.

The general policy of 1456 object code is that the 1456 programmer is kept away from the internal workings of the 1456 engine. However, a partial exception has been made to this in regard to the 1456 programmer being able to find out how much software storage space is left unused at the present time. The &Q command places into the ai1456 register the number of 16 bit characters available and as yet unused for 1456 software in the present program. This is particularly useful as a test facility where someone is devising a question and answer program with many questions in it and it is desired to know with certainty whether the 1456 engine being used has sufficient space available for additional questions to be added.

In such a case the &Q command would be used when running a 1456 program during development, perhaps drawing the value obtained at some place on the screen. Once the 1456 program had been finalized in its content the section of the software that uses &Q and draws the value obtained on the screen could be commented out using { and } just before final testing of the 1456 program takes place.

1456 object code

Copyright 2000 William Overington