[Simh] fprint_sym and parse_sym limitation

[Mark Pizzolato - Info Comm]

On Sunday, September 13, 2015 at 9:21 PM, J. David Bryan wrote:
> On Sunday, September 13, 2015 at 13:55, Paul Koning wrote:
> 
> > I wonder if it would make sense to create new functions, with cleaner
> > calling conventions, and a global simulator flag that the init code
> > can set (or set at compile time) to tell the mainline which calling
> > convention to use.
> 
> I'd argue no, because I think it'd make an already complicated situation
> worse.  Consider that ex_reg (e.g.) currently does:
> 
>   if REG_VMAD
>     then call sim_vm_fprint_addr
>   else if REG_VMIO
>     then call fprint_sym
>   else
>     call fprint_val
> 
> Adding a conditional fourth value-printing routine in front of those three
> seems to me to be going the wrong way.  

I agree 100%.

> > I wonder if a more general rationalization of interfaces and structures
> > -- possibly one that means adjusting the existing VMs to use the new
> > stuff -- is worth doing.
> 
> If changing existing simulators is deemed OK, then it seems to me that
> having just one VM-provided print (and one parse) routine would be the way
> to go.  If the simulator designer didn't want the default formatter, then a
> custom formatter could be invoked in its place.  Those routines would have
> to receive some unequivocal indication of what they were printing (or
> parsing) -- a memory address, a memory value, a specific register value,
> etc.  They'd also want to be called from every place where default printing
> or parsing would otherwise take place.
> 
> That said, given that every simulator has to provide symbolic print and
> parse routines, every simulator would require changes to accommodate new
> calling sequences.  That was the primary reason I implemented my suggested
> changes the way I did; it seemed to be the least disruptive way to get
> positive IDs to the print and parse routines.

Proposing such a change would imply the willingness and would require expertise to change AND test EVERY existing simulator.  That is a steep hill to climb.  The changes to most simulators would not really bring any net benefit to those quite stable simulators.

Meanwhile back to a few of Paul's earlier comments:

Paul said:
> parse_addr and fprint_addr are another area that gave me surprises.  They
> don't see the switches, so there isn't any way for command switches to
> affect the address printing, which is what I wanted to be able to do.

The current command's switches are visible via the global sim_switches.  Accessing this variable is done throughout the codebase.  How doesn't this work for you?

Paul said:
> We have a context pointer in
> the device, but not in the unit (I ended up having to abuse the filebuf for
> that).  

Reusing the filebuf could certainly be used for an arbitrary context variable if it isn't being used otherwise.  Alternatively fileref can optionally also not be a FILE *.  When it isn't a FILE *, the unit->dynflags UNIT_NO_FIO flag should be set.  When set, it becomes a unit specific void * which can be used for context or anything else.

Dave's suggestion seems most reasonable due to the zero impact on the existing simulators.  Can you work with that?

- Mark