CombSortA fails with an access violation for this snippet:
include \masm32\MasmBasic\MasmBasic.inc
FakeStruct STRUCT
TheR4 REAL4 ?
FakeStruct ENDS
.data
align 16
R4Array REAL4 123.456, 99.0, -3000.0, 3000.0, 0.0, 3.0e-20, 3.0e20, 1.000001, 0.999999, 1.00001e2, 0.99999e2, 1.0
.code
start:
; void Str$(0) ; <<<<<<<<<<<<<<<<< sets FPU to down, 64
mov esi, offset R4Array
mov ebx, sizeof R4Array/4
; finit ; workaround: reset the FPU
invoke CombSortA, esi, ebx
.Repeat
Print Str$(ebx), Str$("\t%f\n", [esi.FakeStruct.TheR4+4*ebx])
dec ebx
.Until Sign?
Inkey "done"
Exit
end start
Olly told me the culprit sits here:
CPU Disasm
Address Hex dump Command Comments
00401415 ³> ÚDB45 FC Úfild dword ptr [local.1]
00401418 ³. ³D835 E0404000 ³fdiv dword ptr [4040E0] ; float 1.300000
0040141E ³. ³DB5D FC ³fistp dword ptr [local.1]
00401421 ³. ³FF4D FC ³dec dword ptr [local.1]
If the FPU happens to be in a virgin state, CombSortA works just fine, and even sorts the REAL4 array in the right order ;-)
Maybe I'm missing something but it doesn't crash when built with 6.15 and current MasmBasic.
Uncommenting the void str$ gets it stuck in a loop.
Strange.
With void Str$(0) and no finit, I get a straight GPF.
With void Str$(0) and finit, no GPF.
Without Str$(0) no GPF.
What I find equally worrying is that my assumption that REAL4's can be sorted like integers might be wrong. It works for
mostallvalues, but a dec ebx before the .Repeat is needed ::)
Quote.data
R4Array REAL4 123.456, 3.3e30, 99.0, -3000.0, 3000.0, 0.0, 3.0e-20, 3.0e20, 1.000001, 0.999999, 1.00001e2, 0.99999e2, 1.0, 33.44, 44.55, 55.66, 66.77, 77.88, 88.99
Output:
19 1.953342e+23
18 3.300000e+30
17 3.000000e+20
16 3000.000
15 123.4560
14 100.0010
13 99.99900
12 99.00000
11 88.99000
10 77.88000
9 66.77000
8 55.66000
7 44.55000
6 33.44000
5 1.000001
4 1.000000
3 0.9999990
2 3.000000e-20
1 0.0
0 -3000.000