2024-04-07

Only listing the most important changesets:

• List INSTALL TOGGLE
• List more INSTALL nouns (1, 2, 3)
• Document L and W commands for sectors
• Update vardco with 7th variables

• init and qq will disable interrupts while relocating EBDA
• bb: Many comments added and updated
• bb: Various optimisations
• bb: Share the skipcomma call done by almost every dispatch destination
• bb: Put some variables into DATASTACK section
• bb: Share setting di for common handler using another dispatch table
• bb: Fix, BL command segment display works in PM
• isstring: Return CF status for match or mismatch
• expr: Use isstring? CF return for getrange_length
• expr: Fix, allow comma after length number
• expr: Optimise operator_default_strings table to drop unused entries (re-ordered first to make this optimisation easier)
• expr: Several optimisations to operator dispatchers, using common code paths and nearby operator indexes
• Move inclusion of rr.asm to behind expr.asm to prepare for next change
• In rr.asm rr4 add build checks that the boolean and bitwise operators are in the expected order

The new bb dispatch table for the DI value as well as the optimised operator default index table for the DX value share one thing: These tables are truncated. That means when the dispatch occurs to a handler without a corresponding entry in the truncated table, the respective register is initialised to a randomly read value within the data/entry section. The table read thus can overflow the table.

This is not a problem for these handlers because they do not depend on any particular value in the register, and are themselves allowed to change it. (Eg the operator dispatchers have "CHG: dx".)

It does pose a small problem when debugging the debugger: If access variables are used to detect a read or access to a variable, the table overflow could register as an access to the variable despite actually accessing the truncated table. This is considered acceptable.

The truncation of the tables in both cases involved re-ordering the tables so that all the in-use entries are first. Previously, unused entries were filled with zeroes to pad out the tables up to the first in-use entry.

There is an alternative: The base of the table could be an equate that displaces the table so that only the in-use entries are actually present, without re-ordering the existing tables. However, the re-ordering I considered to be simpler than that. (I have seen a table with such a displacement in the Enhanced DR-DOS kernel sources for redirector functions.)

The optimisations to the operator dispatchers used several facts. First, some of the used operator index values were right next to each other, allowing an inc bx or dec bx instruction to adjust from one to the other. (These are single-byte instructions.)

Second, some code pathes turned out to be duplicated for different operators. These were merged.

Third, the boolean and bitwise OR/AND/XOR operators using the non-keyword symbols all compared the next text byte with the matched symbol (conveniently passed in AL) and did a certain adjustment to the default operator index in case a match is found. The adjustment happens to match the same simple addition for every one of these operators. So the entire code for these three operator dispatchers is now shared.

(By re-ordering the bitwise and boolean operators the latter adjustment could be done using just an inc or dec but it would be more difficult to insure that all uses of the operators are updated for this. One such use is in rr4.)

I idly wondered whether an Extension for lDebug being loaded into the debugger could extend the GNU GPL copyleft to the debugger. In practice this doesn't matter because the debugger is freer than copyleft, as it follows a "copycentre" approach. (Go down to the copycentre and make as many copies as you like!)

I believe that the code links and data links that the ELD linker gets from the debugger constitute dynamic linking of the ELD to the debugger. Therefore if the ELD is under the GNU GPL, the debugger and likely all other ELDs used at the same time also need to be GPL-compatible. (As to the exact timing there was a recent stackexchange question about this. No answers yet. (Update: There is an answer now, focusing on distribution being allowed or not.))

Moreover, if an ELD is under the GNU LGPL, then it (and/or the debugger) must follow a certain specification of the links and interfaces in order to enable swapping the LGPLed module by an independent implementation at link time (that is, run time of the ELD being loaded).

In addition to the earlier considerations, there is yet to be even a single ELD not written by me. The only case in which an ELD I wrote is not under the lDebug licenses or in the Public Domain is in the dbitmap.eld use of a font that is under CC-BY-SA 4.0 International.