Re: [PATCH] Remove some hardwired assumptions about register sets

[Andrew Cagney <cagney@gnu.org>]

>> Daniel, the patch adds a global variable "num_mips_processor_regs" 
> 
> 
> We could use a new "tdep->num_mips_processor_regs" variable instead.
> That is probably cleaner anyway.
> 
> 
>> I'm wondering what motivated the change?
>> ... sidestep the issue
>> ... made all the arrays the same size.
> 
> 
> The problem is the assumption that all the arrays are the same size,
> or perhaps more fundamentally, that "all mips architectures will have
> registers sets of similar size'.

The number of registers is determined by "num_regs".  Thinking about it, 
wouldn't ->num_mips_processor_regs be redundant information?

> I'm working on port, which will soon be contributed, that currently
> adds 384 new register names (reg numbers 32-415) for a matrix
> coprocessor (cop 2).
> 
>  When contributed though the names will be reduced to just 69 new
> names (32-100).  The original port assigned separate register names to
> each of the individual 256 matrix elements (16 vectors of 16 elements)
> instead of handling each 16 element vector as a single named vector
> register.
> 
> Still, even with 69 new names, it gets really ugly having all the
> other *_reg_name[] arrays have to be full of mostly null strings.

True, but it isn't that much memory.

Does setting "num_regs" to ARRAY_SIZE (relevant register name array) + 
magic:32 work?  What of the function 
deprecated_mips_set_processor_regs_hack which would need an array size 
sanity check.

Andrew