[Simh] Questions regarding future simulator development

[Michael Mondy]

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

First though, let me say that I looked at a lot of simulator toolkits
for my personal project before selecting SimH.  Nothing else came
close for supporting weird things like a 36-bit architecture that
sometimes ran with a flat addressing model and sometimes ran with
a segment/offset model.  With SimH, I can do memory inspection and
breakpoints using either native addressing model.

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.

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.

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.

Open sockets with the SO_REUSEADDR or "no wait" option. I have code
for this minor change.

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

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.

My simulator for the hardware that ran Multics supports source-level
debugging.  I display the Multics PL/1 sources, the PL/1 stack,
values of PL/1 variables etc.  However, I'm lucky to have the
compiler listing files for the sources that make the Multics boot
tape.  It seems unlikely that this will be of much interest after
I get to the point where the OS fully boots.  It also seems unlikely
that any other simulator would have compiler listing files available,
so this probably isn't a feature that would be useful generically.

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

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.

-- Mike