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

[lists]

On Mon, 22 Feb 2016 11:13:37 -
"Dave Wade"  wrote:

> > >
> > > 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.
> > 
> > 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.
> > 
> 
> That’s not (quite) true. As I said before problem state code works fine.

That is 99.9% of all applications code.

> Anything that uses supervisor mode will likely fail. 

Absolutely not true. I don't know of any code we wrote for XA and ESA that
runs sup state that had any problems going forward. We continue to support
ESA code to this day. I can't remember anything that failed. I also can't
remember an OS service that wasn't upward compatible.
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

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

[Dave Wade]

> >
> > 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.
> 
> 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.
> 

That’s not (quite) true. As I said before problem state code works fine. 
Anything that uses supervisor mode will likely fail. 

It took IBM a lot of work, microcode (SIE instruction) and a new Hypervisor to 
get from MVS/SP to MVS/XA.
I am told VM/XA only exits because they needed it to debug MVS/XA.

There is much more I info about IBM and especially VM's history on Melinda 
Varian's home page:-

http://www.leeandmelindavarian.com/Melinda/

and as for backwards compatibility the book "The soul of a new machine"

http://www.amazon.co.uk/The-Soul-Machine-Modern-Library/dp/0679602615 

has some interesting observations about building a new machine...

Dave
G4UGM

___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

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

[Johnny Billquist]

On 2016-02-22 10:48, li...@openmailbox.org wrote:

On Mon, 22 Feb 2016 10:07:10 +0100
Johnny Billquist  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 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.


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.



We all know at the end of the day people buy hardware to run apps. We
also know most of the apps ever written for Intel are no longer useful
even if you could boot obsolete OS and run them. Any meaningful notion
of compatibility has to include the ability to continue to run your
apps on every new OS and hardware generation. With Intel you can't. You
can point all the fingers you want but that is the reality in the Intel
environment.

In practice, several decades of software and development investment,
applications, and OS go up in smoke with each new generation of Intel
chips. In contrast IBM has preserved the customer's investments in
technology, development, and applications. IBM takes the loss on the OS
development but the customer's applications continue to run forever on
the latest platform. Intel is an ecosystem of churning, turmoil and
waste. That's something only an accountant could love.


I think you are confusing the backware compatibility in the processor,
which is working just fine, with the less than stellar backward
compatibility in various OSes along the way, which is nothing you should
blame on Intel.


I'm comparing Intel's shortcomings and consistent track record of borks to
what I have seen done well by IBM. It was all there for Intel and the
developers who write for it to see how things were done right, but they
kept making mistakes. There's just no excuse for most of the decisions.
Except possibly from Intel's accounting viewpoint as was discussed.


And here we go again. You point the finger at Intel, while in truth the 
CPU can do the work just fine. And you compare with IBM, and more 
specifically what their OS handles, which is not meaningful to compare 
to what Intel is doing, as Intel is not doing OSes.



Like I said, grab an old DOS floppy, pop it into a a new machine, and it
will boot. That's a fact.


See above. That doesn't really help the 99.9 bar percent of people that
spent money on DOS and DOS apps and countless other OS and software that
don't run on Windows on modern hardware.


No. But you can boot your DOS on the modern hardware, and still run the 
software. The backward compatibility in the hardware is there. I have no 
problems with you complaining that Microsoft sucks. I also have no 
issues with complaints that Intel made a horrible CPU. But it's stupid 
to say they don't manage backward compatibility, when it is so obvious 
that they do.


Johnny

___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

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

[lists]

On Mon, 22 Feb 2016 10:07:10 +0100
Johnny Billquist  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.

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.

> 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:

> > We all know at the end of the day people buy hardware to run apps. We
> > also know most of the apps ever written for Intel are no longer useful
> > even if you could boot obsolete OS and run them. Any meaningful notion
> > of compatibility has to include the ability to continue to run your
> > apps on every new OS and hardware generation. With Intel you can't. You
> > can point all the fingers you want but that is the reality in the Intel
> > environment.
> >
> > In practice, several decades of software and development investment,
> > applications, and OS go up in smoke with each new generation of Intel
> > chips. In contrast IBM has preserved the customer's investments in
> > technology, development, and applications. IBM takes the loss on the OS
> > development but the customer's applications continue to run forever on
> > the latest platform. Intel is an ecosystem of churning, turmoil and
> > waste. That's something only an accountant could love.
> 
> I think you are confusing the backware compatibility in the processor, 
> which is working just fine, with the less than stellar backward 
> compatibility in various OSes along the way, which is nothing you should 
> blame on Intel.

I'm comparing Intel's shortcomings and consistent track record of borks to
what I have seen done well by IBM. It was all there for Intel and the
developers who write for it to see how things were done right, but they
kept making mistakes. There's just no excuse for most of the decisions.
Except possibly from Intel's accounting viewpoint as was discussed.

> Like I said, grab an old DOS floppy, pop it into a a new machine, and it 
> will boot. That's a fact.

See above. That doesn't really help the 99.9 bar percent of people that
spent money on DOS and DOS apps and countless other OS and software that
don't run on Windows on modern hardware.

