Talk:Asymmetric multiprocessing

External links modified

Hello fellow Wikipedians,

I have just modified one external link on Asymmetric multiprocessing. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

• Added archive https://web.archive.org/web/20050208000902/http://ed-thelen.org:80/comp-hist/CDC-6600-R-M.html to http://ed-thelen.org/comp-hist/CDC-6600-R-M.html#TOC/

When you have finished reviewing my changes, please set the checked parameter below to true or failed to let others know (documentation at {{Sourcecheck}}).

Y An editor has reviewed this edit and fixed any errors that were found.

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 11:29, 20 October 2016 (UTC)

definition of multiprocessing

The following text was removed recently: “Multiprocessing is the use of more than one CPU in a computer system. The CPU is the arithmetic and logic engine that executes user applications. With multiple CPUs, more than one set of program instructions can be executed at the same time. All of the CPUs have the same user-mode instruction set, so a running job can be rescheduled from one CPU to another.” I think it is important to define what Multiprocessing means in the context of Asymetric Multiprocessing. Would anyone object if I restored this text? John Sauter (talk) 21:18, 13 March 2019 (UTC)

In what way does the multiprocessing link in the first sentence not suffice to point the user to a page that obviously should define multiprocessing? If multiprocessing doesn't define it sufficiently, it should be changed to do so. Guy Harris (talk) 22:05, 13 March 2019 (UTC)

Not necessarily speaking to this article, but sometimes it seems better to me to put a one-line definition of the general case in an article on a specific case. Peter Flass (talk) 00:59, 14 March 2019 (UTC)

1. It would have been helpful had you identified the revision in question.
2. One obvious reason is that the definition is incorrect. E.g., in the CDC 6600, the ten PPs have a different instruction set from the CP. Note that the operating systems for the 6600 generally run in the PPs rather than in the CP. Shmuel (Seymour J.) Metz Username:Chatul (talk) 16:17, 14 March 2019 (UTC)

I'm not sure the 6600 would be an example of multiprocessing, asymmetric or otherwise. A pp could be equated to an intelligent channel, except for that OS thingy. Peter Flass (talk) 16:58, 14 March 2019 (UTC)

"Except for that OS thingy" is rather a big thing. How important does a processor inside a system have to be in order for a system with more then one processor to be a multiprocessor?

For most systems with an operating system, one or more of the "central" processing unit(s) ran the operating system; if there are other processors, they're running dedicated tasks. If you have an IBM 3090 with one processor running the S/370 instruction set, and one or more channel controllers running a program, consisting of IBM 801 instructions, that, in turn, executes channel programs, I could see that not being deemed a multiprocessor, just as I wouldn't count the baseband processor in my iPhone in the processor count on my iPhone, even though it's probably an ARM core just as the two application processors are ARM cores.

With the 6600, however, there's a "CPU" whose job it is to crunch numbers, and, as I understand it, it doesn't decide which process to run next, a PP does that. Do the PPs also, for example, process the job control language, or do they run a program on the CP for that?

I don't know how it worked in NOS and NOS/BE, but in SCOPE the control card scanning, dispatching and pretty much everything else ran in the PPs. The utilities and language processors ran in the CP. Shmuel (Seymour J.) Metz Username:Chatul (talk) 14:36, 15 March 2019 (UTC)

Most of the multiprocessor page deals with systems where all processors run the same instruction set. (In that category, I include systems such as ARM big.LITTLE systems where both types of core can run at the same time, and the Apple A10/Apple A11/Apple A12, where the processors all run the same instruction set, but not all have the same microarchitecture, with some being high-powered, in both senses of the word, and others aren't as powerful but don't consume as much power, as those run similarly to an SMP system, but with process/thread schedulers that put threads that need heavy CPU onto the more powerful processors and others on the less powerful processors, and power up the more powerful processors only if they have a thread to run.)

I view the CDC 6600 as an example of heterogeneous computing. That page explicitly describes big.LITTLE as "more like a symmetric multiprocessor":

