Talk:X86

Navigation

Could there be a more obvious way to direct readers to X86 assembly language than the mention in the "See also" section? Maybe something in italics at the top a la disambiguation? — Preceding unsigned comment added by Johnruble (talk • contribs) 10:35, November 2, 2006 (UTC)

 DoneI added a " see also" tag .Bettering the Wiki (talk) 13:40, 21 August 2008 (UTC)

Another Point...

I'm not sure if this has been mentioned already but Intel has also developed and released 64-bit Xeon and Pentium 4 and Pentium D (Dual-Core) processors. The technology is known as EM64T (extended memory sixty-four technology).

While the following external links were removed as part of a responsible-looking edit, the IP editor made no comment to indicate they harmed the article.

[1], [2], [3]

--Jerzy(t) 16:04, 2004 Mar 14 (UTC)

Why are IA-32 and x86 separate articles? --Damian Yerrick 14:27, 2 Apr 2004 (UTC)

IA-32 is Intel's 32-bit instruction set, whereas x86 broadly refers to a range of Intel processors (and their instruction sets, some of which predate IA-32). The two terms do overlap to a degree, but they're not synonyms. A 80286 is an x86 processor that does not support IA-32.

Perhaps better phrased as "a range of Intel, AMD, and other processors (and their instruction sets...)". Guy Harris 00:00, 13 January 2006 (UTC)

Revamping X86 and IA-32 articles

I plan on making some major changes to the contents of both the X86 and the IA-32 articles, to eliminate most of the overlap between them. I plan to make X86 the general overview of the architecture, with shorter technical descriptions, and more historical descriptives. For technical info, I will let the X86 link to the IA-32 (and also other articles) for more details. I will make IA-32 the more technical-oriented article, at least for the 32-bit side of this architecture. I will also let the X86 make links to the AMD64 article for the 64-bit technical details of this architecture.

--ykhan 05:29, 2004 May 3 (UTC)

The descriptions would benefit by being consistently in present-tense except where events are referred to. Where obsolete programming models are described, the description should still be in the present tense, with the context set in the opening paragraph. It's more tiring to read with the inconsistent style of description. For example,

