OSDev.org

The Place to Start for Operating System Developers
It is currently Thu Mar 28, 2024 12:27 pm

All times are UTC - 6 hours




Post new topic Reply to topic  [ 6 posts ] 
Author Message
 Post subject: FPU initialization
PostPosted: Tue Nov 14, 2017 11:41 pm 
Offline
Member
Member
User avatar

Joined: Sat May 20, 2017 1:25 am
Posts: 51
Location: PCI bus: 3, slot: 9, function: 5
Brendan wrote:
If the CPU is an 80486 or later, and if an FPU is present, then the FPU is built into the CPU. Otherwise it's 80386 or older CPU. I assume nobody cares about 80286 or older so I won't go into those cases. For an 80386 the FPU can be an 80387 or an 80287, and if you care you can check if the FPU knows the difference between positive infinity and negative infinity (80387 does know the difference, and for 80287 "+infinity == -infinity").

Now you should know if an FPU is present, and if it's built into the CPU or not, and if it's 80287 or 80387 or later.

If there is no FPU, then set the EM flag in CR0 and clear the MP flag in CR0. Otherwise, clear the EM flag in CR0 and set the MP flag in CR0; and if the FPU is built into the CPU then set the NE flag in CR0 so that FPU errors are reported as an exception (and so that FPU errors aren't reported using the IRQ13 via. the PIC, which is slower and can cause problems with race conditions, etc). In practice, it's easier to refuse to boot if the CPU is 80386 (or older) and always use the "native FPU exception" mechanism (and skip the "is it 80387 or 80287" check too).


If the CPU is 80386 (or CPUs without CPUID were we cannot find the CPUs model), how we know if the FPU is built into the CPU or not?

_________________
How people react when a new update of your OS is coming:
Linux user: Cool, more free stuff!
Mac user: Ooh I have to pay!
Windows user: Ah not again!


Top
 Profile  
 
 Post subject: Re: FPU initialization
PostPosted: Wed Nov 15, 2017 7:03 am 
Offline
Member
Member
User avatar

Joined: Sat Jan 15, 2005 12:00 am
Posts: 8561
Location: At his keyboard!
Hi,

ARISTOS wrote:
Brendan wrote:
If the CPU is an 80486 or later, and if an FPU is present, then the FPU is built into the CPU. Otherwise it's 80386 or older CPU. I assume nobody cares about 80286 or older so I won't go into those cases. For an 80386 the FPU can be an 80387 or an 80287, and if you care you can check if the FPU knows the difference between positive infinity and negative infinity (80387 does know the difference, and for 80287 "+infinity == -infinity").

Now you should know if an FPU is present, and if it's built into the CPU or not, and if it's 80287 or 80387 or later.

If there is no FPU, then set the EM flag in CR0 and clear the MP flag in CR0. Otherwise, clear the EM flag in CR0 and set the MP flag in CR0; and if the FPU is built into the CPU then set the NE flag in CR0 so that FPU errors are reported as an exception (and so that FPU errors aren't reported using the IRQ13 via. the PIC, which is slower and can cause problems with race conditions, etc). In practice, it's easier to refuse to boot if the CPU is 80386 (or older) and always use the "native FPU exception" mechanism (and skip the "is it 80387 or 80287" check too).


If the CPU is 80386 (or CPUs without CPUID were we cannot find the CPUs model), how we know if the FPU is built into the CPU or not?


My code initially does:
  • If bit 15 of the flags register is hardwired to 1; then it's an 8086
  • If it's not an 8086 and bits 12 and 13 of the flags register can't be modified; then the CPU doesn't support the IOPL field and must be 80286 or 80186
Note that these checks can be done safely in pure 16-bit real mode code running on an 8086 (and don't require a 32-bit CPU); and I don't do anything to determine if the CPU is 80186 or 80286 (I only display a "CPU is too old" error message and halt boot).

After you've determined that the CPU is 80386 or later (and therefore does support 32-bit); you can test if the "alignment check" feature exists by testing if bit 18 in EFLAGS can be modified, and test if CPUID is supported by testing if bit 21 of EFLAGS can be modified. If bit 18 can't be modified then the CPU it must be an 80386; if bit 18 can be modified but bit 21 can't be modified, then it must be an 80486. Otherwise, it supports CPUID and must be 80486 or later.

Once you've determined the CPU type you can use that information to help determine the FPU type (as I described years ago).

Please note that this is mostly just historical information. When I first started OS development 80486 was new, so I started doing "minimum requirement is 80486 or later" for my OS, and just kept doing that because it's easy for me (e.g. I can cut & paste old code without thinking about it much). If I were starting OS development today my OS's minimum requirements would be quite different (possibly "OS requires long mode") so that I could avoid spending time learning about things that aren't very important anymore - I'd still have an "is CPU too old" check that doesn't crash on ancient CPUs, but after that I wouldn't have a reason to care about whether FPU exists or not, or what type of FPU it is, or if the native FPU exceptions are supported, or if there's an FDIV bug, or ...


Cheers,

Brendan

_________________
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.


Top
 Profile  
 
 Post subject: Re: FPU initialization
PostPosted: Wed Nov 15, 2017 9:35 am 
Offline
Member
Member
User avatar

Joined: Fri Oct 27, 2006 9:42 am
Posts: 1925
Location: Athens, GA, USA
What Brendan said brings up an important question, one we have asked you before: why are you so concerned about supporting hardware which is so old that, quite frankly, you probably will never actually see in person, never mind actually have your OS installed on? Most of the members of this forum aren't old enough to have ever worked on a system older than a Pentium III, which is itself long since defunct (P3s were produced from 1999 to 2003, and were only really in common use between 2000 and 2002). The majority of 386, 486, and even Pentium systems had already gone to the scrapyard by then.

Furthermore, they were never as common as later models in the first place. Between 1966 (the year year Gordon Moore first stated his eponymous law) and 2006, computer sales roughly paralleled Moore's Law, in that as many new computers were sold in each new hardware generation as in all the previous generations - for example, more Pentium 4s were sold between 2002 and 2006 than all the Pentium IIIs, Pentium IIs, Pentium Pros, Pentiums, 486s, 386s, 286s, ans 8088s combined.

The simple fact is, it is unlikely that you would even find a system that old today even if you were deliberately seeking one out. Even second- or third-hand systems in the third world are more likely to be from after 2000 than before (or more likely still, are mobile devices made after 2007 - tablets and smartphones are far more common in most of the world today than desktops had ever been).

So, the question becomes: why are you so interested in this older hardware? Do you have a specific need to support it in mind? Or is this just out of curiosity (which is a valid reason - perhaps more than most, really, given the topic - but one with different implications than a specific need would)?

I am not saying that you don't have a reason, but if you do you haven't told us what it is. Knowing why would make a big difference in what advice we can offer you.

_________________
Rev. First Speaker Schol-R-LEA;2 LCF ELF JAM POEE KoR KCO PPWMTF
Ordo OS Project
Lisp programmers tend to seem very odd to outsiders, just like anyone else who has had a religious experience they can't quite explain to others.


Top
 Profile  
 
 Post subject: Re: FPU initialization
PostPosted: Wed Nov 15, 2017 1:26 pm 
Offline
Member
Member

Joined: Mon Mar 25, 2013 7:01 pm
Posts: 5099
ARISTOS wrote:
If the CPU is 80386 (or CPUs without CPUID were we cannot find the CPUs model), how we know if the FPU is built into the CPU or not?

Why does it matter? From a software perspective, there's only 387-compatible FPU with native exceptions, 387-compatible FPU with IRQ13, and 287-compatible FPU with IRQ13. None of those explicitly depend on whether the FPU is internal or external.

I would guess that CR0.NE is supported on CPUs with internal FPUs and not supported on CPUs with external FPUs, but I can't say for sure since it's nearly impossible to find reliable documentation for x86 CPUs from the era where that was relevant. (For example, the NexGen Nx586 is 386-compatible, implements CPUID in the microcode it loads from the BIOS ROM, and may have either an internal or external FPU. Assuming a Nx586 with an internal FPU and no CPUID support in microcode, CR0.NE may not be enough to determine whether the FPU is internal or external.)

In several cases, it's possible to determine the CPU model without using CPUID, but there are still too many gaps in my knowledge to be able to give a definite answer even if you include these nonstandard CPU detection methods.


Top
 Profile  
 
 Post subject: Re: FPU initialization
PostPosted: Wed Nov 15, 2017 3:08 pm 
Offline
Member
Member
User avatar

Joined: Fri Aug 21, 2009 5:54 am
Posts: 178
Location: Moscow, Russia
Schol-R-LEA wrote:
why are you so concerned about supporting hardware which is so old that, quite frankly, you probably will never actually see in person, never mind actually have your OS installed on?
Well, some people like to tinker with old hardware.

I.e. i am currently working on getting my OS to run on a PC104 board with a 386SX on it (and 4Mb of RAM - fun!), and had to figure out FPU detection as well as to purge the unnecessary FPU operations from random places in the RTL.
Next stop would be getting the ethernet to run ("Realtek 8019AS 16bit ISA full-duplex ethernet controller"), then the end goal would be dumping the content of the DiskOnChip 2000 that sits on this board (hopefully some defunct DOS thingy is in it. If it's blank, i'll be pissed off).

Sure, this problem can be solved by soldering together an adapter to attach a floppy drive to the non-standard port on the board, but where is the fun in that? :)


Top
 Profile  
 
 Post subject: Re: FPU initialization
PostPosted: Thu Nov 16, 2017 10:39 am 
Offline
Member
Member
User avatar

Joined: Fri Oct 27, 2006 9:42 am
Posts: 1925
Location: Athens, GA, USA
Artlav wrote:
Schol-R-LEA wrote:
why are you so concerned about supporting hardware which is so old that, quite frankly, you probably will never actually see in person, never mind actually have your OS installed on?
Well, some people like to tinker with old hardware.


Fair enough, sure, I don't have a problem with that. However, it would make sense for the OP to say so if that's the case, because then we'd have enough context to give a more appropriate answer.

Thing is, as it is written now, it sounds like ARISTOS either just curious (which is fine), or thinks it is relevant to an OS not targeting older hardware, and I was trying to find out which it was. If it's the former, all well and good, but if it is the latter, I would want to point out that it really isn't something one needs to worry about when not specifically working on older systems.

_________________
Rev. First Speaker Schol-R-LEA;2 LCF ELF JAM POEE KoR KCO PPWMTF
Ordo OS Project
Lisp programmers tend to seem very odd to outsiders, just like anyone else who has had a religious experience they can't quite explain to others.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 6 posts ] 

All times are UTC - 6 hours


Who is online

Users browsing this forum: Bing [Bot], SemrushBot [Bot] and 84 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group