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

[Fausto Saporito]

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
>
>