Bug #89

64 bit version

Added by Mark Maunder almost 3 years ago. Updated about 2 years ago.

Status:In ProgressStart date:05/14/2012
Priority:NormalDue date:
Assignee:John Sibert% Done:

0%

Category:ADMB 11
Target version:-

Description

Make sure the 64 bit versions work
Chnage long to longlong

History

#1 Updated by John Sibert over 2 years ago

  • Status changed from New to In Progress
  • Start date changed from 03/20/2012 to 05/14/2012

I can make and test changes under linux, but will need some help with windows versions.

#2 Updated by John Sibert over 2 years ago

Johnoel pointed out the following link http://www.viva64.com/en/a/0004/

From Table N2, I'm guessing the current 4Gb file size limit fix works for linux systems but may not work in windows.

The viva64 site lists 20 issues converting to 64 bit code. I've added a star to the ones I think might be a problem in ADMB.

1. Disabled warnings
2. Use of functions with a variable number of arguments
3. Magic numbers
4. Storing integers in double type
5. Bit shifting operations
*6. Storing of pointer addresses
7. Memsize types in unions
8. Changing an array type
9. Virtual functions with arguments of memsize type
10. Serialization and data exchange
11. Bit fields
*12. Pointer address arithmetic
*13. Arrays indexing
14. Mixed use of simple integer types and memsize types
15. Implicit type conversions while using functions
16. Overloaded functions
17. Data alignment
18. Exceptions
19. Using outdated functions and predefined constants
*20. Explicit type conversions

#3 Updated by John Sibert about 2 years ago

Integer types

A signed 32 bit integer ranges from −2,147,483,648 to +2,147,483,647, and an unsigned 32 bit integer ranges from 0 to 4,294,967,295. This is the so-called 2Gb file size limit on 32 bit systems.

A signed 64 bit integer ranges from −9,223,372,036,854,775,808 to +9,223,372,036,854,775,807, and an unsigned 64 bit integer ranges from 0 to 18,446,744,073,709,551,615.

Integer types for 64 bit computing vary between operating systems and compilers. The following is a quote from a Wikipedia (http://en.wikipedia.org/wiki/64-bit_computing) entry:

64-bit data models

In 32-bit programs, pointers and data types such as integers generally have the same length; this is not necessarily true on 64-bit machines. Mixing data types in programming languages such as C and its descendants such as C++ and Objective-C may thus function on 32-bit implementations but not on 64-bit implementations.

In many programming environments for C and C-derived languages on 64-bit machines, "int" variables are still 32 bits wide, but long integers and pointers are 64 bits wide. These are described as having an LP64 data model. Another alternative is the ILP64 data model in which all three data types are 64 bits wide, and even SILP64 where "short" integers are also 64 bits wide.[citation needed] However, in most cases the modifications required are relatively minor and straightforward, and many well-written programs can simply be recompiled for the new environment without changes. Another alternative is the LLP64 model, which maintains compatibility with 32-bit code by leaving both int and long as 32-bit. "LL" refers to the "long long integer" type, which is at least 64 bits on all platforms, including 32-bit environments. 64-bit data models:

Data model short int long long long pointers/size_t Sample operating systems
LLP64/
IL32P64 16 32 32 64 64 Microsoft Windows (X64/IA-64)
LP64/
I32LP64 16 32 64 64 64 Most Unix and Unix-like systems, e.g. Solaris, Linux, and Mac OS X; z/OS
ILP64 16 64 64 64 64 HAL Computer Systems port of Solaris to SPARC64
SILP64 64 64 64 64 64 Unicos

Many 64-bit compilers today use the LP64 model (including Solaris, AIX, HP-UX, Linux, Mac OS X, FreeBSD, and IBM z/OS native compilers). Microsoft's Visual C++ compiler uses the LLP64 model. The disadvantage of the LP64 model is that storing a long into an int may overflow. On the other hand, casting a pointer to a long will work. In the LLP model, the reverse is true. These are not problems which affect fully standard-compliant code, but code is often written with implicit assumptions about the widths of integer types.

Note that a programming model is a choice made on a per-compiler basis, and several can coexist on the same OS. However, the programming model chosen as the primary model for the OS API typically dominates.

Another consideration is the data model used for drivers. Drivers make up the majority of the operating system code in most modern operating systems[citation needed] (although many may not be loaded when the operating system is running). Many drivers use pointers heavily to manipulate data, and in some cases have to load pointers of a certain size into the hardware they support for DMA. As an example, a driver for a 32-bit PCI device asking the device to DMA data into upper areas of a 64-bit machine's memory could not satisfy requests from the operating system to load data from the device to memory above the 4 gigabyte barrier, because the pointers for those addresses would not fit into the DMA registers of the device. This problem is solved by having the OS take the memory restrictions of the device into account when generating requests to drivers for DMA, or by using an IOMMU.

A object of type long is interpreted as 64 bits on unix-like systems and as 32 bits on Windows systems. Objects of type long long are interpreted as 64 bits on all platforms. Therefore variables that really need to have 64bit precision such as indices to ADMB temporary buffers for derivative information and file indices should be of type long long.

Also available in: Atom PDF