Proposal for handling large numbers of registers

Stan Shebs shebs@cygnus.com
Fri Aug 6 16:33:00 GMT 1999


As some of you may know, Cygnus is working on a port of GNU to the
Fujitsu FR-V, a high-performance VLIW processor.  (See
http://www.cygnus.com/news/fujit071499.html for the announce.)

One of the interesting things about the FR-V is that it has a lot of
registers.  I don't think I can disclose the number and types of them
yet, but it's *well* over 100.  So the old model of a big flat list of
registers is going to be rather unwieldy for this target.  (Actually,
the model already wasn't working well for other register-rich targets.)

So I'm considering importing the idea of "register classes" from GCC.
GCC uses the class idea to guide allocation and instruction selection,
but we don't even need that much; just define the names of the classes
and which registers belong to each.

In a minimal model, each register belongs to exactly one class.  A
more sophisticated model would allow registers to belong to multiple
classes, although I think you'd want to have a primary class for each
register, so that GUIs can construct a hierarchical list of registers
by class, where each register appears exactly once.  (Note that if
each class has an individual bit vector for register membership, then
subclasses/superclasses may be computed with set ops.)

For the user, "info registers" works as before, listing all registers.
We can then extend it to make "info reg <class>" list only the
registers in the given class; the restriction that class names be
distinct from register names doesn't seem too onerous.

To go along with this, it would be useful to able to identify a class
of registers that are always fetched from targets.  Typically these
would be the ones saved and restored by traps, and so would not include
special registers, but that would be up to the person doing the GDB
and target-side stub port.  I could also see adding an option to
"info registers" to only display these, and redefining it and
"info all-registers" to base their behavior upon agreed-upon
classes, rather than always being wired to float/non-float classes
as they are now.

Questions and/or comments?  If everybody is agreeable to what I've
proposed here, I'll work out more details in a prototype and present
that later.

							Stan






More information about the Gdb mailing list