User talk:HenkeB

Your thoughts goes here.

Toshiba TMPZ84C015

Not sure why you re-uploaded Image:TMPZ84C015AF.png — the original one was removed from the article, but hasn't been deleted yet. BTW, it's probable best to upload any GFDL or Creative Commons images from other versions of Wikipedia to Wikimedia Commons when you use them. Cheers, --StuartBrady (Talk) 18:56, 12 July 2006 (UTC)

Well, I'm not sure I understand completely what is happening here, but the first time I uploaded this image (a week ago) I forgot to select a license, so I immediately uploaded it again, but this time under the name TMPZ84C015.png (without "AF") because I didn't know how to erase the previous one (or change attributes, if possible?) and that is the version currently displayed on the Z80-page. I probably should learn a little about Wikimedia Commons, and other stuff as well — I'm still a novice here at WP... -- HenkeB 21:50, 12 July 2006 (UTC)

Take a look at Image:TMPZ84C015AF.png, and choose 'edit this page'. You should see the licensing information is specified with templates. {{no license}} was added by OrphanBot when it removed the image from the Z80 article. You'd have had to change {{don't know}} to the correct template — in this case, it's {{GFDL}}. Wikipedia:Image copyright tags has a list of them. --StuartBrady (Talk) 22:24, 12 July 2006 (UTC)

Ok, I've tried that (on both files), I suppose the one with {{no license}} will be deleted soon(?).

I will probably use Wikimedia Commons next time — thanks for your guidance! -- HenkeB 23:39, 12 July 2006 (UTC)

Answer for inner functions in Perl

at http://fr.wiki.x.io/wiki/Discussion_Utilisateur:Stefp

Bass

The early bass players used the slap to add volume in between the bass notes and it seems clearly imitative of a snare drum "backbeat." By saying "percussive" this implies that it's a deep, drum-like sound and there is an element of this due to the fact that the wood of the bass body will vibrate sympathetically with the slap. However, the slapping of the thick metal-wound strings against the hardwood of the fingerboard, in all the traditional jazz and rockabilly bands I've heard who use this technique, it produces a strong trebly metallic "click," as opposed to a deep "thump" Badagnani 00:16, 23 October 2006 (UTC)

With gut strings, are the lowest strings wound or just pure gut? How would you describe the sound produced by the slapping of gut strings? I've seen the clip of Cab Calloway's "Reefer Man" and it sounds similar to the more modern examples I've heard. Badagnani 00:28, 23 October 2006 (UTC)

Interesting to hear about this music in Sverige. I think you're describing the difference between the technique as done with gut and metal-wrapped strings. I'd agree with you on the sound produced by the gut strings. I think we could split the difference in the description, while acknowledging that with either kind of string there's a sharpness (maybe somewhat like a "crack" of a snare drum rather than a "click") to the attack which is contrasting to the mellow, round depth of the bass string's plucking -- though the metal strings create a sharper attack. So it creates a substitute for a snare drum when a band doesn't have a drummer. I think another reason it imitates the snare drum is that if one slaps more than one (or all four) of the strings against the fingerboard, they don't all strike at exactly the same instant, creating a complexity of sound that is similar to the sound of the snare drum, with its many wires jangling against the bottom drumhead. By the way, I listen to a lot of Swedish folk artists, one of my favorite being Garmarna who do old Swedish songs with modern instrumentation. Badagnani 02:46, 23 October 2006 (UTC)

Svensk jazz

I'll look for that music! I heard of something similar, but it may have been Norwegian songs that were learned and arranged by Art Farmer, I think, maybe in the 1960s or 1970s. Badagnani 04:40, 23 October 2006 (UTC)

Oh, it's here: http://www.amazon.ca/Sweden-Love-Art-Farmer/dp/B00000IWNQ Do you know this one? Badagnani 04:42, 23 October 2006 (UTC)

