The first words on your website: "Ascon is a family of lightweight cryptographic algorithms…". This includes small 8-bit systems (as witnessed by you providing the "8-bit optimized" implementations, such as opt8, bi8 and opt8_lowsize.
However, it looks to me like excessive use of forceinline hurts small systems. I looked at the opt8_lowisze implementation, which is supposed to be "8-bit size- and speed-optimized" as such, it uses forceinline less than other implementation (P is not inline), but IMO still too much (everything inside P is inline): I compiled the opt8_size implementation for STM8 using SDCC with default compiler options (SDCC by default prefers optimization for size over optimization for speed). I included both AEAD and Hash functionality, and get a code size of 0x17A9. When I selectively comment out a few forceinline, I get a code size 0x1019, i.e. a reduction by about a third, and while I haven't run any benchmarks yet, I think speed won't be affected much:
The functions where I commented out forceinline are:
INSERT, SQUEEZE, ABSORB, ENCRYPT, DECRYPT, VERIFY - since the main work is done in P, these are not the bottleneck, and their inlining can be omitted without impacting speed much.
ROUND - this is the function where the main work is done. But apart from eliminating the call overhead itself (which should be negligilble on an 8-bit system compared to all the work done inside ROUND, there is no benefit to inlining this: there also is not much optimization opportunity, since apart from RC(i), the compiler cannot precompute any of the data between rounds - doing so would essentially require the compiler to break a round of Ascon.
NONLINEAR_LAYER - the only benefit from inlining that I can see would be the potential for vectorization, by executing the loop in parallel, but 8-bit systems tend not to have vector instructions.
ROR - I'm actually unsure about this one. Here inlining would allow to compute quite some operands at compile time, potentially really speeding up the code. But the effect on code size is just too big for me (not inlining this one functions saves more code size than all the rest combined). Personally I suspect that the ROR implementation is quite specific to GCC-AVR. I'll look into alternatives, and their code size impact.
P.S.: Indeed replacing ROR by ISO C2Y stdc_rotate_right, I get code nearly as small as the noninlined ROR, and also much faster than ROR (SDCC inlines all stdc_rotate_right uses in LINEAR_LAYER).
The first words on your website: "Ascon is a family of lightweight cryptographic algorithms…". This includes small 8-bit systems (as witnessed by you providing the "8-bit optimized" implementations, such as opt8, bi8 and opt8_lowsize.
However, it looks to me like excessive use of forceinline hurts small systems. I looked at the opt8_lowisze implementation, which is supposed to be "8-bit size- and speed-optimized" as such, it uses forceinline less than other implementation (P is not inline), but IMO still too much (everything inside P is inline): I compiled the opt8_size implementation for STM8 using SDCC with default compiler options (SDCC by default prefers optimization for size over optimization for speed). I included both AEAD and Hash functionality, and get a code size of 0x17A9. When I selectively comment out a few forceinline, I get a code size 0x1019, i.e. a reduction by about a third, and while I haven't run any benchmarks yet, I think speed won't be affected much:
The functions where I commented out forceinline are:
INSERT, SQUEEZE, ABSORB, ENCRYPT, DECRYPT, VERIFY - since the main work is done in P, these are not the bottleneck, and their inlining can be omitted without impacting speed much.
ROUND - this is the function where the main work is done. But apart from eliminating the call overhead itself (which should be negligilble on an 8-bit system compared to all the work done inside ROUND, there is no benefit to inlining this: there also is not much optimization opportunity, since apart from RC(i), the compiler cannot precompute any of the data between rounds - doing so would essentially require the compiler to break a round of Ascon.
NONLINEAR_LAYER - the only benefit from inlining that I can see would be the potential for vectorization, by executing the loop in parallel, but 8-bit systems tend not to have vector instructions.
ROR - I'm actually unsure about this one. Here inlining would allow to compute quite some operands at compile time, potentially really speeding up the code. But the effect on code size is just too big for me (not inlining this one functions saves more code size than all the rest combined). Personally I suspect that the ROR implementation is quite specific to GCC-AVR. I'll look into alternatives, and their code size impact.
P.S.: Indeed replacing ROR by ISO C2Y stdc_rotate_right, I get code nearly as small as the noninlined ROR, and also much faster than ROR (SDCC inlines all stdc_rotate_right uses in LINEAR_LAYER).