Template talk:Infobox CPU architecture

This is the talk page for discussing improvements to the Infobox CPU architecture template.

Put new text under old text. Click here to start a new topic. New to Wikipedia? Welcome! Learn to edit; get help. Assume good faith Be polite and avoid personal attacks Be welcoming to newcomers Seek dispute resolution if needed

Infoboxes on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.InfoboxesWikipedia:WikiProject InfoboxesTemplate:WikiProject InfoboxesInfoboxes articles

Computing Template‑class

This template is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing articles Template This template does not require a rating on Wikipedia's content assessment scale. This template is supported by Computer hardware task force.

I assume this field is supposed to state how many bits the architecture is? I don't believe "bus" is correct term to describe this. "Bits" is a more appropriate term. Rilak (talk) 05:34, 11 May 2009 (UTC)[reply]

I used 'bus' as in address bus. I've now changed it to 'bits', as you consider that to be more appropriate. Thank you for your input, it is appreciated. -- Frap (talk) 12:20, 11 May 2009 (UTC)[reply]

'Bus' isn't even appropriate for discussing "bits" - an instruction set architecture doesn't have a bus, and different implementations of that architecture can have different numbers of buses and different widths of those buses. I'll change the documentation.

Guy Harris (talk) 22:19, 2 October 2009 (UTC)[reply

]

Registers

"Registers" by itself is ambiguous. It needs to be restricted. Stating the number of general purpose registers and floating-point registers is sufficient for a very brief overview. Rilak (talk) 05:41, 11 May 2009 (UTC)[reply]

How is it ambiguous? How should it be restricted? My idea that the number of registers could be stated among with bits of the register, and type of register, example "16x 32-bit floating point registers". -- Frap (talk) 12:23, 11 May 2009 (UTC)[reply]

Presently, the infobox just says "Registers". Its ambiguous. A processor has many registers. Obviously it isn't possible to state all of them. I know the template documentation explains what to state, but it isn't helpful to the audience as it isn't mentioned on the template. Rilak (talk) 12:35, 11 May 2009 (UTC)[reply]

I saw on your userpage that RISC is a special interest of yours. You have more knowledge than me on this topic. Do you have any proposals? Would you like to see the 'Registers' field removed? Frap (talk) 18:21, 11 May 2009 (UTC)[reply]

I think mentioning the number and width of general purpose registers and floating-point registers is sufficient. The registers field should be replaced with two new fields: "GP registers" and "FP registers", as "registers" is ambiguous. Rilak (talk) 09:14, 12 May 2009 (UTC)[reply]

But I made 'Registers' a header, instead of just a normal field, so that the user are able to specify more registers than GP and FP, such as in the case of Itanium, "64 1-bit predicate registers". -- Frap (talk) 09:57, 13 May 2009 (UTC)[reply]

I proposed the changes becuase the type of register is not mentioned in example and the documentation doesn't say, "specify what type". If it were made unambiguous, it would work. Rilak (talk) 10:45, 13 May 2009 (UTC)[reply]

Any reason why this infobox has no parameters for images? Many of the architectures have logos. It would be useful to have a slot for them. --Lester 12:08, 30 January 2010 (UTC)[reply]

I didn't know there were any architectures that had logos. -- Frap (talk) 16:47, 30 January 2010 (UTC)[reply]

So is a "register-register" architecture a "load-store architecture", where the only instructions that refer to data in memory are load and store instructions, with all arithmetic instructions are register-register? That might need to be clarified, as somebody listed the

]

Template title

Shouldn't this template be called something like "Infobox ISA"? "CPU architecture" could conceivably misinterpreted to mean "microarchitecture". 50504F (talk) 10:33, 28 May 2017 (UTC)[reply]

Hi there,

Since the infobox has a field called "bits", representing the bus width, I figured it'd be good to define whether that field is referring to the address bus width or the data bus width. It appears to be referring to the data bus width, so I expanded the name to specify that, giving it the name "Data bus width".

To help decrease the ambiguity, I also added another field called "Address bus width".

I'm not sure if both of these attributes are consistent among every implementation of an architecture (e.g.: x86-64), but the infobox seems to make that assumption, so I went with it

InternetMeme (talk) 23:05, 12 January 2018 (UTC)[reply]

CPU architecture here means

8088

), they have register/etc. widths.

Most ISAs have a single width, although some may not use all bits of registers in addresses (for example,

Motorola 68012

only used the lower 31 bits).

