Bayard Coolidge USG <[EMAIL PROTECTED]> writes:
> However, I'd strongly encourage looking more at what might be coming > up in Itanium, and rather than doing Assembly-level stuff, be looking > at what it REALLY takes to migrate existing C/C++ code to a 64-bit > environment. In a sense, it shouldn't take ANY migration work at all, > if the programmer paid attention to the difference between pointer > sizes and integer sizes. But, there is a lot of sloppy code out there > that assumes a 32-bit object, and that's an erroneous assumption, as > 9+ years of experience with Alpha has shown. I submit that this may > prove to be more interesting/lucrative than twiddling bits on a > small system. But, that's strictly MHO. Speaking for myself, I find the whole "let's migrate to a 64-bit architecture" issue to be a little bit unexciting. As you implied, most of the problems in this space are going to involve dealing with (frequently bad) assumptions that other programmers made. Bleh. (coincidently, the <thing> that I work on originally was developed on ILP32, the "port" to LP64 was trivial, since I paid attention to details...) "All the world is a VAX" is no longer true... But being somebody who finds the internal workings of compilers fascinating, the Itanium's capability for speculative execution, instruction predication, parallel operations, etc. make this architecture terribly interesting. IMHO, Derek can't go wrong by examining any of the issues associated with x86 assembly language, or the Itanium spiffy new features, etc. Regards, --kevin -- "If it doesn't have 36 bits, you're not playing with a full DEC!" (seen printed on a tee-shirt at a trade show) ***************************************************************** To unsubscribe from this list, send mail to [EMAIL PROTECTED] with the text 'unsubscribe gnhlug' in the message body. *****************************************************************
