On Thu, 2009-10-08 at 18:00 +0200, Alessandro Rubini wrote: > > No interest in the suggestion to not require count to be an exact > > multiple of 4/8? > > Actually, I wrote about that in my patch 0/3.
Sorry, I should have read more thoroughly. > > I don't think it would be that hard to update the logic accordingly > > and this would let your code be utilized much more often, especially > > if/when we run on a 64-bit machine. > > That's true, but I think the most important case is lcd scrolling, > where it's usually a big power of two -- that's where we had the #ifdef, > so the problem was known, I suppose. I think the most important case for *you* is lcd scrolling, but for 99% of everyone else, it isn't at all:) memcpy() and memset() are used 100 times more often in non-lcd related code and most boards don't even have LCDs. In my opinion, we shouldn't be fixing/bloating common code for 1 outlying scenario, we should be trying to improve it for common cases. > Currently, I don't even know if this is going to be picked up, so I > don't want to go too far -- and in that case I would like to measure > things and be able to test for stupid bugs, so it takes time. Sure, I understand where you're coming from. FWIW, if people don't want to pick this up as it affects lots of people, you could always add an architecture-specific memcpy/memset implementation. > If there's interest, there's memmov to fix; it's used pretty often and > it's the same idea as memcpy (well, scrolling should use memmove, > in theory). I'll quit pestering, just wanted to put my $.02 in:) Best, Peter _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
