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

[Fausto Saporito]

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

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