For example, ARM big.LITTLE is an exception where the ISAs of cores are the same and heterogeneity refers to the speed of different microarchitectures of the same ISA, thus making it more like a symmetric multiprocessor (SMP).

so I wouldn't classify that as an example of heterogeneous computing.

Note that there are ten (expandable to 20) PPs, not just one. Shmuel (Seymour J.) Metz Username:Chatul (talk) 14:36, 15 March 2019 (UTC)

ASMP and SMP generally both refer to systems where all processors support the same instruction set; the asymmetry is either a hardware-layer asymmetry in access to peripherals, or a software-layer asymmetry in which, for example, low-level OS code only runs on one processor (rather than being able to run on any processor, but with a giant lock around the kernel code, so it can only run on one processor at a time).

So which of the "more than one processing unit of some type" scenarios does "multiprocessing" cover? The ones where all processors run the same ISA, with other scenarios being "heterogeneous computing" (and with the "same ISA, but different microarchitectures" scenario possibly being both), and where all processors are equally capable of running application/userland/"problem state" code? Guy Harris (talk) 20:32, 14 March 2019 (UTC)

References

Why 1108?

Why is the Univac 1108 listed here instead of in Symmetric multiprocessing? The processors were identical and the OSdispatched work to whatever processor was available; no processor had a distinguished role. Shmuel (Seymour J.) Metz Username:Chatul (talk) 19:11, 27 September 2019 (UTC)

So it sounds as if, "from the surviving documentation", it's clear "where that operating system was on the path from asymmetric to symmetric multiprocessing", i.e. it made it to symmetric multiprocessing; "ABOVE THIS BASIC LEVEL, ANY OF THE AVAILABLE PROCESSORS CAN PERFORM A GIVEN TASK" (page 7-3 of the Exec 8 programmer's reference) is pretty clear - the only distinction appears to be that some devices are connected to particular processors. The 1108 II was apparently the first MP model, as per UNIVAC 1100/2200 series#1108; symmetric multiprocessing mentions it.

I'll just be bold and remove it from this page. Guy Harris (talk) 20:57, 27 September 2019 (UTC)

The article says:

Other AMP systems might allow any CPU to execute operating system code and perform I/O operations, so that they were symmetric with regard to processor roles, but attached some or all peripherals to particular CPUs, so that they were asymmetric with respect to the peripheral attachment.

I think that means it is AMP, but I have no vested interest either way. Peter Flass (talk) 21:56, 27 September 2019 (UTC)

The UNIVAC 1108 System Description seems to say that 1) peripherals are attached to I/O Controllers (IOCs) and 2) any CPU can access any I/O Controller, which seems to suggest that, at least at the hardware level, it was capable of being symmetric. The UNIVAC 1108 Multi-Processor System Operating System EXEC 8 Programmer's Reference says "AT THE LOWEST LEVEL, THE EXEC MUST QUEUE INTERRUPTS USING THE DESIGNATED PROCESSOR. IT MUST ALSO ISSUE I-O REQUESTS ON PARTICULAR PROCESSORS ACCORDING TO THE AVAILABLE HARDWARE LINKAGES.", so it may be that a system can be set up in a way not to allow all CPUs to access all peripherals. Guy Harris (talk) 22:46, 27 September 2019 (UTC)

The 1106/1108 Facts and Figures brochure has diagrams on pages 4 through 7 that seem to indicate that the 1106 has channels in the CPUs, so that a CPU might only be able to access devices on its channels, but the 1108 can either have an ASMP configuration with an "Input/Output Processor" that acts as a CPU with channels attached and a "Computational Processor" that has a CPU with no channels attached and a mixed configuration with CPUs with channels attached, with peripherals on those channels presumably being accessible only by that CPU, and "Input/Output Controllers" (IOCs) with channels attached and with any CPU being able to access any IOC, with peripherals on an IOC possibly being accessible by any CPU. Guy Harris (talk) 23:53, 27 September 2019 (UTC)