Intel 8086 and 8088 had 14 16-bit registers. Four of them (AX, BX, CX, DX) were general purpose (although each had also an additional purpose; for example only CX can be used as a counter with the loop instruction). Each could be accessed as two separate bytes (thus BX's high byte can be accessed as BH and low byte as BL).

becomes

Intel 8086 and 8088 have 14 16-bit registers. Four of them (AX, BX, CX, DX) are general purpose (although each has an additional purpose; for example only CX can be used as a counter with the loop instruction). Each can be accessed as two separate bytes (thus BX's high byte can be accessed as BH and low byte as BL).

-- Shay

Done the revamping for you. Overlapping info merged and removed. However I made IA-32 focus on the name and succeeding architectures, with x86 containing the descriptions whilst not being too detailed and technical. Da rulz07 (talk) 02:14, 5 December 2007 (UTC)

Title

{wrongtitle|title=x86}

Wikipedia:Naming conventions (technical restrictions) says "A workaround for this issue is to insert a unicode word joiner at the start of the name. This can be done by entering ⁠ in the move page box." Does anyone want to try this? Rd232 18:05, 29 July 2005 (UTC)

80286 Real/Protected

The 80286 had a problem that once it was switched into Protected Mode, only a Reset could change it back to Real Mode. The IBM-AT architecture had some way where software could force a reset to flip it back (a reset is really just another interrupt), but it was time consuming. That's what OS-2 tried to do.

It really wasn't until the 80386 came out that it was possible to have an operating system that could have some "back-compatible" mode for older real-mode programs in a reasonable, efficient way.

Swirsky 06:40, 6 Jun 2005 (UTC)

Need to point out the data-bus is 16-bit, while the address bus is 20-bit.

Why remove FOLDOC?

While i feel the burden of explaining should lie on Stan Shebs, I'll avoid conflict before reverting again and explain:

According to the history section of this article, the original FOLDOC statement was introduced by Uriyan 23:07, 4 Jul 2002, and stated:

This article (or an earlier version of it) contains material from FOLDOC, used with permission.

It did not state what is currently the statement implied by {{FOLDOC}}:

This article was originally based on material from the Free On-line Dictionary of Computing and is used with permission under the GFDL.

Nor could it, because the original version is not equal nor very close to the very short

http://web.archive.org/web/20020906172641/http://foldoc.doc.ic.ac.uk/foldoc/foldoc.cgi?x86

1999-2002 FOLDOC entry.

This article may very well have used some of the info found in the 17 words of the 1999-2002 version, or the 43 words found in the current version, but that does not merit a statement in the article space. Anyone curious about who has contributed to the article will find FOLDOC mentioned among all the other contributors in the article history (in the summaries) and now also here.

Even though this BBC article would inspire me to write an entry on Lord Bell, noting that he works for Mark Thatcher, I would not conclude the article with a statement like "This article has used information found in BBC news". Should you (Stan) still have the desire to revert my change, then please discuss it here first.--Dittaeva 16:24, 26 Aug 2004 (UTC)

You have to attribute the source even if you only copied three words; the license doesn't say "only attribute if you feel it's merited". Not only is it dishonest to remove attribution, but Wikipedia could be sanctioned for violating the license. Another bad thing is that by introducing a fuzzy "does not merit" argument, you open it up to other people to say for other articles, "well, we're only using one sentence", or "I copyedited, lots of words are different now". The only way the FOLDOC cite could legally go away is if you rewrote from scratch, leaving out FOLDOC's sentences. This is different from using a source for facts, because facts aren't copyrightable, although of course it's expected of you that you Wikipedia:Cite sources anyway, and too few WP articles do that. Anyway, if you don't like my reasoning, try your argument out on the village pump; but be aware that there are some pretty hardnosed people when it comes to copyright, I'm laidback about it compared to them. Stan 17:20, 26 Aug 2004 (UTC)

But which "FOLDOC's sentences" or "three words" do you mean? Have you actually looked at the links I supplied? If you compare the first WP version and the FOLDOC version, not even two words are connected the same way in the two versions, and the only mutually used words are: "a", "Intel", "AMD" and "of". Does that really constitute "originally based on material from the Free On-line Dictionary of Computing"? I do not mind FOLDOC being referenced with a link (and a reference header), but the license does not require us to put in a line of its own in the article-space for every source or contributor to the article.--Dittaeva 22:52, 26 Aug 2004 (UTC)

OK, you're right; I had the impression that some of the wording had survived. It looks like former editor Uriyan added the notation in July 2002, perhaps because he cut-n-pasted the "80186, 80286, ..." list from the FOLDOC entry and was being scrupulous. But that bit has been altered completely, so there's no vestige of FOLDOC-ness left. On the plus side, article history shows I wasn't the only one to want the attribution back, so now we have this little discussion as a warning note for the future. :-) Sorry to suck up your time on this! Stan 23:34, 26 Aug 2004 (UTC)

x86 licensing?

Anyone have info on if the x86 architecture is patented, and has to (or used to be) licenced by Intel or something? Googling around for a minute didn't turn up anything good for me to add to the article, perhaps I'll dig into it some other time if no one has info right at the top of their brain :) --Fxer 17:54, July 12, 2005 (UTC)

According to Mike Myers 'Comp TIA A+ Certification Exam Guide, 6th edition', pg. 70 "chipmakers have a habit of exchanging technologies through cross-licensing agreements ... In 1976, AMD and Intel signed signed such an agreement, giving AMD the right to copy certain types of CPUs". The article goes on to explain how Intel regretted this decision by the early 80's, and after much legal squabbling the agreement was mutually absolved January 1995. Since, AMD and Intel chips are no longer interchangeable.

Take that for what its worth.

199.80.154.46 18:16, 19 October 2007 (UTC)

AMD 'clones'

I think that the phrase 'clones' is used incorrectly, as over the past few years AMD has created many propriety extensions to x86, to the point where AMD no longer 'clone' the chips. Also Intels version of AMD's 64-bit extensions is EMT64.

I too think that the word 'clone' is wrong in most uses. AMD originally had a license to produce x86 CPUs from Intel. This dated back to the days when no system manufacturer would consider designing in a chip that didn't have a "second source". Intel reneged on the license, fought a long court battle, and settled, leaving AMD with a complicated set of rights, not including full rights to future Intel chip design. So AMD x86 chips up to and including the 386 were essentially the same designs as Intel's (even so, I would not call them clones). I don't remember what AMD had for the 486. Everything else was an independent design to the defacto standard x86 architecture.

Harris Semiconductors also had licenses from Intel to produce 286 CPU chips (and maybe earlier x86 chips).

NEC V20 and V30 chips implemented the 8080 and 8186 architecture. I have no idea about the legal arrangements.

As far as I know, all other manufacturers' implementations of x86 architecture were independant designs. Again, I would not call them clones.

Note that IBM x86 chips were designed by Cyrix (and Cyrix chips were manufactured by IBM mostly) so those two are essentially the same.

The point of this is that the word 'clone' seems to reflect a POV.

DHR 22:43, 14 January 2007 (UTC)

This is not a POV issue, the word 'clone' was a widely-recognized term for these systems (even if it's relatively obsolete in today's industry), see the hacker Jargon File:

[obs] PC clone: a PC-BUS/ISA/EISA/PCI-compatible 80x86-based microcomputer (this use is sometimes spelled klone or PClone). These invariably have much more bang for the buck than the IBM archetypes they resemble. This term fell out of use in the 1990s; the class of machines it describes are now simply PCs or Intel machines.

radimvice 23:59, 20 April 2007 (UTC)

In this context, "clone" is not referring to IBM-PC-compatible systems, it's referring to the chips produced by AMD, so it's not being used to refer to "these systems", as it's not referring to complete computer systems at all. As noted, the original AMD x86 chips were made under license, so I'm not sure "clone" is appropriate for those. And, as noted, AMD have made their own instruction set and other feature additions (including 3DNow! and 64-bit support), and processors with those are arguably a bit more than just "clones". Guy Harris 00:13, 21 April 2007 (UTC)

real mode addressing 'modes'

I don't think it's accurate to refer to near and far as addressing 'modes'. They are not modes. In fact every memory access uses both a segment and offset. The only difference is that sometimes the segment is not explicitly specified.

The terms near and far are used to describe pointers in software. Do you store only the offset (near) or both segment and offset (far)? The distinction has nothing to do with the CPU addressing hardware.

--ScottJ 17:50, August 10, 2005 (UTC)

Prospects for the x86

Okay,

I’m getting really, really tired of you reverting stuff which I removed under, what I believe are valid arguments. If you do so, you should provide solid sustainable counter arguments. Unfortunately, you don’t even try to do that. Three examples:

• Your C# addition to the continuations article: you add it back by arguing that I should quote the C# spec on saying that it’s not a continuation. This is complete non-sense: 99.99 percent of specs of programming languages don’t say what a certain construct is not. They don’t do this, as it bloats the spec and as implementers of the spec are not interested in what a certain construct doesn’t do.
• Your Microsoft addition to the Itanium and x86 page: You add it back under the cover of saying that Microsoft is big player. But, as I already mentioned Microsoft isn’t a big player on the high-end server market, which is the market the IA-64 architecture is aimed at. Moreover, it can also be argued that Microsoft is doing a very clever thing: They’re targeting their version of Windows for high-end servers at some the core application areas. Hence, it might just be the case that they want to gain experience in these areas before they start supporting other applications on these high-end servers.
• You added back the "Prospects for the x86" section to the x86 article, but up until now you haven't come up with any arguments on why this doesn't violate the wiki policy of not being a crystal ball. Moreover, you completely ignore any application areas for which the x86 architetcure is completely unsuitable (do I hear high-end server market?).

Anyway, I beg you to provide solid arguments before you add something back of which you might suspect that the person who removed it had very good reasons for doing so.

-- Koffieyahoo 07:55, 7 September 2005 (UTC)

I can appreciate your tiredness and frustration. The Wikipedia process is hard work!

• The net result of the process in the article on continuation was that (as you suggested) the example of delegates in C# was removed.
• Attempting to suppress information from the Wikipedia article Itanium based on Microsoft conspiracy theories is misguided.
• Attempting to suppress analysis in the Wikipedia article x86 on the false charge that it is "crystal ball" is similarly misguided.

--Carl Hewitt 16:25, 7 September 2005 (UTC)

In Wikipedia:What_Wikipedia_is_not#Wikipedia_is_not_a_crystal_ball, it states:

The above prohibitions are not intended to suppress discussion of current trends and tendencies and how they may affect future events. In particular the Wikipedia allows discussion about the arguments for and against whether developments and proposals will be successful provided that they are well grounded and sourced.

However the above statement is new and so it may be controversial.--Carl Hewitt 21:30, 9 September 2005 (UTC)

In Wikipedia talk:What Wikipedia is not the above statement has been amended to:

"It is appropriate to report discussion and arguments about the prospects for success of future proposals and projects or whether some development will occur, provided that discussion is properly referenced. It is not appropriate for an editor to insert their own opinions or analysis, because of Wikipedia's prohibition on original research."

--Carl Hewitt 03:44, 10 September 2005 (UTC)

In that case, please explain why your statements are not original research. That is, cite a relevant source (I don't believe one exists). -- Koffieyahoo 14:51, 12 September 2005 (UTC)

The article cites sources. Which statements do you think need sourcing? Thanks.--Carl Hewitt 16:57, 12 September 2005 (UTC)

Okay, to name a few:

• "The displaced architectures include Lisp machines, Japanese Fifth Generation, Reduced Instruction Set, and supercomputers processors."

PowerPCs and SPARCs have a RISC architecture, both are still sold on large quantities, this is even more justified by the Xbox 360

Supercomputers are rediculously expensive, so not many of them are sold, but they 'are' still sold.

Fith Generation computers were never sold in large quantities as far as I know, so I don't think you can claim that x86s replaced them. Please provide a source if you think I'm wrong.

• "Strong competition between Intel and AMD, coupled with the continuous progress predicted by Moore's law suggests that innovations will continue at a steady pace."

Please provide a source that claims this, otherwise I must consider it original research

• "Considering the enormous (and increasing) research and capital costs incurred in the development and production of a modern processor"

Please provide a source which shows such figures.

• "the x86 architecture is likely to continue replacing specialized processors in a number of markets."

Given especially my remarks regarding other architectures I don't think this claim can be maintained. If you think it can be please provide sources. Moreover, what are specialized processors. I mean I don't see any x86 processors in phones, PDAs, etc.

• Itanium paragraph

Except for the first sentence I think this belongs in one of the Itanium related articles, not here.

Koffieyahoo 12:43, 3 January 2006 (UTC)

Image

There is a request for an image here, is there a particular qualifier for this? Are we looking for a newer AMD K6-2 processor? An older 286? Or even older 8086? If we're just looking for any random processor, or a series of different ones, that can be easily arranged. Janizary 04:10, 2 March 2006 (UTC)

AMD64 vs. EM64T vs. x86-64 vs x64

I would like to say that to say that Intel and Microsoft refer to AMDs 64bit CPU's different would be false. The words are use interchangable on both the MS and Intel sites. Furthermore x64 is used over whelmingly by almost of all member of varius technical communities. Please do not destinguish who uses these words because it is extremly hard to proove. —This unsigned comment was added by 66.72.205.197 (talk • contribs) 13:56, 22 March 2006 (UTC).

Intel presumably refers to AMD's 64-bit CPUs as "Athlon 64", "Opteron", etc.. That's not what "x64" refers to, however; it refers to the instruction set architecture. AMD calls that instruction set AMD64, Intel calls it EM64T, and Microsoft uses x64 in the names of its OSes for AMD64/EM64T. I see no sign that "x64 is used over whelmingly by almost of all member of varius technical communities". Guy Harris 21:57, 22 March 2006 (UTC)

80186 cores and "extended mode"

I have read about an "extended mode" on 80186 cores being sold today, where the segments are expanded to handle 24-bit addressing by making segments 256 bytes in size instead of 16. Perhaps some research should be done on this new mode's specifics and the relevant information added to this page. I don't know enough about it to do so, however. Daivox 22:05 UTC 23-Mar-2006

List of 80x86 generations

• 8086, initial/first generation - first member is Intel 8086 (and derivates), later multiple clones appeared.
• 80186, first generation update - first member is Intel 80186 (and derivates), later multiple clones appeared.
• 80286, second generation - first member is Intel 80286, later multiple clones appeared.
• 80386, third generation - first member is Intel 80386 (and derivates), later multiple clones appeared.
• 80486, fourth generation - first member is Intel 80486 (and derivates), later multiple clones appeared
• 80586, fifth generation - first member is Pentium (and derivates), later appeared Nx586, 5x86, 5k86, WinChip, mP6
• 80686, sixth generation - first member is Pentium Pro (and derivates, incl. Pentium M and Core), later appeared 6x86, K6, C3, Crusoe
• 80786, seventh generation - first member is Athlon (and derivates), later appeared Pentium 4 (and derivates), C7, Efficeon
• 80886, eighth generation - first member is Opteron (and derivates, incl. Athlon 64), later appeared Core 2 (and derivates)

the 80..86 links are redirecting to the article of the first member of the generation in question. But maybe we should make some disambiguation-like "generation articles" (similar to the "Xth gen. competitors" section in current articles like Pentium, Pentium Pro, Athlon, Opteron) - this way we could list also 8086/186/286/286/386/486 clones there. Alinor 20:07, 10 September 2006 (UTC)

What exactly defines a "generation"?

Are we talking generations of the instruction set architecture (which is what this page is about), in which case there are both obvious major updates (80286, adding a full-blown MMU; 80386, adding the 32-bit architecture; AMD64, adding the 64-bit processor), major add-ons (MMX, 3DNow!, SSE, SSE2, etc.), and minor updates (80186?, Pentium, P6, probably others along the way)? If so, then the "Design" section of this page already covers that.

Or are we talking about processor design updates, in which case there are sometimes instruction set updates associated with them and sometimes not, so it's not clear it belongs on this page, and it's not clear that AMD and Intel generations are obviously coupled, so perhaps there should be separate generation lists?

Given that the 80186 was a different physical architecture (with microcoded intructions replaced by silicon), had a different package, extra instructions, and ran (at least) two times faster at the same clock speed than it's predecessor, it qualifies as a seperate generation if pentium/pentium pro qualifies. (And you can see from the name that Intel thought it was a seperate generation).

Unless you are using the fact that IBM only ever made an 8088 generation PC and an 80286 Generation PC to define generations.

On the other hand, if the only difference is processor mode (Real Mode, Protected Mode, and Virtual mode), then there has only ever been three generations: 8086, 80286, 80386.

You forgot Poland^Wx86-64. :-)

Architecturally, yes, there are four generations of instruction set architecture, as indicated (at least if you ignore minor updates and the MMX/3DNow!/SSE updates), and multiple generations of processor design updates, which would include the 186 as a separate generation. Guy Harris 08:06, 1 November 2006 (UTC)

We should certainly separate instruction sets from particular implementations, it could probably make sense to define processor "generations" for instruction sets (like compilers do). However, it becomes rather silly, trying to do the same thing with implementations (unless employing a strictly chronological approach). Problems arises not only with Intel Core or Centaurs WinChip, which couldn't be put into any generation without severe logical contradictions, but with many other designs as well.

The only fair thing to do is to discuss (and/or classify) the individual physical processors real technical aspects and properties, such as, whether or not they have address-calculation in hardware (80186,..), protected mode (80286,..), 32-bit registers (80386,..), are tighly pipelined (i486,WinChip), superscalar (Pentium,..), speculative with register renaming (6x86,..), micro-op translation (K5,Nx586,PPro,..), very deep pipeline (P4), etc etc. Of course, whether this article is the right spot for such technical elaborations is another question. /HenkeB 17:03, 23 March 2007 (UTC)

...much criticized stopgap concept of segment registers...

Segment Registers were, and are, an architecture for separating out the code and the data. See Data Execution Prevention for the current implementation. Using a segmented architecture prevents buffer overrun exploits. (Actually, in the context of the times, buffer overrun system crashes were an equal problem). Segment Registers were later criticized by one particular important sub-group (unix/c programmers) but you can't call them a 'stopgap concept' - that's just wrong. 218.214.148.10 08:24, 1 November 2006 (UTC)

Segmented architecture is, in general, what you describe, and in fact the x86 protected-mode segmented architecture can achieve separation and protection. However, the 20-bit real-mode x86 implementation (which is what the article is calling "much criticized stopgap") was not designed for such a thing. Not only is there no provision to mark certain segments as read-only or no-execute, but two different combinations of segment:offset addressing could point at the same byte in memory, subverting any attempt at separation and protection. The 20-bit segmentation was almost certainly introduced to increase the addressable memory, and not for any sort of protection. AcidPenguin9873 21:45, 1 November 2006 (UTC)

That is a common point of view, but one not supported by by my experience at the time, nor by the literature that I have retained. This from an Intel programmers reference: "Generally, the most powerful microprocessors are the ones with the widest variety of addressing modes available" ... "The memory segmentation scheme is optimised for the reference needs of computer programs, and is separate from the operand addressing structure. | The structure for addressing operands whithin segments directly supports the various data types found in high level programming languages." ... "The iAPX microporcessor family with its memory segmentation scheme is designed for modular programs."

As you can see, the ability to use 20 bit addresses is not what Intel was proud of, nor was it what they thought users were looking for. In fact, their user community was happy with 16 bit addressing for some years after the 8086 was introduced: their next generation chip, the 80186, did not make any signifigant changes to addressing.

What I do remember from the time is that the problems of stack, program, and data co-location were well known, and the mini-computer operating systems which did not use a segmented memory architecture were widely regarded as toys. In this context, the Intel claims make sense: they designed a memory architecture that supported segmentation, just like on a real computer. 218.214.18.240 04:56, 8 July 2007 (UTC)

Generations

Hi, how were those x86-Generations established? Does anybody have a Source on this? They just seem strange to me... --Pentiumforever 21:00, 3 January 2007 (UTC)

NPOV edits by 80.92.248.145

It seems to me the edits by 80.92.248.145 on the 17th of december are more than a little laden with negative value (see diff). Please advise. —The preceding unsigned comment was added by 193.50.44.5 (talk • contribs) 13:00, January 10, 2007 (UTC)

I would agree that those changes present a strong POV, and I can't see that they add anything much to the article. — Aluvus ^t/c 18:50, 10 January 2007 (UTC)

SI vs Binary??

I think that there should be more consistency in the use of SI or Binary prefix notation, one or the other should be used. I think that when they are both it causes confusion eg does that 64KB mean 64*2^10 or 64*10^3? I feel that if (K|M|G|...)B is used exclusively, it will likely be assumed that powers of 2 are being used, when both are used some confusion will occur about values in the "SI" format. Busfault 02:40, 4 February 2007 (UTC)

Real mode 4 bit shift?

In real mode, memory access is segmented. This is done by shifting the segment address left by 4 bits and adding an offset in order to receive a final 20-bit address. [...] In this scheme, two different segment/offset pairs can point at a single absolute location. Why did the designers decide to use this rather complicated approach of generating absolute addresses? I guess it can cause problems when accidentally accessing / writing to addresses that are already used by something else. --Abdull 09:45, 11 March 2007 (UTC)

Yes it might seem odd, but basically it simplifies software development. Imagine a segment as a window onto a painting. Having overlapping "segments" means you can place the window anywhere you please on the picture, whereas with non-overlapping segments no two "windows" can show the same parts of the larger painting. In other words, Intel's method give developers more freedom when working with memory, at the cost that two segments can overlap.--Anss123 18:37, 21 April 2007 (UTC)

Could you give a more concrete example where such a thing might actually be useful?

In my experience, programmers vastly prefer "flat" addresses, saying it simplifies software development and gives them more freedom, over x86-style "shift segment address left 4 bits and add an offset" "segmented" addresses. (Although they may admit that x86 "segments" are not quite as bad as bank switching). --68.0.124.33 (talk) 03:54, 3 March 2008 (UTC)

Well, it's better than bank switching for sure and as long as you do not need more than 64KB of continuous memory it's not worse than a flat address space either. OS researchers like segmented architectures for their flexibility. For applications you can use them to bounds check a memory area, which is usefull for preventing illigal pointers and buffer overflows.

The parent question wondered why Intel’s segmentation scheme allowed overlapping addresses. That’s what I was referring too with it makes software development easier, if you compare with a flat address space segments still have merit - assuming your application lends itself to be segmented up, but few will choose Intel’s 20-bit segmentation scheme over a flat 32-bit one regardless.

--Anss123 (talk) 12:07, 3 March 2008 (UTC)

Barbarism

I have re-added in the reference to the word 'Pentium' being a barbarism, and added a reference to a discussion on the subject. It was evidently removed by a techie who does not appreciate that the naming of processors, and the origins of those names, is extremely important to people involved in sales and marketing (not to mention those involved in language research, but I'm not one of those).

If anyone still has a problem with this reference, please discuss it here rather than unilaterally deciding that it is not appropriate content for this article.DanMatthewsUK 13:30, 2 May 2007 (UTC)

Fair enough, but new discussion should go at the bottom.--Anss123 14:57, 2 May 2007 (UTC)

oops :)DanMatthewsUK 13:27, 3 May 2007 (UTC)

I removed it. The reason is that this factoid belongs in Pentium, not here. Ham Pastrami 21:06, 11 July 2007 (UTC)

Merge proposal with x86 assembly language

I know this is likely to be somewhat controversial, but it is my sincere opinion that "architecture" and "assembly language" are really quite inseparable in the context of an encyclopedic article. The only real difference IMO is between the hardware and software representation of the same concepts. Full instruction set references, either in the form of hardware or assembly language, are not encyclopedic content, it is a technical manual that is better left to external sources or Wikibooks. Currently the content of these two articles are almost entirely overlapping. Ham Pastrami 13:21, 14 July 2007 (UTC)

"I believe, however, that x86 architecture and x86 assembly are legitimately different to under alternate headings. Indeed, they both relate to each other in the fact that they are x86, but the assembly language for the x86 architecture can be classified separately in that it is an represents so much more information regarding an assembly language of x86 architecture type. Simply, the assembly language is applied according to the architecture and it :is related more than it is a part-of. It would also be useful not to bulk together related items but have more modular pages with links to related fields." - Ross R. Australia.

I to agree that this should not be merged, as one is a concept of hardware design, and the other is a concept of theory application. The concept of hardware registers is different than the concept of chipset connections. It's almost a matter of letting the "editors" decide, however in Wikipedia WE are the editors, so it is my vote that we not merge the sections -- Cole Brand email to for further questions zib.nalot ta eloc 129.7.110.55 22:41, 28 August 2007 (UTC)

Whilst I appreciate where you are coming from in the idea for the merge, merging both articles would make the resulting article extremely long and cluttered. Perhaps just keep it like it is but add a very brief summary section in the architecture article with one of those links to main article. Therefore, my vote is not to merge. Changed my mind. After reading some of the other articles in detail, there is lots of duplicated content. Already started merging info. Da rulz07 07:28, 17 October 2007 (UTC)

I think what can be taken from the suggestion is that the articles should be condensed to have less overlapping information and that each section should focus more directly on what they should be, respectively. I'll agree is is a little odd and difficult to differentiate between the history of a language (encyclopedia worthy) and the language itself (an external reference manual). Also notable, the current Wikibook on the subject is quite poorly written for practical use and really needs an expert as suggested, but I added an external link to an EXCELLENT guide, despite being a bit old, for the early x86 processors. 199.80.154.46 18:25, 19 October 2007 (UTC)

x87

Apparently the x87 instruction set was integrated into the x86 chips; this is not explained in the article. -- Beland 14:00, 24 July 2007 (UTC)

amd k10 is the first 9th generation x86 processor to reach the market in the form of opteron barcelona core. since no desktop product have yet reach the market and intel have not introduced equivalents as of now we shouldn't add it to the chart. however amd k10 is definitely not an 8th generation cpu. —Preceding unsigned comment added by 160.94.27.159 (talk) 22:38, 25 October 2007 (UTC)

Still ,its not clear at all now whether a CPU that claims to be "x86 compatible" should per-definition support a floating point instruction set extension. Can a CPU claim to be "x86 compatible" while NOT incorporating a floating point processor? Mahjongg (talk) 12:54, 21 August 2008 (UTC)

Address spaces...

In the table it lists CPU addressing. I'm afraid that this is quite inaccurate, what that is actually listing is the register size. Addressing is quiet different. The 8088/86 is actually 20bit addressing. (which gets you up to 1MB of memory instead of just 64KB! quite useful to have an address space larger than your registers but needs segments...) The 286 is 24bit addressing. 32bit for the 386, 486 and pentium. 36bit for the pentium pro , pentium ii and pentium iii and pentium 4 48 bit addressing for the Athlon 64. —Preceding unsigned comment added by Mornnb (talk • contribs) 13:12, 20 November 2007 (UTC)

True of the physical address space. Not true of the logical/virtual address space. For a lot of programming, the logical/virtual address space matters more than the physical address space. It should perhaps give both the "flat" and segmented address sizes, rather than just the flat address sizes, but, other than that, the sizes are correct. Guy Harris (talk) 19:16, 20 November 2007 (UTC)

Disambiguation of binary prefix

I just added a couple of footnotes to explain the binary meaning of MB, GB etc. I then noticed that the binary forms GiB, TiB are used explicitly later on in the article. I think it would be better to choose between the two disambiguation styles and then apply it consistently. Are there any views on which of the two styles is preferred? Thunderbird2 (talk) 11:42, 20 April 2008 (UTC)

There isn't a lot of guidance in WP:MOSNUM#Binary prefixes, but consistency is definitely preferred. My personal preference is for GiB, etc., on the basis that a) given the article content, we can reasonably assume a fairly technical readership; and b) if we find that we need footnotes to clarify a term, that's a good indication that we ought to use a more clear term. Jakew (talk) 12:01, 20 April 2008 (UTC)

Hey that was quick :) It's true there's not much guidance from MOSNUM, but that's not for lack of trying. There's been a huge amount of debate there recently, but little consensus (yet). If the x86 readers will understand GiB (or at least take the trouble to read gibibyte) it would certainly read better without the footnotes. Thunderbird2 (talk) 12:07, 20 April 2008 (UTC)

