It's interesting to consider locality-of-reference. It's an even worse
problem on VM systems, because there is paging and the translation
look-aside buffer. But it exists on embedded systems because they have
cache. Small data really belong on the stack (if they're not in a register)
because you can assume that the top of the stack is cached at all times.
Then you get this important statement about STM32F7:
The L1-caches on all Cortex®-M7s are divided into lines of 32 bytes. Each
line is tagged with an address. The data cache is 4-way set associative
(four lines per set) and the instruction cache is 2-way set associative.
This is a hardware compromise to keep from having to tag each line with an
address.
The important issue here is that cache lines are selected using the lower
bits of the address. Since the data cache is 4-way, if you have a 5-opcode
operation with the lower bits of the opcode addresses all aligned with each
other, the cache will flush and reload for every operation.
MIPS used to have a 2-way data cache, which flushed when three-opcode
operations (very common) had their opcodes aligned on page addresses (very
easy to do).
TCM on the Cortex M0 doesn't use the cache.
Thanks
Bruce
On Mon, Jun 11, 2018 at 9:22 AM, Jeroen Vreeken <jer...@vreeken.net> wrote:
> To make matters worse:
> - It is harder to know your total memory usage if you have more on the
> stack: it just magically goes down and overwrites whatever is already
> there. A malloc atleast has a way of signalling failure: the NULL pointer
> - On systems with caches (e.g. the cortex M7 in the ATSAME70 I currently
> use) your timing will get less predictable as you might get different
> timing for the same functions depending on wherever you stack pointer
> happened to be. (Also think about where your stack will be during an
> interrupt)
>
>
>
> On 06/11/2018 05:41 PM, Bruce Perens wrote:
>
> Hi Sumek,
>
> Codec2 for embedded platforms is definitely in need of size optimization
> by *removing unused code for your chosen modes,* and speed optimization
> by *optimizing the floating-point calculation.*
>
> I think you might be wasting your time by pursuing structure and malloc()
> optimizations, though. Consider what happens when you remove malloc and
> place a variable on the stack. Instead of indexing through the heap
> pointer, you are indexing through the stack pointer. You don't see the
> stack pointer in the C code, but it's there. The instructions will probably
> be very similar, especially on ARM, you can check this using the -S flag of
> the compiler. When optimizing, *always* use -S to look at the
> instructions generated by the compiler, this will show when an optimization
> is *really* an optimization.
>
> Similarly, removing a struct and using a local variable would still index
> through the stack pointer.
>
> The second problem with removing malloc() and structs is that it makes it
> less likely that your work could be returned to David's codec2 sources.
>
> Thanks
>
> Bruce
>
> On Mon, Jun 11, 2018 at 1:00 AM, sumek.wi via Freetel-codec2 <
> freetel-codec2@lists.sourceforge.net> wrote:
>
>> Hi,
>>
>>
>> The reduced I said is program size. Also, I removed malloc and struct to
>> make the program
>>
>> as simple as possible for embedded systems, and it also reduce the
>> execute time by not
>>
>> indexing pointer.
>>
>>
>> I used gcc on CodeLite, I don't know why it doesn't remove unreferenced
>> much. Probably
>>
>> it is in debug mode.
>>
>>
>> Sumek.
>> ------------------------------
>> *From:* Danilo Beuche <danilo.beu...@gmx.net>
>> *Sent:* Monday, June 11, 2018 12:06:54 PM
>> *To:* freetel-codec2@lists.sourceforge.net
>> *Subject:* Re: [Freetel-codec2] noob in voice coding asking for help
>> about Codec2 decoder.
>>
>>
>> Hi,
>>
>> btw, using the gcc's -flto during compiling and linking does a great job
>> of removing unused data and functions. Basically the gcc breaks up every
>> file into individual linkable elements (each global variable and functions
>> becomes an independent linkage element) and anything not referenced
>> anywhere simply disappears from the final binary. Of course there is a lot
>> more going on with -flto (LTO stands for link time optimization) but one of
>> the side effects of using LTO is this removal of unreferenced elements from
>> binary code.
>>
>> Other compilers have similar "tricks".
>> Regards,
>> Danilo
>>
>> On 11.06.2018 03:19, Bruce Perens wrote:
>>
>> Hi Sumek,
>>
>> I am curious about your memory saving strategy. Specifically, why using
>> the stack vs. malloc() would result in a significant memory savings, and
>> how removing structs would result in a significant memory savings.
>>
>> Perhaps you mean you are removing *unused *ones?
>>
>> Or is there something about the Windows compiler I don't understand?
>>
>> Thanks
>>
>> Bruce
>>
>> On Sun, Jun 10, 2018 at 1:40 PM, David Rowe <da...@rowetel.com> wrote:
>>
>> Hi Sumek,
>>
>> Oh I have one question, do you know if we can reduce the size of codebook
>> especially lsp_cbjvm
>>
>>
>> Many of those tables aren't used, so just link in the ones you need to
>> support the Codec 2 modes you would like to use.
>>
>> Cheers,
>>
>> David
>>
>>
>> ------------------------------------------------------------
>> ------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> Freetel-codec2 mailing list
>> Freetel-codec2@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/freetel-codec2
>>
>>
>>
>>
>> --
>> Bruce Perens K6BP - CEO, Legal Engineering
>> Standards committee chair, license review committee member, co-founder,
>> Open Source Initiative
>> President, Open Research Institute; Board Member, Fashion Freedom
>> Initiative.
>>
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>
>>
>>
>> _______________________________________________
>> Freetel-codec2 mailing
>> listFreetel-codec2@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/freetel-codec2
>>
>>
>>
>> ------------------------------------------------------------
>> ------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> Freetel-codec2 mailing list
>> Freetel-codec2@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/freetel-codec2
>>
>>
>
>
> --
> Bruce Perens K6BP - CEO, Legal Engineering
> Standards committee chair, license review committee member, co-founder,
> Open Source Initiative
> President, Open Research Institute; Board Member, Fashion Freedom
> Initiative.
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>
>
>
> _______________________________________________
> Freetel-codec2 mailing
> listFreetel-codec2@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/freetel-codec2
>
>
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Freetel-codec2 mailing list
> Freetel-codec2@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freetel-codec2
>
>
--
Bruce Perens K6BP - CEO, Legal Engineering
Standards committee chair, license review committee member, co-founder,
Open Source Initiative
President, Open Research Institute; Board Member, Fashion Freedom
Initiative.
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2
