> On Sep 25, 2015, at 2:24 PM, Mark Pizzolato - Info Comm <[email protected]>
> 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
_______________________________________________
Simh mailing list
[email protected]
http://mailman.trailing-edge.com/mailman/listinfo/simh
