Template talk:Infobox CPU

message: How about adding "Number of cores" or (i.e. |cores=4 to the template? +mt 22:51, 7 August 2007 (UTC)
replies: text: . Added as numcores --TheJosh 12:41, 8 August 2007 (UTC)
thread_title:  Number of cores 

message: I'm wondering, is there a good reason why the "slow-unit" and "fast-unit" parameters have to be separate from the actual values? Seems like overengineering; why not just use "slowest = 450 MHz" etc? -- intgr [talk] 20:53, 4 August 2008 (UTC)
replies: text: It was originally so that the units would automatically become links. Not its just legacy (unless if someone wants to put Template:AutoLink back. TheJosh (talk) 02:47, 5 August 2008 (UTC)

text: Actually, since there are less than 100 articles using this template, I'm tempted to just break the current usage and fix them up manually. Seems like it would be less total effort if we do it now. Ham Pastrami (talk) 02:32, 15 February 2009 (UTC)
replies: text:  You've got my support there. The current parameters all appear fairly arbitrary to me. Chris Cunningham (not at work) - talk 09:33, 15 February 2009 (UTC)
thread_title:  Unit parameters 

message: I don't like the behaviour of resizing the image by default. Many images look terrible because of suck resizing. I'd suggest applying a default resizing ONLY for images bigger that the default size. Richard Wolf VI (talk) 02:21, 12 October 2009 (UTC)
thread_title:  Image size 

message: AMD's HyperTransport is in the box... why isn't QPI? It's misleading on pages like Xeon, implying that FSB is the same as QPI.
DEC42 (talk) 16:41, 31 October 2009 (UTC)
thread_title:  Adding QuickPath to the Infobox 

message: How about a transistor count?  Willus (talk) 13:25, 13 February 2010 (UTC)
replies: text: That's now the "transistors" parameter. Guy Harris (talk) 04:05, 9 February 2021 (UTC)
thread_title:  Transistor count? 

message: there seems to be a problem with the way other editors sees the added info into the template a problem, tell me all of the problems you have with it first! before reverting. and i will gladly tell you my problems with the old template, I'm trying to improve wikipedia just as much as you guys, but I'm always having to fight to make things better, My edits include the addition for adding more information in a list manner in a single infobox, some will argue that the infobox will become to big, this is true however not ALL tags are in every template it really is not that big compared to most templates on wikipedia, an example would be the microsoft one the one with net worth and all that. help me improve wiki so i can help you. — Preceding unsigned comment added by Matthew Anthony Smith  (talk • contribs) 12:35, 6 September 2012‎ (UTC)
: No, the problem is 1) that at least six other editors disagree with you that your changes are improvements and 2) that you seem to have some difficulties in communicating with other editors, making it quite hard to reach some sort of solution or consensus here.  —Ruud 23:26, 6 September 2012 (UTC)
replies: text: well to bad then you have to come up with a reason how it breaks the template, because that's the ONLY reason why the other editors reverted it is for breaking  old information from showing in old generic template. all of those 6 editors say the samethign as you the about breaking content, I have FIXED them ALL. if you are seeing something that I am not tell me then and I will not have any problem at all to help solve it. Matthew Smith (talk) 23:39, 6 September 2012 (UTC)
replies: text: Random bypasser here. I've reverted to the old-stable version, and set up a Template:Infobox CPU/sandbox and Template:Infobox CPU/testcases. Please do NOT push changes live, until there is both certainty that nothing is broken (with confirmation from anyone who is familiar with the template's history and usage), and until there is WP:consensus that the changes are widely desired. This includes aspects such as parameter order, parameter quantity, box design, box accessibility, etc. Remember, there is no rush to get things right (it's endless, nothing is perfect), but clear problems have to be fixed ASAP, or simply reverted, so that readers don't suffer. Thanks! (Further comments at Matthew's talkpage). —Quiddity (talk) 00:34, 7 September 2012 (UTC)
replies: text:  why is Ruud so rude, he files countless complaints, accuses me of sock puppetry, of vandalism, its not right and now he has got me down for a block... why block someone who is helping! this is what hes accusing me of as WP:ANEW I'm not saying Ruud is a bad admin, but I am saying he does not take the time to look at the comments I make first, he assumes and just does and that is not professional. Matthew Smith (talk) 01:00, 7 September 2012 (UTC)
replies: text:  Unfortunately, the road to hell is paved with good intentions. This template is used on over 100 pages and due to your bold changes and the ensuing edit warring, some articles now require different versions of this template. This needs to be cleaned up first. Afterwards we can discuss the changes that should be made to this template, as there certainly is some room for improvement. However, this should be done in small, carefully considered increments as—again—over 100 articles are already using this template. On some occasions being bold is a good thing, but modifying a highly-used and complex template—especially if you are fairly inexperienced with template design—is not one of them. The rushed and uncollaborative approach you have been taking so far—simply proclaiming you are right and everyone else is wrong—is not the way to go forward. —Ruud 17:44, 7 September 2012 (UTC)
thread_title:  Generic Template Improvement consensus 

message: Was looking at the Xeon article trying to figure out which of them had HT support. Having this in the info box would be helpful.
If Hyper Thread is too Intel specicific, something like "number of threads" or some other more generic version of the information could also work fine.  — Preceding unsigned comment added by 184.65.99.106 (talk) 05:03, 22 October 2012 (UTC)
replies: text: Yes, "numthreads=", with a title of "Number of threads" or "Threads per core" as appropriate (the former being threads-per-core*number-of-cores and the latter being what it says it is), might make sense. Anything with "hyper" in it would be too Intel-specific. Guy Harris (talk) 09:01, 28 March 2023 (UTC)
thread_title:  How about hyper threaded/number of threads? 

message: How about adding support for "gpudram" parameter to the CPU Infobox, please?  It should go after the current "llcache" parameter, and it would make it possible to specify the amount of integrated GPU DRAM, what's one of the latest features of Intel Haswell microarchitecture.
While there, it would be also good to add support for the "gpu" parameter, as numerous CPUs are having an integrated GPU nowadays.  That would allow GPU specs within info boxes, what should be quite neat and usable.  Of course, "gpu" would fit the best after "llcache" and before "gpudram".
Please advise, and sorry if this isn't the right place for such questions / suggestions.
-- Dsimic (talk) 22:32, 15 September 2013 (UTC)
replies: text: I've moved this here from Template talk:Infobox. Jackmcbarn (talk) 22:35, 15 September 2013 (UTC)
replies: text:  Thank you!  I wasn't sure where to post this anyway. :) -- Dsimic (talk) 22:40, 15 September 2013 (UTC)
replies: text:  Already did this before seeing this (for Apple A7) and reverted since it didn't work.. See change and comment there: https://en.wikipedia.org/w/index.php?title=Template%3AInfobox_CPU&diff=573629231&oldid=547623399 comp.arch (talk) 11:51, 19 September 2013 (UTC)
replies: text:  Added again (only gpu - for now) and it worked. Keeping it unless there are objections. comp.arch (talk) 11:57, 19 September 2013 (UTC)
replies: text:  Comp.arch, you added the GPU field to bottom of the template, rather than after the Cache fields, as proposed.  Having the GPU appear after the predecessor/sucessoror/variant fields is really awkward.  I also notice that you didn't update the template documentation.  Could you make these additional changes? I could lend a hand if you need help.  —RP88 (talk) 12:07, 19 September 2013 (UTC)
replies: text:  OK, I moved the "gpu" field to immediately after the "llcache", as proposed and updated the docs accordingly. —RP88 (talk) 12:30, 19 September 2013 (UTC)
replies: text:  Looking good to me!  You're right Comp.arch, adding the number of GPU cores (or Execution Units) would be useful, it should probably be named "gpu-numcores" so we keep the naming scheme consistent.  Also, "gpu-memory" (instead of previously proposed "gpudram") would be really useful, as it would be having "gpu-slowest" / "gpu-slow-unit" and "gpu-fastest" / "gpu-fast-unit".  That way, we'd end up with the following series: "gpu", "gpu-numcores", "gpu-memory", "gpu-slowest", "gpu-fastest", "gpu-slow-unit", "gpu-fast-unit"... Thoughts? -- Dsimic (talk) 14:30, 19 September 2013 (UTC)

text:  Also, it seems that many articles using this info box are alreay having values defined for the "gpu" parameter, Ivy Bridge (microarchitecture) for example.  Those values existed as defined before the today's addition of "gpu" parameter itself.  Any insights, please?  Sorry if this is a dumb question, I'm not familiar with the internals of templates. -- Dsimic (talk) 15:03, 19 September 2013 (UTC)
replies: text:  Looking at edit histories, It looks like there was a proposal to add a "gpu" parameter a year ago, so editors probably started adding "gnu" fields to CPU infoboxes in anticipation that the template would soon be updated.  However, it looks like that earlier attempt got bogged down somehow and was never completed (maybe due to disagreement about what extra parameters to add or something to do with template layout changes?) Maybe we can take that failure to heart and be careful about too much extra complexity related to the GPU field.  —RP88 (talk) 17:15, 19 September 2013 (UTC)
replies: text:  Sure thing, all changes to info box templates should in general happen only when a consensus is reached.  I'm sure there are even more people having a much broader insight into potential issues with the whole proposal, and we should just see how to bring their attention?  The whole GPU addition thing sounds as something to be useful, but — as always — there's a lot of room for otherwise hidden issues down the road.  Thoughts? -- Dsimic (talk) 17:56, 19 September 2013 (UTC)
thread_title:  CPU Infobox: gpu & gpu-memory 

message: There is no resolution if the CPU is 32 or 64bit, which is important today (32 or 64 bit ARM, only 32bit Intel Atom, both 32 and 64 bit Intel-compatible and so on). --Milan Kerslager (talk) 22:31, 18 September 2013 (UTC)
replies: text: What is the bit width of the CPU?  If it's the bit width of the instruction set, you can put that in "arch=", e.g. IA-32 vs. x86-64, System/390 vs. z/Architecture, PowerPC (32-bit) vs. PowerPC (64-bit), whatever of the 10,000 different terms ARM offers that could be used for 32-bit vs. 64-bit, etc.  If it's a bus width, there are parameters for that. Guy Harris (talk) 08:54, 28 March 2023 (UTC)
thread_title:  Number of bits 

message: I noticed in Sandy Bridge:
| clock = 1.60 GHz to 3.60 GHz
(GHz link) didn't show up. Nothing about clock in Template or talk page. I assume you all know. GPUs also have clock rate, maybe that is delaying adding this. That is recent addition however and I guess doesn't matter. Couldn't figure out label5.. Notice also similar to this:
| cores1 = 4–6 (8–12) (Extreme)
| cores2 = 2–8 (4–16) (Xeon)  comp.arch (talk) 17:29, 25 September 2013 (UTC)
replies: text: . now you can use the new parameter ″numcores″ or the old ″cores1″...″cores5″. --W like wiki good to know 10:20, 30 October 2019 (UTC)
thread_title:  Clock (= label5?) and more not being displayed 

message: Currently this looks extremely ugly, with multiple "Extensions" labels. Why don't we just group them into one label, optionally putting some 's in between them? Timothy G. from CA (talk) 19:09, 8 February 2015 (UTC)
replies: text: . Timothy G. from CA (talk) 19:22, 8 February 2015 (UTC)
thread_title:  Multiple "Extensions" labels 

message: Request for 1 or more generic fields to be added, at the bottom of the template, so we can add information that doesn't fall into your "bin names".  This concept has been in "Template:Infobox settlement" for a very long time, search for "blank_name" and "blank_info".  Thanks in advance!  • Sbmeirow • Talk • 03:23, 10 February 2015 (UTC)
thread_title:  REQUEST - please add 1 or more generic fields 

message: I have added two new parameters:
Example using the MOS Technology 6502 CPU:
:data-width = Data width 	8
:address-width = Address width 	16
Thus the base unit for data processing is 8-bits and it has an address bus of 16-bits so it can make use of 64 kB (64*2^10) of RAM. Bytesock (talk) 13:06, 5 May 2016 (UTC)
replies: text: "Data processing" in "the base unit for data processing" presumably means "movement of data into and out of the CPU"; there are CPUs where the data bus between the CPU and memory is wider than, or narrower than, the registers and the widest data processed by integer arithmetic instructions, for example. Guy Harris (talk) 18:14, 5 May 2016 (UTC)
thread_title:  Data and address width 

message: Is "arch" supposed to be the instruction set architecture (e.g., x86, PowerPC, x86-64, etc.), or is it supposed to be the microarchitecture (e.g., NetBurst, Intel Core microarchitecture)?  I'd vote for "instruction set architecture".  Both appear to be used. Guy Harris 21:57, 29 November 2006 (UTC)
replies: text: I originally designed it as instruction set arch, but both could be used ie arch=x86 (NetBurst) --TheJosh 00:18, 30 November 2006 (UTC)
replies: text: So should we use it for both, or should we add another tag for the microarchitecture? Guy Harris 07:47, 30 November 2006 (UTC)
replies: text: Not sure. Only about 20 articles actually use this template (although it would be good to see more) At this point, nothing special is done on the field, except for autolinking (turning plain text into a link if it wont cause a red link). If you think a microarch should be put in, go right ahead, or say so and I will if you dont know how. --TheJosh 08:36, 30 November 2006 (UTC)
replies: text: OK, I've added "microarch" and updated some pages. Guy Harris 08:54, 30 November 2006 (UTC)
replies: text: Fixed link in "red link" above - G.A.S 16:25, 12 May 2007 (UTC)
thread_title:  What is "arch"? 

message: Back when I added the "microarch" parameter, my intent was that "arch" be the instruction set architecture implemented by the CPU and that "microarch" be the microarchitecture of the CPU.
A later set of edits appeared to be intended to "split arch and microarch with instructions and extensions without losing compatibility"; the template documentation was updated to reflect that.  Many of that editor's changes were reverted, although the documentation wasn't reverted as well; I fixed the documentation up a bit.
So:
*Is it considered useful to have "arch" be a family of microarchitectures and "microarch" be the member of that family, as the second editor apparently intended?  Note that such a change means some Magic Elves would have to go fix all the uses of  template to use them in the new fashion and, presumably, to use "instructions" for the instruction set architecture(s).
*If not, is it considered useful to have the "instructions" parameter? Guy Harris (talk) 09:12, 10 February 2015 (UTC)
replies: text: Haswell (microarchitecture) uses both "instructions" and "extensions" to list instruction set features not present in the 80386 (i.e., everything - or, at least, everything big, the byte-swapping instructions, the compare-and-exchange instructions, the conditional move instructions, etc. presumably not being big enough to deserve Wikipedia pages and thus not big enough to deserve being listed :-)).  It lists MMX under "instructions" and SSE etc. under "extensions".  At least according to the MMX article, the "X" did stand for "eXtensions" in Intel marketing material, so the fact that MMX didn't officially have "extensions" in its name doesn't seem sufficient to render it not an "extension", and even if that weren't the case I'd call that a pretty feeble argument for listing it under "instructions". Guy Harris (talk) 09:24, 10 February 2015 (UTC)
thread_title:  "arch" vs. "instructions" 

message: I miss a parameter like family or part-of where you can see imediatelly that for example Silvermont or Goldmont are part of Atom processor family, like here: Tick–tock model#atom-roadmap. --W like wiki good to know 14:40, 30 October 2019 (UTC)
thread_title:  "family" 

message: The Arm architecture complicates the process of describing a CPU.  The "Arm architecture" has multiple versions and, in later versions, three different profiles - "A", "R", and "M" (geddit?).
It also has three instruction sets: "A32" (traditional 32-bit Arm), "T32" (Thumb and Thumb-2), and "A64".  Different versions, and different profiles, support different (possibly improper) subsets of those instruction sets.
Unfortunately, there's no parameter shown as "architecture".  If "arch" were just shown as "Architecture", Arm processors could have "ArmvN" as the "Architecture", and some combination of A32, T32 (or, for older processors, just "Thumb" if it's the original 16-bit-only version), and A64, possibly also listing various extensions. Guy Harris (talk) 19:19, 27 March 2020 (UTC)
thread_title:  "Architecture" vs. "Instruction set" 

