User talk:Timharwoodx

From Wikipedia, the free encyclopedia

Welcome!

Hello, Timharwoodx, and welcome to Wikipedia! Thank you for your contributions. I hope you like the place and decide to stay. Here are a few good links for newcomers:

I hope you enjoy editing here and being a Wikipedian! Please sign your name on talk pages using four tildes (~~~~); this will automatically produce your name and the date. If you need help, check out Wikipedia:Where to ask a question, ask me on my talk page, or place {{helpme}} on your talk page and someone will show up shortly to answer your questions. Again, welcome!  --Etimbo | Talk 01:47, 16 Jan 2005 (UTC)

Contents

[edit] Works in Progress

I like to edit the IT articles. Articles I'd done work for incude:

Most notable? Probably the AMD page, as I did a major re-write, and its yet to be significantly changed from where I left it. Also the structure of the ATI and NVIDIA sections is a lot down to me, the nav bars, classification according to core revisions, the market trends text, etc. I also put articles up for deletion every now and then, such as ones on NVIDIA marketing demos (other than DAWN, which WAS notable, for several reasons).

Some of the articles I've created.

Nav bars:

.......... and lots of other pieces of tidy up all over.

[edit] Great work on AMD

Timharwoodx, You're doing great work on the AMD-related stuff. There was—and is—a lot to do in this very messy collection of pages. I've worked on it from time to time, but you're making it even better than I had ever envisioned.

DanielVonEhren 17:25, 26 Mar 2005 (UTC)

I've got a soft spot for AMD. They deserve their place in history. So do Jerry Sanders and Dirk Mayer. Now there is a nice neat title bar for AMD processors, maybe it will encourage some more work on the pages. Timharwoodx 20:02, 26 Mar 2005 (UTC)

In response to questions, I will be more specific. The k8 has 2 modes, long mode (64 bit), and legacy. I would anticipate at some future point, to save die space and reduce manufacturing costs, legacy mode will be eliminated from the feature set. Windows VISTA is supposed to be 64-bit, and once than becomes the standard shipping OS, legacy mode becomes redundant.

Also, about the FPU, quite clearly x87 is NOT DEFINED under AMD64. The fact x87 works in long mode on the K8 is beside the point - thats an undocumented feature. Undocumented features can, and often are, eliminated without warning.

MMX, SSE, x87 often use the same hardware registers, I take the point. However, because they use the same registers, any mixing and matching of SSE / x87 code causes inefficient processor stalls. In the VIA C3/C7 the hardware is different, but again, the elimination of the x87 FPU would clearly save die space.

Timharwoodx 22:48, 3 February 2006 (UTC)

[edit] The great FPU debate

Presumably by "the FPU" you mean "the hardware that executes x87 instructions", not "the Floating point unit that executes floating-point instructions", as SSE2, at least, also includes instructions that manipulate floating-point values. Guy Harris 01:11, 31 January 2006 (UTC)
Yes. SSE 1,2,3, replaces x86 FPU under AMD64. Timharwoodx 22:49, 31 January 2006 (UTC)
Probably better stated as "SSE/SSE2/SSE3 replace the x87 floating-point instructions (except for the FISTTP x87 floating-point instruction that SSE3 adds)". An FPU is a piece of hardware that performs floating-point calculations; an Intel paper on NetBurst says:
Floating-Point (x87), MMX, SSE (Streaming SIMD Extension), SSE2 (Streaming SIMD Extension 2), and the new SSE3 (Streaming SIMD Extension 3) operations are executed by the two floating-point execution blocks. One of the execution blocks is used for simple operations, such as SSE register-to-register moves and x87/MMX/SSE/SSE2 store data uops. The other execution block is used for more complex operations.
and an AMD slide presentation on Hammer seems to show a floating-point block but no separate SSE block, so I suspect it, like the P4, uses the same floating-point hardware for x87 and SSE/SSE2 floating-point. Guy Harris 23:21, 31 January 2006 (UTC)
Well the x86 FPU is still there in K8 hardware, but is not defined under AMD64. So the k8 is a transitional piece of hardware. Once The standard version of windows is based upon AMD64, AMD will just drop the x86 FPU from the die, lower manufacturing costs, and use a combination of microcode instructions and the SSE unit for legacy compatability.

http://www.via.com.tw/en/products/processors/c7/specs.jsp#blkdiagram

