On Mon, Sep 8, 2014 at 10:41 AM, Fausto Saporito <[email protected]> wrote:
> 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 > > Starting a new thread.... If we're standardizing on 19c, I'll try to make a branch from 19c to keep track of this development work, so we don't lose it. It's probably worth while for me to get the github mirror of cmucl actually working. > regards, > Fausto > > > 2014-09-08 19:16 GMT+02:00 Fausto Saporito <[email protected]>: > > ok, Ray. > > I'll use 19c from now on. > > > > thanks, > > Fausto > > > > > > 2014-09-08 18:24 GMT+02:00 Raymond Toy <[email protected]>: > >> > >> > >> > >> On Sun, Sep 7, 2014 at 9:42 PM, Fausto Saporito < > [email protected]> > >> 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 < > [email protected]> > >>> ha scritto: > >>> > >>> > >>> > >>> > >>> On Sun, Sep 7, 2014 at 9:25 AM, Fausto Saporito > >>> <[email protected]> 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 <[email protected]>: > >>>> > 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 > >>>> > <[email protected]> > >>>> > 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 > >>>> >> <[email protected]>: > >>>> >> > It's INITIAL-FUNCTION: > >>>> >> > > >>>> >> > 0x3028EEE8: %INITIAL-FUNCTION #x3028EED1 > >>>> >> > > >>>> >> > so it seems ok... > >>>> >> > > >>>> >> > > >>>> >> > 2014-09-04 22:29 GMT+02:00 Carl Shapiro <[email protected] > >: > >>>> >> >> On Thu, Sep 4, 2014 at 9:17 AM, Raymond Toy < > [email protected]> > >>>> >> >> 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 > >> > >> > _______________________________________________ cmucl-help mailing list [email protected] http://lists.zs64.net/mailman/listinfo/cmucl-help
