Øyvind Harboe wrote: > On Fri, May 8, 2009 at 2:18 AM, Magnus Lundin <lun...@mlu.mine.nu> wrote: > >> Here is my last comment for tonight, promise :) >> >> Before we had a setup where it was possible to use inhandlers, or to not >> use inhadlers and place the corresponding logic in the upper layer. >> >> Now inhandlers are supposed to be bad, it is dictated that inhandlers >> are bad. I know about the potentioal problems for out of scope >> variables, but that happens with all asynchronous code. That is never >> problem free. And USB interfaces are asynchronous, and distributed >> systems even more so. >> >> One example is that should realy show this is to read a big block of >> chars in cortex-m3 code, that is to call the >> arm_adi_v5.c;mem_ap_read_buf_packed_u8 with a big block of data. >> >> Another one (I think) is reading all core registers on ARM7/9, here we >> do 16 in scans of a bitreversed scanchain. So this can definetly >> affect single stepping with a USB interface. >> > > W.r.t. performance the first order of the day is to profile. > > Could you get me some numbers about the above? > > For the sake of argument: if 16 roundtrips was the total # of roundtrips > for a step, then I'd have to see real world numbers before I believed that > that was observable. > > You are changing very centrals parts, you should show the benefits before this kind of radical changes. And the priority is stability. > I'm pretty confident that the new scheme + a tad of profiling will on > the roundtrip problem will yield *better* performance than before. > >
That reamins to be seen. _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
