Magnus Lundin wrote: > Dick Hollenbeck wrote: > >> Magnus Lundin wrote: >> >>> The tap state engine will not change any time soon. >>> >>> Hopefully the statenumbers will stay. >>> >>> But there will probably be work on shortest path tables, path >>> transition tables with fixed mumber of tap transition etc. For this >>> type of work I think an array is a better and less error prone >>> representation than a big set of nested switches. It is graphic :) >>> and that is good. I can also play with and debug array repsentations >>> of state graphs in other tools like Octave. This very good way to >>> check the validity and catch errors. Actually, now when I think about >>> this, it should be possible to generate the arrays with some >>> Octave/Matlab code and calculate path lengths. >>> >>> So my wote goes for arrays. >>> >>> Regards >>> Magnus >>> >>> >> How should we count your vote, with or without array out of bounds >> checking? >> >> Dick >> >> >> > I am perfectly ok with array out of bounds checking, it will catch some > silly errors and on PC platforms we have sufficient processor cycles for > that. Bounds checking can always be turned off when the code runs > stable and performance is critical.
I think you just described an assert() Has this been discussed in the past? I have not seen any in the code. Dick > The really hard errors are logical > mistakes within a state transition sequence that always keeps valid > states but it does the wrong thing. Here my vote is for the most clear > and understandable representation. > > Regards > Magnus > > _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
