On Saturday 31 October 2009, Øyvind Harboe wrote:
> > Well...
> >
> > I really don't like this pointer business. No type checking at all,
> > etc. This should be turned upside down as you suggested already: embed
> > more generic structures within the more specific ones, and copy the
> > container_of() macro from Linux to get at the outer structure when
> > needed.
>
> I would like to see this gone when we solve the interface
> problem. There is stuff like this all over OpenOCD.
Preview:
@@ -648,10 +601,7 @@ int arm926ejs_write_memory(struct target
uint32_t size, uint32_t count, uint8_t *buffer)
{
int retval;
- armv4_5_common_t *armv4_5 = target->arch_info;
- arm7_9_common_t *arm7_9 = armv4_5->arch_info;
- arm9tdmi_common_t *arm9tdmi = arm7_9->arch_info;
- arm926ejs_common_t *arm926ejs = arm9tdmi->arch_info;
+ arm926ejs_common_t *arm926ejs = target_to_arm926(target);
/* FIX!!!! this should be cleaned up and made much more general. The
* plan is to write up and test on arm926ejs specifically and
That's the "simplification" step. Less source and object
code. The container_of() is inside the target_to_arm926()
and it boils down to "result = target->arch_info + offset",
which is a single instruction.
> In C++ we would have used interfaces(pure abstract classes),
Actually in C++ standard single inheritance would be the most
natural scheme for this stuff, given the current code base and
design approaches.
In Tcl ISTR approaches like stacked interpreters get used.
That's just another single inheritance scheme ... e.g. the
command environment could be "current target's commands"
then globals, with the code implementing the command being
passed the right environment (== interpreter) as its context
for name resolution (procedures, variables, etc).
Though as I said a while back, it's been a long time since
I paid attention to OO implementation strategies inside Tcl.
There were quite a few available.
> but
> I'm still waiting for someone to come forth with the suitable mechanism
> for C(we'll visit this issue after 0.3 I'm sure).
If by "waiting" you mean "want to see patches", I'll send
a larger preview at some point. But container_of() seems
already, as Nico noted, sufficient to current tasks... and
just simplifying (like above) will be a major win.
- Dave
_______________________________________________
Openocd-development mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/openocd-development