Consulting the 1108 MP reference manual, there is no mixed configuration; in a multiprocessor 1108, the CPUs have no I/O channels and rely on the IOC for I/O. So it is fully symmetric. Shmuel (Seymour J.) Metz Username:Chatul (talk) 18:26, 29 September 2019 (UTC)

References

From the references above it is clear that the Univac 1100 was a fully-SMP computer system. What is not clear is the multiprocessing capabilities of Exec 8 at the time of the 1108. Even with fully-SMP hardware, incomplete support in the operating system can limit the ability of applications to make use of the multiple CPUs. “Asymmetric Multiprocessing” was a term of art in the 1960s and 1970s, meaning “not symmetric multiprocessing”. SMP was an operating system software goal, and we weren't there yet. I suspect that Exec 8 at the time of the Univac 1108 also wasn't there yet. John Sauter (talk) 07:26, 1 October 2019 (UTC)

So what about the OS references - "UNIVAC 1108 MULTI-PROCESSOR SYSTEM OPERATING SYSTEM EXEC 8 PROGRAMMERS REFERENCE" and "UNIVAC 1100 SERIES OPERATING SYSTEM PROGRAMMERS REFERENCE" - don't indicate that the OS fully supported SMP? In the first of them, section 7.2 "MULTI-PROCESSING" says

THE EXEC ROUTINES INTERFACING WITH THE RESIDENT WORKER PROGRAMS ARE RE-ENTRANT IN DESIGN. FOR MINOR TASKS REQUESTED OF THE EXEC MANY OF THE ROUTINES ARE TOTALLY RE-ENTRANT. OTHERS, WHEN IN THE MULTI-PROCESSING ENVIRONMENT, WILL QUEUE THE WORKER PHOGRAM REQUEST WHERE SERIAL PROCESSING IN A PARTICULAR AREA OF THE EXEC IS REQUIRED. AT THE LOWEST LEVEL, THE EXEC MUST QUEUE INTERRUPTS USING THE DESIGNATED PROCESSOR. IT MUST ALSO ISSUE I-O REQUESTS ON PARTICULAR PROCESSORS ACCORDING TO THE AVAILABLE HARDWARE LINKAGES. ABOVE THIS BASIC LEVEL, ANY OF THE AVAILABLE PROCESSORS CAN PERFORM A GIVEN TASK, WITH SELECTION BASED ON THE PRIORITY OF THE TASKS CURRENTLY BEING EXECUTED BY THE PROCESSORS. THE AREAS OF EXEC CODING WHICH REFERENCE COMMON DATA AND OTHERS WITH SPECIALIZED CODING METHODS MUST BE PROTECTED FROM SIMULTANEOUS EXECUTION, BUT MANY AREAS WILL BE OPEN AND MULTI-PROCESSED AS NECESSARY.

That seems to imply that there's no single CPU that's designated as "the CPU that runs the Exec", given the mention of a need to "[protect]" "the areas of Exec coding which reference common data and others with specialized coding methods" "from simultaneous execution" and given that "many areas" of the Exec "will be open and multi-processed as necessary". It appears that not only can any CPU run Exec code, but there's isn't even a giant lock - the locking is more fine-grained.

It also seems to indicate that there's no single CPU that's designated as "the CPU that does I/O" - I/O requests may be issued "on particular processors", plural. As per Chatul's comment, an MP 1108 system has all devices attached to IOCs rather than to CPUs, and all IOCs appear to be accessible to all CPUs, so it appears that there are "hardware linkages" between each CPU and all I/O devices. There was also an ASMP configuration of the 1108, in which there was one CPU to which all I/O devices were attached, so in that configuration there were no hardware linkages between the "computational processor" and any I/O devices, so only the "I/O processor" can issue I/O requests.

The second of those manuals speaks less of the MP capabilities of the system - but it does refer to the 1108, so it's not as if it doesn't speak of the capabilities of Exec 8 when running on the 1108. Guy Harris (talk) 16:49, 1 October 2019 (UTC)

The text you quoted from section 7.2 sounds more like design goals for the multi-processor version of Exec 8. Note the following from the Introduction paragraph, right after the table of contents:

