Upcoming Events
Southwest Gaming Expo
11/20 - 11/22 @ Dallas, TX

Workshop on Network and Systems Support for Games (NetGames 2009)
11/23 - 11/25 @ Paris, France

ICIDS 2009 Interactive Storytelling
12/9 - 12/11 @ Guimarães, Portugal

Global Game Jam
1/29 - 1/31  

More events...


Quick Stats
6926 people currently visiting GDNet.
2341 articles in the reference section.

Help us fight cancer!
Join SETI Team GDNet!



Link to us

Link to us

  Intel sponsors gamedev.net search:   

20 issues of porting C++ code on the 64-bit platform


Miscellaneous

Error diagnosis

The diagnosis of the errors occurring while porting 32-bit programs on 64-bit systems is a difficult task. The port of a not very quality code written without taking into account peculiarities of other architectures, may demand a lot of time and efforts. That’s why we’ll pay some attention to the description of methods and means which may simplify this task.

Unit test

Unit test have fought well-earned respect among programmers long ago. Unit tests will help to check the correctness of the program after the port on a new platform. But there is one nuance which you should keep in mind.

Unit test may not allow you to check the new ranges of input values which become accessible on 64-bit systems. Unit tests are originally developed in such a way that they can be passed in a short time. And the function which usually works with an array with the size of tens of Mb, will probably process tens of Kb in unit tests. It is justified for this function in tests may be called many times with different sets of input values. But suppose you have a 64-bit variant of the program. And now the function we study is processing more than 4 Gb of data. Surely there appears a necessity to raise the input size of an array in the tests either up to sizes more than 4 Gb. The problem is that the time of passing the tests will increase greatly in such a case.

That’s why while modifying the sets of tests keep in mind the compromise between speed of passing unit tests and the fullness of the checks. Fortunately, there are other methods which can help you to make sure of the efficiency of your applications.

Code review

Code review is the best method of searching errors and improving code. Combined thorough code review may help to get rid of the errors in the program completely which are related to the peculiarities of the development of 64-bit applications. Of course, in the beginning one should learn which errors exactly one should search, otherwise the review won’t give good results. For this purpose it is necessary to read this and other articles devoted to the port of programs from 32-bit systems on 64-bit ones, in time. Some interesting links concerning this topic can be found in the end of the article.

But this approach to the analysis of the original code has on significant disadvantage. It demands a lot of time and because of this it is actually inapplicable on large projects.

The compromise is the use of static analyzers. A static analyzer can be considered to be an automated system for code review where a fetch of potentially dangerous places is created for a programmer so that he could carry out the further analysis.

But in any case it is desirable to provide several code reviews for combined teaching the team to search for new kinds of errors occurring on 64-bit systems.

Built-in means of compilers

Compilers allow to solve some problems of searching defect code. They often have built-in different mechanisms for diagnosing errors observed. For example, in Microsoft Visual C++ 2005 the following keys may be useful: /Wp64, /Wall, and in SunStudio C++ key –xport64.

Unfortunately, the possibilities they provide are often not enough and you should not rely only on them. But in any case it is highly recommended to enable the corresponding options of a compiler for diagnosing errors in the 64-bit code.

Static analyzers

Static analyzers are a fine means to improve quality and safety of the program code. The basic difficulty related to the use of static analyzers consists in the fact that they generate quite a lot false warning messages about potential errors. Programmers being lazy by nature use this argument to find some way not to correct the found errors. In Microsoft this problem is solved by including necessarily the found errors in the bug tracking system. Thus a programmer just cannot choose between the correction of the code and tries to avoid this.

We think that such strict rules are justified. The profit of the quality code covers the outlay of time for static analysis and corresponding code modification. This profit is achieved by means of simplifying the code support and reducing the time of debugging and testing.

Static analyzers may be successfully used for diagnosing many of the kinds of errors observed in the article.

The authors know 3 static analyzers which are supposed to have means of diagnosing errors related to the port of programs on 64-bit systems. We would like to warn you at once that we may be mistaken about the possibilities they have, moreover, these are developing products and new versions may have great efficiency.

  1. Gimpel Software PC-Lint - This analyzer has a large list of supported platforms and is the static analyzer of general purpose. It allows to catch errors while porting program on the architecture with LP64 data model. The advantage is the possibility to organize strict control over the type conversions. What the disadvantages are concerned the only one of them is the absence of the environment but it may be corrected by using the external Riverblade Visual Lint.
  2. Parasoft C++test - Another well-know static analyzer of general purpose. It has the support of a lot of device and program platforms too. It has built-in environment which simplifies the work and setting of the analysis rules greatly. As well as PC-Lint it is intended for LP64 data model.
  3. Viva64 - Unlike other analyzers it is intended to work with Windows (LLP64) data model. It is integrated into the development environment Visual Studio 2005. It is intended only for diagnosing problems related to the port of programs on 64-bit systems and that simplifies its setting greatly.

Conclusion

If you read these lines we are glad that you’re interested. We hope the article has been useful for you and will help to simplify the development and debugging of 64-bit applications. We will be glad to receive your opinions, remarks, corrections, additions and will surely include them in the next version of the article. The more we’ll describe typical errors the more profitable will be the use of our experience and getting help.

For more articles of the same, please visit our website.

Resources

  1. Chandra Shekar. Extend your application's reach from 32-bit to 64-bit environments
  2. Converting 32-bit Applications Into 64-bit Applications: Things to Consider
  3. Andrew Josey. Data Size Neutrality and 64-bit Support
  4. Harsha S. Adiga. Porting Linux applications to 64-bit systems
  5. Transitioning C and C++ programs to the 64-bit data model
  6. Porting an Application to 64-bit Linux on HP Integrity Servers
  7. Stan Murawski. Beyond Windows XP: Get Ready Now for the Upcoming 64-Bit Version of Windows
  8. Steve Graegert. 64-bit Data Models Explained
  9. Updating list of resources devoted to the development of 64-bit applications



Contents
  Introduction
  Issues 1-4
  Issues 5-9
  Issues 10-14
  Issues 15-20
  Conclusion

  Printable version
  Discuss this article