> > As has been noted code from virtually the beginning of OS/360 still runs
> > today and furthermore can happily coexist with newly written apps
> > without any hoop jumping like relinking, recompiling, or needing
> > multiple libraries. It just continues to work. Software compatibility
> > beats hardware compatibility any day of the week. What's important is
> > that your application and development investment continues to be viable
> > on each new hardware platform with each new OS. That is what IBM has
> > done, and it is a combination of hardware and software designed to work
> > together and boy does it ever, as opposed to a pizza with everything on
> > it spoiled by too many chefs.
> 
> Yes. IBM has done an excellent job.

It's not just excellent in the abstract. It's the best example we have in
the history of computing of how good engineering and upward compatability
as fundamental design principles preserves the investment in software and
development skills. Virtually everything that ever ran since the beginning
of OS/360 in 1964 still runs on the latest hardware and OS here in 2016,
all without recompiling or relinking or duplicate libraries, etc.
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

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

[Johnny Billquist]

On 2016-02-22 07:07, li...@openmailbox.org wrote:

On Sun, 21 Feb 2016 08:50:45 -0500
Clem Cole  wrote:


To pick on DEC (or IBM), the later generations of their respective ISAs
cannot boot the older OS – which Intel’s primary ISA can – and that is
what started this discussion.


I can't speak to DEC's issues but with IBM has already been said, this was
by design. They were selling hardware. The OS and program products helped
them do that.

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. 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.



We all know at the end of the day people buy hardware to run apps. We
also know most of the apps ever written for Intel are no longer useful even
if you could boot obsolete OS and run them. Any meaningful notion of
compatibility has to include the ability to continue to run your apps on
every new OS and hardware generation. With Intel you can't. You can point
all the fingers you want but that is the reality in the Intel environment.

In practice, several decades of software and development investment,
applications, and OS go up in smoke with each new generation of Intel
chips. In contrast IBM has preserved the customer's investments in
technology, development, and applications. IBM takes the loss on the OS
development but the customer's applications continue to run forever on the
latest platform. Intel is an ecosystem of churning, turmoil and waste.
That's something only an accountant could love.


I think you are confusing the backware compatibility in the processor, 
which is working just fine, with the less than stellar backward 
compatibility in various OSes along the way, which is nothing you should 
blame on Intel.


Like I said, grab an old DOS floppy, pop it into a a new machine, and it 
will boot. That's a fact.



As has been noted code from virtually the beginning of OS/360 still runs
today and furthermore can happily coexist with newly written apps without
any hoop jumping like relinking, recompiling, or needing multiple
libraries. It just continues to work. Software compatibility beats hardware
compatibility any day of the week. What's important is that your
application and development investment continues to be viable on each new
hardware platform with each new OS. That is what IBM has done, and it is a
combination of hardware and software designed to work together and boy does
it ever, as opposed to a pizza with everything on it spoiled by too many
chefs.


Yes. IBM has done an excellent job.

Johnny

--
Johnny Billquist  || "I'm on a bus
  ||  on a psychedelic trip
email: b...@softjar.se ||  Reading murder books
pdp is alive! ||  tryin' to stay hip" - B. Idol
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

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

[lists]

On Sun, 21 Feb 2016 08:50:45 -0500
Clem Cole  wrote:

> To pick on DEC (or IBM), the later generations of their respective ISAs
> cannot boot the older OS – which Intel’s primary ISA can – and that is
> what started this discussion.

I can't speak to DEC's issues but with IBM has already been said, this was
by design. They were selling hardware. The OS and program products helped
them do that.

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. 

We all know at the end of the day people buy hardware to run apps. We
also know most of the apps ever written for Intel are no longer useful even
if you could boot obsolete OS and run them. Any meaningful notion of
compatibility has to include the ability to continue to run your apps on
every new OS and hardware generation. With Intel you can't. You can point
all the fingers you want but that is the reality in the Intel environment.

In practice, several decades of software and development investment,
applications, and OS go up in smoke with each new generation of Intel
chips. In contrast IBM has preserved the customer's investments in
technology, development, and applications. IBM takes the loss on the OS
development but the customer's applications continue to run forever on the
latest platform. Intel is an ecosystem of churning, turmoil and waste.
That's something only an accountant could love.

As has been noted code from virtually the beginning of OS/360 still runs
today and furthermore can happily coexist with newly written apps without
any hoop jumping like relinking, recompiling, or needing multiple
libraries. It just continues to work. Software compatibility beats hardware
compatibility any day of the week. What's important is that your
application and development investment continues to be viable on each new
hardware platform with each new OS. That is what IBM has done, and it is a
combination of hardware and software designed to work together and boy does
it ever, as opposed to a pizza with everything on it spoiled by too many
chefs.

In terms of rubber meets the road upward compatibility what IBM has
delivered over the lifetime of OS/360->MVS-XA-ESA-z is infinitely more
valuable than compatibility on paper that nobody who runs Intel has ever
been able to take any practical advantage of.
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh