Well, if the goal is a common ABI then we have to expose the details in order to put together a proposal for the group. I don't see any other way to do it. As for the spreadsheet ... One way to do it would be to assign an "owner" for each of the columns on the spreadsheet. I will do the integration. Let's discuss at the WG session next week. I'd like to start getting into discussion of the ABI column. We should have enough data to get that rolling. Perhaps we will have something to propose at the next meeting (although this seems to pop up on everyones radar a week prior to the meeting - myself included). Jeff
On Apr 25, 2008, at 6:21 AM, Supalov, Alexander wrote:
I've reviewed the current spreadsheet. Note that according to our current observations, 64-bit Linux column covers Itanium Linux as well, as far as the contents of the MPICH2 mpi.h is concerned. I take this as an indication that we should not forget that ABI is more than mpi.h, and that we should be very specific in the platform description.
Also, we might want to split Linux and Windows into different subsheets. Indeed, splitting into 32- and 64-bit might be helpful as well, as soon as the table becomes densely populated. I think this is something we should discuss when we see a joint ABI emerging.
What is the goal for all of this analysis? I think we can already tell that:
- many MPI implementations have different fixed values for the same MPI constants/etc. - some MPI implementations have run-time determined values (e.g., pointers) - some MPI implementations change values/types based on the compiler +platform that they are operating on
Do we really need to make a comprehensive list of all MPI's on all compiler+platforms to see these trends? Is there specific data that would be gleaned from these vs. seeing a representative sample?
(just trying to understand the purpose of the ever-expanding spreadsheet)
I have a process question here: how do we prevent multiple updates running into each other, or overwriting each other accidentally? Is there a check-in/out feature in Wiki, or should we introduce a manual lock? Say, a file with a well known name to create before editing and delete afterwards? The name of the creator would show who's holding the lock. The modification date of the main file would show whether the copy you're working with is still actual.
How about creating separate spreadsheets, one for each MPI implementation? This would allow for more-or-less independent updates.
At some point in the future (when most changes have been complete), they can be [re-]merged back into one spreadsheet.
-- Jeff Squyres Cisco Systems
_______________________________________________ mpi3-abi mailing list mpi3-abi_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-abi