[mpi-22] FW: [mpi-21] Proposal: MPI_OFFSET built-in type

[Hubert Ritzdorf]

And the length of these datatypes in external32 representation
has to be defined if it should be allowed to read/write these
datatypes.

Hubert

Jeff Squyres wrote:
> Don't forget MPI::OFFSET (and MPI::AINT).
>
> And they should be const.  ;-)
>
>
> On Jan 24, 2008, at 12:55 PM, Rajeev Thakur wrote:
>
>   
>> Is it an interface change? It would be an addition to the set of  
>> predefined
>> types, such as MPI_INT, MPI_CHAR, so it should just work I think.
>>
>>     
>>>> MPI Datatype: MPI_OFFSET
>>>> Corresponding C type: long long int
>>>> Corresponding Fortran type: INTEGER(KIND=MPI_OFFSET_KIND)
>>>>         
>> The corresponding C type should be "implementation defined". It  
>> could be int
>> for example in an implementation that only supports 32-bit file sizes.
>>
>> Rajeev
>>
>>
>>     
>>> -----Original Message-----
>>> From: mpi-22-bounces_at_[hidden]
>>> [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Richard Graham
>>> Sent: Thursday, January 24, 2008 11:48 AM
>>> To: mpi-22_at_[hidden]
>>> Subject: Re: [mpi-22] FW: [mpi-21] Proposal: MPI_OFFSET built-in type
>>>
>>> Do you think this should go into 2.2 or 3.0 ?  I ask not
>>> because the change
>>> is large, but because it will change the signature of several
>>> interface
>>> functions (presumably marking the older functions as deprecated - for
>>> removal in X number of years).  There is another change that
>>> I would like to
>>> see added to the standard, which is adding a way to convey  
>>> information
>>> between MPI_Alloc_mem() to the functions using this memory,
>>> w/o forcing the
>>> implementations to try and use all sorts of non-portable
>>> solutions to figure
>>> out if this memory can be used "as-is" by the network layer,
>>> of if it needs
>>> to be "prepared" (pinned, and ?).
>>>
>>> It seems prudent to combine such interface changes into the
>>> smallest number
>>> of changes (1 is preferred).
>>>
>>> What do you think ?
>>> Rich
>>>
>>>
>>> On 1/24/08 12:18 PM, "Rajeev Thakur" <thakur_at_[hidden]> wrote:
>>>
>>>       
>>>> A similar one is needed for MPI_Aint.
>>>>
>>>> Rajeev
>>>>
>>>>         
>>>>> -----Original Message-----
>>>>> From: mpi-22-bounces_at_[hidden]
>>>>> [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Richard Graham
>>>>> Sent: Thursday, January 24, 2008 11:09 AM
>>>>> To: mpi-22_at_[hidden]
>>>>> Subject: [mpi-22] FW: [mpi-21] Proposal: MPI_OFFSET built-in type
>>>>>
>>>>> Moving this to the appropriate list.
>>>>>
>>>>> Rich
>>>>>
>>>>> ------ Forwarded Message
>>>>> From: Robert Latham <robl_at_[hidden]>
>>>>> Reply-To: "Mailing list for discussion of MPI 2.1"
>>>>> <mpi-21_at_[hidden]>
>>>>> Date: Thu, 24 Jan 2008 10:41:52 -0600
>>>>> To: <mpi-21_at_[hidden]>
>>>>> Subject: [mpi-21] Proposal: MPI_OFFSET built-in type
>>>>>
>>>>> I hope this is less contentious than adding 'const' keywords...
>>>>>
>>>>>
>>>>> I would like to propose a new built-in type MPI_OFFSET,
>>>>>           
>>> defined to be
>>>       
>>>>> a type corresponding to INTEGER(KIND=MPI_OFFSET_KIND) or MPI_Offset
>>>>>
>>>>> This is a minor addition to the standard, which would have
>>>>>           
>>> no impact
>>>       
>>>>> on existing code while serving to simplify code which
>>>>>           
>>> exchanges file
>>>       
>>>>> offsets among processes.
>>>>>
>>>>> There is a workaround in the standard: a user can define a
>>>>>           
>>> type from
>>>       
>>>>> MPI_BYTE:
>>>>>
>>>>> MPI_Type_contiguous(sizeof(MPI_Offset), MPI_BYTE, &offtype);
>>>>>
>>>>> However, it would clearly be more convienient to operate
>>>>>           
>>> on built-in
>>>       
>>>>> types.
>>>>>
>>>>> MPI Datatype: MPI_OFFSET
>>>>> Corresponding C type: long long int
>>>>> Corresponding Fortran type: INTEGER(KIND=MPI_OFFSET_KIND)
>>>>>
>>>>>
>>>>> Thanks
>>>>> ==rob
>>>>>
>>>>> -- 
>>>>> Rob Latham
>>>>> Mathematics and Computer Science Division    A215 0178
>>>>>           
>>> EA2D B059 8CDF
>>>       
>>>>> Argonne National Lab, IL USA                 B29D F333
>>>>>           
>>> 664A 4280 315B
>>>       
>>>>> _______________________________________________
>>>>> mpi-21 mailing list
>>>>> mpi-21_at_[hidden]
>>>>> http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21
>>>>>
>>>>> ------ End of Forwarded Message
>>>>>
>>>>> _______________________________________________
>>>>> mpi-22 mailing list
>>>>> mpi-22_at_[hidden]
>>>>> http://lists.cs.uiuc.edu/mailman/listinfo/mpi-22
>>>>>
>>>>>
>>>>>           
>>>> _______________________________________________
>>>> mpi-22 mailing list
>>>> mpi-22_at_[hidden]
>>>> http://lists.cs.uiuc.edu/mailman/listinfo/mpi-22
>>>>         
>>> _______________________________________________
>>> mpi-22 mailing list
>>> mpi-22_at_[hidden]
>>> http://lists.cs.uiuc.edu/mailman/listinfo/mpi-22
>>>
>>>
>>>       
>> _______________________________________________
>> mpi-22 mailing list
>> mpi-22_at_[hidden]
>> http://lists.cs.uiuc.edu/mailman/listinfo/mpi-22
>>     
>
>
>   







* 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3245 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.mpi-forum.org/pipermail/mpi-22/attachments/20080206/8808a4d0/attachment.bin>