lwip-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[lwip-users] Re: [lwip] Anyone Using An Architecture That Isn't little


From: Kenneth Porter
Subject: [lwip-users] Re: [lwip] Anyone Using An Architecture That Isn't little or big endian?
Date: Thu, 09 Jan 2003 01:04:04 -0000

On Mon, 2002-08-19 at 12:04, John C. Toman wrote:

> The one drawback I can see to this approach is if there are other 
> architectures that store bytes differently than little or big endian, 
> they would need to come up with their own constants that represent the 
> network-storage format on their systems ...

I haven't started to look at the source, but I do want to point out the
architecture I'd like to use it on, and it's quite different from an
endian architecture.

I want to use a 32-bit DSP. The chip, an Analog Devices SHARC, uses a
uniform 32-bit word. There are no "bytes". The C char and short are both
32 bits, ie. the same size as a long. If you increment a pointer to
long, the underlying machine adds one to the pointer register, not 4.

I understand that there's already code in lwIP to deal with 16-bit DSP's
with a similar characteristic, expect it will be straightforward to
extend this to a 32-bit DSP.

Using a MAC with an 8-bit bus interface, packets will be dropped into
memory one byte per machine word. I haven't shopped for a MAC yet, so I
don't know what other bus interfaces are common.

BTW, when porting some 80186 C code to the SHARC, the one idiom that was
most insidious was the use of a cast to char to mask a quantity to 8
bits. The expression "(char)n" does no masking on the SHARC. To work
around this, I defined a macro, MASK_TO_8_BITS(n), which does a cast on
byte-addressable architectures and performs a bit-masking operation (ie.
"((n) & 0xFF)") on the SHARC.

[This message was sent through the lwip discussion list.]




reply via email to

[Prev in Thread] Current Thread [Next in Thread]