Hello,
Am 11.02.2011 10:17, schrieb Øyvind Harboe:
> How about rewriting clock_tms then?
>
Because the used time? This session was to short (some seconds) to get a
meaningful time statistic.
Regards,
Mathias
___
Openocd-development mailing list
Ope
How about rewriting clock_tms then?
--
Øyvind Harboe
Can Zylin Consulting help on your project?
US toll free 1-866-980-3434 / International +47 51 87 40 27
http://www.zylin.com/zy1000.html
ARM7 ARM9 ARM11 XScale Cortex
JTAG debugger and flash programmer
___
Hello,
Am 11.02.2011 10:01, schrieb Øyvind Harboe:
> What kind of CPU are you running OpenOCD on?
It's a Intel T7200.
Regards,
Mathias
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinf
What kind of CPU are you running OpenOCD on?
It's great that you are basing your optimizations on
profiling information. That always makes for a convincing
case.
--
Øyvind Harboe
Can Zylin Consulting help on your project?
US toll free 1-866-980-3434 / International +47 51 87 40 27
http://w
Hello,
i think this patch make sense because the functions are called very often
(column calls in the
profile data) and do a little bit more then nothing.
Am 11.02.2011 07:29, schrieb Øyvind Harboe:
> I don't have any objections to this particular patch, but if we
> have to start doing tweaks at
On Fri, Feb 11, 2011 at 8:41 AM, Michael Schwingen
wrote:
> On 02/11/2011 07:29 AM, Øyvind Harboe wrote:
>>
>> I don't have any objections to this particular patch, but if we
>> have to start doing tweaks at this level, then where does it
>> end?
>
> I am not too fond of this since it exposes inte
On 02/11/2011 07:29 AM, Øyvind Harboe wrote:
I don't have any objections to this particular patch, but if we
have to start doing tweaks at this level, then where does it
end?
I am not too fond of this since it exposes internals that should stay
internals (variables that were static are now globa
I don't have any objections to this particular patch, but if we
have to start doing tweaks at this level, then where does it
end?
Is there any profiling data that backs up this particular
optimization as particularly effective?
It is very surprising that this would make an impact,
but that's what
Changes:
- declare tap_set_state_impl, tap_get_state, tap_set_end_state,
tap_get_end_state as static inline,
this will decrease the calling overhead for this status getter and setter
functions
diff --git a/src/jtag/interface.c b/src/jtag/interface.c
index 1ed4512..8d5d514 100644
--- a/src/jtag/i
