modulo and frame number in mframe_sched.c

This is merely a historical archive of years 2008-2021, before the migration to mailman3.

A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/baseband-devel@lists.osmocom.org/.

Harald Welte laforge at gnumonks.org
Thu Oct 18 10:15:28 UTC 2012


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 <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)




More information about the baseband-devel mailing list