message: === Manufacturing Process Nomenclature ===
Some pages, e.g,. Haswell (microarchitecture) and Skylake (microarchitecture) are misusing the "transistors" field to list the manufacturing process resolution, e.g., "Transistors: 14nm transistors".  This is completely wrong, the 14nm is the smallest feature size; the actual transistors are serveral times larger.
What is a better terminology to use here?  Does it need a new template item?  — Preceding unsigned comment added by 118.92.151.74 (talk) 07:46, 1 October 2015 (UTC)
replies: text: Hi, for this is already the parameter size-from and size-to existing which are listed under label Min. feature size. So maybe we have to change the label name into Process (like here) or Techn. node? --W like wiki good to know 09:07, 30 October 2019 (UTC)
thread_title:  Manufacturing Process 

message: Some pages, e.g,. Haswell (microarchitecture) and Skylake (microarchitecture) are misusing the "transistors" field to list the manufacturing process resolution, e.g., "Transistors: 14nm transistors".  This is completely wrong, the 14nm is the smallest feature size; the actual transistors are serveral times larger.
What is a better terminology to use here?  Does it need a new template item?  — Preceding unsigned comment added by 118.92.151.74 (talk) 07:46, 1 October 2015 (UTC)
thread_title:  Manufacturing Process Nomenclature 

