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

[Fausto Saporito]

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 ? 

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