uECC_OPTIMIZATION_LEVEL=4 breaks uECC_sign()/uECC_verify() on atmega328p

[gitcnd]

test/test_ecdsa.c WORKS with this:- #define uECC_OPTIMIZATION_LEVEL 2

but FAILS with this:- #define uECC_OPTIMIZATION_LEVEL 4

[L1uTongweiNewAccount]

I found a truth when I was viewing asm_avr.inc:255 and asm_avr_mult_square.inc.

The truth is: you write a loooooong asm like FAST_MULT_ASM_<BITS>.

I really feel curious about this, and why? My compiler (avr-gcc 13.2.0) tell me that size of string literal is too large.

[L1uTongweiNewAccount]

Issue #50 is where asm_avr.inc:255 and asm_avr_mult_square.inc from. It referred to a method to optimize the performance.

But @kmackay are you tested this? Maybe it is a issue of avr-gcc?

We need a method to let the compiler accept the looooong inline-asm string literal.

[L1uTongweiNewAccount]

Well, #50 's method is so STUPID. No compiler can accept so huge codes. I'm trying to reoptimize these code.

[WestfW]

i think (assembler) macros could fix this.

[L1uTongweiNewAccount]

i think (assembler) macros could fix this.

Yes, i think so. But GCC inline assembler cannot compute the real size of the assemble. (See at GCC document)

But if we ignore this, can you fix it with assembler macros?

[L1uTongweiNewAccount]

i think (assembler) macros could fix this.

Subroutine may works, i think

[L1uTongweiNewAccount]

i think (assembler) macros could fix this.

I found something: the asm are be divided by some subprocess.

Maybe we can define many function to reduce single string literal.

[L1uTongweiNewAccount]

i think (assembler) macros could fix this.

Fixed. But I think the performance will reduce a little and the code is huge like the past.

The code is in https://github.com/L1uTongweiNewAccount/micro-ecc

see asm_avr.inc and asm_avr_mult_square.inc

I did not tested this so be careful.

[L1uTongweiNewAccount]

#224 I opened a PR. see this