THIS DOCUMENT CONTAINS A DESCRIPTION OF THE EXECUTIVE COMPONENT OF THE OPERATING SYSTEM FOR THE UNIVAC 1108 COMPUTER AND TAKES THE FORM OF A PROGRAMMERS REFERENCE MANUAL (PRM). THE EXECUTIVE IS DESIGNED TO OPERATE AS A MASTER CONTROL PROGRAM WHICH ESTABLISHES THE EFFICIENT MULTI-PROGRAMMING ENVIRONMENT NEEDED FOR UTILIZING THE FULL CAPABILITIES OF THE UNIVAC 1108 MULTI-PROCESSOR SYSTEM. THIS MANUAL INCLUDES DETAILS OF UTILIZATION PROCEDURES AND FUNCTIONAL CAPABILITIES BUT DOES NOT IN ALL CASES PRESENT THE DETAILED PROGRAMMING LOGIC WHICH MAKES POSSIBLE THOSE PROCEDURES AND CAPABILITIES.

THE VERSION OF THE EXECUTIVE SYSTEM DESCRIBED IS FOR THE UNIT PROCESSOR CONFIGURATION. THE INTERFACE OF THE USER TO THE EXEC IS THAT SHOWN, THE SAME INTERFACE WILL BE USED IN THE MULTI-PROCESSING VERSION WITH ADDITIONS MADE FOR CONTROL AND USE OF NEW FEATURES AVAILABLE ONLY IN THE MULTI-PROCESSOR CONFIGURATION, ALL SYSTEM SHIPMENTS WILL INCLUDE A 'SYSTEM MEMORANDUM' WHICH DETAILS THE CHARACTERISTICS OF THE CURRENT SYSTEM. THE MEMOS WILL POINT OUT THE VARIOUS ADDITIONS OR ENHANCEMENTS MADE AS THE SYSTEM IS UPDATED,

It seems clear from the above that the multi-processing capabilities of Exec 8 were not yet ready in 1968, when the manual was written. John Sauter (talk) 19:35, 1 October 2019 (UTC)

It seems unclear whether "THE VERSION OF THE EXECUTIVE SYSTEM DESCRIBED" would even run on SMP hardware, other than perhaps by completely ignoring the other processor or two processors, as it "IS FOR THE UNIT PROCESSOR CONFIGURATION". The interesting question is what versions of Exec 8 ran on the 1108 - was there ever an SMP version for the 1108? If there was, than the 1108 was an SMP system, even if it didn't initially ship with an SMP version of the OS.

An issue of the Unisys History Newsletter about the 1108] says:

While both EXEC I and EXEC II were provided for the unit processor 1108s, it was clear that the two should be merged to provide a true multi-programming system with the ease of use and external appearance of EXEC II. Furthermore, there had to be an operating system for the multiprocessor 1108s. This new operating system was EXEC 8, sometimes written as EXEC VIII. The specifications for it were drawn up in December 1964 and work began in May 1965. The announcement of EXEC 8 in 1966 was greeted with skepticism by Datamation, which had seen many big software fiascoes by other computer companies: "A step towards the quicksand: Univac, which has been doing well with about the only working large-scale software, joins the manana crowd with a new operating system for the 1108." At first, Datamation had it pegged correctly: the initial versions of EXEC 8 did not work very well, and in 1967 Sperry Rand had to give one of the 1108s to NASA for free as a penalty for missing contract deadlines. The situation did improve, so that the University of Maryland was using EXEC 8 in the spring of 1968, and one year later the president of Computer Response Corporation, a service bureau with an 1108 in Washington, could say of EXEC level 23.25: "We're satisfied with the way it's handling our workload." However, EXEC 8 wasn't fully settled down until 1970.

The 1110 wasn't introduced until 1972, according to UNIVAC_1100/2200 series#1110, so between 1970 and 1972 the only models were the 1108 and 1106. Unless SMP support didn't arrive in Exec 8 until 1972, that meant that it supported the 1108, and even if it arrived in 1972 or later, unless that version of Exec 8 didn't support SMP on the 1108, that also meant that the 1108 could run an SMP version of the OS.

