Talk:Asymmetric multiprocessing

message: Does Asymmetric multiprocessing refer to identical processors asymmetrically sharing the workload, or does it also encompass dissimilar processors working together on the same task? For example, do the SNES and the PlayStation 2 qualify as being asymetrically multiprocessing? --Martin Rudat(T|@|C) 02:02, 23 April 2006 (UTC)
replies: text: I don't know about the SNES, but IMHO the PS2 and the PS3 would qualify as an asymmetric system. --Pezezin 23:12, 10 May 2006 (UTC)
replies: text: The PS2 does not qualify as a AMP equipped unit as the Emotion Engine VPUs are actually separate from the CPU. In an AMP system like the PS3, the differentiated cores all make one CPU unit locked to the same clock and contiguous memory space but unable to all process the full set of instructions available, whereas the PS2 is more of a semi SoC setup with a CPU  then a dedicated VPU that is directly linked to the GIF (graphics). The VPU and rest of the CPU have completely non-connected memory space within the die, so don't really constitute a processor, and would be addressed more like a PCI-bus-connected device (much like the GPU would be). 37.152.200.88 (talk) 01:10, 11 July 2013 (UTC)

text: In another thread I mentioned the CDC 6600, in which a single 10 MHz clock drives a 60-bit Central Processor and 10 12-bit peripheral processors; each PP had access to all 12 I/O channels. The operating system runs on the PPs, with the kernel on PP0. I would certainly consider that to be an ASMP Shmuel (Seymour J.) Metz Username:Chatul (talk) 21:48, 15 July 2013 (UTC)
thread_title: Do all the processors in an ASMP system have to be identical?

message: : Your question, outlines the answer. All of the above are forms of ASMP and can be defined by its different subsections.
Software ASMP and hardware ASMP G7a (talk) 04:09, 11 February 2008 (UTC)
thread_title: Complete Answer To "What is Asymmetric multiprocessing"

message: : As of now, this page refers to both Asymmetric multiprocessing AND Asymmetric multiprocessors.It is a very confusing topic that I feel should be in one place as
many will come looking for one thing but want the other. In the grand scheme of things, both topics to come together and become the same thing. Its all one idea, broken down into different areas of computing. G7a (talk) 05:09, 11 February 2008 (UTC)
thread_title: Complete Answer To "What Does This Article Refer To"

message: ASMP is a type of multiprocessing, correct? What is multiprocessing? Multiprocessing is where two or more CPUs are used within a single computer system. So why does the article give an example of a ASMP system as a personal computer with a CPU and a GPU? Are the two performing multiprocessing? I don't think so. So how can it be classified as a ASMP when it isn't performing multiprocessing in the first place? If someone thinks that this scenario does qualify as a multiprocessor and not as a uni-processor system with a coprocessor (the GPU), I would like to see some reliable sources (multiple ones in fact, such claims are a bit dubious) stating this, such as papers from the ACM or the IEEE, or university level textbooks. Rilak (talk) 12:47, 14 September 2008 (UTC)
replies: text: Yes, ASMP is an early form of multiprocessing, in which a second CPU is added to a computer system that lacks a re-entrant operating system.  If there are no objections I will revise the article to make this clear.  This will involve removing the references to I/O channels and co-processors. John Sauter (talk) 12:17, 18 September 2010 (UTC)
thread_title:  Is it a ASMP system? Or is it a coprocessor? 

message: The article states that there are no ASMP devices being sold today, but I'm pretty sure the iPhone and iPod Touch are both ASMP systems. The main CPU is an ARM-11 chip, and they use an ARM-7 chip at a slower clock speed for things like audio decoding. 
MaxWinsForever (talk) 04:33, 11 April 2009 (UTC)
thread_title:  What about the iPhone? 

message: "Currently there are no consumer level production computers that use asymmetric multiprocessor designs." As others have said, Cell processor, PS2, etc etc, there are many commodity processors that are ASMP, so this quote is wrong.  —Preceding unsigned comment added by 69.36.131.254 (talk) 22:44, 1 September 2009 (UTC)
thread_title:  Article is wrong to say ASMP processors are old and not commonly used 

message: The article states that ASMP was first used in 1970, but there were ASMP machines at universities in 1968 (see ) and Burroughs was selling a dual-processor B5000 in 1963 (see ).  If there are no objections I will edit the article to add this information. John Sauter (talk) 21:39, 14 September 2010 (UTC)
thread_title:  ASMP is from early 1960s 

