anthony-kolesov
commented
5 years ago Note that today some registers which are essential for the debugging have hardcoded definitions. For example here https://github.com/foss-for-synopsys-dwc-arc-processors/openocd/blob/master/src/target/arc_ocd.c#L195 code uses hardcoded information for STATUS32. Or here https://github.com/foss-for-synopsys-dwc-arc-processors/openocd/blob/master/src/target/arc32.c#L530 code has hardcoded info on caches.
At the same time there is a more flexible code, like here: https://github.com/foss-for-synopsys-dwc-arc-processors/openocd/blob/master/src/target/arc32.c#L763, it refers to registers and their field by name, and I consider this code superior, because it doesn't duplicate information on which bit or register name has what meaning - connection through names is better. Although it is still not perfect, for example, in theory parameters of caches can be read and fully configured in TCL scripts as well, I think - that would be even better.
My opinion is that it would be better to replaces instances of code that use hardcoded register definitions with approach that relies on register/field names - it is something that I wanted to do after implementing registers in TCL, but never had the time to do. Though it is possible there could be some functions which are executed very early, before register definitions are read from TCL, so those functions would have to use hardcoded info, but that should use IDENTITY, DEBUG and STATUS32 at most, if at all. However, there is a concern that getting register by name is done by scanning linked list, so log(N), so in some cases you may need to either cache pointer to register object, or keep using the hardcoded definitions.
Also the more of this stuff you'd move to TCL, the more flexible it will be. For example, function https://github.com/foss-for-synopsys-dwc-arc-processors/openocd/blob/master/src/target/arc32.c#L751, that sets up CCM parameters - arc32_common fields can be exposed as TCL properties, then those checks, based on register field values can be done in TCL and then they would set arc32_common fields. Perhaps, this should be done only after the initial upstreaming, though.
EvgeniiDidin
In case of ARC we have arch-specific registers like "STATUS32", "DEBUG", etc. We use one routine to add default GDB and ARC-specific register types.
In cpu/arc related .tcl script we describe register-types and registers, which are available on target. This requires jimctl command handlers.