On Wed, Nov 18, 2009 at 15:35, Øyvind Harboe <[email protected]> wrote: > On Wed, Nov 18, 2009 at 3:32 PM, Michael Bruck <[email protected]> wrote: >> On Wed, Nov 18, 2009 at 15:12, Øyvind Harboe <[email protected]> wrote: >>> On Wed, Nov 18, 2009 at 2:53 PM, Michael Bruck <[email protected]> wrote: >>>> I would suggest removing the fields completely from that layer and >>>> replacing them with function calls. For the most common types of data >>>> like uint32_t. >>>> >>>> scan_start_dr(); >>>> >>>> scan_tap(struct jtag_tap); >>>> scan_field_u32_w(size_t bits, uint32_t value); >>>> scan_field_u32_wr(size_t bits, uint32_t value, uint32_t * result); >>>> scan_field_buf_w(size_t bits, const void * buf); >>>> ... >>>> scan_end(); >>>> jtag_execute_queue(); >>>> >>>> etc. >>>> >>>> The layer below takes all these neatly constructed and allocated >>>> fields and copies them anyway. You'd have to switch from an array of >>>> fields to a linked list internally, but overall the code would be >>>> cleaner. >>> >>> I don't see the entire API you are propsing, but it would be very >>> inefficient >>> and completely break with the current model. >>> >>> The current API has a couple of things going for it with being efficient on >>> both low performance cpu low latency and high performance cpu long latency >>> scenarios. >> >> To the contrary, it would be faster. When fully implemented it removes >> the step that clones all the data in driver.c. > > Actually, the minidrivers don't clone today, so that's already taken care of.
Doesn't that apply only to zy1000.c ? > The USB drivers have a 1ms roundtrip problem to contend with, the > rest is in the noise, essentially. There is plenty of evidence to this effect. *You* brought up performance as concern... My goal was primarily streamlining code. Your example seemed to be too much of a workaround rather than addressing the problem directly, which IMO is that the uint32_t case is so common that there should be a short unambiguous way to deal with it. Of course even a set of standard wrappers to package the set-up of the most common field configurations would help a lot, without also serving as a shortcut into the minidriver-layer to avoid the copying. > Also we have to *carefully* consider how we can make *small* steps that > can be tested on all the hardware combinations. Otherwise any change > is unlikely to pay off. We're getting there but it will and should take time. It was a suggestion on long-term goals. Small steps are usually most effective when they go towards a specific target. Michael _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