And if we look at the second of the two OS manuals, from 1971, section 25.2 "BASIC DESIGN PHILOSOPHY" says:

Central processor units (CPU) are in general treated equally. Components must be prepared to execute on any CPU; exceptions are limited to certain maintenance functions, and to input/output (I/O) situations in which a particular CPU does not have a direct electrical path to a particular peripheral device. This approach allows maximum CPU utilization in multiprocessor systems.

and section 25.4 "MULTIPROCESSING" makes similar claims to the 1968 manual about the locking being 1) necessary (i.e., there's no CPU that is the only one running executive code) and 2) fine-grained (so it's not just symmetrical-but-giant-locked). Guy Harris (talk) 21:09, 1 October 2019 (UTC)

I agree that the question of Exec 8's support of multiprocessors is an interesting one. You suggested that early versions of Exec 8 might have ignored the additional processors. Another possibility is that Univac might not have shipped multi-processor 1108 systems to customers until Exec 8 was ready to support them. DEC did that with the PDP-10: customers could build multi-processor systems from components, but they were responsible for the software. Still another possibility is that early versions of Exec 8 ran only user-mode (guard mode) tasks on the additional processors, like the Burroughs B5500. That kind of minimal support can be coded quickly, but it places the 1108 running such a version of Exec 8 (if it ever existed) firmly in the AMP camp. John Sauter (talk) 17:17, 2 October 2019 (UTC)

If the "Family Tree of Sperry Rand Computers 1962-1980" diagram on this page gives correct delivery dates, the 1108 II first shipped in 1968. According to "Unisys Computers, An Introductory History", by George T. Gray and Ronald Q. Smith (at least in the Apple Books edition), "The first delivery of a one-processor version of EXEC 8 was in February 1967." and "The first multiprocessor EXEC 8 (Level 20) was released in January 1968." So perhaps the first MP system and the first MP version of Exec 8 were shipped in 1968. Guy Harris (talk) 17:56, 2 October 2019 (UTC)

I suspect that the UP version of EXEC 8 could not run on an MP 1108 at all; does anybody know whether the UP version of EXEC 8 was capable of using an IOC? Shmuel (Seymour J.) Metz Username:Chatul (talk) 22:49, 2 October 2019 (UTC)

"could run on an MP 1108 at all" or "could not run on an MP 1108 at all"? Guy Harris (talk) 04:43, 3 October 2019 (UTC)

Thanks; corrected. Shmuel (Seymour J.) Metz Username:Chatul (talk) 16:53, 3 October 2019 (UTC)

Inconsistency in #CDC 6500 and 6700

The selection of models in #CDC 6500 and 6700 is confusing and inconsistent. If the definition of AMP that the article uses takes the peripheral processors (PPs) into account then the 6400 and 6600 should be included as AMP. Alternatively, if the definition does not take the PPs into account, then only the 6700 should be listed, since the two CPs of a 6500 are identical and play identical roles in the software. Shmuel (Seymour J.) Metz Username:Chatul (talk) 11:48, 28 March 2023 (UTC)

The article states that the CDC 6000-series do not fit into the usual classification of ASMP and SMP. Perhaps they should be eliminated from the article entirely, but I thought that the information would be useful to a reader wondering about these computers. I am not very familiar with them; perhaps you could expand the description to provide more details and thus clear up the confusion. John Sauter (talk) 20:16, 28 March 2023 (UTC)

The lead says An asymmetric multiprocessing (AMP or ASMP) system is a multiprocessor computer system where not all of the multiple interconnected central processing units (CPUs) are treated equally.; it does not say that the processors have to run the same code. Historically, the term Multiprocessor has included systems with dissimilar processors, e.g., IBM's Direct Coupled System (DCS), the predecessor to ASP. --Shmuel (Seymour J.) Metz Username:Chatul (talk) 11:14, 29 March 2023 (UTC)

