Microsoft C bombs doing floating points

[neozeed]

I know this is silly but I was collecting as many 'cl386' compilers and trying to compare assembly output and speed.

the info is the infocom'87 interpreter, it doesnt use floats, and it runs just fine. info.zip

The phases of the moon test however does use floats and this is where it goes off the rails phoon.zip

I had thought I could output assembly and assemble that, but it doesnt seem to actually work.. so maybe thats nothing. But trying to use pharlap 286 to run the compilers (16bit os/2 only)

astro.c(124) : Compiler error (internal):infinite changes in optimize, loop 1
NMAKE : fatal error U1077: 'C:\WINDOWS\system32\cmd.exe' : return code '0x66'
Stop.

The makefile can select which compiler set to use, if it needs an emulator (msdos.exe..), an extender (run286) and other options.. I've included the runtimes of phar lap 286 2.5 & 3.1 in each zip

Additionally so do some misc benchmarks bench.zip

Thanks again so much !!!

[cracyc]

I don't understand, is the problem with compiling or with running the programs? Is there an easy way to repo the problem? The 386 binaries seem to be win32 and work. Phoon2 complains that run286 is needed and when I do that is give a bad exe error. Compiling gives bunch of different errors depending on which compiler, linker and nmake I try.

[neozeed]

Sorry i could have worded it better.

from the poon.zip

set the path to include the 'bin' directory

path=bin;%PATH%

nmake clean nmake

and it'll bomb right away

Copyright (c) Microsoft Corp 1984-1991. All rights reserved.

astro.c
astro.c(124) : Compiler error (internal):infinite changes in optimize, loop 1
NMAKE : fatal error U1077: 'C:\WINDOWS\system32\cmd.exe' : return code '0x66'
Stop.

in the makefile the PLATFORM setting chooses which compiler, although all the 16bit OS/2 cl386 all act weird with this ":infinite changes in optimize, loop" error. running the compiler under dosbox via pharlap 286 or native on OS/2 both work with no complaints...

[cracyc]

The 486 version of msdos.exe works while the 386 version gives that error. I suppose the compiler expects the cpu to have x87 support. Maybe fpu emulation in the compiler is failing in the cpu emulator? The compiled program still gives the bad exe error no matter if it's compiled or run in msdos-player or dosbox.

[neozeed]

wow that is... wierd.

Microsoft (R) Microsoft 386 C Compiler. Version 6.00.054
Copyright (c) Microsoft Corp 1984-1989. All rights reserved.

whet.c
        link  -out:whet-ddksrc.exe whet.obj libc.lib  kernel32.lib
Microsoft (R) 32-Bit Executable Linker Version 1.00
Copyright (C) Microsoft Corp 1992-93. All rights reserved.

whet.obj : warning LNK4033: converting object format from OMF to COFF

yeah that did it! 286 or 486 work, not the 386.

C:\cl386-research\proj\bench>msdos386 whet-ddksrc.exe
Fatal error TNT.11020: unhandled exception occurred: Unknown Exception.
ProcessId=7915 ThreadId=7916
User Registers:
EAX=00160AF4h EBX=00160B18h ECX=00160B1Ch EDX=00160B1Ch
ESI=C0000090h EDI=00160DBEh EBP=00160E34h
DS=0017h ES=0017h FS=008Fh GS=0017h FLG=00003202h
CS:EIP=000Fh:00056C52h SS:ESP=0017h:00160AE0h

C:\cl386-research\proj\bench>msdos486 whet-ddksrc.exe

Loops: 1000, Iterations: 1, Duration: 7 sec.
C Converted Double Precision Whetstones: 14.3 MIPS

So the moral of the story is the 486 is the way to go.

Sorry for all the confusion, thanks for figuring that one out!

[cracyc]

The 386 and 486 emulation is the same except for the floating point while the 286 is different. I wonder if the compiler thinks there's a coprocessor with the 386 and if trying to use x87 insns. If you want 32bits though the 486 is definitely better than the 386 though because the cpu x87 emulation will be faster than the dos compiler one.

[neozeed]

I had feared the 486's math emulation somehow introducing errors, but turns out it's perfectly fine.