Very Computer

    I'm curious if anyone has any opinions on the best way to get existing
32-bit UNIX code ready for forthcoming 64-bit OSes and processors. What I've
been thinking about doing is requiring that code be changed to tolerate both
ILP32 and LP64 models. This seems to me to be both realistically doable as
well as sufficient.

    It seems to me that 64-bit int's will likely be a loss overall.
Presumably, 64-bit processors will be able to manipulate 32-bit quantities
about as fast as they can manipulate 32-bit quantities and any possible loss
will be made up for by the benefits of smaller structures easing memory
bandwidth usage.

    I don't really want to start a religious war. I'm just looking for
practical suggestions about how to draft coding standards so that code will
work with minimal pain on future platforms.

    DS

Quote:>     I'm curious if anyone has any opinions on the best way to get
> existing 32-bit UNIX code ready for forthcoming 64-bit OSes and
> processors.

Are there any ILP64 platforms?

/fc

Quote:> been thinking about doing is requiring that code be changed to tolerate both
> ILP32 and LP64 models. This seems to me to be both realistically doable as
> well as sufficient.

>     It seems to me that 64-bit int's will likely be a loss overall.
> Presumably, 64-bit processors will be able to manipulate 32-bit quantities
> about as fast as they can manipulate 32-bit quantities and any possible loss
> will be made up for by the benefits of smaller structures easing memory
> bandwidth usage.

>     I don't really want to start a religious war. I'm just looking for
> practical suggestions about how to draft coding standards so that code will
> work with minimal pain on future platforms.

Fixing up old code can be a real PITA, though.  Your best bet might be
to compile it with a compiler that generates warnings for 64-bit
unsafe things.  Supplement with heavy testing, of course.

--
M?ns Rullg?rd

Quote:> >     I'm curious if anyone has any opinions on the best way to get
> > existing 32-bit UNIX code ready for forthcoming 64-bit OSes and
> > processors.
> ISTM Sun has already produced a lot of documentation addressing this.
> I would use that as a starting point.

Quote:> Are there any ILP64 platforms?

    DS

http://docs.sun.com/db/doc/806-0477?q=lp64&a=load

Joe

A handful of rare ones.  Of the platforms X11/XFree86 has been ported
to, the only ifdef for ILP64 mode is for CRAY - there's a sizable list
for LP64 mode though.  There was also a short lived custom port of
Solaris using ILP64 that HaL did for their SPARC64 machines before Sun
came out with the LP64 support in Solaris.

--
________________________________________________________________________


  Working for, but definitely not speaking for, Sun Microsystems, Inc.

Quote:> Fixing up old code can be a real PITA, though.

RFM
--
To reply, translate domain from l33+ 2p33|< to alpha.
                4=a  0=o  3=e  +=t

Quote:> > Fixing up old code can be a real PITA, though.
> I've never had problems, and most of the code I've ported to make 64-bit
> safe is kernel code (device drivers and big chunks of the real kernel on
> AIX and Solaris).  If you start out with poorly written code --
> especially code that makes assumptions about sizeof(int) == sizeof(*void)
> -- then you'll have a bit of a headache, but even these are not too hard
> to find if you pay attention to compiler warning output.

    DS

- Bill

I worked with a sizable X/Motif code base that had worked for several
years just fine on 64bit OSF/DEC/HP... systems as well as various
flavors of 32 bit systems including IRIX.  We did a port to IRIX64 and
ran into a bunch of crash problems in the GUI code.  It turned out that
the GUI code had a lot of cases where it fetched (int) values from
widgets (XmNuserData) into (int) fields.  XmNuserData stores an
XtPointer type so that it can hold the address of data.  But it's used
a lot to store integer values.  So, we had a lot of code that
implicitly assumed that sizeof(int) == sizeof(void *).

It worked on OSF because the correct 32 bits were mapped between the
two locations and the other 32 bits never clobbered anything
symptomatically.  On IRIX64 you set and got back the wrong 32 bits and
the code didn't validate values when they were returned so we got
crashes.  Not because of the overlooked extra 32 bits but later when
the values returned were unexpected.

-- ced

--
Chuck Dillon
Senior Software Engineer
NimbleGen Systems Inc.