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... > 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. > Also the ARM11 is *very* different > so stuffing it into the armv4_5 would be a pain. That's what I meant about "should be core-ARM-etc" ... you'll notice that the ARMv7a support uses that, but it's no more a v4 chip than an arm11 is. The armv4_5 stuff is pretty much core ARM ... registers, half a dozen modes, lightly banked except FIQ which has more. Support for coprocessors (mrc/mcr) fits in fine. If the arm11 (armv6) stuff isn't layering on top of that, I'm sort of curious why. If the reason is anything more than the name suggesting it's the wrong approach, then that's something to fix... > 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++ ... _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
