Re: [lwip-users] alignment problems

[Bartlomiej Wicher]

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),
doesn't it mean that alignment should be 2?

> > 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.

> > Finally - do I have to make any changes in the original LWIP source code
> > due to my my architecture?
>
> I'm concerned that you say that "two addresses" are only used with long,
> and one for both char and int. Does this mean that for:
> char foo[4];
> that: &foo[0] == &foo[1] ?
> If that is the case, I think you may have an uphill struggle.


Yes, that what it means. I'm not sure if it's compiler feature, but in  
previous version of the microcontroller I used (56800 core), it wouldn't  
be true.
Each char had it's own memory address and size of foo would be 4 words (8  
bytes). "Packing" of char arrays was
intoduced in a new core (used by me) - 56800E. Here, size of foo is 2  
words (4 bytes). Each address points to a 16-bit word, not a byte like in  
standard byte-addressable processors.
See the pseudo memory map below:

char foo[4] = {0x12, 0x34, 0x56, 0};
// Assuming that address of foo is 0x0666, the memory in address 0x0666  
will be following
// address:     content:
// 0x0666       0x1234
// 0x0667       0x5600


int x = 0xabcd;
// one int is two bytes.
// Assuming that address of x is 0x0666, the memory in address 0x0666 will  
be following
// address:     content:
// 0x0666       0xabcd

char x = 0xab;
// one char is one byte.
// Assuming that address of x is 0x0666, the memory in address 0x0666 will  
be following
// address:     content:
// 0x0666       0x00ab

long x = 0xabcdef12;
// one long is 4 bytes.
// Assuming that address of x is 0x0666, the memory in address 0x0666 will  
be following
// address:     content:
// 0x0666       0xabcd
// 0x0667       0xef12

I guess that it would be a problem only in a case of char arrays. I really  
don't feel like changing the whole code of LWIP. 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...





> Jifl



--
Bartlomiej Wicher
Newtec A/S
Odense, Denmark