Factor supports machines without SSE2 if you compile it yourself. In this case it will use the x87 floating point. The binaries are built to use SSE2 for floating point since most machines have it these days.
SSE2 is great for more than just SIMD. It gives you additional registers, allowing the compiler to generate more parallel scalar operations. Visual C++ with /arch:SSE2 will happily interleave x87 instructions with SSE2 instructions, which looks strange but works well.
You may also want to use SSE2 for saturated scalar additions or prefetches.
Very few people have x86 processors that don't support SSE2 these days. In our tests at IMVU, I think less than 1% of our customers didn't support SSE2, and it was only that high due to the Athlon XP.
In short: when starting a project targeting x86 today, default SSE2 on.
Under what circumstances does Visual C++ still emit x87 instructions? I'd think that other than legacy support, 80-bit long double arithmetic, and the 32-bit ABI (float return values are passed on the x87 stack) there's no reason to use x87.
The optimizer will choose when and how to make use of the SSE and SSE2 instructions when /arch is specified. SSE and SSE2 instructions will be used for some scalar floating-point computations, when it is determined that it is faster to use the SSE/SSE2 instructions and registers rather than the x87 floating-point register stack. As a result, your code will actually use a mixture of both x87 and SSE/SSE2 for floating-point computations. Additionally, with /arch:SSE2, SSE2 instructions can be used for some 64-bit integer operations.
In addition to using the SSE and SSE2 instructions, the compiler will also use other instructions that are present on the processor revisions that support SSE and SSE2. An example is the CMOV instruction that first appeared in the Pentium Pro revision of the Intel processors.
Probably not; It's just that floating point on x86 without SSE is ridiculously awkward, and it's becoming hard to find platforms with no SSE2, so no sense in making an effort to support the x87 or SSE1 instruction sets.
Unfortunately enough people have older CPUs that we still have to support x87 code generation; its just not used in the binary packages, you have to build the source to get it.
Factor uses ahead of time compilation. When you load a source file at the REPL, all definitions in it are compiled immediately, and compiled code is saved in the image. So when you download a pre-built binary package, all the code has already been compiled so auto-detection is not an option.
There are pros and cons to both compiling at load time or run time; one of the disadvantages of the former is less flexibility when it comes to using CPU-specific features.