So I'm reverting this change. It needs some discussion if we're going to mention more than one width.

Guy Harris (talk) 23:26, 12 January 2018 (UTC)[reply

]

Ahh, that makes sense. In that case, all that needs to be done is a clarification of what the "bits" are referring to. I'll to it now.

InternetMeme (talk) 23:45, 12 January 2018 (UTC)[reply]

That's an incorrect clarification. True 64-bit ISAs have 64-bit pointers, even if only some number of bits significantly > 32 in the pointer are used and the rest are either ignored or required to be all zero or all one. And, again, it's not a bus width; a 32-bit machine might, for example, have a wider memory bus that it uses to fill cache lines.

Guy Harris (talk) 23:50, 12 January 2018 (UTC)[reply

]

Okay, it looks like you'll have to do it: What is the correct wording to specify that the "bits" field isn't referring to the Address bus? The kludgy way to do it is to change the field name to "Bits (this is not the Address bus width". But that's clearly terrible.

The wording needs to be such that when a typical reader reads the "bits" column, they can tell that it's not referring to the Address bus width. It sounds like you're better qualified to figure out the best wording.

InternetMeme (talk)

"Bits" is the address width, even if, on some implementations of some architectures, not all the bits are used. See 64-bit computing#Limits of processors for what address limitations some 64-bit ISAs impose (although it should perhaps be updated for Intel's proposed extension for 5-level page tables to allow all 64 bits of address to be used).

The documentation speaks of an "address" field, but it's not implemented. If we decide that we need a separate field to indicate how many bits are available for addressing, it would need to be implemented, its documentation needs to be fixed to remove all mention of a "bus", and it needs to say something such as "Address width", again, without mentioning buses. "Bus" is a word that should not appear anywhere in this template, as buses are an implementation detail, not an architectural detail.

But I'll wait for some more discussion before doing any of that.

Guy Harris (talk) 00:21, 13 January 2018 (UTC)[reply

]

A general "addressing" field, displayed just as "Addressing", could be used for multiple purposes here, indicating not only how many of the bits of the architectural bit width are "live" for addressing (and, if there are multiple answers, as with x86-64, giving more details), but also discussing segmentation and other ways in which the address space isn't just a simple linear address space, as appropriate.

Guy Harris (talk) 03:24, 13 January 2018 (UTC)[reply

]

Ahh, thanks for your comments! I'm learning some things about CPU architecture here : ) Those ideas make good sense, but they do sound like they'd take a lot of work, and I think there may be an easier way to solve the problem I want to address. I'll try to explain it better:

The root of the problem is that many people who are interested in the history and progress of computing power want to know "how many bits" various CPUs are capable of addressing. A good example of where some confusion lies is with the Atari Jaguar, which claimed to be a 64-bit processor, but which in most important respects was a 32-bit system. Also, many people are interested in finding out when common mobile devices reached the 64-bit stage, and often want to compare iPhones to Android devices, etc.

The thing I'm worried will happen is that people will click an article on a particular CPU architecture and see "64-bit" written near the top, and immediately conclude that systems based on the chip are 64-bit systems. It's a difficult problem to solve without placing some kind of note near the top of the infobox. And it's such a complicated concept that it's even harder to find good concise wording to express it. But something along the lines of "This number denotes register width, and does not reflect the Address Bus width (the number commonly associated with, e.g., a "32-bit system" or "64-bit system" designation) of systems based on this CPU". Perhaps a footnote with a ref number would work? What kind of ideas do you think would work?

And thanks for your help in explaining these things to me!

InternetMeme (talk) 12:25, 13 January 2018 (UTC)[reply]

The best way to deal with systems like that Atari Jaguar is, rather than to call them "64-bit", to specify which elements of the system are 64-bit and which elements aren't, even if the vendors might have called them "64-bit" for promotional reasons. "64-bit" should be reserved for systems where the processor instruction set generates 64-bit addresses internally.

Note that the Atari Jaguar doesn't use this infobox, because it's not an article about an instruction set architecture, so changing this infobox won't help there. The Atari Jaguar article itself seems pretty clear that it's not a "64-bit"s system, it's a system with some 64-bit arithmetic support in the object processor and blitter, but with otherwise 32-bit processors. Furthermore, your edits to 64-bit computing to split the hardware timeline into "hardware that can do 64-bit data processing" and "hardware that can do 64-bit data processing and use 64-bit pointers" timelines puts the Jaguar into the first category, further reducing the chances that people will be confused about it.

