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

[Raymond Toy]

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