In doing a new simulator, I ran into an unexpected quirk of command parsing, in
particular handling of VM-specific commands.
The way it works is that a user command matches a command table entry if the
user string is a prefix of the command in the table. And as soon as a match is
found, the search stops and that entry is used.
In addition, if a VM command table is supplied, that table is searched first,
and only if no match is found will the standard command table be searched.
These rules can produce some annoying surprises. For example, suppose I have a
VM specific command table that contains just one entry, for the command
"SUFFIX". The result is that the user command "S" now executes "SUFFIX" rather
than the expected "STEP".
A lot of programs that supply this sort of user interface use an "unambiguous
match" rule: a command is accepted if the supplied string is a prefix of
exactly one command table entry. Then to allow specific shorthands like "s"
there is an additional rule that an exact match is accepted even if it is a
prefix of some other command. And in such systems, you'd find an explicit
table entry for "s" as an alias of "step".
I'm wondering if a similar change for SIMH could be considered. As it stands,
when I wanted to add a VM-specific command, the first choice for the command
name (START) and the second (NORMAL_START) conflict with popular
single-character command names. I ended up with a command name RESTART, which
is reasonably obvious but doesn't match what the corresponding operation is
called in the real hardware. The change I would suggest is that a command
lookup would scan both tables, and accept the user entry if it is either an
exact match, or a prefix match of exactly one entry (across both tables).
paul
_______________________________________________
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh
