[Simh] Questions regarding future simulator development
Michael Mondy
michael.mondy at coffeebird.net
Thu Apr 11 17:12:32 EDT 2013
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:
> > 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...
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.
>
> > 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.
>
> > 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?
>
> > 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
>
> > 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.
Agreed. I was listing all the "interesting" ideas I had even if I didn't personally see much utility. Someone might find one of these languages interesting if they wanted to make a GUI or some sort of appliance? Maybe...
>
> > 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.
>
Good to know.
> 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
>
--- scp.c.orig 2013-03-16 13:40:50.000000000 -0500
+++ scp.c 2013-03-16 14:00:30.000000000 -0500
@@ -23,6 +23,10 @@
used in advertising or otherwise to promote the sale, use or other dealings
in this Software without prior written authorization from Robert M Supnik.
+ 10-Dec-12 MM Pass rptr to fprint_sym to allow output to be tailored
+ to the specific register such as displaying a condition
+ register as flag names. Allow quoted sequences in command
+ input as a single token.
20-Mar-12 MP Fixes to "SHOW <x> SHOW" commands
06-Jan-12 JDB Fixed "SHOW DEVICE" with only one enabled unit (Dave Bryan)
25-Sep-11 MP Added the ability for a simulator built with
@@ -4529,7 +4533,10 @@
if ((rptr->flags & REG_VMAD) && sim_vm_fprint_addr)
sim_vm_fprint_addr (ofile, sim_dflt_dev, (t_addr) val);
else if (!(rptr->flags & REG_VMIO) ||
- (fprint_sym (ofile, rdx, &val, NULL, sim_switches | SIM_SW_REG) > 0)) {
+ // Pass the rptr to fprint_sym instead of a NULL uptr.
+ // Otherwise, fprint_sym has no way to provide output tailored to
+ // a specifc register (e.g. displaying a conditions register as flags).
+ (fprint_sym (ofile, rdx, &val, (void*) rptr, sim_switches | SIM_SW_REG) > 0)) {
fprint_val (ofile, val, rdx, rptr->width, rptr->flags & REG_FMT);
if (rptr->fields) {
fprintf (ofile, "\t");
@@ -5048,7 +5055,13 @@
char *get_glyph_gen (char *iptr, char *optr, char mchar, t_bool uc)
{
-while ((isspace (*iptr) == 0) && (*iptr != 0) && (*iptr != mchar)) {
+int quoting = 0;
+while ((quoting || isspace (*iptr) == 0) && (*iptr != 0) && (*iptr != mchar)) {
+ if (*iptr == '"') {
+ quoting = ! quoting;
+ iptr ++;
+ continue;
+ }
if (islower (*iptr) && uc)
*optr = toupper (*iptr);
else *optr = *iptr;
More information about the Simh
mailing list