In article <1991Mar29.151930.5
...@cc.helsinki.fi>, torva
...@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
pa...@polari.uucp or ...!uw-beaver!sumax!polari!paulc
|