Wow, I had no idea the 7040-7090 direct couple system existed; thank you for the reference. We had something similar at Stanford, except we used a DEC PDP-1 instead of the IBM 7040, the 7090 kept its tape drives and 1401, and of course we had to write all our own software.

As I read the manual you referenced, I see the word multiprocessor only as part of the name of the software that ran in the 7040, and the name of the instruction used to communicate between the computers. Later, IBM used "multisystem" to describe both this kind of system and computers that shared main storage, with "multiprocessor" being just the latter.

Perhaps the lead of this article should also say that user software can run on any of the CPUs. John Sauter (talk) 13:57, 29 March 2023 (UTC)

Cray had something similar to DCS on the Cray 1, using a Data General Eclipse as a front end.

I'd say that the thing to do is to consult some CS texts and let the lead reflect that. My primary concern is that whatever definition is used be applied consistently, which is currently not the case, but I'm reluctant to edit that section until there is a consensus on what definition to use, since that will determine whether it should include only the 6700 or all four..

The Honeywell 8200 is an example that matches your definition but where the processors have radically different architectures, one character oriented and one, a virtual multiprocessor, word oriented.

I'm wondering whether the article should have sections on DCS and the H-8200. --Shmuel (Seymour J.) Metz Username:Chatul (talk) 22:04, 29 March 2023 (UTC)

Wow, I found reading the 8200 hardware reference manual like drinking from a firehose. I found a description of the software that was more approachable at . It appears that the H8200 is a multiprocessor, with one CPU having eight threads and the other, the Support Processor, using a different instruction set. Both CPUs have access to memory and peripherals. However, the operating system cannot move an application between the two CPUs because they have different instruction sets. If we are going to include a machine like this in this article we need to expand the scope of the article. I also think an expansion of scope is warranted for including computers like DCS. Any thoughts on an expanded lead? John Sauter (talk) 13:16, 30 March 2023 (UTC)

Coming late to this discussion. I think SMP and ASMP implies compatible CPUs sharing memory. Front-ends wouldn’t count, so, for example The CDC 6600 PPs or PDP-11s front-ending a PDP-10 aren’t examples. I think the systems have to share memory, otherwise it’s a cluster. My example of ASMP is the Burroughs 5500, where Processor A ran the OS attached all the IO, and Processor B could only run user jobs and had to interrupt Processor A to do I/O. I believe IBM had similar systems. In SMP, all processors are equal, and any one can run the OS and/or user jobs. I think DCS is an example of a front-end system, and ASP is a cluster, but definitions are slippery. Peter Flass (talk) 23:39, 29 March 2023 (UTC)

Yes, definitions are very slippery. Perhaps we can expand the scope of this article to include the Honeywell 8200 and the DCS. Concerning using a PDP-11 as a front end on a PDP-10, there were two ways of interfacing the computers: on the KL-10 the interface was a DTE-20, which just conveyed messages between the computers, but on the KI-10 the interface was the DL-10, which mapped a portion of the PDP-11 address space into PDP-10 memory, if I am remembering correctly. John Sauter (talk) 13:16, 30 March 2023 (UTC)

There are a bunch of different types of systems with multiple processors that are not invariant under a permutation of the processors:

• "all processors have the same instruction set and have the same performance, one processor is designated as the processor that handles the low-level OS code, everthing else just runs application code", e.g. the early Burroughs B5xxx systems;
• "all processors have the same instruction set, all processors can run low-level OS code, but some resources are "local" to a particular processor or subgroup of processors with resources "local" to a given group being slower to access from another group", e.g. NUMA systems;
• "all processors have (mostly) the same instruction set but don't have the same performance, all processors can run low-level OS code and talk to all I/O devices", e.g. ARM big.LITTLE, Intel Lakefield, Apple silicon SoCs with "performance" and "efficiency" cores, etc. - see Heterogeneous computing § Heterogeneous CPU topology;
• "some processors are application processors, others perform system functions", e.g. the CDC 6xxx systems with the CP and the PPs, systems with front-end processors, DCS, ASP, cellphones with baseband processors, IBM mainframes with a Coupling Facility, IBM System/34 and IBM System/36, etc.;
• "some processors are general-purpose application processors, others are specialized coprocessors", e.g. supercomputers using GPUs for some computations, systems with neural network coprocessors, etc. (this leaves out coprocessors that implement CPU instructions, such as add-on floating-point processors).

