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. > But some variant & helper fn's along the lines above would make > a lot of sense. Yes I would actually prefer an API that is tightly linked to an independent data structure that that builds up a jtag sequence in the target driver and then executes it. All the commands would then work on building up that structure and in the end it is handed over directly to the jtag interface driver for execution. The current model does the same but essentially uses a global variable. But presumably due to ownership issues the field data is cloned for that global variable. If the jtag sequence structure is owned by the target this (second) copy operation can be avoided as well. Michael _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
