I was deliberately ignoring the 67 (&47) as they were very much “specials”. I cut my teeth on the 360/67 at Newcastle Upon Type under MTS, (and OS/MVT) but MTS was never generally available, MVS and later won’t run on the 360/67, and TSS pretty much died a death. Even CP/47 and CP/67 had a major re-write to become VM/370… The 360/67 actually had 32 bit addressing rather than 31-bit that’s XA and S/390. Also as for comparison with the VAX on memory cabinet which I think had 64K Bytes is about the same size as a large VAX. This is the Newcastle 360/67 with 512K of Core and the DAT gate open… http://history.cs.ncl.ac.uk/anniversaries/40th/images/ibm360_672/slide07.jpg and a close view of the core cabinet here:- http://history.cs.ncl.ac.uk/anniversaries/40th/images/ibm360_672/21.html I think it is also interesting to compare the Intel architecture which was designed to be economical with Silicon against the M6800, M6809 and the M68000 which were designed to be programmer friendly, and of course note the similarities between the 68000 & S/360 with 16 general purpose registers and orthogonal instruction set) and wonder where we would be today had IBM chosen them for its PC rather than the 8086 which I assume was cheaper… Dave G4UGM From: Clem Cole [mailto:cl...@ccc.com] Sent: 16 February 2016 13:58 To: Dave Wade <dave.g4...@gmail.com> Cc: SIMH <simh@trailing-edge.com> Subject: Re: [Simh] VAX/VMS Dave be careful -- S/360 Model 67 has VM in the late 1960's - TSS and it's brother MTS, both rely on it. The 67 is a Model 65 with a Data Address Translation unit (DAT box) - is supplied by a 8 x 32 bit TLB which is in a cabinet that t'ed off the main CPU and is about the same size en entire Vax 780 which would follow 10 years later. Think about that for a minute -- an 8 word TLB. At Intel we regularly examine the different sizes of the different parts of the memory system. Core 7 (aka Nehalem of a few years ago) has a two-level TLB: the first level of TLB is shared between data and instructions. The level 1 data TLB now stores 64 entries for small pages (4K) or 32 for large pages (2M/4M), while the level 1 instruction TLB stores 128 entries for small pages (the same as with Core 2) and seven for large pages. The second level is a unified cache that can store up to 512 entries and operates only with small pages. Also it is also interesting to consider that while the AT&T folks came off of Multics, a number of us university types that would work on earlier Unix came from TSS and MTS (one 360/67). In fact, TSS is still the only system I ever used that lived in the debugger as your command system - which I always thought was a cool idea. As for what started this thread. I think it is interesting that the long term successful architectures in the market did have a excellent compatibility stories. IBM with system 360 certainly set a high bar, and DEC has nothing to be ashamed of, the different DEC lines, particularly the Vax, did a great job here. In truth, probably the best of pure compatibility story has to be Intel. The H/L registers of the 4004 are still there ;-) Seriously, the INTEL*64 is from an computer science standpoint, not an architecture you would create from scratch. But Intel has completely understood the economics of SW compatibility. Also, if you peeked inside a modern processor, you would discover they are dataflow engines and put together with all of the modern computer science; but there is about a 5% silicon tax paid for compatibility. Clearly, my siblings at Intel believe it's worth tax and the customers seem to keep wanting it. Clem On Tue, Feb 16, 2016 at 8:15 AM, Dave Wade <dave.g4...@gmail.com <mailto:dave.g4...@gmail.com> > wrote: > -----Original Message----- > From: Simh [mailto:simh-boun...@trailing-edge.com > <mailto:simh-boun...@trailing-edge.com> ] On Behalf Of Wilm > Boerhout > Sent: 16 February 2016 11:58 > To: simh@trailing-edge.com <mailto:simh@trailing-edge.com> > Subject: Re: [Simh] VAX/VMS > > Johnny Billquist schreef op 16-2-2016 om 12:49: > > > > No, it is not. Talk to IBM about S/360... :-) And there are some VAXen
S/360 compatibility is only forward, and only to a certain point. S/360 and S/370 are both 24-bit addressing and fairly compatible, but S/370 (Mostly) has Virtual Memory as standard. Then came the "great divide" S/370XA. XA mode has 31-bit addressing and different I/O instructions. Some of the XA boxes will work is S/370 mode, but many won't. More recently IBM moved to 64-bit hardware. Again some will boot in 31-bit mode but more recent boxes need a 64-bit OS. So the earliest incarnations of "OS", which were I guess "MFT" which is basically a fixed number of partitions will run on later machines until you get to systems which will only run in 31bit mode. (XA Mode). OS/VS2 and its siblings MVS (This is the free version), MVS/SP (The paid for version) will only run on S/370 or later, not on 360, as they need Virtual Memory and it stops working at the same point as MFT when 31 bit only machines appear. There are also issues of Virtual Memory Page size which may stop MVS (the free version working) working on some hardware (there are patches to work round this). You also have issues over disk (DASD in IBM speak) support. So whilst MFT was written for a 1996 S/360 it would in theory run on an P390E from 1996 so 30 years of computability. However, it would need older disks, which the P/390E cannot support. Of course these changes are really only to do with programs that run in supervisor state. User mode programs generally will run unchanged from 1966 through to the present day, and the latest zOS a descendant of MVS will still run 24-bit applications. I am pretty sure that until a few years many commercial sites, so mostly Cobol, still used the older "free" Fortran-66 compiler for the odd Fortran job. > > on which V7.3 will definitely not run. How about rtVAX for example. > > > I stand corrected. Please note that I had a marketing job once. It sticks... ... I also believe that some of the in-compatibility in IBM kit is to drive the hardware->software->Hardware->Software upgrade chain and keep the dollars rolling in... Dave G4UGM > _______________________________________________ > Simh mailing list > Simh@trailing-edge.com <mailto:Simh@trailing-edge.com> > http://mailman.trailing-edge.com/mailman/listinfo/simh _______________________________________________ Simh mailing list Simh@trailing-edge.com <mailto:Simh@trailing-edge.com> http://mailman.trailing-edge.com/mailman/listinfo/simh
_______________________________________________ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
