[Simh] fprint_sym and parse_sym limitation

[J. David Bryan]

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 prefer your later suggestion.


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

                                      -- Dave