[cmucl-help] 19c alpha [Was Re: CMUCL 18c building on tru64 5.1]

Mon Sep 8 19:41:48 UTC 2014

On Mon, Sep 8, 2014 at 10:41 AM, Fausto Saporito <fausto.saporito at gmail.com>
wrote:

> Hello... I fixed the Depends problem... in the GNUMakefile there's -MM
> flag for depend... it seems DEC cc wants just one M...
>
> so -M -E
>
>
Starting a new thread....

If we're standardizing on 19c, I'll try to make a branch from 19c to keep
track of this development work, so we don't lose it.

It's probably worth while for me to get the github mirror of cmucl actually
working.

> regards,
> Fausto
>
>
> 2014-09-08 19:16 GMT+02:00 Fausto Saporito <fausto.saporito at gmail.com>:
> > ok, Ray.
> > I'll use 19c from now on.
> >
> > thanks,
> > Fausto
> >
> >
> > 2014-09-08 18:24 GMT+02:00 Raymond Toy <toy.raymond at gmail.com>:
> >>
> >>
> >>
> >> On Sun, Sep 7, 2014 at 9:42 PM, Fausto Saporito <
> fausto.saporito at gmail.com>
> >> wrote:
> >>>
> >>> Hello Raymond
> >>>
> >>> I agree with you. I don' want try random version, I'm following what
> you
> >>> said in a previous message.
> >>>
> >>> More far we are from 18a, worst is.
> >>>
> >>> Now I have a cross compiled kernel core from 19a and 19c
> >>> What do you think ? Are they ok for our purpose or we should get a core
> >>> from 18c or 18d ?
> >>
> >>
> >> If you have a kernel.core from 19a or 19c, let's stay with that. If 19c
> is
> >> working, let's use 19c since it's more up-to-date.
> >>
> >> Let's figure out why call_into_lisp is crashing.
> >>
> >>>
> >>>
> >>> So we can stick to a specific version and we can continue only with
> that
> >>> one.
> >>>
> >>> Regards
> >>> Fausto
> >>>
> >>> Il giorno 08/set/2014, alle ore 00:15, Raymond Toy <
> toy.raymond at gmail.com>
> >>> ha scritto:
> >>>
> >>>
> >>>
> >>>
> >>> On Sun, Sep 7, 2014 at 9:25 AM, Fausto Saporito
> >>> <fausto.saporito at gmail.com> wrote:
> >>>>
> >>>> Hello Ray,
> >>>>
> >>>> i'm trying to do a cross-compile with 18e, I copied the scripts from
> >>>> 19a, cause in the 18x src tree they don't exist.
> >>>> It seems all ok, but I got this new error:
> >>>>
> >>>> ;; Loading
> >>>>
> #p"/home/fausap/CMU/18e/alpha-cross/compiler/generic/new-genesis.x86f".
> >>>> ;
> >>>>
> >>>> ; Warning: This function is undefined:
> >>>> ;   KERNEL::%CLASS-LAYOUT
> >>>>
> >>>> Error in %COERCE-TO-FUNCTION:  the function KERNEL::%CLASS-LAYOUT is
> >>>> undefined.
> >>>
> >>>
> >>> Ah, there were some class layout changes done by Gerd somewhere around
> >>>
> >>> the 18e or 18f time frame.  It might work to just remove those things
> from
> >>> the bootstrap file or try to get the scripts from release 18e or 18f.
> >>>
> >>> Rather than randomly trying different versions, can we stick to the one
> >>> where you were able to create a kernel.core successfully? (Which
> version was
> >>> that?) Let's stick to that and see how far we can get with it. I think
> if we
> >>> can figure out why your debugger session is so different from the
> assembly
> >>> source, we can make it work. That's gotta be something simple and
> stupid
> >>> that we're overlooking. I just don't know what it could be.
> >>>
> >>>
> >>>>
> >>>> Restarts:
> >>>>   0: [CONTINUE] Return NIL from load of "cross.lisp".
> >>>>   1: [ABORT   ] Return to Top-Level.
> >>>>
> >>>> Debug  (type H for help)
> >>>>
> >>>> (%COERCE-TO-FUNCTION KERNEL::%CLASS-LAYOUT)
> >>>> Source:
> >>>> ; File: target:code/fdefinition.lisp
> >>>> (ERROR 'UNDEFINED-FUNCTION :NAME NAME)
> >>>>
> >>>> maybe something in setenv-scripts directory is too new...
> >>>>
> >>>> what do you think ?
> >>>>
> >>>> regards,
> >>>> Fausto
> >>>>
> >>>>
> >>>> 2014-09-07 6:35 GMT+02:00 Raymond Toy <toy.raymond at gmail.com>:
> >>>> > Change :compile-toplevel :load-toplevel :execute to compile load
> eval.
> >>>> > The
> >>>> > former are the CLHS names previously known as the latter. CMUCL
> >>>> > supports
> >>>> > both. The purpose of the change was to make all of the exported
> symbols
> >>>> > in
> >>>> > parms.lisp available while cross-compiling. This is why you were
> >>>> > getting
> >>>> > errors about using symbols that weren't exported.
> >>>> >
> >>>> > I think 20d should support the new :compile-toplevel and friends.
> >>>> >
> >>>> > Also, I think 20d might work if you use a lisp that uses 8-big chars
> >>>> > instead
> >>>> > of unicode.  20e would work if you make a small change to
> >>>> > src/compiler/alpha/array.lisp.  On line 137, change :byte to :short.
> >>>> > This
> >>>> > makes Lisp characters be 16-bits long instead of 8.  You'll have to
> >>>> > compile
> >>>> > using a 20e lisp with unicode.
> >>>> >
> >>>> > However, I think it would be best to stay with 18c or 18d to do the
> >>>> > first
> >>>> > cross-compiles.  The farther away we get from 18a, the more changes,
> >>>> > and
> >>>> > it's not clear if the changes were ported to alpha or not.
> >>>> >
> >>>> > We still have to figure out why your debugger session disassembly of
> >>>> > call_into_lisp looks so different from the actual assembly in
> >>>> > alpha-assem.S.
> >>>> >
> >>>> >
> >>>> > On Sat, Sep 6, 2014 at 1:49 PM, Fausto Saporito
> >>>> > <fausto.saporito at gmail.com>
> >>>> > wrote:
> >>>> >>
> >>>> >> Hello,
> >>>> >>
> >>>> >> i tried again cross-compiling using the git sources, I saw Ray
> >>>> >> modified something related alpha tree... but it seems cmucl doesn't
> >>>> >> like the line with eval-when
> >>>> >>
> >>>> >> ; Error: Read error in form starting at 1236:
> >>>> >> ;  "(eval-when (:compile-toplevel :load-toplevel :execute)"
> >>>> >> ; End-of-File on #<Stream for file
> >>>> >> "/home/fausap/CMU/cmucl/src/compiler/alpha/parms.lisp">
> >>>> >>
> >>>> >> I tried with 20d and 20e
> >>>> >>
> >>>> >> What am I doing wrong ?
> >>>> >>
> >>>> >> regards,
> >>>> >> Fausto
> >>>> >>
> >>>> >>
> >>>> >> 2014-09-04 23:54 GMT+02:00 Fausto Saporito
> >>>> >> <fausto.saporito at gmail.com>:
> >>>> >> > It's INITIAL-FUNCTION:
> >>>> >> >
> >>>> >> > 0x3028EEE8: %INITIAL-FUNCTION   #x3028EED1
> >>>> >> >
> >>>> >> > so it seems ok...
> >>>> >> >
> >>>> >> >
> >>>> >> > 2014-09-04 22:29 GMT+02:00 Carl Shapiro <carl.shapiro at gmail.com
> >:
> >>>> >> >> On Thu, Sep 4, 2014 at 9:17 AM, Raymond Toy <
> toy.raymond at gmail.com>
> >>>> >> >> wrote:
> >>>> >> >>>
> >>>> >> >>> I have to say, I can't really understand this.  The
> disassembled
> >>>> >> >>> instructions don't seem to match what's in alpha-assem.S.  I'm
> >>>> >> >>> guessing,
> >>>> >> >>> however, that this jsr inst is jumping into the
> initial_function,
> >>>> >> >>> which
> >>>> >> >>> might be in v0.  But in alpha-assem.S, the instruction looks
> like
> >>>> >> >>> jsr
> >>>> >> >>> reg_ZERO, (reg_LIP).
> >>>> >> >>
> >>>> >> >>
> >>>> >> >> The map files generated when building a core should help you
> >>>> >> >> translate
> >>>> >> >> a PC
> >>>> >> >> to a function.  I would look to see which function's PC range
> >>>> >> >> encloses
> >>>> >> >> 0x3028eee8.  From there, we can develop a hypothesis about what
> is
> >>>> >> >> going
> >>>> >> >> wrong.
> >>>> >
> >>>> >
> >>>> >
> >>>> >
> >>>> > --
> >>>> > Ray
> >>>
> >>>
> >>>
> >>>
> >>> --
> >>> Ray
> >>
> >>
>