October 2010 - mpiwg-fortran - mailman3.cels.anl.gov

Re: [MPI3 Fortran] Results of recent J3 Fortran meeting
by Bill Long 21 Oct '10

21 Oct '10

N.M. Maclaren wrote: > On Oct 21 2010, Bill Long wrote: >>> Except for the last sentence, that is true. But one of MPI's major >>> requirements is that it should be able to handle Fortran default types, >>> and NOT force every program to use the C-interoperability KINDs to >>> call MPI! Sorry, but there IS an issue. >>> >> OK, I agree that there is a general issue for MPI with non-interoperable >> types. We have a type code for that - CFI_type_unspecified. I assume >> that, if the MPI routines are expecting data objects of Fortran types >> that have no corresponding C types (and hence there is little that can >> be done with them in C other than memory copies) then the actual intent >> is to only make memory copies. In that case, knowing the size of a >> single character is unimportant. All you need is the base_addr, >> elem_len, rank, and dim[] information. > > That is true, but why do you assume that they have no corresponding C > types? C90 had a fixed number of integer types, but C99 has an arbitrary > number. It is also possible to translate between any number of bytes > and an integer/character in C - all you need to know is how many there > are. I am assuming that the interoperable types are the ones we say are interoperable in Table 15.2 of the Fortran standard (and in the corresponding table in the TR). If the table is missing some entries for types that correspond between Fortran and C, then we can expand the table. The sort of games you can play with bits inside C is separate from interoperability of interfaces. > > What I said at the beginning, and which was my point, is that this approach > is the least FUTURE-PROOF of the approaches, not that it was incompatible > with the existing interoperability design. And one of the things that I > hope Fortran has learnt is that assuming that requirements aren't going to > become important is a mistake. It isn't possible to design for everything, > but maximising the flexibility is definitely good. I think we have good flexibility. The table of interoperable types is expandable, and we (with TYPE(*)) have provisions for non-interoperable types. Flexibility is not the only goal. Another design goal is to avoid internal inconsistency and contradictions. The rank expansion scheme fails that goal. Cheers, Bill > > Regards, > Nick Maclaren. > > _______________________________________________ > mpi3-fortran mailing list > mpi3-fortran(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran -- Bill Long longb(a)cray.com Fortran Technical Support & voice: 651-605-9024 Bioinformatics Software Development fax: 651-605-9142 Cray Inc./Cray Plaza, Suite 210/380 Jackson St./St. Paul, MN 55101

1 0

Re: [MPI3 Fortran] Results of recent J3 Fortran meeting
by N.M. Maclaren 21 Oct '10

21 Oct '10

On Oct 21 2010, Bill Long wrote: >> >> Except for the last sentence, that is true. But one of MPI's major >> requirements is that it should be able to handle Fortran default types, >> and NOT force every program to use the C-interoperability KINDs to >> call MPI! Sorry, but there IS an issue. >> > >OK, I agree that there is a general issue for MPI with non-interoperable >types. We have a type code for that - CFI_type_unspecified. I assume >that, if the MPI routines are expecting data objects of Fortran types >that have no corresponding C types (and hence there is little that can >be done with them in C other than memory copies) then the actual intent >is to only make memory copies. In that case, knowing the size of a >single character is unimportant. All you need is the base_addr, >elem_len, rank, and dim[] information. That is true, but why do you assume that they have no corresponding C types? C90 had a fixed number of integer types, but C99 has an arbitrary number. It is also possible to translate between any number of bytes and an integer/character in C - all you need to know is how many there are. What I said at the beginning, and which was my point, is that this approach is the least FUTURE-PROOF of the approaches, not that it was incompatible with the existing interoperability design. And one of the things that I hope Fortran has learnt is that assuming that requirements aren't going to become important is a mistake. It isn't possible to design for everything, but maximising the flexibility is definitely good. Regards, Nick Maclaren.

1 0

Re: [MPI3 Fortran] Results of recent J3 Fortran meeting
by Bill Long 21 Oct '10

21 Oct '10

