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.

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.

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.

-- 
Øyvind Harboe
http://www.zylin.com/zy1000.html
ARM7 ARM9 ARM11 XScale Cortex
JTAG debugger and flash programmer
_______________________________________________
Openocd-development mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/openocd-development

Reply via email to