Rick Altherr wrote: > Actually, the TCL layer is using TCL objects which in the JIM > implementation of TCL, happen to be pointers. Of course, with JIM, we > didn't need to build our own runtime, so things like determining the > type of an object is handled for us. > > I've had a number of ideas on how to rewrite OpenOCD in an > object-oriented fashion (be it in C++, Objective-C, or C with a custom > built runtime). Mainly I see a benefit in streamlining how we develop > targets. Today, it is a manual process where a target is a set of C > functions that are collected under a target type. In practice, those > functions rely on some stack of internal layers (cortex-m3 relies on > adiv5 relies on jtag....). All of that is hard-coded into the target > and introducing a new target can be daunting. > > Instead, an object-oriented model where each layer is a separate > object allows for much more dynamic handling of targets. We can also > consolidate common behavior into superclasses and split large blocks > of functionality into finer grain classes. For example, an FT2232 > device could be represented as a subclass of the Interface class. > That subclass could in turn have each port be a different object (A > could be a JTAGPort subclass while B could be a SerialPort subclass). > Then a JTAGProtocol class could be attached to the JTAGPort. That > allows the implementation of the JTAG hardware to be split from the > JTAG protocol (state machine, etc). Such a separation not only makes > the code easier to understand, but the pieces can also be tested in > isolation. > > Going to an extreme, the classes could also incorporate an API that > describes the types of classes they should be attached to. This > allows for dynamic loading and automatic configuration of classes. A > certain amount of seeding would be necessary, but it could simplify > things to the point that telling OpenOCD you have an FT2232-based > interface is sufficient for it to figure out what targets, flashes, > and plds are available.
Cool. Then there is the nice std::string. We could have an unsigned char version and use it for buffer management, basic_string rooted. At that point, we begin to get off of our hands and knees. Dick _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
