[cmucl-help] CMUCL 18c building on tru64 5.1

[Raymond Toy]

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