Quote from: matrix01 on November 13, 2019, 04:20:42 AM

How does one correctly decide if a computer is compatible with gcc7.2 or gcc4.9? In my case, my Intel486 Laptop works great with gcc4.9. However, it does not work with gcc7.2. In contrast, my Ubuntu desktop PC works great with gcc7.2.

Based on your OS. gcc4.9 is built on a dedicated offline debian 8 laptop. This is to provide builds for people who use older systems as their signer mostly.

Quote

Also what does the acronym "NOASM" represent?

CPU manufacturers add extra silicon on top of the baseline Intel x86 and AMD64 for specific calculations. Stuff like AVX, baked in AES, the old MMX and so on. All that stuff is instruction sets that are not part of the baseline. If you allow your compiler to build against those, you get a performance boon, but older CPUs without the dedicated silicon can't run the software. If you turn off the compiler's access to these instructions, the code will run on anything that's x86/x64 compliant.

The "No ASM" tag signifies that these optimizations are turned off. This is due to how they get enabled the in the first place: GCC will read the C++ code and interpret it into assembly. Assembly code isn't very human readable. The lingo just isn't intuitive, and revolves around registers, which are specific addresses to certain CPU resources.

A simple example: in C/C++ and any other language designed for humans, you perform additions by writing them out as you would on paper. To add a to b and get the result in c you do "c = a + b". In Assembly, you'd have to load a in the first addition register, b in the second addition register, and read the result in the result register. This is why we use compilers, to avoid having to go through that mess.

The extended instruction sets you see in modern CPUs allow you to perform some operations much faster than just using the plain old x86 stuff. One example is pulling 2 128bit integers and adding or multiplying them in as little as 3 cycles instead of breaking down the operation to multiple 32 or 64 bit operations, each costing a few cycles.

Now don't get the wrong idea, the compiler doesn't interpret your code to use extended instructions on a whim. This typically has to be enabled by humans, and more often than not you gotta get your hands dirty and implement in pure ASM to squeeze performance. In the case of Armory, the crypto library it uses has a bunch of these assembly sections to leverage extended instructions, most notably for AES. In this case, NOASM means "turn off all of these optimizations, just use old x86".

The goal is to allow people to use Armory on older hardware. It goes in line with using gcc4.9, to allow for older machines to be recycled into offline signers for the most part, since the performance cost of offline Armory is negligible even on 20 years old machines. The builds with recent GCC has a all optimizations enabled and is meant for recent machines using online Armory, which is resource intensive.