This discussion has very much diverged from the original topics of VAX/VMS and ISA compatibility. If folks want to discuss the actions or inactions, who did what *etc*… let’s take that off list.
I will try to come back to what I started with: Some people on this list (including me), believe that Intel has done a pretty reasonable job of compatibility as it moved from generation to generation from its original 4004 microprocessor to today’s Intel*64 ISA From reading the comments, others may not think the Intel team did, fair enough. Also, other firms such as IBM and DEC had done the same with their ISA (S360 and Vax in those cases). As has been pointed out, each of three firms mentioned have injected some level of incompatibility along the way. The question of how a good a job they did is likely to be gauged on how it affected you personally. I personally find the ability to be able to boot a really old OS and run really old programs on a modern chip to be handy. Since this is a forum on simulation, I would have thought others considered that a pretty important feature. But maybe it is not. 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 have also pointed out (as have others) that Intel also did not try to be compatible with all its lines, which others consider that a negative for Intel’s commitment to compatibility. In fact is in almost every case except one that I can think, when Intel broke away from the compatibility path that became today's INTEL*64 ISA, Intel was not as successful in the market (I'm thinking i432, 860, 960, Itanium) – the one success I can think of where they were not compatible and were still successful was in their embedded line which was originally the 8748 (which became the 8051). I suppose it also can be pointed out that the 860/960 ended up have a fairly long life also in the embedded space and were "successful" there. But those ISAs were eventually EOL’s; while you can still find 8051 ISA based chips being manufactured today. Others in this list seem to object to the fact the current INTEL*64 ISA is owned and defined by Intel, not by a competing firm who originally created an extension to the x86 (ney IA-32) ISA before Intel and brought it to market in their product line. Fair enough and I personally think I understand why people might believe that and I do understand and lived the same history. But I point out that it does not change the fact that Intel owns and defines ISA, it >>is<< Intel’s ISA. Someone else does not get to call it something else when they do not own it. Just as the PDP-11, Vax & Alpha were DEC’s ISAs and S360, S/370 & Power is/was IBM’s. Think about 2 other instances, Cal Data extended the PDP-11 before DEC did and Amdahl the S/360 before IBM. As it turns out, DEC sued and put Cal Data out of business but IBM let Amdahl be. In both cases features first pioneered on those other product lines, end up in the original (although maybe with a different name and/or different implementation). But the ISA stayed S/360 and PDP-11 and the owners of each further extended their ISA along the way (S/370, now zSeries, PDP-11 begat VAX 11/780). I ask you for a minute to consider this set of facts. When the engineers at Intel did decide to extend IA32 to 64 bits (which was after others had done it), the Intel engineering team could have created a set of extensions to the x86 family that was different from others currently on the market. We can all guess, but none of us on this list or elsewhere will ever know if taking that design choice would have been successful -- as that choice was made 15 years ago. I think we might agree that a good bit of chaos would have been brought to us as programmers. Instead, the Intel engineers started with an existing set of extensions, and added too (and continued to add too) that list. Intel has brought out many devices since that time and the market has moved on. The choices made by the Intel team does not lessen or make greater the work done by Intel or it’s competitors. It is what it is. I believe that what matters to us as programmers, is that our code runs on those devices – *that they are compatible *- the topic of this discussion. That is to say, I am happy a different path was not chosen. It certainly made my own choices simpler. For the record, the main system I run at home as “ccc.com” happens to be on an Opteron and have no reason to change it. It has a good bit of SCSI storage on it, as well a number of different types of tapes. It “just works” and OpenBSD runs fine “out of the box”. The truth is if I changed it, I’m probably more likely to switch to an unused Tru64 based DS10 with an Alpha in it than an Intel processor because I have one in the basement that is currently turned off. However, that system does not have as many free SCSI channels as the Opteron does and the OpenBSD box just works. So it remains with lots of fan, noise and heat, as it is. Also, as a computer scientist, I personally detest the technical aspects of INTEL*64 ISA. For an ISA, I’m unabashedly an Alpha believer. But the fact is DEC broke from compatibility when the Alpha was created. And as has been pointed out Intel/HP did the same with Itanium. But unlike DEC, which threw everything into Alpha, Intel did not abandoned x86. Once the team at Intel was realized that IA32 could have a future, the company started to reinvest. And when Alpha failed in the market (for whatever reasons), sadly Alpha died. Which brings be to my primary point about compatibility. Compatibility is an economic argument, not a technical one and we often forget that. I am glad that because Intel decided to stay in (come back too) the main stream business (IA32) and created INTEL*64 for them to compete, the price was driven down. As a consumer, I believe that having options is good. I personally think this is a case where the market caused the right thing to occur. ‘nuf said – so unless you want to talk about the compatibility thread, please take it off line.
_______________________________________________ Simh mailing list [email protected] http://mailman.trailing-edge.com/mailman/listinfo/simh