N.M. Maclaren wrote: > On Oct 21 2010, Bill Long wrote: >> We currently interoperate only with C's char type. On the Fortran side, >> the interoperable declaration is character(kind=c_char). Fortran's >> default character kind is irrelevant. And sizeof(char) is 1. So there >> is no issue here. > > Except for the last sentence, that is true. But one of MPI's major > requirements is that it should be able to handle Fortran default types, > and NOT force every program to use the C-interoperability KINDs to > call MPI! Sorry, but there IS an issue. > OK, I agree that there is a general issue for MPI with non-interoperable types. We have a type code for that - CFI_type_unspecified. I assume that, if the MPI routines are expecting data objects of Fortran types that have no corresponding C types (and hence there is little that can be done with them in C other than memory copies) then the actual intent is to only make memory copies. In that case, knowing the size of a single character is unimportant. All you need is the base_addr, elem_len, rank, and dim[] information. The origin of CFI_type_unspecified is to provide a type code in the case that the actual argument is TYPE(*). If you want to pass a non-interoperable kind of character to a C function, you can write the Fortran interface with a TYPE(*) argument. If the rest of the declaration requires a C descriptor pointer in the C prototype, then the contents of that descriptor will look just like the one I'm proposing for the interoperable character kind, except that the type code will be CFI_type_unspecified, rather than CFI_type_char. The base_addr, elem_len, rank, and dim[] information will be correct and the MPI memory copies should work just fine. In fact, consistency in the way character arguments are passed to CHARACTER(kind-C_CHAR) dummies and to TYPE(*) dummies is yet another argument against the rank modification scheme. Cheers, Bill -- Bill Long longb(a)cray.com Fortran Technical Support & voice: 651-605-9024 Bioinformatics Software Development fax: 651-605-9142 Cray Inc./Cray Plaza, Suite 210/380 Jackson St./St. Paul, MN 55101

1 0

Re: [MPI3 Fortran] Results of recent J3 Fortran meeting
by N.M. Maclaren 21 Oct '10

21 Oct '10

On Oct 21 2010, Bill Long wrote: >>> >>> As noted earlier, this is currently an academic issue since the only >>> interoperable character is char. ... >> >> You have completely missed the point. I am not assuming any type other >> than Fortran default CHARACTER. There are compilers where you have a >> options like -ASCII and -UNICODE, which control which character code >> Fortran uses for its default characters. I can't offhand remember which, >> as I wasn't very interested, but I have seen more than one. >> >> So a new type code in the Interoperability specification doesn't help, >> because the interface type is default CHARACTER in both cases. > >We currently interoperate only with C's char type. On the Fortran side, >the interoperable declaration is character(kind=c_char). Fortran's >default character kind is irrelevant. And sizeof(char) is 1. So there >is no issue here. Except for the last sentence, that is true. But one of MPI's major requirements is that it should be able to handle Fortran default types, and NOT force every program to use the C-interoperability KINDs to call MPI! Sorry, but there IS an issue. Regards, Nick Maclaren.

1 0

Re: [MPI3 Fortran] Results of recent J3 Fortran meeting
by Bill Long 21 Oct '10

21 Oct '10

N.M. Maclaren wrote: > On Oct 21 2010, Bill Long wrote: >> Not sure where compiler options come in here, but... >> >> As noted earlier, this is currently an academic issue since the only >> interoperable character is char. ... > > You have completely missed the point. I am not assuming any type other > than Fortran default CHARACTER. There are compilers where you have a > options like -ASCII and -UNICODE, which control which character code > Fortran uses for its default characters. I can't offhand remember which, > as I wasn't very interested, but I have seen more than one. > > So a new type code in the Interoperability specification doesn't help, > because the interface type is default CHARACTER in both cases. > We currently interoperate only with C's char type. On the Fortran side, the interoperable declaration is character(kind=c_char). Fortran's default character kind is irrelevant. And sizeof(char) is 1. So there is no issue here. Cheers, Bill > If I can't tell how big a character is from the descriptor, I can't > write C (i.e. the MPI interface) that will work for both. And that's > the requirement - having to have different libraries for different > compiler options is a PAIN. > > Another point here is that I can do this for numeric units, if a compiler > switches between 4-byte INTEGER and REAL (and 8-byte D.P.) and 8-byte > INTEGER and REAL (and 16-byte D.P.) But I can't do it for CHARACTER > with that approach. > > > Regards, > Nick Maclaren > > > > > _______________________________________________ > mpi3-fortran mailing list > mpi3-fortran(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran -- Bill Long longb(a)cray.com Fortran Technical Support & voice: 651-605-9024 Bioinformatics Software Development fax: 651-605-9142 Cray Inc./Cray Plaza, Suite 210/380 Jackson St./St. Paul, MN 55101

