Dimitar Dimitrov

Thank you so much for the report. I hacked `gnuprumcu` to increase the PRU0 IMEM size, so that I can analyse your codebase. A few observations: - In `mabi=ti` mode...

> BTW: in the meantime i replaced uint64_t with uint32_t out of curiosity and the code compiles without the hack: FYI, I've been trying for a while to optimize 64-bit...

I found two inefficiencies. I'll start working on them. - https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106562 - https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106564

> And another strange observation is that -fno-inline actually shrinks codesize here (overflow is reduced from 2672 to 2276 bytes). Yes, excessive register pressure might cause that. I'll check the...

With GCC trunk [e95e91eccd](https://github.com/gcc-mirror/gcc/commit/e95e91eccd022a4a3a86da2749809fbad9afd20e), code size is down to 9352 bytes (overflow is 1160). I'm continuing the analysis for other areas to improve.

And with LTO enabled it is even better: ``` $ pru-size out/pru-core0.elf text data bss dec hex filename 8720 176 824 9720 25f8 out/pru-core0.elf ```

> Do you know an option to see the these size-statistics for the CGT-binary? i looked through the ti-docs and found nothing so far. Both CGT and GNU use ELF...

Two suggestions which would save a few more bytes: 1. You could remove `max_value` and `min_value` since those do not seem to be used. 2. It's more efficient to declare...

This unresolved middle-end issue also affects the code quality of this particular firmware program: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81357

This particular task outlines what needs to be done for these packages to be accepted into Debian mainline. It doesn't have relation to the Beagleboard Repo. Robert Nelson has merged...