[Gcl-devel] Re: Recent ansi fixes

[Paul F. Dietz]

Camm Maguire wrote:

> Great!  Just wondering here, I know we still are not implementing as
> much stuff as clisp and cmucl, but how 'solid' is our compiler, at
> what it does, in comparison with these others in your opinion? 

CLISP is the most 'solid' (but the compiler there does relatively little).
It goes about 3 million iterations (on average) before finding a bug.
The random tester has found only two (or perhaps three) bugs there.

SBCL and CMUCL have aggressive compilers, and so it's not surprising
the random tester has been finding many bugs there.  The hit rate
is still better than 1 in 2000 iterations at this time, IIRC (on terms
of 'size' 100).  Bugs have been manifesting themselves in integer
type propagation, backend code generation, dead code elimination,
and at least one previously known optimization bug.  The developers
on both lisps have been fixing many of the problems as they arise.

The tester has found some problems with ECL's compiler, but progress
is limited there because ECL doesn't currently compile the random
tester itself properly.

There were four common failures in ACL 6.2 (x86 trial).  When I
conditionalized out the builtin functions that were leading to
those failures, the random tester found a number of lower probability
failures, with 23 hits in 1 million iterations (with many caused by
the same bugs).  I believe these bugs are being fixed internally.

Lispworks (4.2, x86 linux free personal edition) has some sort of
space leak that prevents it from getting too far.

See gcl/ansi-tests/misc.lsp for tests based on some of the bugs the
random tester has found.


> > If COMPILE were implemented using file compilation (which I thought
> > gcl did), then inserting appropriate LOAD-TIME-VALUE forms could make
> > the semantics come out right even if the file compiler doesn't preserve
> > literal identity.
>
>
> Ah, enlightenment!  We do indeed base compile on compile-file.
>
> 1) The devil is in the term 'appropriate'.  When walking the form, can
>    one simply wrap evrey symbol with this function?

Better, whenever you have a literal object, just stick its address in some
form like (LOAD-TIME-VALUE (GCL-INTERNAL-POINTER <address-of-that-object>))
where GCL-INTERNAL-POINTER converts an integer to a pointer to that address.
There's no need to dump the contents of that object to the file,
since this file is being compiled just for internal consumption
by this lisp.  You'd want to do this before dumping out the files but
after optimizations at the lisp level.


> 2) How does this strategy compare with the other I posted in your
>    opinion?  The tricky part in the latter is at least twofold -- a)
>    one needs a macro to protect against the evaluation of the
>    &optional def on the compile command line (a la compile.5), but one
>    also needs to walk the form after evalutation (inside my posted
>    compile-internal) as if the def is named by a symbol on the command
>    line, there is apparently no way to get at it in the macro.  As in
>    1), a big question is in coming up with a minimal set of object in
>    the form that need gensyming.  What constitutes a 'literal object'
>    -- can't find a clear definition in the spec.

I haven't gone over that strategy yet.  The one I'm suggesting doesn't
seem very complicated at all, though.

For 'literal', see the glossary:

  literal adj. (of an object) referenced directly in a program rather than
  being computed by the program; that is, appearing as data in a quote form,
  or, if the object is a self-evaluating object, appearing as unquoted data.
  ``In the form (cons "one" '("two")), the expressions "one", ("two"), and
  "two" are literal objects.''

        Paul