This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

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

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]