Subject: Mail delivery failed: returning message to sender
From: Mail Delivery System <[email-masked]>
To: [email-masked]
Date: Thu, 18 Oct 2012 13:15:34 +0200

This message was created automatically by mail delivery software.

A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:

  [email-masked]
    retry timeout exceeded

------ This is a copy of the message, including all the headers. ------

Date: Thu, 18 Oct 2012 12:15:28 +0200
From: Harald Welte <[email-masked]>
To: =?utf-8?B?4piO?= <[email-masked]>
Subject: Re: modulo and frame number in mframe_sched.c
Cc: Baseband Devel <[email-masked]>
Sender: [email-masked]

Hi Max,

On Wed, Oct 17, 2012 at 08:21:59PM +0200, ��� wrote:

> In "struct mframe_sched_item" in target/firmware/layer1/mframe_sched.c
> both 'modulo' and 'frame_nr' defined as uint16_t. This seems like big
> space waste considering tight memory environment we're working in.

On ARM, it doesn't matter.  even if you made those fields uint8_t
in the struct mframe_sched_item, they would still be aligned to 32bit
boundaries.  So you wouldn't change the memory layout at all based on
your change.

If you really wanted to save memory, then you would have to make the
struct packed.  This in turn would mean that accesses to the structure
members would be unaligned accesses, around which the compiler has to
work around by bit-shifting.

So you save some memory at the expense of increasing code size (and
execution time).

Given that the CPU speed is more limited than RAM, I think the current
approach makes sense.

> Does structure alignment matters in this case? If so - how exactly?

see above.

> Is it possible for 'modulo' to be bigger than 255?

I don't think so, at least not for standard GSM operation.

> Is it possible for 'frame_nr' to be bigger than 255?

frame_nr can never be bigger than 'modulo'.

-- 
- Harald Welte <[email-masked]>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)