Personal computing discussed

Moderators: Flying Fox, morphine

 
confusedpenguin
Gerbil Team Leader
Topic Author
Posts: 205
Joined: Tue Nov 15, 2011 12:50 am
Location: Potato State

80387 math coprocessors

Sun Apr 16, 2017 7:39 pm

I recall my parents old computer having an empty socket for an Intel 80387 Math Coprocessor. I knew what it was for, but I always wondered if it would have made games run faster. I was an Ultima junkie, mostly wasting away my teenage years playing The Black Gate and The Serpent Isle. Would installing a math coprocessor made any difference in games, or does a piece of software have to be programmed to take advantage of it?
 
bthylafh
Grand Gerbil Poohbah
Posts: 3808
Joined: Mon Dec 29, 2003 11:55 pm
Location: Southwest Missouri, USA

Re: 80387 math coprocessors

Sun Apr 16, 2017 8:04 pm

The program would have to use x87 floating-point instructions to take advantage. Falcon 3.0 was an early example of such a game, and some professional programs like AutoCAD would do so as well.
Hakkaa päälle!
i5-2500K@4.3|Asus P8P67-LE|8GB DDR3-1600|Powercolor R7850 2G|SanDisk Ultra II 480GB|1988 Model M|Saitek X-45|Logitech MX 518 & F310|Dell 2209WA|Sennheiser PC151|Asus Xonar DX
 
just brew it!
Gold subscriber
Administrator
Posts: 47888
Joined: Tue Aug 20, 2002 10:51 pm
Location: Somewhere, having a beer

Re: 80387 math coprocessors

Sun Apr 16, 2017 8:22 pm

By default the Microsoft C compiler for MS-DOS (and early Windows versions) generated code which could be patched on the fly to take advantage of an x87 coprocessor if it was present.

The way they did this was clever, and took advantage of the fact that code memory was not write-protected in MS-DOS or early versions of Windows. The generated code contained calls to runtime library routines which would emulate the x87 instructions in software. If the runtime library detected that an x87 was installed, it would go back and patch the code in memory to replace the library call with the corresponding x87 instruction. So the overhead of calling the emulator library was only incurred the first time a given piece of code was run after being loaded from disk; after that, it ran at native x87 speed.

Well OK... not QUITE native speed. The encoding of an x87 instruction is shorter than a subroutine call, so the extra couple of bytes of code memory had to be backfilled with NOPs when the runtime library did the patching. But NOPs execute very fast, so it was close to native. You could optionally tell the compiler to assume that an x87 would always be present, in which case it would just generate the x87 instructions from the get-go; in that case the runtime emulator and on-the-fly patching was not needed, and the code would shrink slightly (but would crash if run on a system without an x87).
If the world isn't making sense to you, you're either drinking too much or not drinking enough.
 
confusedpenguin
Gerbil Team Leader
Topic Author
Posts: 205
Joined: Tue Nov 15, 2011 12:50 am
Location: Potato State

Re: 80387 math coprocessors

Sun Apr 16, 2017 8:28 pm

I don't know much about programming. I successfully compiled a Linux Kernel by pure luck, kind of like making the perfect chicken on a charcoal grill. So if a game were compiled by the MSDOS C compiler, would it have automatically detected the coprocessor and taken advantage of it? Or does support have to be enabled by the game programmer or be specifically programmed to be able to use it?
 
just brew it!
Gold subscriber
Administrator
Posts: 47888
Joined: Tue Aug 20, 2002 10:51 pm
Location: Somewhere, having a beer

Re: 80387 math coprocessors

Sun Apr 16, 2017 8:31 pm

confusedpenguin wrote:
I don't know much about programming. I successfully compiled a Linux Kernel by pure luck, kind of like making the perfect chicken on a charcoal grill. So if a game were compiled by the MSDOS C compiler, would it have automatically detected the coprocessor and taken advantage of it? Or does support have to be enabled by the game programmer or be specifically programmed to be able to use it?

If they used the MS C compiler and used the default floating point settings, yes it would've detected and used the x87 automatically.
If the world isn't making sense to you, you're either drinking too much or not drinking enough.
 
