gcc on minix-386 doesn't optimize?

1777 views
Skip to first unread message

torv...@cc.helsinki.fi

unread,
Mar 29, 1991, 10:19:30 AM3/29/91
to
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
torv...@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-).

Paul Cornett

unread,
Mar 31, 1991, 2:55:44 AM3/31/91
to
In article <1991Mar29....@cc.helsinki.fi>, torv...@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:


---------
Paul Cornett
pa...@polari.uucp or ...!uw-beaver!sumax!polari!paulc

klib386.x.cd
Message has been deleted

M E Leypold

unread,
Sep 9, 2006, 2:28:40 PM9/9/06
to

Arnold Schwarzenegger <gover...@california.gov> writes:

> Is there a list of functional MINUX download sites that someone can
> provide ?
>
> Thanks.

Arnold,

A big bad boy like you doesn't use MINUX. I recommend MAXUX for someone
BIG like you.

Have you tried googling for the OS you're looking for? Try using the
name as spelled in the name of the news group. And I don't mean
'bonoism'.

Actually I wonder why you crossposted to alt.religion.dake-bonoism, misc.misc?

Regards -- Markus

kazimir...@gmail.com

unread,
Jan 3, 2014, 10:17:14 AM1/3/14
to
A good system thanks Linus. You saved the world :)

hallo.hey.hal...@gmail.com

unread,
Mar 5, 2019, 4:45:25 AM3/5/19
to
Hallo
Reply all
Reply to author
Forward
0 new messages