You can try this one (it's working for me now). One phrase in "De Salde" reminds me of a phrase from Grieg's "Peer Gynt." http://www.cduniverse.com/search/xx/music/pid/6764228/a/To+Sweden+With+Love%2FLive+At+The+Half+Note.htm Badagnani 05:49, 23 October 2006 (UTC)

Good night? Have you got the midnight sun these days?  :) Badagnani 07:41, 23 October 2006 (UTC)

'8085 architecture, which resembles neither CISC nor RISC'

tell me whether 8085 is a RISC or CISC design? It's CISC. When the term RISC was invented, CISC was invented to describe all the other conventional architectures of the time. Thus, it meant approximately non-RISC, and means much the same today, although VLIW, dataflow, and some other minor categories would typically be excluded. The 8085 is not particularly odd for a CISC design, although it certainly differs from a VAX or 68000. The latter are late developments of the "CISC" design tradition, but their predecessors like PDP-11, Nova, PDP-8 show more resemblance to the 8085. RISC and CISC are not great categories, but trying to reform their meanings at this point is hopeless; better to just let them wither. -R. S. Shaw 20:53, 20 January 2007 (UTC)

I'm glad you belive those are not great categories, but how can they wither away if we continue to re-establish them over an over (particulary on WP)?

Regarding their more concrete technical meaning: I assume you can agree that one of the central ideas behind RISC was to leave complicated addressing modes out, as such addressing was normally implemented by varied length microcode routines, which, at the time, was very hard and/or expensive to fit into a pipelined execution model.

With that in mind, it's a little hard to digest that architectures with even simpler addressing modes (such as the 8008) should be labeled as complex. I have no problems with the term "RISC", as it means something. "CISC", on the other hand, is a sloppy retroactive label (as implied by yourself), which can meaningfully describe only a subset of all non-RISC computers. As such, the term should be used very sparingly and only for machines that fits the description. To just give up, as you suggested, and quietly accept whatever usage of terms and language, is wrong :)

HenkeB 22:15, 20 January 2007 (UTC)

So which language was C's enumerations influenced by?

By the time enum was added to C, in a typically integer-oriented way, other Bell Labs staff were contributing to C in various ways, and presumably some of them were familiar with Pascal. Note that Pascalisms like case ranges were never picked up for C. My objection to the addition of Pascal as an "influence" is that whatever influence it might have had occurred only after C was substantially complete, was indirect, and was not as significant as the other listed influences. — DAGwyn 01:56, 2 March 2007 (UTC)

7400 series

Hi. I've been watching several rounds of edit-revert-restore happening on 7400 series. May I suggest that rather than continuing the Wikipedia:Edit war, you discuss the issue on talk:7400 series and come to consensus that all can live with? Thanks. -- RoySmith (talk) 03:56, 14 January 2008 (UTC)

I made two edits - with sensible comments, hardly a war... Thanks. / HenkeB (talk) 04:04, 14 January 2008 (UTC)

I've seen edit wars. This is not one. I don't think the proposed addition adds any content to the article, that's all. Too many Wikipedia articles are written like school assignments that have to hit 1000 words. It's just padding. --Wtshymanski (talk) 04:07, 14 January 2008 (UTC)

Ok, I suppose I once wrote that because I felt many (computer oriented) people had a far too rigid, "modular", or "square" (pardon my limited English) view on what electronic components really are about; and, regarding padding, check out some of the articles on history, countries, or similar topics... / HenkeB (talk) 04:23, 14 January 2008 (UTC)

bytecode

I've looked into google and I think it's seventies, smalltalk has it, p-code too, may be some lisp implementation. May be I'll just ask RMS about it, likely to be on old paper only and not accessible to google. Guerby (talk) 21:45, 10 June 2008 (UTC)

RMS = Richard Stallman Guerby (talk) 17:20, 11 June 2008 (UTC)

I checked one of my books "SMALLTALK 80" and it already has bytecode in the index. Linked from wikipedia Smalltalk page http://gagne.homedns.org/~tgagne/contrib/EarlyHistoryST.html mentions bytecode for 1960-1966 era. Guerby (talk) 17:30, 16 June 2008 (UTC)