Oh my, I had no idea that this subject was so sensitive! Can I propose waiting for a few days, to see what other editors think? Jakew (talk) 12:24, 20 April 2008 (UTC)

Sensitive? Some people have it has their religion. Soon they'll be demanding tax deduction.--Anss123 (talk) 12:29, 20 April 2008 (UTC)

It depends on what the sources use. At the moment it looks like the sources mostly use GB, so using GiB in the article would make it inconsistent with those sources. Fnagaton 14:01, 20 April 2008 (UTC)

I reckon the professional and academic literature is tending more and more to use IEC prefixes, which I feel should be preferred for this article. Here are some examples

• Buntinas et al
• Eeckhout et al
• Ganssle & Barr
• Georges et al
• Kuszmaul
• Rauch

Thunderbird2 (talk) 21:00, 20 April 2008 (UTC)

Which of those sources are used by this article though? This source, cited by the article, uses GB. Fnagaton 21:16, 20 April 2008 (UTC)

What if some sources use GB and others use GiB? It seems to me that the result would be rather confusing. To my mind, except for direct quotes, it makes sense to standardise on one or the other. Jakew (talk) 21:22, 20 April 2008 (UTC)

Which sources used by the article use GiB? Fnagaton 21:24, 20 April 2008 (UTC)

What matters is the reliable literature aimed at this level of readership. Just one or two more ...

