[Simh] Compatibility you can use Was: VAX/VMS

[lists at openmailbox.org]

On Mon, 22 Feb 2016 11:30:08 +0100
Johnny Billquist <bqt at softjar.se> wrote:

> On 2016-02-22 10:48, lists at openmailbox.org wrote:
> > On Mon, 22 Feb 2016 10:07:10 +0100
> > Johnny Billquist <bqt at softjar.se> wrote:
> >
> >> On 2016-02-22 07:07, lists at 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.