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