On Sat, Sep 29, 2012 at 9:58 PM, Freddie Chopin <[email protected]> wrote: > W dniu 2012-09-29 10:53, Andreas Fritiofson pisze: > >> For a bugfix release, I think it's reasonable to just reinstate the >> user pointer. The risk of introducing other regressions when fixing >> all call sites is probably significant, and it would be hard to test >> all different code affected. The few callers using auto variables >> could be audited for problems, but any bugs there would have existed >> pre-0.6.0 as well. > > > That's a good point for reverting the commit temporarily for 0.6.1. I'm > convinced, as we cannot test all affected flash types and instead of fixing > one regression we may introduce 3 new ones (; > > >> The direction bug in the new ftdi driver could also be a candidate for >> inclusion in a bug fix release. > > > You mean this one? > http://openocd.zylin.com/#/c/849/ > > ?
Yes. > >> Yes. They need a bit of rebasing work. I could take a stab at it this >> weekend, perhaps. But there are also other places such as the mips >> fast data mentioned. Preferably we should solve all problems >> similarly, so we need to agree on the general method. >> >> If we remove all re-use of working areas, there's probably no need to >> store the pointers outside the functions at all, so if we go that >> route we should probably take Freddie's option #3. > > > If we have time (because regression was "fixed" with a revert), then I'm > also for #3 - removing all static pointers to working area. I just pushed a set of patches that hopefully fixes all uses of working area so they're at least safe, removing all non-local working area pointers. > >> The big question is if some code is very dependent on re-use of >> working areas (for performance). In that case we could add a proper >> mechanism to keep, but invalidate, an allocation on target resume etc, >> instead of the unconditional freeing as today. The drivers would use a >> validity check instead of checking if it's own pointer is nullified to >> know when they need to re-upload the algorithm. Allocations would only >> be freed explicitly. >> >> On the other hand, that may still not be safe, since other things than >> target resume/reset could destroy working area contents (such as the >> user interactively writing memory with mdw), so we would need to >> invalidate on those events too => complex and may not be many >> opportunities left for any performance gains. > > > Is there any code that fits such characteristics? I just cannot see anyway > it would be possible to gain any performance by having the working area > available past resets and resumes - when you do anything that requires > working area and should be fast (flashing) you do it in one go without any > resumes or resets in between... Apparently the nand code depends heavily on re-use of the working area, and it doesn't fit the assumption of making all the work in one go. Every read will need one algorithm execution and if that now needs to carry the algorithm upload too, it's bound to be slower. How much I have no idea. Same for the MIPS fastdata access and arm7/9 read_memory. >Thus I think that removal of such static > pointers is a good solution. Anyway - "allocation" of working area is fast > (everything is done inside OpenOCD - right?), what is slow is > uploading/downloading anything there and I just cannot see how one would > expect the contents of the working area to be intact after target is resumed > or reset... It's not about reusing between resumes/resets. But rather if you do several operations needing the same algorithm, between resumes/resets. I'm thinking my suggestion above is starting to look like the better solution, long term. /Andreas ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://ad.doubleclick.net/clk;258768047;13503038;j? http://info.appdynamics.com/FreeJavaPerformanceDownload.html _______________________________________________ OpenOCD-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openocd-devel
