On Apr 29, 2009, at 10:59 PM, Michael Bruck wrote:
On Thu, Apr 30, 2009 at 7:12 AM, Zach Welch <[email protected]> wrote:On Thu, 2009-04-30 at 05:17 +0200, Michael Bruck wrote:On Thu, Apr 30, 2009 at 1:16 AM, Zach Welch <[email protected]> wrote:On Wed, 2009-04-29 at 17:25 -0500, Dick Hollenbeck wrote:What? It is only several days to get this project to compile with C++, maybe several weeks to "rewrite" it. (Do we get to peek at the oldcode when we "rewrite" it? If not, it would be several years.)Having developed large projects in both languages, my approach would be different enough that they would be unrecognizable from one another. They would be two different projects. At that point, preserve this CCould you elaborate on that ?At the most fundamental level, it comes down to this: C == imperative programming C++ == object-oriented programming The different mindsets should yield completely different code. Theiroverall architectures could be virtually identical, but the code wouldnot be structured even remotely the same.The current code looks to me as if in large parts it is a simulation of C++ in C. It mostly is object-oriented. So I was curious if you had thought of any specific things that you would structure differently. My impression was that its just a matter of switching code that simulates classes to code that are actual classes. Michael _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
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.
-- Rick Altherr [email protected]"He said he hadn't had a byte in three days. I had a short, so I split it with him."
-- Unsigned
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