confusedpenguin
Gerbil Team Leader
Topic Author
Posts: 205
Joined: Tue Nov 15, 2011 12:50 am
Location: Potato State

Re: 80387 math coprocessors

Sun Apr 16, 2017 8:34 pm

Ok, cool. :-) I guess now it's just doing the homework to find out which compiler game companies used on specific games, just out of curiosity. I'd like to know how much of my childhood was spent playing games where a math coprocessor wouldn't have been sitting idle if the computer had one.
 
just brew it!
Gold subscriber
Administrator
Posts: 47888
Joined: Tue Aug 20, 2002 10:51 pm
Location: Somewhere, having a beer

Re: 80387 math coprocessors

Sun Apr 16, 2017 8:41 pm

I imagine other compiler vendors probably used the same trick. The biggies back then were Microsoft, Watcom, and Borland... I'm just most familiar with the Microsoft one, since that's the one I (mostly) used.
If the world isn't making sense to you, you're either drinking too much or not drinking enough.
 
The Egg
Gold subscriber
Minister of Gerbil Affairs
Posts: 2093
Joined: Sun Apr 06, 2008 4:46 pm

Re: 80387 math coprocessors

Sun Apr 16, 2017 10:59 pm

I've always had an affinity for the 286-486 era of PCs, and specifically thought it would be cool to have a 386DX-33 with a 387 co-processor and maxed out RAM.

Now that I think about it, AMD might have actually made them up to 40mhz, but still...
 
SoM
Gerbil Elite
Posts: 511
Joined: Wed Jan 26, 2011 11:56 am
Location: Toronto

Re: 80387 math coprocessors

Sun Apr 16, 2017 11:08 pm

The Egg wrote:
I've always had an affinity for the 286-486 era of PCs, and specifically thought it would be cool to have a 386DX-33 with a 387 co-processor and maxed out RAM.

Now that I think about it, AMD might have actually made them up to 40mhz, but still...


would the two mathcoproc work together ?
InWin 303 - Asus z170a - G.Skill 32GB 2400 - i7-6700k - H60 - EVGA GTX 1070 FTW - EVGA Supernova G2 750w - M.2 950 Pro 256GB - Audioengine A5+ - Sennheiser HD 280pro - Win 10
 
CuttinHobo
Gold subscriber
Gerbil
Posts: 16
Joined: Sat Sep 05, 2009 9:18 pm

Re: 80387 math coprocessors

Sun Apr 16, 2017 11:22 pm

If I recall, the DX models had x87 built-in. I was the (not so) proud user of a 386-SX 25 that my parents bought for me (starting with a whopping 2MB of RAM), and I was envious of the DX models. Though I don't know how tangible the difference would have been.
 
LiamC
Gerbil
Posts: 26
Joined: Tue Apr 15, 2003 1:49 am
Location: AUS
Contact:

Re: 80387 math coprocessors

Sun Apr 16, 2017 11:24 pm

I'm pretty sure I still have a 20 or 25 MHz 80387. Might have thrown it out last year though...
Deja Moo: The feeling that you've heard this
bull before.
 
The Egg
Gold subscriber
Minister of Gerbil Affairs
Posts: 2093
Joined: Sun Apr 06, 2008 4:46 pm

Re: 80387 math coprocessors

Sun Apr 16, 2017 11:30 pm

CuttinHobo wrote:
If I recall, the DX models had x87 built-in. I was the (not so) proud user of a 386-SX 25 that my parents bought for me (starting with a whopping 2MB of RAM), and I was envious of the DX models. Though I don't know how tangible the difference would have been.

The 486DX had the x87 coprocessor built in. Almost certain the 386DX did not.
 
ludi
Emperor Gerbilius I
Posts: 6972
Joined: Fri Jun 21, 2002 10:47 pm
Location: Sunny Colorado front range

Re: 80387 math coprocessors

Sun Apr 16, 2017 11:51 pm

The Egg wrote:
The 486DX had the x87 coprocessor built in. Almost certain the 386DX did not.

https://en.wikipedia.org/wiki/Intel_80386

