Talk:IBM System/370

From Wikipedia, the free encyclopedia
Jump to: navigation, search
WikiProject Computing / Hardware (Rated Start-class, High-importance)
WikiProject icon This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
Start-Class article Start  This article has been rated as Start-Class on the project's quality scale.
 High  This article has been rated as High-importance on the project's importance scale.
Taskforce icon
This article is supported by Computer hardware task force (marked as High-importance).
WikiProject Technology (Rated Start-class)
WikiProject icon This article is within the scope of WikiProject Technology, a collaborative effort to improve the coverage of technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
Start-Class article Start  This article has been rated as Start-Class on the project's quality scale.


It would be useful to have some comparison with the performance of other systems of the same era, and possibly a comparison with a processor of today with which readers are likely to be familiar. (talk) 15:19, 3 October 2012 (UTC)

Performance comparisons would b a bit dicey for several reasons
  • Overal performance debends of the balance between CPU load and I/O load
  • Both the S/370 and competitive lines ran over multiple models with different performance profiles
  • Even for CPU performance on a single product line, speed ratios depend on the exact instruction mix used.
  • Multiprocessor interference depends very much on details of the OS
I can see someone throwing in some rough timing metrics, but it would be very easy to draw incorrect conclussions from them unless the text included appropriate warnsings. Shmuel (Seymour J.) Metz Username:Chatul (talk) 15:31, 5 October 2012 (UTC)

Level of detail for 370/145?[edit]

It is misleading to state that The S/370-145 had relocation hardware (implemented in microcode) from its first shipments in June 1971. More precisely, the original microcode on the 370/145 had microcode for the OS DOS compatibility feature, but not for paging. A new floppy disk provided the microcode to support paging. I'm not sure whether to update the article only to clarify that the paging microcode was not in the initial version or also to mention the 8-line associative memory in the initial shipment that was used by both the old and new microcode. Shmuel (Seymour J.) Metz Username:Chatul (talk) 19:07, 11 December 2012 (UTC)

Page for the parts of the architecture that have remained the same for all S/3x0 architectures?[edit]

IBM System/360 architecture and this page have a number of details that really didn't change much from S/360 to S/390, such as the GPRs, the FPRs, the data formats, and, I think, at least some of the exceptions. Problem-state instructions were added over time, but that also applies to x86, 68k, SPARC, MIPS, PA-RISC, etc..

Should there be a page to cover the common parts of all S/3x0 architectures, with other pages discussing the major changes (DAT, 31-bit addressing, I/O interface changes), etc.?

I'm not sure what the right thing is to do about z/Architecture; ISAs that went from 32-bit to 64-bit varied from "we made the registers twice as wide, changed the page tables to handle bigger addresses, and added 64-bit load, store, and (if relevant) arithmetic instructions" (several RISC architectures) throught "we did all that, got rid of most of the segmentation stuff, added instruction-relative addressing, and doubled the number of registers" (x86-64) to "we made the registers twice as wide, doubled the number of them, changed the page tables to handle bigger addresses, and added 64-bit load and store instructions - oh, and we got rid of conditional execution for most instructions" (64-bit ARM). x86-64 has its own page, which, given the changes, is probably the right thing; 64-bit ARM doesn't, which, given the changes, might not be the right thing. I don't know where z/Architecture fits on the scale. Guy Harris (talk) 22:58, 15 September 2013 (UTC)