• Chanet et al
• Coutinho et al
• Desnoyers & Dagenais
• Engel & Mertens
• Ericsson
• Gara et al
• Gleixner et al
• Heimpold & Baumgartl
• Heirman et al
• Heander & Malmborn
• Moreira et al
• Parthey & Baumgartl

Thunderbird2 (talk) 21:41, 20 April 2008 (UTC)

• All: One’s sources is only part of the equation. Often the source you are quoting helps to discern who your target readership is. I would suggest that the true test of the wise thing to do here is to decide whether this article is truly directed primarily to an expert audience, such as professional software developers, or is really directed to a general-interest readership. Who is the audience? Does this article seem like it would most likely belong to part of a registered-membership Web site for software developers (?) or does this article look more like the sort of thing you would read in an in-depth article in PC World? If the latter, what unit symbols would PC World use and how would they disambiguate (if at all)? Wikipedia’s mission is to communicate with minimal confusion so that readers can learn about a subject and are primed as well as possible to learn even more in their studies elsewhere. I don’t profess to know the answer to who the readership truly is in this case; it seems, however, to be a general-interest readership to me though. Greg L (talk) 21:46, 20 April 2008 (UTC)

• Yes, that's a good point. Looking through the article I think anyone capable of reading and understanding it would probably already be familiar with MiB, and if not, he (I hope that's not considered sexist - it's unlikely to be a she) could easily lap up the concept in between bites of shreddies for breakfast. Thunderbird2 (talk) 21:57, 20 April 2008 (UTC)

