Just-B'cos: Where would you draw the line for compatibility?

[gravaera]

I think that it may be safe to say that when developing for the x86 PC compatible platform, you can confidently draw the line for compatibility backward-bending at the 80386 and up.

If you want to absolutely maximize your customer/interest/market base, you could break your back a little and go on to 80286, but definitely, I mean: 8086/80186 is just probably, unless you have reason privately defined, just not fruitful enough.

As much as you won't have to bend over backward too much, it's also not worthwhile enough to persist. I mean: do YOU know anyone who still runs an 8086/80186? Or even an 80286?

I may be thinking wrong, and before I go about coding my OS for i386 up, I wanted to consult .

Would you specially optimize for god running on 8086-80286? Or would you probably do just enough to make sure it works on an older Intel chip? Not too much, not too little? Or just go straight where the crowd is? i386 up?

[JackScott]

If you wanted to go where the crowd was, I'd be pointing my compiler at least at CPUs with a built in FPU (i486DX), and most probably at a Pentium III, since it has an FPU, SSE, PAE, MMX. None of these are essential, of course, but having them makes a computer more powerful, and almost nobody has a computer without them these days.

Of course, if you're in the masochistic mood, just write your OS for an i8080, we don't mind.

[whowhatwhere]

I think that it may be safe to say that when developing for the x86 PC compatible platform, you can confidently draw the line for compatibility backward-bending at the 80386 and up.

If you want to absolutely maximize your customer/interest/market base, you could break your back a little and go on to 80286, but definitely, I mean: 8086/80186 is just probably, unless you have reason privately defined, just not fruitful enough.

As much as you won't have to bend over backward too much, it's also not worthwhile enough to persist. I mean: do YOU know anyone who still runs an 8086/80186? Or even an 80286?

I may be thinking wrong, and before I go about coding my OS for i386 up, I wanted to consult .

Would you specially optimize for god running on 8086-80286? Or would you probably do just enough to make sure it works on an older Intel chip? Not too much, not too little? Or just go straight where the crowd is? i386 up?

Although I try to avoid the CISC, I would demand anything better or equivalent to and Athlon64.

[Combuster]

For most of the stuff, an 486DX+ makes your life comparatively easy: fpu guaranteed, many useful opcodes for waitfree stuff, and caches and cache management - all the stuff you'd normally need. Anything later just adds a few relatively boring features (until you reach the opterons and x86-64)

I'm doing 386+, because that's what my lowest end machine is.

[gravaera]

For most of the stuff, an 486DX+ makes your life comparatively easy: fpu guaranteed, many useful opcodes for waitfree stuff, and caches and cache management - all the stuff you'd normally need. Anything later just adds a few relatively boring features (until you reach the opterons and x86-64)

I'm doing 386+, because that's what my lowest end machine is.

QFT++!!

I was totally thinking this same way. I mean seriously: if I'm building a desktop OS, and most desktop and portables in the last decade are like...80586+, why bother doing any more compatibility coding than 80386? Seriously.

But, just to see, though, I wonder: Is anyone going to start coding from say, 80586 specific and upwards? As in, "Well, if you can;t get a good processor, son, I can't help you."

Would you go that far? Or do you have a small fear that, well, If I don't code for i386, I think I really might be missing out on some of the relevant populace.

And seeing as I'm not extremely versed in CPU architectures, just for the heck of it, is the i586+ Instr. set much more improved than the i386?

[JackScott]

Lots of people have already gone that far, and more. A growing number of people are coding just for x86-64 machines.

Edit: As for what each processor introduces, have a look at IA32_Architecture_Family. The charts show all the big things, but there are a few individual instructions that have been introduced that don't come under any category, those aren't shown.

[NickJohnson]

I think the more important part is what components you're going to rely on in the target architecture. The reason there is such a big gap between the 286 and 386 is that the 386 has a paging system and reasonable (i.e. >16 bit w/o segmentation) addressing, just like other modern architectures (PPC, ARM, etc.). If you write the OS for the 286 and port it to something like the PowerPC or even the 386, you can't take advantage of very useful features that are necessary for modern OS designs. For example, MINIX was originally written for the 8088, so it doesn't use paging, and that makes it less memory efficient and easier to break by design (compared to other microkernels), even when running on an i686. That's the reason the line is drawn so often at the 386; you can also assume things like a built in FPU and such, and go for a 486 or 586 as a minimum, but those differences do not change the whole architecture like paging and 32+ bits.

[Solar]

I remember, back when I started my project, that I've been pouring through the Intel Manuals trying to answer that very question: How far back would I go? I didn't want to cut off arbitrarily, like with saying "everybody has a i686 these days", but founded on a technical reason.

But with me being an old fart and everything, I only remember that I came up with the i586 as lowest common denominator, but I don't remember why anymore. I think it had something to do with how system calls could be implemented, but I really don't know anymore.

