On Sun, Oct 17, 1999 at 03:21:49PM +0100, Brian J. Beesley wrote:
> On 17 Oct 99, at 8:22, Nick Craig-Wood 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?
Yes sounds like a good idea. Perhaps we should formalise the version
number like this?
1 int8 Major
1 int8 Minor
1 int8 Micro
1 int8 Patch level
> > 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.
Ah, offset! I wrote this before offset was introduced. This would
need to be part of the save file I think because different offset =>
different save file data. I think offset would fit into an int32?
> 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.
That was what I intended by the last two entries above, but I may not
have been clear enough.
4 int32 length of platform specific area x words
4x int32 platform specific (x words of data may be 0 length)
> > 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!
This is sensible. I like the big/little endian flag idea. I've tried
to design the header so that it can be represented by a C struct and
just (f)write()-en straight to the file. Having big/little endian
flag is an excellent idea here.
Also it might just be better to store the actual numeric data as
int8's rather than int32s - this way the endian ness of the processors
doesn't matter.
--
Nick Craig-Wood
[EMAIL PROTECTED]
http://www.axis.demon.co.uk/
_________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
