On Thu, 2009-12-03 at 10:51 +0100, Øyvind Harboe wrote: > On Thu, Dec 3, 2009 at 10:36 AM, Zach Welch <z...@superlucidity.net> wrote: > > On Thu, 2009-12-03 at 10:22 +0100, Øyvind Harboe wrote: > >> (Ref. discussion I think we've settled that the minidriver can either > >> implement an ABI or use inlining for performance.) > >> > >> On Thu, Dec 3, 2009 at 10:11 AM, Zach Welch <z...@superlucidity.net> wrote: > >> > On Thu, 2009-12-03 at 09:53 +0100, Øyvind Harboe wrote: > >> >> So the minidriver (including classic API) must have control over > >> >> whether or > >> >> not the following fn's gets inlined or not. These fn's really are in > >> >> the inner > >> >> loops and boil away to *nothing* on a low performance low latency > >> >> system. > >> > > >> > And they should now, after my patches. I want to see yours again, > >> > updated against the current master. :) > >> > >> I have an automake problem / include file problem I don't know how > >> to solve in a pretty fashion: > >> > >> jtag.h needs to include a minidriver_inline.h for the active minidriver. > >> How to do that? > > > > You should not need to add any new files at this point: > > > > jtag/minidriver.h includes "minidriver_imp.h": > > jtag/drivers/minidriver_imp.h -->> the driver's implementation > > jtag/minidriver/minidriver_imp.h -->> the minidriver's implementation > > > > The minidriver's implementaiton includes "jtag_minidriver.h", which is > > defined by the implementation: > > > > jtag/minidummy/jtag_minidriver.h > > jtag/zy1000/jtag_minidriver.h > > > > Put stuff in these files... Do not put new inline functions in > > jtag/jtag.h. jtag/minidriver.h, or jtag/drivers/minidriver_imp.h. > > To get inlining to work, I need to make a few fn's in core.c > inline fn's too. Take jtag_add_dr_out() as an example.
Well, you can't. The rules prohibit this. ;) > jtag_add_dr_out() must be defined after including jtag.h. This means > jtag.h must include the inline version of interface_jtag_add_dr_out(). That's fine -- for ZY1000. > So.... yes... I need to figure out a way for minidrivers to expose, via > jtag.h, > the inline implementations. ...while also providing an out-of-line version for the drivers. :/ Define a macro called jtag_add_dr_out in drivers/minidriver_imp.h that redirects the call to an out-of-line function (with the _imp suffix). The driver.c file can define that function and #include a new header that is also shared with minidriver/minidriver_imp.h. This new header provides the inline version, which is called from the driver's _imp. There you have it. Or, improve the algorithms such that such inlining is moot. ;) > The driver minidriver should be able to implement jtag_add_dr_out() as a > non-inlined function in order to be able to support an ABI at that level. As I said elsewhere, it's now safe to #include "minidriver.h" in "jtag.h", so long as you do not add in-lines to the files I noted. > > Look at my mirror. Go there right now. :) I've mentioned my 'hdr' and > > 'tests' branches a few times. You haven't looked at them, or you > > wouldn't be asking this question. That work is now on my master branch, > > queued to be pushed. > > Rights... I recall those changes. Yes that's a good cleanup. I > protest when you are doing cleanup work that causes problems, > but not comment when it looks all good. The problem is that your definition of good puts performance too high at the list of priorities. At this stage, that is like polishing a turd. You would be better off investigating long-term fixes, rather than chasing around implementation issues that patch over the problem temporary. The architectural improvements that are binding your hands presently reflect other design improvements need to be made. That said, I still want to see you find a suitable workaround, and there will undoubtedly be a compromise involved. ;) > I think I want to wait with the minidriver work until you have the hdr branch > pushed. It's nearly ready. --Z _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
