Re: [lwip-users] Problem With dns.c Using 32-Bit Compilers

[John Keil]

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