I've tested Jonathan's patch for dns.c on our port of lwIP for a TI 6711
DSP and it seems to work correctly.
This would be one less file that we need to modify in order to use lwIP
with this family of processors. As has been discussed on several
previous occasions, the compiler for these DSP's does not support
#pragma PACK, or any misaligned access of data. Actually, the DSP
itself does not allow unaligned access... even via a debugger you cannot
access an integer on an odd byte boundary. It seems TI could work
around this in the compiler (copy the data to a register, operate on it,
copy it back), but they have so far refused to do so, citing complexity
and performance issues.
However, with a little care in our driver to assure that incoming
packets are aligned properly, this was actually the only file that was
causing us trouble due to alignment issues. Obviously, over time people
have taken care to not introduce code that depended on the compiler
packing data properly, and that has been a huge advantage for us, and
one of the reasons we use lwIP with our family of products.
So it seems to me that there isn't additional work involved to make lwIP
friendly to these TI platforms (and possibly some older ARMs and other
processors that can't access 4-byte values at arbitrary addresses). It
just takes the developers of any new code to keep in mind that there are
such platforms out there and to continue to write code that doesn't rely
on structure packing or overlays of structures onto byte buffers.
John Keil
Critical Link, LLC
Jonathan Larmour wrote:
Bill Auerbach wrote:
I'm not sure which ARM processor you're referring to, but that can't
actually be true.
On the contrary, the LDRB instruction only appeared in the ARMV4T
architecture. There are still simple small ARM7 variants with cores
like ARM7DI, ARM720, etc. floating around, which do no support LDRB.
By definition in the C standard, every compiler is
guaranteed to have byte access anywhere it wants (IIRC, a byte is
defined as the minimal unit addressable on the architecture).
As Bill noted "byte"->"char" really. But even then, a compiler may say
that chars are 8-bits, however the minimum addressable unit for an
architecture can be something else, e.g. a 32-bit word. There's a
difference between what the compiler does and what the processor
accepts. It is then up to the compiler to load a word and mask off the
relevant bits to get a byte.
Are there really any processors in the last 10-20 years that didn't have
bytes that are 8-bits?
Yes. Someone I know is using one right now, and it was released only a
few years ago.
To be semantically correct, C defines char (not byte). Sizeof char is
always 1, and if bytes have 8-bits, then the compiler is guaranteed
to load
chars as you stated. Then it follows that macros are possible that do 2
char accesses. The macros I posted that do this work - they do 2
separate
byte reads and form the final int. This should work everywhere.
(Apart from the pointer aliasing issue I mentioned).
Despite all the chatter, I note that no-one seems bothered enough to
confirm whether or not the patch I suggested for the specific issue
with dns.c works!
Jifl
_______________________________________________
lwip-users mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/lwip-users