Early Problems wrote:
The i387 math coprocessor was not ready in time for the introduction of the 80386, and so many of the early 80386 motherboards instead provided a socket and hardware logic to make use of an 80287. In this configuration the FPU would operate asynchronously to the CPU, usually with a clock rate of 10 MHz. The original Compaq Deskpro 386 is an example of such design. However, this was an annoyance to those who depended on floating point performance, as the performance advantages of the 80387 over the 80287 were significant.

Also see subsequent sections "Pin Compatible Upgrades" and "Models and Variants." The tl;dr is that some boards had an 80287 coprocessor socket and some had an 80387 coprocessor socket, because no actual Intel 386 had a math coprocessor onboard. But Intel later produced repackaged 486DX core that was 386 pin-compatible and a dummy coprocessor module (to convince the motherboard to enable an FPU) as a way of extending the life of existing 386 systems.
Abacus Model 2.5 | Quad-Row FX with 256 Cherry Red Slider Beads | Applewood Frame | Water Cooling by Brita Filtration
 
Pancake
Gerbil
Posts: 82
Joined: Mon Sep 19, 2011 2:04 am

Re: 80387 math coprocessors

Mon Apr 17, 2017 12:19 am

just brew it! wrote:
By default the Microsoft C compiler for MS-DOS (and early Windows versions) generated code which could be patched on the fly to take advantage of an x87 coprocessor if it was present.

The way they did this was clever, and took advantage of the fact that code memory was not write-protected in MS-DOS or early versions of Windows. The generated code contained calls to runtime library routines which would emulate the x87 instructions in software. If the runtime library detected that an x87 was installed, it would go back and patch the code in memory to replace the library call with the corresponding x87 instruction. So the overhead of calling the emulator library was only incurred the first time a given piece of code was run after being loaded from disk; after that, it ran at native x87 speed.

Well OK... not QUITE native speed. The encoding of an x87 instruction is shorter than a subroutine call, so the extra couple of bytes of code memory had to be backfilled with NOPs when the runtime library did the patching. But NOPs execute very fast, so it was close to native. You could optionally tell the compiler to assume that an x87 would always be present, in which case it would just generate the x87 instructions from the get-go; in that case the runtime emulator and on-the-fly patching was not needed, and the code would shrink slightly (but would crash if run on a system without an x87).


It was a kludge and only necessary because the Intel designers never thought to include something as elegant as a trap or interrupt mechanism to deal with presence/absence of coprocessor. Actually the whole design of how the 8087 interfaced with the 8086 was a hideous kludge. Although as the processors were mostly independent while the 8087 was spending lots of cycles doing a complex operation the CPU could quite independently execute its own instruction stream. A primitive form of out-of-order execution! But best left to ace assembly language programmers. Now, counting cycles takes me back...
 
spiked_mistborn
Gerbil
Posts: 30
Joined: Fri Aug 06, 2010 11:01 pm

Re: 80387 math coprocessors

Mon Apr 17, 2017 2:34 am

I actually just bought a new math co-processor for my 386DX system. I have 3 CPUs that I can run in it: an Intel 386DX-33, an AMD 386DX-40, and Cyrix 486DLC-33. I'm currently using the AMD chip because I haven't been able to get the Cyrix 386 to 486 upgrade chip to run reliably yet. It has a few pins that relate to cache control (it has 1KB of on-chip cache!) that weren't present on most 386 motherboards (makes sense since the 386 did not have on-chip cache). I just upgraded from a ULSI math co-processor a few days ago to a Cyrix Fasmath to see if it would help with system stability when using the Cyrix CPU, but no luck so far. I did see an increase in speed in synthetic x87 FPU benchmarks though. Some things that I learned while researching this: the x86 CPU and x87 FPU communicate using a couple of specific IO ports. The CPU sends a command to the FPU, gives it control of the data bus, and pauses until the FPU signals that it is finished. The Cyrix CPU, however can conditionally still execute instructions if they are in the cache, while the FPU does its thing, since it does not need to access the external data bus in this case! Also, to clarify, the only difference between a 386SX and 386DX is a 16-bit vs. 32-bit bus, neither has a FPU or cache. I'm about to try a few things with the cache control registers on the Cyrix chip right now to see if I can get it working, and I might also run a few benchmarks with and without the FPU enabled while I'm at it. I'll post the results here. Cyrix at a later time did make another 386-486 upgrade chip called the Cx486Drx2, which was clock-doubled and also had supporting circuitry on-package to fix the cache coherency issues that the earlier chips like mine suffered from. The problem is, the only one on the whole internet that I can find right now is on eBay, and the seller is asking $530! My budget is closer to $20, so it's not looking good that I will find one.