The C3/C7 block diagram just happens to be nice and clear. Under AMD64 native, the FPU part can go. Basicaly, present x86 CPUs that are AMD64 compatible have two FPUs on chip, x86 classic and SSE AMD 64. Long term, only SSE will be left.
The C3/C7 block diagram might be clear, but it's also irrelevant to other x86 processors. See, instead, Appendix A, section A.13, of AMD's Software Optimization Guide for AMD Athlon(TM) 64 and AMD OpteronTM Processors, which says:
The floating-point logic of the AMD Athlon 64 and AMD Opteron processors is a high-performance, fully pipelined, superscalar, out-of-order execution unit. It is capable of accepting three macro-ops per cycle from any mixture of the following types of instructions:
• x87 floating-point
• 3DNow! technology
• MMX technology
• SSE
• SSE2
and section A.14, which says:
The floating-point execution unit (FPU) is implemented as a coprocessor having its own out-of-order control in addition to the data path. The FPU handles all register operations for x87 instructions, all 3DNow! technology operations, all MMX operations, and all SSE and SSE2 operations. The FPU consists of a stack renaming unit, a register renaming unit, a scheduler, a register file, and three parallel execution units.
so the Athlon 64 and Opteron, at least, use a single floating-point scheduler and single floating-point execution unit for the x87 ("x86 classic") and SSE/SSE2 instructions, as well as for the MMX and 3DNow! instructions, rather than having separate floating-point units for x87 and SSE/SSE2.
Now, they could reduce the number of transistors by not optimizing the translation of x87 (and perhaps MMX) instructions to uops, and not doing stack renaming (which would be the closest thing to "dropping the x86 FPU from the die") so that, for example, only one x87 instruction could be executed at a time; the question is whether that'd free up enough transistors to do anything interesting, or reduce the cost enough to be interesting.
I'm also not sure that changing the floating-point scheduling and execution units not to optimize x87 instructions would make enough of a difference to "allow a total redesign of the chip from the ground up". It'd be interesting to see what AMD chip designers would say (they're probably the only people in a position to say anything definitive about that). Guy Harris 10:03, 1 February 2006 (UTC)
The rumor was always that AMD added MMX / SSE functionality largely by FPU microcode - originally. Going forward, a dedicated SSE unit will emulate x87 FPU via microcode. I accept maybe 'total redesign' is slightly too strong, but with the extra registers, RISC type FPU, you effectively turn x86 into a RISC type instruction set. At least, near enough, that x86 adopts most of the major advantages of the RISC instruction sets. That is big news. An edit was made to the page that made it look like AMD64 was just 64 bit IA-32. Nobody else really seemed to grasp SSE replaces x87 under AMD64, so maybe I got a bit carried away......... Timharwoodx 22:15, 3 February 2006 (UTC)
If future processors implement the x87 instruction set, it's not "emulation" if they dedicate less circuitry to it. And saying that "a dedicated SSE unit will emulate x87 FPU via microcode" is just making a prediction, which might or might not be correct. I'm not convinced that it'd buy them very much to dedicate less circuitry to it; I'm not sure anybody other than a microprocessor design engineer could convince me, and even then it might take one actually working for AMD or Intel.
Going from 8 GPRs to 16 GPRs hardly turns x86 into a RISC instruction set; the 68k and S/360-and-successors have 16 GPRs and they're not RISC. SSE* isn't exactly RISC, either - the SSE instructions still have all the standard x86 addressing modes. The trick was that Intel and AMD adopted implementation techniques that gave their x86 processors enough performance to refute the "CISC is out of gas" arguments - without going to a completely different RISC-like instruction set. That, however, was done before AMD64. Guy Harris 22:34, 3 February 2006 (UTC)
Thats what I said 'x86 adopts most of the major advantages of the RISC instruction sets.' The 16 register switch is where a lot of the projected performance gains come from. Not true RISC, but good as makes little to no performance difference. Sorry, microcode is emulation. You're wrong about that. VIA admit it quite openly. Software to replace hardware. The PC industry is about margins. If you can make something 5% cheaper you do. Intel dropped IA-32 support from the Itanium recently to save a few % on die space for that exact reason, refuting your idea PC makers don't care about manufacturing cost. CISC is out of gas. The Pentium 1 was the last CISC x86 chip made in volume. Internally, all AMD and Intel chips have been RISC ever since. Anyway, AMD64 is an instruction set page, not a hardware page, so none of this is strickly relevant. It IS a major change to the instruction set. With that in mind, your point here is what?Timharwoodx 22:48, 3 February 2006 (UTC)

[edit] Aetherometry

An article on Aetherometry has been nominated for deletion. I'd be very interested in any comments you might care to make, preferably in the VfD discussion.

I voted for deletion but said that I would change my vote if someone convinced me that aetherometry has the status of an important and well-established theory/discipline within the perpetual motion/free energy/overunity community, and I mean it. In this regard, I would give a lot of weight to your opinion. Dpbsmith (talk) 22:54, 23 Jun 2005 (UTC)

All M-M proved, was that certain concepts about the structure of the Aether were not sustainable. The debate was not resolved. People will keep submitting aether pages until one gets let through. The WIKI community should accept this. A section of the community demands an aether page. The 'zero point energy' is clearly the same basic concept as the aether, and I think many of us think the game of petty semantics played by modern phycicts, is just pathetic. As for the article, I agree it is flawed in several places, however, as a first draft, I would rate it as useful and informative. In sum, regardless of anything else, I think this game of constant deletion requests for aether pages is getting boring. Just let one in, slap on NPOV, and lets be done with it, and agree to disagree. Timharwoodx 00:25, 24 Jun 2005 (UTC)

[edit] Nvidia VANTA

To clarify, the VANTA was actually a product of its own. It was based on the original TNT1 core, but had DVD motion comp which the TNT1 did not have. The M64 and VANTA were not the same product - saying so would be like saying that the Pentium II/III and the Celeron were the same product.

Thanks. I'll look into it. I guess I can't get everything right. But inventing bogus categories is the most common sin in the IT section. Timharwoodx 10:38, 8 December 2005 (UTC)

Well I have now checked up on this, and I note The NVIDIA press release and another I found both clearly stated VANTA 'Leveraging the RIVA TNT2 core.' The user seems unable to reference his claim VANTA was a TNT1 product - contrary to NVIDIA's own website claims. I think the user is confused about NVIDIA's product history. TNT2 was TNT1 with a process shrink - but since I wrote the TNT pages, thats pretty much stated, and should be *OBVIOUS*. VANTA was a lower clocked version of the M64, that never sold in any volume. Timharwoodx 20:35, 11 December 2005 (UTC)

[edit] Article in need of cleanup - please assist if you can

The article AMD K10, to which you have helped contribute, has been flagged as requiring cleanup.

If possible, we would appreciate your assistance in cleaning up this article to bring it up to Wikipedia's quality standards. If you are unsure what the nature of the problem is, please discuss this on the article's talk page.
Retrieved from "http://en.wikipedia.org../../../t/i/m/User_talk%7ETimharwoodx_03c7.html"