message: I am planning to rewrite the article based on ASMP being an early form of multi-processing, and multi-processing being defined as multiple CPUs, all of which use the same instruction set and run user applications.  If I hear no objections I will perform this rewrite within a few days, and we can all improve the result. John Sauter (talk) 22:31, 21 September 2010 (UTC)
thread_title:  rewrite planned 

message: Imagine this scenario on M65MP: a task is running on processor A and issues an I/O request for a device that is accessible only on processor B.  The I/O supervisor asks processor B to issue the Start I/O instruction.  When the I/O operation completes, processor B is interrupted and finds that the task has an exit routine for the I/O operation.  
I didn't see anything in the I/O supervisor PLM about processor B asking processor A to run that exit, but if it doesn't, then the task will be running on both processor A (the main-line code) and on processor B (the exit routine).  That is what you would expect on a fully SMP system, but on M65MP I suspect it would open up a large can of worms.  Applications weren't coded to expect this behavior, and the kernel would need defense against the mainline and the task making kernel requests at the same time.  Therefore, I suspect that exits for a task are run on the processor which is executing that task, even if the event that caused the exit to be run happened on the other processor. John Sauter (talk) 15:06, 1 December 2010 (UTC)
replies: text: What kind of exit are you talking about? I/O appendages run as extensions of the I/O supervisor, not as part of the task; they are always handled by the CPU taking the interrupt or I/O request. At the application level, exits run under an Interrupt Request Block. Requests to schedule an IRB go on a global queue, which the dispatcher services. When IRB is activated, other work on the TCB is suspended. See the MVT Supervisor PLM for details of RB processing. Also see "exit effector" in the same manual. Shmuel (Seymour J.) Metz Username:Chatul (talk) 15:37, 1 December 2010 (UTC)
replies: text: I've never been familiar with OS/360 application programming; I saw the reference to exits in the description of ENQ and DEQ.  The implication was that they were something that could happen asynchronously, such as at the completion of an I/O operation.  Your explanation that application-level exits run as part of the task answered my question.  Apparently, either processor's I/O appendage can enqueue an IRB, and the dispatcher will schedule it as part of the task.  Thanks for answering my question. John Sauter (talk) 20:39, 1 December 2010 (UTC)
replies: text: To clarify, a DCB for EXCP can specifyThe programmer can specify a two character code for each type of appendage; OPEN appends those characters to a standard prefix and loads the appendage. multiple types of I/O appendages. I would expect only the Channel End and PCI appendages to schedule an IRB. Shmuel (Seymour J.) Metz Username:Chatul (talk) 21:11, 1 December 2010 (UTC)
thread_title:  question about exits 

message: In a note from 22:43 23 November 2010 John Sauter asked "What about TSS and MTS?" I can't speak about TSS, but MTS was SMP.  The supervisor (UMMPS) ran on either or both CPUs of the S/360-67. Supervisor locks were small and were used to protect individual common data structures that might be accessed simultaneously from either CPU. Individual tasks (jobs, processes) would only execute on one processor at a time. Time Sharing Supervisor Programs by Mike Alexander (May 1971) has information on MTS, TSS, CP/67, and Multics which might be interesting. Jeff Ogden (talk) 16:12, 22 December 2010 (UTC)
replies: text: This is good information for the article.  If you don't object, or add it yourself, I will add it. John Sauter (talk) 16:47, 22 December 2010 (UTC)
replies: text: No objection. Jeff Ogden (talk) 17:17, 22 December 2010 (UTC)
thread_title:  What about MTS? 

message: Another ASMP system is the IBM 9020, where the different processors had different roles. See  Shmuel (Seymour J.) Metz Username:Chatul (talk) 16:05, 24 November 2010 (UTC)
replies: text: If the processors had different roles, I wonder if they could be properly called a multiprocessor?  If computers cooperate but do not share main memory, that is a multisystem, not a multiprocessor. John Sauter (talk) 04:49, 25 November 2010 (UTC)
replies: text: My recollection is that the I/O Elements of a 9020 did share memory with the larger boxes. Shmuel (Seymour J.) Metz Username:Chatul (talk) 15:01, 25 November 2010 (UTC)
replies: text: Is there a citeable reference for this?  Statements in Wikipedia articles need to be backed up with good references.  The IBM Systems Journal citation that you used above certainly qualifies as a good reference, but I cannot read it. John Sauter (talk) 03:18, 26 November 2010 (UTC)
thread_title:  IBM 9020 