System specs: AMD 386DX-40 CPU, Cyrix Fasmath 40MHz FPU, 32MB RAM, ATI Mach64 ISA graphics card, MediaVision Proaudio Spectrum 16 sound card, 2GB WD HDD, Lite-On 40x CD-ROM, Gravis Gamepad

Pic: https://twitter.com/SpikedRN/status/853015786323148800
 
Aranarth
Gerbil Elite
Posts: 946
Joined: Tue Jan 17, 2006 6:56 am
Location: Big Rapids, Mich. (Est Time Zone)
Contact:

Re: 80387 math coprocessors

Mon Apr 17, 2017 6:45 am

I watched one of Dad's drawings for a gearbox in a carseat mechanism go from 2 seconds to redraw the screen to instant after installing a cyrix 387.

Once dad realized he could use 10 times more points on screen with little loss in processing power his drawings got a lot more complex.

About a year later we moved to a 486dx-2 66. :D
I wish to see things not as they are but as they should be.

Main machine: Core I7 -2600K @ 4.5Ghz / 16 gig ram / Radeon 7870 / 240 gb Corsair ssd / 5tb hd
Old machine: Core 2 quad Q6600 @ 3ghz / 8 gig ram / Radeon 6870 / 240 gb PNY ssd / 1tb HD
 
just brew it!
Gold subscriber
Administrator
Posts: 47888
Joined: Tue Aug 20, 2002 10:51 pm
Location: Somewhere, having a beer

Re: 80387 math coprocessors

Mon Apr 17, 2017 6:56 am

SoM wrote:
The Egg wrote:
I've always had an affinity for the 286-486 era of PCs, and specifically thought it would be cool to have a 386DX-33 with a 387 co-processor and maxed out RAM.

Now that I think about it, AMD might have actually made them up to 40mhz, but still...

would the two mathcoproc work together ?

No.

CuttinHobo wrote:
If I recall, the DX models had x87 built-in. I was the (not so) proud user of a 386-SX 25 that my parents bought for me (starting with a whopping 2MB of RAM), and I was envious of the DX models. Though I don't know how tangible the difference would have been.

That was the case with the 486 (i.e. DX = math coproc, SX = not). With the 386 the SX had a narrower data bus (but neither the DX nor SX had a math coproc built-in).

The 487 wasn't really a coprocessor though; it was essentially a complete 486DX with altered pinout. Installing a 487 in the "coprocessor" socket of system that had a 486SX in the CPU socket actually disabled the 486SX CPU entirely, and shifted all processing to the 487.
If the world isn't making sense to you, you're either drinking too much or not drinking enough.
 
Glorious
Gold subscriber
Gerbil Khan
Posts: 9807
Joined: Tue Aug 27, 2002 6:35 pm

Re: 80387 math coprocessors

Mon Apr 17, 2017 7:48 am

JBI wrote:
Installing a 487 in the "coprocessor" socket of system that had a 486SX in the CPU socket actually disabled the 486SX CPU entirely, and shifted all processing to the 487.


...and to think that we complain about the inefficiencies of market segmentation today! :lol:
 
Greyguy 1948
Gerbil
Posts: 15
Joined: Wed Mar 29, 2017 6:32 am

Re: 80387 math coprocessors

Mon Apr 17, 2017 9:02 am

I started with a math coprocessor with Turbo Pascal and Mandelbrot fractals. It was in the DOS time so I have tested them all 8087, 80287 and 80387. You could run Turbo Pascal without any coprocessor but it was really slow.
These coprocessors were not great if you compare here:
http://home.vianetworks.nl/users/mhx/flops_1.tbl

Today I have tested Raspberry Pi 3 at 1200 MHz and the result is 347 MFLOPS
 