message: How about a new template parameter manufacturing_process? This could include information like feature size (e.g. 14nm), or (especially for historic CPUs) technology such as NMOS, CMOS, ECL, etc. SJK (talk) 13:31, 12 June 2018 (UTC)
replies: text: Hi, for this is already the parameter size-from and size-to existing which are listed under label Min. feature size. So maybe we have to change the label name into Process (like here) or Techn. node? --W like wiki good to know 09:07, 30 October 2019 (UTC)
thread_title:  Proposal: manufacturing_process 

message: === Produced-start/end ===
Has anyone realized that those dates are usually not publicly available? What everyone has been filling in is the date when shops can start selling the products and when the company stopped general availability. These fields should be renamed to reflect the practice. Rilak (talk) 05:58, 10 May 2009 (UTC)
replies: text: Hi Artem, the name of the parameter we have to keep because it is used on some paged under the 300 pages which are linking here. But I picked up your thoughts and changed the label to "Introduced". After I checked Intel's ark-pages, e.g.: core-i7-990x. There they call it "Launched" and "Discontinued". So it is also possible, that we use the existing parameters produced-start and produced-end and just changing the labels to "Launched on" and "Discontinued on". And the created parameter we could merged with the produced-start under the same Launched-label. --W like wiki good to know 23:37, 30 October 2019 (UTC)
replies: text: I did it, hope it 's ok? --W like wiki good to know 07:17, 14 November 2019 (UTC)
replies: text:   well that's a sorry excuse to the concerns expressed by  and . Fixing the label addresses the appearance to readers, but adds further confusion in that now the field doesn't match the label. Parameter names are corrected all the time; just create new parameters and keep the old ones for backward compatibility, then update the documentation so that editors use the new (correct) parameter names going forward. – voidxor 01:14, 9 February 2021 (UTC)
thread_title:  Dates 

