Replies to post #2671 on Advanced Micro Devices Inc (AMD)

[yourbankruptcy]

wbmw, that's true. 90% of all existing applications will break when integer becomes 8 bytes. There are so many obscure places in immature code when this bug may pass all the QA and then bum in production. In my code, I use int32 and int64 variable types to avoid that. Integer is almost prohibited. When I need the size of the integer I always put it as "sizeof(int)". Also "sizeof(char*)" whenever the pointer size is needed.

All databases from commericial like Oracle and Sybase to OSS like MySQL and Postgresql are completely clean today. So, porting Oracle to Opteron or IA64 is just politics, not software problem. The actual port is just 1 day work and then 3-6 weeks of QA (depends on the product). That's it.

[sgolds]

wbmw, actually, it depends on how efficient you want your EPIC code. A simple port in the way you described can be done, but it does not take advantage of EPIC optimizations based on the order of instructions. Without hand coding of critical paths you get a reliable but inefficient code with parts of the CPU stalling because instruction queues get underruns.

Originally, Intel expressed that compilers would be able to take care of this. However, Intel never did quite understand the subtleties of software developement. It was widely reported by Itanium developers that they were disappointed with the efficiency of Itanium compilers. I have not read anything in connection with Itanium2 to see that the compilers have improved noticably.

EPIC simply must have code properly optimized or the whole theory of it falls apart.