On Fri, Oct 23, 2009 at 11:37 AM, David Brownell <[email protected]> wrote:
> On Friday 23 October 2009, Øyvind Harboe wrote:
>> > These would be methods in the armv4_5 struct yes? The thing
>> > that should be core-ARM-for-everything-except-Cortex-M?
>>
>> No. They go into the target->type.
>
> But not all processors are ARMs...
That's not a problem as such. If we had C++ we would simplify define
a mrc/mcr interface and each target would either implement it or not.
>> OpenOCD does not use C++
>> and the idea of multiple interfaces.
>
> It uses C with a different style of interface abstraction.
> I'm sure you've observed how for example the "armv4/v5" and
> "arm7/arm9" and "arm9" plus core-specific stuff all works
> concurrently.
I've looked at it. Shudder....
>> In lieu of C++ & interfaces, I think the least horrible choice is to
>> put it into target->type and return error when it is not supported.
>
> I don't understand this implication that you need C++ to do
> any of that. Especially since OpenOCD is already doing those
> things without using C++ ...
And look at the result, e.g. here is a particularly juicy bit:
int arm966e_get_arch_pointers(target_t *target, armv4_5_common_t
**armv4_5_p, arm7_9_common_t **arm7_9_p, arm9tdmi_common_t
**arm9tdmi_p, arm966e_common_t **arm966e_p)
{
armv4_5_common_t *armv4_5 = target->arch_info;
arm7_9_common_t *arm7_9;
arm9tdmi_common_t *arm9tdmi;
arm966e_common_t *arm966e;
if (armv4_5->common_magic != ARMV4_5_COMMON_MAGIC)
{
return -1;
}
arm7_9 = armv4_5->arch_info;
if (arm7_9->common_magic != ARM7_9_COMMON_MAGIC)
{
return -1;
}
arm9tdmi = arm7_9->arch_info;
if (arm9tdmi->common_magic != ARM9TDMI_COMMON_MAGIC)
{
return -1;
}
arm966e = arm9tdmi->arch_info;
if (arm966e->common_magic != ARM966E_COMMON_MAGIC)
{
return -1;
}
*armv4_5_p = armv4_5;
*arm7_9_p = arm7_9;
*arm9tdmi_p = arm9tdmi;
*arm966e_p = arm966e;
return ERROR_OK;
}
--
Øyvind Harboe
http://www.zylin.com/zy1000.html
ARM7 ARM9 ARM11 XScale Cortex
JTAG debugger and flash programmer
_______________________________________________
Openocd-development mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/openocd-development
