Prolog-2 PRM files, extra degrees of freedom 
Author Message
 Prolog-2 PRM files, extra degrees of freedom

In Prolog-2, which is an implementation of Prolog for MS-DOS machines,
predicates can be saved to a file in a fast-loading binary format, a
so-called module. Such files have the default extension PRM.

It seems that PRM files can be equivalent even though their contents at
the byte level differ. The files are equivalent in the sense that the
same contents are reported when inspected with open_module/4,
listing/0, and predicate/3. At the byte level the files may differ when
compared with the FC utility (a DOS program that resembles cmp).

I have seen this behaviour for small modules as well as large ones.
Apparently, if preconditions are sufficiently equal the resulting PRM
files may be identical. In particular, the time and date do not matter.
On the other hand, the contents of the MNU file that is consulted when
starting Prolog is significant in some way. If the default MNU file is
used the PRM file produced may differ (at the byte level) from the file
produced if a reduced MNU file is used.

You may ask what difference this makes, as long as the contents of the
PRM files represents the stored clauses faithfully.  However, when
using a CASE tool for handling different versions of a software
product, life would be simpler if one could trust that a certain Prolog
source always yields a particular PRM byte sequence. With the present
state of things, when a PRM file is re-made and differs from an older
version, this may be because the source has been changed, OR because
something has gone wrong, OR because the PRM files just differ even
though they are equivalent at the Prolog level. To exclude the "gone
wrong" case means some hard work.

Can anyone shed more light on this, please? What preconditions should
be kept unchanged in order to get byte-wise identical PRM files from
unchanged sources?

I include a small piece of code that produces a module, and that
behaves as explained in this article.

        ?- create_module(zap,virtual),
           state(output_module,Old,zap),
           assert((foo(X) :- bar(X))),
           save(zap,"zap",none,data,readwrite),
           state(output_module,_,Old).

________________________________________________________________________



Sun, 24 Apr 1994 06:41:04 GMT  
 Prolog-2 PRM files, extra degrees of freedom

Quote:

>It seems that PRM files can be equivalent even though their contents at
>the byte level differ. The files are equivalent in the sense that the
>same contents are reported when inspected with open_module/4,
>listing/0, and predicate/3. At the byte level the files may differ when
>compared with the FC utility (a DOS program that resembles cmp).

You are probably expecting too much to expect that the binaries would
be identical because two programs were logically eqivalent.  Two
programs that only differed in ordering of predicates within a file,
ordering of clauses within the predicate, or ordering of arguments
within a term *might* be logically equivalent, but expecting them
to be compiled to the same binary is asking a lot of the compiler.

Quote:
>You may ask what difference this makes, as long as the contents of the
>PRM files represents the stored clauses faithfully.  However, when
>using a CASE tool for handling different versions of a software
>product, life would be simpler if one could trust that a certain Prolog
>source always yields a particular PRM byte sequence.

Perhaps life would be simpler that way, but I know of no compiler
writer for any language who would guarentee the exact binary generated
for a particular program.  The exact contents of the binary file is
clearly the province of the compiler writer, not the user.

It is fairly standard among software development tools to use the
last-modified time of the file for the purposes of determining if
a file has changed, and only in that case forcing a recompile.

--
John Dowding



Mon, 25 Apr 1994 01:04:22 GMT  
 Prolog-2 PRM files, extra degrees of freedom

Quote:

>Fogelholm) writes:
>>It seems that PRM files can be equivalent even though their contents at
>>the byte level differ. The files are equivalent in the sense that the
>>same contents are reported when inspected with open_module/4,
>>listing/0, and predicate/3. At the byte level the files may differ when
>>compared with the FC utility (a DOS program that resembles cmp).


Quote:
(John Dowding) writes:
>You are probably expecting too much to expect that the binaries would
>be identical because two programs were logically eqivalent.  Two
>programs that only differed in ordering of predicates within a file,
>ordering of clauses within the predicate, or ordering of arguments
>within a term *might* be logically equivalent, but expecting them
>to be compiled to the same binary is asking a lot of the compiler.

I agree, that would be asking a lot. However, I am just curious why
even a small hello-world style module (one predicate, one clause, no
logical variables) does not yield the same binary always.

Quote:
>> [ text deleted ]
>..., but I know of no compiler
>writer for any language who would guarentee the exact binary generated
>for a particular program.  The exact contents of the binary file is
>clearly the province of the compiler writer, not the user.

A hello-world program in C yields the same a.out binary always, I
think.  Initially I expected Prolog-2 to have the same sort of
"reproducibility" property.

Quote:
>It is fairly standard among software development tools to use the
>last-modified time of the file for the purposes of determining if
>a file has changed, and only in that case forcing a recompile.

I know, but isn't it usually the case that time-stamps are kept
separate from the contents of binary files? For example, the 'make'
facility for C programs under Unix looks at time-stamps which are not
encoded in the binaries.

Anyway, the PRM files of Prolog-2 do not contain time-stamps, because
then two PRM files produced at different instants would *always*
differ, which is not the case. It must be something fancier (amount of
GCtime, say) that accounts for the differences that occur.

________________________________________________________________________



Tue, 26 Apr 1994 05:35:58 GMT  
 Prolog-2 PRM files, extra degrees of freedom

        ...
   A hello-world program in C yields the same a.out binary always, I
   think.

hmmph.  optimization, dynamic library versions, which compiler you use
all make a difference.  this isn't what you were talking about
exactly, but here is an example (which isn't exactly hello world, but
it's about as simple).

Quote:
> cat x.c

#include <stdio.h>
#include <ctype.h>

main(c,a)
int c;
char **a;
{
    int ch;
    ch = getchar();
    while (ch != EOF) {
        if (isprint(ch)) printf("%c\n", ch);
        else printf("%02x\n", ch&0xff);
        ch = getchar();
    }

Quote:
}
> cc -o x x.c
> cc -O -o xO x.c
> gcc -o xg x.c
> gcc -O -o xgO x.c
> cmp x xg

x xg differ: char 20, line 1
Quote:
> cmp xO x

xO x differ: char 657, line 7
Quote:
> cmp xg xgO

xg xgO differ: char 672, line 9


Wed, 04 May 1994 01:59:45 GMT  
 
 [ 4 post ] 

 Relevant Pages 

1. variance and degrees of freedom

2. The extra extra segments

3. Prolog for DOS/Win95 & extra's

4. Question about .exxe files (with an extra x)

5. Extra line in text file

6. Create Zip file with no extra folder info

7. Huge files take days at extra high speed

8. Extra file handles

9. Extra file handle in event loop?

10. Your request for freedom! 13243

11. Million Dollar Investment for FREEDOM

12. slavery and freedom in language design

 

 
Powered by phpBB® Forum Software