Opinions on getting existing code 64-bit ready

[David Schwartz]

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

[Frank Cusack]

On Thu, 3 Jul 2003 18:51:16 -0700 "David Schwartz" <davids@webmaster.com> wrote:

> 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.

Are there any ILP64 platforms?

/fc

[Måns Rullgård]

"David Schwartz" <davids@webmaster.com> writes:

> 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

Forthcoming? They've been around for a decade.

> 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.

It's rather easy when writing new code. Whenever you require a
particular size for a variable, use one of the intXX_t types. Never
cast a pointer to an integer and expect to be able to get back the
right value.

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
[email]mru@users.sf.net[/email]

[David Schwartz]

"Frank Cusack" <fcusack@fcusack.com> wrote in message
news:x5y65mj2brf.fsf@vger.corp.google.com...

> On Thu, 3 Jul 2003 18:51:16 -0700 "David Schwartz" <davids@webmaster.com>

wrote:

> > 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.

I only found a few FAQs that seemed to suggest that supporting both
ILP32 and LP64 would be the best way to go.

> Are there any ILP64 platforms?

Not that I know of.

DS

[joe@invalid.address]

"David Schwartz" <davids@webmaster.com> writes:

> "Frank Cusack" <fcusack@fcusack.com> wrote in message
> news:x5y65mj2brf.fsf@vger.corp.google.com...
>

> > On Thu, 3 Jul 2003 18:51:16 -0700 "David Schwartz"
> > <davids@webmaster.com>

> wrote:
>

> > > 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.

>
> I only found a few FAQs that seemed to suggest that supporting
> both ILP32 and LP64 would be the best way to go.

I don't know if you saw this, but it might have some relevant things
in it.

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

Joe

[Bjorn Reese]

Frank Cusack wrote:

> Are there any ILP64 platforms?

IIRC, Cray C90 was an ILP64 platform.

[Alan Coopersmith]

Frank Cusack <fcusack@fcusack.com> writes in comp.unix.programmer:
|Are there any ILP64 platforms?

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.

--
__________________________________________________ ______________________
Alan Coopersmith [email]alanc@alum.calberkeley.org[/email]
[url]http://www.CSUA.Berkeley.EDU/~alanc/[/url] aka: [email]Alan.Coopersmith@Sun.COM[/email]
Working for, but definitely not speaking for, Sun Microsystems, Inc.

[Fritz M]

[email]mru@users.sf.net[/email] (Måns Rullgård) wrote:

> Forthcoming? They've been around for a decade.

I thought the same thing, but then it occurred to me that the original
poster is probably living in the world of Intel and AMD.

> 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.

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

[David Schwartz]

"Fritz M" <news@m4s0n3r.n3+> wrote in message
news:Xns93B260041A5B6fritz2masonernet@139.187.81.1 ...

> [email]mru@users.sf.net[/email] (Måns Rullgård) wrote:

> > Forthcoming? They've been around for a decade.

> I thought the same thing, but then it occurred to me that the original
> poster is probably living in the world of Intel and AMD.

More Intel, AMD, MIPS, and R10K. The only 64-bit OS I've used, other
than Solaris, is OSF1.

> > 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.

Yeah, but is it okay to replace that with code that assumes
sizeof(long)==sizeof(void*)? That makes things easier than more general
fixes.

DS

[William Ahern]

David Schwartz <davids@webmaster.com> wrote:

> "Fritz M" <news@m4s0n3r.n3+> wrote in message

>> 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.

>
> Yeah, but is it okay to replace that with code that assumes
> sizeof(long)==sizeof(void*)? That makes things easier than more general
> fixes.

use intptr_t instead. if it's available, it'll be the proper type. if its
not, then your code won't silently break.

- Bill