[Simh] fprint_sym and parse_sym limitation

[J. David Bryan]

On Friday, September 11, 2015 at 15:32, Paul Koning wrote:

> Not quite.  It would break existing simulators that use the addr field
> for register radix without masking it. 

But existing simulators wouldn't be passing any user-defined REG_* flags, 
so "(rptr->flags & REG_UFMASK) | rdx" would be equal to "rdx", and they'd 
receive the radix just as before.


> If you want to disregard that case, would it not be just as simple,
> but more powerful, to pass the index into the registers array as
> "addr"?  Then all you need is to find the regs vector from the UNIT
> pointer, and index that with addr, and you have all the information you
> might want about that register -- its flags, name, or the register
> number if you want to use that. 

Assume that I have three CPU registers that I want to format identically.  
How do I tell if I've been called for one of these?  If I receive the 
index, then I'd have to do:

  if (addr == 3 || addr == 7 || addr == 12) ...

or:

  if (strcmp (cpu_reg [addr].name, "CIR") == 0 ||
      strcmp (cpu_reg [addr].name, "NIR") == 0 ||
      strcmp (cpu_reg [addr].name, "XIR") == 0) ...

whereas with a user-defined flag, it's:

  if (addr & REG_IR) ...

When I first ran into the problem two years ago, I had done what you 
suggested, i.e., pass the register index.  But in addition to being more 
complicated, the problem with using register numbers or names is that it's 
fragile.  The register definitions are (typically) in cpu.c, but the above 
usage is in sys.c.  If I rearrange the register order or insert a new 
register or change the names in cpu.c without correcting the usage in 
sys.c, things fail silently.


> True, but if you can see the register array entry, then you can test the
> flag from that entry, which is just as general.

I'd argue the other way around.  :-)  If you need the index number, you can 
define a flag field to hold it.

                                      -- Dave