Re: Declaration to get 8-bit (or 16-bit) integer?

Clive Page wrote:
Thanks to all of you who responded. I take the point made so forcefully by Richard Maine that the type definitions and specialised I/O routines need to be encapsulated in a module. I didn't mention this as I'd taken it as read, and my posting was already rather long.

Actually the encapsulation is a little less straight-forward it one has to include the run-time checks with BIT_SIZE that I put forward in my option (D), but on reflection perhaps this is just a bit over the top. The listing of current compiler properties on the very valuable website of Messrs Polyhedron shows that *every* compiler listed there supports both 8-bit and 16-bit integer types.

A simple solution (that I would recommend anyway) is to include a test suite with your code. This test suite would compile under the smae conditions as the library build and test the bit size stuff. If the tests fail, the user knows about it before he does anything with the library and, maybe, can try and fix it (i.e. different compiler switches, new compiler.. etc)


I'd also like to thank Arjen Markus for his clever coding of run-time checks for the desired sizes, which are certainly better than a run-time check.

The other topic I deliberately did not mention is that of endian differences, which can be a problem when using multi-byte integers. However with a single-byte data type I've always found it quite hard to distinguish between big-endian and little-endian systems, for some reason. :-)

Just use characters. If the byte sex is wrong the letters will be backwards. :o) Hard to tell for those symmetrical letters though....

But seriously, I use this for the multi-byte case:

MODULE Endian_Utility
USE Type_Kinds
IMPLICIT NONE
CONTAINS
FUNCTION Big_Endian()
INTEGER(Short) :: Source = 1_Short
LOGICAL :: Big_Endian
Big_Endian = .FALSE.
IF ( IACHAR(TRANSFER(Source,'a')) == 0 ) Big_Endian = .TRUE.
END FUNCTION Big_Endian
....
END MODULE Endian_Utility

EXAMPLE:
USE Endian_Utility
.....
WRITE( *, '( 5x, "Platform is " )', ADVANCE = 'NO' )
IF ( Big_Endian() ) THEN
WRITE( *, '( "big-endian." )' )
ELSE
WRITE( *, '( "litle-endian." )' )
END IF

It's worked for me on linux platforms (all the usual compilers), AIX, IRIX, and Sun Sparcs.

The conclusion I've drawn is that one ought to use SELECTED_INT_KIND for portability, and that this should work on every current Fortran system.
The main drawback is that it looks a bit cumbersome and the meaning is not all that obvious - but even so not too difficult to explain.

I use the following in my Type_Kinds module, adopting some common tersm that people seem to understand (e..g short, long, single, etc):

INTEGER, PARAMETER :: Byte = SELECTED_INT_KIND(1) ! Byte integer
INTEGER, PARAMETER :: Short = SELECTED_INT_KIND(4) ! Short integer
INTEGER, PARAMETER :: Long = SELECTED_INT_KIND(8) ! Long integer
INTEGER, PARAMETER :: LLong_t = SELECTED_INT_KIND(16) ! LLong integer
INTEGER, PARAMETER :: LLong = ((( 1 + SIGN(1,LLong_t)) / 2) * LLong_t) + &
((( 1 - SIGN(1,LLong_t)) / 2) * Long )
INTEGER, PARAMETER :: Single = SELECTED_REAL_KIND(6) ! Single precision
INTEGER, PARAMETER :: Double = SELECTED_REAL_KIND(15) ! Double precision
INTEGER, PARAMETER :: Quad_t = SELECTED_REAL_KIND(20) ! Quad precision
INTEGER, PARAMETER :: Quad = ((( 1 + SIGN(1,Quad_t)) / 2) * Quad_t) + &
((( 1 - SIGN(1,Quad_t)) / 2) * Double)

(LLong_t and Quad_t are private to the module)

I also include the *expected* byte size of each type. That sometimes comes in handy as well. Just about every piece of code I write USEs my Type_Kinds module. Made my life much easier and has worked flawlessly on all different platforms and compilers so far.

Now to a more difficult topic: how to get the effect of LOGICAL*1

What for? :o)

cheers,

paulv

--
Paul van Delst Ride lots.
CIMSS @ NOAA/NCEP/EMC Eddy Merckx
.

Relevant Pages

  • Re: Declaration to get 8-bit (or 16-bit) integer?
    ... Actually the encapsulation is a little less straight-forward it one has to include the run-time checks with BIT_SIZE that I put forward in my option, but on reflection perhaps this is just a bit over the top. ... The listing of current compiler properties on the very valuable website of Messrs Polyhedron shows that *every* compiler listed there supports both 8-bit and 16-bit integer types. ... This test suite would compile under the smae conditions as the library build and test the bit size stuff. ... Support the GNU GFortran Project: http://gcc.gnu.org/fortran/index.html ...
    (comp.lang.fortran)
  • Re: Python from Wise Guys Viewpoint
    ... acceptable by the compiler. ... >>They same holds for assertions as soon as they are run by the test suite. ... Maybe we both understand language implementation, ... type system is better. ...
    (comp.lang.python)
  • Re: Python from Wise Guys Viewpoint
    ... acceptable by the compiler. ... >>They same holds for assertions as soon as they are run by the test suite. ... Maybe we both understand language implementation, ... type system is better. ...
    (comp.lang.lisp)
  • Re: ARM IDE
    ... IAR's web site says they test with Plum Hall and Perennial - they don't give any results for these tests for their compilers. ... test suite is any better than an open source test suite, ... Most compiler companies have test suites for checking the build. ... They run all their internal tests and validation on these builds, just like for closed source tools. ...
    (comp.arch.embedded)
  • Re: C Compiler for 8051 microcontroler
    ... But my code does not include the compiler and validating it as ... compiler but could not afford to validate something like the SDCC. ... >The Plum Hall test suite requires licensing and hence it is not ... Hall and Perennial are the industry wide test suites. ...
    (comp.arch.embedded)