Quote from: 2112 on November 27, 2012, 10:45:58 PM

But even the definitions in your "ccoin" include files are deeply incompatible with any standalone environment, even if it uses GCC toolchain. Major rework would be required even now, when there's just couple of hundred lines of code.

This seems quite an exaggeration, with no supporting evidence of what needs a major rework. I do embedded programming for the day job, so I don't see this. The Linux kernel is as bare metal as it gets, and must work in all environments, all platforms.

The main chore of embedded use is simply the dependencies, most notably OpenSSL, and to a lesser extent GLib. Once you have that, or its replacement, embedded use is straightforward.

Quote

The big-endian compatibility is already super-confusing. Istead of using uint32_t in bu256_t use an "union le_int32" to at least flag the mixing of little endian uint32_t with guint32_t.

Using "union" decreases the performance and quality of code output for zero gain. It is trivial enough to use sparse with a type specifier to guarantee endian purity, like the Linux kernel does, if that is desired ("__le32" etc.)

Quote

1) from the start build also on Mac Leopard or Snow Leopard to verify the endian-neutrality with "-arch ppc" with Rosetta on Intel CPU. Edit: Never mind, I forgot that you have access to the Linux on POWER and z/Arch through your association with RedHat.

The code has long since been verified to work on big endian.