Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!cs.utexas.edu!uwm.edu!ogicse!milton!sumax!polari!paulc From: paulc@polari.UUCP (Paul Cornett) Newsgroups: comp.os.minix Subject: Re: gcc on minix-386 doesn't optimize? Summary: EM bit in cr0 not set Message-ID: <3621@polari.UUCP> Date: 31 Mar 91 07:55:44 GMT References: <1991Mar29.151930.5767@cc.helsinki.fi> Organization: Seattle Online Public Unix (206) 328-4944 Lines: 49 In article <1991Mar29.151930.5767@cc.helsinki.fi>, torvalds@cc.helsinki.fi writes: > Hello everybody, > I've had minix for a week now, and have upgraded to 386-minix (nice), > and duly downloaded gcc for minix. Yes, it works - but ... optimizing > isn't working, giving an error message of "floating point stack > exceeded" or something. Is this normal? I had problems with the crcs, so I had the same problem, and after a while I found that coprocessor instructions were not causing an exception even though I don't have a 387. Apparently the bios (which minix uses to enter protected mode) on my machine doesn't set the EM bit of CR0 to indicate the lack of a coprocessor, so any fp instructions just get ignored. Since the minix patches for gcc depend on SIGFPE being generated when an fp instruction is encountered, things get screwed up pretty quickly. I fixed the problem by adding a quick hack to klib386.x; probably it would be better to add code which determines whether or not a coprocessor is present, but that was too much trouble, and this worked for me: *** klib386.x~ Wed Mar 13 02:52:32 1991 --- klib386.x Thu Mar 21 14:22:43 1991 *************** *** 417,422 **** --- 417,423 ---- mov eax,cr0 or eax,#CR0_PG + or eax,#4 | turn on fp coprocessor emulation mov cr0,eax pop edi in case that gets mangled, here it is uuencoded: begin 644 klib386.x.cd M*BHJ(&ML:6(S.#8N>'X)5V5D($UA"QC