On Sunday 25 October 2009, Zach Welch wrote:
> Øyvind wrote:
> > >> This whole mrc/mcr thing is about driving
> > >> OpenOCD in the direction of polymorphic interfaces
> > >> at the C and command level, ref recent "mww phys"
> > >> work.
If you wanted polymorphism at the command level, then
it's not clear Tcl was the best choice. :)
Or at least, tcl used the way it's now used in this
project ...
> > > Is this the right level though? Anything that is specific to ARM should
> > > not be in target.[ch].
> >
> > If the current programming model supported the concepts
> > of interfaces, then this would have gone into some arm
> > generic files.
>
> It does support the concept. I think we lack a clear concept of how and
> here they should be layered.
Yes it does support the concept. It's done a bit more
hackishly than I'm used to, though... the type models
are not clean.
So for example this would be a clean hierarchy:
target --> ARM --> ARMv{4,5,6,7} --> core
As in, "arm926 is an ARMv5 is an ARM is a target".
(The Cortex-M stuff is kind of odd; it doesn't really
have much in common with any other ARM. Like the six
CPU modes, shadow registers, and so on. Just Thumb2.)
And the clean way to do that is just to encapsulate the
more generic structs inside the less generic ... like
struct arm926 {
...
struct armv5 {
...
struct arm {
...
struct target { ... }
...
}
...
}
...
}
At which point it's trivial for e.g. an arm926 method to
find the containing struct given a pointer to the target,
the arm, or the armv5 struct ... example:
/**
* container_of - cast a member of a structure out to the containing structure
* @ptr: the pointer to the member.
* @type: the type of the container struct this is embedded in.
* @member: the name of the member within the struct.
*
*/
#define container_of(ptr, type, member) ({ \
const typeof( ((type *)0)->member ) *__mptr = (ptr); \
(type *)( (char *)__mptr - offsetof(type,member) );})
Copied from some GPL'd OS source code. :)
That could be the basic single inheritance type model that
everything follows. But ... instead, there's something a
lot more convoluted and, afaics, error prone.
> > We have a separate problem(which I won't try to attempt solving
> > anytime soon) in that we have a very weak
> > model(not any really) to define an interface which a target
> > can either support or not.
We don't use the Tcl mechanisms for that: "$object method ..."
working iff $object supports "method", and otherwise failing
politely. (And explicitly passing $object around...)
> > Such interface is stuff is trivial in C++/java, but I haven't
> > seen it done elegantly in C yet. I hear it can be done
> > and certainly well enough for OpenOCD's simple needs.
>
> It's definitely possible, and I am slowly working toward this type of
> cleanup effort.
See above for one of the traditional ways to do it.
- Dave
_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