just brew it!
Gold subscriber
Administrator
Posts: 47888
Joined: Tue Aug 20, 2002 10:51 pm
Location: Somewhere, having a beer

Re: 80387 math coprocessors

Mon Apr 17, 2017 10:28 am

Greyguy 1948 wrote:
I started with a math coprocessor with Turbo Pascal and Mandelbrot fractals. It was in the DOS time so I have tested them all 8087, 80287 and 80387. You could run Turbo Pascal without any coprocessor but it was really slow.
These coprocessors were not great if you compare here:
http://home.vianetworks.nl/users/mhx/flops_1.tbl

They were still orders of magnitude faster than software emulation!
If the world isn't making sense to you, you're either drinking too much or not drinking enough.
 
Buub
Maximum Gerbil
Posts: 4583
Joined: Sat Nov 09, 2002 11:59 pm
Location: Seattle, WA
Contact:

Re: 80387 math coprocessors

Mon Apr 17, 2017 11:15 am

The Egg wrote:
CuttinHobo wrote:
If I recall, the DX models had x87 built-in. I was the (not so) proud user of a 386-SX 25 that my parents bought for me (starting with a whopping 2MB of RAM), and I was envious of the DX models. Though I don't know how tangible the difference would have been.

The 486DX had the x87 coprocessor built in. Almost certain the 386DX did not.

The 386SX was a 16-bit external bus that could fit in a 286 socket. The 386DX was a full 32-bit external bus. Otherwise, they were identical. Neither had a built-in 387.
 
Greyguy 1948
Gerbil
Posts: 15
Joined: Wed Mar 29, 2017 6:32 am

Re: 80387 math coprocessors

Mon Apr 17, 2017 11:21 am

Yes you could get a speed up around 10 times. It was good but a very long step to all the RISC alternatives like MIPS, PA-RISC or Pentium Pro (later).
 
