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