This is the
talk page for discussing improvements to the
Infobox CPU architecture template. |
|
This template does not require a rating on Wikipedia's
content assessment scale. It is of interest to the following WikiProjects: | ||||||||||||||||||
|
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)
"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)
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)
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)
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)
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)
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)
(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)
@ 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)
|introduced=
. I don't think that giving a more precise date would harm anyone. Best.
AXONOV
(talk)
⚑
07:23, 20 June 2022 (UTC)
Designer | IBM |
---|---|
Bits | 32-bit |
Introduced | April 7, 1964 |
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
, 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?
<br>
(
360/67 only)
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)
|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)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)
This is the
talk page for discussing improvements to the
Infobox CPU architecture template. |
|
This template does not require a rating on Wikipedia's
content assessment scale. It is of interest to the following WikiProjects: | ||||||||||||||||||
|
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)
"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)
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)
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)
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)
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)
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)
(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)
@ 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)
|introduced=
. I don't think that giving a more precise date would harm anyone. Best.
AXONOV
(talk)
⚑
07:23, 20 June 2022 (UTC)
Designer | IBM |
---|---|
Bits | 32-bit |
Introduced | April 7, 1964 |
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
, 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?
<br>
(
360/67 only)
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)
|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)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)