When a literal appears in the file multiple times its identity should be preserved. CLHS 3.2.4.4: > If two literal objects appearing in the source code for a single > file processed with the file compiler are the identical, the > corresponding objects in the compiled code must also be the identical. Previously, every bytecode object created during ext::bc-compile-file had its own vector of constants making it impossible to satisfy this constraint. Thus, we change ext::bc-compile-file to use the same constants vector for all bytecode objects from the same file. The simplest way to achieve this is to use the same compiler environment for all of the compilation process and push the read-compile loop into the si_bc_compile_from_stream function implemented in C. |
||
|---|---|---|
| contrib | ||
| examples | ||
| msvc | ||
| src | ||
| .gitignore | ||
| .gitlab-ci.yml | ||
| appveyor.yml | ||
| CHANGELOG | ||
| configure | ||
| COPYING | ||
| INSTALL | ||
| LICENSE | ||
| Makefile.in | ||
| README.md | ||
ECL stands for Embeddable Common-Lisp. The ECL project aims to produce an implementation of the Common-Lisp language which complies to the ANSI X3J13 definition of the language.
The term embeddable refers to the fact that ECL includes a Lisp to C compiler, which produces libraries (static or dynamic) that can be called from C programs. Furthermore, ECL can produce standalone executables from Lisp code and can itself be linked to your programs as a shared library. It also features an interpreter for situations when a C compiler isn't available.
ECL supports the operating systems Linux, FreeBSD, NetBSD, DragonFly BSD, OpenBSD, Solaris (at least v. 9), Microsoft Windows (MSVC, MinGW and Cygwin) and OSX, running on top of the Intel, Sparc, Alpha, ARM and PowerPC processors. Porting to other architectures should be rather easy.