morphine
Gold subscriber
Gerbilus Supremus
Posts: 11314
Joined: Fri Dec 27, 2002 8:51 pm
Location: Portugal (that's next to Spain)

Re: 80387 math coprocessors

Mon Apr 17, 2017 12:40 pm

Aye, the 386-SX was 32-bit internally, 16-bit externally. I had one, and it wasn't fast. And yet... it was awesome at the time.
There is a fixed amount of intelligence on the planet, and the population keeps growing :(
 
Chuckaluphagus
Silver subscriber
Gerbil Elite
Posts: 635
Joined: Fri Aug 25, 2006 4:29 pm
Location: Boston area, MA

Re: 80387 math coprocessors

Mon Apr 17, 2017 1:18 pm

morphine wrote:
Aye, the 386-SX was 32-bit internally, 16-bit externally. I had one, and it wasn't fast. And yet... it was awesome at the time.

It was fast enough to run Wing Commander. At the time, that was all that mattered.
 
confusedpenguin
Gerbil Team Leader
Topic Author
Posts: 205
Joined: Tue Nov 15, 2011 12:50 am
Location: Potato State

Re: 80387 math coprocessors

Mon Apr 17, 2017 2:26 pm

Chuckaluphagus wrote:
morphine wrote:
Aye, the 386-SX was 32-bit internally, 16-bit externally. I had one, and it wasn't fast. And yet... it was awesome at the time.

It was fast enough to run Wing Commander. At the time, that was all that mattered.


I remember having to edit the config.sys file constantly when switching back and forth between playing Wing Commander 2 and Ultima VII. Wing Commander 2 was optimized to run with an expanded memory manager such as EMM386, and Ultima VII wouldn't run at all unless you disable expanded memory and stuck with pure Extended Memory with the HIMEM.SYS line in the CONFIG.SYS file. Eventually I got so used to doing it all the time it only took a few seconds to edit the file and reboot whenever I wanted to switch games.
 
morphine
Gold subscriber
Gerbilus Supremus
Posts: 11314
Joined: Fri Dec 27, 2002 8:51 pm
Location: Portugal (that's next to Spain)

Re: 80387 math coprocessors

Mon Apr 17, 2017 2:30 pm

Noob. Real people used config.sys / autoexec.bat's menu capabilities.

Realer people would use the B000-B7FF range of upper memory to stash everything unneded and had a 620-630KB low RAM setup with CDROM, etc enabled :P

(This is tongue-in-cheek, by the way :))
There is a fixed amount of intelligence on the planet, and the population keeps growing :(
 
Captain Ned
Gold subscriber
Global Moderator
Posts: 25769
Joined: Wed Jan 16, 2002 7:00 pm
Location: Vermont, USA

Re: 80387 math coprocessors

Mon Apr 17, 2017 2:34 pm

morphine wrote:
Noob. Real people used config.sys / autoexec.bat's menu capabilities.

Realer people would use the B000-B7FF range of upper memory to stash everything unneded and had a 620-630KB low RAM setup with CDROM, etc enabled :P

Ah, the last time I could "program" anything. Then I gave up and used QEMM.
If the Earth were flat, cats would have pushed everything off of it by now.
 
Cuhulin
Gold subscriber
Gerbil First Class
Posts: 133
Joined: Sun Mar 02, 2003 12:52 pm
Location: Meridian, Idaho

Re: 80387 math coprocessors

Mon Apr 17, 2017 3:00 pm

Ahh, Quarterdeck!

One of the best tech companies to appear and disappear - extended memory management when Intel processors only allowed 640K to be addressed; windowed multi-tasking when even Microsoft Windows could not do that - a real pioneer!
 
Evan
Gerbil XP
Posts: 411
Joined: Mon Apr 21, 2003 8:42 am
Location: San Diego, California
Contact:

Re: 80387 math coprocessors

Mon Apr 17, 2017 3:14 pm

confusedpenguin wrote:
Chuckaluphagus wrote:
morphine wrote:
Aye, the 386-SX was 32-bit internally, 16-bit externally. I had one, and it wasn't fast. And yet... it was awesome at the time.

It was fast enough to run Wing Commander. At the time, that was all that mattered.


I remember having to edit the config.sys file constantly when switching back and forth between playing Wing Commander 2 and Ultima VII. Wing Commander 2 was optimized to run with an expanded memory manager such as EMM386, and Ultima VII wouldn't run at all unless you disable expanded memory and stuck with pure Extended Memory with the HIMEM.SYS line in the CONFIG.SYS file. Eventually I got so used to doing it all the time it only took a few seconds to edit the file and reboot whenever I wanted to switch games.


Ugh, I remember having to deal with that extended/expanded memory crap back in the day, it was quite a hassle. I was fortunate in that my family eventually got a 486DX-33 with 4MB of RAM that let me play the glorious Wing Commander and Wing Commander II games. I also remember having the separate speech packs for Wing Commander 2. Things sure were different back then.
 
ptsant
Silver subscriber
Gerbil Team Leader
Posts: 224
Joined: Mon Oct 05, 2009 12:45 pm

Re: 80387 math coprocessors

Mon Apr 17, 2017 3:40 pm

confusedpenguin wrote:
I recall my parents old computer having an empty socket for an Intel 80387 Math Coprocessor. I knew what it was for, but I always wondered if it would have made games run faster. I was an Ultima junkie, mostly wasting away my teenage years playing The Black Gate and The Serpent Isle. Would installing a math coprocessor made any difference in games, or does a piece of software have to be programmed to take advantage of it?


Having bought a 80387 myself I can tell you that the vast majority of games would not benefit from the FPU. In fact, the FPU was extremely slow compared with the CPU. For example the transcendental functions would regularly require hundreds of cycles and even simple multiplication or division would be much, much slower than the integer version. The only thing slower than the FPU was emulating the FPU in the CPU, if you really needed floating point math.

As far as I can tell, the first game that used the FPU was Quake (pentium era), which used FDIV (floating point division) to calculate 1/z to order the objects on the screen. It was also, due to the popularity of the Quake engine, one of the reasons the contemporary AMD CPUs (K5-K6) lost to Intel Pentiums, whose FPU was considerably faster, in many gaming tests.

Anyway, to make a long story short, I really don't think you 'll notice a difference in games. If anyone knows of a specific game that did use the FPU in the 80386 or 80486 era, please enlighten me.

Who is online

Users browsing this forum: No registered users and 2 guests