"...people will click an article on a particular CPU architecture and see "64-bit" written near the top, and immediately conclude that systems based on the chip are 64-bit systems" is a separate issue. If the instruction set architecture doesn't support 64-bit addressing (even with some high-order bits ignored or required to be all-zeroes or all-ones), then the infobox for that instruction set architecture shouldn't say "64-bit", which solves the problem for those ISAs. If the ISA supports 64-bit addressing, but some particular system runs a processor with that ISA in 32-bit mode - for example, because there's no 64-bit OS for it yet - that's something for the page about the system to explain, if there are any such systems.

So what examples are there of ISAs where either 1) the {{Infobox CPU architecture}} says "64-bit" but the ISA doesn't actually support 64-bit addressing (even with the limitations mentioned, so x86-64 doesn't count here) or 2) the template says it's 64-bit but some system using processors with that ISA don't support 64-bit addressing (e.g., because the OS runs the processor in 32-bit mode, such as Alpha-based systems running Windows NT) and that limitation isn't indicated anywhere (it's not indicated on the

Guy Harris (talk) 20:13, 13 January 2018 (UTC)[reply

]

Discontinued year

Architectures have finite lifespans. Shouldn't this template have a parameter for when an architecture is discontinued? 99Electrons (talk) 01:49, 13 March 2019 (UTC)[reply]

"Discontinued" as in "they stop making processors that implement that architecture", or something else? IA-64/Itanium is "discontinued" in the sense that neither HP{E} nor Intel are planning on doing any more Itanium processors, but I think they're still making them for now.

And should there be predecessors and successors? If, for example, we treat S/360, S/370, S/370-XA, S/370-ESA, S/390, and z/Architecture as separate ISAs, that's the sequence (you can collapse all flavors of S/370 into one, and you still have the sequence), so they have meaningful predecessors and successors. The same applies for POWER, PowerPC, and Power ISA.

Guy Harris (talk) 02:19, 13 March 2019 (UTC)[reply

]

I would say, from an architecture's perspective, it's discontinued when new hardware implementations aren't designed anymore. So in the Itanium case, that would be when Intel announced sometime ago that Poulson would be the last new Itanium processor. I realize that this suggestion could be problematic in regards to the exact criteria an architecture should meet before it's considered to have been discontinued (for example, some might also argue that the existence of a software emulator or simulator for an architecture means that the architecture hasn't "ended"), but I think Wikipedia needs to better contextualize the topics it covers. Being able to mark year an architecture "started" and "ended" is an important improvement, even if it's imperfect.

As for whether the template should list predecessors and successors, doesn't the extensions parameter already provide a similar purpose? For example, the infobox for x86 lists IA-32 and x86-64 as extensions. The S/360 line follows a similar development as x86, as does POWER et al. (mostly, there's some incompatibility between them), so couldn't they use the extensions parameter similarly? 99Electrons (talk) 02:48, 13 March 2019 (UTC)[reply]

"When new hardware designs aren't being made, or won't be made, any more" is as good a criterion as any. Yeah, Unisys is still selling machines that can run Burroughs A-series or Univac 1100/2200 code, but they do it by running a binary-to-binary translator to generate x86-64 code, so I'd count them as having ended.

I guess instruction sets such as Java or CLR bytecode aren't considered "CPU" architectures, as few CPUs implemented Java bytecode and I don't know of any that implement CLR bytecode, so this wouldn't be an issue for them.

I'll open up the predecessors/successors question as a separate item.

Guy Harris (talk) 04:21, 13 March 2019 (UTC)[reply

]

Predecessors/successors to instruction sets?

(As already asked in the previous section, but the discussions should probably be conducted separately.)

Should there be predecessors and successors? If, for example, we treat S/360, S/370, S/370-XA, S/370-ESA, S/390, and z/Architecture as separate ISAs, that's the sequence (you can collapse all flavors of S/370 into one, and you still have the sequence), so they have meaningful predecessors and successors. The same applies for POWER, PowerPC, and Power ISA.

For x86, we have a single x86 page, with an infobox that goes all the way from 16-bit no-MMU x86 to x86-64; there are also pages for 32-bit x86 and 64-bit x86, but they don't have infoboxes of their own.

