lwip-users
[Top][All Lists]
Advanced

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

Re: [lwip-users] alignment problems


From: Jonathan Larmour
Subject: Re: [lwip-users] alignment problems
Date: Thu, 08 Nov 2007 12:34:17 +0000
User-agent: Thunderbird 1.5.0.12 (X11/20070530)

Bartlomiej Wicher wrote:
> 
> Thanks for your response.
> 
>>> I am a newbie in LWIP and it's my first post to this list. I'm trying to
>>> use LWIP with Freescale DSP568366. I have some problems with value of
>>> MEM_ALIGNMENT. Normally microprocessor are 8-bit addressable,  but the
>>> DSP568366 is word-addressable (16-bits). It means that each address of
>>> memory stores dwo bytes. Moreover:
>>>
>>> + Size of char is 1 byte - it is stored in one word (one address used)
>>> + Size of int is 2 bytes - it is also stored in one word
>>> + Size of long is 4 bytes - it is stored in two words (two addresses
>>> involved)
>>> + An array of chars is "packed" automatically by the microcontroller, so
>>> that 2 consecutive chars are stored in one word.
>>>
>>> What value of MEM_ALIGNMENT should I use?
>>
>> Probably 2. Although it would be 4 if your longs must be aligned on a
>> 2-word boundary. Or it might need to more if there are any other
>> fundamental types that have stronger alignment requirements.
> 
> Long is the biggest fundamental type in my case (no long longs available).
> Longs must be aligned to 2-word boundary (since one word is 16 bits and
> long is 32),

Note that that doesn't necessarily followed from the size. For example,
there are several 32-bit processors that don't require 32-bit alignment of
all quantities.

> doesn't it mean that alignment should be 2?

Given what you say further below, in that case yes.

>>> Can I use LWIP memory
>>> functinos (mem_malloc() etc) without any changes in their original
>>> source code, or should I use the stdio mem functions (malloc() etc)?
>>
>> You can always choose to use the standard malloc() etc. if you want to
>> anyway, although if you weren't going to use it otherwise, it might
>> result
>> in smaller code not to, because some malloc()s are quite heavyweight. I
>> don't think the mem_alloc() etc. code is likely to more of a problem than
>> any other part of lwIP....
> 
> I was checking the amount of memory consumed by mem_malloc() for 10
> longs with
> alignment = 2. It was almost twice as big as it should (37 words vs 20
> words).
> Probably it's becaue my microcontroller is word-addressable.

Sure - but as I said the mem_alloc is not likely to be any worse than the
rest of lwIP, which you can interpret as meaning the rest of lwIP is going
to have problems too.

The underlying problem is that your environment is not ANSI/ISO C
compatible. ISO C says "It shall be possible to express the address of each
individual byte of an object uniquely" (s3.4).

Although even if, as Kieran said, you can make the environment be one where
you are using 16-bit bytes, then you still may not be happy, as there will
be lots of wasted space (and no doubt lwIP will still have some, albeit
fewer, problems to fix).

> I guess that it would be a problem only in a case of char arrays.

Or char pointers. The problem is that there are many of those!

> I really don't feel like changing the whole code of LWIP.

You may want to consider looking at uIP. It's possible that may cater
better for your requirements: http://www.sics.se/~adam/uip/index.php/Main_Page

> I guess that
> simply changing the char arrays to word (int) arrays would help only in
> a case if you don't perform char* to int* conversions. Do you think that
> defining u8_t and s8_t as word (int) could help? That would increase the
> memory consumption, but it's not crutial for me right now...

It might help. Although I'm sure there would still be quite a few changes
required in lwIP.

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.
------["Si fractum non sit, noli id reficere"]------       Opinions==mine




reply via email to

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