I don't know what you mean by "not widespread", smalltalk was about the most talked about language in the eighties, for example there was a whole issue of "Byte Magazine" about it, you can read more here: http://www.byte.com/art/9608/sec4/art3.htm and cover with "SMALLTALK" in big here: http://www.byte.com/art/9608/img/086bl3a1.htm Guerby (talk) 18:56, 20 June 2008 (UTC)

Wikimania 2010 could be coming to Stockholm!

I'm leaving you a note as you may be interested in this opportunity.

People from all six Nordic Wiki-communities (sv, no, nn, fi, da and is) are coordinating a bid for Wikimania 2010 in Stockholm. I'm sending you a message to let you know that this is occurring, and over the next few months we're looking for community support to make sure this happens! See the bid page on meta and if you like such an idea, please sign the "supporters" list at the bottom. Tack (or takk), and have a wonderful day! Mike H. Fierce! 09:05, 5 August 2008 (UTC)

Thanks for that! (Yes, it's Tack! in Swedish). HenkeB (talk) 10:17, 5 August 2008 (UTC)

Personal attacks - SSD

Please cease your personal attacks on me at talk:Solid state drive. If you wish to courteously discuss article improvements, fine. Zodon (talk) 21:53, 26 September 2008 (UTC)

Pentium Pro Fabrication

Hi! I've noticed you have tweaked the statements regarding the semiconductor processes the Pentium Pro used. However, I recall that in the Microprocessor Report, the Pentium Pro was described as having used a "BiCMOS process" or something similar. I'm no expert on semiconductor processes, but I think that Bipolar Junction transistors are structurally and electrically different from MOSFETs that are used in CMOS transistors thus requiring different fabrication. In fact, in the late 1990s, I think there was an article about how Texas Instruments was giving up on BiCMOS devices because they could not get the BJTs to scale with the CMOS transistors properly or something. Am I completely wrong about this? Regards. Rilak (talk) 04:38, 4 October 2008 (UTC)

No, you are not completely wrong, but you cannot really say "CMOS transistors". You are right in that BiCMOS (bipolar transistors mixed with pMOS and nMOS transistors) need special process steps compared to ordinary CMOS (only pMOS and nMOS transistors). However, BiCMOS could hardly be called a process in itself, so the a in "a BiCMOS process" is rather significant. Similarly, as you probably know, CMOS structures has been built using many many different manufacturing processes (or techniques/methods) over the years, the scale, or feature size, being one of the differences between them. Regards. HenkeB (talk) 05:39, 4 October 2008 (UTC)

Yeah, I know "CMOS transistors" isn't right, but I couldn't think of a better word at the time :) Anyways, a quick Google Books search returns: D Widmann, H Mader, H Friedrich, Dr. "Technology of Integrated Circuits". Springer, 2000, ISBN 3540661999, 9783540661993 has what appears to be a large section on "BiCMOS process". A Google Search also returns many reliable sources that mention the term. Going through some old microprocessor datasheets, the term "BiCMOS process" was used, by the manufacturers themselves. I'm wondering if the article remain the way it is or should it be restored, as the term seems to be technically correct and is used widely. Rilak (talk) 06:13, 4 October 2008 (UTC)

You do as you wish of course, but my point is that BiCMOS is a way to design gates; basically, it's about employing bipolar push/pull output stages in strategic places in order to charge certain high capacity loads faster, thereby speeding up "critical paths" (such as long metal interconnects). This was made possible by complicated multi-step manufacturing processes.

Words such as process (and, in particular, technology!) are often used quite differently by different people, although each "subculture" use the word as if it was clearly defined! The word process may denote: (1) the hundreds of manufacturing steps in a "real process", (2) a schematic, generic, or principal model of the latter (like in the book you mentioned), (3) a manufacturing scale, such as 90nm (many sites/forums on the web) etc. As you have already guessed, for an encyclopedia with a serious tone, I would vote for the first definition :) Regards. HenkeB (talk) 17:13, 4 October 2008 (UTC)

