[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: SPAM? Re: [lwip-users] about alignment issues.
From: |
Jan Ulvesten |
Subject: |
RE: SPAM? Re: [lwip-users] about alignment issues. |
Date: |
Thu, 20 Apr 2006 11:29:14 +0200 |
>From Alteras lwIP port:
static u8_t ip_reassbuf[IP_HLEN + IP_REASS_BUFSIZE] __attribute__
((aligned (MEM_ALIGNMENT)));
Memory alignment can be forced on specific variables, at least for GNU
compilers. I guess other compilers have a similar syntax?
Why not use that like below?
#define MEM_ALIGNMENT_DIRECTIVE __attribute__ ((aligned
(MEM_ALIGNMENT)));
static u8_t ip_reassbuf[IP_HLEN + IP_REASS_BUFSIZE]
MEM_ALIGNMENT_DIRECTIVE;
MEM _ALIGNMENT_DIRECTIVE can be blank if not supported.
There are 5 places in the code where memory alignment has been included
in the definition in my source.
static u8_t ip_reassbuf...
static u8_t ip_reassbitmap....
static u8_t buf....
static u8_t ram....
static u8_t pbuf_pool_memory....
Jan Ulvesten
Senior Software Engineer
SICOM AS
Tel +47 72 89 56 55
Fax +47 72 89 56 51
Mob +47 416 62 033
-----Original Message-----
From: Pedro Alves [mailto:address@hidden
Sent: 17. april 2006 14:26
To: Mailing list for lwIP users
Subject: SPAM? Re: [lwip-users] about alignment issues.
Derek Guerdon wrote:
>On Fri, 14 Apr 2006 09:30:46 -0700, Curt McDowell wrote:
>
>
>>Still, a union is not called for:
>>
>>struct {
>> struct pbuf pbuf;
>> u64_t payload[MEM_ALIGN_SIZE(PBUF_POOL_BUFSIZE) / sizeof(u64_t)];
>>} pbuf_pool_memory[PBUF_POOL_SIZE];
>>
>>Or, if it's more pleasing, we could define a "maximal" type somewhere
>>and use that for payload[]. "struct mem" does that in mem.c, except
it
>>should be defined in a header file to clean it up.
>>
>>
>
>I think the latter is preferable for three reasons. First, even u64_t
>isn't required to be maximally aligned under ANSI-C (although in
>practice I've never seen a case where it wasn't). Second, there are
>some compilers without native unsigned 64-bit integer. Third,
>allocating an array of 'memory aligned types' allows targets with
>limited memory to avoid allocating unused memory.
>
>The declaration needs to be reworked a bit as the one given won't
>allocate enough space when MEM_ALIGNMENT is less than 8 (e.g. if
>MEM_ALIGNMENT is 4 and PBUF_POOL_SIZE is 1540, only 1536 bytes are
>allocated in payload).
>
>Something along these lines should work:
>MAX_ALIGN_T
>payload[(PBUF_POOL_BUFSIZE+sizeof(MAX_ALIGN_T)-1)/sizeof(MAX_ALIGN_T)];
>
>
>I'd like to offer my thanks to you for addressing these issues. I
>think they consumed the majority of the time I spent porting lwIP.
>Getting the alignment issues fixed will be a major improvement to the
>code base.
>
>
Although I don't belong to the "unions are ugly school", I'm ok with a
solution like this.
Actually, I think that flattening the pool some more would be even
better.
static struct pbuf mem[PBUF_POOL_SIZE];
typedef u32_t MAX_ALIGN_T;
typedef MAX_ALIGN_T
pbuf_pool_payload_t[(PBUF_POOL_BUFSIZE+sizeof(MAX_ALIGN_T)-1)/sizeof(MAX
_ALIGN_T)];
pbuf_pool_payload_t pbuf_pool_payload[PBUF_POOL_SIZE];
void
pbuf_init_dummy_just_to_show(void)
{
int i;
for(i = 0; i < PBUF_POOL_SIZE; ++i) {
mem[i].next = mem[i+1].next;
mem[i].len = mem[i].tot_len = sizeof(pbuf_pool_payload_t);
mem[i].payload = pbuf_pool_payload[i];
mem[i].flags = PBUF_FLAG_POOL;
}
}
_______________________________________________
lwip-users mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/lwip-users
- RE: SPAM? Re: [lwip-users] about alignment issues.,
Jan Ulvesten <=