Industry sources confirm that there are problems converting 32-bit code to run on Digital Equipment Corp’s 64-bit Alpha systems but suggest that Hewlett-Packard Co has got the wrong end of the stick (CI No 2,651). Problem one: when converting from 32-bit Unix to DEC Alpha (running Digital Unix), Digital Equipment Corp makes pointers different sizes; Int being 32-bit, Long being 64-bit. On a VAX and every other normal machine an Int and a Long are both 32 bits. This tends to cause lots of problems that are straightforward but tedious to fix. Problem two: With Int and Long being different, typical C compilers will silently convert back and forth from Int to Long, even though to do so might produce wrong answers. This mostly arises through function calls in C, because the language is so loose about this. For example, a function declared: void myfunc(long x)that is called elsewhere like this: myfunc(27);might not work, depending on how the declaration was made in the calling environment. It is likely that the 27 will be passed as a 32-bit value, which will screw up the function because it expects a complete 64-bit value. Apparently, there was an effort during the Alpha design process to get DEC’s C++ development people to design the compiler so that it issued more warnings about Int->Long and Long->Int conversions. Problem three concerns Alpha’s lack of byte-oriented instructions. Code written to do byte-by-byte string processing can suffer on Alpha. Regarding standards for floating point, the feeling is that de facto standards are adequate, and that Hewlett-Packard is making a mountain out of a non-existent molehill.