For S/3x0, we don't have a single page with a single infobox; there are two pages for S/360 (IBM System/360 and IBM System/360 architecture), one page for S/370 (IBM System/370, covering S/370, 370-XA, and ESA/370), one page for S/390 (IBM System/390), and one page for z/Architecture). All but IBM System/360 architecture have infoboxes (IBM System/360 has the infobox). Should there be a single page for all of them, or two pages, one for S/360 (all but one model of which had no memory mapping) and one for S/370-through-z/Architecture (all but the first few S/370 models having memory mapping, with hardware or microcode updates available for the models that didn't have it to start with, other than the Model 195), or separate pages for all of them? (Does 370-XA deserve its own page any more than did the 68020-and-successors? In both cases, the biggest change was arguably "not throwing away the upper 8 bits of addresses" - the 68020 and successors threw away none, 370-XA threw away only one - although the 68020 also added some addressing modes and instructions.)

Should VAX be a successor to the PDP-11? Would Alpha be a successor to the VAX, given the presence of some features in Alpha to support VAX compatibility (e.g., support for PDP-11/VAX floating-point formats), or is Alpha different enough not to be a successor to VAX?

Most of the RISC instruction sets haven't had predecessors or successors - they may have added 64-bit support, but that's mostly just widening the registers and adding 64-bit arithmetic instructions. One exception is ARM, where A64 not only adds more registers (which we don't treat as enough to make x86-64 a separate ISA) but also drops predication - and

has three infoboxes, with the 32-bit instruction sets for Cortex and pre-Cortex having separate infoboxes, and with the 32-bit infoboxes both treating T32 as an extension rather than as a separate ISA.

]

I think there are two issues here: How should the infobox communicate that an architecture has evolved (which is distinct from how it has been extended with optional parts), and how should the infobox facilitate navigation between a set of articles that cover the span of an architecture's evolution. I think it would be better if the infobox didn't describe optional architectural features ambiguously as "extensions". I think something that conveys "optional feature" is better (exactly what term should be used is something I'll leave to someone else to figure out). Doing so separates optional extensions from extensions of the base architecture. For navigating a set of articles covering the extensions of a base architecture, perhaps a collapsible list embedded inside the infobox will be suitable.

I feel that each article about an architecture should have its own infobox, regardless of whether its an extension of an earlier one or not. The infobox should conveniently summarize the architecture described in the article. There should also be just one infobox per an article. I don't think it's helpful to have multiple infoboxes placed throughout an article; doing so defeats the purpose of summarizing the architecture in point-form up-front (beside the lead section). 99Electrons (talk) 00:06, 14 March 2019 (UTC)[reply]

@

Guy Harris

: Your discussion wanders a bit, but I agree that predecessor/successor links would be useful when there are separate articles as in the IBM example. In fact, I just added them to the template! If anyone thinks they belong somewhere else in the box, feel free to move them.

FWIW, PDP-11/VAX is a pretty loose connection, but it could be argued. VAX/Alpha are not linked in any reasonable way, any more than PowerPC is linked to 68k because Apple emulated the latter in software on the former. 209.209.238.189 (talk) 10:58, 29 March 2019 (UTC)[reply]

@Alexander Davronov: you introduced a "date=" parameter, for "Date when the architechture was released".

@Frap: you reverted it, noting that there is already an "introduced=" parameter.

The documentation says that introduced= is "Year introduced".

I don't see a need for both parameters, but is there a need for specifying the introduction point with more precision than a year, e.g. a date, or a season?

If so, the documentation should be updated.

]

@

Guy Harris: Hi. There is certainly a need for date. I'm fine with |introduced=. I don't think that giving a more precise date would harm anyone. Best. AXONOV (talk) ⚑ 07:23, 20 June 2022 (UTC)[reply

]

@

Guy Harris (talk) 07:35, 20 June 2022 (UTC)[reply

]

Control registers

System/360

Designer	Floating point	4× 64-bit

I wanted to edit an infobox in

360/67

only), but the text does not align with that for FPR and GPR. Is there a way to get a left-aligned label of control and to align the text with that of the other register types?

Note: I wanted to wrap the template in {{

]

For what it's worth, the Model 67 flavor of S/360, and S/370 onward, aren't the only instruction sets with

Guy Harris (talk) 09:16, 9 February 2023 (UTC)[reply

]

Absolutely, and that would solve my immediate problem. But should there also be a clean way to include a class of registers that we (TINW) did not anticipate? Maybe |registers1= through 9 for the text and |register-type1=} through 9 for the lable? --Shmuel (Seymour J.) Metz Username:Chatul (talk) 13:18, 9 February 2023 (UTC)[reply]