[Openmcl-devel] saving data to a fasl file

[Gary Byers]

On Tue, 23 Nov 2004, Dan Knapp wrote:

> > The general idea (which might make reading the code in
> > "ccl:xdump;faslenv.lisp", "ccl:level-0;nfasload.lisp", and
> > "ccl:lib;nfcomp.lisp" easier to understand) is:
>
>    Yeah, actually, I was looking the other day for a description of the
> fasl
> format, and I couldn't find one.  Not that I really needed to know,
> but...
> I'm going to add this email as a new section in the "Implementation"
> chapter...  Is there anything (besides the source) that I could include
> or link to for more details?  If not, don't bother writing anything up;
> I
> doubt the audience for it is large...

There are opcodes like "$fasl-a5ref" defined, which date back to the
68K MCL days.  I'd rather not try to explain what they're doing there ...

>
> > The file name "nfasload.lisp" is so-called because this is the "new"
> > fasloader.  It was "new" in 1986 or so.  The format could probably
> > stand some modernization/overhaul; it would certainly need extensions
> > to deal with 64-bit architectures, etc.
>
>    I notice there's a lot of "ppc64" stuff in the source tree.  Does it
> work?
> What sort of systems is it intended for?

I was starting to work on a ppc64 port last spring.  It was originally
(mostly) intended to work on G5s under Panther (where you can sort of
get the processor into 64-bit mode but are stuck with a 32-bit address
space and a 32-bit C world.)  Targeting Tiger and PPC64 Linux would
make more sense at this point.

I changed jobs last spring, and honestly haven't had time to work on
this (or too many other OpenMCL things) since.  As I've been saying
(to myself, at least), hopefully that'll change soon. (I've been
holding a "Will Hack PPC64 For Food" sign near freeway exits, but
the response has been underwhelming so far.)

The code that's in CVS doesn't work; it'd probably take several (6?
8?) weeks of full-time effort to get it to the point where it'll
compile itself and not crash too often ...

Some of the stuff I was doing last spring/winter involved reorganizing
some implementation packages ("PPC", "PPC32", etc.) to try to better
hide/expose PPC32 dependencies.  It's better-organized than it was,
but if/when the PPC64 port starts moving forward again there may be
further reorganization necessary.

>
> -- Dan Knapp
>