message: Has anyone realized that those dates are usually not publicly available? What everyone has been filling in is the date when shops can start selling the products and when the company stopped general availability. These fields should be renamed to reflect the practice. Rilak (talk) 05:58, 10 May 2009 (UTC)
thread_title:  Produced-start/end 

message: Doesn't make any sense at all. CPU architectures sometimes take up to five years to develop and in most cases WP articles list an official release date for an architecture. I suggest we rename this field to e.g. "Released on", "Announced on", "Introduced on" or something similar. Artem S. Tashkinov (talk) 15:21, 4 August 2019 (UTC)
replies: text: Hi Artem, the name of the parameter we have to keep because it is used on some paged under the 300 pages which are linking here. But I picked up your thoughts and changed the label to "Introduced". After I checked Intel's ark-pages, e.g.: core-i7-990x. There they call it "Launched" and "Discontinued". So it is also possible, that we use the existing parameters produced-start and produced-end and just changing the labels to "Launched on" and "Discontinued on". And the created parameter we could merged with the produced-start under the same Launched-label. --W like wiki good to know 23:37, 30 October 2019 (UTC)
replies: text: I did it, hope it 's ok? --W like wiki good to know 07:17, 14 November 2019 (UTC)
replies: text:   well that's a sorry excuse to the concerns expressed by  and . Fixing the label addresses the appearance to readers, but adds further confusion in that now the field doesn't match the label. Parameter names are corrected all the time; just create new parameters and keep the old ones for backward compatibility, then update the documentation so that editors use the new (correct) parameter names going forward. – voidxor 01:14, 9 February 2021 (UTC)
thread_title:  The "Created" field 

