[Simh] Questions regarding future simulator development

Thu Apr 11 16:07:10 EDT 2013

Hi Michael,

On Thursday, April 11, 2013 at 10:37 AM, Michael Mondy wrote:
> On Wed, Apr 10, 2013 at 12:27:47PM -0400, Christian Gauger-Cosgrove wrote:
> > Hello,
> >
> > I have a few quick questions about what could be added to SIMH.
> > [ ... ]
> 
> 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...

> 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

> 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.

> 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)?

> I suppose it might be interesting if the control console supported a well
> known scripting language such as tcl, python, or lua.

The control console language has been extended considerably in the current codebase.  It is not using any of your suggested languages, but it is much more flexible.

Given simh's already long life and the many configuration scripts which exist in the wild, extending the existing syntax is deemed more useful than starting fresh.  This allows users to leverage all of the many examples without breaking them.  Most users really don't want to deal with the simh interface, but want to get on with running the legacy system which the system simulates and dealing with that.

> A libvirt interface would be interesting. Some, perhaps significant, re-
> architecture would probably be required.  However, with the right libvirt
> client, we'd end up with generic GUI capabilities, console re-attach, etc.

Console reattach is already a feature of the current codebase (SET CONSOLE TELNET=port,BUFFERED).  A simulator with a buffered console runs without requiring a telnet connection when it is started.  A telnet connection to the designated port will display the buffered contents (i.e. the last 32KB output to the console) and then accept and pass across input to the guest system.

Some of the libvirt features (and possibly support for libvirt itself) may be a useful future extension.

> I'd like to see it be easier to use SimH as a library.  However, this is probably
> mostly incompatible with desires to build simulators that run as fast as
> possible.  I've tried leaving the SimH makefile untouched, but wrapping it
> with another makefile.  E.g., renaming the SimH makefile and having another
> makefile that references the SimH makefile.  It works, but feels a bit "off".

Well, it may be a bit 'off', but it does work.  You certainly can mess with the makefile during the active development of your simulator and if/when it gets merged into the active codebase the details needed to build your simulator will be folded in.

> I guess there are two types of questions when talking about ways to extend
> or improve SimH.  What would be useful to current users?
> What would be useful to current developers?  What would be useful for new
> users?  What would be useful for new developers.  Ok, that's four...
> 
> I think a generic GUI facility that provided a console and self- configuring
> displays of registers and devices would be great.  If it supported an easy way
> to link in simulator-specifc help, it would be awesome.  You could start from
> scratch or try to leverage things like libvirt or environments like Eclipse and
> Gnat.  It would be a lot of work though.

The current codebase has support at the sim> prompt for a much extended help.  Each device can provide a device specific help output routine.  Registers can each have static descriptions along with the BitField details previously mentioned.  Generic help is provided for classes of devices which use the sim_ether, sim_tmxr, sim_disk and sim_tape libraries.  The VAX simulators and the devices they use have had these help capabilities populated in the device and register structures.

These details and others can be extended as needed.

Thanks for your suggestions.  All are food for thought.

- Mark