[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Compiler design reference sought
From: |
Chun Tian (binghe) |
Subject: |
Re: Compiler design reference sought |
Date: |
Wed, 7 Feb 2024 20:41:04 +1100 |
User-agent: |
Mozilla/5.0 (Macintosh; Intel Mac OS X 14.3; rv:91.0) Gecko/20100101 Firefox/91.0 SeaMonkey/2.53.18.1 |
Sorry, I should really try again before sending the last email. The
"tangle0.lisp" I extracted, can indeed be compiled by GCL 2.7.0 in a few
seconds:
>(compile-file "tangle0.lisp")
;; Compiling tangle0.lisp.
;; End of Pass 1.
;; End of Pass 2.
OPTIMIZE levels: Safety=0 (No runtime error checking), Space=0, Speed=3
;; Finished compiling /Users/binghe/Lisp/AXIOM/axiom-code/books/tangle0.o.
#P"/Users/binghe/Lisp/AXIOM/axiom-code/books/tangle0.o"
NIL
NIL
P.S. The full "tangle.lisp" from AXIOM source code, when compiled by GCL
2.7.0, is really low. But now I don't have confidence to say anything
like "infinite loop" now. Perhaps it just needs some more time, e.g. 10
minutes.
--Chun
On 07/02/24 20:34, Chun Tian (binghe) wrote:
> Hi Camm,
>
> Is it possible that the "iteration" in the GCL compiler that you
> mentioned, may not terminate (i.e. falling into infinite loops) for
> certain inputs?
>
> The attached Lisp code is the very beginning part of AXIOM's "tangle"
> utility for extracting code from LaTeX files. In my machine, GCL 2.7.0
> compiler seems take forever to compile the (only) Lisp function in it.
>
> My guess is that, in the function, many other Lisp functions are
> referenced, but these functions are to be defined at later position of
> the code, and thus their type information is unknown. GCL 2.6.x can
> compile this file any way, but the current GCL 2.7.0 compiler seems
> failing into infinite loops.
>
> Regards,
>
> Chun TIAN
>
> On 05/02/24 02:27, Camm Maguire wrote:
>> Greetings! Over the years, various theoretical papers on algorithms for
>> Common Lisp utilities have been very helpful in GCL development,
>> e.g. Baker's paper on the type system.
>>
>> I am looking for a reference on compiler design algorithms which handle
>> type inferencing most efficiently. Right now we iterate on conflict,
>> and I think this is too slow. Pointers most appreciated!
>>
>> Take care,
>>
signature.asc
Description: OpenPGP digital signature