64 bit architectures and C/C++
Jerry Gitomer
jerry at talos.npri.com
Thu May 2 00:50:15 AEST 1991
mvm at jedi.harris-atd.com (Matt Mahoney) writes:
:When I need to specify bits, I'm usually forced to make the
:following assumptions:
: char 8 bits
: short 16 bits
: long 32 bits
:since this is true on most machines. Anything else would probably break
:a lot of code.
We are caught between the rock (wanting to take *full* advantage of
the new wider register and memory data path machines 64 bits today,
128 tomorrow, and 256 the day after tomorrow) and the hard place
(wanting to preserve code that was handcrafted to the
idiosyncracies of prior generation hardware). Our choices are
simple -- throw the performance of the new machines out the window
or spend the time and money required to fix up the code so that it
complies with the standard. (Sure, standards aren't cast in
concrete, but their life exptancy exceeds that of today's typical
computer system).
IMHO (now isn't that an arrogant phrase? :-) ) it is better to fix
up the offending programs now than to do it later. I say this
because I presume that salaries will continue to increase, which
will make it more expensive to fix things up later, and because
staff turnover leads to a decrease over time in knowledge of the
offending programs.
--
Jerry Gitomer at National Political Resources Inc, Alexandria, VA USA
I am apolitical, have no resources, and speak only for myself.
Ma Bell (703)683-9090 (UUCP: ...uunet!uupsi!npri6!jerry )
More information about the Comp.lang.c
mailing list