• T-bird, I agree that this article quite arguably enjoys a relatively pro audience that can swallow and digest “GiB”. Accordingly, I see no reason to take a stand of any sort on this one as it is quite fairly a judgment call. Having stipulated that a pro audience can “swallow and digest” the unit, is a separate issue from whether it is most wise to feed it to them; clearly, a pro audience would also have reciprocal-infinity trouble with “A 32-bit address space would allow the processor to directly address only 4 GB of data.” The advantage of this wording, of course, is it is all the more accessible to a less knowledgeable readership. In the final analysis, I would argue the real test here is a tradeoff on Wikipedia’s fundamental mission, which is: A) so that readers can learn about a subject and B) are primed as well as possible to learn even more in their studies elsewhere. In other words, will a reader who has learned a great deal in this article, later encounter “GiB” most often in his studies elsewhere on this subject? If so, use of GiB is good. Quite good. But the second, “B” consideration must be weighed against the possible confusion with the “A”-side of the equation: looking out for relatively novice readers trying to make heads or tails of this complex topic. I don’t know the answers to any of this as the true answer relies entirely upon fact: what sort of articles for further reading are really likely to be encountered and what units do they use? I do however, believe this is the proper way to frame and evaluate the problem. Greg L (talk) 23:46, 20 April 2008 (UTC)

• P.S. I’ve withdrawn my vote in the survey. Thunderbird2 is using the proper process in evaluating the issue: who is the audience? Upon further looking at the article, it appears that a good case can be made that it is directed to a professional audience. Fnagaton: this is a poor choice of an article to make war on the IEC prefixes. As long as the authors here are properly considering who the audience is, that’s all we can fairly ask. I suggest you let them do as they see fit in this case and direct your energies on an egregious example that needs fixing. I do wish you’d chill a bit until MOSNUM#Follow current literature has better taken root. Greg L (talk) 21:55, 20 April 2008 (UTC)

---

Let's have a quick survey. Thunderbird2 (talk) 21:05, 20 April 2008 (UTC)

Survey

I think this article should use MiB, GiB, TiB ... to disambiguate

