Template talk:Infobox CPU architecture

Bus?

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)

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)

'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)

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)

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)

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)

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)

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)

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)

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)

Logos and images

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)

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

Type

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 IBM System/370 architecture as "Register/Register/Register-Memory/Memory-Memory", presumably meaning "Register-Register/Register-Memory/Memory-Memory", presumably because it supports register-register arithmetic instructions, even though it's not a load/store architecture. In addition, it's presumably "Memory-Memory" because there are decimal arithmetic and character string instructions that take two operands in memory, even though fixed-point binary arithmetic instructions are only register-register or register-memory - unlike, say, the PDP-11 or VAX, which could do memory-memory arithmetic. If the only interesting distinction is between "load-store" and "not load-store", we might want to indicate that. Guy Harris (talk) 01:58, 26 October 2010 (UTC)

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)

Bus widths.

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)

CPU architecture here means instruction set architecture, and they don't have bus widths, as not all implementations of a given architecture have the same type of bus (consider, for example, the 8086 vs. the 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, IBM System/360 was a 32-bit ISA, but only the lower 24 bits of addresses were used, except on the IBM System/360 Model 67, and IBM System/370, when it expanded from 24-bit addressing, only used the lower 31 bits), and some implementations of an ISA might not use all bits of registers in addresses (for example, the Motorola 68000 family was 32-bit, but the Motorola 68000 and Motorola 68010 only used the lower 24 bits of addresses and the 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)

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)

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)

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)

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)

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)

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 DEC Alpha page)? Guy Harris (talk) 20:13, 13 January 2018 (UTC)

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)

"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)

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)

"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)

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 ARM architecture 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.

POWER has a page, separate from PowerPC and Power ISA, with no infobox; PowerPC and Power ISA have separate pages, each with an infobox. Does POWER deserve an infobox? Should there be a page for all three, with a single infobox, even though PowerPC introduced some significant incompatibilities, albeit with the ability to generate code for a common subset (which some compilers supported with an option); should we have the three pages, with PowerPC as the successor to POWER, and with Power ISA as the successor to PowerPC; or should we have a page for PowerPC/Power ISA, with that ISA being the successor to POWER? Guy Harris (talk) 04:38, 13 March 2019 (UTC)

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)

@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)

Year introduced, or something with more precision

@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 (talk) 22:23, 19 June 2022 (UTC)

@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)

@Alexander Davronov: Then, as I said, the documentation for the "introduced" parameter should be changed, to say something such as "When the architecture was introduced" (intentionally vague, so that greater precision is allowed but not required) rather than "Year introduced". Guy Harris (talk) 07:35, 20 June 2022 (UTC)

Control registers

System/360

Designer	IBM
Bits	32-bit
Introduced	April 7, 1964 (1964-04-07)
Design	CISC
Type	Register-Register Register-Memory Memory-Memory
Encoding	Variable (2, 4 or 6 bytes long)
Branching	Condition code, indexing, counting
Endianness	Big
Page size	N/A, except for 360/67
Open	Yes
Registers
16× 32-bit control registers (360/67 only)
General-purpose	16× 32-bit
Floating point	4× 64-bit

I wanted to edit an infobox in IBM System/360 architecture to include the control registers. My first thought was to use |registers=16× 32-bit control registers<br>(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 {{tlx}}, but it did strange things even when I change = and | to {{=}} and {{!}}. Shmuel (Seymour J.) Metz Username:Chatul (talk) 08:28, 9 February 2023 (UTC)

For what it's worth, the Model 67 flavor of S/360, and S/370 onward, aren't the only instruction sets with control registers, so perhaps there should be a "cr" parameter in the template. Guy Harris (talk) 09:16, 9 February 2023 (UTC)

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)

Registers redoux

I propose adding new parameters |reg-typen=, |reg-countn=(|reg-countn=1 should be the default), |reg-widthn=, for n=1-9. These could be used for register types that don't have their own paameters, e.g., access registers, floating point control registers, PSW. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 11:12, 25 June 2024 (UTC)

Sounds good. Guy Harris (talk) 21:11, 27 July 2024 (UTC)