On 17 Oct 99, at 8:22, Nick Craig-Wood wrote:
> Some time ago I proposed a standard format for save files. It also
> had the advantage that it only saved the actual bits used so would
> make the save files 1MByte rather than 1.8 MByte for an 8,000,000
> exponent in prime95.
Yes - this idea is useful ...
> > Converting a savefile is also going to be a lot of work :-)
>
> It needs to be done exactly right - hence by the program which
> generated it probably.
>
If it's worthwhile, there is of course source for George's programs
(which represent the vast majority of clients). So there's existing
source code for reading Prime95/mprime format save files.
>
> Here is what I wrote :-
>
> I'd like to propose for discussion a simple cross-platform save file format
> as below.
>
> Width Value Description
>
> 8 "MersSave" in ASCII as a file identifier
> 4 int32 version number of file
> 16 ASCII space filled name of creating program
I want this longer, & to include version major/minor/release & build
numbers as well. 32 bytes?
> 4 int32 exponent being tested (n)
> 4 int32 iteration that this residue represents
> 4 int32 length of platform specific area x words
> 4x int32 platform specific
e.g. George's programs would want to store the offset here.
Would it be too much to ask to have an int32 count of "platform
specific" bytes following in a variable length field here? Some
platforms will require none (just a zero count), others might want to
embed a (currently unknown) vector of arbitary length at this point.
> len int32 binary data for the residue
> len = ((n + 0x1F) & ~ 0x1F) >> 3
> 4 int32 CCITT CRC-32 of the entire file
>
> All integers should be represented as little-endian in the file (the majority
> of the clients are little-endian). The residue should be little endian with
> the unused 1-31 bits at the end set to 0.
Since the "majority of clients" which are "little endian" are
overwhelmingly IA32 processors, which have byte reversal instructions
specifically designed to do the job, I'd like to propose that the
integers be stored in "big-endian" format. Or, alternatively, that we
devote _two_ bits of the file version number - both the MS and LS
bits - to flags, set to 0 for little-endian format or 1 for big-
endian format. Still leaves 30 bits for file version number info, and
allows clients to write whatever format is easiest. Write operations
outnumber read operations by a big margin!
Regards
Brian Beesley
_________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
