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 Michael Schwingen wrote: > Dick Hollenbeck wrote: > >> I nak the arrays. I hate them, they are a crash waiting to happen. >> >> > Why? > > >> Put the same logic into a series of switches please, nested if necessary. >> >> Switches reads better, and are less subject to breakage. We just >> changes the values of the #defines in the last 10 minutes, this kind of >> change breaks these tables in the future. >> >> > That could be worked around by using C99 initializers. I am not fond of > replacing a small amount of static data with a bigger chunk of code. > > cu > Michael > > _______________________________________________ > Openocd-development mailing list > Openocd-development@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/openocd-development > _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