message: Can the announcement date of CPU be equally as important as the release date?  Usually, when there has been announcement on the news or publication they plan on releasing the product(s) at later date with pricing as well. Rjluna2 (talk) 12:53, 11 September 2019 (UTC)
thread_title:  Announcement versus Release Date? 

message: === Arrangement ===
It seems logical to place the Core name(s) immediately after the number of cores. I realize a number of articles use this infobox (and have never edited an infobox before), so I am hesitant to do it myself without discussing here. But this might clean up the flow of the infoboxes. Dbsseven (talk) 00:29, 8 November 2017 (UTC)
replies: text: Hi Dbsseven, the Core names are not the names for each of the 2, 4, 8 cores ;-) The creator of this parameter intended more the meaning model names or product names. --W like wiki good to know 13:31, 30 October 2019 (UTC)

text: .
=== Core names – Product code names – Models – Variants ===
Hi, here a copy from the doc page:
* core1                     = (1..9) Names of the cores
* pcode1                    = (1..9) Product code names
* model1                    = (1..9) Model names
* variant                   = Variants in the same family and generation
I think, all of these 4 are the same and could be merged. Just look in the history how they entered this infobox. --W like wiki good to know 13:48, 30 October 2019 (UTC)
thread_title:  Names (Products, models, variants) 

