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 _______________________________________________ Simh mailing list [email protected] http://mailman.trailing-edge.com/mailman/listinfo/simh