message: Someone added a request for attention from an expert to the article, but did not add any information to the talk page about the need.  As can be seen from the other topics on this talk page, there has been plenty of attention from experts already.  Might the request have to do with the recently-added stubs about multiprocessor support by certain operating systems?
Actually, come to think of it, I am not even sure what “non-identical CPUs” means.  Does being unable to access the I/O channels make a second CPU non-identical to the first?  If the second CPU has a different instruction set from the first, does that make it non-identical?  If so, the B5000's processor B qualifies on both counts, since it could not do I/O and could not enter control state. John Sauter (talk) 03:24, 3 September 2011 (UTC)
thread_title:  expert attention request? 

message: Arm's big.LITTLE architecture (which pairs a low-power core with a high-performance core) may mark a return to AMP in the 2010s, with the new goal maximising efficiency (generally with battery-powered devices in mind).  Although described by ARM as 'heterogeneous multiprocessing', the architecture tallies with our definition of AMP in that the processors are instruction-set compatible and all user code can run on any processor (probably true of system code as well, but that's not required).
big.LITTLE may be used as a highly-scalable uniprocessor by migrating the entire workload to the most appropriate core for the conditions, or as independent processors with different performance characteristics (requiring an AMP-aware scheduler to place user jobs on the most appropriate core).
References:
* Web page
* White paper
--Streapadair (talk) 17:26, 28 November 2012 (UTC)
thread_title:  ARM big.LITTLE architecture 

message: :A system wherein only one particular designated processor (in the sense of "one particular collection of transistors") runs OS code, for example, is asymmetric; a system wherein any processor can run OS code is symmetric, regardless of whether there's a giant lock that allows only one processor to run OS code at any given instant or more fine-grained locks allowing more than one processor to run OS code at the same time.
:Whether a system is asymmetric or symmetric is an issue of the entire system - both the hardware running on it and the software running on it:
:*A system in which, for example, the I/O devices or channels are connected to one particular processor, so that the other processors cannot issue I/O instructions, would inherently be asymmetric, as would a system in which, for example, the "trap to privileged mode" instruction is wired up on one processor to cause a trap of some sort to privileged-mode code and, on the other processors, is wired up to halt that processor and deliver a "another processor executed a trap to privileged mode" trap to the first processor, would also inherently be asymmetric, as, in both of those cases, there are hardware differences between the processors.
:*A system in which all processors are capable, at the hardware level, of running privileged-mode code and starting I/O operations, but in which the OS that happens to be running on that system only runs the privileged-mode code on one particular processor, is also asymmetric.
:The difference between the first type of system and the second type of system is that the first type of system can't be made symmetric by changing the OS, but the second type of system can. Guy Harris (talk) 18:14, 6 April 2013 (UTC)
replies: text: We disagree about the definition of the term “asymmetric multiprocessing”.  I claim it is an obsolete computer science and computer marketing term, and I have citations (in the main article) to demonstrate my point.  Your definition is a reasonable one, but do you have citations to justify it? 14:08, 7 April 2013 (UTC)
thread_title:  part 1 