message: It seems logical to place the Core name(s) immediately after the number of cores. I realize a number of articles use this infobox (and have never edited an infobox before), so I am hesitant to do it myself without discussing here. But this might clean up the flow of the infoboxes. Dbsseven (talk) 00:29, 8 November 2017 (UTC)
replies: text: Hi Dbsseven, the Core names are not the names for each of the 2, 4, 8 cores ;-) The creator of this parameter intended more the meaning model names or product names. --W like wiki good to know 13:31, 30 October 2019 (UTC)
thread_title:  Arrangement 

message: Hi, here a copy from the doc page:
* core1                     = (1..9) Names of the cores
* pcode1                    = (1..9) Product code names
* model1                    = (1..9) Model names
* variant                   = Variants in the same family and generation
I think, all of these 4 are the same and could be merged. Just look in the history how they entered this infobox. --W like wiki good to know 13:48, 30 October 2019 (UTC)
thread_title:  Core names – Product code names – Models – Variants 

message: and they could be arranged next to one another like this:
<-  Predecessor   |  Successor -> 
chip_prev      |   chip_next 
Hopefully this formats correctly. I'd draw a sketch but uploading images to MediaWiki is a pain lmao  Mapmaker345 (talk) 17:23, 14 September 2021 (UTC)
thread_title:  Predecessor and Successor could have <- & -> arrows  

message: I'm trying to find a good infobox for the PDP-11 and Raytheon 704. PDP-11 uses "Infobox information appliance", which seems very wrong, but lacking anything better I used that in the 704 article as well. I don't believe Infobox CPU is intended to be used for this either. So what is?
One of the (many) goals of the infobox system is to provide clear semantic information about the article topic. A page with infobox video game is generally going to be about video games (contrast with the profusion of categories). This suggests there should be some granularity in the infoboxes so one can map to the correct content type. This is currently lacking.
I just noticed that the original Mac 128 is also an "information appliance" which puts it in the same list as the PDP-11, which I absolutely object to. They are not the same class of machine, and neither is rightfully referred to as an "information appliance". Our own definition accurately describes such as "designed and pre-configured for a single application". Neither machine remotely fits this definition. Sure, one can bend the definitions to fit these machines, but that's precisely what we want to avoid in order to accurately describe the content.
Likewise, the CPU infobox appears to be intended to refer to stand-alone CPU designs. The Mac 128 is not a CPU either. 
So... I believe we need an "infobox computer", possibly marked as a template that should not be used in favour of one of several sub-templates, "mainframe computer", "minicomputer", "microcomputer" and yes, "information appliance". I'm sure there are others that would also be useful.
Maury Markowitz (talk) 13:56, 23 September 2021 (UTC)
replies: text: Note: this is also being discussed at . Guy Harris (talk) 19:53, 23 September 2021 (UTC)
replies: text:  has been renamed .  I guess a KA{whatever} would be the "CPU" of a given PDP-11 model. Guy Harris (talk) 08:58, 28 March 2023 (UTC)
thread_title:  Is a PDP-11 a CPU? An information appliance? Neither?

message: Can we use Technology Process at the Architecture and classification section?  For example, the technology process can be PMOS, NMOS, CMOS, CHMOS, and et cetera.  Rjluna2 (talk) 14:05, 15 May 2023 (UTC)
thread_title:  Technology Process 

message: I edited the docs to remove ; it's not supported and I couldn't see how it was supposed to be distinct from .  However, it was in use at three articles, all of which were using  with a different value; see e.g. :Zen 2.  Does anybody with a bit more understanding of the topic know what the article author was intending, and if the infobox should be modified to support it?  Thanks, Wham2001 (talk) 17:51, 13 August 2023 (UTC)
replies: text: @Wham2001 There was support for codename parameters in the CPU infobox template at one point, but that support was later removed, as it was made by a blocked sockpuppet in evasion of a block on a previous account (see the WP:EVASION section of the blocking policy). The infobox edits adding the codenames on those Zen architecture articles were also made by the same blocked editor. — AP 499D25 (talk) 11:21, 21 August 2023 (UTC)
replies: text: Thanks – that's clear now.  I've deleted the codename params from :Zen 2 and :Zen 4; I see that you did :Zen 3 already.  Best, Wham2001 (talk) 11:32, 21 August 2023 (UTC)
thread_title:  Codenames