Silicon Investor (SI) -- The First Internet Community

STOCKTALK

We've detected that you're using an ad content blocking browser plug-in or feature. Ads provide a critical source of revenue to the continued operation of Silicon Investor. We ask that you disable ad blocking while on Silicon Investor in the best interests of our community. If you are not using an ad blocker but are still receiving this message, make sure your browser's tracking protection is set to the 'standard' level.

Technology Stocks : Advanced Micro Devices - Moderated (AMD) -- Ignore unavailable to you. Want to Upgrade?

To: Petz who wrote (105871)	11/14/2003 11:20:14 PM
From: Joe NYC	Respond to of 275872

Petz, re: PADDQ page 84 - can add 2 64 bit integers PSUBQ page 232 - you can guess. Do these extensions only work in long mode? I was reading from AMD documentation as a convenience. The document I linked is part of the documentation that is common with Intel, just MMX / SSE / SSE2 documentation. Here is Intel version: tommesani.com Basically, extremely basic 64 bit integer operation can already be done in MMX / SSE, but it is done in such an incovenient place (floating point unit) that it is not practical for normal integer programming. I guess my overall point about 64-bit extensions is that adding registers and instructions is something relatively easy for an OS to handle -- it doesn't have to use the instructions and it just has to save and restore registers if a context change occurs when the software is executing in the extended mode. But adding 64-bit addressing is a whole nuther ball of wax, and that may be where Microsoft drew the line. I am by no means assembly expert, but apparently, adding registers runs into limitations of the instruction set, and apparently, going to more than 16 becomes extemely dificult, the instruction set needs to change more dramatically to accommodate this, rather than extending it. My general impression is that extending MMX/SSE-X extensions is relatively harmless, Intel can certainly add more extensions. The gains from these extensions is limited to specialized case. Let's take an example. (I welcome corrections, BTW) Suppose you want to add 2 64 bit integers, both are in 64 bit integer registers. In AMD64, you do it right in the ALU by issuing instruction: ADD RegX, RegY. And you have the result right there in RegisterX, that can be used in a subsequent comparison or any other general purpose instruction. To do it in MMX/SSE, (and this is even assuming AMD64, because without it, the 64 bit integers just don't exist except in a handful of MMX/SSE instructions), you have to first move these integers from general purpose registers RX to xmm registers (2 operation), issue the PADDQ, move the result back to general purpose register. Intel could add million instructions to MMX/SSE to handle everything, but than it is no longer x86 CPU, but a x86 CPU that can switch to a completely different MMX/SSE only mode. Anyway, the general purpose instructions execute in ALU. Messing with ALU is much much more difficult, messing with ALU to enable 64 bit computing in any useful manner (even without 64 bit addressing) will require changes of order of magnitude of close to AMD64. At least that's my opinion. Could Intel's extensions do everything AMD64 does except 64-bit addressing? The obvious question would be, Why do such a thing? 1) Preserve Itanium 2) cache design and chipset design doesn't have to change 3) would always be easy to go 100% AMD64 at some future time I guess it could be possible. But the cost is tremendous fragmentation of the instruction set. Intel would be asking Microsoft to write software for x86-32, IA64, x86-64 crippled, and be prepared to rewrite the x86-64 crippled to non-crippled when Intel requests it. I think that's way too much for Intel to ask. And Microsoft would have to be jumping up and down only because Intel screwed up with Itanium. This scenario does not match the balance of power between Intel and Microsoft. Intel would have to completely stop all Linux related activities, and Intel would still be short, in a quid pro quo. Joe