1. While I recognise the desire to follow the current literature, Thunderbird2 has shown numerous examples of current literature that uses GiB, etc. While we could examine the sources currently cited in this article, it therefore seems likely that (even if we don't already do so) we will sooner or later cite a source using the IEC units. Unless we wish to use inconsistent units (which would be very confusing), we therefore have to choose. I see our role as to clearly and precisely express the subject matter. While I recognise that an explanatory footnote helps, I think that use of ambiguous units (eg., GB) does not help the reader. Also, I think that we can assume a reasonably technical audience, who will likely be familiar with GiB, etc. (and if not, will likely follow a link as an opportunity to learn). Apologies for the not-very-brief explanation. Jakew (talk) 11:41, 21 April 2008 (UTC)
2. Clarity. I'm a strong supporter of IEC 60027-2. --217.87.99.52 (talk) 20:15, 21 April 2008 (UTC)
3. Reasoning per Jakew. Thunderbird2 (talk) 18:12, 21 April 2008 (UTC)
4. <your signature here (+ brief explanation)>

I think this article should use MB, GB, TB ..., and disambiguate with an explanatory footnote

1. Fnagaton 21:16, 20 April 2008 (UTC)
2. Anss123 (talk) 22:18, 20 April 2008 (UTC) (It's rear to see GiB used anywhere but here)
3. A footnote is much more clearer than GiB.DavidPaulHamilton (talk) 23:22, 20 April 2008 (UTC)
4. Oh, well then. After reading Jakew’s vote above, I see that no one has yet identified a cited source that uses the IEC prefixes. That changes things: facts I didn’t have before. Besides, the test isn’t where any source uses them, but what most of the sources cited in this article are using. Anywhere else, that would normally quickly settle the issue of what is the proper terminology and units of measure we should be using here to most easily communicate to this readership. Greg L (talk) 03:03, 23 April 2008 (UTC)
5. Common usage is MB, not MiB, and until the IEC terminology is standardized I believe this should revert to MB/GB/TB with footnotes. Resuna (talk) 00:24, 17 June 2008 (UTC)
6. Oh, no, do not let this slip in through the back door again, after years of fighting this bad bad bad idea. Common use is NOT to use GiB KiB etc, never seen it used in common computer magazines, never expect it to see it either, if it was bound to happen it should have happened by now. except perhaps in an article that explains the discrepancy in hard-disk capacities, and then only in a theoretical setting, as in "some experts use the term MiB". its NOT used in common conversation. P.S. I see, I reacted to an old thread, no use starting it up again. Mahjongg (talk) 17:33, 11 January 2009 (UTC)
7. <your signature here (+ brief explanation)>

I think this article should use MB, GB, TB ..., with some other form of disambiguation (please specify)

1. <your signature here (+ brief explanation)>

---

Where do we go from here?

That seems fairly evenly balanced. May I gauge the strength of your views?

The act of disambiguation is more important than the manner in which it is achieved

1. Ambiguity is the root of all evil.Thunderbird2 (talk) 19:52, 21 April 2008 (UTC)
2. <your signature here (+ brief explanation)>

IEC prefixes should never be used

1. DavidPaulHamilton (talk) 22:50, 21 April 2008 (UTC) If you must disambiguate it serves the reader to use the more familiar method. IEC is not familiar so do not use it.
2. The use of the non IEC prefixes is so ingrained, and with it the knowledge that it means binary, that using a different unit will only confuse. IEC prefixes are only for purely academic (rocket science) purposes, not for common conversation. Mahjongg (talk) 17:38, 11 January 2009 (UTC)
3. <your signature here (+ brief explanation)>

Ambiguous prefixes should never be used

1. <your signature here (+ brief explanation)>

I cannot identify with any of the above (please clarify)

1. This is a muddy grey area. I believe that arguments over the inherently ambiguous nature of the standard prefixes, while true, have become way overblown; their shortcomings largely an issue of our own making (the rest of the general-interest publishing world manages well enough with “GB”). The most important objective is to not confuse the readers. Who are the readers in this case? What can cause confusion in this case? Some would argue that “a 32-bit address space is 4 GB” causes confusion for an expert readership and this overrides concerns that “a 32-bit address space is 4 GiB” will be unfamiliar to less knowledgeable readers. I’m not sold on that reasoning yet; the whole article is clearly dealing only with binary address space. Still, given that this article is clearly directed to an advanced readership, the scales are not wildly imbalanced here. I have my idea as to the better solution but I have no problem with GiB for this article. Greg L (talk) 20:22, 21 April 2008 (UTC)
2. I wouldn't go so far as to say that ambiguous prefixes should never be used. Having said that, I'm not convinced that using "GiB" will really cause confusion, for two reasons. First, we can't be sure that readers will even be familiar with "GB", and the prospect of avoiding prefixes altogether seems unrealistic. Second, this is an encyclopaedia, and surely as a general rule readers of an encyclopaedia want and expect to learn something, and aren't frightened of doing so (I suspect, but can't prove, that this is especially true of more technical audiences). As a general principle, we don't avoid unfamiliar units, but we do wikilink them. So to my mind to "harms" of using ambiguous prefixes are greater than the "harms" of using potentially unfamiliar prefixes, at least in this article. I do agree with Thunderbird2, though, that some form of disambiguation is essential, and I would also say that lack of consistency within the article is probably more confusing than one prefix or the other. Jakew (talk) 14:28, 22 April 2008 (UTC)

• We do avoid using unfamiliar terms for disambiguation though. The sources do mostly use GB.DavidPaulHamilton (talk) 15:14, 22 April 2008 (UTC)
• Jakew, I don’t think your position conforms to the basic principals of technical writing. Your position stated above: “as a general rule, readers of an encyclopaedia want and expect to learn something” says, in effect “let’s go ahead and teach readers about ‘GiB’ because they are good units and it’s so good for readers to know about them, we should use them in an in-your-face, routine fashion like ‘oh, didn’t you know(?), this is the way one communicates on this subject’.” But no encyclopedia—not even Wikipedia with the power of wikilinking to easily explain stuff—should try to teach terminology that even computer aficionados haven’t seen before and which no one will likely ever again encounter out in the real world after leaving Wikipedia. Wikipedia is the only animal around that would pull such a stunt. I would argue that Wikipedia’s use is not because there is a broad consensus of support to do so (far from it), but is because the proponents of using them strongly believe they are so good, our use here on Wikipedia might somehow bootstrap their adoption. It hasn’t worked so far. Since the proponents started using the IEC prefixes en-mass two years ago, there have been seven archives (B1–B7) dedicated to arguments over their use and at least two regular archives (97 & 98) also dedicated exclusively to the issue. Their use has been highly controversial on Wikipedia and we’re pretty much alone on this; no other encyclopedia uses them—and for good reason. Greg L (talk) 02:42, 23 April 2008 (UTC)

• Greg L, I'm afraid you've misunderstood my argument. I'm not saying that we ought to use these units because it is good for readers to learn about them. I'm saying that we shouldn't avoid using them just because they might be unfamiliar (as with, say, zettajoules, we should use the units when appropriate, but should make every effort to make it easy for readers to become familiar with them). Nor am I saying that we should bootstrap their usage; as Thunderbird2 has shown, these units are used in the technical literature, and there is every possibility that readers will come across them as they learn about the subject. What I am saying is that the harms of using these units seem somewhat overstated, particularly given the likely audience of this article. Jakew (talk) 11:47, 23 April 2008 (UTC)

Greg L, where can one read about these "basic principals of technical writing"? I don't see how it's possible to interpret Jakew's statement in the way you do. Aren't you just once more ridiculing a statement that you disagree with? You summarization of the previous discussion isn't only extremely single-sided, it's plain wrong. I don't even see why you're arguing that much about this case at all. Let's look at your very own proposed "guideline": Wikipedia_talk:Manual_of_Style_(dates_and_numbers)#First_draft. This article is about as close as it gets to x86 assembly language. So why are you opposing something that is perfectly in-line with your own proposal? --217.87.102.163 (talk) 19:55, 23 April 2008 (UTC)

1. "a 32-bit address space is 2³²B = 4,294,967,296 bytes = 4 gigabytes". HAHAHAA --212.149.216.233 (talk) 15:00, 22 April 2008 (UTC)

1. I believe that common usage should be followed. Neither format is ambiguous as used on this page with appropriate footnotes, so ambiguity is not an issue. In any case, GiB and MiB is still ambiguous because it doesn't specify the size of the bytes. There are still computers operating with non-power-of-two words and bytes, after all. But, you say, the x86 family isn't one of them, and common usage is for 8 bit bytes... why then, the x86 CPU is not a disk drive either, and common usage is for MB and GB to refer to power-of-two prefixes. Resuna (talk) 00:30, 17 June 2008 (UTC)

inconsistent disambiguation

The inconsistent manner with which binary prefixes were disambiguated was not good for this article. I've fixed it. Thunderbird2 (talk) 08:24, 11 May 2008 (UTC)

I disagree, it is not inconsistent and the current way uses WP:MOSNUM approved ways of using familiar prefixes. So I've fixed your edits. Fnagaton 08:49, 11 May 2008 (UTC)

There is no consensus for the current wording at MOSNUM. Please do not add inconsistency to the article. Thunderbird2 (talk) 08:59, 11 May 2008 (UTC)

There is consensus please read WP:MOSNUM and WT:MOSNUM where it is clear there is consensus. Fnagaton 09:01, 11 May 2008 (UTC)

No consensus there. I see only disagreement. Thunderbird2 (talk) 09:08, 11 May 2008 (UTC)

I'm afraid you might disagree but there is wider consensus. Please see the comments by an uninvolved editor like Francis Schonken's edits where he wrote "I agree with the current version of the proposed guideline addition. ... I see no problem to make this part of the guideline now". Fnagaton 09:12, 11 May 2008 (UTC)

I am trying to improve this page by removing a long-standing and well documented inconsistency. You are reverting my changes without any attempt at explanation except by reference to a disputed styleguide. I have no intention of engaging in a sterile edit war with you. If you want to achieve consensus, try engaging in constructive debate. Thunderbird2 (talk) 09:49, 11 May 2008 (UTC)

I've already said it is not inconsistent (at my last edit). You've not shown exactly why it is inconsistent and since all of the use in this article is with powers of two it is not inconsistent to use the terms found in reliable sources, so don't try to accuse me of not providng reasons since you have not done so in the first place. Also the terms are disambiguated with the edits you made earlier in the edit history and are more familiar to the reader than using IEC prefixes. My goal is to improve the article by using prefixes that are more familiar to the readers and to disambiguate without pushing any point of view about what system to use, basically by disambiguating with the number of bytes instead of relying on virtually unused prefixes. Fnagaton 10:29, 11 May 2008 (UTC)

(ec) My recollection was that you had participated in the discussion concerning the inconsistency, and my attempts at that time at tidying up the article, so I did not consider it necessary to repeat the arguments. Thunderbird2 (talk) 10:35, 11 May 2008 (UTC)

Yes I remember and in response you made these edits which do not use IEC and I am fine with that. Nowhere in the discussion you just linked was it agreed that IEC should be used, unless of course you can supply the diff from that linked discussion that agrees your use of IEC? As Greg said above "The advantage of this wording [using GB etc], of course, is it is all the more accessible to a less knowledgeable readership.". Being accessible to less knowledgeable readership is an important aim of writing articles. Therefore use of familiar terms rather than the unfamiliar IEC prefixes is advantageous. Fnagaton 10:41, 11 May 2008 (UTC)

If you read the edit history and discussion you will see that the edits to which you refer are the ones that created the inconsistency in disambiguation that I now seek to correct. Thunderbird2 (talk) 13:57, 11 May 2008 (UTC)

I don't see any inconsistency if Fnagaton's edits are applied throughout. Resuna (talk) 00:33, 17 June 2008 (UTC)

Is this spell error?

In the first paragraph, "derived from the model numbers of the first few generations of processors". model "number"? Would that could be "member"?Callmejosh (talk) 06:36, 25 August 2008 (UTC)

The sentence is clumsy for other reasons, but "model number" is correct and "model member" would be incorrect. Model numbers (such as 8086, 286, and 386) are the identifiers for specific products. — Aluvus t/c 00:05, 26 August 2008 (UTC)

Thanks. I see the reason for your explanationCallmejosh (talk) 08:05, 26 August 2008 (UTC)

Xbox

The article uses the original Xbox as an example of an x86 based system with "different hardware from the PC" This isn't very true. The Xbox used a video card very similar to nVidia's commercial PC designs, IDE for storage subsystems, and USB and Ethernet as connection systems. Furthermore, with a BIOS hack the Xbox can boot an otherwise standard Linux kernel. —Preceding unsigned comment added by 128.211.227.55 (talk) 19:34, 9 September 2008 (UTC)

MSR Register

Hi,

It could also be interesting to describe the msr register. Since I don't really know about it I can't help.

Thanks —Preceding unsigned comment added by 82.236.49.183 (talk) 21:45, 17 November 2008 (UTC)

This is an insane x86 conversation I was forced into on my talk (I gave up at this point), it belongs either here or in the trash.

I have no objection to trashing it, so long as you've discontinued listing MOV as a SIMD instruction, which seemed to be the only remaining point of contention. -无名氏- 22:30, 28 April 2009 (UTC)

Please stop lying... I never listed mov as a SIMD instruction. HenkeB (talk) 04:10, 29 April 2009 (UTC)

SIMD or not

you stated: The fact that "MOV" has been extended to cope with 128-bit words does not make the 128 SSE registers general purpose. The bitwise instructions extended to the 128-bit SSE registers and memory locations is just SSE/SIMD, plain and simple. The fact that 128-bit registers can be pushed and popped to/from the stack with "normal instructions" is nothing more remarkable than the "MOV" mentioned above (although very useful). Only 128-bit SSE words (not 129-bit integers or addresses) are supported by the single-instruction-single-data core. What opcodes are used are irrelevant here.

you seem to be misinformed on a number of subjects. for starters, and this is the fifth time I'm going to be explaining this to you, but I'll try to elaborate to the extent that the facts will be unavoidable:

MOV is not a Single Instruction Multiple Data operation. MOV moves one value. whether MOV is moving an 8, 16, 32, 64, 128, or 16384 bit value, it's still not a SIMD instruction. SIMD means that two or more identifiably separate values are being manipulated in some way, which means performing some sort of ARITHMETIC or other mathematical operation on two or more groups of bits. for example, if you performed separate additions on AL+BL and AH+BH with one instruction, that would be a SIMD operation. however, MOV BX,AX is not a SIMD operation. that has nothing to do with register size or the typical purpose of the registers, it's that the operation doesn't do anything with multiple separate data.

you also seem to be having trouble distinguishing between integer math and moving a value in memory. not all processors support identical bit widths for math and memory, and since the addition of SSE in 1999, x86 has been such an architecture. the distinction was clearly stated as "Word size for memory moves" versus "the maximum integer size is." however, if you feel those terms are not precise enough, that isn't a reason to keep reverting, that's a reason to fix it.

you quoted "normal instructions" for push/pop. by "normal instructions" I mean the PUSH and POP instructions.

you mentioned "129-bit integers or addresses." x86 doesn't use 9-bit, or 17-bit, or 33-bit, or 65-bit integers or addresses. a signed 32-bit integer is still 32 bits, having a 31-bit numeric value and a 1-bit sign value.

also, moving a 128-bit value in memory doesn't imply a 128-bit address space.

you could move a 1024-bit value in a 16-bit address space if you had an opcode for it, and you can move an 8-bit value in a 64-bit address space.

in short, there are 5 completely separate concepts here that you seem to be lumping together:

SIMD: performing multiple separate MATHEMATICAL operations with one instruction. MOV, PUSH, POP, XOR, AND, OR, and NOT, aren't SIMD operations. they can't be, the concept doesn't apply to binary operations.

MOVES: moving a whole binary value of a given size from one storage location to another. meaning, memory-to-register, register-to-memory, or register-to-register. this is not a SIMD operation, it's just a straight binary move.

BINARY MATH: performing bitwise logic on two groups of bits. this isn't subject to SIMD because there's no logical grouping of bits.

ARITHMETIC: performing integer and/or floating point math on registers and/or memory locations. arithmetic specifically is subject to SIMD because there is a difference between adding two groups of two 16-bit values, and adding two 32-bit values.

ADDRESSING: different processors have different styles and restrictions on addressing. not all processors support addresses as large as the largest value that they can move or mathematically process. in fact, a processor supporting 64-bit math but only 32-bit addressing is typical. also, x86 processors have conventionally had addressing that is larger than their largest native word size, if you include the segment register.

anyway, it is a fact that almost every amd and intel processor made after 1999 can perform the 8086 instructions MOV, PUSH, POP, AND, OR, XOR, and NOT on 128-bit values. I'm not trying to misrepresent that as meaning that there is support for 128-bit integer or floating point math, and also, those aren't SIMD operations. so unless you can demonstrate that I'm mistaken, or that the non-SIMD 128-bit capabilities shouldn't be mentioned for some reason, please stop reverting and just FIX anything you think is unclear. -无名氏- 16:43, 25 April 2009 (UTC)

"FIX anything you think is unclear"? That's exactly why I wrote the paragraph on FP & SIMD; to try to explain the capabilties of modern x86, rather than the ambiguous wording you seem to prefer (I wouldn't say weasel-like, that's too harsh). Traditionally "word size", ALU-width, and (largest) integer size have been regarded as more or less synonymous for general purpose CPU-architectures, there is a fairly strong consensus on that. Therefore, your (previous) formulation would easily be misunderstood by many readers; it may seem to suggest that x86 is some kind of 128-bit machine, which would be quite misleading as it lacks any 128-bit arithmetics, having no 128-bit ALU (except for the bitwise part which is relatively simple, the addition/subtraction part of an ALU is much harder to implement (fast), due to the the necessary carry generation).

That the SIMD-units & registers, predominantly designed for SIMD operations, can be used also for other things is not any more strange than that the x87 FP-unit can load and store integer values and operate on integer values in memory. Also, the fact that the FP-unit in the 80486 (for instance) can load and store 64-bit (and 80-bit) floating point words is seldom pointed out as a 64-bit property of the i486 processor. (And the 129-bits was a typo, see next minor-edit.)

I actually agree on some of your points above, the reason why you think I disaggre on everything or belive that I'm misinformed eludes me. Perhaps it has something to do with the fact that you was clearly misinformed yourself (as you admitted), or because you do not seem to have read the new FP & SIMD paragraph I wrote, or that you seem to interpret my edit summaries somewhat strangely. However, your last edit is MUCH better, I only hope you can bare that I'm going to adjust the language only slightly ;) HenkeB (talk) 22:10, 25 April 2009 (UTC)

Traditionally "word size", ALU-width, and (largest) integer size have been regarded as more or less synonymous for general purpose CPU-architectures, there is a fairly strong consensus on that.

not so. in fact, x86 documentation conventionally refers to 8-bit values as a byte, 16-bit values as a word, 32-bit values as a double word, 64-bit values as a quad word, and so on. this is even expressed in instruction names like movsb for 8-bit byte, movsw for 16-bit word, or movsd for 32-bit double word. this naming convention is very common. for instance, the windows api defines a 16-bit value as a WORD and a 32-bit value as a DWORD on any platform.

Actually, I know x86 conventions like the palm of my hand, since the last 20 years or so, but you have to realize that many people don't. Belive it or not, but there are numerous other architectures, both historical and current (such as for embedded systems) that uses other conventions. The people not knowing x86 well is therefore the primary audience for an x86 article. Also, you changed the subject, my statement was not about names of integer datatypes, it was about the traditional correlation between ALU-width, integer-width, and "word size". HenkeB (talk) 12:58, 26 April 2009 (UTC)

I have no objection to omitting the term "word," and I did so. however, a word in x86 and most processor nomenclatures is 16-bits, not the largest supported integer or memory offset. -无名氏- 16:42, 26 April 2009 (UTC)

No, see Word (computing). HenkeB (talk) 18:39, 28 April 2009 (UTC)

quoting that article, Sometimes the size of a word is defined to be a particular value for compatibility with earlier computers. The most common microprocessors used in personal computers (for instance, the Intel Pentiums and AMD Athlons) are an example of this. Their IA-32 architecture is an extension of the original Intel 8086 design which had a word size of 16 bits. The IA-32 processors still support 8086 (x86) programs, so the meaning of "word" in the IA-32 context was kept the same, and is still said to be 16 bits, despite the fact that they at times (especially when the default operand size is 32-bit) operate largely like a machine with a 32 bit word size. Similarly in the newer x86-64 architecture, a "word" is still 16 bits, although 64-bit ("quadruple word") operands may be more common.

though, it is moot as I've eliminated the term "word" from the statement. -无名氏- 20:12, 28 April 2009 (UTC)

Therefore, your (previous) formulation would easily be misunderstood by many readers; it may seem to suggest that x86 is some kind of 128-bit machine, which would be quite misleading as it lacks any 128-bit arithmetics,

as I said above, if the problem is vague or weasel-like wording, please just fix or at least mark it, rather than taking it as a reason to delete/revert/bury it.

That's exactly what I did. I wrote a new paragraph that explained the capabilties in sufficient detail, to avoid misunderstandings. That I also removed a small misplaced and misleading remark should not really be that controversial. HenkeB (talk) 12:58, 26 April 2009 (UTC)

binary operations such as MOV have nothing to do with SIMD. -无名氏- 16:42, 26 April 2009 (UTC)

"Nothing to do with SIMD"? Well, they copy data to and from the SIMD registers. HenkeB (talk) 18:39, 28 April 2009 (UTC)

the registers are typically used for SIMD operations and were added with SSE, but the MOV instruction doesn't process separate groups of bits. it doesn't process the bits at all, in fact. it just copies them. you seem to be having trouble distinguishing between a SIMD instruction and a single-data instruction. SIMD isn't some marketing title like "a Pentium Pro instruction." it's a specific technical term meaning that a Single Instruction operates on Multiple Data. not every opcode added with SSE is a Single Instruction that operates on Multiple Data, and whether or not the XMM registers are involved has no bearing on what an instruction does and whether that involves multiple data. -无名氏- 20:12, 28 April 2009 (UTC)

having no 128-bit ALU (except for the bitwise part which is relatively simple, the addition/subtraction part of an ALU is much harder to implement (fast), due to the the necessary carry generation).

I agree, this distinction is important and should be clearly represented. the hardest part by far, in my experience, has been to implement efficient division.

"In your experience". Excuse me for being frank, but you seem like the typical bold WP "editor" with very limited experince on the subject at hand, but instead a large ego. I'm really sorry, but that's the impression I got. HenkeB (talk) 12:58, 26 April 2009 (UTC)

my personal qualifications are extensive, but it's moot, the only question is the facts. the subject of implementing arithmetic really isn't relevant, but in defense of what I said, adding two binary numbers consists of performing a bitwise test with a simple carry on each bit, from lowest to highest. that is:

if (Left&&Right) Carry<<=1; else if (Right) Left = true; else if (Carry) { Left = true; Carry>>=1; }

division, on the other hand, requires much, much more complex logic involving several counters and a series of additions and subtractions, and optimizing it typically involves storing static tables and performing a series of table lookups and other tests. I would recommend that you try implementing both addition and division in C using only binary math, and seeing which is more difficult. -无名氏- 16:42, 26 April 2009 (UTC)

Who mentioned division? Anyway, I'm glad your "personal qualifications are extensive". So, for your information, perhaps I should mention that I implemented many algorithms in 6502, Z80, and 68000 assembly language in the 1980s, division on floating point as well as integer formats among them. I fail to see the reason I should do the C language exercises you "recommend", and I find your C-snippet above uncomprehensible. HenkeB (talk) 18:39, 28 April 2009 (UTC)

if you wanted to see whether addition or division was more difficult to implement using binary math, you could try implementing both, but really all of this is moot, and not worth debating further. -无名氏- 20:12, 28 April 2009 (UTC)

That the SIMD-units & registers, predominantly designed for SIMD operations, can be used also for other things is not any more strange than that the x87 FP-unit can load and store integer values and operate on integer values in memory. Also, the fact that the FP-unit in the 80486 (for instance) can load and store 64-bit (and 80-bit) floating point words is seldom pointed out as a 64-bit property of the i486 processor.

FPU load/store is a great example of a non-binary move. you can't do a floating point move with the MOV instruction, and that's because floating-point loads and stores perform coding operations and support multiple coding models. the special instructions FLD and FST are used, and they can't be used for a binary copy. therefore, the x87 instruction set doesn't add 64-bit or 80-bit binary moves. FLD/FST are non-binary operations that are subject to SIMD, and in fact, there are SIMD instructions in SSE for performing several floating point loads/stores with one instruction.

That's mostly nonsense, it's perfectly possible to copy ("move") a 32-bit floating point number with a single mov, push, or pop instruction; compilers I designed (as well as many others) do this all the time; with 64-bit floating point numbers you need two 32-bit instructions, it's that simple. What you are probably thinking of is the conversion between integer and real-representations that takes place when you (for instance) use an integer operand with an x87 instruction. HenkeB (talk) 12:58, 26 April 2009 (UTC)

you're not addressing the subject by talking about moving binary memory that may happen to contain packed floating point values. you claimed that floating point instructions can move a 64-bit value. they can't. they can perform a "load" or "store" on a 32-bit, 64-bit or 80-bit value, but it mangles the data by performing floating point coding. there's no way to perform a 64 bit binary move with one opcode in the core 80386 instruction set, even with the floating point instructions. that's why the SIMD instructions support performing several floating point loads/stores with one opcode, because a floating point load/store isn't a binary move, it's an encoding operation, and you can perform several separate encodings on one large block of bits. -无名氏- 16:42, 26 April 2009 (UTC)

Read again and try to comprehend what I really claimed (nothing about copying of 64-bit integers). My exact wording was "load and store integer values", which is what fild and fist(p) do, and "load and store 64-bit (and 80-bit) floating point words", which is what fld and fst(p) do. And again, a floating point number is just as "binary" as an integer, and can therefore be "moved" using a plain copying of data; neither mov/push/pop or 128-bit SSE load/store instructions such as movaps or movapd "mangle" bits in any way. And again, the fact that x87 and SSE are able to round and perform (implicit or explicit) type and size conversions is another matter. Furthermore, your home made terms "non-binary move" and "moving binary memory" are quite illogical. HenkeB (talk) 18:39, 28 April 2009 (UTC)

you seem to be confusing a standard memory move (as in MOV) that isn't specific to any encoding, and floating point loads/stores that are coding-specific and that modify the supplied values. MOV is contents-agnostic and simply copies the bits without processing their values. meaning, the destination will always be identical to the source after the instruction. so yes, you can move packed floating point data or any data, but that has no bearing on the subject of floating point operations. -无名氏- 20:12, 28 April 2009 (UTC)

80-bit floating point specifically is used to implement 64-bit integer arithmetic in many cases, and in fact, that is why 80-bit floating point is supported. 80-bit floating point is exactly wide enough to support 64-bit whole numbers. however, the reason the instructions aren't used for 64-bit moves and binary math is that they don't enable those operations. even with floating point operations, a pre-MMX x86 processor can't perform a 64-bit move or binary math operation with one opcode. if you used a floating-point load and store to do a move, that would be two opcodes, and various combinations of bits would be modified by that procedure. -无名氏- 20:12, 28 April 2009 (UTC)

Perhaps it has something to do with the fact that you was clearly misinformed yourself (as you admitted), or because you do not seem to have read the new FP & SIMD paragraph I wrote, or that you seem to interpret my edit summaries somewhat strangely.

I was under the mistaken impression that you can perform 128-bit integer arithmetic on the XMM registers in SSE. I researched the subject myself when you questioned the assertion, I discovered that I was wrong, and I immediately corrected myself. however, I confirmed that you can perform 128-bit binary moves and bitwise operations, and correcting your mistaken impression that those are SIMD operations, and that integer operations aren't supported so neither are binary operations, has been a slow and difficult process.

If you prefer to call the bitwise SSEx operations "SIMD" or "128-bit" is totally irrelevant, as the result is the same (as you know). Referring to all (potentially single-instruction-mutiple-data) operations performed by the SIMD unit & registers as "SIMD operations" thus makes perfect sense. The real "slow and difficult process" has been for you to realise that I know what I'm talking about. HenkeB (talk) 12:58, 26 April 2009 (UTC)

you have it backward. my point has been that MOV is specifically NOT a multiple-data instruction, even with 128-bit operands, and that it doesn't belong in a section about multiple-data operations or to otherwise be removed or buried for reasons relating to SIMD, even though it was added with SSE. you seem to have reversed your position and to now believe that I was claiming that binary operations were SIMD and that their mention should be moved into a paragraph about SIMD. the edit history says the opposite, but it really doesn't matter, so long as you've ceased erasing/moving mentions of a 128-bit move on the grounds of mistakenly calling it a SIMD operation. -无名氏- 16:42, 26 April 2009 (UTC)

I never called 128-bit moves SIMD operations, although Intel does. However, all 128-bit mov-instructions copy data to and from the SIMD registers, so it's fairly reasonable mentioning them in a SIMD context, just as the Intel-manuals do; movaps and movapd, for instance, are presented as a move of 4/2 packed IEEE single/double floating point numbers. (Having different names and opcodes also for 128-bit copying of packed singles, doubles, and various integers enables future processors to check for zero, infinity, denormalized, etc.)

What the edit history indeed shows is a bold but clearly uneducated 无名氏 stumbling in the dark, presenting guesswork as facts: "true 128-bit integer ops", "true 128-bit fpu which enables 96-bit ints", and several other misconceptions. HenkeB (talk) 18:39, 28 April 2009 (UTC)

I was mistaken about the 128-bit capabilities in SSE. I was mistaken because CPU manufacturer advertising was inaccurate, but I looked at the actual instruction set, saw that I was mistaken, and I corrected myself. in spite of that, the facts are what they are. for example, a 128-bit MOV is possible, and a MOV isn't a SIMD operation. -无名氏- 20:12, 28 April 2009 (UTC)

movaps and movapd are SIMD instructions. they're examples of what I mentioned above, that SSE supports performing multiple floating point coding operations with one opcode, and that this is an example of how floating point loads/stores are coding operations that operate on a group of bits, and they are subject to SIMD. floating point loads and stores are completely different from the MOV instruction. MOV copies bits without changing their values, there is no grouping. a 128-bit MOV isn't moving two logically separate groups of 64 bits, or a group of 27 bits and a group of 101 bits. such divisions would be fictional and meaningless, having nothing to do with the instruction. thus, it is a single data instruction, not a multiple data instruction. -无名氏- 20:12, 28 April 2009 (UTC)

I'm an idiot, being lured into this parody once more, but again and again, try to grasp that movaps and movapd do NOT perform any "coding operations", and please specify exactly which x86/SSE instruction(s) you refer to as "non SIMD" 128-bit moves. HenkeB (talk) 04:10, 29 April 2009 (UTC)

I only hope you can bare that I'm going to adjust the language only slightly

please do. -无名氏- 02:41, 26 April 2009 (UTC)