I'm not sure what to do about the common features, but there is some background to take into account. The major changes were DAT, XA, ESA and 64-bit virtual. Each of these changed the addressing as seen by unprivileged code. In what follows, I will not be dealing with how the OS was affected by the changes, only how application code was affected.
For the transition to DAT, the major visible change was that accesses to unallocated memory could cause a program exception even if the virtual address was within the region. This resulted in the failure of programs that had been "working" for years, sometimes revealing that they had been giving incorrect results.
For the transition to DAT, existing code was only affected if it referred to OS control blocks above the 16 MiB line, but new code could run in either 24-bit or 31-bit mode.
For the transition to ESA, memory access could still only be 24-bit or 31-bit, but there was a new AR mode that allowed access to multiple data spaces through a set of access registers. As with XA, you mostly only had to change your code if you wanted to exploit the new mode.
64-bit real only affected programs that dealt with real channel programs.
64-bit virtual again provided a new mode. While general registers are now 64 bits wide, code running in 24-bit and 31-bit modes can generally ignore the high 32 bits. In 64-bit mode, addressing uses all 64 bits of base and index registers.
Note that programs can use long displacement instructions even in 24-bit mode. Similarly, the upper 32 bits of a general register for arithmetic, although not for addressing.
IBM added new formats for save areas at various times, but those pertain to the OS rather than to the architecture. Shmuel (Seymour J.) Metz Username:Chatul (talk) 21:17, 16 September 2013 (UTC)
Yes, that's why I mentioned them as "the major changes" (I forgot about the ESA stuff).
Most 32-bit ISAs these days were "born" with some form of address translation, either in the ISA itself (VAX, IA-32, and MIPS, for example) or in the systems in which it's used even if the MMU itself wasn't part of the ISA or wasn't originally part of the ISA (68k - even with the 68000 there were some machines with two processors to work around the non-restartability of instructions after bus errors, and that was fixed in the 68010 - and SPARC, for example) - so they didn't have the "paging was added" transition. S/3x0, being much older than the others, was different in that regard.
Most of them also didn't have "we ignore some address bits" architected in at the beginning; the one exception I can think of is 68k, and I don't know whether that was explicitly given as a feature of the architecture or was given as "we ignore those bits in the 68000, but don't assume they'll be ignored forever". It did have such a transition, at least on the Mac, although Sun, I think, made it clear from the beginning that you Should Not Stuff Extra Stuff Into The Upper 8 Bits Of A Pointer, and people used to writing code for BSD on VAXes already knew that wouldn't necessarily work.
So a discussion of the S/3x0 architecture(s) has to do things for various flavors of the 32-bit architecture that don't have to be done for most other 32-bit ISAs.
But the "General-purpose registers" and "Floating-point registers" charts in IBM System/360 architecture and IBM System/370 are identical, and most of the "Features", "Memory", "Addressing", "Data formats", and "Instruction formats" sections of IBM System/360 architecture, and most of the first three top-level items in the "Architecture details" list in IBM System/370, apply to both (the only parts of the latter list that don't apply to S/360 are the control registers, the PSW in extended-control mode, and some of the timing facilities).
FWIW, I added the CPU register tables to both articles (as well as several other CPUs), but they need to be double-checked for accuracy by someone more familiar with the S/360 and S/370 architectures than me. In particular, I'm not clear on the organization of the CRn control registers, and I did not show most of the individual parts of the PSW (although I'm not sure we even need to). — Loadmaster (talk) 22:00, 17 September 2013 (UTC)
The control registers have enough different fields that I'd advise adding a reference to "Assignment of Control-Register Fields". IBM System/370 Principles of Operation (PDF) (Eleventh ed.). IBM. September 1987. pp. 4–10–4–11. GA22-7000-10.  rather than putting the individual fields in the table.
I agree; the CPU register table is meant to be a visual depiction of the CPU structure, but should not be excessively detailed. Showing individual control flags is about as detailed as it needs to be, and even that might be overkill for some particularly complex CPUs. Labeling each bit of each CR is definitely on the overkill/too-much-information side of things. — Loadmaster (talk) 17:42, 3 October 2013 (UTC)
Style question: when the page number includes a hypen, how should I show a range of pages in the {{cite manual}}?
I would use extra spaces (e.g., "4-10 - 4-11"), or periods (e.g., "4.10-4.11"), or the word 'to' (e.g., "4-10 to 4-11"), but I don't know what the WP recommended practice is. — Loadmaster (talk) 17:42, 3 October 2013 (UTC)
The bit numbering is inconsistent. If you use the IBM convention for the PSW then you should use it for the other registers. Also, The EC format of the PSW is more important than the BC format, although my preference would be to show both. Shmuel (Seymour J.) Metz Username:Chatul (talk) 15:15, 3 October 2013 (UTC)
How to do the bit numbering comes down to whether we want to be consistent with the manufacturer's numbering, or consistent across multiple WP articles having similar CPU register tables. For the first approach, the tables provide a visual depiction that should complement the text description of the CPU. For the second approach, the tables provide the user a common visual frame of reference to understand the CPU capabilities, particularly as compared to other CPUs. I probably lean towards the first approach, since CPUs may differ enough that trying to come up with a common bit numbering for all CPUs may ultimately be too difficult. But further opinions from other editors are needed. — Loadmaster (talk) 17:36, 3 October 2013 (UTC)
I think it's best to stick to the IBM conventions or it will be confusing. I think the "progression" would show both BC and EC PSWs. Peter Flass (talk) 20:22, 3 October 2013 (UTC)
One possibility might be to have an "IBM System/3x0 architecture" page that starts out with the common stuff and then has subsections for S/360, S/370, S/370-XA, and S/370-ESA and S/390-ESA. Whether to describe "S/3100" :-), a/k/a z/Architecture, there is another matter; as indicated, some 32->64-bit architectures have separate pages for the 64-bit version, others don't. Perhaps having a short section for z/Architecture, with a "main article" link to the z/Architecture page, is the right way to go. Guy Harris (talk) 22:19, 16 September 2013 (UTC)
I like the idea of starting out with the common/old stuff, then adding individual sections to discuss the additions and extensions for each subsequent model. Since there is no "standard" Wikipedia approach for this, we should probably use a historical feature progression as the basis for the article structure. — Loadmaster (talk) 22:00, 17 September 2013 (UTC)