and possibly some others I missed.

The first of those is probably what most people think of as "ASMP".

The second of those are generally treated as being similar to SMP, but with the scheduler having to take the topology into account.

The third of those are also somewhat like SMP, with the scheduler taking the capabilities of the CPUs into account, e.g. moving jobs between "performance" and "efficiency" cores.

The fourth of those are probably not generally thought of as "MP" in the SMP/ASMP sense. At least as I read the AFIPS paper on the H8200, it's somewhat in the second category, but the Support Processor can run application code to do data communications and media conversion, so it's not as if the "other" is just running system code.

The fifth of those are clearly not traditional SMP or ASMP. Heterogeneous System Architecture discusses modern versions of some of those.

The heterogeneous computing page talks about various systems in the last three categories, but that's a sufficiently, well, heterogeneous group of systems, and Heterogeneous computing § Example hardware has a "needs cleanup" note. Guy Harris (talk) 20:16, 30 March 2023 (UTC)

This is an excellent breakdown of the many ways that multiple computers can be used together. The article on Multiprocessing starts by define multiprocessors as tightly coupled, but then describes loosely-coupled systems. I think that whole article could be replaced by this description. The revised multiprocessing article could then have daughter articles Symmetric Multiprocessing and Asymmetric Multiprocessing. John Sauter (talk) 06:39, 31 March 2023 (UTC)

How about three daughter articles:

• Tightly coupled asymmetric multiprocessing
• Tightly coupled symmetric multiprocessing
• Loosely coupled multiprocessing.

IMHO it wouldn't be helpful to split loosely coupled into symmetric and asymmetric. Also, the definition needs to be clear on the status of processors that have indirect access to the memories of other processors.

To add to the complexity, one of the things that ASP version 3 added was Local ASP (LASP), in which a processor served as both main and support processor, and with JES3 that became the norm; the MVS image serving as a support processor also runs the workload of a main processor.. --Shmuel (Seymour J.) Metz Username:Chatul (talk) 12:20, 31 March 2023 (UTC)

I think this would be a fine organization. I am not sure what the name of the top-level article should be. Early in the life of System/360 IBM used the term Multisystem for it, but eventually used that term only for loosely-coupled computers. Perhaps we could call it "multiprocessing and multisystem", with the three daughter articles referring back to it with something like "for other ways of using multiple computers together, see "multiprocessing and multisystem". John Sauter (talk) 13:15, 31 March 2023 (UTC)

References

IBM System/z

IBM System/z can contain a number of special-purpose CPs. For example the Integrated Facility for Linux (IFL) - I don’t know if this is strictly a software thing or if it runs different microcode, but in either case this would seem to be a current example of AMP. How about something like XT/370, which has both an Intel “suport” CPU and a CPU running 370 microcode? Peter Flass (talk) 18:48, 14 September 2023 (UTC)

IBM Z systems with IFLs don't strike me as being like classical AMP. There are a lot of types of systems that involve multiple processors where not all processors "look the same"; heterogeneous computing covers many of them, and those systems strike me as heterogeneoous computing.

As for the "support" CPU in the PC-XT/370 (which is just the "PC" part), according to the article, it appears to have run some sort of VM-like hypervisor application on top of DOS, with, I suspect, the code running on the microcode-hacked 68000+8087 S/370 implementation "trapping to the hypervisor" by the CPU stopping and the VM DOS application being notified of the trap, doing whatever it's supposed to do, and restarting the CPU. That also strikes me as heterogeneous computing rather than ASMP.