1 0

Re: [MPI3 Fortran] Results of recent J3 Fortran meeting
by N.M. Maclaren 21 Oct '10

21 Oct '10

On Oct 21 2010, Bill Long wrote: > >Not sure where compiler options come in here, but... > >As noted earlier, this is currently an academic issue since the only >interoperable character is char. ... You have completely missed the point. I am not assuming any type other than Fortran default CHARACTER. There are compilers where you have a options like -ASCII and -UNICODE, which control which character code Fortran uses for its default characters. I can't offhand remember which, as I wasn't very interested, but I have seen more than one. So a new type code in the Interoperability specification doesn't help, because the interface type is default CHARACTER in both cases. If I can't tell how big a character is from the descriptor, I can't write C (i.e. the MPI interface) that will work for both. And that's the requirement - having to have different libraries for different compiler options is a PAIN. Another point here is that I can do this for numeric units, if a compiler switches between 4-byte INTEGER and REAL (and 8-byte D.P.) and 8-byte INTEGER and REAL (and 16-byte D.P.) But I can't do it for CHARACTER with that approach. Regards, Nick Maclaren

1 0

Re: [MPI3 Fortran] Results of recent J3 Fortran meeting
by Bill Long 21 Oct '10

21 Oct '10

N.M. Maclaren wrote: > On Oct 21 2010, Bill Long wrote: >>> On Oct 21 2010, Bill Long wrote: >>>> I've lost track of the choice numbers, but if there is no need for >>>> characters other that C's char, then the simplest solution (for both >>>> the user and the TR) is to treat character arrays passed by descriptor >>>> like any other arrays passed by descriptor. The type would be char, and >>>> the dimension information (dim[] member) corresponds to the Fortran >>>> dimensions. The elem_len field contains the array element length. >>>> Because sizeof(char) is 1, the character length parameter is equal to >>>> the elem_len value, so the character len value is directly available. >>> It is also the least future-resistant, which is matter of considerable >>> concern. >> Not really. The size of the array element in a character array will >> always have a known relationship to the number of characters in the >> variable. > > But not necessarily one known to the C - that's a fairly common option > in Fortran compilers, and one common requirement is to have a single > (C-based) library for a range of Fortran compiler options. > Not sure where compiler options come in here, but... >> For ASCII characters, the relationship is trivial (equal), >> but it we later wanted to add support for 32-bit characters, the factor >> of 4 is well known. ... > > That's only one possibility. Now consider this one. > > I write some C code to handle characters, without actually doing > anything very much with them except passing them around. However, I do > need to know how big a single character is, because some interfaces > have specifications that ask for each of the characters from a 'string' > in order and/or I occasionally have to translate to and from the code I > use in my C. My code will work irrespective of the size of characters, > provided only that I know what it is. That approach conflates a > CHARACTER(LEN=4) of 1-byte characters with a CHARACTER(LEN=1) of 4-byte > ones. > As noted earlier, this is currently an academic issue since the only interoperable character is char. If, in the future, we support interoperability of a different character kind, then we would need to add a new type code (CFI_type_whcar, in addition to CFI_type_char). If the programmer wanted to do anything interesting with the characters, the type value needs to be checked anyway. From the type code, the user could infer the size of an individual character. So the problem is solvable, and straightforwardly so. I think it is overkill to add a separate member to the struct just to hold the character size. The small extra code required to extract the len parameter from already available information is better than adding cruft that is unnecessary in 99% of the cases. And either option is better than conflating the KIND and RANK. Cheers, Bill > Indeed, I have come close to describing MPI's MPI_CHARACTER support in > the above! > > > Regards, > Nick Maclaren. > > _______________________________________________ > mpi3-fortran mailing list > mpi3-fortran(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran -- Bill Long longb(a)cray.com Fortran Technical Support & voice: 651-605-9024 Bioinformatics Software Development fax: 651-605-9142 Cray Inc./Cray Plaza, Suite 210/380 Jackson St./St. Paul, MN 55101

