The gmp manual (https://gmplib.org/manual/Custom-Allocation.html) states > GMP may use allocated blocks to hold pointers to other allocated blocks. This will limit the assumptions a conservative garbage collection scheme can make. Thus we can't use ecl_alloc_atomic. We could just use ecl_alloc instead, however our implementation is already structured in such a way that it is sufficient to use ecl_alloc_uncollectable. The reason for that is that currently all bignums except those in the bignum registers in the thread local environment are allocated as compact objects so that we only need to call mpz_clear for the few non-compact objects in the bignum registers. See also commits |
||
|---|---|---|
| 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.