torvalds@cc.helsinki.fi (03/29/91)
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'm not actually sure I've gotten it right (pretty sure though), but I'm somewhat surprised that gcc would use floating point in normal optimizations when the program under compilation certainly doesn't. I've downloaded the sources (2.9Mb for just gcc, not gas etc), but due to a rather small HD I've been unable to untar them completely, so I cannot recompile or anything. I could get one of the floating point packages floating around, if that is the problem, but my understanding is that the current binary cannot take advantage of them anyway. Could somebody please tell me what's the story behind the gcc floating point? advTHANKSance, Linus Torvalds torvalds@cc.helsinki.fi PS. No it's not a big problem, even without optimization I get around 7000 dhrystones, I'm just wondering. And yes - I'll get a bigger HD as soon as my somewhat strained economy can make it 8-).
paulc@polari.UUCP (Paul Cornett) (03/31/91)
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<B Q,R P,CHU,CHS,B Q.3DQ"BTM+2!K M;&EB,S@V+G@)5&AU($UA<B R,2 Q-#HR,CHT,R Q.3DQ"BHJ*BHJ*BHJ*BHJ M*BHJ*@HJ*BH@-#$W+#0R,B J*BHJ"BTM+2 T,3<L-#(S("TM+2T*(" *(" ) M;6]V"65A>"QC<C *(" );W()96%X+"-#4C!?4$<**R );W()96%X+",T"0E\ M('1U<FX@;VX@9G @8V]P<F]C97-S;W(@96UU;&%T:6]N"B @"6UO=@EC<C L 296%X"B @"B @"7!O< EE9&D* end --------- Paul Cornett paulc@polari.uucp or ...!uw-beaver!sumax!polari!paulc