On Thu, Nov 19, 2009 at 1:03 PM, Øyvind Harboe <oyvind.har...@zylin.com> wrote: > Was this for the list?
Yeah it was, that Reply-to-all button seems to be hard to find sometimes. > > On Thu, Nov 19, 2009 at 12:34 AM, Andreas Fritiofson > <andreas.fritiof...@gmail.com> wrote: >> On Wed, Nov 18, 2009 at 9:40 AM, Øyvind Harboe <oyvind.har...@zylin.com> >> wrote: >>> On Wed, Nov 18, 2009 at 9:38 AM, Laurent Gauch >>> <laurent.ga...@amontec.com> wrote: >>>>> >>>>> I'm pondering how we could gently in a series of >>>>> non-breaking patches prepare the ground for switching from >>>>> 8 to 32 bit words in the jtag_add_xxx API. >>>>> >>>>> The attached patch gets rid of buf_set_u32() when setting >>>>> the value of a byte. >>>>> >>>>> This achieves two things: the code is less obtuse and it >>>>> is more evident how we could introduce a new type >>>>> that is *currently* uint8_t and later on could be increased to >>>>> uint32_t or wider, for the out_value/in_value bit vectors. >>>>> >>>>> Comments? Protests? >>>> >>>> JTAG serial link itself has a notion of bits and not bytes nor dwords ... >>>> >>>> I do not understand what is the advantage to work on 32bit buffers >>>> instead 8bit buffers for out_value and in_value. >>>> Why the code will be less obtuse use 32bit buffer instead 8 bit buffers ? >>> >>> Look at all the buf_set_u32()'s sprinkled around the code. They are >>> essentially >>> unnecessary. >>> >>> The drivers probably wouldn't change. >> >> I don't see the point in deciding on a specific width of the storage >> unit. The JTAG layer (should?) handle bit strings of arbitrary >> lenghts, so why not abstract away how the bit strings are stored >> internally? Some time ago someone (David?) suggested we borrow/build >> on the bitmap facility from Linux. I remember someone had strong >> opinions against it, don't remember why. I myself think it's a good >> idea to migrate towards a similar solution rather than switching from >> one arbitrary, fixed width to another. >> >> As a side note, the Linux' bitmap implementation actually uses >> 'unsigned long' as storage, so if using 32 bits is your design >> requirement you'll get it on at least some platforms. :) >> _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
