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: wanna_bmw who wrote (56146)	9/24/2001 8:04:26 AM
From: pgerassi	Respond to of 275872

Wanna_bmw: Re: "AMD is left with a glorified 32-bit processor, which will suffice for the desktop market, but it won't penetrate the enterprise." Neither was Xeon. It penetrated fairly well for being a 32 bit processor. Re: "What risk? These applications are all validated and tested before they launch. There should be no more risk than programming for any other architecture." They have not gone through years of debugging work at the very minimum. Also many applications are built to the idiosyncracies of a particular compiler version. Just changing a version of the compiler can be a 6 to 12 month job. Ditto for libraries, RDBMS and OS. And that does not even include those faults due to 2nd and 3rd order effects and interactions. And that is with production worthy compilers of which IA-64 does not have. Re: "As for the difficulty in coding, like all new instruction sets, there is probably a little low level coding required to get fast and stable code at this stage of development. But like all other instruction sets, this will eventually get to the point where the coding is 100% high level, such as C++, while the compiler does all the work. If they aren't there already, they soon will be." You like everyone at Intel, underestimated the problems of making a optimizing compiler for VLIW architectures. Many have tried to crack that nut of needing a compiler that optimizes for a given VLIW implementation, works for all cases, robust and generates good code in a reasonable time with a small amount of effort. Its relatively easy to get code out that works. Its a lot harder to get it with good performance. And that is easy compared to getting it to work in a dynamic environment (the real achilles heal or VLIW CPUs). The compiler builds code for a single copy running all by itself on a machine. That of course assumes that all of the previous stuff works. It is no longer optimal, if being used like most people use them, doing multiple things all at the same time. That is the reason why the only succesful implementations of VLIW CPUs are those in embedded applications where the problem is very restricted (one app running all by itself and many millions of exact copies). Re: " But there is no support for 64-bit extensions, or 64-bit addressing support for x86-64 in Windows XP. Nor has there been announced any such support." BS! Linux has support for x86-64. It is used in more servers than IA-64. Heck, NT is only 64 bit on Alphas. Most UNIX systems will not have much trouble with x86-64 support. Much of the support is already there becuase of 64 bit RISC. A few thousand lines of assembly for performance and a 64 bit cross compiler is all that is needed to make most UNIXes work in 64 bit mode, since they already have the APIs, the libraries and utilities already coded for 64 bit CPUs. This is typical of any UNIX port to a new architecture. This was the problem for IA-64 as the compiler would not generate good code robustly, thus, the amount of assembly work required was much higher. I think you forget about how little needs to change to add 64 bit support for x86-64. The only areas affected are those that switch tasks and manage memory. That is a far smaller subset of any modern OS than a full top to bottom changeout ala IA-64. Losing the segment registers, the legacy BCD math support and single byte increments and decrements are a small price to pay as these things are rarely used currently in any application (for many apps, the segment registers are indentical). Trying to equate the little change for converting x86-32 to x86-64 to the massive one converting from x86-32 to IA-64. Just shows how rose colored those glasses are. Pete