On Sunday 14 June 2009, Øyvind Harboe wrote: > my whole idea with using 32 bit sizes was that *no* bit array > library would be needed....
Maybe call it a "bignum" package then? Without things like modular exponentiation. Or addition. Or ... ;) My model is that a DR or IR scan is basically working with a bit array ... the TDI bits were likely constructed from a bunch of fields, and the TDO bits will likely then need to be split into fields. Some of those fields will be more than 32 bits long. So it feels to me like decent bit array tools should be the guts of the data manipulation parts of JTAG code. Maybe fancy tools that support fragmented arrays, or maybe simpler ones. > I don't think there are *any* places in OpenOCD where bit array > code is needed or even particularly convenient if we had 32 > bit sizes. Today that might be true. But ... boundary scan registers routinely take several hundred bits. Other data registers do too. And there are even instruction registers that take more than 32 bits. (Those DSPs with 38 bit IRs, and 46 bits in newer siblings, are examples.) > My only (slight) concern with 32 bit would be that perhaps 64 > bit targets(a looong way off) would be better off w/64 bit > sizes, though creating some JTAG helper fn's on top of a 32 > bit API would be easy peasy. Why not just have an interface that doesn't *care* what word size applies underneath? Settling on 32 is better than settling on 8 ... but specifying 32 is not necessary. Such things tend to cause needless trouble over time. - Dave _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