1 0

Re: [MPI3 Fortran] Results of recent J3 Fortran meeting
by N.M. Maclaren 21 Oct '10

21 Oct '10

On Oct 21 2010, Bill Long wrote: > >> On Oct 21 2010, Bill Long wrote: >>> I've lost track of the choice numbers, but if there is no need for >>> characters other that C's char, then the simplest solution (for both >>> the user and the TR) is to treat character arrays passed by descriptor >>> like any other arrays passed by descriptor. The type would be char, and >>> the dimension information (dim[] member) corresponds to the Fortran >>> dimensions. The elem_len field contains the array element length. >>> Because sizeof(char) is 1, the character length parameter is equal to >>> the elem_len value, so the character len value is directly available. >> >> It is also the least future-resistant, which is matter of considerable >> concern. > >Not really. The size of the array element in a character array will >always have a known relationship to the number of characters in the >variable. But not necessarily one known to the C - that's a fairly common option in Fortran compilers, and one common requirement is to have a single (C-based) library for a range of Fortran compiler options. > For ASCII characters, the relationship is trivial (equal), >but it we later wanted to add support for 32-bit characters, the factor >of 4 is well known. ... That's only one possibility. Now consider this one. I write some C code to handle characters, without actually doing anything very much with them except passing them around. However, I do need to know how big a single character is, because some interfaces have specifications that ask for each of the characters from a 'string' in order and/or I occasionally have to translate to and from the code I use in my C. My code will work irrespective of the size of characters, provided only that I know what it is. That approach conflates a CHARACTER(LEN=4) of 1-byte characters with a CHARACTER(LEN=1) of 4-byte ones. Indeed, I have come close to describing MPI's MPI_CHARACTER support in the above! Regards, Nick Maclaren.

1 0

Re: [MPI3 Fortran] Results of recent J3 Fortran meeting
by Bill Long 21 Oct '10

21 Oct '10

N.M. Maclaren wrote: > On Oct 21 2010, Bill Long wrote: >> I've lost track of the choice numbers, but if there is no need for >> characters other that C's char, then the simplest solution (for both the >> user and the TR) is to treat character arrays passed by descriptor like >> any other arrays passed by descriptor. The type would be char, and the >> dimension information (dim[] member) corresponds to the Fortran >> dimensions. The elem_len field contains the array element length. >> Because sizeof(char) is 1, the character length parameter is equal to >> the elem_len value, so the character len value is directly available. > > It is also the least future-resistant, which is matter of considerable > concern. > Not really. The size of the array element in a character array will always have a known relationship to the number of characters in the variable. For ASCII characters, the relationship is trivial (equal), but it we later wanted to add support for 32-bit characters, the factor of 4 is well known. If the user only wants to move the data, then the only relevant value is the elem_len anyway. If they want to cast the pointer to a local bigchar type, then one additional line, len = elem_len/4, trivially gets the length. This is certainly simpler, and conceptually more acceptable, than adding dimensions and making believe that character variables are really arrays. This is only future-resistant if the size of the future character representation is not an integer multiple of the size of char. If that is the case, then far worse issues arise. Cheers, Bill > > Regards, > Nick Maclaren. > > > _______________________________________________ > mpi3-fortran mailing list > mpi3-fortran(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran -- Bill Long longb(a)cray.com Fortran Technical Support & voice: 651-605-9024 Bioinformatics Software Development fax: 651-605-9142 Cray Inc./Cray Plaza, Suite 210/380 Jackson St./St. Paul, MN 55101

1 0

Re: [MPI3 Fortran] Results of recent J3 Fortran meeting
by N.M. Maclaren 21 Oct '10

21 Oct '10

On Oct 21 2010, Bill Long wrote: > >I've lost track of the choice numbers, but if there is no need for >characters other that C's char, then the simplest solution (for both the >user and the TR) is to treat character arrays passed by descriptor like >any other arrays passed by descriptor. The type would be char, and the >dimension information (dim[] member) corresponds to the Fortran >dimensions. The elem_len field contains the array element length. >Because sizeof(char) is 1, the character length parameter is equal to >the elem_len value, so the character len value is directly available. It is also the least future-resistant, which is matter of considerable concern. Regards, Nick Maclaren.

1 0