What do you want to use from parity/primitives? Their numbers don’t actually seem to be that well-suited to what we are doing (@ttk2- they are mostly about x86 optimizations right?) . Some of the other stuff like their byte arrays could be nice just to avoid conversions when calling their code, but i’d want to look at the tradeoffs of doing it their way (IIRC they use Vec’s, which are easier but also less strongly typed)
Their numbers are based on byte arrays instead of bignums (which are vecs of bytes under the hood), and their binary representations are exactly what ethereum expects. They also have strongly typed eth specific types like private keys, which are basically exactly the same as our implementation except it is used throughout the whole parity “ecosystem”
Their numbers are more optimised by virtue of being stack allocated and specialised to their integer size, and they also have asm implementations for x86, but nothing in particular that makes it unoptimised for the architectures we will be using it in (mips, arm etc)
actually @kindiana now that Jehan reminds me I remember checking the parity uint implementation out before writing our own. They didn’t seem to have general functions.
Yup just doubled checked, you added the convenience features to code with only x86 in line ASM options, no general purpose implementation. If you want to upstream something you could integrate our general purpose implementation and then use their tests, which we know should be correct.