OSDev.org

This "backward compatability" is advantageuos only from a commercial point of view and is not very efficient for e.g suppose the new 64bit computers try to provide 80286 etc support then this would be just a waste of its power. What do you think?

Neo wrote: This "backward compatability" is advantageuos only from a commercial point of view and is not very efficient for e.g suppose the new 64bit computers try to provide 80286 etc support then this would be just a waste of its power. What do you think?

The extra baggage backwards compatibility carries around is undeniable, but your example may somewhat distort the picture here. Are there any 286-specific items that can be eliminated from the new 64-bit design while still retaining compatibility with other existing 32-bit processors (i.e., 80386+)? Since the 386 was engineered to be compatible with the 286, I suspect that if compatibility was completely dropped with the 286, 386+ compatibility would also suffer. I could be terribly misguided (and please correct me if I am), but the way I see it is that dropping a lot of the "compatibility baggage" of an older processor will break the foundation of compatibility with any processor that succeeded it.

I don't think that the Itanium has 32bit support (ie it starts in long mode - 64bit) So no more mode changes

Well, dropping 32-bit support isn't smart; the userbase won't like being cut off from all the apps they are currently using. It probably explains why Intel is delaying their 64-bit entry into the desktop market, however.

I can confirm that Itanium does have 32-bit support, somewhat like V86 mode in 32-bit CPUs. In fact, I believe you can run a full 32-bit OS inside a 64-bit OS, alongside 64-bit applications, so in this sense 'V386' mode is more powerful than its 16-bit counterpart.

Neo wrote: yeah thats what i intend doing. no old relics only the new ones. btw will it be easy to port to the 64bit world or will that require rewriting of the entire code?
Any related info welcome.

Intel's 64-bit world or AMD's 64-bit world?

Since I'm planning to go to 64-bit AMD asap, I'm keeping every algorithm and piece of code in a way that it can be ported to AMD64 without any trouble as far as I can see. Memory management supports up to 3.75TB in 32-bit mode (physical memory that is), and up to 255PB in 64-bit mode (again, physical memory). If you want to know about AMD64, go to the AMD site for the docs on them. ordernr's 24572 + 24573 + 24574 + 26568 + 26569 (if I'm not mistaking that is). In short, no hardware task switching, no segmentation (although it does support using FS and GS base registers), way less overhead from those things .

Anyway, just ask for details

AFAIK, the Itanium does have a 32bit emulation mode, which however is not "transparent" as the AMD approach.

(Sorry, no details from me, just recalling headlines.)

On "286" compatibility: Note that the current architecture is "IA32", with the first CPU of that generation being the 386. Compatibility with 286 has been a non-issue for quite some time now AFAIK. (You won't find a 286-compiled Linux version, for example.)

Solar wrote: On "286" compatibility: Note that the current architecture is "IA32", with the first CPU of that generation being the 386. Compatibility with 286 has been a non-issue for quite some time now AFAIK. (You won't find a 286-compiled Linux version, for example.)

no, but you have 286 call gates and 286 task state segment descriptors in any IA-32 processor, and the obsolete "SMSW" and 'LMSW" instructions (which are redundant with mov cr0,... and mov ...,cr0) are still supported aswell ...

Look at the PS2 with its PS1 chip for backward compatibility! having the immediate benefit of a large software library is definitely a mastercard (french: "atout") for selling your hardware.

Solar wrote: (You won't find a 286-compiled Linux version, for example.)

Why would you say that was true? Maybe because Linux was developed by Linus to learn about the 386 in the first place?

Candy wrote:

Solar wrote: (You won't find a 286-compiled Linux version, for example.)

Why would you say that was true? Maybe because Linux was developed by Linus to learn about the 386 in the first place?

Let's put it this way: With Linux being what it is, if it were possible to back-port Linux to the 286 without much ado, don't you think they would have done it by now?

Many generic distributions target the i386. Not because so many people still have such a system, but because you can use the same binary on i386 through PIV systems without major impacts. (Well, performance takes somewhat of a hit on the faster systems, but then they have more MHz anyway.)

The 286 is a different beast, that's why there are no 286 Linux compiles.

The 286 is a different beast, that's why there are no 286 Linux compiles.

Actually the truth could be a lot simpler than that. I don't recall GCC supporting a 286 target. No GNU toolchain, no Linux, end of story.

afaik, there's some 8086 port of Linux ... well, pretty different from the 386 version, but still linux.