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

[Grubb, Jared]

According to the ARMARM (pg A4-113), LDRB is present in v3 (LDRH was added in 
v4). I use a ARM7TDMI, so I have no direct knowledge of anything!=v4, so I can 
just say what the ARMARM says.

You're right about your byte/char statement; I should've said "minimal unit 
addressable in the language" not architecture.

Out of curiousity, what is the processor that your friend is using? (If you can 
say)

Jared

-----Original Message-----
From: address@hidden [mailto:address@hidden On Behalf Of Jonathan Larmour
Sent: Tuesday, September 02, 2008 14:34
To: Mailing list for lwIP users
Subject: Re: [lwip-users] Problem With dns.c Using 32-Bit Compilers

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
--
eCosCentric Limited      http://www.eCosCentric.com/     The eCos experts
Barnwell House, Barnwell Drive, Cambridge, UK.       Tel: +44 1223 245571
Registered in England and Wales: Reg No 4422071.
------["The best things in life aren't things."]------      Opinions==mine


_______________________________________________
lwip-users mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/lwip-users