The CDC supercomputers with the peripheral processors not only controlling the devices but also running the OS also strike me as heterogeneous computing, as do, for example, the IBM System/34 and IBM System/36 with a "control storage processor" running the OS and a "main storage processor" running the applicatins.

Has the term "asymmetric multiprocessing" ever been used for anything other than "the CPUs can all run the same application code, but only one of them {runs system code, can control I/O devices}" anywhere other than Wikipedia? (The topology of the never-released Asymmetric multiprocessing § PDP-11/74 was described by DEC as "symmetrical" on page 2 of the RSX-11M - PDP-11/70 Multiprocessing System Functional Specification, its appearance in Asymmetric multiprocessing nonwithsttanding; it strikes me as more "NUPA" - "non-uniform peripheral access", by analogy to NUMA - rather than asymmetric.) Guy Harris (talk) 20:38, 14 September 2023 (UTC)

The CDC 6000 series is clearly an AMP, but, as discussed in #Inconsistency in #CDC 6500 and 6700, the first paragraph of Asymmetric multiprocessing#CDC 6500 and 6700 is irrelevant and the section name is inappropriate; all of the CDC 6000 series and Cyber 70 and 170 had the CP-PP distinction, not just the 6500 and 6700.

As a side note, the 6600 could be equipped with an optional second CP. -- Shmuel (Seymour J.) Metz Username:Chatul (talk)

The CDC 6000 series is clearly an AMP The CDC 6000 series is clearly a line of systems where not all processors have the same instruction set and have the same role. It's very different from, say, the B5000, where the processors have the same instruction set, and can both run B5000 application code, but only one of them can directly talk to I/O devices or run privileged-mode OS code. It's more like, for example, the System/34 and System/36, where you have an "OS processor" and an "application processor", with the two types of processor having different instruction sets, and with the OS code running on the "OS processor".

CDC 6000 series § The 6500 says that it has two central processors and one set of peripheral processors. If either of the two CPs could communicate with the PPs, then, it sounds as if it's symmetric from the point of view of running application code and heterogeneous as a system as a whole. CDC 6000 series § The 6700 describes a heterogeneous system of one sort from the point of view of running application code (sort of like, for example, an ARM big.LITTLE system, where the processors have the same instruction set, and can both run the same code, but there's a significant performance difference between them) that's also heterogeneous from the point of view of having separate application and OS processors, with two different instruction sets.

The terms "asymmetric multiprocessing", "asymmetric multiprocessor", and "AMP" should be used in Wikipedia according to how they've been used historically. If they've only been applied to systems where the processors all ran the same instruction set, and could all run application code, but only some could talk to peripherals and only some ran OS privileged code, then that's what this page should discuss. If they've also been applied to other flavors of heterogeneous computing, then that's what this page should discuss, probably with a taxonomy of heterogeneous computing systems used to distinguish the different types of systems. Guy Harris (talk) 21:29, 15 September 2023 (UTC)

On IBM z, the CP, ICF, IFL, SAP, zAAP and zAAP are physically the same and run the same instruction sets, with the exception of special instructions that let the OS verify compliance with license terms. Linux and z/VM can run on either a CP or on an IFL, but the latter is less expensive. At the time you license processor units, IBM configures available PUs to the types that you have ordered. The hardware is symmetric, but various sofwtare components will only run on particular PU types, e.g., CFCC will not run on a CP or IFL.

The XT/370 had one Intel 8088 and two Motorola 68000 processors]]; one 68000 had standard microcode and one had custom microde. I don't know what parts of the VM/PC Control Program ran on the 8088 and what parts ran on the 68000s, nor do I know the dividion of CP code between the two 68000s, but S/370 code ran only on the 68000 with modified microcode. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 13:18, 15 September 2023 (UTC)

VM/PC Control Program

Thanks. I’ve never dug into the details of Ziips and zaps, etc., so I didn’t know if there were more microcode differences than you describe to improve performance or whatever. I guess they don’t qualify for this article no matter what, based on the definition we use. Peter Flass (talk) 21:05, 15 September 2023 (UTC)