That being said, when starting your project today, and aiming for a generic desktop OS, it's probably safe to assume that no-one will look at you askance if you support only x86-64 and upwards, given that your v1.0 release will be in five, more realistically in ten years, soonest...

[TverrBjelke]

reading this, I *can* think of a useful goal for doing an OS for eg. 8088 or somewhat that kind - FPGA!
You know these little chips, that you can program to become whatever logical circuit you can implement.
And they are used e.g. when fast prototype to market cycles are needed, and the hardware is just procduced in low numbers, so you cannot waste a whole supply-chain of the million-chip industry for those few ones.

These chips becoming more and more capable these days, in that you can use the "unused arrays" to become a small processor unit, doing the stuff that you cannot easily do with simple state-machines, or adding some extra features (like virtual console application to allow some remote configuration of the application).

Newest models already integrate a small CPU besides the logic arrays. So all these CPUs need some kinda embedded "OS".

And here one *could* think: O.K. no one has these thinigs for his Desktop Comupter, but everyone (of oldscool) developer still knows them, so using an tiny old known chip like 8088 you find people able to program them. But in the real world companies are using "free" cpu designs (I think it was e.g. sparc?), not those like 8088 of intel.

So this idea of programming OS for an extremely old cpu model is not just a geek-brainfarth...

O.K. the thread was talking compatibility... And so my guess is: Everything predating amd64 is wasted
And only if you are hopelessly lost in geek-romantic, you could keep stick to i586... (but then you as well could argue for i386 - who REALLY needs floatin' stuff and all the other waste? We have GPU's for that now

[earlz]

Well there is always the embedded market.. aren't there still 286s being made in portable devices?

[jal]

Well there is always the embedded market.. aren't there still 286s being made in portable devices?

Probably not, the 286 has nothing the 80186 doesn't have, except crud you don't want in the embedded market. There are, no doubt, many 80186 compatible processors out there, just like there are still many Z80s...


JAL

[Solar]

...and ARMs and 68k's...

But an OS is seldom targeted at both the desktop and the embedded market, as the requirements and restrictions of the two are very different. I take it we're generally talking the desktop here, and as such, I'd say 286 and older are out of the equasion for any serious considerations.

[gravaera]

Well, as an update, I'm now wavering between having base support for i486+ or i586+. I like the guarantee of an FPU. And Pentium is sweet and easy compared to the minimal instruction set of the 386.

[manonthemoon]

Well, as an update, I'm now wavering between having base support for i486+ or i586+.

That's good to hear. The 586 will guarantee that you have the ability to use 4MB pages and an on-chip APIC. After the 586, the most significant changes to the x86 family are the SIMD instructions and various performance enhancements that don't directly affect compatibility. So I think that's a good place to draw the line.

Personally, I compile my OS with -march=i686, but that's because I don't care much for compatibility with old processors. 486 is two decades old, and the Pentium was discontinued ten years ago. My memory manager assumes 4MB pages are available, so that puts my support at a 586 minimum.

And Pentium is sweet and easy compared to the minimal instruction set of the 386

I don't think the main instruction set (not counting MMX/SSE) changed much after the 386. Aside from the CMOVcc instructions, am I missing something?

[Brendan]

Hi,

Well, as an update, I'm now wavering between having base support for i486+ or i586+. I like the guarantee of an FPU. And Pentium is sweet and easy compared to the minimal instruction set of the 386.

If you do support Pentium, then it's very easy to also support 80486 in most cases; and it might make more sense to decide between "80486 with FPU" and "80486 without FPU". Of course if you do decide to support Pentium only, then you get to decide between "Pentium with MMX" and "Pentium without MMX".

As far as applications are concerned the only differences between 80486 and Pentium are the CMPXCHG8B instruction, the RDTSC instruction (which can be disabled for CPL=3 and emulated by the OS on later CPUs, which is something I'd recommend doing for other reasons). The FPU and the CPUID instruction are supported on some (but not all) 80486 CPUs.

From a kernel's perspective, the only differences between 80486 and Pentium (except for differences that also effect applications) are RDMSR/WRMSR, MSRs (which didn't exist on 80486 but are "model specific" anyway), the MTRRs, the missing test registers (they were present in 80486 but removed after that), VM86 enhancements, debugging extensions (mostly just the ability to set I/O port breakpoints), and 2 performance monitoring counters (which are "model specific" anyway).

For my own purposes, I've been working on this specification that defines a standardized set of feature flags that normal executables can rely on in my OS. It might be useful for other purposes though...

However, regardless of what you set for the minimum requirements there will be grey areas. For example, is a Cyrix 6x86 an 80486 compatible or is it a Pentium compatible?


Cheers,

Brendan