Hi Bruce Yeah... but this STm32 M4 is nothing like that in the cache department.
The FLASH is 128 bits wide.... the system takes BIG gulps per cycle. worst case is a 6 cycle miss. The instruction prefetcher holds the instruction pipeline full to the brim. Until you get a decent sized branch of course. There is also the ICEN and DCEN bits. (search for it in the manual) . You can control the loss during jumps. The current code might run better or worse with the ICEN/DCEN bits enabled /disabled.dunno data cache is 8 rows of 128 bits, so that can fit quite a few variables. maybe use the tables such that each access brings a little more of the next into cache (to avoid the 6 cycle hit) as ti keep the Dcache fresh. getting a bit off topic...those interested should refer to : "3 Embedded Flash memory interface" in the manual RM0090 particularly- figure 3. g On 29/07/2015 2:38 PM, Bruce Perens wrote: > For cache optimization you have to consider the line size, the cache > line hashing scheme, and how many lines match the same hash. The > classic example is doing three-operand array processing using cache > aligned buffers, with two-way set-associative caching. You end up with > a flush and load per operation. This used to hit us with SGI > workstations using MIPS processors. > > On Tue, Jul 28, 2015 at 7:15 PM, Steve <[email protected]> wrote: >> Yes, the frame of data. kissfft uses one array for input, and another for >> output, but if I recall, the input is never used. Although, I'm sure that >> gives it a speed advantage. Anyway, it will be used on the next pass :-) >> >> I used the code from JTransforms, where the internal tables are about 2K so >> not much advantage there, but I'm sure ARM has optimized memory code. >> >> ------------------------------------------------------------------------------ >> >> _______________________________________________ >> Freetel-codec2 mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/freetel-codec2 >> > ------------------------------------------------------------------------------ > _______________________________________________ > Freetel-codec2 mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/freetel-codec2 > -- - Glen English RF Communications and Electronics Engineer CORTEX RF & Pacific Media Technologies Pty Ltd ABN 40 075 532 008 PO Box 5231 Lyneham ACT 2602, Australia. au mobile : +61 (0)418 975077 ------------------------------------------------------------------------------ _______________________________________________ Freetel-codec2 mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freetel-codec2