message: :It may well be "obsolete" in that people aren't building, for example, master/slave MP systems, but that's "obsolete" in the sense that the term "core memory" is obsolete; it's not as if it shouldn't be used to describe systems in the past.  I'm not sure what the point of saying it's an "obsolete term" is.
:As for references, let's look at some of the references in the article.
:Chapter 1, HISTORICAL PERSPECTIVES, of Introduction to Multiprocessing talks about the IBM Stretch being an "asymmetric multiprocessor in which each processor had a separate and distinct function", with one processor "used for binary arithmetic" and another being "used for character operations".  I suspect they're referring to the IBM 7950 Harvest, with the "stream coprocessor" being what was "used for character operations".  That does, indeed, match what, these days, is generally being referred to as a system with coprocessors.  In the same paragraph, they talk about the IBM Direct Coupled System, where the 7044 acted as "a communications processor" according to that document and a machine "performing I/O operations" according to the Wikipedia article for the 7090; in either case, it's a system with a front end processor (which could control I/O devices other than communications devices).
:Chapter 2, DEFINITIONS AND COMPARISONS, speaks of a "multicomputer" as "a system that has two or more computers sharing data at the data-set level", and a "multiprocessor" as having multiple computers with some amount of shared memory (tightly coupled if most of the communication is through shared memory, loosely coupled if most communication is over a shared bus), at least some shared I/O devices, and "one operating system".  They speak of "asymmetric" multiprocessors as multiprocessors not having "equal performance and functionality"; given that an earlier example of that was a Stretch with a coprocessor, the "one operating system" presumably needn't run on all the processors - the coprocessors could presumably be controlled by the OS on the "main" processor, just as long as the system doesn't look as if the coprocessors are running their own full-blown OSes.
:Chapter 5, MULTIPROCESSING SOFTWARE, says:
::...Multiple processors may be arranged hierarchically (dissimilar) or symmetrically (identical) to produce the preferred result.
::Hierarchical Systems
::A hierarchical system reduces complexity in system design by producing predefined dependencies.  An example of a hierarchical system is a master/slave arrangement in which one of the processors is considered superior to the others.  In a typical master/slave organization, the master may be responsible for distributing the work load to the slave processors.  For example, the system may be programmed so that only the master can respond to interrupts, but the resulting work can be handled by any one of the slave processors.
:::...
::Symmetric Systems
::Symmetric systems treat all processors equally, execute common operating system code, and share all devices.
:That chapter speaks of both master/slave and symmetric PDP-10 systems; they say that, in the PDP-10 systems, "the slave has no I/O devices (except a console terminal)", so that sounds like a system where the asymmetry is in hardware, not just in software, but they also say "A symmetric multiprocessor requires only new software; the hardware is essentially unchanged", which seems to be saying, if taken literally, that no multiprocessor hardware systems exist in which only one processor has peripherals attached to it.  That matches the earlier definition, so presumably "the slave has no I/O devices" doesn't mean "the slave has no hardware connection to any I/O devices"; it must mean "the slave does not touch the I/O devices to which it has access, it lets the master handle that".  A DEC paper on TOPS-10 SMP doesn't indicate whether the KA-10 multiprocessor systems were "multcomputers" or "multiprocessors" in the sense used in the previous DEC reference; they say that the SMP version of TOPS-10 didn't have to run on the KA-10.  They speak of dual-ported disks; I don't see any indication of any other mechanism used to allow multiple processors to access the same peripherals.
:RSX-11M multiprocessing (PDP-11) defines "symmetrical system" as "synonymous with multiprocessor system", with "multiprocessor system" described as "generally" giving "each unit" "common access to at least a portion of the I/O devices", and seems to speak of a system where that's not the case as a "multicomputer system".
:Appendix G of  says, of the IBM 3062 Attached Processing Unit, that "the APU has no channels attached", so a 370 Model 168 with an APU is an asymmetric system where the asymmetry is in hardware.  Appendix E seems to indicate that, in the MP configuration, each CPU has channels attached to it, and that each CPU has some sort of control over the channels attached to the other CPU if that CPU is stopped, so maybe you could speak of a asymmetry in that not all channels are accessible to all CPUs.  However, it also speaks of a "two-channel switch feature", which sounds as if it allows a peripheral to be controlled from two different channels (whether attached to the same CPU, presumably for redundancy, or attached to different CPUs), so that might allow either CPU to control all peripherals, rendering that system symmetric.
:Operational Characteristics of the Processors for the Burroughs B5000 seems to indicate that only Processor Module A has an I/O Exchange, so that's another asymmetric-in-hardware system.
:So, for the definitions used in the two DEC documents, systems such as the Burroughs B5000 and the IBM System/370 Model 168 with a 3062 Attached Processing Unit aren't "asymmetric multiprocessors", but not because they're not asymmetric (there's most definitely asymmetry between the processors!) - it's because they're not multiprocessors at all, they're "multicomputers", because not all processors have access to the I/O devices.  I'm not sure how they'd categorize the MP configuration of the Model 168, given that not all processors have equal access to all peripherals, but maybe it'd be a "symmetric multicomputer", in that the processors don't have "[unequal] performance and functionality" - it's not as if one of them has more performance or functionality, at least not if you've attached as many peripherals to the channels on the second processor as you've attached to the channels on the first processor.
:I.e., if you go by the definitions in the two aforementioned DEC documents, we should remove the B5000 from this page, as it's not a multiprocessor, just a multicomputer.  The APU configuration of the 370/168 should be removed for the same reason; I'm not sure what should be done with the MP configuration of the Model 168.
:On the other hand, the VAX Product Sales Guide shows the VAX-11/782 in a fashion that indicates that the peripherals are connected to one particular processor, referring to the second processor as an "attached processor" and saying that "All peripherals are attached to the primary processor ONLY; they are not supported by the attached processor".  However, the fact that it would be a "multicomputer" by the definitions in the other DEC documents nonwithstanding, they refer to it as an "asymmetric multiprocessing system"!  Perhaps a "multiprocessing system" isn't necessarily a "multiprocessor", or perhaps they just didn't get the memo. :-)  In any case, if the 11/782 is an "asymmetric multiprocessor", then so are the B5000 and the APU configuration of the 370/168.
:So, if we only go by DEC's documents, the question is whether an "asymmetric multiprocessing system" is an "asymmetric multiprocessor".  If so, then the definitions of "multiprocessor" in the first two DEC references I cite should be ignored, and systems in which all I/O devices are attached to one particular processor are multiprocessors, and obviously asymmetric multiprocessors at that, including the B5000, the APU configuration of the 370/168, and the VAX-11/782.  If not, then neither the B5000, the APU configuration of the 370/168, and the VAX-11/782 aren't multiprocessors, but multicomputers, and shouldn't be described on a page about "asymmetric multiprocessing", unless you can do "asymmetric multiprocessing" on a system that's only a multicomputer, not a multiprocessor.
:In either case, the MP configuration of the 370/168 appears to be, at the hardware level, a symmetric multiprocessor if all devices are attached with a two-channel switch, and, depending on whether "symmetric" means "all machines can get at all peripherals" or "no one machine is given all the peripherals", symmetric or not.
:(In addition, the "SYSTEM PERFORMANCE DEGRADATION" section of Chapter 5 of the first DEC reference seems to speak of a giant lock ("Such an instruction is used to program a mutual exclusion code surrounding the kernel."), so they seem not to consider a giant lock to make a system asymmetric.  Given that, and given that, on the Multics machines, all peripherals were available to all devices, and no processor was designated as the processor to do all the I/O, Multics was not what would be called an asymmetric multiprocessor, and should be removed from this page.) Guy Harris (talk) 20:59, 7 April 2013 (UTC)
thread_title:  part 2 