I think that the statement in question should be changed to reflect the conventions that the manufacturer and the semiconductor industry uses, which is "BiCMOS process". You are correct in that "process" has many definitions in different contexts, but "disambiguating" the statement I think is not required. For example, you said that "process" can be defined as "the hundreds of manufacturing steps", but it is in my view that the term "BiCMOS process" already covers this as it can be literally defined as "a fabrication process to construct integrated circuits that contain bipolar junction and CMOS transistors". Prefixing, for example, "0.5 micron" to "BiCMOS process" - "0.5 micron BiCMOS process" can be literally defined as "a fabrication process to construct integrated circuits that contain bipolar junction and CMOS transistors with an average feature size of 0.5 microns", thus satisfying the third definition. How would you feel if I changed it back and cited it? Regards. Rilak (talk) 04:51, 6 October 2008 (UTC)

If it's important to you, go ahead! And while you are at it, please also change the word "fab" in "the process used to fab the Pentium Pro...", then we can both be happy. Regards. HenkeB (talk) 07:49, 6 October 2008 (UTC)

I've changed it back, tweaked the statements a little and cited a reliable source. It should be noted that source's claims differ from what the article claims so you might wish to take a look. Regards. Rilak (talk) 10:47, 6 October 2008 (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 only hope you can bare that I'm going to adjust the language only slightly

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

Intel Pentium (P5 microarchitecture)

The trademark Pentium need not and should not be in the title of the P5 microarchitecture. Despite the fact that microprocessor cores were initially released under a brand name containing such a trademark this is not the place for that anymore than the Netburst microarchitecure should be named something akin to "Intel Pentium 4 (Netburst microarchitecture)". The Pentium trademark has been used for many different brands and those brands for many different cores from many different microarchitecures. You cause more confusion than you attempt to solve my making such changes. Please discuss on the Talk:Intel Pentium (P5 microarchitecture) page first. Uzume (talk) 21:23, 1 June 2010 (UTC)

I don't see your point. "Intel Pentium 4 (Netburst microarchitecture)" would be just fine, there are no contradictions in that naming. "Intel Pentium 4 (Willamette)" and "Intel Pentium 4 (Nortwood)" would be ok too, if these were separate articles. Moreover, the original usage of a term, name, "brand", "trademark", or whatever, deserves special emphasis. HenkeB (talk) 22:54, 1 June 2010 (UTC)

Well what about "Intel Pentium D (Netburst microarchitecture)"? (obviously the same thing as "Intel Pentium 4 (Netburst microarchitecture)" so it is not a good name) "Intel Pentium 4 (Willamette)" is a different thing as Willamette was a core of Netburst microarchitecture (and there were several models with different brands applied to Willamette too). As you can see the use of the trademark/branding only confuses the issue and does not clarify it. If you want to clean up the P5 article to move trademark and branding information out into the Pentium, Pentium (brand), or other Pentium brand articles please do so but the microarchitecture was never called Pentium until Intel lost the court case to trademark i586 and then it was only employed as a marketing branding name. Your including "Pentium" in the article name only dilutes the meaning of the article and confuses the issue. If anything the name Pentium was applied later and P5 is and always was the original and most proper name of the microarchitecture. Uzume (talk) 23:25, 1 June 2010 (UTC)

ArbCom elections are now open!

Hi,
You appear to be eligible to vote in the current Arbitration Committee election. The Arbitration Committee is the panel of editors responsible for conducting the Wikipedia arbitration process. It has the authority to enact binding solutions for disputes between editors, primarily related to serious behavioural issues that the community has been unable to resolve. This includes the ability to impose site bans, topic bans, editing restrictions, and other measures needed to maintain our editing environment. The arbitration policy describes the Committee's roles and responsibilities in greater detail. If you wish to participate, you are welcome to review the candidates' statements and submit your choices on the voting page. For the Election committee, MediaWiki message delivery (talk) 13:53, 23 November 2015 (UTC)