[Simh] fprint_sym and parse_sym limitation

[Paul Koning]

> On Sep 12, 2015, at 12:24 AM, J. David Bryan <jdbryan at acm.org> wrote:
> 
> On Friday, September 11, 2015 at 20:17, Paul Koning wrote:
> 
>> I'd do: if (cpu_reg[addr].flags & REG_IR) ...
> 
> OK, that's a reasonable approach.
> 
> You might wish to write an implementation of your idea.  I recall trying it 
> myself when I was first looking into the issue, but it turned out to be 
> reasonably complicated -- more so than passing register flags, which 
> required changing only two of the fprint_sym calls as I have outlined while 
> maintaining backward compatibility with existing simulators.

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.
> 
> You mentioned getting the register array by working back from the UNIT 
> pointer, but unfortunately, uptr is NULL in some cases, e.g., when called 
> from ex_reg.  ex_reg receives a REG pointer but neither a unit pointer or a 
> device pointer.  It could be added, of course.
> 
> Also, it's not clear how to derive the register index in ex_reg.  It's 
> known in find_reg, but it's not passed back out.  It could be rediscovered 
> by a second scan of the register array, though, to match the REG pointer.
> 
> Even when passing a register index and unit pointer, or a register pointer, 
> there's still the problem of identifying how that register is to be handled 
> within fprint_sym.  I think that something within the REG structure itself 
> needs to be the identifier, as identifying via the index or REG address 
> leads to maintenance issues, as I've noted earlier.
> 
> As an aside, I've not looked carefully, but I suspect that the 
> sim_vm_parse_addr and sim_vm_fprint_addr routines are just special cases of 
> this more general problem of knowing which register is being passed so that 
> you then know how to handle its parsing or printing.  It'd be nice if a 
> general solution could be found that would fold these in as well.

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.

In general, and that ties to my earlier comment, the SIMH calling conventions and structure layouts show lines of long evolution without a common model.  We have flags in some places but not others, switches passed in some cases but not others.  There are functions to format stuff that aren't told what it is they are formatting.  We have a context pointer in the device, but not in the unit (I ended up having to abuse the filebuf for that).  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.

	paul