> On Fri, May 8, 2009 at 8:53 AM, Magnus Lundin <lundin at mlu.mine.nu > <https://lists.berlios.de/mailman/listinfo/openocd-development>> wrote: > >/ U;yvind Harboe wrote: > />>>/ > />>>/ You can add your stuff for testing, ok no problem. You can put things in > />>>/ plase so that I can test and profile potential changes. But you are > />>>/ stepping on my toes by changing things I work on. > />>>/ > />>/ > />>/ Let me take this oportunity to thank you for finding and reporting these > />>/ bugs > />>/ in a productive manner even if you disagree with me on this one. I > believe > />>/ I will win you over, eventually. > />>/ > />>/ I'm jumping to fix the problems that I've created, this includes > />>/ performance > />>/ problems. > />>/ > />>/ > />>>/ > />>>/ The in_handlers are not depreciated, you are suggeting that they should > />>>/ be. > />>>/ a big difference, and I think they should stay. > />>>/ > />>/ > />>/ in_handlers cause various problems: > />>/ > />>/ - API bloat. It is only used in a few places. > />>/ > />/ > />/ Important places :) > / > Right. But it complicates all the other places. > > >>/ - performance problems on embedded targets. Lots of fn calls and overhead > />>/ in the drivers. > />>/ > />/ > />/ If the operation performed by the inhandler is necessary the it must be > />/ called anyway somwhere, it is just moved around. > / > But if called from the calling code, it will not be a series of function > calls within function calls within function calls. It will just be a > loop that manipulates an array. For *slow* CPUs arm7/9 type > embedded hosts, this matters. > > >>/ - hard to read code (callbacks are much more opaque than a straightforward > />>/ manipulation in the code) > />>/ > />/ > />/ We have event_callbacks, timed callbacks and other fancy stuff. Shall > they > />/ also be removed ? > / > I don't see a strong analogy to this case so it is hard to comment. > > >/ The in_handlers are actually easier to know exactly when and how they are > />/ called. > />>/ > />>/ - I believe that they will *hide* some performance problems that will > />>/ now be brought into bright daylight. Using a normal out/in scan + > />>/ post processing will be much clearer and faster. > />>/ > />>/ > />/ > />/ You may be right about this on embedded openocd hosts (zylin) but for > />/ systems with long roundtrips, no ! > />/ > />/ The actual implementation can be check and perhaps improved. > / > If this causes performance regressions on USB, I've promised to fix > them. Some way or another. > > > -- > Øyvind Harboe > Embedded software and hardware consulting services > http://consulting.zylin.com <http://consulting.zylin.com>
OpenOCD is a concept with a defined structure and some layers. The JTAG API layer is a important part of the structure, certainly the more important. But WHY simplifying the JTAG API just because it will generate a smaller code for a specific embedded systems ? For an simple embedded you only need to have to wiggle the TMS TCK TDI ... signals. The actual JTAG API provide much more than just wiggler. Simplifying the JTAG API as you are doing actually is very very bad. You are removing an very powerful possible extension of JTAG API. All your changes are too much specific to a specific hardware. But are bad regression for USB concept. You should create your own OPENOCD code for your specific requirement and hardware. But please do not touch so important layer as the JTAG API (jtag.c and jtag.h) . We will lost performance and have a very BAD regression regarding the general concept of OpenOCD. Also, you are deleting many IMPORTANT codes in the OpenOCD for the future of OpenOCD. You created many changes without any tests before committing + bugs + real regression ? Again, please create your own OpenOCD optimized for your own hardware. Please come back with the in_handler ... and other _mask ! Laurent http://www.amontec.com JTAGkey makers ! http://www.amontec.com/jtagkey.shtml _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
