-----Original Message-----
From: Jeff Hill
[mailto:[email protected]]
Sent: Wednesday,
November 02, 2005 2:58 PM
To: 'Eric Norum'; 'Ernest L.
Williams Jr.'
Cc: 'Marty Kraimer'; 'Andrew
Johnson'; 'Janet Anderson'; [email protected]
Subject: RE: R3.14.8 testing
Ø I
don't see this as an argument for making 'long' a 64-bit type. It's an argument
for 64-bit pointers, yes,
Ø but
I think that making 'sizeof(long)==8' is a separate issue.
There may be compiler switches that
provide sizeof(long)==4, but I expect that the defacto standard compiler
default will eventually be sizeof(long)==8.
I can think of some reasons why that
default might become ubiquitous, but my opinion doesn’t matter. You can
take that issue up with the compiler vendors.
IMHO the important issue for EPICS
developers is instead this: should we define an EPICS base default which
requires EPICS applications to compile with a non-standard sizeof(long)
default. The downside is that if the users inadvertently take the compiler
default an incomprehensible crash will occur.
Jeff
-----Original Message-----
From: Eric Norum
[mailto:[email protected]]
Sent: Wednesday,
November 02, 2005 2:24 PM
To: Ernest L. Williams Jr.
Cc: Marty Kraimer; Andrew Johnson;
Janet Anderson; Jeff Hill
Subject: Re: R3.14.8 testing
On Nov 2, 2005, at 2:59 PM, Ernest L. Williams Jr. wrote:
We are moving to the use of linux-x86_64 and want to run native 64-bit
We want to take advantage of not only the AMD64 hardware but also the
larger address space which will be very useful for database
applications
and systems which have a lot of RAM e.g. our ChannelArchiver.
There is a very small performance penalty within the OS for translating
32-bit app to use the AMD64. Probably not much.
I don't see this as an argument for making 'long' a 64-bit type. It's
an argument for 64-bit pointers, yes, but I think that making 'sizeof(long)==8'
is a separate issue.
I seem to recall some earlier discussions where we had decided that
EPICS would use 'long long' where 64-bit integers were needed.
--
Eric Norum <[email protected]>
Advanced Photon Source
Argonne
National Laboratory
(630) 252-4793