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