On Friday 11 September 2009, Øyvind Harboe wrote: > There are *lots* of snippets around the code.
And they're mostly core-specific. Stuff like the DCC support on ARMs, where ARMv4 and ARMv5 share the same model (cp14 based), XScale morphed it by taking away one bit, and newer ARM cores changed the JTAG level interfaces in various ways. Plus the calling conventions aren't necessarily going to be portable ... and some of them need customized exit conditions. Which registers are used as inputs will matter; that assumes params fit in registers, which is _probably_ a safe assumption to make. > I'd like to see what's running under MIPS exercised by > and large by the ARM target.... And vice versa. Or AVR8; or AVR32. With hardware ECC, NAND-related code snippets need to be controller-specific instead of core-specific. One aid might be to have a small library of standard code fragments, written in C, that new targets should try to package -- for optimization. CFI support would be a useful test: the accelerators are currently there only for ARMv4 and ARMv5 cores. (Though there's no reason they shouldn't work on ARMv6 and ARMv7...) I guess I don't quite see the point to coming up with something more generic than target algorithm support. For ARM there's a current reusability problem: when the code *could* be reused, that's needlessly blocked because the run_algorithm() interface isn't generic enough to ignore what core is underneath. Before bringing MIPS into that picture I suggest it's best to get ARM sorted better. - Dave _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
