On Mon, 22 Feb 2016 11:30:08 +0100 Johnny Billquist <b...@softjar.se> wrote:
> On 2016-02-22 10:48, li...@openmailbox.org wrote: > > On Mon, 22 Feb 2016 10:07:10 +0100 > > Johnny Billquist <b...@softjar.se> wrote: > > > >> On 2016-02-22 07:07, li...@openmailbox.org wrote: > >>> However, we see that Intel's hardware compatability is only of > >>> academic interest because virtually none of the OS or apps for several > >>> generations of Intel chips runs on any remotely current Intel-hosted > >>> OS. I already pointed out many day-to-day incompatibilities between > >>> code running 32 bit vs. 64 etc. on Intel today. You can blame > >>> Microsoft or Bell Labs or even Richard Stallman but Intel has > >>> certainly been involved intimately with much OS development on its > >>> platform and has continued to bork time after time. > >> > >> You can't seriously mean that you think that a 32-bit application and a > >> 64-bit application would be expected to be compatible with each other? > >> I would expect the 32-bit code to work in 32-bit mode, but having it > >> work if you are in 64-bit mode is a ridiculous expectation. > > > > Really? It works fine on IBM's z/OS. > > Yes. And now you are talking about the OS, which manages parts of this. It's a combination of the hardware and OS working together to provide compatibility. It's not just one or the other but it is how things ought to be done. > > It seems ridiculous to me that you think it shouldn't. This is what I > > have been saying. IBM moved from 24 bit to 31 bit to 64 bit and > > everything still works. No expanded footprint, no duplicate libraries, > > no problem. > > There is no reason it couldn't work. You just said "You can't seriously mean that you think that a 32-bit application and a 64-bit application would be expected to be compatible with each other? I would expect the 32-bit code to work in 32-bit mode, but having it work if you are in 64-bit mode is a ridiculous expectation." > >> And the OS should detect that it's a 32-bit application, and set the > >> system up for running such an application with the CPU set the right > >> way. The CPU can do it. If things fail because the OS does things > >> wrong, you should not blame the CPU. > > > > I didn't blame the CPU. I said Intel's compatibility is really only > > academic and has no actual value in most cases: > > You did blame the CPU. You have been saying time and again that Intel > don't manage backward compatibility. Intel only do the CPU. So if you > blame Intel, it's only the CPU you can mean. First of all we are talking about upward/forward compatibility. Nobody ever argued on the backward compatibility point. I said Intel borked many aspects of various upgrades. That together with their work with various OS providers that cooperate with Intel to write their OS, is the problem. At the end of the day it means any claims of upward compatibility by Intel are strictly academic and not meaningful except on paper. If anything, Intel has burdened itself with tunnel vision on theoretical compatibility that brings tremendous legacy baggage and virtually no practical benefit. _______________________________________________ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh