I'm pretty much trying to get transaction signing to run on STM32 to see if I can do it. So for now all I need is less than 1k for UART communication code. If I get it working, I'll probably order a larger chip with USB capability and make a hardware wallet.
I'm certainly willing to test what I can, writing a script to feed in values over serial and check the output against the PC should be easy enough. Modifying bench.h to use hardware timers shouldn't be difficult either.
Topic: Compiling secp256k1 without makefile (Read 1662 times)
The ones I have are 32k flash. I could always go to a bigger chip, but I have a bunch of these from another project laying around, so it's convenient for testing. Are these planned features for the library? I wouldn't want to ask you to do any extra work, since this is more likely gonna end up as a one-off experiment than anything else.
They're planned eventual features and the lowmem table is stuff already implemented but not merge ready yet. Our priority for working on low-mem optimization is boosted if someone is around to test and say if it actually works (and perhaps get benchmark numbers). Some of the memory optimizations improve performance for all hosts anyways (e.g. the "compact storage type" code that was merged last night.)The more immediate issue is that with 32k flash we'll need a code size reduction in addition to the table size reduction. 30k alone is used right now in the binary compiled for x86 is used for the unrolled sha256 implementation. We can have a lowmem compile switch to a looping implementation and such. How much do you have free on the flash (e.g. how small does the code need to be?) that you could realistically use and have enough free to do something useful with it?
Yep, the only thing I really need is signing. The chip I have on hand for testing only has 4k RAM, so 1024 should work. I could squeeze up to 2048 if there's significant performance improvement.
You have 4k RAM but I assume a fair bit more more memory addressable flash?Some of the pre-work for lowmem turns most of the data into const static RO data.
The existing table will be 64kb of static data, and the low mem version will likely be 1kb and about 17% slower.
If you do have a large amount of memory mapped flash, then even the big table would likely work for you. If you don't then code size is likely going to be an issue, even with the smaller tables. Though low mem will also reduce the codesize once we get around to that. (Right now secp256k1 has several special case implementations of various parts which could just be use the most general implementation when complied with lowmem, for a few percent performance hit).
How much read only memory do you have for const static tables / code?
The ones I have are 32k flash. I could always go to a bigger chip, but I have a bunch of these from another project laying around, so it's convenient for testing. Are these planned features for the library? I wouldn't want to ask you to do any extra work, since this is more likely gonna end up as a one-off experiment than anything else.
Yep, the only thing I really need is signing. The chip I have on hand for testing only has 4k RAM, so 1024 should work. I could squeeze up to 2048 if there's significant performance improvement.
You have 4k RAM but I assume a fair bit more more memory addressable flash?Some of the pre-work for lowmem turns most of the data into const static RO data.
The existing table will be 64kb of static data, and the low mem version will likely be 1kb and about 17% slower.
If you do have a large amount of memory mapped flash, then even the big table would likely work for you. If you don't then code size is likely going to be an issue, even with the smaller tables. Though low mem will also reduce the codesize once we get around to that. (Right now secp256k1 has several special case implementations of various parts which could just be use the most general implementation when complied with lowmem, for a few percent performance hit).
How much read only memory do you have for const static tables / code?
Yep, the only thing I really need is signing. The chip I have on hand for testing only has 4k RAM, so 1024 should work. I could squeeze up to 2048 if there's significant performance improvement.
The memory is mostly taken by the pre calculated multiples of G. You can reduce that by choosing a smaller window in the WNAF decomposition.
I'd bet his interest is in signing, which doesn't use WNAF. 
Thanks, took me a while to wrap my head around all the config options, but I finally got it to build in EWARM 
Edit: well, all that for nothing... memory usage is way too high for the chip I was trying to run it on.
The memory is mostly taken by the pre calculated multiples of G. You can reduce that by choosing a smaller window in the WNAF decomposition. Edit: well, all that for nothing... memory usage is way too high for the chip I was trying to run it on.
Thanks, took me a while to wrap my head around all the config options, but I finally got it to build in EWARM
Edit: well, all that for nothing... memory usage is way too high for the chip I was trying to run it on.
It's trivial to reduce the memory usage to whatever level is needed. Whats your target?Edit: well, all that for nothing... memory usage is way too high for the chip I was trying to run it on.
Pieter and I have been working on low-mem signing (trying for a formulation with the most reduction for the smallest performance it); would signing with 1024 bytes of static data be okay?
Thanks, took me a while to wrap my head around all the config options, but I finally got it to build in EWARM
Edit: well, all that for nothing... memory usage is way too high for the chip I was trying to run it on.
Edit: well, all that for nothing... memory usage is way too high for the chip I was trying to run it on.
Ah. I was not aware of this change.
Without makefile, I remember I could build using
following the README from https://github.com/joshlang/Secp256k1.NET
Without makefile, I remember I could build using
Code:
1) yasm -f win64 -o obj\field_5x52_asm.o src\field_5x52_asm.asm
2) x86_64-w64-mingw32-gcc-4.8.1.exe -I gmp -fPIC -std=gnu99 -DNDEBUG -O2
-DUSE_NUM_GMP -DUSE_FIELD_INV_NUM -DUSE_FIELD_5X52 -DUSE_FIELD_5X52_ASM
src\secp256k1.c -c -o obj\secp256k1.o
3) x86_64-w64-mingw32-gcc-4.8.1.exe -I gmp -std=gnu99 -DUSE_NUM_GMP
-DUSE_FIELD_INV_NUM -DUSE_FIELD_5X52 -DUSE_FIELD_5X52_ASM -DVERIFY
-fstack-protector-all -O2 -ggdb3 src\tests.c obj\field_5x52_asm.o
-lgmp -L gmp -o tests
4) ar -rs libsecp256k1.a obj\field_5x52_asm.o obj\secp256k1.o
following the README from https://github.com/joshlang/Secp256k1.NET
Is GMP still necessary as of this commit? https://github.com/bitcoin/secp256k1/pull/168
You can get away from using make for secp256k1 but the dependencies will be harder to compile without. Do you have GMP ported?
Can anyone give an example of how to compile secp256k1 without using make? I'm trying to port it to an ARM microcontroller, and really have no idea how all the autogen/configure stuff works. Is it possible to compile using a single gcc command + dummy main.c?
https://github.com/bitcoin/secp256k1
https://github.com/bitcoin/secp256k1
Jump to: