Fixes#21.
In the face of all adversity to other sources indicating that the four-bit shuffling element specifier is recycled as a selector for the source element from VT, the only way to pass krom's hardware tests on the VMOV operation with operands illegal to standard RSP assembler was to replace this notion with the seemingly oversimplified read from `de` instead of `e`, even though that specifier is already in use as the selector for which destination slice to write to and not just read from.
Despite being removed from any references in the corresponding translation unit's functional implementation, the four-bit element shuffling mask is still in use as with all other vector operations for pre-shuffling VT[] before jumping into the vector operation interpreter function pointer table.
In addition, the MovIn register is also half-emulated. It is not maintained as a global state machine attribute and only stores the final, hardware-accurate result that was already going to be copied into VD[] anyway rather than the preconceived result of a direct copy from VT[e].
Fixes#19.
Disabling the optimized code is perhaps a temporary measure, but the more readable code under the #else clause should absolutely be kept. The optimized version for 2's complement machines has however also been patched with a fix in case it becomes desirable to go back to enabling it for substantial speed gains.
Sign-extension is correct but only for single-precision reciprocal calculations. Double-precision divides should still continue to mask in the zero-extended low 16 bits of the determined vector register slice if the previously executed divide instruction prepared a double-precision result rather than defining a single-precision one.
This is either for good or just temporary. It depends how much performance is lost from having to call the NOINLINE function, but as this is the actual source of speed hits for the divide operations I find it all that much easier to benchmark it when it is not getting in-lined.
Furthermore, it's usually way low at the bottom of the function hot-spot lists anyway, so I'd rather save my 1 KB of DLL file size than worry about premature optimization for a function that needs more thorough benchmark testing anyway.
