On Sunday 14 June 2009, Øyvind Harboe wrote:
> >> I'd like to see the JTAG API use 32 bit instead of 8 bit for the
> >> bit arrays(post 0.2).
> >
> > 32 is better than 8 here, yes.
> >
> > If you'd consider using "unsigned long" (which might be 64 bits
> > on some hardware) there's a lot of *nice* bit array code that
> > could be imported from Linux. Including even arch-specific
> > speedups...
>
> Tell me more about how this would look and what dependencies,
> if any, that we would need.
Most of it is header magic, there's not a lot of C code.
I would imagine a new src/include directory, plus some
solution for arch-specific stuff either mirroring what
Linux does today (src/arch/include) or what it did before
(src/include/asm-$arch symlinked at setup to include/asm).
Process-wise, it would be grabbing a snapshot and trimming
it down to fit. Probably limiting license to "GPLv2-only".
Or, just use it as a model, to avoid reinventing too much.
That code is very portable, and AFAIK more efficient than
what OpenOCD uses today. It wraps a lot of good design work.
But, probably more than what OpenOCD needs.
Things I like about it compared to currrent OpenOCD: it
is explicit about big vs little vs host endianness; it
doesn't rely on unaligned accesses all over; it handles
both little (one-long) and big (N-long) bit arrays with
the same code; it uses the ASM ops that GCC won't; etc.
> For embedded hosts/windows, I'd like avoid
> depending on lots of libraries...
It's not a library, just a bunch of code used all over
the kernel.
Grab a copy of the 2.6.30 kernel, then start with
include/linux/
bitmap.h
bitops.h
bitrev.h
byteorder/*
include/asm-generic/
bitops.h
bitops/*
lib/bitmap.c
lib/bitop.c
and arch-optimized versions in e.g.
arch/{x86,arm,ppc,...}/include/asm/
bitops.h
byteorder.h
There's stuff that would not be wanted, like the ext2 bitops.
_______________________________________________
Openocd-development mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/openocd-development
