OSDev.org

I was wondering if we still should take the effort to support older computers that for example don't support the FPU. Is there any reason to still support computers that do not have support for the floating point unit or processor features that are very common nowadays?

By not supporting them, I mean something like displaying a message "your computer does not meet the requirements for installing the OS" or something similar. What are your thoughts on this? Is it worth the effort to support very very old computers?

Creature

I'm not sure you'll want to print an error message and halt the whole thing just because the guy is not using a Pentium 2+ processor.

What I recommend is to write a simple kernel (I strongly believe that with kernels, simple is the best. The kernel should be unseen and unheard. It's just supposed to sit in a dark corner int he background, consuming as little memory as possible, and and when it's called, do whatever it's asked as fast as possible, and then return to the corner), and have it support multiple processors by using the simplest of language features.

Then, anyone can install it on pretty much any 32bit PC. Let the Application developers print out incompatibility errors. But it's really not a good idea to have an OS telling people that their PCs don't 'qualify' to run it. It just sound too much like a computer talking back to you.

Hi,

Creature wrote:Is it worth the effort to support very very old computers?

That depends on what your OS is designed for (and what you consider "old").

For example, Intel's desktop/server CPUs have all had an FPU since the 80486SX (released in 1991, 18 years ago now); and IMHO if your OS is only intended to be used for desktop/server, then it's not worth supporting CPUs that don't have an FPU.

However, I'm currently writing a kernel. This kernel might eventually be used as part of a desktop/server OS, but it might also be used as part of an OS for embedded systems, and you can still buy new 80x86 embedded systems that don't have an FPU. In this case, the desktop/server version of my OS probably will require an FPU, but the version of my OS for embedded systems probably won't, and therefore the boot code and kernel (which is used by both versions of the OS) can't assume an FPU is present.


Cheers,

Brendan

I see your point. I think I'm going to implement a validation function in my operating system that will check if the computer meets the hardware requirements needed to run my OS properly. This makes me wonder why I didn't implement something similar sooner...

Thanks for your feedback,
Creature

Depending upon where you are now, and how much time you can give to it, it will prabably take at least five years to write an operating system. What needs to be considered is the capabilities of processors then. Today's high end processors will by then be low end processors, and "legacy" processors will belong even more to the distant past than they do now.

Oberon was written in less than five years, but there were two people (part timers like us) working on it.

I would personally say that you should work on including all of the high end features of today's top computers. That way in the years it takes for your OS to finalize it would be working on what would become pretty common hardware. That means 64-bit support for gigs of ram and terabyte hard drives, WIFI and USB. Unless you are working on an embedding OS, of course. Hardware we would define as obsolete today is still common place in the embedded field.

Some of you will remember my previous OS, TBOS16. TBOS16 was instruction compatible with the little-known embedded 80186 processor. Needless to say, it couldn't really grow in any form because of the limitations of real mode and the instructions (not) supported by the 186. Because of that (and the codebase fail) it was a complete failure.

The case of TBOS16 may be different than this, but the point still stands: limiting yourself to old technology is some SERIOUSLY bad mojo. Very Bad Idea (tm).

--Troy

Hi,

Troy Martin wrote:The case of TBOS16 may be different than this, but the point still stands: limiting yourself to old technology is some SERIOUSLY bad mojo. Very Bad Idea (tm).

That depends.

There isn't any reason why an OS can't have 3 different versions (a 16-bit version, a 32-bit version and a 64-bit version), where the 16-bit version will only run 16-bit applications, the 32-bit version will run 16-bit and 32-bit applications, and the 64-bit version will run all applications. Different applications may have additional requirements of their own (for example an application might require SSE), and because of that it might not run on some computers, but that's normal/expected and not really the OS's problem.


Cheers,

Brendan

Brendan wrote:There isn't any reason why an OS can't have 3 different versions (a 16-bit version, a 32-bit version and a 64-bit version), where the 16-bit version will only run 16-bit applications, the 32-bit version will run 16-bit and 32-bit applications, and the 64-bit version will run all applications. Different applications may have additional requirements of their own (for example an application might require SSE), and because of that it might not run on some computers, but that's normal/expected and not really the OS's problem.

That's very true. Although it would most definitely take more time to port your OS from 64-bit to 32-bit and down to 16-bit, especially if your OS is written in something like D. I do not know of any real-mode D compiler that exists.

Note that on these older processors, you have a couple of options for running the newer software. You could emulate the newer instructions, making it just run the 64bit code (although this is generally agreed to have a factor of 10 slowdown), or you could write all your applications (even for the 64bit machine) in an interpreted or bytecode language (.NET, JVM, eat your heart out). Again, slow, but it's an option for supporting the newer software, if you write your operating system for multiple target architectures.

Hi,

Troy Martin wrote:

Brendan wrote:There isn't any reason why an OS can't have 3 different versions (a 16-bit version, a 32-bit version and a 64-bit version), where the 16-bit version will only run 16-bit applications, the 32-bit version will run 16-bit and 32-bit applications, and the 64-bit version will run all applications. Different applications may have additional requirements of their own (for example an application might require SSE), and because of that it might not run on some computers, but that's normal/expected and not really the OS's problem.

That's very true. Although it would most definitely take more time to port your OS from 64-bit to 32-bit and down to 16-bit, especially if your OS is written in something like D. I do not know of any real-mode D compiler that exists.

There's a massive difference between 16-bit, 32-bit and 64-bit code. However I doubt that these are the only features that Creature was thinking about. For example, a 32-bit kernel could support CPUs with MMX and CPUs without MMX with very little extra code in the kernel (the main difference is whether you use FXSAVE/FXRSTOR or FSAVE/FRSTOR in the task switching code).

If you have a look at all the features that may or may not be supported by the CPU, you'll see that some of them only effect the kernel itself (e.g. global pages, PAE, PSE, MSRs, performance monitoring, etc) and their existence (or non-existence) can be entirely hidden from user level code. With a little care, this can be extended to some other features too - for e.g. for RDTSC and CPUID you could provide kernel APIs that user level code uses instead of using these instructions.

Here's a quick list of features that user level code might care about:

• FPU
• CMPXCHG8B
• SYSENTER/SYSEXIT (32-bit)
• SYSENTER/SYSEXIT (64-bit)
• SYSCALL/SYSRET (32-bit)
• SYSCALL/SYSRET (64-bit)
• CMOVcc
• FCMOVcc/FCOMI/FCOMIP/FCOMIP/FUCOMIP
• CLFLUSH
• MMX
• FXSAVE/FXRSTOR
• SSE
• SSE2
• SSE3
• FISTTP
• PCLMULQDQ
• SSSE3
• FMA
• SSE4.1
• SSE4.2
• MOVBE
• POPCNT
• AES
• AVX
• Extended MMX (Cyrix)
• 3DNow!
• Extended 3DNow!
• PREFETCH/PREFETCHW
• SSE5A
• LZCNT
• LAHF/SAHF
• Montgomery Multiplier and Hash Engine (Centaur)
• Advanced Cryptography Engine (Centaur)
• FEMMS (Centaur)
• Random Number Generator (Centaur)
• PFRSQRTV/PFRCPV (Geode GX/LX)

Cheers,

Brendan

Checking for an FPU/SSE and the like could be the responsibility of the application. Since when does a kernel do floating point math? (I know, sysenter/sysret is used in the kernel, so the kernel could do a check to see if it's supported). But, don't push back the floating point registers on a task switch unless a floating point instruction has been called, which won't happen if you don't have an FPU.