========================== C M U C L 18 e =============================
The CMUCL project is pleased to announce the release of CMUCL 18e.
This is a major release which contains numerous enhancements and
bugfixes from the 18d release.
CMUCL is a free, high performance implementation of the Common Lisp
programming language which runs on most major Unix platforms. It
mainly conforms to the ANSI Common Lisp standard. CMUCL provides a
sophisticated native code compiler; a powerful foreign function
interface; an implementation of CLOS, the Common Lisp Object System,
which includes multimethods and a metaobject protocol; a source-level
debugger and code profiler; and an Emacs-like editor implemented in
Common Lisp. CMUCL is maintained by a team of volunteers collaborating
over the Internet, and is mostly in the public domain.
New in this release:
* Feature enhancements:
- Karatsuba multiplier added to give faster multiplication for
big bignums.
- Better support for linking foreign libraries. You can now dump
cores with foreign libraries and reload this core and the
libraries, without having to reload code that uses those
libraries. Available if the feature :linkage-table is present.
- A cross-referencing facility has been added to the compiler,
providing WHO-CALLS, WHO-BINDS, WHO-REFERENCES, WHO-SETS
information. See the corresponding chapter of the User's Manual
for more information.
- Bindings to the POSIX user and group database access functions
(getpwuid et al) have been added to the UNIX package.
- Support for Unix sockets and for binding to specific IP
addresses has been added to the networking code.
- Support for generalized function names of the form
(<SYMBOL> ...) has been added. See EXT:DEFINE-FUNCTION-NAME-SYNTAX
and EXT:VALID-FUNCTION-NAME-P.
- Access to the hardware cycle counters on Pentium and UltraSPARC
processors has been added, and is reported by the TIME macro.
- On Linux, it is possible to read and write files larger than 2GiB
(Large File Support implementation) using the low-level functions
in the UNIX package. Use of ANSI CL functions to process such files
may work, but the code base hasn't been audited for this.
Full support for this requires a 2.4 or a 2.2 kernel with LFS
patches.
* Numerous ANSI compliance fixes:
- SYMBOL-MACROLET signals an error when an attempt is made to
bind a special variable or a constant
- the function COMPILE no longer coalesces constants, as required
by the specification (however, COMPILE-FILE continues to do so)
- WITH-OUTPUT-TO-STRING accepts the :external-format keyword
argument
- the function WRITE-STRING accepts a NIL value for the :end
argument
- the function CHANGE-CLASS now accepts initargs
- loops of the form (LOOP FOR I BY (INCF X) FROM ...) now work
- in loop forms, the INITIALLY, FINALLY and DO keywords must be
followed by a compound form
- in the loop macro, PRESENT-SYMBOL now means both internal and
external symbols of a package
- the class precedence list of NULL has symbol before list
- the function FLOAT-RADIX signals an error if its argument is
not a float
- an error is signaled if the lambda keyword &rest is not
followed by a variable
- the GENTEMP function no longer accepts arguments of type symbol
- the function SHIFTF supports multiple values
- compiler macros recognize calls of the form (funcall foo args)
- (coerce <rational> '(complex float)) now returns a (complex
float) rather than a rational
- the ECASE and CCASE macros are allowed to use T and OTHERWISE
as regular keys, instead of as the otherwise clause. CMUCL
prints a warning about this being poor style.
- the type (complex (eql 0)) is accepted now instead of
generating an error.
- the sequence functions check to make sure sequences are
specified and that, if lengths are given, the result matches
the given length.
- when the argument to TRANSLATE-LOGICAL-PATHNAME is a physical
pathname, return it instead of signalling an error.
- the function DEFAULT-DIRECTORY returns a pathname with an
explicit Unix host, instead of leaving it unspecified.
- logical pathnames are now externalizable
- bad directives in FORMAT-LOGICAL-BLOCK: an error is now signalled
if ~W, ~_, ~<...~:>, ~I, or ~:T is used inside "~<..~>"
(without the colon modifier on the closing syntax).
- the SUBTYPEP function is more intelligent when dealing with
certain hairy types (such as those based on SATISFIES).
- the optional environment argument to the functions TYPEP,
SUBTYPEP and friends are now accepted (but ignored).
- system classes FILE-STREAM and STRING-STREAM have been added.
* Numerous bugfixes:
- READ-BYTE on certain types of multi-byte elements was incorrect
- fix the treatment of colon package delimiters for the ~/
formatting directive
- correction to CLX's handling of FamilyLocal authorization
cookies (as created by versions of ssh after 3.4)
- fix to CLX handling of :any event-spec
- fix to boa-constructors ??
- EXPT was not correctly handling a zero exponent
- PROGV was not handling special variables correctly.
- MULTIPLE-VALUE-SETQ and PSETQ were not handling symbol macros correctly.
- index calculations for operations bitvectors of sizes near the
ARRAY-DIMENSION-LIMIT could overflow
- redefining a class with a changed class precedence list didn't
update the CMUCL type system
- generated CLOS getter/setter/boundp generic functions are now
declared correctly, to eliminate bogus undefined function
warnings from the compiler
- method combination options for the long form of the
DEFINE-METHOD-COMBINATION special form work correctly
- executing a defclass form with a metaclass of STRUCTURE-CLASS
would result in the generation of recursive print-object
methods, so that printing such instances would loop
- dividing a ration by zero returned 1/0 instead of signaling an
error
- PPRINT-LOGICAL-BLOCK with a numeric prefix no longer causes the
system to crash
- byte-compiled calls to two-argument STRING< and STRING>
returned incorrect results
- the function READ-SEQUENCE returned incorrect results for
specialized arrays when the internal READ-N-BYTES function read
short
- when a sequence type specifies a length, CMUCL checks that the
length of sequence arguments match the length of the sequence type
- the function REMOVE was not correctly handling all possible
combinations of the :start, :end and :from options.
- the function COMPILE-FILE-PATHNAME computes the output file
name by merging the input file name and the supplied output file name
- the functions MAKE-BROADCAST-STREAM, MAKE-TWO-WAY-STREAM,
MAKE-CONCATENATED-STREAM and MAKE-ECHO-STREAM check that their
argument is an input or output stream, as appropriate
- STREAM-READ-SEQUENCE and STREAM-WRITE-SEQUENCE were getting
called with arguments in the wrong order.
- numerous error conditions are signalled using a more specific
condition type than a generic error
- many (all?) cases where the unused labels functions were
causing a compiler assertion error.
- some cases where the compiler was incorrectly deriving the
types of functions have been fixed.
- error reporting in many areas have been improved to be more
specific and/or ANSI compliant.
- error detection of defclass options in line with ANSI
requirements.
- the compiler now checks type declarations on array elements
before believing them.
- Special declarations of the DOLIST iteration variable are
now honoured when evaluating the DOLIST result form.
- The argument evaluation order of MAKE-STRING in compiled
code has been fixed.
* Other changes:
- The default value for EXT:*BYTES-CONSED-BETWEEN-GCS* has been
increased from 2000000 to 12000000, which should improve GC
performance for many applications out of the box. Of course
people are encouraged to tune the GC parameters to match their
application requirements (e.g. interactive response times),
and their hardware environment.
- The sparc port has experimental support for native 64-bit
integers (unsigned-byte 64) and (signed-byte 64) on sparc v9
(64-bit) architectures. Enabled if the feature :sparc-v8plus
is present (you will need to rebuild CMUCL).
- The CMUCL release tarballs are now relocatable. The lisp image
(in the lisp.core file) is now searched for relative to the
lisp runtime. The previous search mechanisms still take
precedence: the -core commandline option, the CMUCLLIB
environment variable, the default /usr/local/lib/cmucl search
path.
- Messages from the compiler are now preceded by a semicolon, for
better interaction with environments with syntax highlighting.
- An improved initializer for random state is available (function
KERNEL:INIT-RANDOM-STATE accepts an argument of type vector).
- the function PROFILE:REPORT-TIME no longer prints out a long
list of functions that were not profiled. The cutoff is
user-configurable by setting the new variable
PROFILE::*NO-CALLS-LIMIT*.
- reinstated the ability to build small runtime images (excluding
the compiler)
- DESCRIBE will print a note if a symbol names a type-specifier
- numeric types with empty ranges are accepted silently (instead
of signalling an error), and treated as the empty type.
- on Linux, the function SOFTWARE-VERSION returns more useful
information than in the past, including the kernel version
number.
- the function MAKE-DISPATCH-MACRO-CHARACTER will quietly
override existing definitions, instead of signalling an error
if a previous binding for a macro character existed.
- a number of stale symbols have been deleted from CMUCL images
* Numerous improvements to the PCL implementation of CLOS:
- some unused code has been deleted
- error checking of CLOS functions has been significantly improved
- the hash function for PCL instances has been improved
- superfluous SLOT-BOUNDP checking for structure-classes has been
removed
- the preallocation of caches for generic functions has been
removed, since benchmarking indicated that this doesn't provide a
noticeable performance increase
* Improvements to Hemlock, the Emacs-like editor:
- a dynamic-abbrev facility has been added (bound to M-/)
- support for C-w (copy work) during incremental search
* Changes to rebuilding procedure:
- the search-list "modules:" tracks the "library:" search-list,
instead of being set to whatever "library:subsystems/" is at
startup.
* Deprecated features:
- the HASH-NEW, NEW-COMPILER and RANDOM-MT19937 elements of the
*FEATURES* list are deprecated. Starting from the next release of
CMUCL, the corresponding code will be included in default CMUCL
builds.
This release is not binary compatible with code compiled using CMUCL
18d; you will need to recompile FASL files.
See <URL:http://www.cons.org/cmucl/> for download information,
guidelines on reporting bugs, and mailing list details.
We hope you enjoy using this release of CMUCL!
In article <····························@posting.google.com>, Pierre R. Mai wrote:
>========================== C M U C L 18 e =============================
>
> The CMUCL project is pleased to announce the release of CMUCL 18e.
> This is a major release which contains numerous enhancements and
> bugfixes from the 18d release.
Redhat rpms are available at http://www.caddr.com/lisp
--
miles egan
·····@rddac.com
reverse the domain name to find me
OpenPGP/GPG Key 0x01F53D51 @ wwwkeys.us.pgp.net
Miles Egan <·····@rddac.com> writes:
> In article <····························@posting.google.com>, Pierre R. Mai wrote:
> >========================== C M U C L 18 e =============================
> >
> > The CMUCL project is pleased to announce the release of CMUCL 18e.
> > This is a major release which contains numerous enhancements and
> > bugfixes from the 18d release.
>
> Redhat rpms are available at http://www.caddr.com/lisp
Are there CMUCL binaries available for SUSE Linux x86_64 (AMD Hammer)?
Petter
--
________________________________________________________________________
Petter Gustad 8'h2B | ~8'h2B http://www.gustad.com/petter
>>>>> "Petter" == Petter Gustad <·············@gustad.com> writes:
Petter> Miles Egan <·····@rddac.com> writes:
>> In article <····························@posting.google.com>, Pierre R. Mai wrote:
>> >========================== C M U C L 18 e =============================
>> >
>> > The CMUCL project is pleased to announce the release of CMUCL 18e.
>> > This is a major release which contains numerous enhancements and
>> > bugfixes from the 18d release.
>>
>> Redhat rpms are available at http://www.caddr.com/lisp
Petter> Are there CMUCL binaries available for SUSE Linux x86_64 (AMD Hammer)?
Not that I'm aware of, except in, perhaps, some kind of compatibility
mode. x86_64 will run plain x86 code, right?
Ray
Raymond Toy <···@rtp.ericsson.se> writes:
> >>>>> "Petter" == Petter Gustad <·············@gustad.com> writes:
>
> Petter> Miles Egan <·····@rddac.com> writes:
> >> In article <····························@posting.google.com>, Pierre R. Mai wrote:
> >> >========================== C M U C L 18 e =============================
> >> >
> >> > The CMUCL project is pleased to announce the release of CMUCL 18e.
> >> > This is a major release which contains numerous enhancements and
> >> > bugfixes from the 18d release.
> >>
> >> Redhat rpms are available at http://www.caddr.com/lisp
>
> Petter> Are there CMUCL binaries available for SUSE Linux x86_64 (AMD Hammer)?
>
> Not that I'm aware of, except in, perhaps, some kind of compatibility
> mode. x86_64 will run plain x86 code, right?
Yes, but I was hoping for an implementation which took advantage of
the 64-bit architecture, i.e. increased memory size, increased word
size, etc.
Petter
--
________________________________________________________________________
Petter Gustad 8'h2B | ~8'h2B http://www.gustad.com/petter
Petter Gustad <·············@gustad.com> writes:
> Yes, but I was hoping for an implementation which took advantage of
> the 64-bit architecture, i.e. increased memory size, increased word
> size, etc.
A 64 bit port of CMUCL is not trivial, unfortunately.
Florian Weimer <··@deneb.enyo.de> writes:
> Petter Gustad <·············@gustad.com> writes:
> > Yes, but I was hoping for an implementation which took advantage of
> > the 64-bit architecture, i.e. increased memory size, increased word
> > size, etc.
>
> A 64 bit port of CMUCL is not trivial, unfortunately.
Might'nt there be useful stuff to crib from the OSF1/Alpha port?
(I'm not sure whether it's been maintained in the last few years,
but I kind of doubt it.)
TTFN,
'mr
--
[Emacs] is written in Lisp, which is the only computer language that is
beautiful. -- Neal Stephenson, _In the Beginning was the Command Line_
rydis (Martin Rydstr|m) @CD.Chalmers.SE writes:
>> A 64 bit port of CMUCL is not trivial, unfortunately.
>
> Might'nt there be useful stuff to crib from the OSF1/Alpha port?
AFAIK, the Alpha ports are 32 bit ports.
Florian Weimer <··@deneb.enyo.de> writes:
> rydis (Martin Rydstr|m) @CD.Chalmers.SE writes:
>
>>> A 64 bit port of CMUCL is not trivial, unfortunately.
>>
>> Might'nt there be useful stuff to crib from the OSF1/Alpha port?
>
> AFAIK, the Alpha ports are 32 bit ports.
Yes. They appear to the OS to be perfectly normal 64 bit
applications, but allocate all Lisp memory from the lower 2Gb of the
address space, and use a 32 bit lispobj.
Some day I'd like to do a real SBCL 64 bit port (Alpha would be easy
if tedious, PPC64 would, I hear, require a little more work, and I
don't know enough about Hammer to comment) if only to get rid of some
of the really grotty casting in the C runtime, but it's not feasible
as a spare-time project right now.
-dan
--
http://www.cliki.net/ - Link farm for free CL-on-Unix resources
Hi Florian Weimer,
> Petter Gustad <·············@gustad.com> writes:
>
>> Yes, but I was hoping for an implementation which took advantage of the
>> 64-bit architecture, i.e. increased memory size, increased word size,
>> etc.
>
> A 64 bit port of CMUCL is not trivial, unfortunately.
It seems to be trivial for some C programs to see significant speedups on
x86-64 with little more than a recompile (I think this is mainly due to
the 8 new integer registers). I suspect even this won't trivial for CMUCL
to implement. Everyone doesn't get a shiny new compiler for free in the
Lisp world in order to promote adoption of the processor.
Regards,
Adam
>>>>> "Adam" == Adam Warner <······@consulting.net.nz> writes:
Adam> Hi Florian Weimer,
>> Petter Gustad <·············@gustad.com> writes:
>>
>>> Yes, but I was hoping for an implementation which took advantage of the
>>> 64-bit architecture, i.e. increased memory size, increased word size,
>>> etc.
>>
>> A 64 bit port of CMUCL is not trivial, unfortunately.
Adam> It seems to be trivial for some C programs to see significant speedups on
Adam> x86-64 with little more than a recompile (I think this is mainly due to
Adam> the 8 new integer registers). I suspect even this won't trivial for CMUCL
I suspect telling CMUCL about the 8 new integer registers wouldn't be
too hard. But CMUCL would still be a 32-bit app.
Ray
"Adam Warner" <······@consulting.net.nz> writes:
> It seems to be trivial for some C programs to see significant speedups on
> x86-64 with little more than a recompile (I think this is mainly due to
> the 8 new integer registers). I suspect even this won't trivial for CMUCL
> to implement. Everyone doesn't get a shiny new compiler for free in the
> Lisp world in order to promote adoption of the processor.
All of this could be solved if there existed a Lisp compiler that used
gcc as the back end. Not going through C, mind you, but using it as a
proper back end, as is done here:
http://gcc.gnu.org/java/
Whatever gcc ever does right or wrong on whatever platform it ever
does it would be immediately available.
</dream>
Mario.
Mario S. Mommer <········@yahoo.com> writes:
> "Adam Warner" <······@consulting.net.nz> writes:
> > It seems to be trivial for some C programs to see significant
> > speedups on x86-64 with little more than a recompile. I suspect
> > even this won't trivial for CMUCL to implement.
> All of this could be solved if there existed a Lisp compiler that
> used gcc as the back end. Whatever gcc ever does right or wrong on
> whatever platform it ever does it would be immediately available.
> </dream>
Or nightmare? Few Lisp programmers seem to think a Lisp front end to
GCC would be very useful.
Lars Brinkhoff wrote:
> Or nightmare? Few Lisp programmers seem to think a Lisp front end to
> GCC would be very useful.
There are some. This has been talked about as an upgrade
path for gcl, which currently uses gcc vis the 'generate C' approach.
Paul
Lars Brinkhoff <·········@nocrew.org> writes:
> Mario S. Mommer <········@yahoo.com> writes:
> > "Adam Warner" <······@consulting.net.nz> writes:
> > > It seems to be trivial for some C programs to see significant
> > > speedups on x86-64 with little more than a recompile. I suspect
> > > even this won't trivial for CMUCL to implement.
> > All of this could be solved if there existed a Lisp compiler that
> > used gcc as the back end. Whatever gcc ever does right or wrong on
> > whatever platform it ever does it would be immediately available.
> > </dream>
>
> Or nightmare? Few Lisp programmers seem to think a Lisp front end to
> GCC would be very useful.
Why would it be a nightmare? Wouldn't portability and standard
executable-deployment (an ELF + a dynamic lib) be a big advantage?
Mario S. Mommer <········@yahoo.com> writes:
> Lars Brinkhoff <·········@nocrew.org> writes:
> > Mario S. Mommer <········@yahoo.com> writes:
> > > All of this could be solved if there existed a Lisp compiler that
> > > used gcc as the back end. </dream>
> > Or nightmare? Few Lisp programmers seem to think a Lisp front end to
> > GCC would be very useful.
> Why would it be a nightmare?
Well, perhaps not a nightmare.
> Wouldn't portability and standard executable-deployment (an ELF + a
> dynamic lib) be a big advantage?
I think a real Lisp programmer (which I'm not) might view that as
being too far removed from the interactive Lisp development experience.
Lars Brinkhoff <·········@nocrew.org> writes:
> > Wouldn't portability and standard executable-deployment (an ELF + a
> > dynamic lib) be a big advantage?
>
> I think a real Lisp programmer (which I'm not) might view that as
> being too far removed from the interactive Lisp development experience.
Whatever GCL does with the output of the c compiler could be done
exactly the same way. The only difference is that instead of adressing
the back end using C as an intermediate lang, you adress it
directly.
Mario.
Mario S. Mommer <········@yahoo.com> writes:
> Lars Brinkhoff <·········@nocrew.org> writes:
> > > Wouldn't portability and standard executable-deployment (an ELF + a
> > > dynamic lib) be a big advantage?
> >
> > I think a real Lisp programmer (which I'm not) might view that as
> > being too far removed from the interactive Lisp development experience.
>
> Whatever GCL does with the output of the c compiler could be done
> exactly the same way. The only difference is that instead of adressing
> the back end using C as an intermediate lang, you adress it
> directly.
Perhaps. But since gcc was written specifically for C originally,
I'm not sure it would have enough generality to address the issues
that Lisp needs addressing.
Back in 1998, I gave a treatise on C-as-assembler, pros and cons,
and why we don't use it in our own product:
http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&selm=4zp8kn7xe.fsf_-_%40beta.franz.com
These issues would also have to be addressed in order to use a gcc back
end.
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
Duane Rettig <·····@franz.com> writes:
> Back in 1998, I gave a treatise on C-as-assembler, pros and cons,
> and why we don't use it in our own product:
C is not an assembler. It doesn't even have a concept of a machine
address! (You can have two pointers p and q, and p == q ("==" as
defined in C), and p + 2 is legal and q + 2 results in undefined
behavior.)
Florian Weimer <··@deneb.enyo.de> writes:
> Duane Rettig <·····@franz.com> writes:
>
> > Back in 1998, I gave a treatise on C-as-assembler, pros and cons,
> > and why we don't use it in our own product:
>
> C is not an assembler. It doesn't even have a concept of a machine
> address!
That doesn't stop many C programmers from using the caddr_t type as
if it were a machine address. And the lack of string types doesn't
stop C programmers from using char *s as if it were a string type.
I actually agree with you. The point of my original article was that
C doesn't have what it takes for a higher level language to get as
close to the metal as possible, and so we don't use C as our "assembler",
as some other lisps do.
In fact, I recall even some assemblers that didn't have what it took
to get down to the metal, and so the only truly closest-to-hardware
language that is available in such systems is bits (i.e. compiling
down to binary code, with an in-core assembler written in Lisp,
whose output is in fact bits). And with the exception of the core
runtime of our lisp, which is written in lisp and compiled to
assembler source for the purposes of creating the executable file
format of the operating system, we do precisely that (i.e. compile
regular lisp code directly to bits).
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
Florian Weimer <··@deneb.enyo.de> writes:
> Duane Rettig <·····@franz.com> writes:
>
> > Back in 1998, I gave a treatise on C-as-assembler, pros and cons,
> > and why we don't use it in our own product:
>
> C is not an assembler. It doesn't even have a concept of a machine
> address! (You can have two pointers p and q, and p == q ("==" as
> defined in C), and p + 2 is legal and q + 2 results in undefined
> behavior.)
Well, maybe. But be assured that that would be the smallest of all
the problems you'll encounter when compiling to C.
Regards,
--
Nils G�sche
"Don't ask for whom the <CTRL-G> tolls."
PGP key ID 0x0655CFA0
Duane Rettig <·····@franz.com> writes:
> Back in 1998, I gave a treatise on C-as-assembler, pros and cons,
> and why we don't use it in our own product:
>
> <http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&selm=
4zp8kn7xe.fsf_-_%40beta.franz.com>
>
> These issues would also have to be addressed in order to use a gcc back
> end.
Very interesting read, thanks.
This immediately rises the question as to what would constitute a good
assembler for compiling CL to, aside of the obvious and inescapable
options. What set of primitives should a higher level language have to
be able to host common lisp?
The lower end the question would be: Could an abstract assembly be a
good option? Some pseudo assembly that could be compiled easily to a
native tongue, like the assembly used in the "Compiling Lisp" chapter
of PAIP?
Mario.
From: Duane Rettig
Subject: Re: Intermediate language (Was Re: GCC front end)
Date:
Message-ID: <4el3utvgk.fsf@beta.franz.com>
Mario S. Mommer <········@yahoo.com> writes:
> Duane Rettig <·····@franz.com> writes:
> > Back in 1998, I gave a treatise on C-as-assembler, pros and cons,
> > and why we don't use it in our own product:
> >
> > <http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&selm=
> 4zp8kn7xe.fsf_-_%40beta.franz.com>
> >
> > These issues would also have to be addressed in order to use a gcc back
> > end.
>
> Very interesting read, thanks.
You're welcome.
> This immediately rises the question as to what would constitute a good
> assembler for compiling CL to, aside of the obvious and inescapable
> options. What set of primitives should a higher level language have to
> be able to host common lisp?
I don't think a high level language can be an assembler for lisp, unless
it emulates a low-level machine. Calling sequence issues will always
place lisp into a more-stringent category than other languages (for
example, the need for a count register for both calls and returned
values). And in order to get as close to the machine as possible,
the obvious choice of low-level machine to emulate is the target machine
itself. And what better language to do this emulation for Lisp than...
Lisp!
> The lower end the question would be: Could an abstract assembly be a
> good option? Some pseudo assembly that could be compiled easily to a
> native tongue, like the assembly used in the "Compiling Lisp" chapter
> of PAIP?
Allegro CL compiles to LAP code, which is defined per machine.
From there, we can use an in-core assembler (written in CL, of
course) to assemble to bits, or we can output to a source file
as assembler source, for later assembly and linking to help form
the shared-library that makes up the core of Allegro CL.
We use an internal hack to look (and possibly modify, for
experimental purposes) the lap code, shown below. On an x86,
the lap can be seen like this:
CL-USER(1): (defun foo (x) (bar x))
FOO
CL-USER(2): (setq comp::*hack-compiler-output* '(foo))
(FOO)
CL-USER(3): (compile 'foo)
Break: type :cont when you're done editing "hackit.s"
Restart actions (select using :continue):
0: return from break.
1: Return to Top Level (an "abort" restart).
2: Abort entirely from this process.
[changing package from "COMMON-LISP-USER" to "COMPILER"]
[1c] COMP(4): (shell "cat hackit.s")
(LABEL GARBAGE::L2)
(PUSH.L (:REG 5 :EBP :BP))
(MOVE.L (:REG 4 :ESP :SP) (:REG 5 :EBP :BP))
(PUSH.L (:REG 6 :ESI :SI))
(SUB.L (IM (:FINAL-FRAME-SIZE 32 -4)) (:REG 4 :ESP :SP))
(CMP.L (IM 1) (:REG 1 :ECX :CX :CL))
(BCC :EQ GARBAGE::L3)
(INT.B (IM 97))
(LABEL GARBAGE::L3)
(LABEL GARBAGE::L1)
(CMP.B (IM 0) (D -105 (:REG 7 :EDI :DI)))
(BCC.S :EQ GARBAGE::L4)
(INT.B (IM 100))
(LABEL GARBAGE::L4)
(MOVE.L (D 18 (:REG 6 :ESI :SI)) (:REG 3 :EBX :BX :BL))
(MOVE.B (IM 1) (:REG 1 :ECX :CX :CL))
(BCC :T (PC (:REG 7 :EDI :DI)) :LINK)
(LEAVE)
(MOVE.L (D -4 (:REG 5 :EBP :BP)) (:REG 6 :ESI :SI))
(RETURN)
0
[1c] COMP(5): :cont
Warning: While compiling these undefined functions were referenced: BAR.
FOO
NIL
NIL
CL-USER(6): (disassemble 'foo)
;; disassembly of #<Function FOO>
;; formals: X
;; constant vector:
0: BAR
;; code start: #x7161bc84:
0: 55 pushl ebp
1: 8b ec movl ebp,esp
3: 56 pushl esi
4: 83 ec 24 subl esp,$36
7: 83 f9 01 cmpl ecx,$1
10: 74 02 jz 14
12: cd 61 int $97 ; EXCL::TRAP-ARGERR
14: 80 7f 97 00 cmpb [edi-105],$0 ; SYS::C_INTERRUPT
18: 74 02 jz 22
20: cd 64 int $100 ; EXCL::TRAP-SIGNAL-HIT
22: 8b 5e 12 movl ebx,[esi+18] ; BAR
25: b1 01 movb cl,$1
27: ff d7 call *edi
29: c9 leave
30: 8b 75 fc movl esi,[ebp-4]
33: c3 ret
CL-USER(7):
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
Mario S. Mommer <········@yahoo.com> writes:
> This immediately rises the question as to what would constitute a good
> assembler for compiling CL to, aside of the obvious and inescapable
> options. What set of primitives should a higher level language have to
> be able to host common lisp?
Some very smart people have been thinking about that and the result is
C-- <http://www.cminusminus.org/>. There are even some prototype
implementations, but it hasn't been a hit with language implementors,
which is a pity. There's really no point in every functional language
implementor maintaining their own backend.
--
Pekka P. Pirinen
Only fools learn by their experience; smart people use the experience
of others. - Bismarck
From: Lieven Marchand
Subject: Re: Intermediate language (Was Re: GCC front end)
Date:
Message-ID: <878ytyiibu.fsf@wyrd.be>
···············@globalgraphics.com (Pekka P. Pirinen) writes:
> Some very smart people have been thinking about that and the result is
> C-- <http://www.cminusminus.org/>. There are even some prototype
> implementations, but it hasn't been a hit with language implementors,
> which is a pity. There's really no point in every functional language
> implementor maintaining their own backend.
I've looked at it from time to time but the main problem I had is that
it is very unclear how to write programs in C-- for even trivial
tasks. They could do with an example directory or a cookbook.
--
Jane - Daria? Come on, the neighbors are starting to talk.
Daria - Um... good. Soon they'll progress to cave drawings and civilization
will be on its way.
Mario S. Mommer <········@yahoo.com> writes:
> Lars Brinkhoff <·········@nocrew.org> writes:
> > > Wouldn't portability and standard executable-deployment (an ELF + a
> > > dynamic lib) be a big advantage?
> > I think a real Lisp programmer (which I'm not) might view that as
> > being too far removed from the interactive Lisp development experience.
> Whatever GCL does with the output of the c compiler could be done
> exactly the same way. The only difference is that instead of
> adressing the back end using C as an intermediate lang, you adress
> it directly.
Certainly, if you link GCC and GCL together in such a way that GCC
replaces GCL's compiler. However, that's not quite the same as
writing a Lisp front end for GCC, which would give you a Lisp batch
compiler. (That's what I mean with "Lisp front end for GCC".)
So, my statement could be clarified as:
Few Lisp programmers seem to think a Lisp front end for GCC, resulting
in a batch compiler, would be very useful.
Lars Brinkhoff <·········@nocrew.org> writes:
> Mario S. Mommer <········@yahoo.com> writes:
>> All of this could be solved if there existed a Lisp compiler that
>> used gcc as the back end. Whatever gcc ever does right or wrong on
>> whatever platform it ever does it would be immediately available.
>> </dream>
>
> Or nightmare? Few Lisp programmers seem to think a Lisp front end to
> GCC would be very useful.
Fine if you only ever want to write GPLed code, or if you can live
without the compiler at runtime.
-dan
--
http://www.cliki.net/ - Link farm for free CL-on-Unix resources
Daniel Barlow <···@telent.net> writes:
> Lars Brinkhoff <·········@nocrew.org> writes:
> > Or nightmare? Few Lisp programmers seem to think a Lisp front end to
> > GCC would be very useful.
>
> Fine if you only ever want to write GPLed code, or if you can live
> without the compiler at runtime.
Your code doesn't become GPL just because you use a GPL compiler. The
license isn't that viral.
--
burton samograd
······@kruhft.dyndns.org
http://kruhftwerk.dyndns.org
Burton Samograd <······@hotmail.com> writes:
> Daniel Barlow <···@telent.net> writes:
>
>> Lars Brinkhoff <·········@nocrew.org> writes:
>> > Or nightmare? Few Lisp programmers seem to think a Lisp front end to
>> > GCC would be very useful.
>>
>> Fine if you only ever want to write GPLed code, or if you can live
>> without the compiler at runtime.
>
> Your code doesn't become GPL just because you use a GPL compiler. The
> license isn't that viral.
I didn't say it did. However, if I want to compile code at runtime -
which is not such an unusual thing to want to do (especially if you're
using PCL as an object system, as it does this internally) - my code
lives in the same process image as the code of the GPLed compiler.
That _does_ make it subject to the GPL, at least if you accept the GNU
definiton of "derived work". If the GPL allowed this usage, there'd
be no need for the LGPL.
-dan
--
http://www.cliki.net/ - Link farm for free CL-on-Unix resources
Daniel Barlow <···@telent.net> writes:
> Burton Samograd <······@hotmail.com> writes:
> I didn't say it did. However, if I want to compile code at runtime -
> which is not such an unusual thing to want to do (especially if you're
> using PCL as an object system, as it does this internally) - my code
> lives in the same process image as the code of the GPLed compiler.
Oops, forgot I was in a lisp group when I said that. I was answering
from a C programmers perspective and now I see your concern.
> That _does_ make it subject to the GPL, at least if you accept the GNU
> definiton of "derived work". If the GPL allowed this usage, there'd
> be no need for the LGPL.
I hate talking about licensing issues, but I would hope that the
implementor of any GPL typed software would put the run-time libs
under LGPL. That seems to be the point of the two different
documents, and unfortunately might not be as well known as it should
be.
Or I could be mistaken and someone more knowledgable could point out
the difference.
--
burton samograd
······@kruhft.dyndns.org
http://kruhftwerk.dyndns.org
Burton Samograd wrote:
> I hate talking about licensing issues, but I would hope that the
> implementor of any GPL typed software would put the run-time libs
> under LGPL. That seems to be the point of the two different
> documents, and unfortunately might not be as well known as it should
> be.
For lisp programs, there's a variant license called the LLGPL,
which is necessary because the LGPL may not interact well with
lisp macros.
Paul
"Paul F. Dietz" <·····@dls.net> writes:
> Burton Samograd wrote:
> For lisp programs, there's a variant license called the LLGPL,
> which is necessary because the LGPL may not interact well with
> lisp macros.
Heh, I thought you were joking until I googled for it :) I can't wait
until someone comes up with the LLGPLGLLLGPL...
Like I said, I hate licensing issues...
--
burton samograd
······@kruhft.dyndns.org
http://kruhftwerk.dyndns.org
Daniel Barlow wrote:
> I didn't say it did. However, if I want to compile code at runtime -
> which is not such an unusual thing to want to do (especially if you're
> using PCL as an object system, as it does this internally) - my code
> lives in the same process image as the code of the GPLed compiler.
Not necessarily. You can imagine sticking the compiler off in
a separate process and sending the code back and forth. gcl
already invokes the compiler in a separate process (on C).
Note that the gcc people made an explicit decision *not*
to separate the back end from the front end(s) by this
kind of mechanism, though, to prevent commercial companies
from using one of the parts with their own proprietary
components (this is often debated on the gcc mailing list,
since it makes debugging and testing more difficult.) So you'd
have to fork gcc's back end to make this work.
Frankly, I'd rather see gcc reimplemented in lisp. :)
Paul
In article <··············@noetbook.telent.net>,
Daniel Barlow <···@telent.net> writes:
> Burton Samograd <······@hotmail.com> writes:
>> Your code doesn't become GPL just because you use a GPL compiler. The
>> license isn't that viral.
>
> I didn't say it did. However, if I want to compile code at runtime -
> which is not such an unusual thing to want to do (especially if you're
> using PCL as an object system, as it does this internally) - my code
> lives in the same process image as the code of the GPLed compiler.
are you sure? i would have asumed that this would be done by a lisp2c
translator that writes the c code to a file and then calls gcc as an
external process
hs
--
Q. what has linux in common with a teepee?
A. no windows, no gates, apache inside
* Hartmann Schaffer wrote:
> are you sure? i would have asumed that this would be done by a lisp2c
> translator that writes the c code to a file and then calls gcc as an
> external process
The problem with this is that it's fairly hard to get it to work well
enough. There are issues with performance - if you're compiling stuff
really on the fly you want the compiler to be *very* fast. As an
example of that, we have a document processing system which has what
are essentially lisp-style macros. These things get compiled
on-the-fly as the document is read, and you *really* want this to be
fast. It might be that you could do this by having the compiler in
some kind of pipe - source went in one end and binary came out the
other - but you probably *couldn't* do it via the filesystem, because
you'd likely saturate the disk (creating hundreds of tiny files a
second...).
--tim
Tim Bradshaw wrote:
> but you probably *couldn't* do it via the filesystem, because
> you'd likely saturate the disk (creating hundreds of tiny files a
> second...).
It's quite easy to make file systems that never touch a disk
at all, but stay in RAM (either by making ramdisks, or by having
caching that prevents the files from being written to disk immediately;
if you delete them soon enough the disk is never touched.)
Paul
* Paul F Dietz wrote:
> It's quite easy to make file systems that never touch a disk
> at all, but stay in RAM (either by making ramdisks, or by having
> caching that prevents the files from being written to disk immediately;
> if you delete them soon enough the disk is never touched.)
yes, of course (indeed /tmp is such a FS on most Unix machines). You
still have to make system calls &c though which take a lot longer than
in-process function calls in general. But, you know, I *really* don't
want to have the performance of my in-core compiler depend on the FS.
--tim
Tim Bradshaw wrote:
> yes, of course (indeed /tmp is such a FS on most Unix machines). You
> still have to make system calls &c though which take a lot longer than
> in-process function calls in general.
But you were suggesting sending the data to/from the compiler by a pipe,
which also involves system calls.
Paul
* Paul F Dietz wrote:
> But you were suggesting sending the data to/from the compiler by a
> pipe, which also involves system calls.
Good point. I think my intuition is that even tmpfs IO is slower than
pipes, but I suspect either is significantly slower than in-image
function calls (apart from anything on a single-CPU machine you'll get
loads of context switches).
--tim
Tim Bradshaw wrote:
> Good point. I think my intuition is that even tmpfs IO is slower than
> pipes, but I suspect either is significantly slower than in-image
> function calls (apart from anything on a single-CPU machine you'll get
> loads of context switches).
The bigger problem is likely going to be that gcc is slow as hell,
and trending slower with each release.
Paul
"Paul F. Dietz" <·····@dls.net> writes:
> Tim Bradshaw wrote:
>
> > Good point. I think my intuition is that even tmpfs IO is slower than
> > pipes, but I suspect either is significantly slower than in-image
> > function calls (apart from anything on a single-CPU machine you'll get
> > loads of context switches).
>
> The bigger problem is likely going to be that gcc is slow as hell,
> and trending slower with each release.
It really is amazing how they've kept up with the increase in
processor speeds. I mean, compiling Emacs from 1997, using gcc from
1997 on a machine from 1997 is about as fast as compiling the same
Emacs with a gcc from 2002, on a machine from 2002. Quite a feat!
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
··@heaven.nirvananet (Hartmann Schaffer) writes:
> are you sure? i would have asumed that this would be done by a lisp2c
> translator that writes the c code to a file and then calls gcc as an
> external process
The discussion at hand is the writing of a lisp-compiling front end to
GCC, i.e. one that compiles to one of[1] GCC's intermediate
representations.
Cheers,
M.
[1] I *think* GCC has several of these these days, but am hardly an
expert.
--
While preceding your entrance with a grenade is a good tactic in
Quake, it can lead to problems if attempted at work. -- C Hacking
-- http://home.xnet.com/~raven/Sysadmin/ASR.Quotes.html
Burton Samograd <······@hotmail.com> writes:
> Daniel Barlow <···@telent.net> writes:
>
> > Lars Brinkhoff <·········@nocrew.org> writes:
> > > Or nightmare? Few Lisp programmers seem to think a Lisp front end to
> > > GCC would be very useful.
> >
> > Fine if you only ever want to write GPLed code, or if you can live
> > without the compiler at runtime.
>
> Your code doesn't become GPL just because you use a GPL compiler. The
> license isn't that viral.
It depends on how you use it. It is not uncommon for a CL program to
use the compiler itself during execution. The compiler can be a
component of the program.
I wouldn't mind GPL.
Mario.
Any Mac OS X support yet???
in article ····························@posting.google.com, Pierre R. Mai at
·······@pmsf.de wrote on 4/10/03 12:33 PM:
> ========================== C M U C L 18 e =============================
>
> The CMUCL project is pleased to announce the release of CMUCL 18e.
> We hope you enjoy using this release of CMUCL!
>>>>> "Sterling" == Sterling Garwood <·········@comcast.net> writes:
Sterling> Any Mac OS X support yet???
Not yet, but someone is (was?) working on it.
Ray