message: You appear to recognize that there are degrees of asymmetry: a 370/168 MP in which all but one of the peripherals are accessible to both CPUs is “less asymmetric” than one where all of the peripherals are attached to one of the CPUs.  Do you also recognize that there can be degrees of asymmetry due to software? John Sauter (talk) 20:10, 9 April 2013 (UTC)
replies: text: Yes.  For example, on a machine where all processors are capable of running privileged code, and where the I/O devices are accessible to all processors, you could have an OS where all but one processor, when making a call to privileged code, must block the thread of control making the call and request that the one processor allowed to perform privileged-mode operations perform the privileged-code function, and you can have an OS where all processors can run privileged code but all but one processor, when it needs to perform an I/O operation, must block the thread of control starting the I/O function and request that the one processor allowed to perform I/O operations start the operation. Guy Harris (talk) 01:30, 10 April 2013 (UTC)
replies: text: Then perhaps you would agree that there is a continuum between fully asymmetric and fully symmetric multiprocessing, with the B5500 at one extreme, a modern Linux system at the other, and the various historical multiprocessors in the article at various places in that continuum? John Sauter (talk) 02:15, 10 April 2013 (UTC)
thread_title:  part 5 

message: "As the references in the article make clear, it was used in computer marketing from about 1960 to about 1985 to refer to such multiprocessors as the B5500, the DECsystem-1055 and the VAX-11/782." All of those systems do, in fact, have a lack of symmetry between the processors.
"Later multiprocessors were called symmetric" - because they did have symmetry between the processors.
"The engineers of the time also called their hacks to make use of the second processor asymmetric multiprocessing because they were looking forward to being able to provide much better support for multiprocessors someday" - they added a qualifier to "multiprocessing" because they were looking forward to being able to provide much better support for multiprocessors someday, and they chose the qualifier "asymmetric" because the systems were not symmetric and the "much better support" they had in mind was making them symmetric.
"and that would be symmetric multiprocessing, where processors are not limited in their capabilities due to software limitations."  Well, software limitations and hardware limitations where only some processors have the physical ability to run privileged code or to control particular peripherals.
A giant lock does not limit the capabilities particular processors have; it limits, instead, the extent to which more than one processor can run in certain sections of code.  If a particular line of multiprocessors were to start out as master/slave, allow all processors to run privileged code and perform I/O operations in a later OS release (and perhaps with later versions of the hardware, if those limitations were in part or in whole due to hardware limitations) with a giant lock, and still later were to make the locking more fine-grained, symmetry would have been achieved by the second step; the subsequent improvement is that the system achieved fine-grained locking, not symmetry.
The lack of multiple threads of control within a single process does not limit the capabilities particular processors have; it limits, instead, the extent to which the code within a process can be run in parallel, with more than one processor participating.  If a particular line of processors were to start out as master/slave and not have multiple threads of control within a single process, allow all processors to run privileged code and perform I/O operations in a later OS release (and perhaps with later versions of the hardware, if those limitations were in part or in whole due to hardware limitations) and still not allow multiple threads of control within a single process, and still later were to add support for multiple threads of control within a single process, symmetry would have been achieved by the second step; the subsequent improvement is that the system achieved threading, not symmetry.
And, on the other side, a system in which all processors can execute privileged code, but not all processors can perform I/O operations on most peripherals (for hardware or software reasons), could lock what privileged code is run on all processors with fine-grained locks, and could support multiple schedulable threads within a single process.  Such a system is asymmetric, not symmetric.  It might not have been deemed worthwhile, at the time asymmetric systems were being built, to provide those capabilities in those systems, but they are still technically possible to provide.
I.e., symmetry, fine-grained locking, and threading within processes, all of which allow a system to make more full use of multiple processors, are orthogonal capabilities.  The lack of symmetry makes a system asymmetric; neither the lack of fine-grained locking nor the lack of threading within processes on a system with symmetry between processors makes a system asymmetric.
I have seen no indication that the term "asymmetric" was used to describe a system for any reason other than the lack of symmetry between the processors. What you described was people using it in anticipation of systems that provided symmetry between processors, regardless of how fine-grained the locking was in those systems or how many threads of control were supported within a process. Guy Harris (talk) 18:33, 11 April 2013 (UTC)
replies: text: Your arguments are cogent and well thought out.  I think it is time to start updating the article.  Much of what you have written could be placed in the article to describe asymmetric multiprocessing and how it relates to other multiprocessing concepts.  If you will do the initial edit I will be happy to help. John Sauter (talk) 00:59, 12 April 2013 (UTC)
thread_title:  part 7 

