Wikipedia:Featured article candidates/Central processing unit/archive1

Central processing unit
Peer review

Certainly deserves featured article status - It is well referenced and well written and has had a lot of work put into it. — Wackymacs 12:33, 26 December 2005 (UTC)

=Nichalp  «Talk»=  08:15, 27 December 2005 (UTC)
 * Support since I mostly wrote it and was going to nominate it for FA status pretty soon myself. -- uberpenguin 13:30, 26 December 2005 (UTC)
 * Support Very thorough, stable, well-referenced. AndyZ 14:50, 26 December 2005 (UTC)
 * Support, excellent article. The "See also" section should probably be trimmed of anything already linked in the text, though. &mdash;Kirill Lokshin 18:55, 26 December 2005 (UTC)
 * Support, a comprehensive article on a very important topic. Good footnotes and references. -- King of Hearts | (talk) 05:38, 27 December 2005 (UTC)
 * Support - I agree with all of the above. - Cuivienen 06:32, 27 December 2005 (UTC)
 * Support - Well written, well referanced article. -- ZeWrestler  Talk 19:42, 27 December 2005 (UTC)
 * Object -
 * 1) The article needs a copyedit. Phrases such as in the same vein; regardless of the physical form they take,; ' Here we are discussing devices that conform'' etc. should be rewritten. I suggest you have it copyedited by someone who hasn't worked on the article.
 * You are most welcome to do so. Heaven knows I've asked other people to look over it and they've either okayed my writing or didn't really bother to do serious nitpicking on the writing.  -- 206.148.144.118 22:25, 30 December 2005 (UTC)
 * 1) The lead is loosely written. Its should ease the user into the topic. The second paragraph is the worst culprit.
 * I agree. Please suggest an alternative since I think I've been working on the article too long to write a really solid summary.  I'd much appreciate anybody who could read the article through and suggest some improvements for the intro. -- 206.148.144.118 22:25, 30 December 2005 (UTC)
 * 1) The =history= is long and could definately be summarised
 * Feh... Specific suggestions on what could be taken out without detriment are more appreciated. It was difficult for me to keep the article the length that it currently is; there is a heck of a lot more that could be said about any one of the sections. -- 206.148.144.118 22:25, 30 December 2005 (UTC)
 * Avoid details:  Tube computers like EDVAC tended to average eight hours between failures, whereas relay computers like the (slower, but earlier) Harvard Mark I failed very rarely / While the complexity, size, construction, and general form of CPUs have changed drastically over the past sixty years, it is notable that the basic design and function has not changed much at all. Almost all common CPUs today can be very accurately described as Von Neumann stored-program machines / Thanks to both the increased reliability as well as the dramatically increased speed of the switching elements (which were almost exclusively transistors by this time), CPU clock rates in the tens of megahertz were obtained during this period can be paraphrased.
 * Okay, I'll see if I can trim it down a bit. -- 206.148.144.173 16:16, 31 December 2005 (UTC)
 * 1) Please do not unnecessarily bold text. (WP:MoS)
 * I like bolding keywords. I think it helps to bold terms that will be frequently used later on in the article, and I've seen other articles do the same. -- 206.148.144.118 22:25, 30 December 2005 (UTC)
 * See the Manual of style on where to use bold text. =Nichalp   «Talk»=  05:50, 31 December 2005 (UTC)
 * I looked over the manual of style. It does not explicitly state when NOT to use bolding, only some circumstances where it is advantageous.  It states "Make judicious use of devices such as [...] bolding."  I do not believe that I've been non-judicious with bolding and I have applied a fairly consistant method of doing so.  I really think this is a matter of opinion on both our parts, so until another party or two weighs in here I don't see much reason to change it. -- 206.148.144.173 16:16, 31 December 2005 (UTC)
 * I find the bold keywords useful, but toned down a little, example: "There are four steps...fetch, decode, execute, and writeback." and on the same 'screen': "After the fetch and decode steps, the execute step is performed." - I'm removing the bold on second fetch and decode there. Taking out all the syntax would be detrimental, in my mind. --zippedmartin 01:08, 9 January 2006 (UTC)
 * Fine by me. I think the edits you made were appropriate. -- uberpenguin 16:09, 9 January 2006 (UTC)
 * 1) PNG images should ideally by converted to SVG [suggestion]
 * My graphics editor doesn't do SVG and I loathe most free vector graphics editors. I didn't produce most of the graphics in the article, and really the only one that would benefit from being vectorized is the clock timing diagram. -- 206.148.144.118 22:25, 30 December 2005 (UTC)
 * Diagrams are supposed to be in SVG. I've marked it as a suggestion.
 * For the average end (read: IE) user, SVG is exactly the same as PNG, I don't think this can count as a valid 'objection' as such. If you prefer SVG, feel free to change the pictures, 's a wiki, after all. --zippedmartin 01:08, 9 January 2006 (UTC)
 * I can also provide the diagrams I create in PostScript format since presumably that's an easier route to getting to SVG. -- uberpenguin 16:09, 9 January 2006 (UTC)
 * 1) After an instruction is fetched, the PC is incremented by the length of the instruction word in terms of memory units could be dumbed down. A brief intro on addressing and data can be added.
 * 2) Terms used without a brief description: eg: ALU. A sentence on the ALU is helpful.
 * 3) I suggest you use establised inline references: inote or ref; The current references could be an irritant for those using speech readers.
 * No can do. I'm using ref templates for footnotes.  I had originally used them for references as well, but it totally screwed up the numbering of both.  Someone pointed out this annoyance so I changed the references over to Harvard style.  Note that Harvard style IS an approved method of referencing by WP style guidelines, and until the ref system is improved a bit, I think it's the best way to go. (Some other recent featured articles have been using Harvard as well). -- 206.148.144.118 22:25, 30 December 2005 (UTC)
 * You can manually number them. Use mn and mnb
 * Interesting... I'll play around with this, though again, I feel this is just personal preference since Harvard references are a blessed method by official policy. -- 206.148.144.173 16:16, 31 December 2005 (UTC)
 * You can also check you the new referencing system. Details are on the FAC talk page.
 * 1) In the case of a binary CPU, a bit refers to one significant place in the numbers a CPU deals with . In the current context: Isn't the bit part related to the number of data bits an ALU can process in one clock?
 * No. The sentence as written is correct and exactly what was intended. Perhaps it could be reworded a bit for clarity, though. -- 206.148.144.118 22:25, 30 December 2005 (UTC)
 * 1) Avoid using sub-subsections
 * Is this just a pet peeve or is there a particularly good reason? I certainly didn't go nuts with subheadings, and I've never before seen this made a big deal out of. -- 206.148.144.118 22:25, 30 December 2005 (UTC)
 * Bad style. None of the articles featured in the last 15 months have sub-sub sections. (L3) =Nichalp   «Talk»=  05:50, 31 December 2005 (UTC)
 * I'll try to eliminate them, though I believe they help a great deal with organization. Again I only see this as a matter of personal preference... -- 206.148.144.173 16:16, 31 December 2005 (UTC)
 * I think three or even four levels of heading are perfectly justified in some articles, 's an issue of style again. --zippedmartin 01:08, 9 January 2006 (UTC)
 * 1) =Design and implementation= has a lot of detailed information that needs to be summarised. It should be kept simple,written in simple terms and new terms defined instead of linking.
 * If I define every term that could be, the article would be twice as long and the notes section would be unbearable. If I summarize the whole section it would be ridiculous to even claim that the article is about CPUs.  True, the article is lengthy, but I did my utmost to cover only the most important topics.  In my humble opinion, there is no section in the current article that shouldn't be there in approximately the detail it is.  Of course, nobody has given me very concrete suggestions on this matter yet, so I'm only hearing myself ramble.  Point out some things that you think are covered in too much detail and I'll try to address them; otherwise I'm going to have to disagree that I should turn the detail sections into even broader summaries than they already are. -- 206.148.144.118 22:25, 30 December 2005 (UTC)
 * Don't define every term. Embed the terms to maintain the flow. There'll be a marginal increase, but it won't drastically increase the page size. See how the article on cricket is written.
 * Again, could you give some examples? Cricket is a bit unique in that it involves many terms that are either unique to the sport or see unique usage in the sport; therefore they MUST be defined for comprehension.  IMO, the CPU article doesn't contain too many terms that aren't fairly general computer/digital electronics fare. -- uberpenguin 22:53, 31 December 2005 (UTC)
 * I'm not asking for each and every term to be defined. Just a few key ones. There are other ways to go about it. It needn't be used in the lead (thus leading it to be defined later), or used in such a way that the meaning can be derived from its context.
 * 1) ==External links= should not be fragmented.
 * I'd really prefer to logically separate that section. If there's a style guideline that says something to the effect "don't fragment this section" I'll change it, otherwise I'll respectfully disagree with you and continue to hold that the separation helps. -- 206.148.144.118 22:25, 30 December 2005 (UTC)
 * If you wan't to fragment the external links use the semicolon to create a bold heading.
 * Will do. -- 206.148.144.173 16:16, 31 December 2005 (UTC)
 * 1) I strongly feel that the basic architecture of a CPU must be mentioned before the workings.
 * I strongly feel that using the basic method of a single-cycle CPU as a vehicle to introduce the somewhat complex topic of synchronous digital design is a fairly elegant solution. Showing the reader how a CPU functions first is much more useful than simply stating "a CPU contains these functional units, these control units, and somehow they all magically do something together."  I did this especially because I already dealt with specific implementation over the years a good bit in the history section and a CPU is, after all, a function not a specific implementation. -- 206.148.144.118 22:25, 30 December 2005 (UTC)
 * Almost all books on CPU architecture deal with the architecture before the working. Without mentioning the architecture it will be difficult for a person to visualise the working.
 * I am loathe to point out that this isn't a book on CPU architecture and it doesn't aim to be. As you can see, we already have another editor suggesting that I tone down the technicality, so perhaps using a book on CPU architecture as an example isn't the best idea.  Note that CPU architecture books all focus on modern implementation, which is not what this article is exclusively about. One of the problems with introducing architecture first is that there is a large amount of variation in architecture over the years.  I could work from the standpoint of a concrete example, but this makes the article too specific and reads too much like a book and not an encyclopedia article.  I still maintain that a discussion of the principle operation of a CPU is more useful because a CPU is a functional device, not an implementation.  Others I've talked to agree with  me here, but I'd like to see other editors' opinions. -- 206.148.144.173 16:16, 31 December 2005 (UTC)
 * I disagree, having an article on the CPU without mentioning the basic architecture is is akin to describing how the heart works without describing its physical body. Variation apart, I'm sure you can mention something on the registers, ALU, FPU, cache etc. =Nichalp   «Talk»=  12:58, 1 January 2006 (UTC)
 * This goes on the false assumption that a CPU must have registers, an ALU, FPU, and cache. There are plenty of examples of CPUs that lack one or several of these items.  Stating that a CPU necessarily contains any of these severely limits the scope of the article to microprocessors (in which some of the items you mentioned are more universal).  I think you're coming from the perspective that a CPU is a microprocessor, which is the same perspective that a modern CPU architecture book would address because anybody concerned with modern CPU architecture is going to be looking only at microprocessors.  However, this is NOT an article on microprocessors, it is an article on CPUs, and a CPU is really just an electrical stored program executing device.  -- uberpenguin 14:21, 1 January 2006 (UTC)
 * I may find some stuff later.


 * Object. Needs a good copy-edit. I'll try to lend a hand if I have time. Tony 13:08, 27 December 2005 (UTC)
 * Object. I understood the History section. After that, it got a little fuzzy. -- Mwalcoff 02:13, 28 December 2005 (UTC)
 * What was fuzzy? -- ZeWrestler  Talk 05:43, 28 December 2005 (UTC)
 * Sorry. I meant everything after the history section was too complicated for me. -- Mwalcoff 00:39, 29 December 2005 (UTC)
 * Unfortunately that doesn't help me improve the article. I really did my best to write this so that the lay man can get a basic grasp of the concept.  Note that the later sections are pointedly intended for an audience with a most basic acquaintence with digital computer architecture.  If don't know very basically how computers are organized, it's unlikely that the impact of the later sections will be readily apparent.  Unfortunately, I feel it's quite impossible to write a good summary of CPUs that someone who hasn't the foggiest idea of how a computer works will totally grasp upon first reading.  Therefore the article will probably lose some of its audience towards the implementation sections.  However, these sections will also interest a slightly different group of readers. -- 206.148.144.118 22:25, 30 December 2005 (UTC)
 * Fair enough, but you might want to consider using the prerequisite template found at Make_technical_articles_accessible. -- Mwalcoff 08:27, 31 December 2005 (UTC)
 * Spiffy... Never seen that. I think a "suggested prior reading" would be better, though.  Most of the article can be understood without extensive knowledge of any of the involved topics. -- uberpenguin 22:09, 31 December 2005 (UTC)
 * I added the box at the beginning of the technical sections. Hopefully that helps. -- uberpenguin 22:32, 31 December 2005 (UTC)


 * Comment: The article has been through peer review and several of my own personal requests on its behalf. If you object to its nomination on issues of flow, clarity, or minor copyediting, PLEASE correct things as you see them or at least try to make concrete suggestions.  I've been nearly solely working on the article, so I'd be overjoyed if others helped point out and repair its flaws.  I will, of course, try to fix things as you point them out, but comments indicating that I should summarize what already is an extremely summarized article aren't very helpful. Thanks! -- 206.148.144.118 22:25, 30 December 2005 (UTC)
 * Apologies. All of the previous comments by User:206.148.144.118 and User:206.148.144.173 are mine. I was on a public computer and forgot I wasn't logged in. -- uberpenguin 22:28, 30 December 2005 (UTC)
 * Support. Good work. -- Pamri &bull; Talk 18:02, 2 January 2006 (UTC)
 * Support It's good. Another look over by a non-technical editor would be useful, but I don't believe in 'finished articles'. --zippedmartin 01:08, 9 January 2006 (UTC)
 * Support The CPU is an important part of the computer. Maybe this article can help a couple of computer n00bs learn what it is and how to check it. Captain Jackson 20:55, 9 January 2006 (UTC)
 * Support Object - I feel the discussion of the word size in the Integer precision section needs improvement. For me, the section does not make the connection between how the word size affects the performance and complexity of the microprocessor clear. As I understand it most 8-bit microprocessors would be able to add two 8-bit numbers with a single clock cycle but not two 16-bit or 32-bit numbers. Where as most 32-bit microprocessors would have no problem adding two 32-bit numbers with a single clock cycle. Obviously there is a performance-complexity trade-off, 32-bit processors offer better performance with bigger numbers but require more logic gates to do so. Also important is to consider that there may be tricks to get around these limitations. For example, most 8-bit microprocessors can typically still address more than 8-bits of memory. Nevertheless the rest of the article seems good and I am sorry I didn't get to reviewing this article earlier (I appreciate last minute objections kind of suck). I also realise it's not strictly my area of expertise so I may have made some mistakes in the above explanation. Cedars 03:33, 12 January 2006 (UTC)
 * Your understanding is correct, but your interpretation is slightly off. An 8-bit microprocessor can only deal with 8-bit numbers, true, but that does not in itself affect CPU "performance."  One would use an 8-bit microprocessor in situations where you only need to deal with 8-bit numbers.  If you needed 16-bit or 32-bit numbers on a regular basis, you'd choose a microprocessor accordingly.  This is a price/features tradeoff, not a complexity/performance tradeoff.  The most important thing to get across about integer precision, IMO, is that it determines the range of numbers a CPU can represent.  What you perceive as a performance issue is merely a system design choice, and is appropriate content for a similarly-titled article, or perhaps one on embedded systems.
 * I think you're right that some clarification could be possibly added, but directly addressing what you've brought up would only add unnecessarily to the length of the section. For example, the tricks used to get around integer size limitations are purely software-based, and are thus not appropriate for discussion here (I will, however, add a footnote to the effect, because you're right that's it's important to at least mention that a CPU's integer precision isn't absolute for software).  As for memory addressing, I do hint at paging in the Integer precision section: "many modern designs use much more complex addressing methods like paging in order to locate more memory with the same integer precision." Thanks for the comments, they're never unappreciated! -- uberpenguin 14:00, 12 January 2006 (UTC)
 * I've added some details and a footnote that hopefully address your initial concern. -- uberpenguin 14:13, 12 January 2006 (UTC)
 * Thanks! The revisions make the article much better. I hope its nomination succeeds. Cedars 01:25, 13 January 2006 (UTC)
 * Support: important article with good use of footnotes. -- —Preceding unsigned comment added by Matthew kokai (talk • contribs)