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. 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 Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