message: It sounds as if you have a definition of "SMP" that has nothing to do with symmetry, but have no citations for that.  As such, I consider it to be your personal definition, rather than a standard definition, and, as it uses the term "symmetric" but doesn't consider a system that's completely symmetric, at the hardware and software level, with regards to the processors, as being symmetric, merely because it does not support multiple threads of control within a single process, I consider it an inaccurate, confusing and misleading definition.  There are several ways to improve the use of CPUs by an MP system; removing hardware and software asymmetry is only one of them - making the locking finer-grained is one (and that's "finer-grained", so it's not as if you have a giant lock and then you have "fine-grained locking"; you can go past a single giant lock - earlier versions of OS X didn't have a single giant lock, but weren't generally all that fine-grained in their locking - and it improved over time), as would be adding support for kernel-level threading within a single process to a system that didn't have it.
So I see no valid reason to consider Multics ASMP, and will remove it from this page. Guy Harris (talk) 16:48, 9 April 2013 (UTC)
thread_title:  Multics as "asymmetric" 

message: I did a Google search for asymmetric multiprocessing and found several references since the mid 1980s.  I haven't read them yet, but I think there is evidence that the term is still being used.  Perhaps the article needs to have a description of how the meaning of asymmetric multiprocessing has changed over time. John Sauter (talk) 01:03, 12 April 2013 (UTC)
thread_title:  not obsolete 

message: Hello fellow Wikipedians,
I have just modified  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 ).
Cheers.—InternetArchiveBot (Report bug) 11:29, 20 October 2016 (UTC)
thread_title:  External links modified