[Simh] Command processing -- abbreviations and VM-supplied commands

[Paul Koning]

> On Sep 25, 2015, at 2:24 PM, Mark Pizzolato - Info Comm <Mark at infocomm.com> wrote:
> 
> On Friday, September 25, 2015 at 10:59 AM, Paul Koning wrote:
>> 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".
> 
> 
> The most common use of a VM specific command table is to replace some standard/general purpose SCP command.  This is done by each the VAX simulators to replace the BOOT command.

Ok, that makes sense (and in fact I need that elsewhere). 

> 
> Three other simulators in the github repo provide a VM specific command table:
> IBM1130, PDQ-3 and SAGE.
> 
> The extended commands in the SAGE simulator ran into the exact same problem you did since this system also wanted to add a command which started with S.  His ingenious solution to the problem was to redefine the STEP command in the VM specific table dispatching to the standard STEP command handler (copying the entry from the SCP defined command table). 
> 
>> 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).
> 
> This would get very messy since, for example, it would break the very common usage of "S" to invoke the STEP command.  STEP is merely one of many existing commands which start with S (SET, SHOW, SAVE, SHIFT, SEND, SCREENSHOT).  Messy since we'd have to allow the normal command parsing to provide the original abbreviation paradigm and then complain about the conflicts with the VM supplied cases AND also provide logic to explicitly allow replacement of SCP provided commands which a VM really intends to replace.

My suggestion would preserve "S" and other single character abbreviations by adding an explicit "S" command (as an alias for "STEP").

> 
> I suggest you follow the example provided by the SAGE simulator.

Ok, yes, that sounds like a simpler solution.  Thanks.

	paul