[Simh] Questions regarding future simulator development

Thu Apr 11 18:35:10 EDT 2013

On Thursday, April 11, 2013 at 2:13 PM, Michael Mondy wrote:
> On Thu, Apr 11, 2013 at 01:07:10PM -0700, Mark Pizzolato - Info Comm wrote:
> > Hi Michael,
> >
> > On Thursday, April 11, 2013 at 10:37 AM, Michael Mondy wrote:
> > >
> > > Here's a bunch of ideas...
> > >
> > > Long options for commands.  I'd like to be able to say "ex --lpw", "ex --
> ptw", and "ex --ptr" instead of using single letter characters.  The
> architecture sends a 32bit mask of which options are used to simulator
> provided routines.  I have some code to provide "aliases" to translate long
> options into single char codes.
> >
> > The current codebase has support for command aliases.  This is achieved
> using environment variables with the:
> >
> >   sim> SET ENVIRONMENT aliasname=some sort of string
> >
> > quotes are not necessary and blanks come along with everything after the
> first non-whitespace character after the =.  The command could be
> shortened to SET ENV.
> >
> > During command processing, the first token of an input command is looked
> up to see if it is an environment variable and the expanded value replaces
> that token.
> >
> > Please describe the long option details more completely and/or send along
> code which does this...
> 
> 
> I'm talking about options not commands.  The ability to say "examine --lpw
> ..." instead of "examine -l ...".  I added a DEBTAB sim_long_opts[] and had
> get_switches() check it when a '-' was seen.  I only have the code in an
> obsolete version, I'll put together a patch.

I look forward to it.

> > > Extend the "set <var> = <value>" command to allow <value> to be a
> quoted string with whitespace.  I have code for this.  I use it to allow an ini file
> to provide initial input for my console routines so that the boot process can
> be partially automated.  There are other approaches to
> automated/interactive interaction, but this was simple.
> >
> > I'm not familiar with any syntax like this.  The above SET ENVIRONMENT
> > command is new since v3.9
> 
> For example, I have a DEVICE named "OPCON" with an MTAB entry named
> "autoinput".  I use the following setting in my ini files:
>    sim> set OPCON autoinput="cold a20 ipc 3381 0a"
> 
> Please see the patch at end of this message for specifics.

OK, so you're parsing (or capturing) arguments in a SET modifier.  You could have chosen a different delimiter (a comma perhaps), and gathered them in the modifier validation routine.  We have other cases which do this.  Once gathered, you can store that information internally however you want.

I'll look to see what else might be affected by this.  This one is a maybe.

> > > Allow the simulator to know what register is being displayed. That is, pass
> the SIMH register pointer to simulator-provided display routines so that per-
> register formats may be displayed.  For example, we can't display the
> condition register as a set of flags if all we have is the value and don't know
> which register we're displaying.  I have code for this.
> >
> > The current codebase has support for registers which can optionally have
> 'descriptor' structures attached to the register declaration.  This descriptor
> defines named bit fields which are displayed by EXAMINE as well as debug
> output of register and their changes.
> 
> Good to know.  I'll have to look into that.  As far as I can see, fprint_sym() is
> called with no clues as to the source of the value for registers.   Perhaps I'm
> missing something.   My code for this is included in the scp patch below.
> 
> Perhaps my fprint_sym() should return failure when the switches include
> SIM_SW_REG and that would cause print_val() to be called?  That way, I
> could key off of rptr->flags?  Or did you mean something else by descriptor
> structures?

Notice the fprint_fields just below the fprint_val.

Your patch will definitely break other simulators.  The NULL argument is a UNIT * and the code in many simulators'  fprintf_sym depend on the value being a unit or apply an internal default when it is NULL.

This patch is a no.

> > > Open sockets with the SO_REUSEADDR or "no wait" option. I have code
> > > for this minor change.
> >
> > When would this be valuable and to whom (of the 4 classes of users you
> define below)?
> 
> This is useful when you re-launch a simulator only a few seconds after the
> prior run.  As you probably know, the TCP specs require that an OS list a
> socket in a TIME_WAIT state for a while after a listening socket is closed.  This
> is to allow the OS to more easily reject any packets that were part of a prior
> session but that did not arrive until after the socket was closed.  Especially
> not of interest on localhost connections.  Many network based apps have an
> option for whether or not to set this flag. See:
> http://www.unixguide.net/network/socketfaq/4.5.shtml

Well, I can see your desire to get back to working your test environment quickly.  

The default behavior is there to hopefully prevent someone from accidentally running multiple instances of the same application.  On at least some platforms, if you set SO_REUSEADDR multiple instances of an application can be started each listening on the same socket.  Each one gets 'some' of the connections which arrive.  

We can add a switch which will add the SO_REUSEADDR socket option if someone explicitly wants that behavior.  The -R switch already has meaning for many attach commands, so maybe -A, -S or -U....

Thanks for your feedback.

- Mark