An assortment of 71B questions

[rprosperi]

Further comments on multiple LEX files/keywords...

1. The JPC is a special case (in many ways) in that it actually integrates some of it's messages (and maybe keywords?) with those in the HP-IL ROM, which is why when JPC is installed you will notice that the HP-IL ROM VER$ appears later in sequence than JPC, and possibly other LEX files.

2. LEX keywords are found (to run or to be added into a program when typing that in) in a port-scan, in the normal port number increasing order, so 0.00, then 0.01, then 0.02... then 1.00, then 1.01... then 4.00, then 4.01, etc. Of course this only applies to IRAM or ROM ports.

So a keyword in a LEX file in Port-1 could be considered 'higher priority' than the same keyword in another LEX file in Port-2, that is until you swapped which ports these modules are in, then the 'priority' would change. (Note: So plan well when considering which modules go into which port).

3. Programs don't store the alpha keyword names for commands, they store the XROM ID, almost exactly like the 41 does, which is why when you list a program with an external (LEX file based) keyword when that LEX file is not installed, you will see "XROM mm,nn"" instructions; the LEX file is not available to provide the string for the editor to display the command. The "mm" is the LEX ID, and the "nn" is the token. These are explained in gory detail in the IDS, but a dead simple example can be seen on p.54 of the Forth/Assembler manual.

This can lead to some initially confusing situations, such as:

a. If a LEX is installed with the keyword FUNC1, whose underlying ID is XROM 52,55, and then at some later time there is a different LEX file also using the same LEX ID/Token (52,55) for another command FUNC2, and is installed in a lower port (aka, a 'higher priority' port) when you list (and run!) this program, the command in the newer module would be shown and executed, appearing as if your program code had changed.

b. Similar to the above, if that newer LEX file (or even another) also has a FUNC1, but with a different LEX ID/Token pair, it's hard to find the problem as you can type a=FUNC1(x) at the command line to see that it is indeed there, while your program may be returning a different value for it's (now with a different name) FUNC1.

Note that this is also how mainframe commands are 'replaced' with modified versions in a LEX file; the ports are scanned for LEX ID matches before the OS. This is how the native PEEK and POKE were replaced with versions that could read/write anywhere (e.g. in protected file's address space) thus quickly rendering the OS 'security' measures useless (and it was even easier in Forth! ).

All this is why HP managed the allocation of LEX ID and Token resources, to prevent LEX command name collisions. Developers were asked to submit requests to HP, describing the class of application, types of functions, etc. and HP would act as a clearing-house and master keeper of the records to attempt to ensure such conflicts did not occur, but of course they did.